IAM na prática: diagnosticar acesso sem ampliar privilégios

Uma role já foi criada para a API, mas o upload falha com AccessDenied. Nesta aula, o foco é diagnosticar autorização, não criar outra identidade. Comece anotando ação, recurso, horário e identidade envolvida; sem isso, qualquer alteração de política vira tentativa e erro.

A primeira pergunta é quem está chamando a AWS. Execute aws sts get-caller-identity no mesmo contexto da aplicação ou do pipeline. O perfil do seu notebook pode funcionar enquanto a role da aplicação falha; testar com outra identidade não comprova a correção.

A política de confiança define quem pode assumir uma role, enquanto a política de permissões define o que ela pode fazer depois. Se sts:AssumeRole falha, investigue a confiança e as permissões do chamador antes de alterar acesso ao S3.

Uma autorização considera mais que a política anexada à role. SCPs, permissions boundaries, políticas de sessão e políticas de recurso também participam da avaliação; um Deny explícito aplicável prevalece sobre um Allow. Adicionar outra política permissiva não remove essa negação.

No S3, diferencie bucket de objeto: s3:ListBucket usa o ARN do bucket e pode ser limitado por prefixo; s3:GetObject usa o ARN com caminho do objeto. Uma aplicação que lê uma chave conhecida pode não precisar listar todo o bucket.

Use o simulador como diagnóstico, não como prova definitiva. simulate-principal-policy ajuda a comparar ações e recursos, mas não reproduz todos os cenários de políticas de recurso, sessão e organização. Confirme com uma chamada real controlada e examine a mensagem de erro.

Criptografia pode acrescentar outra camada: ler objeto protegido por SSE-KMS pode exigir kms:Decrypt, além da autorização no S3. Verifique a key policy e a região da chave, sem substituir criptografia por acesso público para destravar o teste.

Feche a mudança com testes negativos: o arquivo permitido deve ser lido e outro prefixo deve continuar negado. Registre evidências no PR e consulte CloudTrail quando houver eventos disponíveis; para operações de objetos S3, os data events precisam ser habilitados e podem gerar custo.

Na prática

Confirmar identidade e simular leitura de objeto

bash

# Execute com o perfil autorizado a diagnosticar IAM; troque conta e bucket.
aws sts get-caller-identity
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/cloudshop-api \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::cloudshop-assets/uploads/teste.txt \
  --query 'EvaluationResults[].{Acao:EvalActionName,Decisao:EvalDecision}'
# A simulação exige permissão IAM própria; não a conceda à aplicação.

Validar acesso permitido e acesso proibido

bash

# Execute no contexto da role da API, com objetos de teste existentes.
aws s3api get-object --bucket cloudshop-assets \
  --key uploads/teste.txt /tmp/cloudshop-permitido.txt
# Este comando deve retornar AccessDenied, não o conteúdo financeiro.
aws s3api get-object --bucket cloudshop-assets \
  --key financeiro/teste.txt /tmp/cloudshop-proibido.txt
# Se o segundo funcionar, revise as políticas antes de publicar.

Por que isso importa

Diagnosticar a causa de uma negação evita transformar um problema operacional em exposição permanente.

Erro comum

Adicionar AdministratorAccess sem identificar a ação e o recurso que falharam.

Dica de produção

Mantenha uma matriz de ações permitidas e negadas por role e repita os testes após mudanças.

Alerta de segurança

Não copie tokens temporários ou objetos sensíveis para tickets e logs; use dados sintéticos nos testes.

Pergunta de entrevista

Uma role tem Allow para GetObject, mas a chamada falha: quais camadas você investigaria?

IAM na prática: diagnosticar acesso sem ampliar privilégios

Objetivos desta aula

Na prática

Glossário

Conexão com o CloudShop

Quiz da aula

Minhas anotações