En Amazon S3 puedes subir objetos (archivos), elegir una clase de almacenamiento, definir quién tiene acceso al archivo, configurar el borrado automático y mucho más. La facturación es por hora y puedes eliminar cualquier objeto en cualquier momento para dejar de pagar por su almacenamiento.
Una de las funcionalidades que lanzó AWS es Object Lock: un mecanismo que impide que los objetos se eliminen o se sobrescriban. Está pensado para proteger datos destinados a una retención a largo plazo —ya sea por cumplimiento normativo o por archivado— frente a borrados accidentales o malintencionados.
Al crear un bucket puedes elegir un Retention Mode de Object Lock, que determina cómo restringirá AWS la eliminación de objetos:
- Governance mode: los objetos quedan protegidos contra escritura, pero los usuarios con permisos especiales pueden anular o quitar el bloqueo.
- Compliance mode: los objetos son totalmente inmutables durante el período de retención definido. Nadie, ni siquiera el usuario root de la cuenta o el soporte de AWS, puede eliminarlos durante ese tiempo.
En ambas opciones se puede definir un período de retención de entre 1 día y 100 años, que se cuenta de forma individual para cada objeto desde el momento en que se sube a S3.
Una vez que Object Lock está habilitado en un bucket, puedes definir el modo de bloqueo y el período de retención de cada objeto al subirlo. Si no especificas estos valores durante la carga, se aplicará la configuración predeterminada.
Si más adelante cambias la configuración predeterminada, esto solo afectará a los objetos nuevos; los existentes conservarán la configuración de bloqueo con la que se subieron.
Centrémonos en el Compliance mode:
Si lo activas, una vez subido el objeto, ningún IAM Role ni usuario —ni siquiera el usuario root— podrá eliminarlo hasta que termine el período de retención. Ni el soporte de AWS podrá ayudarte a borrarlo antes de tiempo.
Te aparecerá el siguiente error:
"Access Denied because object protected by object lock."
¿Por qué te conviene bloquearlo?
Para reducir el daño en caso de que se vea comprometida una cuenta de AWS.
Te explico: hay tres patrones habituales que siguen los atacantes cuando logran acceso a una cuenta de AWS:
- Rescate y destrucción: cifran los respaldos, exigen un rescate y eliminan recursos para sembrar caos.
- Minería de criptomonedas: levantan instancias de cómputo con GPU costosas en todas las regiones disponibles para minar criptomonedas.
- Drenaje financiero: aprovisionan recursos caros como instancias metal y volúmenes EBS enormes, o compran nodos reservados de Redshift para acumular cargos.
Una jugada particularmente dañina que podría usar un atacante es crear un bucket de S3 con Object Lock a largo plazo en Compliance mode y subir archivos gigantes desde instancias EC2 zombi, o incluso contenido cuya posesión sea ilegal.
Más adelante, durante una revisión de costos o una detección de anomalías, podrías descubrir un bucket con cantidades enormes de datos imposibles de eliminar, con un costo de miles o decenas de miles de dólares al mes, sin forma de borrarlos.
Entonces, ¿cómo se elimina un bucket con objetos protegidos por Compliance mode?
No se puede.
La única vía es cerrar toda la cuenta de AWS con todos sus recursos, algo que resulta un verdadero dolor de cabeza, sobre todo en entornos de producción.
Tendrás que migrar todos tus workloads a una cuenta de AWS nueva, un proceso que puede llevar semanas o incluso meses, similar a una migración completa de entorno.
¿Cómo se bloquea?
Con Resource Control Policies (RCP), una funcionalidad de AWS Organizations que te permite aplicar políticas en las cuentas de tu organización (salvo la cuenta de gestión) sobre recursos como los buckets de S3.
Puedes crear una resource policy que deniegue cualquier intento de habilitar Object Lock (lamentablemente, no se puede limitar únicamente al Compliance Mode). Si alguien intenta aplicarlo, recibirá un error de Access Denied.
Tip: también puedes permitir que solo ciertos usuarios (por ejemplo, el equipo de seguridad) puedan saltarse la restricción, mientras bloqueas al resto. Así mantienes el control sin exponer la cuenta a riesgos innecesarios.
Aquí tienes un ejemplo de RCP que bloquea por completo el uso del Compliance mode, tanto para buckets existentes como nuevos:
Apliqué la política, creé un bucket nuevo y, al intentar habilitar el Compliance mode, recibí el siguiente error:
Reflexiones finales:
Si te tomas en serio minimizar el daño financiero a largo plazo derivado de configuraciones erróneas o accesos no autorizados, te recomiendo aplicar esta política sin pensarlo dos veces.
Por cierto, el Compliance mode no es exclusivo de S3; también existe en:
- EBS Snapshots: respaldos de volúmenes (discos) de EC2.
- AWS Backup Vault: el servicio AWS Backup.
Conviene plantearse bloquearlos también, según tu postura de riesgo.
Descubre más recursos útiles visitándonos en doit.com/services. ¡Tu próximo paso hacia el éxito te está esperando!