¿Cómo lidiar con las contraseñas durante la implementación automatizada?

Question

Como administradores responsables, conocemos debilidades comunes como

• CWE-260: Contraseña en el archivo de configuraciónhttp://cwe.mitre.org/data/definitions/260.html
• CWE-522: Credenciales insuficientemente protegidashttp://cwe.mitre.org/data/definitions/522.html
• CWE-257: Almacenamiento de contraseñas en un formato recuperablehttp://cwe.mitre.org/data/definitions/557.html

Pero, ¿cómo abordamos esto en la práctica?

Por supuesto, con tecnologías como la autenticación sin contraseña a través de SSH y herramientas como sudo, es posible deshacerse de las credenciales de inicio de sesión almacenadas en lugares importantes y esto realmente ayuda durante la implementación automatizada de servidores Linux.

Pero tan pronto como abandona el sistema operativo e instala aplicaciones, es muy probable que se enfrente al problema de dónde almacenar de forma segura las contraseñas.

Por ejemplo, si instala un servidor de base de datos, lo más probable es que necesite guardar la contraseña en texto sin cifrar en un archivo de configuración de su aplicación web.

Luego, debe proteger el archivo de configuración para que solo el administrador pueda ver las credenciales y debe limitar los permisos de acceso del usuario de la base de datos para limitar el posible impacto en la seguridad.

Pero, ¿cómo tratar, por ejemplo, con la cuenta de la base de datos administrativa principal? Al menos su administrador de bases de datos debería saberlo (por lo que necesita el texto sin cifrar en algún lugar) y, como administrador del sistema operativo, deberíanoconocer las credenciales. O el despliegue lo realizan devops y no deberían saberlo.cualquierde las credenciales en los servidores de producción.

Soluciones posibles

Después de pensar en esto durante un período de tiempo más largo, se me ocurren tres posibles soluciones, pero tienen sus propias debilidades:

1. Genere credenciales aleatorias durante la implementación y guárdelas en una base de datos en formato de escritura única. Y, por ejemplo, los dbas tienen otro usuario que solo puede leer las credenciales de la base de datos. Pero, ¿cómo lidiar con contraseñas de texto sin cifrar en archivos de configuración de, por ejemplo, aplicaciones web? Un usuario root podría leerlos. También el usuario root de la base de datos de contraseñas podría leertodocredenciales de contraseña.

2. Acepte contraseñas de texto sin cifrar y credenciales predeterminadas durante la implementación y agregue una posdata que cambietodos y cada unocontraseñas. Quizás incluso interactivo donde las personas autorizadas deben ingresar las credenciales durante el tiempo de ejecución del script.

3. Cifre la contraseña de forma asimétrica con la clave de un tercero de confianza. Cuando se solicita la contraseña,debe sercambiado después.

¿Qué opinas? ¿Ve alguna de las mejores prácticas aquí?

Answer 1

1. Debe tener una base de datos segura y cifrada con todas sus credenciales.
2. Un servidor debe ser totalmente inaccesible desde el exterior gracias a los firewalls durante la implementación.
3. Está bien que un script genere un pase aleatorio y se lo envíe por correo electrónico.
4. También está bien cambiar esa contraseña después de que se haya aprovisionado el servidor, ANTES de haber permitido el acceso al público.
5. Está bien enviarse la contraseña por correo electrónico, siempre y cuando utilice su servidor de correo interno y no se enrute a través del público a través de SMTP (SMTPS es una historia diferente).

Puede sustituir el correo electrónico por casi cualquier protocolo. Puede enviar la contraseña por sftp a algún lugar, crear un mensaje único usando la API onetimesecret, cargarlo en un gist privado usando https o cualquier otra cosa que se le ocurra.

Creo que eso lo cubre.