¿Por qué es una mala idea almacenar contraseñas en el control de versiones?

La forma en que lo veo, no almacenar contraseñas en Git (u otro control de versión) es una convención . Supongo que uno podría decidir no imponerlo con varios resultados, pero aquí está la razón por la que esto es generalmente mal visto:

1. Git hace que sea difícil eliminar las contraseñas del historial del código fuente, lo que podría dar a las personas una idea falsa de que la contraseña ya se eliminó en la versión actual.
2. Al poner la contraseña en el control de origen, básicamente decide compartir la contraseña con cualquier persona que tenga acceso al repositorio, incluidos los futuros usuarios. Esto complica el establecimiento de roles dentro de un equipo de desarrolladores, lo que podría tener diferentes privilegios.
3. El software de control de fuente tiende a ser bastante complicado, especialmente los sistemas "todo en uno". Esto significa que existe un riesgo de que este sistema pueda verse comprometido, lo que podría provocar una pérdida de la contraseña.
4. Otros desarrolladores pueden ignorar que la contraseña está almacenada y manejar mal el repositorio; tener claves en la fuente significa que se debe tener un cuidado especial al compartir el código (incluso dentro de la empresa; esto podría crear una necesidad de cifrado. canales).

I no puedo decir que todos los patrones relacionados con infosec son buenos , pero antes de romperlos, siempre es una buena idea para considerar su modelo de amenaza y vectores de ataque. Si esta contraseña en particular se filtró, ¿qué tan difícil sería para un atacante usarla para dañar a la compañía?

Primero, la razón de no seguridad:

Flujo de trabajo de cambio de contraseña

Las contraseñas cambian independientemente del código de la aplicación de software. Si un DBA cambia la contraseña de una base de datos, ¿tiene sentido que los desarrolladores tengan que actualizar el código, obtener una nueva compilación y lanzamiento para producción e intentar cronometrarlo todo? Las contraseñas son un artefacto de configuración en tiempo de ejecución, no un artefacto de desarrollo. Se deben inyectar a través de archivos de configuración, variables de entorno o cualquier paradigma de configuración que esté utilizando.

Ámbito de autorización

En general, los sistemas de control de versiones proporcionan control de autorización, de modo que solo los usuarios autorizados pueden acceder a él. Pero dentro de un repositorio, los permisos son generalmente de lectura / escritura, o de solo lectura, o posiblemente algunas campanas y silbidos como GitHub proporciona. Es poco probable que encuentre restricciones de seguridad que permitan a los desarrolladores obtener el código fuente, pero las contraseñas no . Si puede clonar un repositorio, puede clonar un repositorio. Período. En muchos entornos, los desarrolladores no tienen acceso completo a la producción. A veces tienen acceso de solo lectura a bases de datos de producción, a veces no tienen acceso. ¿Qué sucede si los desarrolladores generalmente tienen acceso, pero no quiere que todos los internos, nuevas contrataciones, etc. tengan acceso?

Environments

¿Qué sucede si tiene varios entornos, como un entorno de desarrollo, un entorno de control de calidad, una puesta en escena y producción? ¿Almacenarías todas sus contraseñas en el control de versiones? ¿Cómo sabría la aplicación cuál usar? La aplicación debería tener una forma de conocer el entorno, lo que terminaría siendo un ajuste de configuración. Si puede hacer del nombre del entorno un ajuste de configuración, puede hacer que la contraseña de la base de datos sea un ajuste de configuración (junto con la cadena de conexión, el nombre de usuario, etc.)

Historia

Como han mencionado otros, el control de versiones está diseñado para preservar el historial. Por lo tanto, las contraseñas más antiguas aún serán recuperables, lo que puede no ser lo mejor.

Compromiso

¿Cuántas veces hemos visto titulares en las noticias sobre el código fuente de algún producto que se está filtrando al mundo? El código fuente es lo que está en el control de versiones. ¡Esta es probablemente la razón principal para no poner contraseñas en el control de versiones!

However...

Dicho esto, las contraseñas deben almacenarse en algún lugar . Lo que se refiere a las preocupaciones anteriores no es necesariamente que no deban almacenarse en el control de versiones, sino que no deben almacenarse en el repositorio de código fuente del producto en el control de versiones. Tener un repositorio separado para la administración de configuraciones, operaciones, etc. es muy razonable. La clave es dividir las operaciones del desarrollo cuando se trata de credenciales de seguridad, no necesariamente para evitar por completo el control de versiones.

También, para entornos que no son de producción, he almacenado contraseñas y claves de API para sistemas externos en archivos de configuración dentro del código fuente del producto como valores predeterminados. ¿Por qué? Para hacer que sea más fácil cuando un desarrollador revisa el código, puede simplemente compilarlo y ejecutarlo sin tener que ir a buscar archivos de configuración adicionales. Estas son credenciales que rara vez cambian y no conducen a ningún secreto comercial. Pero nunca haría esto con secretos de producción.

Entonces, la conclusión es ... depende.

Siempre es importante tener en cuenta que las sugerencias deben adaptarse a su caso de uso. Las salvaguardas de seguridad adoptadas por, digamos, la NSA para proteger todos los días cero que mantienen durante un día lluvioso deben ser mucho más estrictas que las salvaguardas de seguridad tomadas para proteger los votos en un sitio de publicación de imágenes de gatos. En un extremo, puedo pensar en un ejemplo cuando mantener las contraseñas / tokens / etc en un repositorio privado de git podría ser razonable:

Si solo una persona accede a este repositorio y la aplicación no almacena ninguna información de ningún valor.

En ese caso, ve a la ciudad! Simplemente tenga en cuenta lo que dijo @ d33tah en su respuesta: limpiar las cosas de un repositorio de git puede ser sorprendentemente difícil (todo el punto, después de todo, es mantener un historial de todo para siempre), así que si decide hacerlo, decida que quiere colabore con más personas pero no quiera que obtengan acceso completo a todos sus sistemas, entonces tendrá un poco de dolor de cabeza en sus manos.

Eso es a lo que realmente se reduce. Su repositorio de código es de alguna manera "público", incluso si solo se comparte con los colaboradores. El hecho de que quiera colaborar con alguien no significa que quiera darles acceso completo a su infraestructura (que es lo que sucede cuando coloca contraseñas / tokens en su repositorio de códigos). Es fácil pensar "sí, pero confío en las personas con las que estoy colaborando", pero esa es simplemente la forma incorrecta de ver el escenario, por varias razones:

1. En la práctica real, una gran parte de las filtraciones de datos comienzan con actores internos (colaboradores, empleados). Por un estudio , aproximadamente el 43% de las violaciones de datos comenzaron con un actor interno. La mitad de ellos fueron intencionales y la otra parte accidentales.
2. El último punto es importante y por qué no se trata solo de confianza. Aproximadamente el 20% de las violaciones de datos son accidentales y causadas por personas internas. Soy lo suficientemente inteligente como para saber que no soy lo suficientemente inteligente como para que todo esté bien todo el tiempo. ¿Qué sucede si convierto el repositorio en público para dejar espacio para una herramienta de integración divertida y olvido que tengo credenciales en ella? ¿Qué sucede si tengo un disco duro de copia de seguridad que olvidé cifrar y sale de mi oficina? ¿Qué sucede si una de mis contraseñas se filtra y alguien la usa para adivinar la contraseña de la cuenta a mi repositorio de git ( tos gentoo github repositorio tos )? Hay una serie de errores accidentales que I puede hacer que puedan exponer mi repositorio git, y si eso sucede y tengo credenciales allí y la persona que los encuentra sabe lo que están mirando, podría muy bien ser indagada. Eso suena como un montón de y pero la realidad es que así es como ocurren las brechas.
3. Incluso si confío en alguien, eso no significa que tenga que darles acceso completo a todo [Insertar una cita cursi sobre cómo corrompe el poder]. Una vez más, colocar las credenciales en un repositorio git significa que potencialmente estoy dando acceso completo a toda mi infraestructura a todos mis colaboradores. Siempre existe la posibilidad de que no conozcas a esa persona tan bien como crees, y podrían decidir hacer algo que no deberían. Incluso si conoces personalmente y confías en todos y cada uno de tus colaboradores con tu vida, eso no significa que no cometan algunos de los errores anteriores (o cualquiera de las infinitas opciones que no mencioné) para liberar accidentalmente tu código.

En resumen, la buena seguridad consiste en tener defensas en capas. La mayoría de los hacks ocurren porque los hackers encuentran debilidades en un área que les permite explotar las debilidades en otra área, lo que lleva a otra parte, lo que finalmente los lleva a la gran ganancia . Tener tantas salvaguardas de seguridad como convenga para su situación es lo que mantiene todo seguro. De esta manera, cuando un disco duro de copia de seguridad sale de su oficina y se da cuenta de que no estaba cifrado, no tiene que preguntar "¿Fue este un ataque dirigido y ahora tengo que cambiar cada credencial que tengo en todas partes porque? estaban todos en el repositorio de git en esa unidad de copia de seguridad? ". Nuevamente, dependiendo de su situación, es posible que esto no se aplique a usted, pero esperamos que esto ayude a explicar en qué escenarios podría ser importante.

Mantener secretos (contraseñas, certificados, claves) separados del código fuente hace posible administrar la fuente y los secretos de acuerdo con las diferentes políticas. Al igual que todos los ingenieros pueden leer el código fuente, solo las personas que son directamente responsables de los servidores de producción pueden acceder a los secretos.

Esto hace la vida más fácil para los desarrolladores porque no están sujetos a las estrictas políticas de seguridad que se necesitan para proteger los secretos. Las políticas de control de fuente se pueden hacer mucho más convenientes para ellos.

Esta convención, al igual que muchas otras "mejores prácticas" de seguridad, es una forma práctica de asegurarse de que las cosas no salgan mal debido a los malos hábitos o la rutina.

Si siempre recuerda que sus contraseñas confidenciales están en su sistema de control de versiones y si nunca le da acceso al repositorio a nadie que no deba tener la contraseña y si su repositorio se almacena de forma tan segura como requieren estos secretos y si su proceso de implementación también es seguro y está protegido contra personas no autorizadas y si puede estar seguro de que todas las copias de seguridad y copias de su repositorio son y ... probablemente pueda agregar un par de "if" más específicos para su contexto.

... entonces puede almacenar sus contraseñas en su sistema de control de versiones.

En la mayoría de las circunstancias, al menos uno de esos "si" no cumple con las condiciones o está fuera de su control.

Por ejemplo, en muchas configuraciones, sus desarrolladores no deberían tener acceso a la base de datos de producción. O el sistema de respaldo está subcontratado a otro departamento. O su proceso de construcción se subcontrata a la nube.

Es por eso que en general , no almacenar sus contraseñas en su sistema de control de versiones es una buena práctica que garantiza que no caiga en una de esas trampas porque no pensó en ellas . "no hay contraseñas en git" es más fácil de recordar que una larga lista de condiciones que debe cumplir para almacenar de forma segura las contraseñas bajo el control de versiones.

Otras respuestas son excelentes, pero considere también el problema de las copias de seguridad. Tiene mucha más flexibilidad en cuanto a dónde, cómo y durante cuánto tiempo almacena las copias de seguridad del repositorio de códigos si no contienen información confidencial sobre cómo acceder a sus cuentas de administrador o servidor.

Desde otro ángulo más centrado en la seguridad, solo la copia de seguridad de su código podría ser un objetivo interesante para los competidores poco éticos en su negocio. Dependiendo de su negocio, la mayoría de los competidores en un país de "ley de derecho" no lo tocarían de todos modos. Una copia de seguridad de código con contraseñas será un objetivo para cualquier organización delictiva que esté interesada en los datos de sus usuarios o que esté interesada en chantajear a su empresa.

El daño de una violación del repositorio de código sería mayor con las contraseñas por razones similares. ¿Prefiere que le roben y publiquen su código fuente, o que todos sus usuarios estén expuestos al robo de identidad, con una demanda potencial o incluso un caso penal en su contra por no haber protegido sus datos privados (piense en GDPR)?

"¿Por qué es realmente tan malo poner las llaves directamente en la puerta principal, cuando vivimos lejos de la civilización?"

Debido a que las personas que quieren hacer cosas malas, lo harán con facilidad y el costo de hacer cosas difíciles para ellos no es demasiado alto. Mantenga sus llaves con usted no al lado de la puerta. Sentido común.

Repo privado? ¿Cuántas personas tienen acceso para descargarlo? ¿Y cuántas personas están conectadas a sus computadoras? Y luego ... ¿Están todos libres de peligro?

También depende del sistema de control de código fuente.

Git tiene la actitud de que el sistema de control de código fuente debería darle un historial confiable del proyecto. Que no es una mala actitud tener. Pero existe el efecto de que si ingresó una contraseña en git, es muy difícil eliminarla de su repositorio.

Perforce tiene un comando "borrar" para ese propósito. Si ingresó una contraseña, o alguien registró un archivo de video sin comprimir de 8 gigabytes, o alguien ingresó un código de terceros que infringe los derechos de autor de alguien y nunca debería haber ingresado, o alguien que fue despedido registró muchas pornografías en Su último día en el trabajo, puedes "borrarlo". Se ha ido completamente del repositorio y de la historia.