Almacenar los secretos de la aplicación de forma segura en Linux

Su servicio no debería ejecutarse como root generalmente . Usar un usuario separado para almacenar el secreto es una sabia precaución, pero almacenar archivos con root de propiedad no es mejor para el secreto que usar otro usuario dedicado para esto. Siempre que su archivo secreto tenga permisos 600 o menos, estará a salvo de otros usuarios que no sean root . Cualquier cosa que se ejecute root tiene acceso completo de todos modos. (a menos que esté ejecutando alguna configuración compleja de SELinux)

Puede ser útil utilizar dos usuarios para esta aplicación única para aislar la administración secreta de la operación normal. Tiene dos demonios ejecutándose con comunicaciones en tiempo real, o tiene comandos de utilidad para operar en el secreto, obteniendo el privilegio necesario (basado en usuarios o grupos) a través de sudo .

Debes considerar posibles vectores de ataque.

• SQLi si está configurado correctamente no otorga acceso al sistema de archivos, pero los ataques de Trayectoria de Ruta podrían. Hay otros tipos de ataques en su aplicación contra los que debe protegerse.

• Explotaciones en bibliotecas de C (es decir, OpenSSL que ejecuta su encriptación HTTPS, procesamiento de imágenes, etc.) puede ser posible. El uso de un usuario separado en procesos expuestos a la red puede ayudar a limitar el alcance o agregar dificultad a un ataque.

• Los robos de otros vectores de ataque podrían ser un problema. (SSH, otros servicios en la máquina) Asegúrese de que cualquier cosa con el potencial de acceso root esté bien asegurada.

Todas estas consideraciones deberían ayudarlo a proteger el secreto. Ahora la pregunta es, ¿el secreto realmente debe almacenarse en un plano?

En el nivel más básico, sí, el secreto debe almacenarse en algún lugar para que pueda ser utilizado. Al menos tiene que almacenarse en la memoria, pero también es necesario el almacenamiento permanente de algún tipo.

Más allá de la separación de usuarios que hemos discutido, podría ser útil descargar los secretos a un Módulo de seguridad de hardware , o incluso a una mini computadora por separado. (es decir, Raspberry Pi) Hay alguna discusión sobre la separación física aquí .

Hay muy pocos casos en los que el secreto se puede cifrar en un almacenamiento permanente.

Si su preocupación es el robo de disco duro (dejando el resto de la máquina), podría tener una secuencia de comandos de arranque que solicita a algunos de los otros hardware identificadores únicos , y obtiene un clave de cifrado mediante una buena función de derivación de clave basada en contraseña; para descifrar el secreto.

Si el cliente puede proporcionar una parte del secreto, sería útil. He descrito una forma de derive claves de descifrado de contraseñas de usuario y tokens de sesión aquí . Este es un sistema elaborado pero efectivo que se centra en limitar la cantidad de tiempo que se almacena un secreto, incluso en la memoria. (suponiendo que no necesite un restablecimiento automático de la contraseña)

Lo que tienes es la forma tradicional de hacer las cosas. Así es como Tomcat, por ejemplo, recomienda hacerlo, con OWASP concurring . Entonces, lo que tienes no está mal.

Sin embargo, hay otras formas de hacerlo: los módulos de seguridad de hardware son un almacenamiento de acceso limitado diseñado para el almacenamiento de claves. El Vault de Hashicorp, KeyWhiz y otras tecnologías similares son sistemas de administración secretos, que básicamente intentan ser HSM de software. Por supuesto, todas esas tecnologías deben ser capaces de autenticar el proceso; su ventaja es que tienen una variedad de mecanismos para eso. Puede usar la raíz para obtener acceso a una clave que luego se proporciona en la memoria solo para el usuario de la web; podría usar esa clave para acceder al HSM / Vault / KeyWhiz para poder acceder y cambiar la clave real. También hay otros mecanismos: los específicos de AWS que usan las teclas EC2, y muchos otros. Es posible que puedas encontrar algo que encaje bien.

Mi opinión personal es que el usuario restringido probado y verdadero (utilizado ÚNICAMENTE para este propósito) y los archivos restringidos a ese usuario no son una mala manera de hacerlo. Sin embargo, no se escala tan bien como otras opciones.

Si el secreto se almacena en el servidor de manera que la aplicación pueda leerlo sin la intervención humana, se puede leer al menos en la raíz de la máquina.

No importa que el archivo esté en texto plano; solo se puede proteger con permisos y la raíz puede omitir esos permisos. Cifrar el archivo (o el sistema de archivos en el que se encuentra) solo ayudará si la clave de cifrado solo está disponible para el proceso de lectura del archivo, y eso requiere intervención externa (y verificación); solo estás moviendo el problema de acceso al secreto en otro lugar.

Incluso si conserva el control de todas las cuentas en el sistema, lo construye como un dispositivo, pero eso deja el problema del acceso físico al sistema. Si está contento de que se puede garantizar la integridad física, entonces tiene el problema de mantener el sistema como un dispositivo. ¿Cómo se instalarán los parches?

Estoy lejos de estar convencido de que un hsm, incluso en hardware, proporcione una solución completamente segura, en lugar de hacer que el acceso normal sea demasiado elaborado (a la vez que complica, pero no evita el acceso no autorizado).

Dado que cualquier solución sería un compromiso con sus expectativas, deberá ser más específico acerca de las restricciones (costos de desarrollo, costos unitarios, volumen esperado) junto con más detalles sobre el modelo thret.