¿La mejor manera de almacenar una contraseña de base de datos en un archivo de configuración/script de inicio?

Question

Por lo tanto, nuestras aplicaciones de servidor web necesitan conectarse a la base de datos y algunas otras aplicaciones tienen scripts de inicio que se ejecutan en el momento del arranque.

¿Cuál es la mejor manera de almacenar el nombre/contraseña de estas aplicaciones, en términos de

• seguridad, p.e.Quizás no queremos que los administradores de sistemas sepan la contraseña de la base de datos.
• mantenibilidad, p.e.haciendo que la configuración sea fácil de cambiar cuando cambia la contraseña, etc.

¡Se agradecen tanto las soluciones de Windows como las de Linux!

Answer 1

La mejor manera de proteger su contraseña es dejar de usarla.Utilice una conexión confiable:Cómo:Conéctese a SQL Server usando la autenticación de Windows en ASP.NET 2.0.Entonces no tiene nada que ocultar: publique su web.config y su fuente al mundo, todavía no podrán acceder a su base de datos.

Si eso no funciona para usted, utilice el integrado configuración del sistema de cifrado en ASP.NET.

Answer 2

PostgreSQL ofrece una buena solución para este tipo de situación en su documentación.Básicamente, utiliza ssh para conectar un puerto de su máquina con el puerto del servidor PostgreSQL en la máquina remota.Este tiene tres etapas de autenticación:

1. Restrinja el acceso al puerto local, por ejemplo, permitiendo que solo un usuario en particular se conecte a él.
2. Configure una conexión sin contraseña al host PostgreSQL con ssh como usuario particular.
3. Permitir que el usuario se conecte ssh para tener acceso local a PostgreSQL sin contraseña.

Esto reduce la seguridad de si sus cuentas de usuario están seguras y su configuración ssh es sólida, y no necesita tener una contraseña almacenada en ningún lugar.

Editar:Debo agregar que esto funcionará con cualquier base de datos que escuche un puerto TCP/IP.Resulta que se describe en PostgreSQL.Y querrás que iptables (o su equivalente en Linux) realice las restricciones de puerto.Ver este.

Answer 3

Estoy de acuerdo con lomaxx:Si alguien ya está en el servidor o tiene amplio acceso a él (como un administrador de sistemas), el juego prácticamente ha terminado.Entonces, la idea sería utilizar un servidor en el que confíe y que sea seguro en la medida en que lo desee.Específicamente:

• Necesitas confiar en los administradores de sistemas.
• Debes confiar en cualquier otra persona que esté ejecutando código en el mismo servidor (es por eso que el alojamiento compartido es un gran no-no para mí)

Más allá de eso, las variables de entorno parecen ser una opción popular para almacenar este tipo de credenciales, porque esto significa que el acceso solo a la fuente (por ejemplo, comprometiendo el cuadro de desarrollo) no la revela directamente y además se puede localizar muy bien para cada servidor (desarrollador, prueba, etc.).

Answer 4

¿Texto sin formato?Si están en su servidor, espero que el servidor sea lo suficientemente seguro como para no permitir el acceso no autorizado.Si las personas pueden acceder a sus archivos de configuración en el servidor, algo salió mal mucho antes.

Answer 5

aclaración:en términos de seguridad, mantenibilidad (p. ej.si es necesario cambiar el inicio de sesión, ¿puedo encontrarlo más tarde, etc.)

@lomax:tal vez no quiera que todos tengan acceso al servidor físico (p. ej.sysadmins) para ver la contraseña.

¡Gracias!

Answer 6

En la mayoría de los casos, creo que es suficiente ofuscar la contraseña en un archivo de texto plano (por ejemplo.con base64).No se puede proteger completamente una contraseña almacenada contra un administrador de sistemas determinado con acceso de root, por lo que realmente no es necesario intentarlo.Sin embargo, la simple ofuscación protege contra revelar accidentalmente la contraseña a un internauta.

Una alternativa más compleja es configurar un servidor de contraseñas seguro y dedicado que:

• proporciona un servicio de descifrado de contraseñas
• en realidad almacena las contraseñas para que las utilicen otros servidores menos seguros

Dependiendo de los protocolos de red utilizados, es posible que esto no proteja contra un administrador de sistemas fraudulento con tcpdump.Y probablemente tampoco protegerá contra un administrador de sistemas determinado con un depurador.En ese momento, podría ser el momento de considerar algo como los tickets de Kerberos.

Answer 7

Puede incorporar una clave de cifrado simétrica en su binario y hacer que ese binario lea un nombre de usuario/contraseña cifrados de un archivo en el disco cuando se inicie.

Sin embargo, esto no es mucho más que una ofuscación, ya que es probable que su código esté almacenado en algún repositorio fuente en algún lugar.

Sugeriría que sería mejor para usted controlar el acceso a sus servidores tanto físicamente como a través de la red utilizando un firewall y una burbuja de red privada, y almacenar las contraseñas en formato claro (o codificadas en base 64) en el disco con permisos bloqueados. al usuario de ejecución de su aplicación web.

También puede bloquear el servidor de la base de datos para que solo acepte conexiones desde las máquinas de su aplicación web por IP.

En última instancia, su problema es que la clave (su par de nombre de usuario/contraseña de base de datos) debe estar disponible para su uso programático y desatendido por sus aplicaciones web.