Gestión segura de secretos y variables de entorno

Los secretos codificados directamente —claves de API, contraseñas de bases de datos, claves privadas TLS y tokens OAuth insertados directamente en el código fuente— son una de las vulnerabilidades de seguridad más comunes y evitables. Los secretos presentes en el código fuente quedan expuestos en el historial del control de versiones (incluso después de eliminarlos), son visibles para todos los desarrolladores con acceso al repositorio y se filtran con frecuencia cuando los repositorios se hacen públicos por accidente. Herramientas como GitGuardian y truffleHog buscan continuamente secretos filtrados en plataformas como GitHub.

Las variables de entorno eliminan los secretos del código fuente al inyectarlos en tiempo de ejecución mediante el sistema operativo anfitrión o el orquestador de contenedores. La aplicación lee os.environ['DB_PASSWORD'] en lugar de un valor codificado directamente. Esto es mejor que codificar secretos directamente, pero las variables de entorno presentan puntos débiles: aparecen en las listas de procesos, se heredan en los procesos secundarios, a menudo terminan en volcados de memoria y registros de depuración, y requieren una rotación manual. Son adecuadas para el desarrollo, pero por sí solas no bastan para gestionar los secretos en producción.

Los gestores de secretos son sistemas diseñados específicamente para almacenar, rotar y auditar el acceso a secretos. Entre las principales soluciones se incluyen HashiCorp Vault (de código abierto y empresarial), AWS Secrets Manager, Azure Key Vault y Google Cloud Secret Manager. Las aplicaciones se autentican en el gestor de secretos durante el tiempo de ejecución, recuperan el secreto y lo utilizan; los secretos no se almacenan nunca en disco ni en variables de entorno. Todos los accesos quedan registrados, lo que permite auditar quién accedió a cada secreto y cuándo.

Una ventaja clave de los gestores de secretos frente a las variables de entorno es la rotación automática. AWS Secrets Manager puede rotar automáticamente las contraseñas de bases de datos RDS según una programación (por ejemplo, cada 30 días) sin necesidad de volver a desplegar la aplicación. El gestor de secretos actualiza la contraseña en la base de datos y el secreto almacenado simultáneamente. Las aplicaciones que recuperan los secretos en cada conexión reciben automáticamente la nueva credencial. Esto elimina la práctica habitual de utilizar contraseñas «permanentes» para cuentas de servicio que nunca se rotan.

La primera línea de defensa contra los secretos confirmados en el repositorio es un archivo .gitignore correctamente mantenido que excluya todos los archivos que puedan contener secretos. Sin embargo, .gitignore solo evita confirmaciones futuras: los secretos que ya se hayan confirmado permanecen en el historial de git. Si se confirman secretos por accidente, deben considerarse comprometidos de inmediato: rote el secreto y, opcionalmente, use herramientas como git filter-repo para reescribir el historial (es necesario para cumplir con las normativas, pero no es suficiente por sí solo, ya que es posible que el secreto ya se haya extraído).

Los archivos de infraestructura como código (IaC), como los de Terraform, CloudFormation y los manifiestos de Kubernetes, suelen contener secretos: cadenas de conexión a bases de datos, claves de API en declaraciones de variables de entorno y certificados TLS. Estos archivos suelen confirmarse en el control de versiones, lo que crea un riesgo de exposición de secretos. Entre las soluciones se incluyen los secretos dinámicos de Vault (Vault genera una credencial de corta duración específica para cada ejecución de Terraform), los Secrets de Kubernetes (almacenados en etcd, deben cifrarse en reposo) y external-secrets-operator, que sincroniza secretos desde un administrador de secretos a Kubernetes durante el tiempo de ejecución.

Cada aplicación o servicio debe acceder únicamente a los secretos que necesita específicamente: el principio de mínimo privilegio aplicado a los secretos. Una aplicación web necesita la contraseña de la base de datos, pero no la clave privada de la CA. Un trabajo de generación de informes necesita credenciales de solo lectura para la base de datos, no acceso de escritura. Los administradores de secretos hacen cumplir este principio mediante políticas de acceso que especifican qué identidades (roles de IAM, cuentas de servicio, AppRoles) pueden leer qué secretos, y registran todos los accesos con fines de auditoría.

Los secretos dinámicos se generan bajo demanda para un solicitante específico y caducan automáticamente. Vault puede generar una credencial temporal de base de datos válida durante 1 hora y asociada al servicio específico que la solicitó. Una vez caducada, la base de datos revoca automáticamente la credencial. Este enfoque elimina las credenciales estáticas de larga duración que podrían sustraerse; incluso si un atacante captura una credencial dinámica, esta caduca rápidamente y queda vinculada a la identidad solicitante en los registros de auditoría.

Las canalizaciones de CI/CD suelen necesitar secretos, como credenciales de proveedores cloud para la implementación, tokens de registros de Docker y claves de firma. Nunca almacene secretos en scripts ni archivos de configuración de la canalización. En su lugar, use el almacén de secretos integrado en la plataforma de canalización (GitHub Actions Secrets, GitLab CI Variables, Jenkins Credentials Store) o recupere los secretos de un almacén central durante el tiempo de ejecución mediante una identidad de máquina. Marque las variables secretas como ocultas en los registros para evitar su exposición accidental en la salida de compilación.

Los administradores de secretos proporcionan registros de auditoría exhaustivos de cada evento de acceso a secretos: qué identidad accedió a qué secreto, desde qué IP, a qué hora y si el acceso se realizó correctamente o fue denegado. Estos registros son fundamentales para el cumplimiento normativo (SOC 2, PCI-DSS) y la respuesta a incidentes. Cuando se sospecha que una credencial está comprometida, los registros de auditoría revelan qué sistemas accedieron a ella y cuándo, lo que permite identificar rápidamente los sistemas potencialmente afectados y tomar decisiones de contención.

Los hooks de preconfirmación son scripts que se ejecutan automáticamente antes de finalizar cada confirmación de git y permiten detectar secretos antes de que entren en el historial del control de versiones. Herramientas como detect-secrets (Yelp), GitLeaks y git-secrets (AWS) se integran como hooks de preconfirmación y analizan los archivos preparados en busca de patrones que coincidan con claves de API, cadenas de conexión, claves privadas y tokens JWT. Si se detecta un secreto, se rechaza la confirmación y se solicita al desarrollador que elimine la credencial. El framework pre-commit facilita añadir y compartir configuraciones de hooks entre equipos.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que: los secretos codificados directamente en el código fuente deben eliminarse y sustituirse por administradores de secretos como Vault o AWS Secrets Manager; la rotación automática elimina las credenciales de larga duración que los atacantes podrían aprovechar incluso después de la intrusión inicial; y los secretos dinámicos y las políticas de acceso basadas en el mínimo privilegio minimizan el valor de cualquier secreto individual que quede expuesto. A continuación, exploraremos la seguridad de las dependencias y el análisis de composición de software.