4 votos

¿Cómo lidiar con las contraseñas durante el despliegue automatizado?

Como responsable de administradores sabemos de deficiencias comunes como

Pero, ¿cómo podemos lidiar con 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 almacena credenciales de inicio de sesión en lugares importantes y esto realmente ayuda durante la implementación automatizada de servidores Linux.

Pero tan pronto como usted deje el sistema operativo e instalar aplicaciones, las posibilidades son altas de que usted se enfrenta con el problema de que para almacenar de forma segura las contraseñas.

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

A continuación, debe proteger el archivo de configuración para que sólo el administrador puede ver las credenciales y usted debe limitar los permisos de acceso a la base de datos de usuario para limitar el posible impacto en materia de seguridad.

Pero, ¿cómo lidiar con, por ejemplo, la principal base de datos administrativa de cuenta? Al menos sus administradores de bases de datos debe saber (por lo que usted necesita en algún lugar de la de texto sin formato) y como OS admin debe no conoce las credenciales. O la implementación se lleva a cabo por devops y que no debe saber cualquiera de las credenciales de los servidores de producción.

Posibles soluciones

Después de pensar en esto por un largo periodo de tiempo, se me ocurren tres posibles soluciones, pero tienen debilidades de su propia:

  1. Generar al azar credenciales durante la implementación y almacenarla en una base de datos en escribir una vez a la moda. Y, por ejemplo, administradores de bases de datos tiene otro usuario que puede leer sólo credenciales de base de datos. Pero, ¿cómo lidiar con contraseñas sin cifrar en los archivos de configuración, por ejemplo, de webapps? Un usuario root puede leer. También el usuario root de la base de datos de contraseñas, posiblemente, podría leer todos los credenciales de contraseña.

  2. Aceptar como texto sin cifrar las contraseñas y credenciales predeterminadas durante la implementación y añadir una coletilla que los cambios de cualquier y todas las contraseñas. Tal vez incluso interactivo donde las personas autorizadas deben introducir las credenciales durante el tiempo de ejecución de la secuencia de comandos.

  3. Cifrar la contraseña de forma asimétrica con la clave de la confianza de terceros. Cuando la contraseña se pone solicitada, debe ser cambiado posteriormente.

¿Qué te parece? ¿Puedes ver alguna de las mejores prácticas aquí?

3voto

Vasili Syrakis Puntos 2507
  1. Usted debe tener una base de datos cifrada segura con todas sus credenciales
  2. Un servidor debe ser totalmente inaccesible desde el exterior, por la virtud de los firewalls en la implementación
  3. Está bien tener un script para generar un azar pasar y por correo electrónico a usted
  4. Es también muy bien para cambiar la contraseña después de que el servidor ha sido suministrado, ANTES de que se haya permitido el acceso al público
  5. Enviando un correo electrónico a ti mismo la contraseña está bien, siempre y cuando el uso de su servidor de correo interno y no se enruta a través del público, a través de SMTP (SMTPS es una historia diferente)

Se puede sustituir el correo electrónico para apenas alrededor de cualquier protocolo. Usted podría sftp la contraseña en algún lugar, crear un mensaje en tiempo de uso de la onetimesecret api, subirlo a un privado esencial el uso de https, o cualquier otra cosa que usted puede pensar.

Creo que sobre la cubre.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: