Dominando o AWS IAM: Solucionando Erros de Acesso Negado de Forma Eficaz

Erros AccessDenied do AWS IAM significam que a AWS avaliou sua solicitação e não encontrou um caminho de permissão efetivo. A correção mais rápida não é adivinhar uma política mais ampla. É identificar a ação exata, o recurso, o principal e o contexto de condição que a AWS avaliou.

A maioria das falhas do IAM vem de um de quatro lugares: nenhum Allow correspondente, um Deny explícito, um limite de permissões ou política de controle de serviço limitando a identidade, ou uma condição que não corresponde à solicitação.

Comece com a Lógica de Avaliação do IAM

A AWS começa com uma negação padrão. Uma solicitação é permitida apenas quando uma política aplicável a permite e nenhuma política aplicável a nega.

Um Deny explícito vence sobre qualquer Allow. Essa negação pode vir de uma política de identidade, política de recurso, limite de permissões, política de sessão, política de controle de serviço ou outro tipo de política aplicável.

Para acesso na mesma conta, políticas de identidade e políticas de recurso geralmente trabalham juntas. Para acesso entre contas, você geralmente precisa de permissão em ambos os lados: a identidade do chamador deve ter permissão para fazer a solicitação, e o recurso de destino ou a conta de destino deve confiar ou permitir esse chamador.

Capture a Solicitação Exata que Falhou

Antes de editar políticas, capture estes detalhes:

• Principal: usuário, função, sessão de função assumida ou principal de serviço da AWS.
• Ação: a operação da API, como s3:GetObject ou ec2:RunInstances.
• Recurso: o ARN ou ID do recurso.
• Região e conta.
• Condições: IP de origem, endpoint VPC, MFA, tags, contexto de criptografia ou região solicitada.

O CloudTrail geralmente é a melhor fonte. Pesquise pelo evento com falha próximo ao horário do erro e inspecione eventName, userIdentity, resources, errorCode e errorMessage.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 10

O CloudTrail não explica cada decisão de autorização em detalhes perfeitos, mas geralmente fornece a ação ausente e o principal real. Isso por si só captura muitos problemas de confusão entre função assumida e nome de sessão.

Use Ferramentas de Simulação e Análise de Acesso

O Simulador de Políticas do IAM pode testar muitas questões de políticas baseadas em identidade antes de você alterar as permissões de produção. Selecione o usuário ou função, escolha a ação do serviço, forneça o ARN do recurso quando possível e inclua chaves de condição relevantes.

Para contas e serviços AWS recentes, verifique também a própria mensagem de acesso negado. Alguns serviços retornam uma mensagem de falha de autorização codificada. Se você tiver permissão, decodifique-a com o STS:

aws sts decode-authorization-message \
  --encoded-message '<mensagem-codificada-do-erro>'

Essa mensagem decodificada pode mostrar qual tipo de política contribuiu para a negação.

O IAM Access Analyzer é útil para questões de política de recurso e entre contas. Pode ajudar a encontrar acesso externo não intencional e validar algumas políticas antes da implantação.

Verifique Cada Camada de Política

Políticas baseadas em identidade são anexadas a usuários, grupos e funções. Elas respondem o que a identidade pode fazer.

Políticas baseadas em recurso são anexadas a recursos como buckets S3, chaves KMS, filas SQS, funções Lambda e políticas de confiança de função. Elas respondem quem pode usar esse recurso ou assumir essa função.

Limites de permissões definem as permissões máximas para um usuário ou função. Eles não concedem acesso por si só. As permissões efetivas são a interseção da política de identidade e do limite.

Políticas de controle de serviço no AWS Organizations definem permissões máximas para contas ou unidades organizacionais. As SCPs também não concedem acesso por si só. Elas podem bloquear uma ação mesmo quando uma política do IAM a permite.

Políticas de sessão e tags de permissão também podem reduzir o acesso para sessões de função assumida. Se uma função funciona em um caminho, mas falha quando assumida por um job de CI, compare a política de sessão, as tags de sessão e as condições da política de confiança.

Padrões Comuns de AccessDenied

Ações Dependentes Ausentes

Algumas operações da AWS exigem mais do que a ação óbvia. Por exemplo, iniciar uma instância EC2 criptografada pode exigir permissões EC2 mais permissões KMS para a chave. O CloudTrail e a documentação do serviço são suas melhores referências para ações dependentes.

ARN de Recurso Incorreto

ARNs de nível de bucket S3 e de nível de objeto são diferentes:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::meu-bucket/*"
}

arn:aws:s3:::meu-bucket cobre o bucket. arn:aws:s3:::meu-bucket/* cobre objetos no bucket. Muitos erros do S3 vêm de conceder um quando a chamada da API precisa do outro.

Incompatibilidade de Condição

As condições devem corresponder exatamente ao contexto da solicitação. Uma política que permite acesso apenas através de um endpoint VPC negará solicitações de outro endpoint, do endpoint público da AWS ou de uma região diferente se a condição verificar essa região.

{
  "Effect": "Deny",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::meus-dados-sensiveis",
    "arn:aws:s3:::meus-dados-sensiveis/*"
  ],
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

Essa declaração nega solicitações HTTP e permite que solicitações HTTPS continuem pelo restante da avaliação da política. Ela não concede acesso por si só.

Lacunas na Política de Chave KMS

O KMS é uma fonte comum de erros de acesso confusos. Uma política do IAM pode permitir kms:Decrypt, mas a política da chave também deve permitir o principal diretamente ou permitir que a conta delegue acesso através de políticas do IAM.

Verifique a política da chave, concessões, condições de contexto de criptografia e o serviço que usa a chave.

Um Fluxo Prático de Solução de Problemas

Primeiro, reproduza ou capture a chamada com falha. Obtenha a ação exata da API e o principal do CloudTrail.

Em seguida, procure por negações explícitas em SCPs, políticas de recurso, limites de permissões e políticas de identidade. Neegações explícitas economizam tempo porque substituem tudo o mais.

Depois, confirme se há uma permissão correspondente para a ação e o recurso exatos. Inclua ações dependentes e recursos relacionados, como chaves KMS, funções IAM passadas para serviços, interfaces de rede ou grupos de log.

Finalmente, teste com a alteração de política mais restrita possível. Evite corrigir uma negação desconhecida com Action: "*" ou Resource: "*"; isso esconde o problema e cria um novo risco de segurança.

O hábito útil é tratar cada AccessDenied como um problema de evidência. Depois que você souber o principal, a ação, o recurso e a camada de política, a correção geralmente é pequena e clara.