¿Cómo gestionas los secretos de forma segura en la nube?
Respuesta breve
Almacena los secretos en un servicio gestionado dedicado (Secrets Manager, Parameter Store, Vault), cifrados con una clave de KMS, y concede el acceso mediante roles IAM para que las cargas de trabajo los recuperen en tiempo de ejecución con credenciales de corta duración. Nunca incrustes secretos en el código, las imágenes de contenedor o archivos .env versionados. Añade rotación automática, políticas de clave acotadas y registro de auditoría para que cada recuperación sea rastreable.
La gestión de secretos es donde las buenas intenciones se topan con la realidad: los desarrolladores quieren que la aplicación "simplemente tenga" la contraseña de la base de datos, y los caminos fáciles — un .env en el repositorio, una constante en el código, una variable de entorno incrustada en una imagen — filtran todos. La entrevista quiere el patrón seguro y el razonamiento.
El patrón correcto
- Una bóveda de secretos dedicada. Usa Secrets Manager, SSM Parameter Store (SecureString) o HashiCorp Vault. Mantienen los secretos fuera del control de versiones y te dan versionado, rotación y registros de acceso.
- Cifrado vía KMS. La bóveda cifra los secretos con una clave de KMS usando cifrado por sobre — KMS guarda la clave maestra y nunca la expone; una clave de datos por secreto hace el grueso del cifrado. Las políticas de clave controlan quién puede siquiera descifrar.
- Acceso vía roles IAM, no claves estáticas. La carga de trabajo asume un rol y recupera el secreto en tiempo de ejecución. Combinado con credenciales de rol de corta duración, no hay ningún secreto de larga duración que robar en reposo dentro de la aplicación.
- Rotación y auditoría. Habilita la rotación automática para que una credencial filtrada tenga una vida útil corta, y registra cada llamada a
GetSecretValuepara que las recuperaciones sean atribuibles.
Por qué fallan los caminos fáciles
Un .env versionado vive para siempre en el historial de git. Un secreto incrustado en una capa de imagen Docker permanece en esa capa aunque un RUN rm posterior elimine el archivo — cualquiera que descargue la imagen puede extraerlo. Las simples variables de entorno aparecen en los volcados de memoria (crash dumps), los procesos hijo y el registro.
Qué buscan los entrevistadores
Mencionar una bóveda gestionada, explicar el cifrado por sobre de KMS y las políticas de clave, insistir en el acceso por rol IAM más la rotación, y saber por qué las capas de imagen y el historial de git hacen inútil "eliminarlo más tarde".
Posibles preguntas de seguimiento
- ¿Qué es el cifrado por sobre y cómo usa KMS una clave de datos?
- ¿Cómo rotas una credencial de base de datos sin tiempo de inactividad?
- ¿Por qué un secreto en una capa de imagen Docker sigue expuesto incluso después de eliminarlo en una capa posterior?