¿Es seguro almacenar contraseñas críticas en las variables de entorno del servidor?

Tengo un grupo de servidores, cada uno con archivos de configuración que actualmente contienen contraseñas de texto sin formato para sistemas sensibles y de misión crítica (colas de mensajes, almacenes de datos y otros servicios).

Algunas personas mueven las contraseñas críticas de los archivos de configuración a una variable de entorno de las cuentas de usuario en las que se ejecutan los procesos del servidor. De esta manera, los archivos de configuración pueden comprometerse con el control de versiones, y el administrador del sistema solo necesita crear una variable de entorno apropiada cuando el sistema del servidor está configurado. Naturalmente, el acceso a las cuentas que ejecutan estos servicios es muy restringido.

¿Es esta realmente la mejor manera de evitar contraseñas en archivos de configuración de texto sin formato, o hay una mejor manera?

Si está en un sistema Linux, mire / proc / * / environmental y decida si las variables de entorno son un buen lugar para almacenar información confidencial o no. / proc / self es el proceso actual:

$ tr '\0' '\n' < /proc/self/environ
USER=me
LOGNAME=me
HOME=/home/me
PATH=/usr/bin:/bin:/usr/sbin:/sbin
MAIL=/var/mail/me
SHELL=/usr/bin/sh
SSH_CLIENT=1.2.3.4 58195 22
SSH_CONNECTION=1.2.3.4 58195 7.8.9.0 22
SSH_TTY=/dev/pts/1
TERM=xterm

No importa que lo que configura la variable de entorno probablemente esté leyendo un archivo en alguna parte.

Lo que debe recordar es que el uso de una contraseña significa que la contraseña está disponible para el programa. Si esta contraseña no la proporciona un usuario que la ingresa cada vez que un programa la necesita, debe accederse a esa contraseña basándose únicamente en el acceso del programa. Puede cifrar la contraseña localmente y hacer que el programa se descifre usando una clave, pero todo lo que hace es ocultar la contraseña contra la divulgación accidental; alguien que tiene el mismo acceso que el programa puede hacer lo mismo que el programa puede hacer, lo que incluye leer la clave de cifrado.

La forma correcta de hacerlo es hacer que la aplicación se ejecute como una cuenta restringida y almacenar la contraseña en un archivo protegido con permisos de nivel de sistema de archivos. Esperemos que pueda "incluir" un archivo o similar para mantener la contraseña fuera del sistema de control de versiones (suponiendo que el VCS no tenga controles de seguridad). Para protegerse contra la divulgación accidental, oculte la contraseña como desee: codifíquela en base64, use pgp para cifrar, lo que tenga sentido en el conjunto de opciones de su programa de servidor. Si está escribiendo un programa para hacer esto, lo mejor que puede hacer es solicitar a un usuario la contraseña solo cuando sea necesario, y luego purgar esa contraseña de la memoria tan pronto como se use.

En última instancia, si tiene datos que deben leerse y escribirse , terminará protegiendo algo con una contraseña (o si es realmente paranoico, con una tarjeta inteligente de hardware físico y un PIN), no importa cuántas capas de cifrado tenga.

Esto se reduce a la cuestión básica de seguridad del sistema versus conveniencia. Puede agregar "defensa en profundidad" al tener montones y montones de capas de controles de seguridad que un actor malintencionado tendría que violar para llegar a los "bienes", pero luego, cuando un actor legítimo quiere leer o cambiar algunos datos, tienen que pasar por un montón de aros. La alternativa son las contraseñas de texto sin formato en archivos de texto.

Lo que haría si realmente quisiera proteger cierta información en un sistema de misión crítica:

1. Use Full Disk Encryption, para que el contenido de todo el almacenamiento persistente esté encriptado.

2. Restrinja el acceso físico a las máquinas. Bloquee el chasis de la máquina con un mecanismo de bloqueo seguro y controle el acceso físico a las teclas. Contratar músculo (guardias armados) para ser guardianes de acceso.

3. Aplicar el control de acceso obligatorio (MAC) de grano fino en el sistema operativo del dispositivo. Puede comenzar con algo como SELinux en GNU / Linux y configurarlo como Enforcing, y luego adaptar la política a las necesidades exactas del software de producción, permitiendo a esas cuentas exactamente (y solo) los permisos que necesitan para los archivos que necesitan.

4. Si va a tener contraseñas específicas del sistema y control de versiones para los archivos de configuración, realmente desea evitar el posible error de tener una contraseña de texto sin formato comprometida por error con el control de versiones, ya que puede ser difícil quitar una contraseña filtrada de un Caché de VCS. Las variables de entorno son una de varias opciones viables para eso. El otro es una solicitud de contraseña cuando se inicia el programa, pero luego reiniciar la máquina y restaurar el estado operativo es un esfuerzo manual y no se puede hacer de forma autónoma, por lo que existe esa comodidad frente a la seguridad nuevamente.

5. Asegúrese de contar con especialistas en redes para ocuparse de los permisos del firewall y minimizar su exposición a un ataque en la red. Audite (prueba de penetración y prueba de caja blanca el código) cualquier software que interactúe con sistemas externos, especialmente Internet público. "Interfaces" incluye no solo conexiones de red directas, sino también leer o escribir datos "no confiables" (datos cuyos bytes se originaron fuera de la RAM / disco / CPU del servidor seguro).

Esta no es una lista completa, pero especialmente el punto 4 probablemente sea relevante para usted, aunque si no realiza al menos los pasos 1 a 3, la consideración del punto 4 y el punto 5 no lo ayudará mucho, porque su el sistema no es seguro a un nivel bastante fundamental.

Pasar una contraseña en una variable de entorno es tan seguro como hacer que el programa lo lea desde un archivo. Solo los procesos que se ejecutan como el mismo usuario pueden leer el entorno de un proceso , y estos procesos pueden leer los mismos archivos de todos modos.

Tenga en cuenta que esto es diferente de pasar una contraseña en la línea de comando. Todos los procesos que se ejecutan en la misma máquina pueden leer los argumentos de la línea de comandos (salvo medidas de protección), no solo los procesos que se ejecutan como el mismo usuario.

Si pasa una variable a través del entorno, tenga cuidado si el programa inicia otros programas. Esos otros programas heredarán el entorno de sus padres. Así que no hagas esto si temes que los otros programas puedan filtrar accidentalmente el contenido de su entorno.

La falla en su escenario es "crear una variable de entorno apropiada cuando el sistema del servidor está configurado". Una variable de entorno es una propiedad dinámica de un proceso. No puede crearlo al configurar un sistema, no si al configurarlo quiere decir algo que sobrevive al reinicio. Lo que quiere decir es de suponer que el administrador dispuestos para esta variable esté presente en el medio ambiente cuando un determinado usuario inicia sesión. Esto se hace a través de un archivo de configuración (normalmente ~/.pam_environmento ~/.profileo un archivo de lectura de ~/.profile). Por lo tanto, esta solución no elimina la contraseña de los archivos de configuración.

Configurar las cosas para que las contraseñas estén en el entorno de inicio de sesión de un usuario no es una buena idea. Significa que cada proceso que se ejecute como ese usuario tendrá el secreto, por lo que es vulnerable a una fuga en cualquier lugar.

Se debe colocar una contraseña en un archivo aparte de los archivos de configuración que están bajo control de versión y de los mecanismos de implementación normales. Está bien poner la contraseña en el entorno en algún momento si es conveniente, pero debe hacerse para un conjunto de programas lo más pequeño posible.