Asegurar contraseñas en el entorno de producción

Question

Tenemos una aplicación web Java que se ejecuta en JBoss y Linux. Los parámetros de conexión de la base de datos del entorno de producción provienen de un archivo de configuración que solo existe en los servidores de aplicaciones del entorno de producción. Ese archivo de configuración solo es legible por el ID de usuario que también ejecuta la aplicación (llamemos a ese usuario del usuario) y las únicas personas que pueden iniciar sesión en los servidores del entorno de producción y sudo al usuario de la aplicación son miembros de nuestro equipo de Operaciones. El entorno de producción en sí está separado de todos los demás entornos.

Queremos que sea más seguro. Específicamente, nos gustaría evitar que el equipo de operaciones lea la contraseña de conexión de la base de datos y otras claves que se encuentran actualmente en el archivo de configuración.

Otro factor a tener en cuenta es que el equipo de operaciones es responsable de crear y desplegar la aplicación.

¿Cuáles son nuestras opciones? La solución debe ser compatible con el reinicio manual de la aplicación y el inicio automático de la aplicación si el SO se reinicia.

actualización

La solución estoy investigando ahora (punta a Adamski por su sugerencia, que se podría traducir en el paso 1):

1. escribir una ejecutable envoltorio que es setuid a un usuario que inicia/detiene las aplicaciones y posee los archivos de configuración y todo lo que está en el árbol de directorios de JBoss.

2. Utilice jarsigner para firmar WAR después de que se haya creado. La construcción de la GUERRA se hará por desarrollo. El contenedor setuid verificará la firma, validando que WAR no ha sido alterado.

3. Cambie el proceso de implementación para desplegar solo el WAR firmado. El contenedor setuid también puede mover el WAR en su lugar en el directorio de implementación de JBoss.

Answer 1

¿Por qué no crear simplemente un segundo usuario para el equipo de operaciones al que sudo, que solo tiene un subconjunto de permisos de archivos en comparación con el ID de usuario de la aplicación?

No son necesarios cambios de código; agradable y simple.

Answer 2

Puede que le resulte interesante para ver cómo la gente Jetty han abordado este problema:

http://wiki.eclipse.org/Jetty/Howto/Secure_Passwords

Esto al menos se asegura de que no se puede simplemente leer la contraseña directamente, sino que necesita un poco de esfuerzo para obtener una versión humanamente legible

Si la licencia de Jetty es compatible con lo que quiere hacer, simplemente puede levantar su código.

Answer 3

La manera fácil es utilizar los permisos de Unix para controlar quién puede leer estos archivos. Sin embargo, los datos confidenciales, como las contraseñas, nunca deben almacenarse de forma sencilla. Hay algunas alternativas. Requieren cierto esfuerzo, pero ese es un enfoque seguido por la mayoría de los productos comerciales.

Almacene las contraseñas encriptadas en el sistema de archivos. Puede usar la criptografía Java o XML encryption para hacerlo.

O

tienda información confidencial, como contraseñas en una base de datos, junto con otros detalles de la configuración y cifrar usando herramientas de bases de datos. Aún necesitará almacenar la contraseña de la base de datos en algún lugar del sistema de archivos. Oracle proporciona una billetera para almacenar la contraseña. También hay algunos monederos de terceros que pueden hacer esto, si el proveedor de su base de datos no proporciona uno.