Solucionar erros de acesso negado (403 Forbidden) no Amazon S3 - Amazon Simple Storage Service
Exemplos de mensagens de acesso negado e como solucioná-lasPolíticas de bucket e políticas do IAMConfigurações de ACL do Amazon S3Configurações do bloqueio de acesso público do S3Configurações de criptografia do Amazon S3Configurações do bloqueio de objetos do S3Políticas de VPC endpointPolíticas do AWS OrganizationsConfigurações do ponto de acesso

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

Erros de acesso negado (HTTP 403 Forbidden) são exibidos quando a AWS nega explícita ou implicitamente uma solicitação de autorização.

  • Uma negação explícita ocorre quando uma política contém uma instrução Deny para a ação específica da AWS.

  • Uma negação implícita ocorre quando não há nenhuma instrução Deny aplicável e também nenhuma instrução Allow aplicável.

Como uma política do AWS Identity and Access Management (IAM) nega implicitamente uma entidade principal do IAM por padrão, a política deve permitir explicitamente que a entidade principal realize uma ação. Caso contrário, a política nega acesso implicitamente. Para ter mais informações, consulte A diferença entre negações explícitas e implícitas no Guia do usuário do IAM. Para ter informações sobre a lógica de avaliação de políticas que determina se uma solicitação de acesso é permitida ou negada, consulte Lógica da avaliação de política no Guia do usuário do IAM.

Para ter mais informações sobre as permissões referentes a operações de API do S3 de acordo com os tipos de recurso do S3, consulte Permissões obrigatórias para operações de API do Amazon S3.

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

nota

Em relação a erros de acesso negado (HTTP 403 Forbidden), o Amazon 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 Exemplos de mensagens de acesso negado e como solucioná-las e acesse a seção Políticas de bucket e políticas do IAM. Lembre-se também de seguir as orientações em Dicas para verificar permissões.

Exemplos de mensagens de acesso negado e como solucioná-las

O Amazon S3 agora inclui contexto adicional em erros de acesso negado (HTTP 403 Forbidden) para solicitações feitas a recursos dentro da mesma Conta da AWS. Esse novo contexto inclui o tipo de política que negou o acesso, o motivo da negação e informações sobre o usuário ou o perfil do IAM que solicitou acesso ao recurso.

Esse contexto adicional ajuda você a solucionar problemas de acesso, identificar a causa-raiz dos erros de acesso negado e corrigir controles de acesso incorretos por meio da atualização das políticas pertinentes. Esse contexto adicional também está disponível nos logs do AWS CloudTrail. As mensagens de erro aprimoradas de acesso negado para solicitações da mesma conta agora estão disponíveis em todas as Regiões da AWS, incluindo as AWS GovCloud (US) Regions e as da China.

A maioria das mensagens de erro de acesso negado está no formato User user-arn is not authorized to perform action on "resource-arn" because context. Neste exemplo, user-arn é o nome do recurso da Amazon (ARN) do usuário que não recebe acesso, action é a ação de serviço que a política nega e resource-arn é o ARN do recurso no qual a política atua. O campo context representa contexto adicional sobre o tipo de política que explica por que o acesso é negado.

Quando uma política nega explicitamente o acesso porque ela contém uma declaração Deny, a mensagem de erro de acesso negado inclui a frase with an explicit deny in a type policy. Quando a política nega acesso implicitamente, a mensagem de erro de acesso negado inclui a frase because no type policy allows the action action.

Importante

  • As mensagens aprimoradas de acesso negado são exibidas somente para solicitações da mesma conta. Solicitações entre contas exibem uma mensagem Access Denied genérica.

    Para ter informações sobre a lógica de avaliação de políticas que determina se uma solicitação de acesso entre contas é permitida ou negada, consulte Lógica de avaliação de política entre contas no Guia do usuário do IAM. Para ter uma explicação detalhada que mostra como conceder acesso entre contas, consulte Exemplo 2: Proprietário do bucket concedendo permissões de bucket entre contas.

  • Mensagens de erro aprimoradas de acesso negado não são exibidas para solicitações feitas aos buckets de diretório. Solicitações de bucket de diretório exibem uma mensagem Access Denied genérica.

  • Se várias políticas do mesmo tipo negarem uma solicitação de autorização, a mensagem de erro de acesso negado não especificará o número de políticas.

  • Se vários tipos de política negarem uma solicitação de autorização, a mensagem de erro incluirá somente um dos tipos de política.

  • Se uma solicitação de acesso for negada por vários motivos, a mensagem de erro incluirá apenas um dos motivos da negação.

Os exemplos a seguir mostram o formato de diferentes tipos de mensagem de acesso negado e como solucionar problemas de cada tipo de mensagem.

Acesso negado devido a uma política de controle de serviço: negação implícita

  1. Verifique se falta uma instrução Allow para a ação em suas políticas de controle de serviços (SCPs). No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a SCP adicionando a instrução Allow. Para obter mais informações, consulte Atualizar uma SCP no Guia do usuário do AWS Organizations.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform:
s3:GetObject because no service control policy allows the s3:GetObject action

Acesso negado devido a uma política de controle de serviço: negação explícita

  1. Verifique se há uma instrução Deny para a ação em suas políticas de controle de serviços (SCPs). No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a SCP alterando a declaração Deny para permitir que o usuário tenha o acesso necessário. Para ver um exemplo de como fazer isso, consulte Prevent IAM users and roles from making specified changes, with an exception for a specified admin role no Guia do usuário do AWS Organizations. Para ter mais informações sobre a atualização da SCP, consulte Updating an SCP no Guia do usuário do AWS Organizations.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a service control policy

Acesso negado devido a uma política de endpoint da VPC: negação implícita

  1. Confira se falta uma declaração Allow para a ação nas políticas de endpoint da nuvem privada virtual (VPC). No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize sua política de endpoint da VPC adicionando a instrução Allow. Para obter mais informações, consulte Atualizar uma política de endpoint da VPC no Guia do AWS PrivateLink.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no VPC endpoint policy allows the s3:GetObject action

Acesso negado devido a uma política de endpoint da VPC: negação explícita

  1. Confira se há uma declaração Deny explícita para a ação nas políticas de endpoint da nuvem privada virtual (VPC). No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a política de endpoint da VPC alterando a declaração Deny para permitir que o usuário tenha o acesso necessário. Por exemplo, é possível atualizar a declaração Deny para usar a chave de condição aws:PrincipalAccount com o operador de condição StringNotEquals e permitir o acesso da entidade principal específica, conforme mostrado em Exemplo 7: excluir determinadas entidades principais de uma declaração Deny. Para ter mais informações sobre como atualizar a política de endpoint da VPC, consulte Update a VPC endpoint policy no Guia do AWS PrivateLink.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a VPC endpoint policy

Acesso negado devido a um limite de permissões: negação implícita

  1. Verifique se falta uma instrução Allow para a ação em seu limite de permissões. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize seu limite de permissões adicionando a instrução Allow à política do IAM. Para ter mais informações, consulte Limites de permissões para entidades do IAM e Edição de políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because no permissions boundary allows the s3:GetObject action

Acesso negado devido a um limite de permissões: negação explícita

  1. Verifique se há uma instrução Deny explícita para a ação em seu limite de permissões. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize o limite de permissões alterando a declaração Deny em sua política do IAM para permitir que o usuário tenha o acesso necessário. Por exemplo, é possível atualizar a declaração Deny para usar a chave de condição aws:PrincipalAccount com o operador de condição StringNotEquals e permitir o acesso da entidade principal específica, conforme mostrado em aws:PrincipalAccount no Guia do usuário do IAM. Para ter mais informações, consulte Limites de permissões para entidades do IAM e Edição de políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::777788889999:user/MaryMajor is not authorized to perform: 
s3:GetObject with an explicit deny in a permissions boundary

Acesso negado devido às políticas de sessão: negação implícita

  1. Verifique se falta uma instrução Allow para a ação em suas políticas de sessão. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a política de sessão adicionando a instrução Allow. Para ter mais informações, consulte Políticas de sessão e Edição de políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no session policy allows the s3:GetObject action

Acesso negado devido às políticas de sessão: negação explícita

  1. Verifique se há uma instrução Deny explícita para a ação em suas políticas de sessão. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a política de sessão alterando a declaração Deny para permitir que o usuário tenha o acesso necessário. Por exemplo, é possível atualizar a declaração Deny para usar a chave de condição aws:PrincipalAccount com o operador de condição StringNotEquals e permitir o acesso da entidade principal específica, conforme mostrado em Exemplo 7: excluir determinadas entidades principais de uma declaração Deny. Para ter mais informações sobre como atualizar a política de sessão, consulte Políticas de sessão e Editar políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a session policy

Acesso negado devido às políticas baseadas em recursos: negação implícita

nota

Políticas baseadas em recursos são, por exemplo, políticas de bucket e de ponto de acesso.

  1. Verifique se falta uma instrução Allow para a ação em sua política baseada em recursos. Confira também se a configuração IgnorePublicAcls do Bloqueio de Acesso Público do S3 é aplicada em nível de bucket, de ponto de acesso ou de conta. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a política adicionando a instrução Allow. Para ter mais informações, consulte Políticas baseadas em recursos e Edição de políticas do IAM no Guia do usuário do IAM.

    Talvez você também precise ajustar a configuração IgnorePublicAcls do Bloqueio de Acesso Público para o bucket, o ponto de acesso ou a conta. Para ter mais informações, consulte Acesso negado devido a configurações do Bloqueio de Acesso Público e Configurar o bloqueio de acesso público para seus buckets do S3.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action

Acesso negado devido às políticas baseadas em recursos: negação explícita

nota

Políticas baseadas em recursos são, por exemplo, políticas de bucket e de ponto de acesso.

  1. Verifique se há uma instrução Deny explícita para a ação em sua política baseada em recursos. Confira também se a configuração RestrictPublicBuckets do Bloqueio de Acesso Público do S3 é aplicada em nível de bucket, de ponto de acesso ou de conta. No exemplo a seguir, a ação é s3:GetObject.

  2. Atualize a política alterando a declaração Deny para permitir que o usuário tenha o acesso necessário. Por exemplo, é possível atualizar a declaração Deny para usar a chave de condição aws:PrincipalAccount com o operador de condição StringNotEquals e permitir o acesso da entidade principal específica, conforme mostrado em Exemplo 7: excluir determinadas entidades principais de uma declaração Deny. Para ter mais informações sobre como atualizar a política baseada em recursos, consulte Políticas baseadas no recurso e Editar políticas do IAM no Guia do usuário do IAM.

    Talvez você também precise ajustar a configuração RestrictPublicBuckets do Bloqueio de Acesso Público para o bucket, o ponto de acesso ou a conta. Para ter mais informações, consulte Acesso negado devido a configurações do Bloqueio de Acesso Público e Configurar o bloqueio de acesso público para seus buckets do S3.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

Acesso negado devido a políticas baseadas em identidade: negação implícita

  1. Verifique se falta uma instrução Allow para a ação em políticas baseadas em identidade anexadas à identidade. Para o exemplo a seguir, a ação é s3:GetObject anexada ao usuário MaryMajor.

  2. Atualize a política adicionando a instrução Allow. Para ter mais informações, consulte Políticas baseadas em identidade e Edição de políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no identity-based policy allows the s3:GetObject action

Acesso negado devido às políticas baseadas em identidade: negação explícita

  1. Verifique se há uma instrução Deny explícita para a ação em políticas baseadas em identidade anexadas à identidade. Para o exemplo a seguir, a ação é s3:GetObject anexada ao usuário MaryMajor.

  2. Atualize a política alterando a declaração Deny para permitir que o usuário tenha o acesso necessário. Por exemplo, é possível atualizar a declaração Deny para usar a chave de condição aws:PrincipalAccount com o operador de condição StringNotEquals e permitir o acesso da entidade principal específica, conforme mostrado em aws:PrincipalAccount no Guia do usuário do IAM. Para ter mais informações, consulte Políticas baseadas em identidade e Edição de políticas do IAM no Guia do usuário do IAM.

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in an identity-based policy

Acesso negado devido a configurações do Bloqueio de Acesso Público

O recurso Bloqueio de acesso público do Amazon S3 fornece configurações para pontos de acesso, buckets e contas para ajudar você a gerenciar o acesso público aos recursos do Amazon S3. Para obter mais informações sobre como o Amazon S3 define “público”, consulte O significado de "público".

Por padrão, novos buckets, pontos de acesso e objetos não permitem acesso público. No entanto, os usuários podem modificar políticas de bucket, políticas de ponto de acesso, políticas do usuário do IAM, permissões de objeto ou listas de controle de acesso (ACLs) para permitir acesso público. As configurações do Bloqueio de Acesso Público do S3 substituem essas políticas, permissões e ACLs. Desde abril de 2023, todas as configurações do Bloqueio de Acesso Público estão habilitadas por padrão para novos buckets.

Ao receber uma solicitação para acessar um bucket ou um objeto, o Amazon S3 determina se o bucket ou a conta do proprietário do bucket tem uma configuração do Bloqueio de acesso público aplicada. Se a solicitação foi feita por meio de um ponto de acesso, o Amazon S3 também verificará se há configurações do Bloqueio de acesso público para o ponto de acesso. Caso haja uma configuração do Bloqueio de acesso público que proíba o acesso solicitado, o Amazon S3 rejeitará a solicitação.

O Bloqueio de acesso público do Amazon S3 fornece quatro configurações. Essas configurações são independentes e podem ser usadas em qualquer combinação. Cada configuração pode ser aplicada a um ponto de acesso, a um bucket ou a uma conta inteira da AWS. Se as configurações do Bloqueio de acesso público para o ponto de acesso, o bucket ou a conta forem diferentes, o Amazon S3 aplicará a combinação mais restritiva das configurações de ponto de acesso, bucket e conta.

Quando o Amazon S3 avalia se uma operação é proibida por uma configuração do Bloqueio de acesso público, ela rejeita qualquer solicitação que viole uma configuração de ponto de acesso, bucket ou conta.

As quatro configurações fornecidas pelo Bloqueio de acesso público do Amazon S3 são as seguintes:

  • BlockPublicAcls: essa configuração se aplica às solicitações PutBucketAcl, PutObjectAcl, PutObject, CreateBucket, CopyObject e POST Object. A configuração BlockPublicAcls causa o seguinte comportamento:

    • As chamadas PutBucketAcl e PutObjectAcl falharão se a lista de controle de acesso (ACL) especificada for pública.

    • As chamadas PutObject falharão se a solicitação incluir uma ACL pública.

    • Se essa configuração for aplicada a uma conta, as chamadas CreateBucket falharão com uma resposta HTTP 400 (Bad Request) se a solicitação incluir uma ACL pública.

    Por exemplo, quando o acesso é negado para uma solicitação CopyObject devido à configuração BlockPublicAcls, você recebe a seguinte mensagem: 

    An error occurred (AccessDenied) when calling the CopyObject operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public access control lists (ACLs) are blocked by the BlockPublicAcls block 
public access setting.

  • IgnorePublicAcls: a configuração IgnorePublicAcls faz o Amazon S3 ignorar todas as ACLs públicas em um bucket e todos os objetos contidos. Se a permissão da solicitação for concedida somente por uma ACL pública, a configuração IgnorePublicAcls rejeitará a solicitação.

    Qualquer negação resultante da configuração IgnorePublicAcls é implícita. Por exemplo, se IgnorePublicAcls negar uma solicitação GetObject devido a uma ACL pública, você receberá a seguinte mensagem: 

    User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject because no resource-based policy allows the s3:GetObject action

  • BlockPublicPolicy: essa configuração se aplica às solicitações PutBucketPolicy e PutAccessPointPolicy.

    A configuração BlockPublicPolicy para um bucket faz com que o Amazon S3 rejeite chamadas para PutBucketPolicy caso a política de bucket especificada permita acesso público. A configuração também faz com que o Amazon S3 rejeite chamadas a PutAccessPointPolicy para todos os pontos de acesso na mesma conta do bucket caso a política especificada permita acesso público.

    A configuração BlockPublicPolicy para um ponto de acesso faz com que o Amazon S3 rejeite chamadas para PutAccessPointPolicy e PutBucketPolicy feitas por meio do ponto de acesso caso a política especificada (para o ponto de acesso ou o bucket subjacente) permita acesso público.

    Por exemplo, quando o acesso é negado em uma solicitação PutBucketPolicy devido à configuração BlockPublicPolicy, você recebe a seguinte mensagem: 

    An error occurred (AccessDenied) when calling the PutBucketPolicy operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:PutBucketPolicy on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public policies are blocked by the BlockPublicPolicy block public 
access setting.

  • RestrictPublicBuckets: a configuração RestrictPublicBuckets restringe o acesso a um ponto de acesso ou a um bucket com uma política pública apenas a entidades principais do AWS service (Serviço da AWS) e a usuários autorizados dentro da conta do proprietário do bucket e da conta do proprietário do ponto de acesso. Essa configuração bloqueia todo acesso entre contas ao ponto de acesso ou ao bucket (exceto entidades principais do AWS service (Serviço da AWS)), mas continua permitindo que usuários na conta gerenciem o ponto de acesso ou o bucket. Essa configuração também rejeita todas as chamadas anônimas (ou não assinadas).

    Qualquer negação resultante da configuração RestrictPublicBuckets é explícita. Por exemplo, se RestrictPublicBuckets negar uma solicitação GetObject devido a uma política de acesso público ou bucket público, você receberá a seguinte mensagem: 

    User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

Para ter mais informações sobre essas configurações, consulte Configurações do bloqueio de acesso público. Para revisar e atualizar essas configurações, consulte Configurar o bloqueio de acesso público.

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 do proprietário 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 do usuário do IAM em vigor, o solicitante (a menos que seja o usuário-raiz da Conta da AWS) 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 do proprietário 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 da Conta da AWS) 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 ao solicitante ao qual você está tentando conceder permissões, seja na política de bucket ou na política do usuário do IAM. Para conceder permissões entre contas usando somente a política de bucket e a política do usuário do IAM, a política do bucket e a política do usuário do IAM 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 seu acesso a um bucket for bloqueado devido a uma política de bucket incorreta, faça login no AWS Management Console usando as credenciais de usuário-raiz da Conta da AWS. Para recuperar o acesso ao bucket, exclua a política de bucket incorreta usando as credenciais de usuário-raiz da Conta da AWS.

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. Também não é possível usar ACLs para conceder acesso a solicitantes que são rejeitados por negações explícitas nas políticas de bucket ou nas políticas do 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

    Não é possível 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, confira as configurações do Bloqueio de Acesso Público do S3 na conta, no bucket ou no ponto de acesso. Para ter mais informações sobre como solucionar erros de acesso negado relacionados a configurações do Bloqueio de Acesso Público do S3, consulte Acesso negado devido a configurações do Bloqueio de Acesso Público.

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 da Conta da AWS, vai gerar 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íticas de VPC endpoint

Se você estiver acessando o Amazon S3 por meio de um endpoint da nuvem privada virtual (VPC), verifique se a política de endpoint da VPC não está impedindo o acesso aos 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 ter informações sobre como conferir a política de endpoint da VPC, consulte os seguintes recursos:

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 ter instruções sobre como conferir as políticas do AWS Organizations, consulte os seguintes recursos:

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.