Fazer isso com segurança é essencial, por isso, muitas vezes optamos por utilizar uma máquina EC2 como bastion host em uma subnet pública. Dessa forma, é possível autenticar o usuário através de um par de chaves, permitindo a conexão via SSH.

Para alguns casos, essa é uma prática viável, porém lidar com a segurança e gerenciamento dessas chaves não é algo tão simples. Se, por exemplo, um desenvolvedor deixar o projeto por algum motivo, uma medida de segurança comum seria a troca das chaves de todas as máquinas às quais ele tinha acesso e a redistribuição de novas chaves para o restante da equipe, correto?

E se, além disso, limitássemos o acesso na porta 22 do bastion host para os IPs do time de forma individual, prevenindo inclusive ataques DDoS no bastion host?

Ainda assim, não poderíamos deixar de atualizar os IPs de diversos desenvolvedores sempre que o IP da máquina deles mudasse ou de conceder permissões de acesso em Security Groups para que eles mesmos façam as atualizações, abrindo brechas de segurança difíceis de serem monitoradas.

Sempre que um desenvolvedor é desligado ou muda para outro projeto, precisamos remover o seu IP em múltiplas contas da AWS, projetos e ambientes (desenvolvimento, homologação, produção, entre outros), aumentando a complexidade de gerenciamento.

Felizmente, temos uma solução efetiva na AWS que permite manter todo o gerenciamento de acessos pelo IAM e conectar em uma subnet privada através do SSM (Systems Manager Session Manager) e VPC Endpoints.

Confira abaixo o passo a passo detalhado de como fazer uma conexão no RDS com o SSM e realizar a configuração de cada recurso.

Imagem da arquitetura implementada:

Pré-requisitos

Para começar, é necessário configurar as seguintes ferramentas e serviços:

• AWS CLI versão 2

• Session Manager plugin

• VPC com DNS ativado

• Subnet(s) privada(s)

• Banco de dados no RDS

• DBeaver ou similar para conexão com banco de dados local

Para verificar a instalação e as suas credenciais, utilize os comandos aws --version, session-manager-plugin e aws sts get-caller-identity.

Nesse tutorial, estou usando ambiente Linux via WSL.

Security Groups

Com tudo configurado, podemos criar Security Groups para os VPC Endpoints, Bastion Host e RDS. (Vou me referir a eles com o mesmo nome utilizado no momento da criação, SG_SSM_ENDPOINTS, SG_SSM_BH e SG_RDS, respectivamente).

Como o banco de dados foi criado anteriormente, você pode usar o mesmo Security Group do momento da criação ou um novo, como preferir.

SG_SSM_ENDPOINTS

Ao criar um novo Security Group, preencha o seu nome, descrição e VPC.

Inbound Rules: Entrada HTTPS para o CIDR da sua VPC.

Outbound Rules: Saída de dados para o CIDR da sua VPC.

SG_SSM_BH

Inbound Rules: Entrada do banco de dados para o SG_RDS.

Outbound Rules: Saída PostgreSQL e HTTPS para a internet.

SG_RDS

Inbound Rules: Entrada PostgreSQL para o SG_SSM_BH.

Outbound Rules: Saída para a rede.

Role IAM

O próximo passo será a criação de uma role no IAM do tipo serviços AWS.

Em EC2, selecione EC2 Role for AWS Systems Manager como na print abaixo:

A política gerenciada AmazonSSMManagedInstanceCore estará selecionada automaticamente, apenas prossiga.

Preencha o nome da role e finalize a criação.

Criação de VPC Endpoints

Estou utilizando os 5 VPC Endpoints listados abaixo, mas somente os 3 primeiros são obrigatórios. Essa variação acontece conforme a sua necessidade e você poderá encontrar os detalhes de cada endpoint na documentação da AWS.

• com.amazonaws.region.ssm

• com.amazonaws.region.ssmmessages

• com.amazonaws.region.ec2messages

• com.amazonaws.region.logs

• com.amazonaws.region.ec2

Começaremos com o endpoint com.amazonaws.region.ssm.

Passo 1: Preencha o nome, selecione AWS Services e busque por ssm. Em seguida, selecione o com.amazonaws.region.ssm.

Passo 2: Escolha a VPC, habilite o DNS e selecione suas subnets privadas.

Passo 3: Escolha o security group SG_SSM_ENDPOINTS.

Para esse tutorial, estou utilizando a política com acesso completo.

Agora é só clicar em “Criar endpoint”. Lembrando que você deverá repetir essas etapas para cada um dos endpoints mencionados acima.

Se estiver tudo certo, todos os endpoints configurados estarão listados e disponíveis.

Criação do Bastion Host no EC2

Escolha um nome, sistema operacional e tipo de instância e siga sem associar pares de chaves.

Em configurações de rede:

• Selecione sua VPC, uma subnet privada que também esteja associada ao seu banco de dados e o security group do Bastion Host (SG_BH_SSM).

• A opção de Auto IP Público deve ficar desabilitada.

Em opções avançadas, selecione a role que criamos (EC2_SSM_CONNECT) no campo perfil IAM da instância.

Clique em criar instância para finalizar e aguarde a máquina ser ativada.

Ainda nessa página, copie e guarde o ID completo da instância, que tem esse formato: I-0xyz123.

Agente SSM

Verifique se o agente do SSM já está ativo na máquina. Dependendo do sistema operacional, ele já vem instalado, caso contrário, você deverá instalá-lo manualmente.

Se o agente já estiver instalado, seu ec2 estará listado no “Fleet Manager” e pronto para ser acessado.

Se ainda não apareceu, verifique se o agente está ativo na máquina. Você também poderá um guia para fazer a instalação manualmente em diferentes sistemas operacionais na documentação.

Sessão SSM e conexão com o banco de dados

Para preparar o comando e iniciar a sessão no SSM, edite o comando abaixo preenchendo o ID do EC2 e o host do banco de dados.

No portNumber, preencha com a porta do banco de dados configurada no RDS.

No localPortNumber, preencha com a porta que utilizará para conectar no banco local.

As barras (\) no comando são apenas para melhorar a visibilidade. Dependendo do seu sistema, elas podem não funcionar. Nesse caso, retire as barras deixando apenas espaços entre os parâmetros.

aws ssm start-session \
--target i-ID-ec2-bastion-host \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["database.id.region.rds.amazonaws.com"],"portNumber":["5432"], "localPortNumber":["5001"]}'

Se tudo estiver correto, você verá a mensagem abaixo no terminal, confirmando que a sua sessão foi iniciada no SSM com o número da porta local de conexão.

Mantenha o terminal aberto para conectar no banco.

No DBeaver ou similar, preencha o usuário e senha apontando o localhost para a porta escolhida.

Pronto, agora você está conectado com segurança!

Se você está utilizando um acesso com altos privilégios na AWS, você não terá problemas com permissões, mas caso sua equipe utilize acessos mais restritos, é importante adicionar o SSM na política de acesso deles.

Conclusão

Agora você já está conectado no banco de dados de forma segura e gerencia de forma prática os acessos no RDS, mas é importante destacar que embora a abordagem discutida ofereça um alto nível de segurança, existem outras práticas e isso pode variar conforme a política interna de cada empresa. Vou citar algumas que podem ser exploradas:

• Evitar armazenamento de credenciais direto no código com o uso do AWS Secrets Manager ou AWS Parameter Store.

• Utilização do RDS IAM Authentication para eliminar a gestão de credenciais.

• Auditorias e monitoramento de ameaças com AWS CloudTrail e Amazon CloudWatch.

• Estabelecer outras camadas de segurança através de conexão VPN, AWS Direct Connect ou AWS PrivateLink.

O Session Manager ainda oferece logs de sessões que podem ser salvos no CloudWatch ou S3, possibilita a especificação de variáveis e inclusão de comandos shell ao iniciar sessões, integração com KMS, gerenciamento do tempo de sessão e muito mais.

For some scenarios, this is a viable practice, but managing the security of these keys isn't straightforward. For instance, if a developer leaves the project, a common security measure would involve changing the keys for all machines they had access to and redistributing new keys to the remaining team members. Correct? Moreover, what if we restricted access to port 22 of the bastion host to individual team IPs, thereby preventing DDoS attacks on the bastion host?

However, we'd still face the challenge of updating IPs for multiple developers whenever their machine IPs change or granting access permissions in Security Groups for them to update themselves, potentially causing security gaps that are difficult to monitor.

Whenever a developer leaves or switches to another project, we must remove their IP from multiple AWS accounts, projects, and environments (such as development, staging, production, among others), increasing management complexity.

Fortunately, AWS provides an effective solution that allows access management through IAM and connection to a private subnet through SSM (Systems Manager Session Manager) and VPC Endpoints.

Check below for a detailed step-by-step guide on connecting to RDS using SSM and configuring each resource.

Image of the implemented architecture:

Prerequisites

To begin, you'll need to set up the following tools and services:

• AWS CLI version 2

• Session Manager plugin

• VPC with DNS enabled

• Private subnet(s)

• Database on RDS

• DBeaver or a similar tool for local database connection

To verify installation and your credentials, you can use the commands aws --version, session-manager-plugin, and aws sts get-caller-identity.

In this tutorial, I'm using a Linux environment through WSL.

Security Groups

With everything set up, we can create Security Groups for the VPC Endpoints, Bastion Host, and RDS (referenced with the same names used during creation: SG_SSM_ENDPOINTS, SG_SSM_BH, and SG_RDS, respectively).

You can use the same Security Group created during database creation or create a new one, as you prefer.

SG_SSM_ENDPOINTS

When creating a new Security Group, fill in its name, description, and VPC.

Inbound Rules: HTTPS input for your VPC's CIDR.

Outbound Rules: Data output for your VPC's CIDR.

SG_SSM_BH

Inbound Rules: Database input for SG_RDS.

Outbound Rules: PostgreSQL and HTTPS output to the internet.

SG_RDS

Inbound Rules: PostgreSQL input for SG_SSM_BH.

Outbound Rules: Output to the network.

IAM Role

The next step is to create a role in IAM of the AWS service type. In EC2, select "EC2 Role for AWS Systems Manager" as shown in the screenshot below:

The managed policy AmazonSSMManagedInstanceCore will be automatically selected, click next.

Fill in the role name and complete the creation.

Creation of VPC Endpoints

I'm using the 5 VPC Endpoints listed below, but only the first 3 are mandatory. This variation depends on your needs, and you can find details for each endpoint in the AWS documentation.

• com.amazonaws.region.ssm

• com.amazonaws.region.ssmmessages

• com.amazonaws.region.ec2messages

• com.amazonaws.region.logs

• com.amazonaws.region.ec2

We'll start with the endpoint com.amazonaws.region.ssm.

Step 1: Fill in the name, select AWS Services, and search for ssm. Then, select com.amazonaws.region.ssm.

Step 2: Choose the VPC, enable DNS, and select your private subnets.

Step 3: Choose the security group SG_SSM_ENDPOINTS.

For this tutorial, I'm using the policy with full access.

Now, simply click "Create endpoint". Remember to repeat these steps for each of the endpoints mentioned above.

If everything is correct, all configured endpoints will be listed and available.

Creation of Bastion Host on EC2

Choose a name, operating system, and instance type, and proceed without associating key pairs.

In network settings:

• Select your VPC, a private subnet associated with your database, and the security group of the Bastion Host (SG_BH_SSM).

• The "Auto-assign Public IP" option must be disabled.

In advanced options, select the role we created (EC2_SSM_CONNECT) in the IAM instance profile field.

Click "Create instance" to finish and wait for the machine to be activated. Still on this page, copy and save the full instance ID with the following format: i-0xyz123.

SSM Agent

Check if the SSM agent is already active on the machine. Depending on the operating system, it may come pre-installed, or you may need to install it manually. If the agent is already installed, your EC2 instance will be listed in "Fleet Manager" and ready to be accessed.

If it hasn't appeared yet, verify if the agent is active on the machine. You can also refer to the documentation for manual installation guides on different operating systems.

SSM Session and Database Connection

To prepare the command and initiate the session in SSM, edit the command below by filling in the EC2 ID and database host.

Fill in the portNumber with the database port configured in RDS.

For localPortNumber, use the port you'll use to connect to the local database.

The backslashes (\) in the command are just for visibility improvement. Depending on your system, they may not work. In this case, remove the backslashes, leaving only spaces between the parameters.

aws ssm start-session \
--target i-ID-ec2-bastion-host \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters '{"host":["database.id.region.rds.amazonaws.com"],"portNumber":["5432"], "localPortNumber":["5001"]}'

If everything is correct, you'll see the message below in the terminal, confirming that your session has been started in SSM with the local connection port number.

Keep the terminal open to connect to the database. In DBeaver or a similar tool, fill in the username and password, pointing localhost to the chosen port.

Now, you're securely connected!

If you're using high-privilege access in AWS, you won't encounter permission issues. However, if your team uses more restricted access, it's important to add SSM to their access policy.

Conclusion

You're now securely connected to the database and can conveniently manage RDS access. However, it's important to note that while the discussed approach offers a high level of security, there are other practices that may vary depending on each company's internal policy. I'll mention some that can be explored:

• Avoid storing credentials directly in the code using AWS Secrets Manager or AWS Parameter Store.

• Use RDS IAM Authentication to eliminate credential management.

• Audit and monitor threats with AWS CloudTrail and Amazon CloudWatch.

• Establish additional security layers through VPN connections, AWS Direct Connect, or AWS PrivateLink.

The Session Manager also offers session logs that can be saved in CloudWatch or S3, allows variable specification, inclusion of shell commands when starting sessions, integration with KMS, session time management, and much more.