¿Cómo evitar el almacenamiento de passwords en el control de versiones?

¿Qué estrategia usas para evitar almacenar passwords en el control de versiones?

Actualmente, tengo passwords de desarrollo / testing / producción guardadas en tres files diferentes y el file apropiado se usa durante la implementación. Todo esto está comprometido con el control de versiones, pero no estoy muy contento con eso, ya que no todos los desarrolladores necesitan saber esas passwords (especialmente las externas, que solo tienen acceso mientras duran sus proyectos, lo que podría ser de solo un mes).

Almacenar passwords en la database no es una gran opción:

  • Necesito la mayoría de los datos durante la initialization del context Spring (aplicación Java), y no quiero crear andamios para conectarme a una única database, y luego conectarme al rest de bases de datos e inicializar el rest de la aplicación
  • algunas de las passwords solo están relacionadas con la implementación; contraseña para acceder a diferentes serveres, almacenes de keys, etc .; esas son las cosas que la aplicación no puede cargar después de que se inicia, ya que no lo carga en absoluto

Estoy pensando en trasladar la configuration de implementación de la máquina del desarrollador a la computadora dedicada que verifica el código del control de la versión y ejecuta la secuencia de commands de compilation / implementación, pero no estoy seguro de cuál sería la mejor manera de hacerlo.

También necesito decir que no quiero la máxima security: solo quiero evitar tener passwords en todos los discos de los desarrolladores y hacerlo demasiado fácil.

Por eso les pido sus experiencias / mejores prácticas. ¿Cómo lo haces?

Las properties de configuration específicas del entorno tienden a poner, digamos, un file de properties que no está en control de fuente y no es parte del process de compilation. Al configurar un nuevo entorno, parte de esa configuration consiste en crear ese file de properties que incluye cosas como direcciones de bases de datos, cnetworkingenciales y nombres, nombres de hosts remotos relevantes, etc.

En Spring utiliza el PropertyPlaceholderConfigurer para cargar el file de properties. Simplemente debe ser encontrado por Spring, que generalmente solo significa colocarlo en un directory apropiado debajo del server de aplicaciones.

De forma alternativa, puede usar el contenedor para ejecutar el server de aplicaciones y las opciones de inicio de JVM incluyen agregar estos files de properties al classpath para que Spring pueda encontrarlos.

He visto dos enfoques para esto:

  • Mueva las passwords a otro tree de control de origen al que los desarrolladores no tienen acceso.
  • No coloque ninguna contraseña en el control de la fuente, y la persona dedicada al administrador de la compilation necesita escribir las passwords cada vez que se realiza una implementación. Esto fue en un banco donde había un tipo de time completo trabajando en processs de compilation / fusión / lanzamientos.

Esto no funciona en todos los casos, pero aquí es donde entra en juego la gloriosa utilidad de NT AUTHORITY \ NETWORK SERVICE a medida que entra la identidad de sus services. Si usa esta identidad, no necesita mantener una contraseña para ello – solo puede usar las cnetworkingenciales de AD de la computadora en forma de DOMINIO \ MACHINENAME $ para hacer su networking protegida y acceso a la database.

Hay, por supuesto, algunas cosas key a tener en count, una de las más importantes es que no hay dos aplicaciones que comparten un límite de security alojadas de esta manera en el mismo server.

Coloque las passwords en las variables de entorno de usuario de o / s.

Solo ese usuario o raíz puede leer el valor, lo mismo que un file, pero sin posibilidad de que se controle en el control de fuente.

Creo que es bueno tener un local_settings fuera del repository.

http://sofes.miximages.com/a/21570849/1675586

En lugar de no almacenarlos, puede almacenarlos en forma encriptada. Así que no tiene el dolor de enviar files de cnetworkingenciales a través de postría instantánea o correo electrónico todo el time que comienza un nuevo desarrollador … Solo necesita decirles la contraseña maestra específica del proyecto una vez para que puedan encriptar las cnetworkingenciales.