El gestor de secretos suele entrar en el roadmap como una “victoria rápida”: se migran contraseñas y tokens fuera del repositorio y de las variables de entorno, se apunta a un Key Vault/Secrets Manager y se da por cerrado el capítulo. Ahí aparece la trampa: confundir almacenar secretos con operarlos de forma segura.
El síndrome del set-and-forget no suele ser mala fe; es presión por entregar, miedo a romper despliegues y falta de ownership claro entre plataforma, seguridad y equipos de producto. El resultado típico es un almacén central “bien” montado, pero con permisos amplios, rotación manual (o inexistente) y auditoría que nadie mira… hasta el incidente.
Qué salió mal: cuando el Key Vault se convierte en un punto único de fallo
El patrón se repite en empresas: se crea un único vault por cuenta/suscripción/proyecto, se suben decenas o cientos de secretos, y para evitar errores en arranques se conceden permisos genéricos. En AWS se ve como políticas con secretsmanager:GetSecretValue sobre *; en Azure, identidades con acceso amplio a secretos del vault; en GCP, cuentas de servicio con roles/secretmanager.secretAccessor en un scope demasiado grande. Funciona… hasta que un workload comprometido puede leer “todo”.
La consecuencia real no es teórica: una sola Lambda/Function/Cloud Run con RCE o credenciales filtradas deja de ser “un servicio caído” para convertirse en un extractor de credenciales a escala. El vault pasa a ser el acelerador del atacante: con permisos de lectura masiva, la enumeración y exfiltración es cuestión de minutos.
Además, muchos secretos se guardan tal cual (texto plano) asumiendo que “ya está cifrado”. Sí, el servicio cifra en reposo, pero eso no sustituye controles de acceso mínimos ni rotación. Si el IAM permite leerlo, el secreto sale en claro porque ese es el propósito del servicio. El error está en asumir que el cifrado del backend compensa el exceso de privilegios.
La confusión más cara: creer que el gestor de secretos “cifra el acceso” a nivel de red
He visto organizaciones dar por sentado que “como está en Key Vault, nadie fuera de la VNet/VPC lo toca”. En realidad, el control de red depende de cómo se consume el servicio: endpoints privados, restricciones de firewall, rutas y condiciones de acceso. Si el equipo no lo configura, el secreto seguirá siendo accesible desde cualquier lugar donde una identidad válida pueda autenticarse.
En el día a día, la fricción aparece cuando una aplicación falla al arrancar porque no puede listar o leer un secreto. La reacción típica es abrir permisos hasta que deje de fallar. El problema es que muchos SDKs y librerías intentan listar para descubrir nombres, o hacen llamadas de validación que llevan a conceder List y Get de forma indiscriminada. El “arreglo” es rápido, pero el blast radius crece silenciosamente.
- Permiso de listar como puerta a la enumeración
Cuando habilitas “listar todo”, facilitas que cualquier identidad con acceso pueda descubrir qué existe: nombres de secretos, convenciones (prod/dev), incluso pistas sobre terceros (por ejemplo, stripe_live, db_admin). En un incidente, esa enumeración ahorra tiempo y reduce el ruido del atacante.
- Acceso sin guardrails de red
Si no usas controles de red (según el proveedor y el servicio), el “perímetro” vuelve a ser IAM. En empresas con identidades distribuidas (muchas cuentas de servicio, muchas funciones), una credencial comprometida desde una máquina de desarrollo puede convertirse en acceso a secretos de producción si el scope está mal delimitado.
Rotación: lo que se promete en el diseño y lo que se opera en la realidad (AWS, Azure, GCP)
La rotación automática es el punto donde más se nota el set-and-forget. En presentaciones se asume “rotaremos cada 30/60/90 días”, pero en producción el secreto depende de un backend (RDS, un API de terceros, un usuario en un LDAP) y hay que orquestar el cambio sin tumbar servicios. Si nadie se responsabiliza de esa integración, la rotación queda como tarea manual… que se pospone.
En AWS, el mecanismo típico se apoya en una rotación basada en Lambda (un rotator) y un calendario de rotación en Secrets Manager. Eso funciona bien cuando el secreto corresponde a un sistema donde puedes crear credenciales nuevas, verificar, promover y revocar. Pero requiere código, permisos mínimos para modificar el backend y pruebas de rollback. Si el equipo “solo sube el secreto” y no implementa el rotator, no hay magia.
En Azure, Key Vault soporta políticas de rotación para secretos cuando existe un mecanismo de renovación integrado o automatizado, pero el valor operativo está en que la organización defina qué secretos son rotables, cómo se valida el nuevo valor y quién responde si la renovación falla. En GCP, Secret Manager puede programar rotación, pero de nuevo la rotación real depende de que haya un proceso que genere el nuevo secreto y actualice consumidores sin cortes. En los tres casos, el fallo corporativo típico es activar el “schedule” sin completar el circuito de actualización del backend y la aplicación.
- Señal temprana: rotación configurada pero sin evidencia de ejecuciones exitosas
Es habitual ver calendarios “bonitos” sin trazas de rotaciones efectivas, o con fallos recurrentes ignorados. Si no hay revisión periódica de ejecuciones y alertas, el calendario se convierte en un placebo.
- Señal temprana: secretos “eternos” para integraciones críticas
Tokens de terceros, credenciales de bases de datos o claves de servicio que no cambian en meses/años suelen ser el síntoma de que el proceso operativo no existe. Cuando ocurre un leak, no hay capacidad de respuesta rápida porque rotar “rompe cosas” y nadie lo ha ensayado.
Cómo hacerlo en la práctica: limitar lectura por etiquetas, y demostrarlo con auditoría
La mejora más rentable suele ser reducir el alcance sin re-arquitecturar: pasar de “cualquier workload puede leer cualquier secreto” a “cada workload solo lee los secretos de su aplicación/entorno”. La técnica más pragmática en empresa es basarlo en etiquetas/tags (y naming conventions consistentes) y aplicar guardrails en IAM/políticas para que la identidad de ejecución solo pueda acceder a secretos con las etiquetas esperadas.
Esto también evita el argumento clásico de “si no doy permisos amplios, algo fallará”: si defines un contrato simple (tags obligatorios por app y entorno) y lo automatizas en CI/CD, el sistema falla de forma explícita y corregible, no con permisos permanentes excesivos.
Ejemplo operativo (AWS IAM) con control por tags para una Lambda/Role que solo debe leer secretos de su aplicación y entorno:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ReadOnlyTaggedSecrets",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"secretsmanager:ResourceTag/app": "billing-api",
"secretsmanager:ResourceTag/env": "prod"
}
}
},
{
"Sid": "DenyListingToReduceEnumeration",
"Effect": "Deny",
"Action": [
"secretsmanager:ListSecrets"
],
"Resource": "*"
}
]
}En la práctica, este patrón obliga a etiquetar correctamente los secretos y evita que un servicio “descubra” secretos ajenos. Si una aplicación necesita List por comportamiento de librería, el remedio no debería ser abrir List global; suele ser fijar el nombre/ARN del secreto en configuración, o encapsular la resolución en una capa interna controlada.
Validación y auditoría (últimos 90 días): lo que cambia el juego es demostrar quién leyó qué. En AWS, revisa eventos de CloudTrail asociados a GetSecretValue y DescribeSecret y cruza por rol/cuenta de servicio; en Azure, revisa los logs de diagnóstico de Key Vault (operaciones de secretos) en Log Analytics; en GCP, filtra Cloud Audit Logs para accesos a Secret Manager. Si no puedes responder en una hora “qué identidades han accedido a este secreto en 90 días”, el vault está en modo set-and-forget.
Recomendaciones para entornos corporativos
La trampa del Key Vault no es tecnológica: es operativa. El gestor de secretos protege el almacenamiento, pero no compensa permisos masivos, ausencia de rotación y la creencia de que la red está “cifrada” o “cerrada” por defecto. Cuando el acceso se amplía para evitar fallos de arranque, el vault se convierte en el multiplicador de impacto ante cualquier compromiso de identidad.
Para salir del síndrome set-and-forget, el foco tiene que estar en tres evidencias: scopes de lectura mínimos (idealmente por etiquetas/proyecto/entorno), rotación que realmente se ejecuta y se monitoriza, y auditoría utilizable (consultable) de accesos de al menos 90 días. Si esas tres piezas están vivas, el gestor de secretos vuelve a ser un control de seguridad; si no, es solo un sitio más donde guardar texto plano con buena UX.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.