Solucionar erros de acesso negado (403 proibido) no Amazon S3 - Amazon Simple Storage Service

Solucionar erros de acesso negado (403 proibido) no Amazon S3

Importante

Em 13 de maio de 2024, começamos a implantar uma alteração para eliminar cobranças por solicitações não autorizadas que não foram iniciadas pelo proprietário do bucket. Depois que a implantação dessa alteração for concluída, os proprietários do bucket nunca incorrerão em cobranças de solicitação ou largura de banda para solicitações que retornem erros AccessDenied (HTTP 403 Forbidden) quando forem iniciadas de fora de sua conta da AWS individual ou de organização da AWS. Consulte uma lista completa de códigos de status HTTP 3XX e 4XX que não serão cobrados em Cobrança pelas respostas de erro do Amazon S3. Essa alteração de cobrança não exige atualizações nas aplicações e é destinada a todos os buckets do S3. Quando a implantação dessa alteração for concluída em todas as Regiões da AWS, atualizaremos nossa documentação.

Os tópicos a seguir abordam as causas mais comuns dos erros de acesso negado (403 proibido) no Amazon S3.

nota

Para Access Denied (HTTP 403 Forbidden), o S3 não cobra do proprietário do bucket quando a solicitação é iniciada fora da conta da AWS individual dele ou da organização da AWS à qual ele pertence.

nota

Se você estiver tentando solucionar um problema de permissões, comece com a seção Políticas de bucket e políticas do IAM e siga as orientações em Dicas para verificar permissões.

Políticas de bucket e políticas do IAM

Operações no nível do bucket

Se não houver uma política de bucket em vigor, o bucket permitirá implicitamente solicitações de qualquer identidade do AWS Identity and Access Management (IAM) na conta proprietária do bucket. O bucket também nega implicitamente solicitações de qualquer outra identidade do IAM de qualquer outra conta e solicitações anônimas (não assinadas). No entanto, se não houver uma política de usuário do IAM em vigor, o solicitante (a menos que seja o usuário raiz) será implicitamente impedido de fazer qualquer solicitação. Para obter mais informações sobre essa lógica de avaliação, consulte Determinar se uma solicitação é negada ou permitida em uma conta no Guia do usuário do IAM.

Operações no nível do objeto

Se o objeto pertencer à conta proprietária do bucket, a política de bucket e a política de usuário do IAM funcionarão da mesma forma para operações no nível do objeto e para operações no nível do bucket. Por exemplo, se não houver uma política de bucket em vigor, o bucket permitirá implicitamente solicitações de objeto de qualquer identidade do IAM na conta proprietária do bucket. O bucket também nega implicitamente solicitações de objeto de qualquer outra identidade do IAM de qualquer outra conta e solicitações anônimas (não assinadas). No entanto, se não houver uma política de usuário do IAM em vigor, o solicitante (a menos que seja o usuário raiz) será implicitamente impedido de fazer qualquer solicitação de objeto.

Se o objeto pertencer a uma conta externa, o acesso ao objeto só poderá ser concedido por meio de listas de controle de acesso (ACLs) do objeto. A política de bucket e a política de usuário do IAM ainda podem ser usadas para negar solicitações de objeto.

Portanto, para garantir que a política de bucket ou a política de usuário do IAM não esteja causando um erro de acesso negado (403 proibido), verifique se os seguintes requisitos são atendidos:

  • Para acesso à mesma conta, não deve haver uma declaração Deny explícita contra o solicitante ao qual você está tentando conceder permissões, seja na política de bucket ou na política de usuário do IAM. Se você quiser conceder permissões usando somente a política de bucket e a política de usuário do IAM, deve haver pelo menos uma declaração Allow explícita em uma dessas políticas.

  • Para acesso entre contas, não deve haver uma declaração Deny explícita contra o solicitante ao qual você está tentando conceder permissões, seja na política de bucket ou na política de usuário do IAM. Se você quiser conceder permissões entre contas usando somente a política de bucket e a política de usuário do IAM, ambas as políticas do solicitante devem incluir uma declaração Allow explícita.

nota

As declarações Allow em uma política de bucket se aplicam somente a objetos que pertencem à mesma conta proprietária do bucket. No entanto, as declarações Deny em uma política de bucket se aplicam a todos os objetos, independentemente da propriedade dele.

Para revisar ou editar a política de bucket
nota

Para visualizar ou editar uma política de bucket, é necessário ter a permissão s3:GetBucketPolicy.

  1. Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.

  2. No painel de navegação à esquerda, escolha Buckets.

  3. Na lista Buckets, escolha o nome do bucket para o qual você deseja visualizar ou editar uma política de bucket.

  4. Escolha a aba Permissões.

  5. Em Bucket policy (Política de bucket), escolha Edit (Editar). A página Edit bucket policy (Editar política de bucket) é exibida.

Para revisar ou editar a política de bucket usando a AWS Command Line Interface (AWS CLI), use o comando get-bucket-policy.

nota

Se você for bloqueado de um bucket devido a uma política de bucket incorreta, faça login no AWS Management Console usando as credenciais de usuário raiz. Para recuperar o acesso ao bucket, exclua a política de bucket usando as credenciais de usuário raiz.

Dicas para verificar permissões

Para verificar se o solicitante tem as permissões adequadas para realizar uma operação do Amazon S3, tente o seguinte:

Configurações de ACL do Amazon S3

Ao verificar as configurações de ACL, primeiro revise a configuração de propriedade de objetos para verificar se as ACLs estão ativadas no bucket. Esteja ciente de que as permissões de ACL podem ser usadas somente para conceder permissões e não podem ser usadas para rejeitar solicitações. As ACLs também não podem ser usadas para conceder acesso a solicitantes que são rejeitados por negações explícitas nas políticas de bucket ou nas políticas de usuário do IAM.

A configuração de propriedade de objetos está definida como o proprietário do bucket aplicado

Se a configuração de proprietário do bucket aplicado estiver ativada, é improvável que as configurações de ACL causem um erro de acesso negado (403 proibido), pois essa configuração desativa todas as ACLs que se aplicam ao bucket e aos objetos. O proprietário de bucket aplicado é a configuração padrão (e recomendada) para os buckets do Amazon S3.

A configuração de propriedade de objetos está definida como o proprietário de bucket de preferência ou o gravador de objetos

As permissões de ACL ainda são válidas com a configuração do proprietário de bucket de preferência ou com a configuração do gravador de objetos. Há dois tipos de ACLs: ACLs de bucket e ACLs de objeto. Para ver as diferenças entre esses dois tipos de ACLs, consulte Mapeamento das permissões da ACL e das permissões da política de acesso.

Dependendo da ação da solicitação rejeitada, verifique as permissões de ACL para o bucket ou objeto:

  • Se o Amazon S3 rejeitou uma LIST, um objeto PUT, GetBucketAcl ou uma solicitação PutBucketAcl, revise as permissões de ACL para o bucket.

    nota

    Você não pode conceder permissões de objeto GET com as configurações de ACL do bucket.

  • Se o Amazon S3 rejeitou uma solicitação GET em um objeto do S3 ou uma solicitação PutObjectAcl, revise as permissões de ACL para o objeto.

    Importante

    Se a conta da que possui o objeto for diferente da conta da que possui o bucket, o acesso ao objeto não será controlado pela política de bucket.

Solução de problemas de um erro de acesso negado (403 proibido) de uma solicitação de objeto GET durante a propriedade de objetos entre contas

Examine as configurações de propriedade de objetos do bucket para determinar o proprietário do objeto. Se você tiver acesso às ACLs do objeto, também poderá verificar a conta do proprietário do objeto. (Para visualizar a conta do proprietário do objeto, revise a configuração da ACL do objeto no console do Amazon S3.) Como alternativa, você também pode fazer uma solicitação GetObjectAcl a fim de encontrar a ID canônica do proprietário do objeto para verificar a conta do proprietário do objeto. Por padrão, as ACLs concedem permissões explícitas para solicitações GET à conta do proprietário do objeto.

Depois de confirmar que o proprietário do objeto é diferente do proprietário do bucket, dependendo do caso de uso e nível de acesso, escolha um dos seguintes métodos para ajudar a resolver o erro Acesso negado (403 proibido):

  • Desative as ACLs (recomendado): esse método se aplicará a todos os objetos e poderá ser executado pelo proprietário do bucket. Esse método concede automaticamente ao proprietário do bucket propriedade e controle total de todos os objetos do bucket. Antes de implementar esse método, verifique os pré-requisitos para desativar as ACLs. Para obter informações sobre como configurar o bucket no modo proprietário do bucket aplicado (recomendado), consulte Configurar Object Ownership em um bucket existente.

    Importante

    Para evitar um erro de acesso negado (403 proibido), migre as permissões da ACL para uma política de bucket antes de desativar as ACLs. Para obter mais informações, consulte Exemplos de políticas de bucket para migrar de permissões de ACL.

  • Altere o proprietário do objeto para o proprietário do bucket: esse método pode ser aplicado a objetos individuais, mas somente o proprietário do objeto (ou um usuário com as permissões apropriadas) pode alterar a propriedade de um objeto. Custos adicionais de PUT podem ser aplicados. (Para obter mais informações, consulte Preço do Amazon S3.) Esse método concede ao proprietário do bucket a propriedade total do objeto, permitindo que ele controle o acesso ao objeto por meio de uma política de bucket.

    Para alterar a propriedade do objeto, siga um destes procedimentos:

    • Você (o proprietário do bucket) pode copiar o objeto de volta para o bucket.

    • É possível alterar a configuração de propriedade de objetos do bucket para a configuração de preferência do proprietário do bucket. Se o versionamento estiver desativado, os objetos no bucket serão substituídos. Se o versionamento estiver ativado, versões duplicadas do mesmo objeto aparecerão no bucket, e o proprietário do bucket poderá definir uma regra de ciclo de vida para expirar. Para obter instruções sobre como alterar a configuração de propriedade de objetos, consulte Configurar Object Ownership em um bucket existente.

      nota

      Quando você atualiza a configuração de propriedade de objetos para a de preferência do proprietário do bucket, a configuração só é aplicada a novos objetos que são enviados ao bucket.

    • É possível fazer com que o proprietário do objeto carregue o objeto novamente com a ACL bucket-owner-full-control do objeto predefinido.

    nota

    Para uploads entre contas, você também pode exigir a ACL bucket-owner-full-control do objeto predefinido na política de bucket. Para obter um exemplo de política de bucket, consulte Conceder permissões entre contas para fazer upload de objetos garantindo que o proprietário do bucket tenha controle total.

  • Mantenha o gravador do objeto como proprietário do objeto: esse método não altera o proprietário do objeto, mas permite que você conceda acesso aos objetos individualmente. Para conceder acesso a um objeto, você deve ter a permissão PutObjectAcl para o objeto. Depois, para corrigir o erro Acesso negado (403 proibido), adicione o solicitante como beneficiário para acessar o objeto nas ACLs do objeto. Para ter mais informações, consulte Configurar ACLs.

Configurações do bloqueio de acesso público do S3

Se a solicitação com falha envolver acesso público ou políticas públicas, verifique as configurações do bloqueio de acesso público do S3 na conta, no bucket ou no ponto de acesso do S3. A partir de abril de 2023, todas as configurações de bloqueio de acesso público são habilitadas por padrão para novos buckets. Para obter mais informações sobre como o Amazon S3 define “público”, consulte O significado de "público".

Quando definidas como TRUE, as configurações do bloqueio de acesso público atuam como políticas de negação explícitas que substituem as permissões por ACLs, políticas de bucket e políticas de usuário do IAM. Para determinar se as configurações de bloqueio de acesso público estão rejeitando sua solicitação, analise os seguintes cenários:

  • Se a lista de controle de acesso (ACL) especificada for pública, a configuração BlockPublicAcls rejeitará as chamadas PutBucketAcl e PutObjectACL.

  • Se a solicitação incluir uma ACL pública, a configuração BlockPublicAcls rejeitará as chamadas PutObject.

  • Se a configuração BlockPublicAcls for aplicada a uma conta e a solicitação incluir uma ACL pública, todas as chamadas CreateBucket que incluírem ACLs públicas falharão.

  • Se a permissão da solicitação for concedida somente por uma ACL pública, a configuração IgnorePublicAcls rejeitará a solicitação.

  • Se a política de bucket especificada permitir acesso público, a configuração BlockPublicPolicy rejeitará as chamadas PutBucketPolicy.

  • Se a configuração BlockPublicPolicy for aplicada a um ponto de acesso, todas as chamadas PutAccessPointPolicy e PutBucketPolicy que especificam uma política pública e são feitas por meio do ponto de acesso falharão.

  • Se o ponto de acesso ou i bucket tiver uma política pública, a configuração RestrictPublicBuckets rejeitará todas as chamadas entre contas, exceto para entidades principais do AWS service (Serviço da AWS). Essa configuração também rejeita todas as chamadas anônimas (ou não assinadas).

Para revisar e atualizar as configurações de bloqueio de acesso público, consulte Configurar o bloqueio de acesso público para seus buckets do S3.

Configurações de criptografia do Amazon S3

O Amazon S3 é compatível com a criptografia do lado do servidor no bucket. A criptografia do lado do servidor é a criptografia de dados em seu destino pela aplicação ou serviço que os recebe. O Amazon S3 criptografa os dados no nível do objeto no momento em que os grava em discos nos datacenters da AWS e descriptografa-os quando você os acessa.

Por padrão, o Amazon S3 agora aplica a criptografia do lado do servidor com chaves gerenciadas pelo Amazon S3 (SSE-S3) como nível básico de criptografia para cada bucket no Amazon S3. O Amazon S3 também permite que você especifique o método de criptografia do lado do servidor ao fazer upload de objetos.

Para revisar as configurações de criptografia e o status da criptografia do lado do servidor do bucket
  1. Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.

  2. No painel de navegação à esquerda, escolha Buckets.

  3. Na lista Buckets, escolha o bucket para o qual você deseja verificar as configurações de criptografia.

  4. Escolha a guia Properties (Propriedades).

  5. Role para baixo até a seção Criptografia padrão e veja as configurações de Tipo de criptografia.

Para verificar as configurações de criptografia usando a AWS CLI, use o comando get-bucket-encryption.

Para verificar o status de criptografia de um objeto
  1. Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.

  2. No painel de navegação à esquerda, escolha Buckets.

  3. Na lista Buckets, escolha o nome do bucket que contém o objeto.

  4. Na lista Objetos, escolha o nome do objeto ao qual você deseja adicionar ou no qual deseja alterar a criptografia.

    A página de detalhes do objeto é exibida.

  5. Role para baixo até a seção Configurações de criptografia do lado do servidor para ver as configurações de criptografia do lado do servidor do objeto.

Para verificar o status de criptografia do objeto usando a AWS CLI, use o comando head-object.

Requisitos de permissões e criptografia

O Amazon S3 agora é compatível com três tipos de criptografia do lado do servidor.

  • Criptografia do lado do servidor com chaves gerenciadas pelo Amazon S3 (SSE-S3)

  • Criptografia no lado do servidor com chaves do AWS Key Management Service (AWS KMS) (SSE-KMS)

  • Criptografia do lado do servidor com chaves fornecidas pelo cliente (SSE-C)

Com base nas configurações de criptografia, verifique se os seguintes requisitos de permissões são atendidos:

  • SSE-S3: nenhuma permissão extra é necessária.

  • SSE-KMS (com uma chave gerenciada pelo cliente): para fazer upload de objetos, é necessária a permissão kms:GenerateDataKey no AWS KMS key. Para baixar objetos e fazer uploads de objetos em várias partes, é necessária a permissão kms:Decrypt na chave do KMS.

  • SSE-KMS (com um Chave gerenciada pela AWS): o solicitante deve ser da mesma conta que possui a chave do KMS aws/s3. O solicitante também deve ter as permissões corretas do Amazon S3 para acessar o objeto.

  • SSE-C (com uma chave fornecida pelo cliente): nenhuma permissão adicional é necessária. É possível configurar a política de bucket para exigir e restringir a criptografia do lado do servidor com chaves de criptografia fornecidas pelo cliente para objetos no bucket.

Se o objeto estiver criptografado com uma chave gerenciada pelo cliente, certifique-se de que a política de chaves do KMS permita que você realize as ações kms:GenerateDataKey ou kms:Decrypt. Para obter instruções sobre como verificar a política de chaves do KMS, consulte Visualizar uma política de chaves no Guia do desenvolvedor do AWS Key Management Service.

Configurações do bloqueio de objetos do S3

Se o bucket tiver o bloqueio de objetos do S3 ativado e o objeto estiver protegido por um período de retenção ou uma retenção legal, o Amazon S3 retornará um erro de acesso negado (403 proibido) quando você tentar excluir o objeto.

Para verificar se o bucket tem o bloqueio de objetos ativado
  1. Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/.

  2. No painel de navegação à esquerda, escolha Buckets.

  3. Na lista Buckets, escolha o nome do bucket que deseja revisar.

  4. Escolha a guia Properties (Propriedades).

  5. Role para baixo até a seção Bloqueio de objetos. Verifique se a configuração de Bloqueio de objetos está Ativada ou Desativada.

Para determinar se o objeto está protegido por um período de retenção ou uma retenção legal, veja as informações de bloqueio do objeto.

Se o objeto estiver protegido por um período de retenção ou uma retenção legal, verifique o seguinte:

  • Se a versão do objeto estiver protegida pelo modo de retenção de conformidade, não há como excluí-lo permanentemente. Uma solicitação DELETE permanente de qualquer solicitante, incluindo o usuário raiz, resultará em um erro de Acesso negado (403 proibido). Além disso, lembre-se de que quando você envia uma solicitação DELETE para um objeto protegido pelo modo de retenção de conformidade, o Amazon S3 cria um marcador de exclusão para o objeto.

  • Se a versão do objeto estiver protegida com o modo de retenção de governança e você tiver a permissão s3:BypassGovernanceRetention, poderá ignorar a proteção e excluir permanentemente a versão. Para obter mais informações, consulte Ignorar modo de governança.

  • Se a versão do objeto estiver protegida por uma retenção legal, uma solicitação DELETE permanente poderá resultar em um erro de Acesso negado (403 proibido). Para excluir permanentemente a versão do objeto, é necessário remover a retenção legal da versão do objeto. Para remover uma retenção legal, você deve ter a permissão s3:PutObjectLegalHold. Para obter mais informações como remover uma retenção legal, consulte Configurar a funcionalidade Bloqueio de Objetos do S3.

Política de endpoint da VPC

Se você estiver acessando o Amazon S3 usando um endpoint da nuvem privada virtual (VPC), verifique se a política de endpoint da VPC não está impedindo que você acesse os recursos do Amazon S3. Por padrão, a política de endpoint da VPC permite todas as solicitações ao Amazon S3. Também é possível configurar a política de endpoint da VPC para restringir determinadas solicitações. Para obter informações sobre como verificar a política de endpoint da VPC, consulte Controlar o acesso a endpoints da VPC usando políticas de endpoint no Guia do AWS PrivateLink.

Políticas do AWS Organizations

Se a sua Conta da AWS pertence a uma organização, as políticas do AWS Organizations podem impedir que você acesse os recursos do Amazon S3. Por padrão, as políticas do AWS Organizations não bloqueiam nenhuma solicitação ao Amazon S3. No entanto, verifique se as suas políticas do AWS Organizations não foram configuradas para bloquear o acesso aos buckets do S3. Para obter instruções sobre como verificar as políticas do AWS Organizations, consulte Listar todas as políticas no Guia do usuário do AWS Organizations.

Configurações do ponto de acesso

Se você receber um erro de acesso negado (403 proibido) ao fazer solicitações por meio de Pontos de Acesso Amazon S3, talvez seja necessário verificar o seguinte:

  • As configurações dos pontos de acesso

  • A política de usuário do IAM usada para os pontos de acesso

  • A política de bucket usada para gerenciar ou configurar os pontos de acesso entre contas

Políticas e configurações de pontos de acesso
  • Ao criar um ponto de acesso, é possível designar Internet ou VPC como a origem da rede. Se a origem da rede for definida somente como VPC, o Amazon S3 rejeitará todas as solicitações feitas ao ponto de acesso que não sejam originadas da VPC especificada. Para verificar a origem da rede do ponto de acesso, consulte Criar pontos de acesso restritos a uma nuvem privada virtual.

  • Com os pontos de acesso, você também pode definir configurações personalizadas do bloqueio de acesso público, que funcionam de forma semelhante às configurações desse recurso no nível do bucket ou da conta. Para verificar as configurações personalizadas do bloqueio de acesso público, consulte Gerenciar o acesso público a pontos de acesso.

  • Para fazer solicitações bem-sucedidas ao Amazon S3 usando pontos de acesso, o solicitante deve ter as permissões necessárias do IAM. Para ter mais informações, consulte Configurar políticas do IAM para uso de pontos de acesso.

  • Se a solicitação envolver pontos de acesso entre contas, o proprietário do bucket deve ter atualizado a política do bucket para autorizar solicitações do ponto de acesso. Para ter mais informações, consulte Conceder permissões para pontos de acesso entre contas.

Se o erro Acesso negado (403 proibido) persistir depois de verificar todos os itens neste tópico, recupere seu ID de solicitação do Amazon S3 e entre em contato com o AWS Support para obter mais orientações.