¿Dónde se debe almacenar un almacén de claves (.jks) en un repositorio?

6

Tengo una pregunta sobre las mejores prácticas para almacenar un archivo de almacén de claves ( .jks ) en el control de origen. Este Keystore es llamado por un componente Java independiente que recupera una clave privada con el propósito de firmar aserciones SAML.

Por razones de seguridad, me gustaría abstenerme de incluir este Almacén de claves en el mismo proyecto de git que nuestro código Java. Este código fuente se envía a muchas ubicaciones diferentes para las diversas herramientas utilizadas. (Herramientas de revisión de código, escáneres de código fuente) y no creo que nada bueno pueda venir de tener nuestro archivo de Almacén de claves en todas estas ubicaciones.

Eso me deja con la pregunta de, ¿cuál es el mejor lugar para incluir este archivo en el control de código fuente? He investigado un poco en Internet y todavía tengo que encontrar una buena respuesta, así que aquí están mis pensamientos.

Plan A

Planeo colocar el archivo de almacén de claves en un repositorio privado que está bloqueado. Esto solo puede ser accedido por una audiencia muy limitada. El almacén de claves se agregará al componente independiente en la compilación como una dependencia por el proceso de implementación.

- Pros

  • El almacén de claves no se distribuiría con nuestro código fuente
  • Las actualizaciones del Almacén de claves en el control de origen se podrían bloquear y supervisar cuidadosamente

- Contras

  • Mayor complejidad para la gestión de certificados
  • El almacén de claves se agregará al módulo en el proceso de implementación de todos modos, por lo que el beneficio de seguridad es limitado

Plan B

En lugar de mantener un almacén de claves estático, cada vez que se inicia el proceso de construcción, se crea un nuevo almacén de claves con una clave pseudoaleatoria. La clave se agrega como parte del código postal en nuestro proceso de compilación. Luego, los certificados deben agregarse al almacén de claves. La mayoría de las instancias de este módulo de Java tendrían certificados únicos, por lo que no mantener la referencia estática no presentaría una gran cantidad de trabajo ocupado.

- Pros

  • No hay almacén de claves estático para que los atacantes aprovechen

  • Cada instancia del almacén de claves tiene su propia contraseña

- Contras

  • Aumente la complejidad del proceso de construcción

  • Si se utiliza el mismo certificado en varias instancias de este módulo, el certificado deberá agregarse a cada uno.

¿Cuál es mi mejor opción? ¿También voy por el camino correcto con esto?

    
pregunta rdChris 18.09.2015 - 16:47
fuente

2 respuestas

2

Todas las organizaciones en las que trabajé almacenan credenciales o información igualmente confidencial en una ubicación conocida fuera del directorio de implementación de la aplicación y están protegidas por entorno. Los desarrolladores crean los archivos ellos mismos con credenciales de desarrollo, mientras que los de producción son creados por operaciones y protegidos, por lo que solo la aplicación tiene acceso.

Si desea que la aplicación se ejecute sin configuración después de la extracción, puede incrustar algunas copias ficticias que solo se utilizan cuando no se puede encontrar el archivo en la ubicación conocida.

    
respondido por el billc.cn 18.09.2015 - 18:26
fuente
0
  

¿Cuál es mi mejor opción? También voy por el camino correcto con   esto?

Depende .

El tipo de su aplicación, el modelo de amenaza de la aplicación y el perfil de ataque de su negocio dictan la opción correcta. Si está preguntando sobre la mejor práctica, puedo sugerirle que utilice un dispositivo HSM para el entorno de desarrollo. y uno para producción . Estos dispositivos están diseñados para la administración segura de claves. Cualquier otra opción personalizada tiene uno o más fallos de seguridad, complejidad innecesaria o un vector de ataque desconocido.

Obviamente, la seguridad provista por un dispositivo HSM tiene un costo. La otra opción práctica es implementar una infraestructura PKI interna basada en software . Depende de la pila de su servidor (MS, Unix, etc.), hay diferentes maneras de implementarlo. Por ejemplo, pki.io , un proyecto de gestión de certificados X.509 de código abierto , aunque ser un proyecto joven puede simplificar La gestión interna de claves.

    
respondido por el Dr. mattle 19.10.2015 - 00:40
fuente

Lea otras preguntas en las etiquetas