Los secretos como las claves de cifrado y las credenciales no deben registrarse en el control de origen por algunas razones. La primera es, obviamente, que las claves de cifrado y las credenciales siempre deben estar basadas en la necesidad de saber, y el control de la fuente no es una forma confiable de proteger la información de la divulgación. La otra razón por la que no desearía tales secretos en su control de fuente es típicamente porque los secretos son generalmente (pero no siempre) específicos de un determinado atributo del entorno en el que se ejecutará su aplicación. firma necesaria para una autorización de servicio web, el punto final específico de ese servicio web puede estar ejecutándose en un entorno de control de calidad que requiere una firma de control de calidad).
La forma correcta de tratar un medio ambiente (o secreto global) es tratarlo como lo haría con cualquier otro atributo de configuración ambiental, con controles de seguridad adicionales como medida. Un módulo de código bien diseñado, independiente y versionable debe ser idéntico en todos los entornos de modo que el entorno en el que se implementan informe a la aplicación sobre sus atributos (por ejemplo, detalles de conexión de base de datos, credenciales, puntos finales de servicios web, rutas de archivos, etc.) Ahora Los detalles de configuración cruciales para su aplicación se externalizan y se convierten en parámetros de configuración de su entorno.
Ahora para abordar algunos de sus argumentos:
En general, ¿no estamos simplemente moviendo el problema?
No existe la seguridad perfecta, sin embargo, "trasladar" el problema a un área donde se puedan colocar medidas y controles adicionales mejorará la dificultad y reducirá la probabilidad de revelación accidental o maliciosa de secretos. Una buena regla general a seguir cuando se diseña un sistema donde se deben proteger los datos confidenciales es poner siempre los controles en dos. Lo que quiero decir con esto es asegurar que para que ocurra una divulgación accidental o maliciosa de información confidencial o incidente de seguridad, entonces tendría que haber una falla o en dos o más controles.
Un buen ejemplo de esto podría ser almacenar un archivo encriptado en un servidor. También tengo una clave de descifrado secreta que debo mantener confidencial en otro archivo.
- Almacene la clave y el archivo cifrado en el mismo servidor (0 controles, cualquier persona con acceso al servidor puede adquirir trivialmente la información confidencial)
- Realice los pasos anteriores y proteja el acceso a los archivos a ambos archivos para que solo el usuario de tiempo de ejecución de la aplicación del sistema operativo pueda leerlo (1 Control, comprometiendo la contraseña del usuario raíz o el usuario de tiempo de ejecución de la aplicación permitirá que un atacante obtenga información confidencial)
- Almacene la clave en el almacén de claves externo, adquiera la clave con múltiples medidas de seguridad, como la lista blanca de direcciones IP, la autenticación de certificados y otras medidas para la aplicación que puede acceder al archivo cifrado en su sistema de archivos. (Múltiples controles, múltiples fallas en los controles de seguridad deben ocurrir para que los datos confidenciales se vean comprometidos)
Una vez más, no existe la seguridad perfecta, pero el objetivo de tener múltiples controles garantiza que se produzcan múltiples fallas para que se produzca la divulgación.
Me parece que los productos como Azure KeyVault no son mejores y son mucho más complicados,
Complicado sí, sin sentido es completamente subjetivo. No podemos tener una discusión sobre la inutilidad de la seguridad adicional sin tener en cuenta de manera realista cuán grave sería que se expongan los datos confidenciales. Si uno pudiera usar los datos confidenciales para enviar transferencias electrónicas ilícitas fuera de su institución financiera, entonces algo así como una bóveda de claves es lo más alejado de lo inútil que sería.
que guardar tus secretos en un archivo de configuración separado y asegurarte de que esté en tu .gitignore o equivalente.
Hasta que alguien accidentalmente lo compruebe en el control de origen, ahora el secreto está incrustado en el historial de control de origen para siempre.
Por supuesto, las personas probablemente se enviarán inseguramente unos a otros ...
La seguridad no es solo un problema técnico, también es un problema de personas. Eso estaría fuera de tema, sin embargo, creo que en este punto estás tratando de convencerte de no hacer lo necesario.
¿Hay alguna forma de administrar secretos que no solo mueva el problema? Creo que esta pregunta tiene una única respuesta claramente definida. Por analogía, si tuviera que preguntar cómo HTTPS no solo mueve el problema, la respuesta sería que las claves CA se distribuyen con su sistema operativo, y confiamos en ellas porque confiamos en el método de distribución del sistema operativo.
La seguridad no siempre hace que los problemas desaparezcan, la mayor parte del tiempo pone controles a su alrededor. Su analogía es sucinta porque, de hecho, eso es exactamente lo que hace la criptografía de clave pública-privada. Estamos "trasladando el problema" a la entidad emisora de certificados al depositar una confianza absoluta y total en nuestra entidad emisora de certificados para garantizar la identidad de la entidad propietaria del certificado público. Básicamente, tendría que ocurrir una cadena catastrófica de fallas (por ejemplo, perder la confianza en la CA) para conducir a un problema de seguridad.
Al igual que con muchas cosas, la seguridad es una línea que debe trazarse en función de criterios subjetivos, la naturaleza de los datos, las consecuencias de la divulgación, el apetito por el riesgo, el presupuesto, etc.
