
Hallo, ich habe ein Problem, ich erhalte AccessDenied in meiner Domain
Ich lade meine Site in einen AWS S3-Bucket hoch, mache sie öffentlich und erstelle eine statische Seite, aber wenn ich über meine domain.com/mypage darauf zugreife, erhalte ich die Meldung „AccessDenied“.
Von aws aus funktioniert mydomain.s3.amazonaws.com/mypage einwandfrei.
Meine Domänen-DNS sind wie folgt eingerichtet
;; ANSWER SECTION:
mydomain.com. 2101 IN CNAME mydomain.s3.amazonaws.com.
mydomain.s3.amazonaws.com. 41342 IN CNAME s3-1-w.amazonaws.com.
s3-1-w.amazonaws.com. 219 IN CNAME s3-w.us-east-1.amazonaws.com.
s3-w.us-east-1.amazonaws.com. 3 IN A 52.217.69.36
Irgendwelche Ratschläge zur Lösung dieses Problems?
Antwort1
Das istaus der Amazon-Supportdokumentation:
Kurze Beschreibung:
Um Zugriffsverweigerungsfehler zu beheben, ermitteln Sie, ob der Ursprungsdomänenname Ihrer Verteilung ein S3-Website-Endpunkt oder ein S3-REST-API-Endpunkt ist. Befolgen Sie diese Schritte, um den Endpunkttyp zu ermitteln:
- Öffnen Sie die CloudFront-Konsole.
- Wählen Sie Ihre CloudFront-Verteilung und dann „Verteilungseinstellungen“ aus.
- Wählen Sie die Registerkarte „Ursprünge und Ursprungsgruppen“.
- Wählen Sie die Registerkarte „Ursprünge und Ursprungsgruppen“.
Überprüfen Sie den Domänennamen unter „Ursprungsdomänenname und -pfad“ und bestimmen Sie dann den Endpunkttyp basierend auf dem Format des Domänennamens.
REST-API-Endpunkte verwenden dieses Format:
DOC-EXAMPLE-BUCKET.s3.amazonaws.com
Notiz: Befolgen Sie unbedingt die Regeln zur Benennung von Amazon S3-Buckets.
Website-Endpunkte verwenden dieses Format:
DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com
Notiz: Abhängig von der AWS-Region kann das Endpunktformat das Bindestrichformat (s3-website-Region) oder das Punktformat (s3-website.Region) verwenden.
Wenn Ihre Verteilung einen REST-API-Endpunkt verwendet, lesen Sie Ich verwende einen S3-REST-API-Endpunkt als Ursprung meiner CloudFront-Verteilung.Warum erhalte ich die Fehlermeldung „403 Zugriff verweigert“?
Wenn Ihre Verteilung einen Website-Endpunkt verwendet, überprüfen Sie die folgenden Anforderungen, um Zugriffsverweigerungsfehler zu vermeiden:
- Objekte im Bucket müssen öffentlich zugänglich sein.
- Objekte im Bucket können nicht vom AWS Key Management Service (AWS KMS) verschlüsselt werden.
- Die Bucket-Richtlinie muss den Zugriff auf s3:GetObject erlauben.
- Wenn die Bucket-Richtlinie öffentlichen Lesezugriff gewährt, muss das AWS-Konto, dem der Bucket gehört, auch Eigentümer des Objekts sein. 5. Die angeforderten Objekte müssen im Bucket vorhanden sein.
- Der öffentliche Amazon S3-Blockzugriff muss für den Bucket deaktiviert sein.
- Wenn „Der Anforderer zahlt“ aktiviert ist, muss die Anforderung den Parameter „request-payer“ enthalten.
- Wenn Sie einen Referrer-Header verwenden, um den Zugriff von CloudFront auf Ihren S3-Ursprung einzuschränken, überprüfen Sie den benutzerdefinierten Header.
Notiz: Wenn Sie nicht zulassen möchten, dass öffentliche (anonym) Zugriff auf Ihre S3-Objekte, und ändern Sie dann Ihre Konfiguration, um den S3-REST-API-Endpunkt als Ursprung Ihrer Verteilung zu verwenden. Konfigurieren Sie dann Ihre Verteilung und Ihren S3-Bucket, um den Zugriff mithilfe einer Origin Access Identity (OAI) einzuschränken. Anweisungen finden Sie unter Verwenden eines REST-API-Endpunkts als Ursprung mit durch eine OAI eingeschränktem Zugriff in Wie verwende ich CloudFront, um eine statische Website bereitzustellen, die auf Amazon S3 gehostet wird?
Auflösung
Objekte im Bucket müssen öffentlich zugänglich sein
Eine Verteilung, die einen Website-Endpunkt verwendet, unterstützt nur öffentlich zugängliche Inhalte. Um festzustellen, ob ein Objekt in Ihrem S3-Bucket öffentlich zugänglich ist, öffnen Sie die URL des Objekts in einem Webbrowser. Alternativ können Sie einen Curl-Befehl für die URL ausführen.
Nachfolgend sehen Sie eine Beispiel-URL eines S3-Objekts:
http://DOC-EXAMPLE-BUCKET.s3-website-us-east-1.amazonaws.com/index.html
Wenn der Webbrowser oder der Curl-Befehl einen Zugriffsverweigerungsfehler zurückgibt, ist das Objekt nicht öffentlich zugänglich.
Erlauben Sie öffentlichen Lesezugriff auf das Objekt auf eine der folgenden Arten:
- Erstellen Sie eine Bucket-Richtlinie, die öffentlichen Lesezugriff für alle Objekte im Bucket erlaubt.
- Verwenden Sie die Amazon S3-Konsole, um öffentlichen Lesezugriff für das Objekt zu gewähren.
- Objekte im Bucket können nicht AWS KMS-verschlüsselt werden
- CloudFront-Distributionen unterstützen keine AWS KMS-verschlüsselten Objekte. Sie müssen die KMS-Verschlüsselung von den S3-Objekten entfernen, die Sie mithilfe der Distribution bereitstellen möchten.
Notiz: Verwenden Sie zum Verschlüsseln Ihrer Objekte anstelle der AWS KMS-Verschlüsselung AES-256.
Verwenden Sie eine der folgenden Möglichkeiten, um zu überprüfen, ob ein Objekt in Ihrem Bucket KMS-verschlüsselt ist:
Verwenden Sie die Amazon S3-Konsole, um die Eigenschaften des Objekts anzuzeigen. Überprüfen Sie das Dialogfeld „Verschlüsselung“. Wenn AWS-KMS ausgewählt ist, ist das Objekt KMS-verschlüsselt. Führen Sie den Befehl head-object mithilfe der AWS Command Line Interface (AWS CLI) aus. Wenn der Befehl ServerSideEncryption als aws:kms zurückgibt, ist das Objekt KMS-verschlüsselt. Hinweis: Wenn beim Ausführen von AWS CLI-Befehlen Fehler auftreten, stellen Sie sicher, dass Sie die neueste Version der AWS CLI verwenden. Informationen zum Ändern der Verschlüsselungseinstellungen des Objekts mithilfe der Amazon S3-Konsole finden Sie unter Wie füge ich einem S3-Objekt eine Verschlüsselung hinzu?
Um die Verschlüsselungseinstellungen des Objekts zu ändern, verwenden SieAWS-Befehlszeilenschnittstelleüberprüfen Sie zunächst, dass der Bucket des Objekts nicht über die Standardverschlüsselung verfügt. Wenn der Bucket nicht über die Standardverschlüsselung verfügt, führen Sie den folgenden Befehl aus, um die Verschlüsselung des Objekts zu entfernen, indem Sie das Objekt über sich selbst kopieren:
aws s3 cp s3://DOC-EXAMPLE-BUCKET/index.html s3://DOC-EXAMPLE-BUCKET/index.html
Warnung: Durch das Kopieren des Objekts werden Einstellungen für Speicherklasse und
Website-Umleitungsstandort entfernt. Um diese Einstellungen im neuen Objekt beizubehalten, geben Sie in der Kopieranforderung unbedingt explizit Werte für Speicherklasse oder Website-Umleitungsstandort an.Die Bucket-Richtlinie muss den Zugriff auf s3:GetObject erlauben. Um eine Verteilung mit einem S3-Website-Endpunkt zu verwenden, darf Ihre Bucket-Richtlinie keine Deny-Anweisung enthalten, die den öffentlichen Lesezugriff auf die Aktion s3:GetObject blockiert.
Auch wenn Ihre Bucket-Richtlinie eine explizite Zulassungsanweisung für s3:GetObject enthält, vergewissern Sie sich, dass keine widersprüchliche explizite Ablehnungsanweisung vorliegt. Eine explizite Ablehnungsanweisung überschreibt immer eine explizite Zulassungsanweisung.
Befolgen Sie diese Schritte, um Ihre Bucket-Richtlinie für s3:GetObject zu überprüfen:
Öffnen Sie Ihren S3-Bucket von der Amazon S3-Konsole aus.
Wählen Sie die Registerkarte „Berechtigungen“.
Wählen Sie Bucket-Richtlinie.
Überprüfen Sie die Bucket-Richtlinie auf Anweisungen mit „Action“: „s3:GetObject“ oder „Action“: „s3:*“.
Die folgende Beispielrichtlinie enthält eine explizite Zulassungsanweisung für den öffentlichen Zugriff auf s3:GetObject. Es gibt jedoch auch eine explizite Ablehnungsanweisung für s3:GetObject, die den Zugriff blockiert, sofern die Anforderung nicht von einer bestimmten Amazon Virtual Private Cloud (Amazon VPC) stammt.
{ "Version": "2008-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" } } } ] }
- Ändern Sie die Bucket-Richtlinie, um Anweisungen zu entfernen oder zu bearbeiten, die den öffentlichen Lesezugriff auf s3:GetObject blockieren.
Notiz: CloudFront speichert die Ergebnisse eines Zugriffsverweigerungsfehlers für die in der Mindest-TTL für die Fehlerzwischenspeicherung angegebene Zeit im Cache. Der Standardwert ist eine Minute. Nachdem Sie eine Deny-Anweisung aus der Bucket-Richtlinie entfernt haben, können Sie eine Ungültigkeitserklärung für Ihre Verteilung ausführen, um das Objekt aus dem Cache zu entfernen.
Wenn die Bucket-Richtlinie öffentlichen Lesezugriff gewährt, muss das AWS-Konto, dem der Bucket gehört, auch das Objekt besitzen. Damit eine Bucket-Richtlinie öffentlichen Lesezugriff auf Objekte zulässt, muss das AWS-Konto, dem der Bucket gehört, auch die Objekte besitzen. Ein Bucket oder Objekt gehört dem Konto der AWS Identity and Access Management (IAM)-Identität, die den Bucket oder das Objekt erstellt hat.
Notiz: Die Objektbesitzanforderung gilt für öffentlichen Lesezugriff, der durch eine Bucket-Richtlinie gewährt wird. Sie gilt nicht für öffentlichen Lesezugriff, der durch die Zugriffskontrollliste (ACL) des Objekts gewährt wird.
Führen Sie die folgenden Schritte aus, um zu überprüfen, ob Bucket und Objekte denselben Besitzer haben:
- Führen Sie diesen AWS CLI-Befehl aus, um die kanonische S3-ID des Bucket-Eigentümers abzurufen:
aws s3api list-buckets --query Owner.ID
- Führen Sie diesen Befehl aus, um die kanonische S3-ID des Objektbesitzers abzurufen:
Hinweis: Dieses Beispiel zeigt ein einzelnes Objekt, Sie können den Listenbefehl jedoch verwenden, um mehrere Objekte zu überprüfen.
aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix index.html
- Wenn die kanonischen IDs nicht übereinstimmen, haben Bucket und Objekt unterschiedliche Besitzer.
Hinweis: Sie können auch die Amazon S3-Konsole verwenden, um die Bucket- und Objektbesitzer zu überprüfen. Die Besitzer finden Sie auf der Registerkarte „Berechtigungen“ des jeweiligen Buckets oder Objekts.
Führen Sie die folgenden Schritte aus, um den Besitzer des Objekts zum Bucket-Besitzer zu ändern:
- Führen Sie vom Konto des Objekteigentümers aus diesen Befehl aus, um die dem Objekt zugewiesenen ACL-Berechtigungen abzurufen:
aws s3api get-object-acl --bucket DOC-EXAMPLE-BUCKET --key object-name
- Wenn das Objekt über die ACL-Berechtigung „Bucket-Owner-Full-Control“ verfügt, fahren Sie mit Schritt 3 fort. Wenn das Objekt nicht über die ACL-Berechtigung „Bucket-Owner-Full-Control“ verfügt, 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
- Führen Sie im Konto des Bucket-Eigentümers diesen Befehl aus, um den Eigentümer 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
Die angeforderten Objekte müssen im Bucket vorhanden seinWenn ein Benutzer keine s3:ListBucket-Berechtigungen hat, erhält er für fehlende Objekte Zugriffsverweigerungsfehler anstelle von 404-Fehlern. Führen Sie den AWS CLI-Befehl head-object aus, um zu prüfen, ob im Bucket ein Objekt vorhanden ist.
Notiz: Bestätigen Sie, dass die an CloudFront gesendete Objektanforderung genau mit dem S3-Objektnamen übereinstimmt. Bei S3-Objektnamen wird zwischen Groß- und Kleinschreibung unterschieden. Wenn die Anforderung nicht den richtigen Objektnamen enthält, antwortet Amazon S3, als ob das Objekt fehlt. Um zu ermitteln, welches Objekt CloudFront von Amazon S3 anfordert, verwenden Sie die Serverzugriffsprotokollierung.
Wenn das Objekt im Bucket vorhanden ist, wird der Fehler „Zugriff verweigert“ nicht Maskieren eines 404 Not Found-Fehlers. Überprüfen Sie andere Konfigurationsanforderungen, um den Fehler „Zugriff verweigert“ zu beheben.
Wenn sich das Objekt nicht im Bucket befindet, wird der Fehler „Zugriff verweigert“ angezeigt. Maskieren eines 404 Not Found-Fehlers. Beheben Sie das Problem im Zusammenhang mit dem fehlenden Objekt.
Notiz: Es ist keine bewährte Sicherheitsmethode, den öffentlichen s3:ListBucket-Zugriff zu aktivieren. Durch die Aktivierung des öffentlichen s3:ListBucket-Zugriffs können Benutzer alle Objekte in einem Bucket anzeigen und auflisten. Dadurch werden Benutzern Objektmetadatendetails (z. B. Schlüssel und Größe) angezeigt, auch wenn die Benutzer keine Berechtigungen zum Herunterladen des Objekts haben.
Amazon S3 Block Public Access muss für den Bucket deaktiviert sein.Stellen Sie sicher, dass auf den Bucket keine Amazon S3 Block Public Access-Einstellungen angewendet wurden. Diese Einstellungen können Berechtigungen überschreiben, die öffentlichen Lesezugriff erlauben. Amazon S3 Block Public Access-Einstellungen können auf einzelne Buckets oder AWS-Konten angewendet werden.
Wenn „Requester Pays“ aktiviert ist, muss die Anforderung den Parameter „request-payer“ enthalten. Wenn „Requester Pays“ für einen Bucket aktiviert ist, ist der anonyme Zugriff auf den Bucket nicht zulässig. Benutzer von anderen Konten müssen den Parameter „request-payer“ angeben, wenn sie Anforderungen an den Bucket senden. Andernfalls erhalten diese Benutzer die Fehlermeldung „Zugriff verweigert“.
Wenn Sie einen Referrer-Header verwenden, um den Zugriff von CloudFront auf Ihren S3-Ursprung einzuschränken, überprüfen Sie den benutzerdefinierten Header. Wenn Sie den Referrer-Header verwenden, um den Zugriff von CloudFront auf den Ursprung des S3-Website-Endpunkts einzuschränken, überprüfen Sie den geheimen Wert oder das Token, das in der S3-Bucket-Richtlinie festgelegt ist. Bestätigen Sie dann, dass der geheime Wert oder das Token mit dem Wert im benutzerdefinierten Header des CloudFront-Ursprungs übereinstimmt.
Wenn Sie in der Bucket-Richtlinie eine explizite Deny-Anweisung verwenden, vergewissern Sie sich, dass auch eine Allow-Anweisung vorhanden ist, die Zugriff basierend auf dem Referer-Header gewährt. Sie können keinen Zugriff nur mit einer expliziten Deny-Anweisung gewähren.
Zum Beispielgewährt die folgende Bucket-Richtlinie Zugriff auf den S3-Ursprung, wenn die Anfrage die Zeichenfolge enthält "aws:Referer“: „MEIN_GEHEIMES_TOKEN_KONFIGURIERT_AUF_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"} } } ] }
Bei dieser Beispiel-Bucket-Richtlinie muss der benutzerdefinierte Header des CloudFront-Ursprungs wie folgt lauten:
- Header: Referrer
- Wert:MEIN_GEHEIMES_TOKEN_KONFIGURIERT_AUF_CLOUDFRONT_ORIGIN_CUSTOM_HEADER
Notiz: Die Beispiel-Bucket-Richtlinie gewährt öffentlichen (anonymen) Zugriff auf den Bucket, da der Principal ein Platzhalterwert ist („Principal“: „*“). Aufgrund der Bedingungsanweisung wird der Zugriff auf den S3-Ursprung jedoch nur gewährt, wenn die Anforderung den Referer-Header enthält und der Header-Wert mit dem Wert in der Bucket-Richtlinie übereinstimmt.