Como solucionar erros 403 Acesso Negado do Amazon S3?

Resolução

Observação: se você receber erros ao executar comandos da AWS Command Line Interface (AWS CLI), consulte Solução de erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

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

Para ajudar você a determinar problemas ao ler objetos de um bucket público específico do S3, use o documento de automação AWSSupport-Troubleshoots3PublicRead no AWS Systems Manager.

Verifique suas configurações de propriedade de bucket e objeto

Para erros de AccessDenied das solicitações GetObject ou HeadObject, verifique se o objeto e o bucket pertencem ao mesmo proprietário. Além disso, verifique se o proprietário do bucket tem permissões de leitura ou controle total na lista de controle de acesso (ACL).

Observação: Quando você cria um novo bucket, as ACLs são desativadas por padrão. É uma prática recomendada usar políticas do AWS Identity and Access Management (AWS IAM) em vez de ACLs para controlar o acesso aos seus recursos do S3.

Confirmar a conta que possui os objetos

Por padrão, a conta da AWS que possui o bucket em que o objeto está armazenado também é proprietária do objeto. Se outras contas puderem carregar objetos no seu bucket, verifique a permissão dos objetos que seus usuários não podem acessar.

Para verificar se o bucket e o objeto têm o mesmo proprietário, conclua as seguintes etapas:

1. Execute o comando list-buckets da AWS CLI para obter o ID canônico do Amazon S3 para sua conta:

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

2. Execute o comando list-objects para obter o ID canônico do Amazon S3 da conta que possui o objeto que seus usuários não conseguem acessar:

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

   Observação: Substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket e exampleprefix pelo valor do seu prefixo. Você pode usar o comando list-objects para verificar vários objetos ao mesmo tempo.

3. Se os IDs canônicos não corresponderem, você não é o proprietário do objeto. O proprietário do objeto pode rodar o comando put-object-acl para conceder a você o controle total do objeto:

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

   Observação: Substitua DOC-EXAMPLE-BUCKET pelo nome do bucket que contém os objetos e exampleobject.jpg pelo nome da chave.

4. Depois que o proprietário do objeto alterar a ACL do objeto para bucket-owner-full-control, o proprietário do bucket poderá acessar o objeto. Para também alterar o proprietário do objeto para a conta do bucket, execute o comando cp na conta do bucket para copiar o objeto sobre si mesmo.

Criar um perfil do IAM com permissões para o seu bucket

Se o perfil do IAM e o proprietário do bucket pertencerem à mesma conta, o perfil do IAM ou o bucket precisarão ter permissões. Você não precisa de permissões no perfil do IAM e no bucket.

Para adicionar permissões em contas diferentes, crie um perfil do IAM em sua conta com permissões para seu bucket. Depois, conceda a outra conta a permissão para assumir o perfil do IAM. Para mais informações, consulte Tutorial do IAM: Delegar acesso entre contas da AWS usando perfis do IAM.

Verifique sua política do bucket ou as políticas de usuário do IAM

Analise a política do bucket ou as políticas de usuário do IAM associadas em busca de declarações que possam negar acesso. Verifique se as solicitações para o bucket atendem as condições de sua política do bucket ou das políticas do IAM. Verifique se há declarações de Negação incorretas, ações ausentes ou erros de digitação em uma política.

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

Verifique as declarações de Negação em busca de condições que bloqueiam o acesso com base no seguinte:

• Autenticação multifator (MFA)
• Chaves de criptografia
• Endereço IP específico
• Nuvens virtuais privadas (VPCs) ou endpoints de VPC específicos
• Usuários ou perfis específicos do IAM

Observação: se você precisar que a MFA e os usuários usem a AWS CLI para enviar solicitações, certifique-se de que seus usuários configurem a AWS CLI para usar a MFA.

Por exemplo, na política do bucket a seguir, o Statement1 permite acesso público para baixar objetos (s3:GetObject) do DOC-EXAMPLE-BUCKET. No entanto, o Statement2 nega explicitamente a todos o acesso para baixar objetos do DOC-EXAMPLE-BUCKET, a menos que a solicitação seja do endpoint da VPC vpce-1a2b3c4d. Como as declarações de Negação têm prioridade sobre as instruções de Permissão, os usuários que tentam baixar objetos de fora do vpce-1a2b3c4d não têm acesso.

{  
  "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ítica de bucket ou políticas de IAM

Confira se a política do bucket ou as políticas do IAM permitem as ações do Amazon S3 que os usuários precisam realizar. Por exemplo, a política do bucket a seguir não inclui permissão para a ação s3:PutObjectAcl.

{  
  "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"  
        ]  
      }  
    }  
  ]  
}

Se o usuário do IAM tentar modificar a ACL de um objeto, ele receberá um erro de Acesso negado.

Outros erros de política

Verifique se há espaços extras, um ARN incorreto ou outros erros de digitação na política de bucket ou nas políticas de usuário do IAM.

Se uma política do IAM tiver um espaço extra no ARN, o ARN será avaliado incorretamente e o usuário receberá um erro de Acesso negado. Por exemplo, uma política do IAM que tem um espaço extra no ARN: arn:aws:s3::: DOC-EXAMPLE-BUCKET/* é avaliado como arn:aws:s3:::%20DOC-EXAMPLE-BUCKET/.

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

Confirme se os limites de permissões do IAM definidos nas entidades do IAM permitem o acesso ao Amazon S3.

Verifique as configurações do Bloqueio de Acesso Público do Amazon S3 do seu bucket

Se você receber erros de Acesso negado em solicitações de leitura públicas permitidas, verifique as configurações de bloqueio de acesso público do Amazon S3 do bucket na conta e no bucket. Essas configurações podem substituir as permissões que permitem o acesso público de leitura.

Examinar as credenciais do usuário

Examine as credenciais que seus usuários configuraram para acessar o Amazon S3. Os usuários devem configurar os SDKs da AWS e a AWS CLI para usar as credenciais da identidade do IAM que tem acesso ao seu bucket.

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

aws configure list

Se seus usuários utilizam uma instância do Amazon Elastic Compute Cloud (Amazon EC2) para acessar seu bucket, verifique se a instância usa o perfil correto. Conecte-se à instância e execute o comando get-caller-identity:

aws sts get-caller-identity

Examinar as credenciais de segurança temporárias

Se seus usuários receberem erros de Acesso negado de credenciais de segurança temporárias que o AWS Security Token Service (AWS STS) concedeu, examine a política de sessão associada. Quando um administrador usa a chamada de API AssumeRole ou o comando assume-role para criar credenciais de segurança temporárias, o administrador pode transmitir políticas específicas da sessão.

Para encontrar as políticas de sessão associadas, encontre os eventos AssumeRole no histórico de eventos do AWS CloudTrail no mesmo período das solicitações de acesso com falha. Em seguida, examine o campo requestParameters nos logs do CloudTrail para ver se há parâmetros política ou policyArns. Confirme se a política associada ou o ARN da política concede as permissões necessárias do Amazon S3.

Por exemplo, o seguinte trecho 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 ao DOC-EXAMPLE-BUCKET:

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

Confirme se a política de endpoint da Amazon VPC tem as permissões corretas para acessar seus recursos do S3

Se seus usuários usarem uma instância do EC2 que é roteada por meio de um endpoint da Amazon Virtual Private Cloud (Amazon VPC) para acessar seu bucket, verifique a política de endpoint da VPC.

Por exemplo, a seguinte política de endpoint da VPC permite acesso somente a DOC-EXAMPLE-BUCKET. Os usuários que usam o endpoint da VPC para enviar solicitações não podem acessar nenhum outro bucket:

{  
  "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": "*"  
    }  
  ]  
}

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

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

As permissões que você concede em uma política de ponto de acesso são efetivas somente quando a política de bucket associada também permite o mesmo acesso. Confirme se tanto a política do bucket quanto a política do ponto de acesso concedem as permissões corretas.

Confirme se o objeto está no bucket e se o nome do objeto não contém caracteres especiais

Verifique se o objeto solicitado está no bucket. Caso contrário, a solicitação não encontrará o objeto e o Amazon S3 presumirá que o objeto não existe. Se você não tiver permissões s3:ListBucket, você receberá um erro de Acesso negado em vez de um erro 404 Não Encontrado.

Observação: Há um procedimento diferente para recuperar objetos que tenham caracteres especiais em seus nomes.

Execute o comando head-object da AWS CLI para verificar um objeto está no bucket:

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

Observação: substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket.

Se o objeto estiver no bucket, o erro de Acesso negado não mascara o erro 404 Não Encontrado. Verifique outros requisitos de configuração para resolver o erro de Acesso negado.

Se o objeto não estiver no bucket, o erro de Acesso negado mascara o erro 404 Não Encontrado. Solucione o problema relacionado ao objeto ausente.

Verificar a configuração de criptografia do AWS KMS

Se um usuário do IAM tiver permissões completas para um objeto, mas ainda não conseguir acessá-lo, verifique se o objeto tem criptografia do AWS Key Management Service (AWS KMS) (SSE-KMS). Você pode usar o console do Amazon S3 para visualizar as propriedades do objeto e verificar as informações de SSE-KMS do objeto.

Se o objeto for criptografado com uma chave gerenciada pelo cliente, a política de chaves do KMS deverá permitir que você execute a ação kms:GenerateDataKey ou kms:Decrypt. Para obter mais informações, consulte Permite o acesso à conta AWS e ativa as políticas do IAM.

Se o usuário do IAM pertencer a uma conta diferente da chave do AWS KMS, modifique a política do IAM para conceder a permissão Kms:Decrypt. Por exemplo, para baixar os objetos do SSE-KMS, você deve especificar a permissão kms:Decrypt 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 do KMS, consulte Permitir que usuários de outras contas usem uma chave KMS.

Para buckets ativados com Requester Pays, confirme se os usuários especificaram o parâmetro request-payer

Se você ativou o Requester Pays no bucket, então os usuários de outras contas deverão especificar o parâmetro request-payer ao enviarem solicitações para o bucket. Para confirmar se você ativou o Requester Pays, use o console do Amazon S3 para visualizar as propriedades do seu bucket.

O seguinte exemplo de comando da AWS CLI inclui o parâmetro correto para acessar um bucket entre contas que possuem o Requester Pays:

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

Verifique suas SCPs do AWS Organizations

Se você utiliza o AWS Organizations, verifique as políticas de controle de serviço (SCPs) para ter certeza de que o acesso ao Amazon S3 está permitido. As SCPs especificam as permissões máximas para as contas afetadas. Por exemplo, a SCP a seguir nega explicitamente o acesso ao Amazon S3 e resulta em um erro de Acesso negado:

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

Para obter mais informações sobre os recursos do AWS Organizations, consulte Habilitar todos os recursos para uma organização com o AWS Organizations.

Informações relacionadas

Solucione erros de acesso negado (403 proibidos) no Amazon S3

Obter IDs de solicitação do Amazon S3 para o AWS Support