🔒 Registro cerrado · Apertura oficial próximamente · Acceso exclusivo para alumnos activos
Iniciar SesiónBases NoSQL abiertas y su modelo de acceso
4 tareas · 40 min · Principiante
Los motores NoSQL nacieron para vivir detrás de una aplicación, en una red de confianza, y algunos todavía se instalan con esa idea: sin pedir usuario. Cuando alguien abre su puerto a una red más grande sin cambiar eso, la base queda al alcance de cualquiera que pregunte. Esta sala lee lo que respondieron los dos MongoDB y los dos Redis de Mensajería Nimaima, compara sus archivos de configuración y aprende a documentar el hallazgo con metadatos, sin abrir un solo documento.
Objetivo de la sala
Los motores NoSQL nacieron para vivir detrás de una aplicación, en una red de confianza, y algunos todavía se instalan con esa idea: sin pedir usuario. Cuando alguien abre su puerto a una red más grande sin cambiar eso, la base queda al alcance de cualquiera que pregunte. Esta sala lee lo que respondieron los dos MongoDB y los dos Redis de Mensajería Nimaima, compara sus archivos de configuración y aprende a documentar el hallazgo con metadatos, sin abrir un solo documento.En un motor relacional es raro encontrar uno que no pida usuario. En los NoSQL no tanto, y conviene saber por qué. MongoDB, según su documentación oficial, no activa el control de acceso por defecto: si nadie lo enciende en la configuración, cualquiera que llegue al puerto puede leer y escribir. Lo que lo protege en una instalación nueva es otra cosa: por defecto solo escucha en la propia máquina.
Redis sigue una idea parecida. Su documentación describe un modo protegido que entra en juego cuando el motor escucha en todas las interfaces y no tiene contraseña: en ese caso solo contesta a la propia máquina y rechaza al resto con un mensaje que explica cómo configurarlo bien.
La consecuencia para el evaluador: una base NoSQL abierta a la red casi nunca es un descuido de una sola línea. Alguien cambió dónde escucha y no encendió el acceso, o apagó la protección a mano.
Responde para continuar
Encuentras un MongoDB que responde sin credenciales desde la red de oficina. ¿Qué cambio de configuración lo explica casi siempre?
Ver pista de ayuda
Por defecto escucha solo en la propia máquina y no pide usuario.
El administrador de Nimaima hizo una consulta de solo lectura sin credenciales desde la VLAN de oficina contra cada motor NoSQL y entregó lo que respondió cada uno. Uno de los MongoDB entrega su lista de bases. Tres de los nombres son bases internas que trae el propio motor; la cuarta es la que importa.
Abre el laboratorio y lee la respuesta de cada motor.
Responde para continuar
Escribe el nombre de la base de la empresa que aparece en la lista entregada sin credenciales.
Ver pista de ayuda
Ejecuta `SELECT * FROM nosql` y fíjate en la respuesta de nmm-mongo01.
Los dos MongoDB de Nimaima son del mismo equipo de administración y, aun así, uno rechaza la consulta sin credenciales y el otro no. La forma más rápida de ver por qué es comparar sus archivos de configuración línea a línea: lo que le falta a uno es lo que el otro tiene.
Esa comparación es además la recomendación del informe: el ajuste exacto que hay que añadir, escrito como lo escribe el motor.
Responde para continuar
Escribe el parámetro que tiene el MongoDB que pide usuario y que no aparece en el archivo de nmm-mongo01.
Ver pista de ayuda
Ejecuta `SELECT * FROM configuracion` y compara las filas de nmm-mongo01 con las de nmm-mongo02.
Uno de los Redis tiene el modo protegido apagado, escucha en todas las interfaces y no pide contraseña. El administrador dice que no importa: «es solo caché, si se borra se vuelve a llenar». La documentación del propio motor advierte de dos riesgos que esa frase ignora: un cliente con acceso completo puede vaciar toda la base con una orden, y puede cambiar la configuración del motor, incluida la carpeta donde escribe sus archivos.
Además, «caché» no dice qué hay dentro: en muchas aplicaciones es donde viven las sesiones de los usuarios conectados.
Para el informe basta con la configuración y el conteo de claves que entregó el administrador: no se lee ninguna clave.
Responde para continuar
¿Cómo tratas en el informe el Redis abierto que el cliente llama «solo caché»?
Ver pista de ayuda
El impacto sale de lo que permite el acceso, no de lo que el cliente cree que guarda; y la carta prohíbe abrir datos.
Whoami-Labs Pro
Whoami-Labs Pro utiliza cookies
Utilizamos cookies y almacenamiento local para el funcionamiento del sitio, seguridad de sesión y, si lo autorizas, analítica y marketing. Puedes aceptar, rechazar o personalizar. Política de Privacidad
Preferencias
Configuraciones de cookies
Elige qué categorías permitir. Las esenciales siempre están activas. Consulta la Política de Privacidad.
Esenciales
Siempre activas · sesión, CSRF, tema y esta preferencia
Necesarias para iniciar sesión, proteger formularios (CSRF) y recordar tu elección de cookies y tema. Sin ellas la plataforma no funciona de forma segura.
Analíticos
Hoy no activos en la plataforma; listos para cuando se conecten
Nos ayudan a entender uso de cursos y páginas. Si los activas, se usarán cuando conectemos analítica; hasta entonces no se carga ningún tracker.
Marketing
Hoy no activos; campañas futuras solo con tu permiso
Comunicaciones o campañas. No activos hoy en la plataforma; quedarán listos si los conectamos y solo si los permites.