Cifrado AWS KMS: tu propia clave en 5 minutos
Si guardás datos sensibles en S3, RDS o DynamoDB y todavía no configuraste tus propias claves, estás dejando que AWS decida cómo se cifra todo. El cifrado AWS KMS con una customer managed key (CMK) te devuelve ese control: rotación, políticas de acceso por usuario y, lo más importante para una auditoría, un registro completo en CloudTrail de quién usó qué clave y cuándo. Crear una CMK toma menos de cinco minutos en la consola.
AWS Key Management Service (KMS) es el servicio de gestión de claves criptográficas de Amazon Web Services. Sirve para crear, almacenar y controlar las claves que cifran tus datos en reposo en servicios como S3, EBS, RDS, DynamoDB, SQS y las variables de entorno de Lambda. Una customer managed key es una clave que vos creás y administrás dentro de tu cuenta, con control total sobre permisos, rotación y auditoría.
En 30 segundos
- Qué es: AWS KMS gestiona las claves que cifran tus datos en reposo en S3, EBS, RDS, DynamoDB, SQS y Lambda.
- Tres tipos de clave: AWS owned (gratis, sin control), AWS managed (gratis, en tu cuenta), customer managed o CMK (costo mensual + por uso, control total).
- Límite técnico: KMS cifra directo solo hasta 4 KB. Para datos más grandes se utiliza cifrado envolvente con data keys.
- Ventaja clave de la CMK: cada operación queda registrada en CloudTrail. Con SSE-S3 no tenés ese rastro.
- Rotación automática: anual, conserva el material anterior para descifrar datos viejos.
¿Por qué te conviene controlar tus propias claves en AWS?
Acá viene el punto que mucha gente pasa por alto. AWS cifra tus datos por defecto en casi todos los servicios de almacenamiento. Eso está bien para cumplir el requisito mínimo, pero esas claves las maneja AWS y vos no podés verlas, ni rotarlas a tu gusto, ni saber quién las usó.
El cifrado AWS KMS con una clave propia cambia ese escenario. Ponele que tu equipo de seguridad necesita demostrar, en una auditoría de cumplimiento, exactamente qué usuario descifró un objeto de S3 el martes a las 3 de la tarde. Con una customer managed key, ese evento está en CloudTrail. Con una clave administrada por AWS sin más, ese nivel de detalle no lo tenés. Para más detalles técnicos, mirá nuestra guía sobre cómo asegurar tu pipeline CI/CD.
Los servicios que se apoyan en KMS son muchos: S3, EBS, RDS, DynamoDB, las variables de entorno de Lambda, SQS y varios más. Aprender a manejar una sola CMK te sirve para todos.
¿Cuál es la diferencia entre cifrado en reposo y cifrado en tránsito?
Son dos cosas distintas y complementarias. No elegís una u otra: necesitás las dos.
- Cifrado en reposo: protege los datos guardados en disco. Objetos de S3, volúmenes EBS, tablas de DynamoDB, bases de datos RDS. Acá es donde entra KMS.
- Cifrado en tránsito: protege los datos mientras viajan entre servicios o entre el cliente y el servidor. HTTPS, TLS, VPN. En S3 podés forzarlo con una bucket policy que rechace conexiones no cifradas.
El error típico es cifrar en reposo y olvidarse del tránsito (o al revés). Si tu bucket está cifrado pero permitís HTTP, alguien puede interceptar los datos en el camino, aunque en disco estén bien protegidos.
Tipos de claves KMS: ¿administradas por AWS o por vos?
Hay tres categorías y la diferencia de fondo es cuánto control tenés y cuánto pagás. Mirá la tabla antes de decidir. Cubrimos ese tema en detalle en nuestra guía sobre integrando secretos en GitHub Actions.
| Tipo de clave | Control | Rotación | Costo | Mejor caso de uso |
|---|---|---|---|---|
| AWS owned keys | Ninguno (no las ves) | La maneja AWS | Gratis | Cifrado por defecto sin requisitos de auditoría |
| AWS managed keys | Limitado, en tu cuenta | Automática cada año | Gratis (cargos por uso) | Integración rápida con servicios AWS |
| Customer managed keys (CMK) | Total: políticas, rotación, cross-account | Vos la configurás | Mensual + por uso | Cumplimiento, auditoría, control fino de permisos |
La customer managed key es la única que te da rotación a tu criterio, políticas de acceso granulares y acceso entre cuentas. Es la que vas a querer si trabajás con datos regulados o si necesitás separar quién administra la clave de quién la usa.
¿Cómo funciona envelope encryption en AWS KMS?
KMS tiene un límite técnico que sorprende a mucha gente: solo puede cifrar directo hasta 4 KB de datos. Y la mayoría de los archivos pesan bastante más que eso. ¿Cómo lo resuelve? Con envelope encryption.
El proceso es así, paso a paso, según la documentación oficial de AWS KMS:
- KMS genera una data key: te devuelve una copia en texto plano y una copia cifrada.
- Vos cifrás tus datos localmente con la data key en texto plano.
- Guardás la data key cifrada junto a los datos ya cifrados.
- Descartás la data key en texto plano de la memoria.
- Para descifrar: KMS descifra la data key, y con ella vos descifrás los datos.
La gracia es que tus datos nunca salen de tu entorno sin cifrar, y la clave maestra nunca toca esos datos grandes. El AWS Encryption SDK hace todo este baile automático, así que no tenés que programar cada paso a mano.
SSE-S3, SSE-KMS y SSE-C: ¿cuál usar para cifrar en S3?
Cuando cifrás del lado del servidor en S3, tenés tres opciones. La elección depende de cuánto control querés y cuánta responsabilidad estás dispuesto a cargar. Lo explicamos a fondo en nuestra guía de infraestructura multi-región.
| Método | Gestor de claves | Auditoría | Costo | Control |
|---|---|---|---|---|
| SSE-S3 | AWS maneja todo | No | Sin costo extra | Mínimo, lo más simple |
| SSE-KMS | Vos controlás la clave KMS | Sí, vía CloudTrail | Cargos KMS por uso | Alto, con políticas |
| SSE-C | Vos proveés la clave en cada request | Limitada | Sin costo de KMS | Máximo, AWS no guarda la clave |
¿Cuál conviene en la práctica? Para la mayoría de los equipos que necesitan trazabilidad, SSE-KMS es el punto justo. SSE-S3 zafa si solo querés cumplir el mínimo sin auditoría. SSE-C es para casos donde no querés que AWS almacene la clave bajo ninguna circunstancia, pero te obliga a gestionarla vos en cada operación (y si la perdés, perdés los datos).
Pasos para crear e implementar una customer managed key
Crear la clave es la parte fácil. Configurar bien los permisos es donde se juega la seguridad.
- Creá la clave: desde la consola de AWS KMS o con el CLI (
aws kms create-key). Elegí cifrado simétrico para la mayoría de los casos de uso de almacenamiento. - Definí la política de clave: aplicá privilegio mínimo. Especificá quién puede administrar la clave y quién puede usarla para cifrar o descifrar. Nunca uses
kms:*abierto a todos. - Creá un alias: un nombre tipo
alias/produccion-rdsen vez del ID largo de la clave. Hace el código más legible y te permite cambiar la clave detrás sin tocar la aplicación. - Usalo en operaciones: referenciá el alias cuando cifres tus volúmenes EBS, buckets o tablas.
El consejo que más se ignora: separá roles. La persona que administra la clave (puede borrarla o cambiar su política) no debería ser la misma que la usa día a día. Esa separación es lo que evita que un acceso comprometido termine en desastre.
¿Cómo configurar la rotación automática de claves?
Rotar claves reduce el riesgo: si una clave se ve comprometida, cuanto más vieja sea, más datos expuso. KMS te da dos caminos. Ya lo cubrimos antes en ejecutando procesos sin APIs externas.
- Rotación automática anual: KMS genera material criptográfico nuevo cada año y conserva el anterior. Eso es clave, porque los datos cifrados con la versión vieja se siguen descifrando sin problema. La habilitás con un solo toggle.
- Rotación manual con alias: creás una clave nueva y apuntás el alias a ella. Cero downtime, porque tu aplicación referencia el alias, no la clave directa. Útil cuando necesitás control sobre el momento exacto.
Para verificar si la rotación está activa, revisás la propiedad de la clave en la consola o con el CLI. Si recién arrancás, dejá la automática habilitada y olvidate.
¿Cómo auditar el uso de tus claves con CloudTrail?
Esta es la diferencia que justifica pagar por una CMK. Cada vez que alguien cifra o descifra usando tu clave, KMS escribe un evento en CloudTrail: quién, cuándo, desde qué servicio, con qué resultado. Con SSE-S3 ese rastro no existe.
Las mejores prácticas de seguridad que recomienda la guía prescriptiva de AWS son concretas:
- Privilegio mínimo siempre: en las políticas de clave, otorgá solo los permisos necesarios. Nada de
kms:*. - Separá administración de uso: roles distintos para administrar y para usar la clave.
- Monitoreá CloudTrail: configurá alertas sobre eventos sospechosos, como intentos de descifrado fallidos repetidos.
- Restringí por servicio: usá condiciones en la política para que la clave solo la pueda usar el servicio que corresponde.
Si tu infraestructura corre en servidores o VPS propios y querés un punto de partida más simple para alojamiento web en la región, donweb.com ofrece hosting y dominios en Argentina, aunque KMS como tal es un servicio nativo de AWS.
Errores comunes al implementar cifrado AWS KMS
- Usar
kms:*en la política: abre la clave a operaciones que no necesitás. Especificá las acciones exactas (kms:Encrypt,kms:Decrypt,kms:GenerateDataKey). - Olvidar el cifrado en tránsito: cifrás el bucket pero dejás HTTP habilitado. Forzá HTTPS con una bucket policy.
- No separar roles: el mismo usuario administra y usa la clave. Si esa credencial se filtra, el atacante puede borrar la clave y los datos quedan irrecuperables.
- Asumir que SSE-S3 da auditoría: no la da. Si necesitás trazabilidad, tenés que ir a SSE-KMS sí o sí.
Preguntas Frecuentes
¿Cómo creo una customer managed key en AWS KMS?
Desde la consola de AWS KMS hacés clic en “Create key”, elegís cifrado simétrico, definís la política de permisos y le asignás un alias. Con el CLI usás aws kms create-key seguido de aws kms create-alias. El proceso completo toma menos de cinco minutos.
¿Cuál es la diferencia entre SSE-KMS y SSE-S3?
SSE-S3 deja que AWS maneje las claves sin que vos tengas control ni auditoría, y no cuesta extra. SSE-KMS te da una clave que vos controlás, con registro de cada operación en CloudTrail y políticas de acceso, a cambio de cargos por uso. Si necesitás trazabilidad, usá SSE-KMS.
¿Qué es envelope encryption y por qué la necesito?
Envelope encryption es el método que KMS usa para cifrar datos mayores a 4 KB, su límite de cifrado directo. Genera una data key para cifrar tus datos localmente y solo guarda la versión cifrada de esa data key. La necesitás porque la mayoría de los archivos supera ese límite de 4 KB.
¿Cuánto cuesta usar AWS KMS?
Las AWS owned keys y AWS managed keys no tienen costo mensual, aunque generan cargos por uso. Las customer managed keys tienen un costo mensual por clave más cargos por cada operación criptográfica. Conviene revisar la calculadora de precios oficial de AWS para tu región y volumen estimado.
¿Cómo audito el acceso a mis claves KMS?
Con CloudTrail, que registra cada operación de cifrado y descifrado hecha con tus customer managed keys: usuario, fecha, servicio de origen y resultado. Configurás alertas sobre eventos sospechosos y revisás los logs para tus auditorías de cumplimiento. Esta trazabilidad no está disponible con SSE-S3.
Conclusión
El cifrado AWS KMS no es un lujo para empresas gigantes. Es la diferencia entre cumplir el mínimo y poder demostrar, dato por dato, quién accedió a tu información. Si manejás datos regulados o necesitás pasar una auditoría, una customer managed key con rotación automática, políticas de privilegio mínimo y monitoreo de CloudTrail es el camino. Empezá por crear una sola CMK, asignarle un alias claro y separar quién la administra de quién la usa. Ese hábito te ahorra dolores de cabeza el día que alguien pregunte qué pasó con tus datos.
![[FREE] I built a deeper WordPress security auditing plugin for my own sites, then released it as 100% GPL - ilustracion](https://donweb.news/wp-content/uploads/2026/04/auditoria-seguridad-wordpress-guia-2026-hero-768x429.jpg)
