Acesso à sua AWS para plataforma externa com privilégio mínimo

Quando uma plataforma opera na sua conta#

Muitas ferramentas trabalham diretamente dentro da sua conta AWS: plataformas de deploy que criam redes, bancos de dados e containers; serviços de observabilidade que leem métricas; otimizadores de custos que analisam seu inventário. Todas precisam de permissões, e a forma como você as concede define quanto risco está assumindo.

Um padrão comum em guias de integração é criar um usuário IAM, anexar a ele algumas políticas amplas que cobrem uma longa lista de serviços (EC2, RDS, ECS, EKS, DynamoDB, ElastiCache, OpenSearch, CloudWatch, S3, Route 53 e outros) e colar as access keys na plataforma. Funciona, mas deixa credenciais de longa duração fora do seu controle e, muitas vezes, com mais permissões do que o necessário.

Este guia explica a alternativa recomendada pela AWS, uma role que a plataforma assume com um external ID, como restringir as permissões dela e como auditar o acesso. No final, você vê o que fazer se a plataforma só aceitar access keys.

Role cross-account ou access keys#

A AWS recomenda usar roles para que terceiros acessem seus recursos sem compartilhar suas credenciais de segurança e, de modo geral, preferir credenciais temporárias a access keys.

Para se aprofundar: Conectar GitHub à AWS sem chaves de acesso (OIDC)

Documentação: AWS IAM · Acesso para terceiros ↗ · AWS IAM · Access keys ↗ · AWS IAM · Boas práticas ↗

O problema do confused deputy e o external ID#

O confused deputy é um problema de segurança em que uma entidade sem permissão para uma ação consegue que outra, com mais privilégios, a execute. Neste contexto: a plataforma atende muitos clientes e assume roles em todas as contas deles. Se outro cliente soubesse o ARN da sua role, poderia pedir à plataforma que operasse na sua conta.

O external ID evita isso. A plataforma gera um identificador único para você, você o exige na trust policy e a plataforma o envia em cada AssumeRole. Só as requisições feitas em seu nome levam o valor correto.

• Deve ser gerado pela plataforma, um por cliente, e não pode ser fácil de adivinhar.
• Não é um segredo: qualquer pessoa com permissão para ver a role consegue lê-lo. A função dele é evitar a confusão, não autenticar.
• Aceita de 2 a 1.224 caracteres alfanuméricos e os símbolos + = , . @ : / -.

Documentação: AWS IAM · O problema do confused deputy ↗ · AWS IAM · External ID ↗ · AWS STS · AssumeRole ↗

Criar a role#

Você precisa de três informações da plataforma: o ID da conta AWS dela, o seu external ID e a lista de permissões exigidas. A trust policy permite que essa conta assuma a role apenas com o external ID correto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "ID-UNICO-FORNECIDO-PELA-PLATAFORMA" }
      }
    }
  ]
}

# Criar a role com a trust policy acima (sessões de 1 hora, o valor padrão)
aws iam create-role \
  --role-name plataforma-externa \
  --assume-role-policy-document file://trust.json \
  --max-session-duration 3600 \
  --tags Key=owner,Value=plataforma-externa

# Anexar só as permissões que a plataforma documenta como necessárias
aws iam put-role-policy \
  --role-name plataforma-externa \
  --policy-name permissoes-minimas \
  --policy-document file://permissoes.json

# Entregar à plataforma apenas o ARN da role (e confirmar o external ID)
aws iam get-role --role-name plataforma-externa --query 'Role.Arn'

Documentação: AWS CLI · iam create-role ↗ · AWS CLI · iam put-role-policy ↗

Restringir as permissões#

A trust policy decide quem entra; a política de permissões decide o que pode ser feito. Estas técnicas se combinam:

• Comece pela lista oficial da plataforma e revise serviço por serviço se você realmente vai usá-lo. Se não usa SageMaker ou OpenSearch, não os inclua.
• Restrinja por recurso quando o serviço permitir: ARNs específicos, prefixos de nome ou tags.
• Se o serviço suportar controle por tags, use a condição aws:ResourceTag para que a plataforma só possa modificar o que ela mesma criou e marcou.
• Adicione um permissions boundary à role se a plataforma também criar roles ou usuários, para que eles nunca ultrapassem um limite máximo.
• No AWS Organizations, as SCPs definem um teto para a conta inteira, por exemplo as regiões permitidas.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SomenteRecursosDaPlataforma",
      "Effect": "Allow",
      "Action": ["ec2:StopInstances", "ec2:StartInstances", "ec2:TerminateInstances"],
      "Resource": "arn:aws:ec2:*:111122223333:instance/*",
      "Condition": {
        "StringEquals": { "aws:ResourceTag/ManagedBy": "plataforma-externa" }
      }
    }
  ]
}

Documentação: AWS IAM · Controle de acesso com tags ↗ · AWS IAM · Permissions boundaries ↗ · AWS Organizations · SCPs ↗

Auditar e reduzir com o tempo#

• O IAM Access Analyzer gera descobertas (findings) de acesso externo: mostra quais roles e recursos podem ser usados por uma entidade fora da sua conta ou organização, e assim você confirma que só a conta da plataforma aparece.
• A validação de políticas do Access Analyzer detecta erros e permissões amplas demais antes de salvar.
• A geração de políticas cria uma política a partir da atividade real registrada no CloudTrail, útil para enxugar uma política inicial ampla.
• As informações de último acesso do IAM mostram quais serviços não foram usados; se a plataforma nunca toca em um deles, remova-o.

O CloudTrail registra as chamadas AssumeRole e cada ação feita com a role, assim você consegue atribuir à plataforma cada mudança na sua conta.

Documentação: IAM Access Analyzer ↗ · Access Analyzer · Descobertas ↗ · Access Analyzer · Validação ↗ · Access Analyzer · Geração de políticas ↗ · IAM · Último acesso ↗ · AWS CloudTrail ↗

Se a plataforma só aceita access keys#

Algumas ferramentas só aceitam um par de access keys. Nesse caso, reduza o risco:

• Crie políticas gerenciadas pelo cliente a partir do JSON publicado pela plataforma (no console do IAM: Policies, Create policy, editor JSON) e marque-as com um owner.
• Crie um usuário IAM dedicado só a essa plataforma, sem acesso ao console, e anexe apenas essas políticas.
• Gere a access key e guarde o secret na hora: a AWS só o mostra uma vez.
• Faça a rotação periodicamente, desative a chave se deixar de usar a plataforma e acompanhe a atividade dela no CloudTrail.

Documentação: AWS IAM · Criar políticas no console ↗ · AWS IAM · Gerenciar access keys ↗

Checklist#

• Role cross-account com o ID da conta da plataforma e sts:ExternalId obrigatório.
• Permissões limitadas aos serviços e recursos que a plataforma gerencia.
• Permissions boundary se a plataforma criar identidades IAM.
• Access Analyzer sem descobertas inesperadas de acesso externo.
• Access keys só se não houver alternativa, com usuário dedicado e rotação.