Activa este cifrado en S3 o un ransomware puede secuestrar tu empresa

Hace poco, un día cualquiera de trabajo, me entra un mensaje por WhatsApp de un colega con el que yo había trabajado meses atrás en una…

Hace poco, un día cualquiera de trabajo, me entra un mensaje por WhatsApp de un colega con el que yo había trabajado meses atrás en una auditoría de AWS. El mensaje decía algo como:

“Bro, parece que nos cifraron unos archivos en S3… ¿tú te acuerdas de la auditoría que hicimos?”

Claro que me acordaba. En esa auditoría habíamos revisado toda su cuenta de AWS: IAM, CloudTrail, S3, backups, roles, todo. Entre las cosas que encontramos, había varios buckets con información sensible donde el cifrado estaba “medio a medias”: sin políticas estrictas y con demasiada libertad sobre cómo se podían subir los objetos.

En ese momento mi recomendación fue clara: activar cifrado con SSE-KMS usando una CMK del cliente y, muy importante, bloquear por política el uso de SSE-C en esos buckets.

¿Por qué? Porque si tú dejas que cualquiera suba objetos usando SSE-C, le estás abriendo la puerta a un escenario perfecto de ransomware: alguien con credenciales válidas puede subir archivos cifrados con una clave que solo él controla, y aunque tú sigas siendo dueño del bucket… ya no puedes leer tus propios datos.

El plan estaba definido, documentado, explicado. Pero pasó lo que pasa en muchas empresas: prioridades del día a día, poco personal en infraestructura, tickets urgentes, proyectos nuevos y esa política de bloqueo a SSE-C se quedó pendiente “para después”.

Meses después, ese “después” llegó en forma de incidente.

Cuando me llamó, empezamos a revisar CloudTrail, accesos a S3, patrones raros de lectura y escritura. Vimos algo muy claro:  alguien estaba usando credenciales válidas para leer objetos y subir nuevas versiones cifradas, rompiendo el acceso normal a la información. Justo el escenario de ransomware que habíamos hablado en la auditoría.

Lo más doloroso no fue solo el ataque en sí, sino la sensación de: “esto lo habíamos visto venir y teníamos el control definido, pero no se aplicó por falta de tiempo y de gente.”

A partir de ahí decidí escribir este artículo, no para quedar como el héroe de la historia, sino para dejar bien claro algo que muchas veces se subestima: en S3 no basta con “tener cifrado”, hay que elegir bien qué cifrado permites y cuál debes bloquear.

Los 3 cifrados de S3 que DEBES controlar: SSE-S3, SSE-KMS y SSE-C

Cuando trabajas con S3, lo importante no es solo “tener cifrado”, sino qué tipo de cifrado estás permitiendo. En esta historia nos vamos a concentrar en tres métodos que son los que más suelen aparecer en escenarios reales:

1. SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys)

Este es el cifrado administrado por S3. Tú lo habilitas en el bucket y AWS se encarga de manejar las claves internamente.

En la práctica significa:

• Tus objetos quedan cifrados en reposo.
• No tienes que manejar claves directamente.
• Es una buena base mínima para muchos casos de uso donde los datos no son extremadamente sensibles.

El problema es que, a nivel de control, sigues dependiendo de claves que maneja AWS y no tienes el mismo nivel de gobierno que con KMS.

2. SSE-KMS (Server-Side Encryption with AWS KMS Keys)

Aquí ya hablamos de un enfoque más serio. Las claves viven en AWS KMS, y puedes usar claves administradas por el cliente (CMK).

Lo bueno de SSE-KMS con CMK es que te da:

• Control detallado de quién puede usar la clave (IAM + políticas de KMS).
• Registros de uso de la clave (CloudTrail + KMS).
• Rotación, separación de funciones y alineación con requisitos de cumplimiento más estrictos.

Por eso, en la auditoría que hicimos, mi recomendación fue clara: para los buckets críticos, usar SSE-KMS con una CMK del cliente como estándar.

3. SSE-C (Server-Side Encryption with Customer-Provided Keys)

Este es el cifrado que, usado sin cuidado, te puede abrir la puerta a un escenario de ransomware bastante feo.

Con SSE-C:

• El cliente envía la clave de cifrado en cada operación (PUT/GET).
• AWS no almacena esa clave.
• Si no tienes la clave, no lees el objeto. Punto.

Suena súper bien desde la perspectiva de control, pero si lo miras desde el ángulo de seguridad ofensiva, pasa algo interesante:

Si en tu bucket permites que se suban objetos usando SSE-C, un atacante con credenciales válidas puede:

1. Subir nuevas versiones de tus archivos cifrados con claves que solo él conoce.
2. Tú sigues siendo dueño del bucket, pero ya no puedes leer esos objetos porque nunca tuviste esas claves.
3. Básicamente te secuestran la información dentro de tu propia cuenta de AWS.

Por eso, en esa auditoría, mi recomendación fue:

• Usar SSE-KMS como cifrado estándar en los buckets críticos.
• Bloquear explícitamente SSE-C mediante política, de forma que ninguna app ni usuario pudiera subir objetos usando cifrado con claves externas a la organización.

Cierro aquí la historia porque entrar en más detalle implicaría tocar información sensible del cliente, y ese nunca debe ser el precio de un buen caso de estudio. Lo realmente importante es la lección: definir un estándar claro (por ejemplo, SSE-KMS con CMK del cliente) y bloquear SSE-C por política cuando no es necesario puede marcar la diferencia entre un incidente controlado y un ransomware cifrando datos dentro de tu propia cuenta de AWS.

Si quieres llevar esto a la práctica, preparé un laboratorio en YouTube donde simulo un escenario muy parecido al que cuento aquí y reviso paso a paso las configuraciones de cifrado en S3. La idea es que puedas usarlo como guía para fortalecer tu entorno, no que te aprendas solo la teoría. Te dejo el enlace al final del artículo por si te sirve para revisar tus propios buckets con más criterio.

Ver video