¿Qué se puede hacer para proteger las contraseñas que se pueden almacenar en texto sin formato o con hash dentro de un repositorio de git?

Bueno, todas las respuestas sensibles se pueden resumir en una regla simple:

• ¡No hagas eso!

Simplemente no hay una forma segura de ingresar contraseñas u otros valores confidenciales en un repositorio Git que será clonado por una serie de desarrolladores en rotación. Y no hay una manera automatizada a prueba de errores para atrapar tales compromisos erróneos. Por lo tanto, todos los consejos deben basarse en estos conceptos:

1. Evitando que sus desarrolladores hagan esto;
2. Detectándolo rápidamente cuando lo hacen;
3. Corrigiendo cualquier error que supere sus medidas.

Así que el consejo que puedo dar es:

Necesitas desarrolladores que se preocupen

Si a sus desarrolladores simplemente no les importa la corrección y la seguridad, abandone toda esperanza. Puedes llevar un caballo al agua pero no puedes hacer que beba.

Revisión cuidadosa y exhaustiva del código

Incluso si tienes desarrolladores a los que les importa, es probable que sigan cometiendo errores de vez en cuando. Esto significa que sus desarrolladores deben revisar el código de cada uno, detectar los errores y solicitar que se solucionen.

Automatización de primer nivel para desarrolladores

¿Por qué sus desarrolladores necesitan contraseñas confidenciales en primer lugar? En mi experiencia, este es un síntoma del que carece la automatización del desarrollador. Por ejemplo, un escenario común es que la aplicación interactúa con un RDBMS y, por lo tanto, se crea una base de datos compartida en algún lugar y los desarrolladores necesitan credenciales para iniciar sesión.

Así que arregla eso. Utilice una herramienta como Docker o Vagrant para que sus scripts de construcción proporcionen a sus desarrolladores instancias locales y desechables de todos los recursos externos que la aplicación necesita, con la mínima necesidad de configurar cadenas de conexión o nombres de usuario o contraseñas o cualquier otra cosa.

Herramientas de análisis de código

Existen herramientas de análisis que pueden ayudar a dicho proceso de revisión al inspeccionar su código y adivinar los lugares donde podría haber problemas. Estas herramientas nunca pueden ser completamente confiables; producirán algunos falsos positivos y se perderán algunos problemas reales. Algunas de las herramientas también son malas, así que evalúe cualquier cosa con cuidado antes de comprometerse. Evalué SonarQube en los programas de Java y en general me impresionó; contiene algunas reglas para buscar posibles debilidades de seguridad . (No tengo ninguna afiliación con la empresa).

Herramientas de gestión secretas

En lugar de escribir sus programas para que lean los secretos de las variables de entorno o los archivos de configuración (o, lo que es peor, ¡los secretos codificados!), escríbalos para que los obtengan de un sistema de administración secreto como Vault o Keywhiz . Sin embargo, esto requiere que los desarrolladores trabajen un poco más duro para aprender la herramienta e integrarse con ella, lo que a su vez requiere que se preocupen.

Estandarizar la gestión secreta

Si no adopta una herramienta como Vault o Keywhiz, todavía debe estandarizar el mecanismo mediante el cual sus aplicaciones acceden a contraseñas y otros secretos. Por ejemplo, exija que todas sus aplicaciones lean sus contraseñas de un archivo llamado appname-credentials.json . Entonces puedes:

1. Haga que los revisores de su código rechacen cualquier código que no siga la práctica;
2. Agregue una regla a .gitignore para rechazar cualquier nombre de archivo que cumpla con ese patrón.

Estructure su base de código para proporcionar una ubicación "segura" para archivos confidenciales

("Seguro" en citas de miedo porque aunque esto es más seguro que muchas bases de código que veo, no es realmente tan seguro ...)

Un problema que sigo viendo en muchas aplicaciones Java es que obtienen toda su configuración de los archivos de configuración que se incluyen en el archivo JAR o WAR de la aplicación. Lo hacen porque:

1. Las herramientas de construcción populares de Java como Maven o Gradle proporcionan un mecanismo predeterminado y convencional para agrupar tales archivos de configuración;
2. Los frameworks populares de Java hacen un uso extensivo de tales archivos y facilitan el acceso a ellos;
3. Los desarrolladores, la mayoría de las veces, simplemente no les importa la seguridad o la corrección.

Un truco que se ha utilizado en muchos proyectos en los que he participado es configurar la herramienta de compilación para que, además de las ubicaciones predeterminadas, también agrupe los archivos de configuración de otra ubicación estándar del proyecto que tiene un archivo .gitignore que evita que se registre algo allí.

Esto todavía tiene una debilidad: las contraseñas no se registran, pero se agrupan en los archivos de aplicaciones que los desarrolladores crean. Si luego los entregan a personas externas, han revelado contraseñas.

Una cosa que podría hacer es almacenar las contraseñas dentro de un archivo de configuración (por ejemplo, Laravel las almacena dentro de .ENV) y luego evitar cometerlas en el repositorio, agregándolas a .gitignore.

Los usuarios deberán crear uno manualmente después de descargar el repositorio.

Muchas herramientas de análisis de código estático permitirán la búsqueda de contraseñas codificadas y marcadas, lo que podría suceder en una etapa temprana del proceso de integración continua, lo que al menos haría menos probable que el código con contraseñas codificadas se fusione para dominar.

enlace

Sin embargo, en última instancia, esta es una oportunidad educativa para desarrolladores: si un desarrollador desea introducir contraseñas codificadas, probablemente pueda hacerlo, a pesar de los bloqueos automáticos. El proceso, la política y el procedimiento tienen su lugar, y creo que aquí es donde están la verdadera respuesta.