1) ¿Qué sugerencias hay para prevenir esto como un riesgo de seguridad? (¿tal vez el hecho de ser propietario del proceso mongodb por parte de un usuario / grupo que ni siquiera sudo permitiría un cierre? es decir, otra combinación desconocida de nombre de usuario / contraseña que el pirata informático necesitaría para romper la fuerza bruta?)
Defensa en profundidad requiere varias capas de seguridad. Usted tiene razón al decir que un atacante que obtiene acceso de superusuario tiene un amplio acceso a su servidor, pero parece estar trivializando el esfuerzo para hacerlo. En el escenario sugerido, existen varios compromisos de seguridad graves: un atacante tiene acceso a sus credenciales de AWS, al archivo cliente .pem y al acceso sin contraseña sudo . Con este nivel de acceso, un atacante tiene efectivamente control total sobre su infraestructura de AWS.
Una lista no completa de medidas de seguridad proactivas a considerar incluye:
- Bloquee la cuenta predeterminada
ec2-user SSH para que solo pueda usarse localmente o desde un conjunto limitado de IP confiables.
- Actualice su configuración
sudoers (utilizando visudo ) para evitar o Limitar el inicio de sesión sin contraseña. sudo access puede limitarse a un subconjunto de comandos con o sin solicitar la contraseña del usuario. Una configuración NOPASSWD para algunos o todos los comandos sudo es una conveniencia, pero ciertamente no es un requisito.
- Limite la exposición de la red SSH a través de firewall o envoltorios TCP (consulte: Cómo mantener el acceso SSH seguro ).
- Cree una cuenta SSH con un acceso más limitado para el inicio de sesión remoto.
- Agregar monitoreo / alerta para intentos de inicio de sesión remotos (exitoso y no exitoso)
2) ¿El uso de --auth es importante en absoluto (suponiendo que ya he asegurado mi base de datos mediante el uso de puntos finales basados en token para el público) porque no quiero que la gente envíe nombres de usuario y contraseñas a mi puntos finales. Veo que es menos seguro que usar un token)
Asegurar los puntos finales de su API pública es un ejercicio relacionado (pero separado) de asegurar su base de datos. Una analogía de la vida real podría ser: "si tiene un candado en la puerta delantera, ¿debería también cerrar la puerta delantera o guardar sus objetos de valor en una caja fuerte?".
Tener autenticación & El control de acceso habilitado es parte de su estrategia de defensa en profundidad y un primer paso en la Lista de verificación de seguridad de MongoDB . Si alguien comprometió su servidor de aplicaciones u otro host de red de confianza, no debería obtener automáticamente acceso completo a la implementación de su base de datos. El control de acceso también puede evitar algunos errores de lógica de la aplicación: por ejemplo, asegurarse de que su API esté limitada a las operaciones CRUD y no pueda (ab) usarse para enviar comandos de reconfiguración de clústeres. Debe considerar la seguridad entre sus usuarios finales y su API, su API y el despliegue de su base de datos, y todos los demás aspectos de su infraestructura. Una buena estrategia de defensa en profundidad incluirá el monitoreo y la detección de intrusos para que esté al tanto de cuándo se están probando y comprometiendo potencialmente sus defensas.