Pular para o conteúdo principal

Acesso SSM via Apono

Um dos motivos mais comuns para adotar o Apono é resolver o problema do acesso direto a máquinas na AWS. Na maioria das organizações, engenheiros precisam acessar instâncias EC2 para troubleshooting, deploys manuais ou investigação de incidentes, e o modelo tradicional de permissões permanentes cria riscos de segurança significativos.

Antes de entender como o Apono automatiza esse acesso, é importante dominar como funciona o AWS Systems Manager Session Manager (SSM), o serviço nativo da AWS que substitui bastion hosts e chaves SSH. Se você ainda não conhece o SSM, leia primeiro o artigo sobre AWS Systems Manager — Session Manager.

O Problema das Permissões Permanentes​

Com o SSM configurado na infraestrutura, o controle de acesso às instâncias é feito via permissões IAM. O usuário precisa ter a policy ssm:StartSession para iniciar sessões em instâncias específicas.

O problema é como essa permissão é concedida na prática:

  1. Um engenheiro solicita acesso a uma EC2.
  2. Um administrador adiciona a policy ssm:StartSession ao usuário ou grupo IAM manualmente.
  3. O engenheiro usa o acesso.
  4. Ninguém lembra de remover a permissão.

O acesso que deveria ser temporário se torna permanente. Com o tempo, cada engenheiro acumula permissões em dezenas de instâncias que não precisa mais acessar, ampliando a superfície de ataque e violando o princípio do menor privilégio.

Como o Apono Resolve​

O Apono gerencia as permissões IAM que controlam quem pode iniciar sessões SSM e em quais instâncias. Ele não substitui o SSM, a infraestrutura (Agent, Instance Profile, VPC Endpoints) continua funcionando normalmente. O que muda é que a permissão do usuário para iniciar sessões passa a ser temporária e auditada.

O fluxo com o Apono:

O connector do Apono gerencia isso adicionando e removendo policies IAM inline ou gerenciadas no usuário/grupo/role. Quando o tempo expira, a policy é automaticamente removida — o engenheiro perde imediatamente a capacidade de iniciar novas sessões SSM.

O Que Muda na Prática​

Com o Apono gerenciando o acesso SSM, o ciclo de vida da permissão passa a ser:

  • Solicitação explícita: O engenheiro precisa pedir o acesso (via portal, Slack ou CLI), informando qual instância e por quê.
  • Aprovação por política: A solicitação é aprovada automaticamente (se a política permitir) ou encaminhada para um aprovador humano.
  • Escopo granular: A policy concedida é para instâncias específicas, não para "todas as EC2".
  • Duração definida: O acesso tem prazo (ex: 2 horas) e é revogado automaticamente ao expirar.
  • Auditoria completa: Quem solicitou, quando, para qual instância, quem aprovou, quando expirou — tudo registrado.

A infraestrutura SSM (Agent instalado, Instance Profile configurada, VPC Endpoints ativos) precisa estar funcionando antes do Apono entrar. O Apono não configura o SSM — ele apenas controla quem tem permissão de usá-lo e por quanto tempo.