Solução de Problemas de 'Acesso Negado' e Autenticação na AWS CLI

Acesso Negado na AWS CLI é frustrante porque a mensagem geralmente nomeia a chamada de API que falhou, mas não a linha de política que a causou. Esses problemas quase sempre têm origem em políticas de Identity and Access Management (IAM) mal configuradas, credenciais temporárias expiradas ou configuração incorreta do ambiente CLI.

O hábito útil é dividir o problema em duas perguntas: quem é a identidade que a CLI está usando para fazer a chamada e qual limite de política está impedindo essa identidade de realizar a ação?

1. Diagnóstico Inicial: Identificando o Chamador e as Credenciais

Antes de mergulhar em análises complexas de políticas, o primeiro passo é confirmar definitivamente qual identidade IAM a AWS CLI está usando e se essas credenciais ainda são válidas.

Verificar Identidade Atual: `sts get-caller-identity`

Este é o comando de diagnóstico mais crítico. Ele informa exatamente qual ARN de Usuário, ARN de Função ou sessão de função assumida está executando os comandos subsequentes da AWS.

aws sts get-caller-identity

Saída Esperada:

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Se o ARN retornado não corresponder ao usuário ou função que você espera, você está operando sob o perfil AWS errado ou variáveis de ambiente incorretas.

Verificar Configuração do Perfil e Região

Certifique-se de que o perfil AWS correto está sendo usado, seja especificado pela flag --profile ou definido pela variável de ambiente AWS_PROFILE.

# Verificar as configurações definidas para o perfil padrão
aws configure list

# Ou verificar um perfil específico
aws configure list --profile prod-admin

Se a saída não mostrar nenhuma região ou mostrar uma região incorreta, as operações em recursos globais ou serviços específicos de região (como buckets S3 ou instâncias EC2) podem falhar, às vezes resultando em um Acesso Negado se o recurso não for encontrado onde a CLI está procurando.

Dica: Se o próprio comando sts get-caller-identity falhar com um erro de autenticação, isso indica um problema fundamental com as chaves de acesso (elas podem ter sido excluídas, revogadas ou estão incorretas).

Lidando com Credenciais Temporárias

Se você estiver usando uma Função IAM (via STS AssumeRole), a CLI opera com credenciais temporárias que incluem um SessionToken. Essas credenciais expiram após a duração configurada para a sessão, geralmente uma hora em configurações padrão. Embora a AWS CLI geralmente as atualize automaticamente quando obtidas da cadeia de provedores de credenciais padrão, configurações manuais podem falhar.

Sintoma: Os comandos funcionam inicialmente, mas falham após um período definido (por exemplo, 60 minutos) com um erro de autenticação.

Solução: Se estiver usando um script personalizado ou um ambiente carregado manualmente, certifique-se de que seu método para assumir a função inclua um mecanismo para atualizar as credenciais quando elas expirarem.

2. Aprofundamento em Políticas IAM e Autorização

Depois de confirmar a identidade sendo usada, o próximo passo é determinar por que essa identidade não tem as permissões necessárias. As falhas de autorização da AWS são complexas porque várias políticas são avaliadas simultaneamente.

A Hierarquia de Avaliação de Políticas IAM

Erros de autorização geralmente ocorrem devido a um dos seguintes componentes de política:

Negação Explícita: Uma declaração Deny explícita em qualquer política aplicável (Identidade, Recurso ou Limite) sempre substitui uma declaração Allow.
Allow Ausente: Nenhuma política aplicável à identidade ou ao recurso concede a ação específica.

A. Políticas Baseadas em Identidade (Usuários e Funções)

Verifique as políticas IAM anexadas diretamente ao usuário ou à função que está sendo assumida. Procure por:

Ações Ausentes: A política lista especificamente a ação de API necessária (por exemplo, s3:ListBucket, ec2:DescribeInstances)?
Restrições de Recurso: A política restringe a ação a recursos específicos usando o elemento Resource? Um erro comum é definir Resource: "*" quando a ação requer um ARN específico, ou vice-versa.
Condições: Existem condições (por exemplo, endereço IP de origem, hora do dia, MFA necessária) que não estão sendo atendidas?

B. Políticas Baseadas em Recursos (S3, SQS, KMS)

Para serviços como S3 ou KMS, o próprio recurso tem uma política que dita quem pode acessá-lo. Para acesso entre contas e para muitos designs específicos de recursos, a política do recurso também deve permitir o principal. Na mesma conta, a interação exata depende do tipo de principal e do serviço, portanto, não presuma que uma política de identidade sozinha explica todos os resultados.

Exemplo: Tentar acessar um bucket S3 (Política de Recurso) que tem um Deny explícito para todos os usuários fora de um VPC Endpoint específico resultará em Acesso Negado, independentemente da política IAM do usuário.

C. Limites de Permissão e SCPs

Se sua organização usa AWS Organizations, as Service Control Policies (SCPs) definem as permissões máximas permitidas dentro de uma conta. Da mesma forma, os Limites de Permissão (Permission Boundaries) limitam as permissões máximas que uma entidade IAM pode possuir.

Se a SCP ou o Limite negar a ação necessária, a operação CLI falhará, mesmo que a Política de Identidade conceda a permissão.

Ferramenta Prática: Simulador de Políticas IAM

Ao solucionar falhas complexas, o Simulador de Políticas IAM no Console de Gerenciamento da AWS é inestimável. Você pode testar uma ação específica (por exemplo, s3:GetObject) contra um recurso específico (por exemplo, arn:aws:s3:::my-bucket/key) e especificar a entidade IAM, ajudando a identificar exatamente qual declaração de política está causando a negação.

3. Cenários Comuns de 'Acesso Negado' e Soluções

Cenário 1: Acesso Negado ao S3 (Recurso vs. Identidade)

O Acesso Negado do S3 é notório porque pode ser causado pela Política do Usuário ou pela Política do Bucket.

Causa	Diagnóstico	Solução
Allow Ausente na Política do Bucket	`sts get-caller-identity` funciona, mas `aws s3 ls` falha.	Modifique a Política do Bucket para permitir explicitamente que o ARN do chamador execute as ações necessárias (`s3:ListBucket`, `s3:GetObject`).
Permissões KMS Decrypt Ausentes	O acesso a objetos criptografados falha (mesmo se a política S3 permitir).	Certifique-se de que a entidade IAM tenha permissões para usar a chave KMS subjacente (`kms:Decrypt`) que criptografou o objeto.
Requester Pays	As tentativas de baixar arquivos grandes falham.	Se o bucket exigir `Requester Pays`, o comando CLI deve incluir a flag `--request-payer requester`.

Cenário 2: Negação Implícita Devido a Falhas de Condição

Muitas políticas utilizam condições que impõem práticas recomendadas de segurança, como exigir Autenticação Multifator (MFA).

Se sua política incluir uma condição como:

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

E você tentar executar um comando sem MFA autenticada, a ação será implicitamente negada.

Solução: Para comandos que exigem MFA, você deve primeiro criar uma sessão STS autenticada com seu dispositivo MFA:

# 1. Obter credenciais temporárias usando seu token MFA
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Exportar o AccessKeyId, SecretAccessKey e SessionToken resultantes como variáveis de ambiente para sua sessão CLI.

Cenário 3: Região Ausente ou Incorreta

Embora nem sempre seja um erro de Acesso Negado, tentar executar uma ação em um recurso sem especificar a região correta geralmente leva a falhas de autorização ou recurso não encontrado, especialmente ao trabalhar com serviços regionais como EC2, DynamoDB ou EKS.

Solução: Defina explicitamente a região em seu comando ou certifique-se de que seu perfil esteja configurado corretamente.

aws ec2 describe-instances --region us-west-2

Verificações Específicas de Serviço que Economizam Tempo

Erros de IAM são mais fáceis de depurar quando você para de tratar a AWS como um único sistema de permissão. Cada serviço adiciona seu próprio modelo de recurso e chaves de condição.

Para S3, separe as ações no nível do bucket das ações no nível do objeto. s3:ListBucket usa o ARN do bucket, enquanto s3:GetObject e s3:PutObject usam ARNs de objeto sob o bucket. Uma política que concede s3:GetObject em arn:aws:s3:::my-bucket está malformada; o acesso ao objeto precisa de arn:aws:s3:::my-bucket/*. O erro inverso é igualmente comum para listagem.

Para KMS, verifique a política da chave, bem como a política IAM. Uma função pode parecer ter kms:Decrypt, mas se a política da chave não permitir esse caminho de função, a descriptografia ainda falha. Isso aparece ao baixar objetos S3 criptografados, puxar snapshots EBS criptografados ou ler segredos que usam uma chave gerenciada pelo cliente.

Para ECR, o login no Docker e a extração de imagem exigem que vários serviços estejam alinhados. A identidade CLI pode precisar de ecr:GetAuthorizationToken, e a política do repositório pode precisar permitir ações de pull se o repositório for compartilhado entre contas. Se a função do nó do cluster estiver extraindo a imagem, depurar com seu perfil de administrador pessoal prova muito pouco; teste como a função do nó ou a função de execução da tarefa.

Para fluxos de trabalho de assume-role do STS, observe ambos os lados da relação de confiança. O chamador precisa de permissão para chamar sts:AssumeRole, e a política de confiança da função de destino deve confiar no chamador. Se um ID externo ou condição MFA estiver presente na política de confiança, o comando assume-role deve satisfazê-la.

A Precedência do Ambiente Pode Enganar Usuários Experientes

A AWS CLI não lê apenas ~/.aws/credentials. Ela percorre uma cadeia de provedores de credenciais que pode incluir flags de linha de comando, variáveis de ambiente, perfis nomeados, entradas de cache SSO, tokens de identidade da web, metadados EC2 ou ECS e suposições de função configuradas no perfil. É por isso que aws configure list é mais útil do que abrir um único arquivo.

Uma falha local comum se parece com isso: você executa export AWS_PROFILE=dev, depois cola credenciais de produção temporárias em AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY e AWS_SESSION_TOKEN. As chaves de ambiente podem assumir o controle, então comandos que parecem usar dev estão na verdade usando a sessão exportada. Em um terminal que ficou aberto o dia todo, execute:

env | sort | grep '^AWS_'

Se você estiver alternando contas com frequência, use abas de terminal separadas, um auxiliar de credenciais ou scripts wrapper que imprimam a identidade do chamador antes de comandos destrutivos. A linha extra na saída é mais barata do que excluir da conta errada.

4. Resumo dos Comandos de Diagnóstico

Use esta lista de verificação de comandos para diagnosticar rapidamente a cadeia de falhas de autorização:

Objetivo	Comando	Propósito
Verificar Identidade	`aws sts get-caller-identity`	Confirma o ARN que está executando o comando.
Verificar Configuração	`aws configure list`	Verifica as configurações do perfil, região e formato de saída.
Testar Validade da Política	(Use o Simulador de Políticas IAM)	Verifica se uma identidade IAM pode executar uma ação de API específica em um recurso.
Identificar Negações de Política	`aws cloudtrail lookup-events ...`	Use o CloudTrail para ver o registro de evento exato onde a avaliação da política falhou.

Um Caminho de Depuração Real

Uma boa primeira passagem se parece com isso. Execute o comando com falha novamente com o perfil e a região escritos explicitamente, mesmo se você achar que seu shell já está configurado:

AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly

Se a identidade estiver errada, pare aí. Verifique AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE e AWS_REGION no ambiente. As credenciais de ambiente podem ter precedência sobre um perfil e fazer a CLI agir como uma função que você esqueceu que exportou anteriormente. Em CI, imprima aws sts get-caller-identity perto da etapa com falha para que o log de construção prove a função usada em tempo de execução.

Se a identidade estiver correta, anote a ação exata da API. Comandos de alto nível podem ocultar isso. aws s3 cp pode precisar de s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt ou kms:GenerateDataKey dependendo da direção, criptografia e se a CLI deve inspecionar o bucket. Quando a mensagem de erro inclui AccessDenied mas não a ação, o CloudTrail geralmente fornece o nome do evento e o recurso.

Para S3, verifique a política do bucket, a propriedade do objeto, as configurações de bloqueio de acesso público, a política do endpoint VPC e a política da chave KMS. Para objetos criptografados por KMS, uma permissão S3 não é suficiente; o chamador também precisa da permissão KMS relevante e a política da chave deve permitir o caminho do principal. Para organizações, verifique as SCPs antes de editar as políticas de identidade. Uma SCP não pode conceder acesso, mas pode limitar o que qualquer principal na conta pode fazer.

A prevenção é principalmente uma higiene básica: credenciais de função de curta duração, perfis claramente nomeados, políticas de privilégio mínimo testadas contra o ARN real e CloudTrail habilitado onde os engenheiros possam realmente consultá-lo. A melhor correção não é um Action: "*" mais amplo; é encontrar a ação ausente ou a condição de negação que corresponde à solicitação.