Hola comunidad,
¿Alguna vez te has despertado un día con un email o reporte del securityHub diciendo que hay x cantidad de buckets de S3 mal configurados que necesitan atención inmediata? En caso de que te permitan realizar remediaciones automáticas, este post es para ti. En este post les compartiré un sistema de remediación automática que combina AWS Config con Systems Manager (SSM) Automation.
En este post estaré cubriendo:
- Qué es la remediación automática y por qué es importante
- Componentes principales y arquictura de la solución
- Demo con capturas reales del funcionamiento (y link al repo)
- Próximos pasos y conclusiones
¿Qué es la remediación automática?
La remediación automática es un proceso que detecta configuraciones que no cumplen con los lineamientos establecidos y corrige automáticamente, sin intervención manual.
En lugar de solo alertar sobre problemas de configuración, el sistema los identifica y aplica las correcciones necesarias de forma inmediata. Esto representa un cambio de enfoque: de reactivo (detectar y alertar) a proactivo (detectar y corregir).
Arquitectura de la solución
La solución implementa tres componentes principales de AWS que trabajan en conjunto:
AWS Config - el detective
Monitorea continuamente la configuración de los recursos y ejecuta evaluaciones de cumplimiento. Utiliza una regla administrada por AWS o personalizada respaldada por Lambda.
AWS Lambda - el analista
Ejecuta la lógica de evaluación personalizada. La función analiza los recursos de interés, verifica su configuración de seguridad, y reporta el estado de cumplimiento (COMPLIANT/NON_COMPLIANT) a AWS Config.
AWS Systems Manager Automation - el reparador
Ejecuta las acciones de remediación cuando Config identifica recursos no conformes. Utiliza documentos de automatización que contienen los pasos específicos, como playbooks, para aplicar las configuraciones de seguridad requeridas.
¿Cómo funciona el flujo completo?
El proceso de remediación automática con una regla de Config períodica para evaluar y remediar buckets que no tiene configurado el bloqueo de acceso público sigue estos pasos:
Detección: AWS Config ejecuta la regla personalizada cada cierta cantidad de cantidad horas, dependiendo la parametrización que definamos.
Evaluación: La función Lambda recibe la lista de buckets y evalúa cada uno, verificando si tiene configurado el bloqueo de acceso público.
Reporte: Lambda reporta el estado de cumplimiento de cada recurso a AWS Config, marcándolos como COMPLIANT o NON_COMPLIANT.
Activación: Config identifica los recursos no conformes y activa el proceso de remediación automática. Esto puede tomar un par de segundos.
Remediación: Systems Manager Automation ejecuta el documento que aplica las configuraciones de bloqueo de acceso público al bucket.
Verificación: Config vuelve a evaluar el recurso, acorde a su periodicidad definida, para confirmar que ahora cumple con la política establecida y marcarlo como OMPLIANT.
Capturas del Demo
Nada mejor que ver el sistema en acción. Te voy a mostrar exactamente lo que pasa cuando alguien (digamos, un desarrollador con prisa y en ese momento no había un control prevenentivo) crea un bucket sin las configuraciones de seguridad:
Escenario: Creamos un bucket S3 sin configuración de bloqueo de acceso público.
Estado Inicial - Bucket No Conforme
AWS Config detecta esta configuración insegura de bucket y marca el recurso como NON_COMPLIANT.
Estado Intermedio - Bucket Corregido
AWS Config activa automáticamente la remediación configurada. En la consola se puede observar el progreso de la ejecución del documento de Systems Manager en tiempo real.
Después de la remediación automática, el bucket tiene correctamente configurado el bloqueo de acceso público. El recurso cambió de NON_COMPLIANT a COMPLIANT sin intervención manual.
Estado Final - Bucket marcado como Conforme
En la próxima evaluación de la regla, el recurso que ya cumple con el lineamiento, es marcado como en cumplimiento. Este estado debe preservarse de allí en adelante siempre y cuando tengamos un control preventivo que evite que este tipo de configuraciones vuelvan a aplicarse o que alguien lo ajuste por consola.
Nota importante - Gastos relacionados:
Para la implementación de esta solución, AWS Config debe estar habilitado en su cuenta. Para optimizar los costos, puede utilizar reglas periódicas que se activan cada cierto número de horas. De esta manera, no es necesario mantener el AWS Config Recorder activado continuamente, lo que puede generar gastos significativos.
Si la necesidad es mantener un cumplimiento continuo, se requiere que el Recorder esté encendido. Este grabará cada cambio en los recursos, permitiendo configurar reglas de Config para que evalúen cada recurso que reciba modificaciones.
Una estrategia para la optimización de costos es ajustar el alcance del Recorder, excluyendo tipos de recursos que no son críticos. Otra opción es modificar la periodicidad del Recorder a una evaluación diaria, lo cual captura una "instantánea" de la configuración. Sin embargo, esta opción no es aplicable a todos los tipos de recursos.
A continuación, se detallan los costos asociados en los que podría incurrir al mantener el Recorder activado.
¿Dónde puedo ver el código completo?
He subido la implementación completa a GitHub, incluyendo:
- Plantilla de CloudFormation con toda la infraestructura
Repositorio: https://github.com/pangoro24/aws-public-buckets-auto-remediation
Próximos pasos
Esta implementación es solo el comienzo. Puedes extender el concepto para:
- Otros recursos de AWS (EC2, RDS, ELB, etc.)
- Múltiples políticas de seguridad
- Integración con herramientas de notificación (sns,ses)
- Métricas y dashboards personalizados
Conclusiones
La implementación de remediación automática representa un cambio significativo en la gestión de seguridad en la nube, pasando de un enfoque reactivo a uno proactivo.
La combinación de AWS Config, Lambda y Systems Manager crea un sistema robusto que no solo detecta configuraciones inseguras, sino que las corrige automáticamente, reduciendo el tiempo de exposición a riesgos y liberando recursos del equipo para tareas más estratégicas.
Si estás cansado de pasar tus días arreglando configuraciones de seguridad, dale una oportunidad a esta solución.
¿Ya tienes algo similar implementado? ¿Te gustaría que hable de otros casos de uso o que profundice en algún aspecto específico? Déjamelo saber en los comentarios - siempre me gusta escuchar experiencias de otros desarrolladores que han pasado por lo mismo.
Gracias por leer.
Top comments (0)