Utilizando o AWS Config para detectar e mitigar não conformidades em bases RDS

Ao adotar a nuvem AWS o cliente possui um conjunto de recursos, funcionalidades e serviços de segurança nativos que podem ser implementados com o objetivo de aumentar o seu nível de resiliência e proteção, utilizando como base o modelo de responsabilidade compartilhada.

Dessa forma ao utilizar o serviço RDS o cliente tem a sua disposição diversos recursos de segurança, como por exemplo os logs disponíveis no serviço RDS, que permitem a monitoração de segurança de seu ambiente além da possibilidade de configuração de regras de firewall (Security Groups) e políticas de acesso de IAM para restringir os acessos e conexões a suas bases de dados, atendendo as suas necessidades e políticas de segurança.

O artigo a seguir descreve como monitorar e mitigar a configuração de regras de firewall incorretas na criação de bases RDS , que possam expor indevidamente o listener do serviço de Banco de Dados para redes não autorizadas. Ainda que adicionalmente exista o processo de autenticação de usuários, é altamente recomendado que bases de dados RDS não estejam com regras de Firewall abertas, permitindo acessos públicos, vindos de qualquer endereço IP.

A proposta descrita a seguir utiliza produtos e serviços nativos AWS para detectar alterações de configurações indevidas em bases RDS que possam trazer algum risco de segurança.

Afim de avaliar a existência de bases de dados RDS com acesso permitido a partir de qualquer IP vamos utilizar o serviço AWS Config com uma regra pré-existente. Trata-se da regra rds-instance-public-access-check , que permite auditar continuamente os recursos criados na AWS, identificando se trata-se de instância RDS com o campo publiclyAccessible como true.

Utilizando o AWS Config + System Manager Automation é possível não só identificar, mas também realizar uma ação automatizada para remediação do problema. Veja abaixo como realizar a configuração de detecção e remediação.

1. Iniciando com a detecção de instâncias RDS configuradas incorretamente, pertmitido acesso a qualquer endereço IP.

a. Abrir o console AWS Config em https://console.thinkwithwp.com/config
b. Habilite o serviço AWS Config (caso ele não esteja habilitado). Para habilitar o serviço, esse tutorial pode ser utilizado.
c. No painel de opções, escolha regras.
d. Clique em adicionar regra.
e. Filtre a lista de regras pré definidas por rds-instance-public-access-check e clique na regra de mesmo nome.
f. Clique em salvar e a regra será executada pela primeira vez verificando todas as suas instâncias RDS.

2. Avaliando os recursos que estão dentro do escopo da regra.

a. No painel de opções, escolha regras.
b. Localize a regra recém criada na lista de regras.
c. Selecione a regra para ver os detalhes.
d. A lista de recursos no escopo da regra está localizada no final da página.

A criação da regra demonstrada acima pode ser automatizada pelo cloudformation stack, para mais informações consulte https://docs.thinkwithwp.com/config/latest/developerguide/rds-instance-public-access-check.html.

Com esses dois passos já ganhamos visibilidade e controle contínuo de bases de dados que podem ser acessadas por qualquer endereço IP.

3. Agora vamos editar a regra recém criada e associá-la a uma ação no ambiente para evitar que esta base fique exposta a qualquer IP, implementando a mitigação automática e corrigindo possíveis erros de configuração.

a. Clique em Editar.
b. Em Ação de correção, selecione AWS-StopRdsInstance, a execução de ação é feita pelo AWS Systems Manager Automation, existem diferentes tipos de ação pré-configuradas, para saber mais sobre esta ação em específico, acesse https://docs.thinkwithwp.com/pt_br/systems-manager/latest/userguide/automation-aws-stoprdsinstance.html.
c. Selecione InstanceId em Parâmetro de ID do recurso, isso fará com que a função do systems Manager receba o ID da instância RDS como parâmetro.
d. Clique em Salvar.

Com isso, a cada re-avaliação as instâncias de RDS que estiverem em não conformidade serão paradas, é possível também criar ações mais customizadas utilizando a ação de correção AWS-PublishSNSNotification, onde cada mudança detectada será postada em um tópico SNS podendo assim ter ações de correções personalizadas.

Auditando e avaliando quem fez as alterações das configurações

Ações executadas nos serviços AWS são registradas no Cloud Trail, sendo assim podemos consultar os agentes e quais foram as alterações executadas nas configurações de bases RDS específicas utilizando o AWS Athena.

1. O primeiro passo é avaliar se os logs do cloud trail estão sendo exportados para o S3, permitindo assim consultas a mais longo prazo, com prazos maiores que 90 dias. Verifique no portal CloudTrail se já existe uma trilha criada onde esteja selecionada a gravação de read/write events, caso contrário, siga o passo a seguir:

a. Abrir o console AWS CloudTrail em https://console.thinkwithwp.com/cloudtrail/home
b. No painel esquerdo, selecione trails.
c. Clique em Create Trail.
d. Escolha um nome para sua trilha.
e. Selecione All em Read/Write events na sessão

f. Escolha o bucket S3 de destino dos log.

g. Clique em Create.

2. Agora que seus logs estão sendo gravados no S3, vamos criar manualmente uma tabela no Athena para poder executar consultas nos logs.

a. Abrir o console AWS CloudTrail em https://console.thinkwithwp.com/cloudtrail/home
b. No painel esquerdo, selecione Event History.
c. Siga o link Run advanced queries in Amazon Athena.
d. No pop-up, selecione o bucket que contém seus trails e clique em create table.

Pronto, seus dados estão catalogados no Athena e prontos para serem consultados via query, porém existem otimizações que podem ser feitas para melhorar a a performance e o custo da ferramenta. Veja este blog post com possíveis otimizações.

No console do Athena, crie uma consulta com o filtro eventsource = ‘rds.amazonaws.com’, a lista com todos os eventos emitidos pelo RDS está disponível em https://docs.thinkwithwp.com/AmazonRDS/latest/APIReference/API_Operations.html, podem ser filtrados no campo eventname.

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

Com isso, podemos fazer auditorias de todos os eventos do RDS; e em casos de eventos de segurança é possível avaliar as alterações realizadas em cada evento pelo campo requestparameters, bem como qual o usuário responsável em userName. Você ainda pode modificar a consulta e explorar ainda mais os dados.

Para avaliação dos custos relacionados a solução consulte AWS Config pricing, Athena pricing e CloudTrail pricing.

Sobre o Autor

Tiago Canassa Bernardinelli

Tiago é arquiteto de soluções na AWS, atua com o segmento enterprise, foi engenheiro do time de serviços do Amazon EC2. Com experiência de mais de 10 anos em desenvolvimento de sistemas, Tiago ajudou empresas de diversos segmentos a definir, planejar e implementar suas estratégias de desenvolvimento e operações.