Utilizando AWS Config para detectar y mitigar las conformidades en bases RDS

Al adoptar la nube AWS el cliente posee un conjunto de características, funcionalidades y servicios de seguridad nativos que pueden ser implementados con el objetivo de aumentar su nivel de resiliencia y protección, utilizando como base el modelo de responsabilidad compartida.

Así que al utilizar el servicio RDS el cliente tiene a su disposición diversas características de seguridad, como por ejemplo los logs disponibles en el servicio RDS, que permiten la vigilancia de seguridad de su ambiente además de la posibilidad de configuración de reglas de firewall (Security Groups) y políticas de acceso de IAM para restringir los accesos y conexiones a sus bases de datos, atendiendo a sus necesidades y políticas de seguridad.

En el siguiente artículo se describe cómo supervisar y mitigar la configuración de reglas de firewall incorrectas en la creación de bases RDS, que pueden exponer indebidamente el listener del servicio de base de datos a redes no autorizadas. Aunque se requiere además el proceso de autenticación de usuarios, se recomienda que las bases de datos RDS no estén con reglas de Firewall abiertas, permitiendo accesos públicos, venidos de cualquier dirección IP.La propuesta que se describe a continuación utiliza productos y servicios nativos AWS para detectar cambios de configuración inadecuados en bases RDS que pueden traer algún riesgo de seguridad.

A fin de evaluar la existencia de bases de datos RDS con acceso permitido desde cualquier IP vamos a utilizar el servicio AWS Config con una regla preexistente. Se trata de la regla rds-instance-public-access-check, que permite auditar continuamente los recursos creados en la AWS, identificando si se trata de instancia RDS con el campo publiclyAccessible como true.

Utilizando el AWS Config + System Manager Automation es posible no sólo identificar, sino también realizar una acción automatizada para la remediación del problema. A continuación, se muestra cómo realizar la configuración de detección y remediación.

1. Iniciando con la detección de instancias RDS configuradas incorrectamente, ha afectado el acceso a cualquier dirección IP.

a. Abrir la consola AWS Config en https://console.thinkwithwp.com/config
b. Habilite el servicio AWS Config (si no está habilitado). Para habilitar el servicio, este tutorial puede ser utilizado.
c. En el panel de opciones, elija regras.
d.Haga clic en agregar regla.
e. Filtre la lista de reglas predefinidas por rds-instance-public-access-check y haga clic en la regla del mismo nombre.
f. Haga clic en guardar y la regla se ejecutará por primera vez comprobando todas sus instancias RDS.

2. Evaluando los recursos que están dentro del alcance de la regla.

a. En el panel de opciones, elija regras.
b. Busque la regla recién creada en la lista de reglas.
c. Seleccione la regla para ver los detalles
d. La lista de recursos en el ámbito de la regla se encuentra al final de la página.

La creación de la regla demostrada anteriormente puede ser automatizada por la cloudformation stack. Para más información consulte https://docs.thinkwithwp.com/config/latest/developerguide/rds-instance-public-access-check.html.

Con estos dos pasos ya ganamos visibilidad y control continuo de bases de datos que pueden ser accedidas por cualquier dirección IP.

3. Ahora vamos a editar la regla recién creada y asociarla a una acción en el ambiente para evitar que esta base quede expuesta a cualquier IP, implementando la mitigación automática y corrigiendo posibles errores de configuración.

a. Haga clic en Editar.
b. En acción de corrección, seleccione AWS -StopRdsInstance, la ejecución de acciones es realizada por AWS Systems Manager Automation, hay diferentes tipos de acciones preconfiguradas. Para obtener más información sobre esta acción en concreto, visite https://docs.thinkwithwp.com/es_es/systems-manager/latest/userguide/automation-aws-stoprdsinstance.html.
c. Seleccione InstanceId en Parâmetro de ID do recurso, esto hará que la función del administrador de sistemas reciba el identificador de instancia RDS como parámetro.
d. Haga clic en Salvar.

Con ello, cada reevaluación las instancias de RDS que se encuentren en inconformidad serán detenidas. Es posible también crear acciones más personalizadas utilizando la acción de corrección  AWS-PublishSNSNotification, donde cada cambio detectado será publicado en un tópico SNS, pudiendo así tener acciones de correcciones personalizadas.

Auditar y evaluar quién hizo los cambios de configuración

Las acciones ejecutadas en los servicios AWS se registran en el Cloud Trail, siendo así que podemos consultar a los agentes y cuáles fueron los cambios realizados en la configuración de bases RDS específicas utilizando el AWS Athena.

1. El primer paso es evaluar si los registros de la nube se están exportando al S3, permitiendo así consultas a más largo plazo, con tiempos mayores que 90 días. Compruebe en el portal CloudTrail si ya existe una pista creada donde está seleccionada la grabación de read / write events, de lo contrario, siga el paso siguiente:

a. Abrir la consola AWS CloudTrail en https://console.thinkwithwp.com/cloudtrail/home
b. En el panel izquierdo, seleccione trails.
c. Haga clic en Create Trail.
d. Elija un nombre para su pista.
e. Seleccione All en Read/Write events en la sesión

f. Seleccione el bucket S3 de destino de los registros.

g. Haga clic en Create.

2. Ahora que sus registros se están grabando en S3, vamos a crear manualmente una tabla en Athena para poder ejecutar consultas en los registros.

a. Abrir la consola AWS CloudTrail en https://console.thinkwithwp.com/cloudtrail/home
b. En el panel izquierdo, seleccione Event History.
c. Siga el enlace Run advanced queries in Amazon Athena.
d. En el pop-up, seleccione el bucket que contiene sus trails y haga clic en create table.

Pronto, sus datos estarán catalogados en Athena y listos para ser consultados vía consulta, pero existen optimizaciones que se pueden hacer para mejorar el rendimiento y el costo de la herramienta. Vea este post del blog con posibles optimizaciones.

En la consola de Athena, cree una consulta con el filtro eventsource = ‘rds.amazonaws.com’, la lista con todos los eventos emitidos por RDS está disponible en inglés en https://docs.thinkwithwp.com/AmazonRDS/latest/APIReference/API_Operations.html , se pueden filtrar en el campo eventname.

SELECT *
FROM «default».»cloudtrail_logs»
WHERE eventsource = ‘rds.amazonaws.com’
AND eventname IN (<LIST OF EVENTS>)

Con ello, podemos hacer auditorías de todos los eventos del RDS; y en casos de eventos de seguridad es posible evaluar los cambios realizados en cada evento por el campo requestparameters, así como el usuario responsable en userName. Usted todavía puede modificar la consulta y explorar aún más los datos.

Para la evaluación de los costos relacionados con la solución, vea AWS Config pricing, Athena pricing y CloudTrail pricing.

Sobre el Autor

Tiago Canassa Bernardinelli

Tiago es arquitecto de soluciones en AWS, actúa con el segmento enterprise, fue ingeniero del equipo de servicios del Amazon EC2. Con más de 10 años de experiencia en desarrollo de sistemas, Tiago ayudó a empresas de diversos segmentos a definir, planificar e implementar sus estrategias de desarrollo y operaciones.