En muchas empresas el cifrado “ya está” porque el servicio indica encrypted at rest y el equipo marca el control como cumplido. El problema no es el cifrado en sí, sino la interpretación: una clave gestionada por defecto (la típica “aws/s3”, “Microsoft-managed”, “Google-managed”) rara vez añade una barrera real si un atacante logra permisos sobre el recurso.
El mito aparece cuando se asume que “usar KMS” equivale a “controlar quién puede descifrar”. En la práctica, con claves gestionadas por el proveedor, el descifrado suele estar implícitamente permitido a través del propio servicio siempre que tengas acceso al recurso. Si tu modelo de permisos falla (y en incidentes reales suele fallar), el cifrado no frena el acceso no autorizado.
Qué salió mal: el cifrado por defecto no separa acceso al dato de acceso a la clave
El patrón se repite: un bucket, una base de datos o un volumen aparecen como cifrados y el equipo se queda tranquilo. Luego ocurre un compromiso de credenciales (API key filtrada, token de CI/CD expuesto, sesión robada) y el atacante no “rompe” el cifrado: simplemente lee el objeto o consulta la tabla porque el servicio descifra por él.
En entornos corporativos con IAM complejo, esa diferencia entre “puedo leer el recurso” y “puedo usar la clave” es crítica. Con claves gestionadas por defecto, el proveedor suele operar el descifrado como parte del flujo normal del servicio. Resultado: la clave no actúa como guardrail adicional, y el impacto del incidente se mueve de “datos inaccesibles” a “exfiltración silenciosa”.
Consecuencia real en empresa: auditorías internas donde el control se marcó como OK por “cifrado en reposo”, pero el incidente demuestra que no había una segunda capa de autorización ligada al uso de la clave. Lo que faltaba no era criptografía; era diseño de políticas.
El abuso más común: “cualquiera con acceso al recurso puede descifrar”
El escenario típico de abuso no es sofisticado. Un rol con permisos amplios a S3/Blob/Storage (por ejemplo, un rol de soporte con lectura temporal, o un pipeline con permisos heredados) termina siendo suficiente para acceder a datos sensibles. El cifrado por defecto no añade fricción porque el servicio desencripta al vuelo para quien cumpla las condiciones de acceso al recurso.
En términos de investigación forense, esto se ve como accesos legítimos desde identidades comprometidas, no como fallos criptográficos. Si además hay permisos de enumeración, el atacante puede localizar contenedores con datos críticos y extraerlos sin tocar la configuración de claves.
- Lectura directa sobre el recurso: cuando la política del bucket/contendor o el IAM permite GetObject/Read, el servicio hace el resto. En incidentes reales, el control que falla primero es el de permisos, no el de cifrado.
- Permisos transversales por “comodidad”: roles compartidos entre apps o equipos (o perfiles de “admin temporal”) convierten el cifrado por defecto en un check de compliance sin valor operativo. El daño aparece cuando esos permisos se reutilizan fuera del contexto esperado.
- Falsa sensación de separación de funciones: se cree que seguridad “posee KMS” y plataforma “posee el recurso”, pero si la clave no impone restricciones, esa separación es cosmética. El atacante no necesita tocar KMS para descifrar si el servicio lo hace por él.
El problema no es usar servicios gestionados, sino confiar en que una clave gestionada por defecto actuará como control de acceso. Para datos críticos, necesitas que el uso de la clave esté condicionado y sea verificable.
Cómo hacerlo en la práctica: CMK y políticas que obligan a pasar por el servicio y por roles concretos
La corrección práctica en AWS suele empezar por migrar a Customer Managed Keys (CMK) y diseñar la Key Policy como un control de seguridad real, no como un “allow admin”. El objetivo: aunque alguien consiga permisos sobre el recurso, no pueda usar la clave fuera del contexto esperado o desde identidades no autorizadas.
Un patrón útil es exigir que el uso de la clave ocurra vía el servicio y sólo para un conjunto de roles/aplicaciones. En AWS esto se aterriza con condiciones como kms:ViaService y, cuando aplica, restricciones de contexto (cuenta, región, encryption context). Ejemplo de declaración (fragmento orientativo) para limitar el uso a S3 en una región concreta y a un rol de aplicación:
{
"Sid": "AllowUseFromS3OnlyForAppRole",
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::123456789012:role/app-prod"},
"Action": ["kms:Encrypt","kms:Decrypt","kms:GenerateDataKey"],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:ViaService": "s3.eu-west-1.amazonaws.com",
"kms:CallerAccount": "123456789012"
}
}
}
Lo importante no es copiar/pegar: es el criterio. Si el atacante roba credenciales de otro rol con acceso a S3, pero ese rol no puede usar la CMK bajo esas condiciones, la lectura fallará aunque el bucket esté accesible. Ahí el cifrado empieza a ser un control efectivo.
- Crear una CMK por dominio de datos: no una por servicio “porque sí”, sino por conjunto de datos con similar criticidad y ciclo de vida. Esto permite revocar o rotar con impacto controlado y aplicar políticas específicas por aplicación.
- Configurar la Key Policy como autoridad primaria: evita delegar todo en IAM si no hay una key policy restrictiva. En AWS, la key policy manda; si es permisiva, el cifrado vuelve a ser decorativo.
- Validar con pruebas negativas: además de probar que la app funciona, prueba que un rol “cercano” (por ejemplo, un rol de lectura general o un usuario de data tooling) recibe AccessDenied al intentar leer objetos cifrados con esa CMK. En empresa, estas pruebas detectan el 80% de los errores de modelado.
Operativamente, añade verificación continua: revisa en AWS CloudTrail eventos de KMS (Decrypt/GenerateDataKey) y correlaciónalos con el rol esperado. Si ves desencriptados desde identidades o servicios no previstos, tu política no está cumpliendo su función.
Multi-cloud sin autoengaños: AWS KMS, Azure Key Vault y GCP Cloud KMS no se comportan igual
El concepto se repite en los tres grandes: claves gestionadas por el proveedor simplifican operación, pero tienden a no separar de forma fuerte “acceso al recurso” de “autorización explícita de uso de clave” para tu caso concreto. El detalle cambia por plataforma y servicio, y ahí se cometen errores al extrapolar un modelo mental de un cloud a otro.
En AWS, la separación se trabaja con CMK + Key Policy + condiciones como kms:ViaService. En Azure, el uso de claves propias se suele materializar con Customer-Managed Keys en Azure Key Vault o Managed HSM según el servicio (por ejemplo, cifrado de almacenamiento, o TDE/Always Encrypted en bases de datos, según el caso). En GCP, el equivalente es Cloud KMS (y, cuando necesitas aislamiento más fuerte, Cloud HSM).
La diferencia práctica en empresa es cómo se gobiernan identidades y permisos: en Azure suele aparecer el anti-patrón de “muchos contribuidores tienen acceso a la cuenta de almacenamiento y, por extensión, a datos cifrados con claves gestionadas”, porque el descifrado es parte del servicio. En GCP, un error común es asumir que “CMEK = control total” sin revisar quién tiene permisos para use la clave y desde qué servicios/proyectos.
Cuándo considerar HSM dedicado: cuando hay requisitos de aislamiento criptográfico, cumplimiento regulatorio estricto o riesgo de abuso interno que exige controles adicionales (aprobaciones, separación más fuerte, evidencias). No es un comodín: añade coste y complejidad operativa, y si el IAM del recurso sigue siendo la puerta abierta, no te salva.
Recomendaciones para entornos corporativos
El cifrado en la nube no falla; falla la expectativa. Las claves gestionadas por defecto son adecuadas para reducir exposición ante pérdida física o capas inferiores, pero no están pensadas para detener a un actor que ya obtuvo permisos sobre el recurso.
Para datos críticos, el control real llega cuando usas claves gestionadas por el cliente y conviertes la política de clave en un guardrail: limitar qué roles pueden usarla, exigir que el uso ocurra vía el servicio correcto (por ejemplo, kms:ViaService en AWS), y validar con pruebas negativas que identidades “cercanas” no pueden descifrar.
En multi-cloud, evita trasladar suposiciones entre proveedores. Revisa siempre el punto exacto donde se autoriza el uso de la clave (KMS/Key Vault/Cloud KMS) y comprueba que el acceso al recurso no implique descifrado automático para identidades que no deberían ver el dato.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.