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.
Tópicos
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çãoAllow
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çãoAllow
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
.
Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/
. -
No painel de navegação à esquerda, escolha Buckets.
-
Na lista Buckets, escolha o nome do bucket para o qual você deseja visualizar ou editar uma política de bucket.
-
Escolha a aba Permissões.
-
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:
-
Identifique o solicitante. Se for uma solicitação não assinada, será uma solicitação anônima sem uma política de usuário do IAM. Se for uma solicitação usando um URL pré-assinado, a política do usuário será a mesma do perfil ou usuário do IAM que assinou a solicitação.
-
Verifique se você está usando o perfil ou usuário do IAM correto. É possível verificar o perfil ou usuário do IAM no canto superior direito doAWS Management Console ou usando o comando aws sts get-caller-identity.
-
Verifique as políticas do IAM relacionadas ao perfil ou usuário do IAM. É possível usar um dos seguintes métodos:
-
Testar as políticas do IAM com o simulador de políticas do IAM
-
Analise os diferentes tipos de política do IAM.
-
-
Se necessário, edite a política de usuário do IAM.
-
Veja os seguintes exemplos de políticas que negam ou permitem explicitamente o acesso:
-
Política de usuário do IAM de permissão explícita: IAM: permite e nega acesso a vários serviços de forma programática e no console
-
Política de bucket de permissão explícita: Conceder permissões a várias contas para fazer upload de objetos ou definir ACLs de objetos para acesso público
-
Política de usuário do IAM de negação explícita: AWS: negar acesso àAWS com base na Região da AWS solicitada
-
Política de bucket de negação explícita: Exigir SSE-KMS para todos os objetos gravados em um bucket
-
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 objetoPUT
,GetBucketAcl
ou uma solicitaçãoPutBucketAcl
, 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 chamadasPutBucketAcl
ePutObjectACL
. -
Se a solicitação incluir uma ACL pública, a configuração
BlockPublicAcls
rejeitará as chamadasPutObject
. -
Se a configuração
BlockPublicAcls
for aplicada a uma conta e a solicitação incluir uma ACL pública, todas as chamadasCreateBucket
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 chamadasPutBucketPolicy
. -
Se a configuração
BlockPublicPolicy
for aplicada a um ponto de acesso, todas as chamadasPutAccessPointPolicy
ePutBucketPolicy
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
Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/
. -
No painel de navegação à esquerda, escolha Buckets.
-
Na lista Buckets, escolha o bucket para o qual você deseja verificar as configurações de criptografia.
-
Escolha a guia Properties (Propriedades).
-
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
Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/
. -
No painel de navegação à esquerda, escolha Buckets.
-
Na lista Buckets, escolha o nome do bucket que contém o objeto.
-
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.
-
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ãokms: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
Faça login no AWS Management Console e abra o console do Amazon S3 em https://console.aws.amazon.com/s3/
. -
No painel de navegação à esquerda, escolha Buckets.
-
Na lista Buckets, escolha o nome do bucket que deseja revisar.
-
Escolha a guia Properties (Propriedades).
-
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çãoDELETE
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ãos3: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.