Hoy vamos a hablar sobre un caso real de implementación de sistemas de monitorización y alerta en AWS que, independientemente de si somos una pequeña o gran empresa, puede servirnos para aumentar el nivel de seguridad de nuestra infraestructura y detectar roturas del control de acceso en AWS.
Hace una semana hablábamos en UnaAlDía sobre cómo podemos limitar el acceso a nuestros recursos en AWS con unas nuevas claves condicionales que hacen más simple controlar el acceso a los recursos existentes en nuestra cuenta.
Utilizar AWS Organizations ya nos ofrece por sí solo la capacidad de «administrar y controlar de manera centralizada» nuestro entorno en AWS a medida que éste crece y escala, pero, además, podemos combinar este servicio con AWS SSO para administrar los controles de acceso también de manera centralizada en todas nuestras cuentas.
En este caso, el reto presente era diseñar una solución eficiente en relación a los costes; teniendo en cuenta esto, se diseñaron dos opciones.
La primera opción era utilizar un enfoque descentralizado, desplegando CloudFormation StackSet para crear, actualizar o eliminar stacks en múltiples cuentas y regiones con una sola operación. No obstante, en este artículo nos centraremos en la segunda opción, la cual fue finalmente implementada.
Usar una ruta de organización en la cuenta de Administración de Organizaciones
Esta opción hace uso de una ruta de organización centralizada en la cuenta de Administración de Organizaciones para extraer información de auditoría.
Una vez creada la ruta organizacional, el procedimiento a seguir es configurar CloudTrail para enviar eventos de registro (logs) a CloudWatch Logs y, tras ello, dichos eventos serán enviados a través de funciones Lambda a la herramienta de comunicación utilizada por la empresa (Slack, en este caso concreto) utilizando webhooks.
Para aquellas organizaciones que, al igual que en este caso concreto, utilicen Slack como herramienta de comunicación de su equipo, puede resultar de ayuda el módulo público de terraform disponible en Github para llevar a cabo el proceso de integración de Lambda Slack.
Fuente de la imagen: AWS Blog
Teniendo en cuenta que el requisito principal de este escenario es detectar roturas del control de acceso en cualquiera de los mecanismos soportados por AWS, incluyendo CLI y el portal de acceso de usuario, el equipo que llevó a cabo la implementación destaca todos los eventos que se deben considerar y que son iniciados en cada mecanismo de acceso:
- Eventos de acceso en el portal de usuario o en la consola de AWS: autenticación, listar aplicaciones (ListApplications), listar perfiles de las aplicaciones (ListApplicationProfiles), y federación (este evento contiene el rol al cual el usuario se está intentando federar).
- Eventos de acceso a CLI: crear un token (CreateToken), listar cuentas (ListAccounts), listar roles de cuentas (ListAccountRoles), obtener las credenciales de un rol (GetRoleCredentials) (este último evento contiene el rol al cual el usuario se está intentando federar).
Como se puede observar en la imagen anterior, en esta implementación se envían los registros de CloudTrail a CloudWatch Logs, para luego iniciar una función Lambda a través de un filtro de suscripción que detecta los nombres de eventos que queramos en el contenido de los registros.
Más información
Monitoring and alerting break-glass access in an AWS Organization
Deja una respuesta