Ich verwende einen S3-REST-API-Endpunkt als Ursprung meiner CloudFront-Distribution. Warum erhalte ich den Fehler „403 Access Denied“?

Kurzbeschreibung

Um Fehler des Typs „Access Denied“ zu beheben, stellen Sie fest, ob der ursprüngliche Domainname Ihrer Distribution ein S3-Website-Endpunkt oder ein S3-REST-API-Endpunkt ist. Gehen Sie wie folgt vor, um den Endpunkttyp zu ermitteln:

1.    Öffnen Sie die CloudFront-Konsole.

2.    Wählen Sie Ihre CloudFront-Distribution aus. Wählen Sie dann Distribution Settings.

3.    Wählen Sie die Registerkarte Origins und Origin Groups.

4.    Überprüfen Sie den Domainnamen unter Origin Domain Name and Path. Ermitteln Sie dann den Endpunkttyp anhand des Formats des Domainnamens. REST-API-Endpunkte verwenden diese Formate:

DOC-EXAMPLE-BUCKET.s3.region.amazonaws.com
DOC-EXAMPLE-BUCKET.s3.amazonaws.com

Wichtig: Das Format bucket-name.s3.amazonaws.com funktioniert nicht für Regionen, die 2019 oder später eingeführt wurden. Statische Website-Endpunkte verwenden dieses Format:

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

Wenn Ihre Distribution einen statischen S3-Website-Endpunkt verwendet, erhalten Sie möglicherweise die Fehlermeldung 403 Access Denied. Weitere Informationen finden Sie unter Ich verwende einen S3-Website-Endpunkt als Ursprung meiner CloudFront-Distribution. Warum erhalte ich den Fehler „403 Access Denied“?

Wenn Ihre Distribution einen REST-API-Endpunkt verwendet, stellen Sie sicher, dass Ihre Konfigurationen die folgenden Anforderungen erfüllen, um Fehler des Typs „Access Denied“ zu vermeiden:

• Wenn Sie weder Origin Access Control (OAC) noch Origin Access Identity (OAI) konfigurieren, müssen die Objekte öffentlich zugänglich sein. Oder Sie müssen die Objekte mit AWS Signature Version 4 anfordern.
• Wenn der S3-Bucket Objekte enthält, die vom AWS Key Management Service (AWS KMS) verschlüsselt wurden, sollte OAC anstelle von OAI verwendet werden.
• Die S3-Bucket-Richtlinie muss den Zugriff auf s3:GetObject ermöglichen.
• Wenn die Bucket-Richtlinie Zugriff gewährt, muss das AWS-Konto, dem der S3-Bucket gehört, auch das Objekt besitzen.
• Die angeforderten Objekte müssen im S3-Bucket existieren.
• Wenn Kunden das Stammverzeichnis Ihrer Distribution anfordern, müssen Sie ein Standard-Stammobjekt definieren.
• Wenn Sie eine OAI konfiguriert haben, muss die OAI in der S3-Bucket-Richtlinie enthalten sein.
• Wenn Sie ein OAC konfiguriert haben, muss der CloudFront-Serviceprinzipal in der S3-Bucket-Richtlinie enthalten sein. Wenn Sie eine OAI konfiguriert haben, muss die OAI in Ihrer S3-Bucket-Richtlinie enthalten sein.
• Wenn Sie weder OAC noch OAI konfigurieren, muss Amazon S3 Block Public Access im Bucket deaktiviert sein.

Lösung

Wenn Sie weder OAC noch OAI konfigurieren, müssen Ihre Objekte öffentlich zugänglich sein oder mit AWS Signature Version 4 angefordert werden.

Um festzustellen, ob die Objekte in Ihrem S3-Bucket öffentlich zugänglich sind, öffnen Sie die URL des S3-Objekts in einem Webbrowser. Oder führen Sie einen curl-Befehl für die URL aus.

Das Folgende ist eine Beispiel-URL eines S3-Objekts:

https://DOC-EXAMPLE-BUCKET.s3.amazonaws.com/index.html

Wenn entweder der Webbrowser oder der Befehl curl den Fehler „Access Denied“ zurückgibt, ist das Objekt nicht öffentlich zugänglich. Wenn das Objekt nicht öffentlich zugänglich ist, verwenden Sie eine der folgenden Konfigurationen:

• Erstellen Sie eine Bucket-Richtlinie, die öffentlichen Lesezugriff für alle Objekte im Bucket zulässt.
• Verwenden Sie die Amazon S3-Konsole, um öffentlichen Lesezugriff für das Objekt zu gewähren.
• Konfigurieren Sie entweder OAC oder OAI für die Verteilung mithilfe des REST-API-Endpunkts.
• Authentifizieren Sie Anfragen an Amazon S3 mithilfe von AWS Signature Version 4.

Mit dem AWS Key Management Service (AWS SSE-KMS) verschlüsselte Objekte

Wenn der s3-Bucket Objekte enthält, die vom AWS Key Management Service (AWS SSE-KMS) verschlüsselt wurden, sollte OAC anstelle von OAI verwendet werden.

Mit AWS KMS verschlüsselte Objekte können mit CloudFront bereitgestellt werden, indem OAC eingerichtet wird. Fügen Sie dazu der AWS-KMS-Verschlüsselungsrichtlinie eine Anweisung hinzu, die dem CloudFront-Serviceprinzipal die Berechtigung erteilt, den Schlüssel zu verwenden. Um mit AWS KMS verschlüsselte Objekte bereitzustellen, ohne OAC einzurichten, stellen Sie den AWS-KMS-Schlüssel verschlüsselt aus einem S3-Bucket mit Lambda@Edge bereit.

Verwenden Sie eine der folgenden Methoden, um zu überprüfen, ob ein Objekt in Ihrem Bucket mit AWS KMS verschlüsselt ist:

• Verwenden Sie die Amazon-S3-Konsole, um die Eigenschaften des Objekts anzuzeigen. Überprüfen Sie das Dialogfeld „Encryption“. Wenn AWS KMS ausgewählt ist, ist das Objekt mit AWS KMS verschlüsselt.
• Oder Sie können den Befehl head-object über die AWS-Befehlszeilenschnittstelle (AWS CLI) ausführen. Wenn der Befehl „ServerSideEncryption“ als aws:kms zurückgibt, ist das Objekt mit AWS KMS-verschlüsselt. Wenn beim Ausführen von AWS-CLI-Befehlen Fehler auftreten,stellen Sie sicher, dass Sie die neueste Version der AWS CLI verwenden.
  Hinweis: OAI unterstützt das Bereitstellen von mit AWS KMS verschlüsselten Objekten nicht.

Die S3-Bucket-Richtlinie muss den Zugriff auf s3:GetObject ermöglichen

Um eine Distribution mit einem S3-REST-API-Endpunkt zu verwenden, muss Ihre Bucket-Richtlinie s3:GetObject entweder für öffentliche Benutzer oder für die OAI von CloudFront zulassen. Auch wenn Sie eine explizite Genehmigungsanweisung für s3:GetObject in Ihrer Bucket-Richtlinie haben, stellen Sie sicher, dass keine widersprüchliche explizite Ablehnungsanweisung vorhanden ist. Eine explizite Ablehnungsanweisung überschreibt immer eine explizite Genehmigungsanweisung.

Gehen Sie wie folgt vor, um Ihre Bucket-Richtlinie für s3:GetObject zu überprüfen:

1.    Öffnen Sie Ihren S3-Bucket von der Amazon S3-Konsole aus.

2.    Öffnen Sie die Registerkarte „Permission“.

3.    Wählen Sie Bucket-Richtlinie aus.

4.    Überprüfen Sie die Bucket-Richtlinie für Anweisungen mit „Action“: „s3:GetObject“ oder „Action“: „s3:\ *“. Die folgende Beispielrichtlinie enthält eine Genehmigungsanweisung, die einem CloudFront-OAC-Zugriff auf s3:GetObject gewährt. Sie enthält auch eine Anweisung, die CloudFront OAI Zugriff auf s3:GetObject gewährt, und eine Genehmigungsanweisung, die öffentlichen Zugriff auf s3:GetObject gewährt. Es gibt jedoch eine explizite Ablehnungsanweisung für s3:GetObject, die den Zugriff blockiert, sofern die Anfrage nicht von einer bestimmten Amazon Virtual Private Cloud (Amazon VPC) stammt:

{
  "Version": "2012-10-17",
  "Id":
    "PolicyForCloudFrontPrivateContent",
  "Statement": [{
      "Sid": "Allow-OAC-Access-To-Bucket",
        "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"
            }
        }
      },

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

5.    Ändern Sie die Bucket-Richtlinie, um Anweisungen zu entfernen oder zu bearbeiten, die den CloudFront-OAI-Zugriff oder den öffentlichen Zugriff auf s3:GetObject blockieren

Hinweis: CloudFront speichert die Ergebnisse eines Fehlers des Typs „Access Denied“ für bis zu fünf Minuten im Cache. Nachdem Sie eine Ablehnungsanweisung aus der Bucket-Richtlinie entfernt haben, können Sie eine Aufhebung für Ihre Distribution durchführen, um das Objekt aus dem Cache zu entfernen.

Besitz von S3-Buckets und Objekten

Damit eine Bucket-Richtlinie für externe Konten oder Dienste gilt, muss das AWS-Konto, dem der Bucket gehört, auch Eigentümer der Objekte sein. Ein Bucket oder Objekt gehört dem Konto der AWS Identity and Access Management (IAM)-Identität, dass den Bucket oder das Objekt erstellt hat.

Hinweis: Die Objekteigentumsanforderung gilt für den Zugriff, der durch eine Bucket-Richtlinie gewährt wird. Sie gilt nicht für den Zugriff, der durch die Access Control List (ACL) des Objekts gewährt wird.

Gehen Sie wie folgt vor, um zu überprüfen, ob der Bucket und die Objekte denselben Besitzer haben:

1.    Führen Sie diesen AWS-CLI-Befehl aus, um die kanonische S3-ID des Bucket-Besitzers abzurufen:

aws s3api list-buckets --query Owner.ID

2.    Führen Sie diesen Befehl aus, um die kanonische S3-ID des Objektbesitzers abzurufen:

Hinweis: Dieses Beispiel zeigt ein einzelnes Objekt, aber Sie können den Auzählungs-Befehl verwenden, um mehrere Objekte zu überprüfen.

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

3.    Wenn die kanonischen IDs nicht übereinstimmen, haben der Bucket und das Objekt unterschiedliche Besitzer.

Hinweis: Sie können auch die Amazon-S3-Konsole verwenden, um die Bucket- und Objektbesitzer zu überprüfen. Die Besitzer befinden sich auf der Registerkarte „Permissions“ des jeweiligen Buckets oder Objekts.

Gehen Sie wie folgt vor, um den Eigentümer des Objekts in den Bucket-Besitzer zu ändern:

1.    Führen Sie im AWS-Konto des Objektbesitzers diesen Befehl aus, um die dem Objekt zugewiesenen Access Control List (ACL) -Berechtigungen abzurufen:

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

2.    Wenn das Objekt über ACL-Berechtigungen für Bucket-Owner-Fullcontrol verfügt, fahren Sie mit Schritt #3 fort. Wenn das Objekt keine ACL-Berechtigungen für Bucket-Owner-Full-Control hat, führen Sie diesen Befehl vom Konto des Objektbesitzers aus:

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

3.    Führen Sie vom Konto des Bucket-Besitzers aus diesen Befehl aus, um den Besitzer des Objekts zu ändern, indem Sie das Objekt über sich selbst kopieren:

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

Hinweis: Stellen Sie sicher, dass Sie den --storage-class Wert im Beispielbefehl in die Speicherklasse ändern, die für Ihren Anwendungsfall gilt.

Die angeforderten Objekte müssen im Bucket existieren

Wenn ein Benutzer keine s3:ListBucket-Berechtigungen hat, erhält der Benutzer die Fehlermeldung „Access Denied“ für fehlende Objekte anstelle der Fehler „404 Not Found“. Führen Sie den AWS-CLI-Befehl head-object aus, um zu überprüfen, ob ein Objekt im Bucket vorhanden ist.

Hinweis: Vergewissern Sie sich, dass die an CloudFront gesendete Objektanforderung genau mit dem S3-Objektnamen übereinstimmt. Bei S3-Objektnamen wird zwischen Groß- und Kleinschreibung unterschieden. Wenn die Anfrage nicht den richtigen Objektnamen hat, reagiert Amazon S3 so, als ob das Objekt fehlt. Verwenden Sie die Serverzugriffsprotokollierung, um zu ermitteln, welches Objekt CloudFront von Amazon S3 anfordert.

Wenn das Objekt im Bucket vorhanden ist, maskiert der Fehler „Access Denied“ nicht den Fehler „404 Not Found“. Überprüfen Sie weitere Konfigurationsanforderungen, um den Fehler „Access Denied“ zu beheben.

Wenn das Objekt im Bucket nicht vorhanden ist, maskiert der Fehler „Access Denied“ einen Fehler „404 Not Found“. Beheben Sie das Problem im Zusammenhang mit dem fehlenden Objekt.

Hinweis: Es ist keine bewährte Sicherheitsmethode, den öffentlichen s3:ListBucket-Zugriff zuzulassen. Wenn Sie den öffentlichen s3:ListBucket-Zugriff zulassen, können Benutzer alle Objekte in einem Bucket sehen und auflisten. Dadurch werden Objektmetadatendetails wie Schlüssel und Größe für Benutzer verfügbar gemacht, auch wenn die Benutzer keine Berechtigungen zum Herunterladen des Objekts haben.

Wenn Kunden das Stammverzeichnis Ihrer Distribution anfordern, müssen Sie ein Standard-Stammobjekt definieren

Wenn für Ihre Distribution kein Standard-Stammobjekt definiert ist und ein Anforderer keinen s3:ListBucket-Zugriff hat, erhält der Anforderer den Fehler „Access Denied“. Der Anforderer erhält diesen Fehler anstelle des Fehlers „404 Not Found“, wenn er das Stammverzeichnis Ihrer Distribution anfordert.

Informationen zum Definieren eines Standard-Stammobjekts finden Sie unter Standardwurzelobjekt angeben.

Hinweis: Es ist keine bewährte Sicherheitsmethode, den öffentlichen s3:ListBucket-Zugriff zuzulassen. Wenn Sie den öffentlichen s3:ListBucket-Zugriff zulassen, können Benutzer alle Objekte in einem Bucket sehen und auflisten. Dadurch werden Objektmetadatendetails wie Schlüssel und Größe für Benutzer verfügbar gemacht, auch wenn die Benutzer keine Berechtigungen zum Herunterladen des Objekts haben.

Berechtigungen für OAC oder OAI

Wenn Sie ein OAC konfiguriert haben, muss ein CloudFront-Dienstprinzipal in die S3-Bucket-Richtlinie aufgenommen werden. Wenn Sie eine OAI konfiguriert haben, muss die OAI in Ihrer S3-Bucket-Richtlinie enthalten sein

Um zu überprüfen, ob Ihre Bucket-Richtlinie die OAI zulässt, öffnen Sie Ihren S3-Bucket in der Amazon-S3-Konsole. Wählen Sie dann die Registerkarte „Permissions“ und überprüfen Sie die Bucket-Richtlinie. In der folgenden Beispielrichtlinie ist die erste Anweisung eine Genehmigungsanweisung für den CloudFront-Dienstprinzipal, wenn OAC konfiguriert ist. Die zweite Anweisung ist eine Genehmigungsanweisung für eine OAI:

{
      "Sid": "Allow-OAC-Access-To-Bucket",
        "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"

    }
     }
      },

{
  "Sid": "1",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin
    Access Identity EAF5XXXXXXXXX"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
}

Gehen Sie folgendermaßen vor, um Ihre Bucket-Richtlinie mithilfe der CloudFront-Konsole zu aktualisieren:

1.    Öffnen Sie die CloudFront-Konsole und wählen Sie dann Ihre Distribution.

2.    Wählen Sie die Registerkarte Origins und Origin Groups.

3.    Wählen Sie den S3-Ursprung und anschließend Edit aus.

4.    Wählen Sie für Restrict Bucket Access die Option Yes aus.

5.    Wählen Sie für Origin Access Identity die vorhandene Identität aus oder erstellen Sie eine neue.

6.    Wählen Sie für Grant Read Permissions on Bucket die Option Yes, Update Bucket Policy.

7.    Wählen Sie Yes, Edit aus.

Ermöglichen des öffentlichen Zugriffs für die Verteilung ohne OAC oder OAI

Wenn Ihre Distribution weder OAC noch OAI verwendet und Objekte mit AWS Signature Version 4 nicht angefordert werden, müssen Sie den öffentlichen Zugriff auf Objekte zulassen. Dies liegt daran, dass eine Distribution mit einem REST-API-Endpunkt nur öffentlich-lesbare-Objekte unterstützt. In diesem Fall müssen Sie bestätigen, dass keine Amazon-S3-Block Public-Access-Einstellungen auf den Bucket angewendet wurden. Diese Einstellungen können Berechtigungen außer Kraft setzen, die öffentlichen Lesezugriff ermöglichen. Amazon-S3-Block-Public-Access-Einstellungen kann für einzelne Buckets oder AWS-Konten gelten.

---

Verwandte Informationen

Fehlerbehebung bei Fehlermeldungen Ihres Ursprungsservers

Wie behebe ich Fehler „403 Access Denied“ von Amazon S3?