¿Quién borró mi archivo? Automatiza la notificación de eliminación en Amazon S3 en tiempo real

Detectar quién borra archivos en S3 puede ser clave para la seguridad; aquí resumo las mejores formas de lograrlo.

Introducción

Hace un tiempo me pregunté: ¿Cuál sería la mejor manera dentro de AWS para poder detectar si un archivo fue borrado de un bucket importante? Me puse a investigar y encontré muchas opciones… pero también varios problemas y limitaciones. En este post quiero guiar a quienes tienen esa misma duda para que puedan elegir la mejor solución y evitarse dolores de cabeza.

Estas son tres de las principales opciones que investigué (aunque existen muchas otras alternativas según la necesidad):

1: Notificaciones de eventos S3 (Event Notifications)

Permiten recibir alertas en tiempo real cuando ocurre una eliminación en el bucket. Se puede configurar para que dispare una función Lambda, un SNS o una cola SQS al instante del evento. Es la opción más flexible y automática.

2: Server Access Logging en S3

Puedes habilitar el registro detallado de todas las operaciones sobre el bucket, incluyendo los borrados. Los logs se almacenan como archivos en otro bucket S3. Su principal desventaja es el costo y la dificultad para analizar grandes volúmenes de logs.

3: AWS Config

AWS Config permite monitorear y auditar cambios en la configuración de recursos AWS, incluyendo buckets S3. Si bien no está pensado específicamente para notificar borrados en tiempo real, ayuda a mantener un historial y estado de los objetos y puede complementar una estrategia de monitoreo.

Cuando comencé a probar la opción 3 (AWS Config), me di cuenta de que era la más complicada y menos efectiva para este caso.

Las razones:

• AWS Config está orientado a monitorear configuraciones y cambios en los recursos, no eventos específicos como el borrado de archivos en tiempo real.
• Requiere reglas y evaluaciones personalizadas, lo que agrega complejidad.
• Puede resultar costoso y, sobre todo, no genera notificaciones instantáneas de cada borrado, sino más bien auditoría y cumplimiento a nivel de configuración.

Después probé con la opción 2 (Server Access Logging en S3). Al principio sonaba bien porque te permite registrar todo lo que sucede en el bucket, incluyendo los borrados. Pero… ¿realmente es la solución ideal? No lo es.

• Es una opción muy costosa en cuanto a almacenamiento, ya que genera grandes volúmenes de logs.
• El análisis es manual y nada en tiempo real; tienes que buscar los logs en otro bucket S3 y luego analizarlos para encontrar quién borró qué archivo.
• Es tedioso y poco práctico para quienes buscan respuestas rápidas y automáticas.

Y fue ahí, buscando algo más eficiente, que me topé con la primera opción: Las notificaciones de eventos de S3.

Esta sí es la solución ideal para detectar y actuar de inmediato cuando alguien borra un archivo. En el resto del post, te voy a explicar cómo ponerla en práctica paso a paso, usando Lambda para recibir el evento y notificarte al instante.

Debemos de identificar cuáles son los buckets S3 realmente críticos o importantes para nuestra organización. No se trata de monitorear todos los buckets indiscriminadamente, ya que eso podría generar un exceso de alertas y ruido innecesario. La clave está en centrarse en aquellos buckets que almacenan información sensible, regulada o de alto valor para el negocio.

Ten en cuenta que esta estrategia tiene más sentido en buckets donde la eliminación de archivos no es una operación frecuente, ya que en buckets de uso intensivo o temporales, la cantidad de notificaciones podría volverse inmanejable.

Partiendo de esta premisa, accedemos a la consola de AWS, nos dirigimos al servicio de S3 y localizamos el bucket o los buckets que queremos proteger. Estos serán el foco principal de nuestro sistema de alertas, asegurando que cualquier intento de borrado sea monitoreado y gestionado de forma adecuada.

Luego de identificar el bucket crítico, el siguiente paso es muy sencillo: Ingresamos a la consola de AWS, seleccionamos nuestro bucket y vamos a la sección Propiedades.

Dentro de las propiedades, buscamos el apartado llamado Notificaciones de evento. Aquí es donde configuraremos la alerta que se activará cada vez que se elimine un archivo.

Seleccionamos el nombre del evento y, si queremos, podemos filtrar por extensión para enfocarnos solo en ciertos tipos de archivos. Luego, marcamos la opción de borrado permanente. Avanzamos y elegimos el destino del evento; en este caso, seleccionamos Lambda. (Si tienes el versionado activado en tu bucket, considera también la opción ‘delete marker created’, aunque ese tema lo profundizaré en otro post.)

¿Y por qué Lambda? Porque el evento viene como un log, y así la función Lambda puede extraer solo lo que nos interesa:

• Usuario (quién borró el archivo)
• IP
• Nombre del bucket
• Archivo borrado

Si dejamos la notificación de S3 conectada directamente a SNS, el mensaje que recibiríamos por correo sería el evento completo en formato JSON, incluyendo muchos detalles técnicos que pueden resultar poco útiles o confusos. Por eso, agregamos una función Lambda entre S3 y SNS: la Lambda procesa el evento, extrae solo la información relevante y envía un mensaje mucho más claro y fácil de entender al correo.

Esta arquitectura mantiene todo bajo control y te permite actuar de inmediato ante un borrado inesperado. Lo mejor de este enfoque es que es fácil de implementar, no requiere configuraciones complicadas y es totalmente administrado por AWS, por lo que el mantenimiento y los costos se mantienen bajos. Además, el mensaje que recibes es claro, con la información clave para tomar decisiones rápidas sin necesidad de revisar logs extensos o archivos JSON poco amigables.

En resumen, monitorear el borrado de archivos críticos en S3 puede ser sencillo y efectivo si usamos bien las herramientas de AWS. No es la única manera, pero es una de las más prácticas, económicas y rápidas de implementar cuando la detección inmediata es prioridad.