Como soluciono o erro 403 Access Denied (403 Acesso negado) do Amazon S3?

Data da última atualização: 13/05/2022

Meus usuários estão tentando acessar objetos no meu bucket do Amazon Simple Storage Service (Amazon S3), mas o Amazon S3 está exibindo o erro 403 Access Denied (403 Acesso negado). Como posso solucionar isso?

Resolução

Usar o documento de automação do AWS Systems Manager

Use o documento de automação AWSSupport-TroubleshootS3PublicRead no AWS Systems Manager. Esse documento de automação ajuda a identificar problemas na leitura de objetos de um bucket S3 público que você especifica.

Verificar a propriedade do bucket e do objeto

Para erros de AccessDenied (Acesso negado) para as solicitações GetObject ou HeadObject, confira se o objeto também é propriedade do proprietário do bucket. Além disso, verifique se o proprietário do bucket tem permissões de lista de controle de acesso (ACL) de leitura ou controle total.

Confirmar a conta que possui os objetos

Por padrão, um objeto do S3 pertence à conta da AWS que fez o seu carregamento. Isso vale inclusive para buckets que pertencem a outra conta. Se outras contas puderem carregar objetos no seu bucket, verifique a conta que possui os objetos que seus usuários não podem acessar.

Observação: se você receber erros ao executar comandos da AWS CLI, certifique-se de estar utilizando a versão mais recente da AWS CLI.

1.    Execute o comando list-buckets na AWS Command Line Interface (AWS CLI) para obter o ID canônico do Amazon S3 para sua conta, consultando o ID do proprietário.

aws s3api list-buckets --query "Owner.ID"

2.    Execute o comando list-objects para obter o ID canônico do Amazon S3 da conta proprietária do objeto que os usuários não podem acessar. Substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket e exampleprefix pelo valor do prefixo.

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix

Dica: é possível usar o comando list-objects para verificar vários objetos.

3.    Se os IDs canônicos não corresponderem, você não é o proprietário do objeto. O proprietário do objeto pode conceder a você controle total do objeto executando o comando put-object-acl. Substitua DOC-EXAMPLE-BUCKET pelo nome do bucket que contém os objetos. Substitua exampleobject.jpg pelo nome da sua chave.

aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg --acl bucket-owner-full-control

4.    Depois que o proprietário do objeto alterar a ACL do item para bucket-owner-full-control, o proprietário do bucket poderá acessar o objeto. Porém, a alteração exclusiva da ACL não muda o proprietário do objeto. Para alterar o proprietário do objeto para a conta do bucket, execute o comando cp da conta do bucket para copiar o objeto sobre si mesmo.

Copiar todos os novos objetos para um bucket em outra conta

1.    Defina uma política de bucket que exija que os objetos sejam carregados com a ACL bucket-owner-full-control.

2.    Habilite e defina o S3 Object Ownership como preferência para o proprietário do bucket no Console de Gerenciamento da AWS.

Em seguida, o proprietário do objeto é automaticamente atualizado para o proprietário do bucket quando o objeto é carregado com a ACL bucket-owner-full-control.

Criar uma função do IAM com permissões para o seu bucket

Para permissões contínuas entre contas, crie uma função do IAM na sua conta com permissões para o seu bucket. Depois, conceda a outra conta da AWS a permissão para assumir a função do IAM. Para mais informações, consulte Tutorial: delegue acesso a contas da AWS usando as funções do IAM.

Verificar a política do bucket ou as políticas de usuário do IAM

Analise a política de bucket ou as políticas de usuários do IAM associadas para ver se há instruções que possam estar negando acesso. Verifique se as solicitações feitas ao seu bucket cumprem as condições da política do bucket ou políticas do IAM. Confira se há alguma instrução incorreta de negação, se falta alguma ação ou se o espaçamento na política está errado.

Condições da instrução de negação

Confira as instruções de negação para condições que impedem o acesso com base no seguinte:

  • autenticação multifator (MFA)
  • chaves de criptografia
  • endereço IP específico
  • VPCs ou endpoints da VPC específicos
  • usuários ou funções do IAM específicos

Observação: se você exigir que a MFA e os usuários enviem solicitações por meio da AWS CLI, verifique e confirme se os usuários configuraram a AWS CLI para usar a MFA.

Por exemplo, na política de bucket a seguir, Instrução1 permite acesso público para baixar objetos (s3:GetObject) de DOC-EXAMPLE-BUCKET. Porém, a Instrução2 nega explicitamente a todos o acesso para baixar objetos de DOC-EXAMPLE-BUCKET, a menos que a solicitação venha do endpoint vpce-1a2b3c4d do VPC endpoint. Neste caso, a instrução de negação prevalece. Isso significa que os usuários que tentarem baixar objetos de fora do vpce-1a2b3c4d terão o acesso negado.

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": "*"
    },
    {
      "Sid": "Statement2",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Deny",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-1a2b3c4d"
        }
      },
      "Principal": "*"
    }
  ]
}

Políticas de bucket ou políticas do IAM

Confira se a política do bucket ou as políticas do IAM permitem as ações do Amazon S3 de que os usuários precisam. Por exemplo, a política do bucket a seguir não concede a permissão à ação s3:PutObjectAcl. Se o usuário do IAM tentar modificar a lista de controle de acesso (ACL) de um objeto, ele receberá um erro Access Denied.

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Principal": {
        "AWS": [
          "arn:aws:iam::111122223333:user/Dave"
        ]
      }
    }
  ]
}

Outros erros de política

Confira se não há espaços extras ou ARNs incorretos na política do bucket ou nas políticas de usuários do IAM.

Por exemplo, a política do IAM a seguir tem um espaço extra no nome do recurso da Amazon (ARN), da seguinte maneira: arn:aws:s3::: DOC-EXAMPLE-BUCKET/*. Nesse caso, o ARN é avaliado incorretamente como arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/ e fornece ao usuário do IAM um erro de acesso negado.

Confirmar se os limites de permissão do IAM permitem o acesso ao Amazon S3

Analise os limites de permissões do IAM definidos nas identidades do IAM que estão tentando acessar o bucket. Confirme se os limites de permissão do IAM permitem o acesso ao Amazon S3.

Verificar as configurações de bloqueio de acesso público do Amazon S3 do bucket

Se você estiver recebendo erros de Access Denied (Acesso negado) em solicitações de leitura pública que estão permitidas, confira as configurações do Amazon S3 Block Public Access do bucket.

Analise as configurações do S3 Block Public Access no nível da conta e do bucket. Elas podem prevalecer sobre as permissões que autorizam o acesso público de leitura. As configurações de acesso do Amazon S3 Block Public Access podem ser aplicadas a buckets ou contas individuais da AWS.

Revisar credenciais do usuário

Confira as credenciais que os usuários configuraram para acessar o Amazon S3. Os AWS SDKs e a AWS CLI devem ser configurados para usar as credenciais do usuário ou função do IAM com acesso ao seu bucket.

Para a AWS CLI, execute o comando configure para conferir as credenciais configuradas:

aws configure list

Caso os usuários acessem o bucket por uma instância do Amazon Elastic Compute Cloud (Amazon EC2), verifique se ela está usando a função correta. Conecte-se à instância e execute o comando get-caller-identity:

aws sts get-caller-identity

Revisar credenciais de segurança temporárias

Se os usuários receberem erros de Access Denied (Acesso negado) de credenciais de segurança temporárias concedidas usando o AWS Security Token Service (AWS STS), analise a política de sessão associada. Quando um administrador cria credenciais de segurança temporárias usando a chamada de API AssumeRole ou o comando assume-role, ele pode transmitir políticas específicas da sessão.

Para encontrar as políticas de sessão associadas aos erros de Access Denied (Acesso negado) do Amazon S3, procure os eventos AssumeRole no AWS CloudTrail event history (Histórico de eventos do AWS CloudTrail). Não se esqueça de verificar os eventos AssumeRole no mesmo período das solicitações de acesso ao Amazon S3 que falharam. Depois, confira o campo requestParameters dos logs relevantes do CloudTrail para ver se há alguma política ou parâmetros policyArns. Confirme se a política ou a política associada ARN concede as permissões necessárias do Amazon S3.

Por exemplo, o snippet a seguir de um log do CloudTrail mostra que as credenciais temporárias incluem uma política de sessão em linha que concede permissões s3:GetObject para DOC-EXAMPLE-BUCKET:

"requestParameters": {
        "roleArn": "arn:aws:iam::123412341234:role/S3AdminAccess",
        "roleSessionName": "s3rolesession",
        "policy": "{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n  {\n  \"Effect\": \"Allow\",\n           
         \"Action\": [\n   \"s3:GetObject\"\n ],\n    \"Resource\": [\n \"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*\"\n  ]\n   }  }\n    ]\n}\n"
    }

Confirmar se a política de endpoint da Amazon VPC inclui as permissões corretas para acessar seus buckets e objetos do S3

Se os usuários acessarem seu bucket com uma instância do EC2 roteada por meio de um VPC endpoint, confira a política de endpoint da VPC.

Por exemplo, a seguinte política do endpoint da VPC permite acesso somente ao DOC-EXAMPLE-BUCKET. Os usuários que enviarem solicitações por meio do endpoint da VPC não poderão acessar outros buckets.

{
  "Id": "Policy1234567890123",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1234567890123",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Principal": "*"
    }
  ]
}

Analisar a política de IAM do seu ponto de acesso do Amazon S3

Se você usar um ponto de acesso do Amazon S3 para gerenciar o acesso ao seu bucket, analise a política do IAM do ponto de acesso.

As permissões concedidas em uma política de ponto de acesso só serão efetivas se a política de bucket subjacente também permitir o mesmo acesso. Confirme se a política de bucket e a política de ponto de acesso concedem as permissões corretas.

Confirme se o objeto não está faltando ou contém caracteres especiais

Confirme se o objeto solicitado está no bucket. Caso contrário, a solicitação não identificará o objeto, e o Amazon S3 presumirá que ele não existe. Você receberá um erro Access Denied (em vez de erros 404 Not Found) se não tiver as permissões s3:ListBucket adequadas.

Um objeto que tem um caractere especial (como um espaço) requer tratamento especial para recuperação.

Execute o comando head-object da AWS CLI para verificar se existe um objeto no bucket. Substitua DOC-EXAMPLE-BUCKET pelo nome do bucket que você deseja verificar.

aws s3api head-object --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg

Se o objeto existir no bucket, o erro Access Denied (Acesso negado) não está mascarando um erro 404 Not Found (Não encontrado). Verifique outros requisitos de configuração para resolver o erro Access Denied (Acesso negado).

Caso ele não esteja no bucket, o erro Access Denied não está encobrindo um erro 404 Not Found. Solucione o problema relacionado ao objeto ausente.

Verifique a configuração de criptografia do AWS KMS

Observe o seguinte sobre a criptografia do AWS KMS (SSE-KMS):

  • Caso um usuário do IAM não consiga acessar um objeto ao qual ele tenha todas as permissões, confira se o item está criptografado pelo SSE-KMS. Você pode usar o console do Amazon S3 para visualizar as propriedades do objeto, que incluem as informações de criptografia do lado do servidor do item.
  • Se o objeto for criptografado pelo SSE-KMS, certifique-se de que a política de chaves do KMS conceda ao usuário do IAM as permissões mínimas necessárias para usar a chave. Por exemplo, se o usuário do IAM estiver usando a chave apenas para baixar um objeto do S3, ele deverá ter permissões kms:Decrypt. Para obter mais informações, consulte Permissão de acesso à conta da AWS e habilitação de políticas do IAM.
  • Se a identidade e a chave do IAM estiverem na mesma conta, as permissões kms:Decrypt deverão ser concedidas usando a política de chaves. A política de chaves deve fazer referência à mesma identidade do IAM que a política do IAM.
  • Caso o usuário seja de uma conta diferente da chave do AWS KMS, tais permissões também precisarão ser concedidas na política do IAM. Por exemplo, para baixar os objetos criptografados do SSE-KMS, as permissões kms:Decrypt devem ser especificadas na política de chaves e na política do IAM. Para obter mais informações sobre o acesso entre contas entre o usuário do IAM e a chave KMS, consulte Permissão a usuários em outras contas para usar uma chave do KMS.

Confirme se o parâmetro request-payer é especificado pelos usuários (se você estiver usando Pagamento a cargo do solicitante)

Se o bucket tiver o Pagamento a cargo do solicitante ativado, os usuários de outras contas deverão especificar o parâmetro request-payer quando enviarem solicitações para o bucket. Para conferir se Pagamentos a cargo do solicitante está habilitado, você pode usar o console do Amazon S3 para visualizar as suas propriedades do bucket.

O exemplo a seguir de comando da AWS CLI inclui o parâmetro correto para acessar um bucket entre contas com Requester Pays (Pagamentos a cargo do solicitante):

aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester

Verifique sua política de controle de serviços do AWS Organizations

Se você estiver usando o AWS Organizations, confira as políticas de controle de serviço para ter certeza de que o acesso ao Amazon S3 está permitido. As políticas de controle de serviço especificam as permissões máximas para as contas afetadas. Por exemplo, a política a seguir nega explicitamente o acesso ao Amazon S3 e gera um erro de Access Denied (Acesso negado):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

Para obter mais informações sobre os recursos do AWS Organizations, consulte Habilitação de todos os recursos na sua organização.


Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?