AWS Systems Manager — Session Manager

O AWS Systems Manager Session Manager (SSM) é um serviço nativo da AWS que permite acessar instâncias EC2 sem abrir portas de rede, sem gerenciar chaves SSH e com auditoria completa de cada sessão. Ele substitui o modelo tradicional de bastion host com uma abordagem mais segura, auditável e sem custos adicionais de infraestrutura.

O Problema do Bastion Host

O modelo tradicional de acesso a servidores na AWS funciona assim: você cria uma instância EC2 chamada bastion host (ou jump box) em uma subnet pública, abre a porta 22 (SSH) no security group e distribui chaves SSH para os engenheiros. Para acessar qualquer máquina na subnet privada, o engenheiro primeiro se conecta ao bastion e de lá faz um segundo SSH para o servidor de destino.

Esse modelo funciona, mas cria vários problemas operacionais e de segurança:

• Superfície de ataque exposta: O bastion host precisa estar acessível pela internet (porta 22 aberta). Qualquer vulnerabilidade nele compromete toda a rede interna.
• Gerenciamento de chaves SSH: Distribuir, rotacionar e revogar chaves SSH para dezenas ou centenas de engenheiros é um pesadelo operacional.
• Falta de auditoria granular: Saber quem acessou qual servidor e o que fez durante a sessão exige configurações adicionais de logging.
• Custo operacional: O bastion host precisa ser mantido, atualizado e monitorado, sendo mais um servidor para gerenciar.
• Acesso permanente: Uma vez que o engenheiro tem a chave SSH, ele tem acesso contínuo até que a chave seja revogada manualmente.

Como o SSM Funciona

O SSM funciona através de um agente instalado na instância EC2 (o SSM Agent) que se comunica com o serviço da AWS via HTTPS. Em vez de abrir uma conexão SSH direta, o engenheiro inicia uma sessão via console da AWS, CLI ou SDK, e o SSM Agent na instância cria um canal seguro de comunicação.

O fluxo na prática:

1. O engenheiro executa aws ssm start-session --target i-0abc123def (ou clica em "Connect" no console).
2. O serviço SSM verifica se o usuário IAM tem permissão para iniciar sessões naquela instância.
3. O SSM Agent na EC2 recebe a instrução e abre um canal seguro.
4. O engenheiro recebe um shell interativo na máquina, sem SSH, sem chave, sem porta aberta.
5. Toda a sessão pode ser gravada automaticamente no S3 ou CloudWatch Logs.

Pré-requisitos

Para que o SSM funcione em uma instância EC2, três componentes são necessários:

1. SSM Agent Instalado e Ativo

O SSM Agent é o software que roda dentro da EC2 e se comunica com o serviço AWS Systems Manager. Ele é responsável por receber comandos, iniciar sessões e reportar o status da instância.

• Amazon Linux 2/2023, Ubuntu 20.04+: O SSM Agent já vem pré-instalado por padrão. Na maioria dos casos, não é necessário fazer nada.
• Outras AMIs: Pode ser necessário instalar manualmente via yum install amazon-ssm-agent ou snap install amazon-ssm-agent.
• Verifique o status com: systemctl status amazon-ssm-agent.

2. IAM Role na Instância (Instance Profile)

Uma instância EC2 não pode ter uma IAM role diretamente associada a ela. Para que a instância assuma uma role, a AWS utiliza um recurso intermediário chamado Instance Profile. O Instance Profile é um "container" que encapsula uma IAM role e permite que a EC2 assuma essa identidade. É ele que aparece na configuração de launch da instância (no campo "IAM Instance Profile"). Quando você associa um Instance Profile a uma EC2, qualquer processo rodando dentro da instância (incluindo o SSM Agent) pode assumir a role automaticamente e obter credenciais temporárias via metadata service, sem precisar de access keys hardcoded.

No console da AWS, ao criar ou editar uma EC2, o campo aparece como "IAM role", mas por baixo, a AWS está criando e associando um Instance Profile automaticamente. Via CLI ou Terraform, a distinção é mais visível: você cria a role, cria o Instance Profile, associa a role ao Instance Profile e então associa o Instance Profile à instância.

A instância EC2 precisa de uma IAM role (via Instance Profile) que permita ao SSM Agent se comunicar com o serviço da AWS. A policy gerenciada AmazonSSMManagedInstanceCore contém todas as permissões necessárias.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel"
      ],
      "Resource": "*"
    }
  ]
}

Na prática, basta anexar a policy gerenciada AmazonSSMManagedInstanceCore à role da instância. Não é necessário criar uma policy customizada, pois a policy gerenciada já inclui todas as permissões listadas acima e é mantida pela AWS.

3. Conectividade com o Serviço SSM

O SSM Agent precisa alcançar os endpoints do serviço Systems Manager via HTTPS (porta 443). Existem duas formas:

Método	Quando usar
Internet (NAT Gateway)	A subnet privada tem acesso à internet via NAT. O Agent se comunica diretamente com os endpoints públicos do SSM.
VPC Endpoints (PrivateLink)	A subnet não tem acesso à internet. Você cria VPC endpoints para ssm, ssmmessages e ec2messages, e o tráfego permanece dentro da rede da AWS.

Para ambientes que exigem zero acesso à internet nas instâncias, os VPC Endpoints são obrigatórios. Você precisará de três Interface Endpoints:

• com.amazonaws.<região>.ssm
• com.amazonaws.<região>.ssmmessages
• com.amazonaws.<região>.ec2messages

Para mais detalhes sobre tipos de endpoints, DNS privado, custos e configuração, veja o artigo dedicado sobre VPC Endpoints.

Permissões do Usuário

Além da configuração na instância, o usuário que inicia a sessão também precisa de permissões IAM. A permissão mínima necessária é:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:<região>:<conta>:instance/i-0abc123def"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ssm:TerminateSession",
        "ssm:ResumeSession"
      ],
      "Resource": "arn:aws:ssm:*:*:session/${aws:username}-*"
    }
  ]
}

Essa policy permite ao usuário iniciar sessões apenas em instâncias específicas (definidas pelo ARN) e gerenciar apenas suas próprias sessões. É aqui que o princípio do menor privilégio se aplica: em vez de dar acesso a todas as instâncias, você controla exatamente quais máquinas cada usuário pode acessar.

Vantagens do SSM sobre o Bastion Host

Aspecto	Bastion Host	SSM
Portas de rede	Porta 22 aberta (SSH)	Nenhuma porta de entrada
Chaves SSH	Necessárias e difíceis de gerenciar	Não utiliza chaves SSH
Auditoria	Requer configuração adicional	Nativa (CloudTrail + gravação de sessão)
Custo	Instância EC2 dedicada	Sem custo adicional (serviço incluso)
Controle de acesso	Baseado em chaves e IPs	Baseado em permissões IAM (granular)
Manutenção	Patches, updates, monitoramento	Zero manutenção de infraestrutura

O SSM é a base sobre a qual ferramentas de gerenciamento de acesso Just-in-Time como o Apono atuam — controlando quem recebe a permissão ssm:StartSession e por quanto tempo, automatizando o ciclo de concessão e revogação que antes dependia de ação manual.

Considerações de Segurança: Port Forwarding

O SSM Session Manager oferece uma funcionalidade de port forwarding que permite redirecionar portas de uma instância EC2 para a máquina local do engenheiro. Embora útil em cenários legítimos (como acessar um banco de dados RDS ou uma interface web interna), essa funcionalidade introduz riscos de segurança que precisam ser avaliados.

O Problema

No modelo tradicional de bastion host, uma prática comum de hardening é restringir a transferência de arquivos entre a máquina local e o bastion, bloqueando SCP, SFTP e túneis SSH. Isso limita a exfiltração de dados e impede que arquivos não autorizados sejam enviados ao ambiente interno.

Com o SSM, o port forwarding pode reintroduzir esse risco. Um engenheiro com permissão de port forwarding pode:

• Redirecionar portas de bancos de dados para a máquina local, acessando dados diretamente sem passar por camadas de controle.
• Criar túneis para serviços internos, expondo aplicações que não deveriam ser acessíveis fora da VPC.
• Facilitar a exfiltração de dados, transferindo informações sensíveis através do túnel estabelecido.

# Exemplo de port forwarding via SSM — redireciona a porta 5432 (PostgreSQL) da EC2 para localhost
aws ssm start-session \
  --target i-0abc123def \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["5432"],"localPortNumber":["5432"]}'

Como Mitigar

A AWS permite controlar o port forwarding via IAM policies e SSM Session Documents. A estratégia recomendada é negar por padrão e liberar apenas para quem realmente precisa.

1. Bloquear Port Forwarding via IAM

Essa policy deve ser aplicada na IAM do usuário (ou na role assumida por ele, como no caso de SSO), e não na role da instância EC2. Isso porque é o usuário quem executa a ação ssm:StartSession e a instância apenas recebe a conexão. Portanto, o controle de quem pode ou não fazer port forwarding está no lado de quem inicia a sessão:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPortForwardingFromSSOToAponoInstances",
      "Effect": "Deny",
      "Action": "ssm:StartSession",
      "Resource": [
        "arn:aws:ec2:*:*:instance/*",
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSession",
        "arn:aws:ssm:*:*:document/AWS-StartPortForwardingSessionToRemoteHost"
      ],
    }
  ]
}

O documento AWS-StartPortForwardingSession redireciona portas da própria instância, enquanto o AWS-StartPortForwardingSessionToRemoteHost permite redirecionar portas de outros hosts acessíveis pela instância (como um RDS em outra subnet). Ambos devem ser bloqueados se o objetivo é impedir qualquer tipo de túnel.

Essa policy pode ser aplicada como Service Control Policy (SCP) no AWS Organizations, garantindo que o bloqueio de port forwarding se aplique a todas as contas e instâncias EC2 da organização, independentemente das permissões individuais de cada conta. Como SCPs funcionam como guardrails de negação, mesmo que um administrador de conta conceda permissão de port forwarding, o SCP impede a execução.

2. Monitorar com CloudTrail

Toda sessão SSM, incluindo port forwarding, é registrada no CloudTrail. Configure alertas para detectar o uso de documentos de port forwarding:

• Monitore eventos StartSession onde o DocumentName contenha PortForwarding.
• Crie alarmes no CloudWatch para notificar a equipe de segurança quando port forwarding for utilizado.
• Mantenha logs de sessão habilitados no S3 ou CloudWatch Logs para auditoria completa.

Quando Permitir Port Forwarding

O port forwarding não é inerentemente ruim, pois ele substitui práticas ainda mais arriscadas, como expor serviços diretamente na internet. Cenários onde faz sentido permitir:

• Acesso a bancos de dados em desenvolvimento: Engenheiros precisam conectar ferramentas locais (como DBeaver ou pgAdmin) a um RDS em subnet privada.
• Debugging de aplicações internas: Acessar interfaces web de monitoramento ou dashboards internos temporariamente.
• Ambientes não produtivos: Em ambientes de desenvolvimento e staging, o risco é menor e a produtividade é prioridade.