Estou usando um endpoint do site do S3 como origem de minha distribuição do CloudFront. Por que estou recebendo erros 403 Access Denied (Acesso negado)?

13 minuto de leitura
0

Estou usando um bucket do Amazon Simple Storage Service (Amazon S3) como origem de minha distribuição do Amazon CloudFront e quero solucionar erros 403.

Breve descrição

Para corrigir erros Access Denied (Acesso negado), primeiro confirme se o nome de domínio da origem da distribuição é um endpoint do site do Amazon S3 ou um endpoint da API REST do Amazon S3. Em seguida, se a sua distribuição estiver usando um endpoint de site, revise as seções de solução de problemas.

Resolução

Determinar o tipo de endpoint do nome de domínio de origem da distribuição

1.    Abra o console do CloudFront.

2.    Escolha sua distribuição do CloudFront. Em seguida, escolha Distribution Settings (Configurações de distribuição).

3.    Escolha a guia Origins and Origin Groups (Origens e grupos de origem).

4.    Revise o nome de domínio em Origin Domain Name and Path (Nome e caminho do domínio de origem). Determine o tipo de endpoint com base no formato do nome de domínio:

Endpoints de APIs REST usam o seguinte formato:

DOC-EXAMPLE-BUCKET.s3.amazonaws.com

Endpoints de site usam o seguinte formato:

DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com

Observação: dependendo da região da AWS, o formato do endpoint pode usar o formato de traço (s3-website-Region) ou o formato de ponto (s3-website.Region). Se sua distribuição estiver usando um endpoint da API REST, consulte Estou usando um endpoint da API REST do S3 como a origem da minha distribuição do CloudFront. Por que estou recebendo erros 403 Access Denied (Acesso negado)?

Se a sua distribuição estiver usando um endpoint de site, verifique os requisitos nas seções a seguir para evitar erros de Access Denied (Acesso negado).

Se estiver usando a OAI, confirme se os objetos no bucket não estão criptografados pelo AWS KMS

As distribuições do CloudFront não são compatíveis com objetos criptografados do AWS Key Management Service (AWS KMS) ao usar a identidade de acesso de origem (OAI). Você deve remover a criptografia do AWS KMS dos objetos do S3 que deseja atender usando a distribuição. Em vez de usar a criptografia do AWS KMS, use AES-256 para criptografar seus objetos.

Determinar se os objetos são criptografados pelo AWS KMS

Para verificar se os objetos no seu bucket estão criptografados pelo AWS KMS:

Use o console do Amazon S3 para visualizar as propriedades do objeto. Revise a caixa de diálogo Encryption (Criptografia). Se AWS-KMS for selecionado, o objeto será criptografado pelo AWS KMS.

-ou-

Execute o comando head-object usando a AWS Command Line Interface (AWS CLI). Se o comando retornar ServerSideEncryption como aws:kms, o objeto está criptografado pelo AWS KMS.

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

Alterar as configurações de criptografia de um objeto

Para alterar as configurações de criptografia do objeto usando o console do Amazon S3, consulte Especificação da criptografia no lado do servidor com o AWS KMS (SSE-KMS).

Para alterar as configurações de criptografia do objeto usando a AWS CLI, primeiro verifique se o bucket do objeto não tem criptografia padrão. Se não tiver, execute o seguinte comando para remover a criptografia do objeto copiando o objeto e substituindo-o por ele mesmo. Substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket:

aws s3 cp s3://DOC-EXAMPLE-BUCKET/index.html s3://DOC-EXAMPLE-BUCKET/index.html

Aviso: copiar o objeto sobre ele mesmo remove as configurações de storage-class e website-redirect-location. Para manter essas configurações no novo objeto, certifique-se de especificar explicitamente esses valores na solicitação de cópia.

Se estiver usando um OAC, confirme se ele tem as permissões corretas

Um controle de acesso de origem (OAC) é compatível com criptografia do lado do servidor do Amazon S3 com o AWS KMS. Para acessar objetos do S3 criptografados pelo AWS KMS, o OAC deve ter permissões para usar a chave do AWS KMS. Para obter mais informações, consulte a seção de SSE-KMS em Conceder permissão ao controle de acesso à origem para acessar o bucket do S3.

Confirme se não há uma “Negação” explícita na política de bucket para a ação s3:GetObject

Sua política de bucket não deve ter uma instrução de negação que bloqueie o acesso público de leitura à açãos3:GetObject.

Mesmo que você tenha uma instrução de permissão explícita para s3:GetObject na sua política de bucket, confirme se não há uma instrução de negação explícita conflitante. Uma instrução de negação explícita sempre substituirá uma instrução de permissão explícita.

Para revisar sua política de bucket para s3:GetObject:

1.    Abra seu bucket do S3 no console do Amazon S3.

2.    Escolha a guia Permissions (Permissões).

3.    Escolha Bucket Policy (Política de bucket).

4.    Revise a política de bucket para ver se há instruções com "Action": "s3:GetObject" ou "Action": "s3:*".

5.    Modifique a política de bucket para remover ou editar instruções que bloqueiam o acesso público de leitura a s3:GetObject.

Por exemplo, a política a seguir contém uma instrução de permissão explícita para acesso público a s3:GetObject. No entanto, ela também contém uma instrução de negação explícita para acesso a s3:GetObject, a menos que a solicitação seja de uma Amazon Virtual Private Cloud (Amazon VPC) específica. Essa política teria que ser modificada para permitir a ação s3:GetObject.

{
  "Version": "2012-10-17",
  "Id": "PolicyForCloudFrontPrivateContent",
  "Statement": [
    {
      "Sid": "Allow-OAI-Access-To-Bucket",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EAF5XXXXXXXXX"
      },
      "Action": "s3:GetObject",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ]
    },
    {
      "Sid": "Allow-Public-Access-To-Bucket",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ]
    },
    {
      "Sid": "Access-to-specific-VPCE-only",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": [
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-1a2b3c4d"
        }
      }
    }
  ]
}

A política abaixo é um exemplo de uma política de bucket do Amazon S3 que permite acesso somente leitura a um OAC do CloudFront:

{
  "Version": "2012-10-17",
  "Statement": {
    "Sid": "AllowCloudFrontServicePrincipalReadOnly",
    "Effect": "Allow",
    "Principal": {
      "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
    "Condition": {
      "StringEquals": {
        "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/EDFDVBD6EXAMPLE"
      }
    }
  }
}

Se a política de bucket conceder acesso público de leitura, confirme se a conta da AWS proprietária do bucket também é proprietária do objeto

Para que a política do bucket permita o acesso público de leitura aos objetos, a conta da AWS que é proprietária do bucket também precisa ser a proprietária dos objetos. Para buckets do Amazon S3 existentes, as configurações provavelmente estão definidas com as configurações padrão de propriedade do objeto. Esta é a conta da AWS do AWS Identity and Access Management (IAM) que fez o upload do objeto para o bucket.

Observação: o requisito de propriedade do objeto se aplica ao acesso público de leitura concedido por uma política de bucket. Ele não se aplica ao acesso público de leitura concedido pela lista de controle de acesso (ACL) do objeto.

Confirme se o bucket e os objetos têm o mesmo proprietário

Use as etapas a seguir para verificar se o bucket e os objetos têm o mesmo proprietário. Você também pode usar o console do Amazon S3 para verificar os proprietários do bucket e do objeto. Os proprietários estão na guia Permissions (Permissões) do respectivo bucket ou objeto.

1.    Execute o seguinte comando da AWS CLI para obter o ID canônico do S3 do proprietário do bucket:

aws s3api list-buckets --query Owner.ID

2.    Execute o seguinte comando para obter o ID canônico do S3 do proprietário do objeto:

aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix index.html

Este exemplo mostra um único objeto, mas você pode usar o comando list para verificar vários objetos.

3.    Se os IDs canônicas não corresponderem, o bucket e o objeto terão proprietários diferentes.

Atualizar propriedade do objeto

Os proprietários de bucket podem gerenciar a propriedade de objetos com o S3 Object Ownership. Todos os novos buckets do S3 têm a configuração imposta pelo proprietário do bucket ativada por padrão. Para atualizar um intervalo existente, consulte Definir a propriedade de objeto em um bucket existente. Quando a configuração imposta pelo proprietário do bucket está ativada, os proprietários do bucket são os proprietários do objeto para todos os objetos dentro desse bucket. Além disso, quando a configuração imposta pelo proprietário do bucket está ativada, todas as ACLs em um bucket e seus objetos são desativados.

É uma prática recomendada que os proprietários do bucket usem a configuração imposta pelo proprietário do bucket em todos os buckets e gerenciem as permissões por meio das políticas do IAM e do bucket.

Para remover ACLs do seu bucket e assumir a propriedade de todos os objetos no bucket, execute o seguinte comando:

aws s3api put-bucket-ownership-controls --bucket example-bucket --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

Caso não queira desativar ACLs no bucket do S3, você também poderá alterar o proprietário do objeto para o proprietário do bucket.  Para fazer isso, siga estas etapas:

1.    Na conta do proprietário do objeto, execute este comando para recuperar as permissões de ACL atribuídas ao objeto:

aws s3api get-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name

2.    Se o objeto tiver permissões bucket-owner-full-control da ACL, pule para a etapa 3. Se o objeto não tiver as permissões bucket-owner-full-control da ACL, execute o seguinte comando na conta do proprietário do objeto. Substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket.

aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name --acl bucket-owner-full-control

3.    Na conta do proprietário do bucket, execute o seguinte comando para alterar o proprietário do objeto, copiando o item e substituindo-o por ele mesmo. Substitua DOC-EXAMPLE-BUCKET pelo nome do seu bucket.

aws s3 cp s3://DOC-EXAMPLE-BUCKET/index.html s3://DOC-EXAMPLE-BUCKET/index.html

Confirme se os objetos solicitados existem no bucket

Se o usuário não tiver permissões S3:ListBucket, ele receberá erros Access Denied (Acesso negado) por objetos ausentes em vez de erros 404 Not Found (Não encontrado). Execute o comando head-object da AWS CLI para verificar se existe um objeto no bucket.

Observação: confirme se a solicitação de objeto enviada ao CloudFront corresponde exatamente ao nome do objeto do S3. Os nomes dos objetos do S3 diferenciam maiúsculas de minúsculas. Se a solicitação não tiver o nome correto do objeto, o Amazon S3 responderá que o item não existe. Para identificar qual objeto o CloudFront está solicitando do Amazon S3, use o registro em log de acesso ao servidor.

Se você receber um erro relacionado ao seu objeto raiz padrão, certifique-se de que o nome do objeto não tenha nenhum caractere extra. Por exemplo, index.html deve ser inserido no campo Default Root Object (Objeto raiz padrão), não /index.html. Para obter mais informações, consulte Como especificar um objeto raiz padrão.

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

Caso ele não esteja no bucket, o erro Access Denied (Acesso negado) não está mascarando um erro 404 Not Found (Não encontrado). Solucione o problema relacionado ao objeto ausente.

Observação: não é uma prática recomendada de segurança habilitar o acesso público a s3:ListBucket. Ativar o acesso público a s3:ListBucket permite que os usuários vejam e listem todos os objetos do bucket. Essa ação mostra os detalhes dos metadados do objeto (por exemplo, chave e tamanho) para os usuários mesmo que eles não tenham permissão para fazer download do item.

Confirme se o Acesso público a blocos do Amazon S3 está desativado para o bucket

Confirme se não há configurações de acesso público de bloqueio do Amazon S3 aplicadas ao bucket. Essas configurações podem substituir as permissões que permitem o acesso público de leitura. As configurações de bloqueio de acesso público do Amazon S3 podem ser aplicadas a buckets individuais ou contas da AWS.

Confirme se os objetos no bucket estão publicamente acessíveis

As distribuições que usam um endpoint do site aceitam somente conteúdo publicamente acessível. Para saber se um objeto do bucket do S3 está publicamente acessível, abra o URL do objeto em um navegador da Web. Ou execute um comando curl no URL.

Por exemplo:

http://DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com/index.html

Se o navegador da Web ou o comando curl retornar um erro Access Denied (Acesso negado), o objeto não está acessível publicamente.

Para permitir acesso público de leitura:

Crie uma política de bucket que permita o acesso público de leitura a todos os objetos no bucket.

-ou-

Use o console do Amazon S3 para permitir o acesso público de leitura ao objeto.

Se o Requester Pays (Pagamento a cargo do solicitante) estiver ativado, confirme se a solicitação inclui o parâmetro request-payer

Se Requester Pays (Pagamento a cargo do solicitante) estiver ativado para um bucket, o acesso anônimo ao bucket não será permitido. Os usuários de outras contas devem especificar o parâmetro request-payer quando enviam solicitações para o bucket. Caso contrário, eles receberão um erro Access Denied.

Se você estiver usando um cabeçalho Referer para restringir o acesso do CloudFront à origem do Amazon S3, verifique o cabeçalho personalizado

Se você estiver usando o cabeçalho Referer para restringir o acesso do CloudFront à origem do endpoint do seu site do S3, verifique o valor secreto ou o token definido na política de bucket do S3. Em seguida, confirme se o valor secreto ou token corresponde ao valor no cabeçalho personalizado de origem do CloudFront.

Se você estiver usando uma instrução de negação explícita na política de bucket, confirme se há também uma instrução de permissão que concede acesso com base no cabeçalho Referer. Você não pode conceder acesso apenas com uma declaração de negação explícita.

Por exemplo, a política de bucket a seguir concede acesso à origem do S3 quando a solicitação contém a string "aws:Referer":"MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER”.
O cabeçalho personalizado de origem do CloudFront deve ser:

  • Cabeçalho: Referer
  • Valor: MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER
{
  "Version":"2012-10-17",
  "Id":"http referer policy example",
  "Statement":[
    {
      "Sid":"Allow get requests originating from my CloudFront with referer header",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{
        "StringLike":{"aws:Referer":"MY_SECRET_TOKEN_CONFIGURED_ON_CLOUDFRONT_ORIGIN_CUSTOM_HEADER"}
      }
    }
  ]
}

Observação: o exemplo de política de bucket concede acesso público (anônimo) ao bucket porque o Principal é um valor curinga ("Principal":"*"). No entanto, devido à instrução de condição, o acesso à origem do S3 é concedido somente se a solicitação incluir o cabeçalho Referer e o valor do cabeçalho corresponder ao valor na política de bucket.

Confirme se não há políticas de controle de serviços (SCPs) de “negação” explícitas anexadas à conta de gerenciamento da sua organização

Políticas de controle de serviço (SCPs) são um tipo de política de organização que você pode usar para gerenciar permissões na sua organização. Use a conta de gerenciamento da sua organização no AWS Organizations para verificar se há uma política de negação (para a ação s3:GetObject) anexada à raiz da organização, à unidade organizacional (OU) ou diretamente à sua conta da AWS.


Informações relacionadas

Solução de problemas de respostas de erro de sua origem

Como corrijo erros 403 Access Denied do Amazon S3?

Como uso o CloudFront para servir um site estático hospedado no Amazon S3?

AWS OFICIAL
AWS OFICIALAtualizada há um ano