Beheben von „Zugriff verweigert“-Fehlern (403 Forbidden) in Amazon S3 - Amazon Simple Storage Service
Beispiele für „Zugriff verweigert“-Meldungen und deren BehebungBucket-Richtlinien und IAM-RichtlinienAmazon-S3-ACL-EinstellungenS3–Block-Public-Access-EinstellungenAmazon-S3-VerschlüsselungseinstellungenS3-Einstellungen für die ObjektsperreVPC-EndpunktrichtlinienAWS Organizations RichtlinienCloudFront Zugriff auf VertriebZugriffspunkteinstellungenWeitere Ressourcen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben von „Zugriff verweigert“-Fehlern (403 Forbidden) in Amazon S3

Fehler „Zugriff verweigert“ (HTTP403 Forbidden) treten auf, wenn eine Autorisierungsanfrage AWS explizit oder implizit verweigert wird.

  • Eine ausdrückliche Ablehnung liegt vor, wenn eine Richtlinie eine Deny Anweisung für die bestimmte Aktion enthält. AWS

  • Eine implizite Verweigerung tritt auf, wenn es keine entsprechende Deny-Anweisung, aber auch keine anwendbare Allow-Anweisung gibt.

Da eine AWS Identity and Access Management (IAM-) Richtlinie standardmäßig implizit einen IAM-Prinzipal verweigert, muss die Richtlinie dem Prinzipal ausdrücklich erlauben, eine Aktion auszuführen. Andernfalls verweigert die Richtlinie implizit den Zugriff. Weitere Informationen finden Sie unter Der Unterschied zwischen expliziten und impliziten Verweigerungen im IAM-Benutzerhandbuch. Weitere Informationen zur Richtlinienevaluierungslogik, die bestimmt, ob eine Zugriffsanforderung erlaubt oder verweigert wird, finden Sie unter Richtlinienevaluierungslogik im IAM-Benutzerhandbuch.

Weitere Informationen zu den Berechtigungen für S3-API-Operationen nach S3-Ressourcentypen finden Sie unter Erforderliche Berechtigungen für Amazon-S3-API-Operationen.

Die folgenden Themen behandeln die häufigsten Ursachen von „Zugriff verweigert“-Fehlern in Amazon S3.

Anmerkung

Bei Fehlern mit Zugriffsverweigerung (HTTP403 Forbidden) berechnet Amazon S3 dem Bucket-Besitzer keine Gebühren, wenn die Anfrage außerhalb des individuellen AWS Kontos des Bucket-Besitzers oder der AWS Organisation des Bucket-Besitzers initiiert wird.

Anmerkung

Wenn Sie versuchen, ein Problem mit Berechtigungen zu beheben, beginnen Sie mit dem Abschnitt Beispiele für „Zugriff verweigert“-Meldungen und deren Behebung und gehen Sie dann zum entsprechenden Abschnitt Bucket-Richtlinien und IAM-Richtlinien. Beachten Sie außerdem die Anweisungen unter Tipps zum Überprüfen von Berechtigungen.

Beispiele für „Zugriff verweigert“-Meldungen und deren Behebung

Amazon S3 enthält jetzt zusätzlichen Kontext in „Zugriff verweigert“-Fehlern (HTTP 403 Forbidden) für Anforderungen, die an Ressourcen innerhalb desselben AWS-Konto gestellt werden. Dieser neue Kontext umfasst die Art der Richtlinie, die den Zugriff verweigert hat, den Grund für die Ablehnung und Informationen über den IAM-Benutzer oder die IAM-Rolle, die den Zugriff auf die Ressource angefordert hat.

Dieser zusätzliche Kontext hilft Ihnen bei der Behebung von Zugriffsproblemen, der Identifizierung der Hauptursache von „Zugriff verweigert“-Fehlern und bei der Behebung falscher Zugriffssteuerungen, indem Sie die entsprechenden Richtlinien aktualisieren. Dieser zusätzliche Kontext ist auch in AWS CloudTrail Protokollen verfügbar. Verbesserte Fehlermeldungen „Zugriff verweigert“ für Anfragen mit demselben Konto sind jetzt in allen Regionen verfügbar AWS-Regionen, auch in den Regionen China AWS GovCloud (US) Regions und China.

Die meisten Zugriffsverweigerungs-Fehlermeldungen haben das Format User user-arn is not authorized to perform action on "resource-arn" because context. In diesem Beispiel ist user-arn der Amazon-Ressourcenname (ARN) des Benutzers, der keinen Zugriff erhält, action ist die Serviceaktion, die von der Richtlinie verweigert wird, und resource-arn ist der ARN der Ressource, auf die sich die Richtlinie bezieht. Das Feld stellt zusätzlichen Kontext über den Richtlinientyp dar, der erklärt, warum die Richtlinie den Zugriff verweigert.

Wenn eine Richtlinie den Zugriff ausdrücklich verweigert, weil sie eine Deny-Anweisung enthält, enthält die Fehlermeldung „Zugriff verweigert“ den Ausdruck with an explicit deny in a type policy. Wenn die Richtlinie den Zugriff implizit verweigert, enthält die Fehlermeldung „Zugriff verweigert“ den Ausdruck because no type policy allows the action action.

Wichtig

  • Erweiterte „Zugriff-verweigert“-Meldungen werden nur für Anforderungen innerhalb desselben Kontos zurückgegeben. Bei kontoübergreifenden Anforderungen wird eine generische Access Denied-Meldung zurückgegeben.

    Informationen zur Richtlinienevaluierungslogik, die bestimmt, ob eine kontoübergreifende Zugriffsanforderung erlaubt oder verweigert wird, finden Sie unter Kontoübergreifende Richtlinienevaluierungslogik im IAM-Benutzerhandbuch. Eine Schritt-für-Schritt-Anleitung für die Gewährung von kontoübergreifendem Zugriff finden Sie unter Beispiel 2: Bucket-Eigentümer erteilt kontoübergreifende Bucket-Berechtigungen.

  • Erweiterte Fehlermeldungen bei „Zugriff verweigert“ werden für Anforderungen an Verzeichnis-Buckets nicht zurückgegeben. Verzeichnis-Bucket-Anforderungen geben eine generische Access Denied-Meldung zurück.

  • Wenn mehrere Richtlinien desselben Richtlinientyps eine Autorisierungsanforderung verweigern, gibt die Fehlermeldung „Zugriff verweigert“ die Anzahl der Richtlinien nicht an.

  • Wenn mehrere Richtlinientypen eine Autorisierungsanforderung verweigern, enthält die Fehlermeldung nur einen dieser Richtlinientypen.

  • Wenn eine Zugriffsanfrage aus mehreren Gründen verweigert wird, enthält die Fehlermeldung nur einen der Gründe für die Ablehnung.

Die folgenden Beispiele zeigen das Format für verschiedene Arten von „Zugriff verweigert“-Fehlermeldungen und wie Sie jede Art von Meldung beheben können.

Zugriff aufgrund einer Ressourcenkontrollrichtlinie verweigert – explizite Verweigerung

  1. Suchen Sie in Ihren Ressourcenkontrollrichtlinien nach einer Deny Erklärung zu der Maßnahme ()RCPs. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre RCP, indem Sie die Deny-Anweisung entfernen. Weitere Informationen finden Sie unter Aktualisieren einer Ressourcenkontrollrichtlinie (RCP) im AWS Organizations -Benutzerhandbuch. 

An error occurred (AccessDenied) when calling the GetObject operation: 
User: arn:aws:iam::777788889999: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 control policy

Zugriffsverweigerung aufgrund einer Service-Kontrollrichtlinie – implizite Verweigerung

  1. Suchen Sie in Ihren Richtlinien zur Servicesteuerung nach einer fehlenden Allow Erklärung für die Aktion (SCPs). Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre SCP, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter -Over-the-Air-Updates im AWS Organizations -Leitfaden.

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

Zugriffsverweigerung aufgrund einer Service-Kontrollrichtlinie – explizite Verweigerung

  1. Suchen Sie in Ihren Servicesteuerungsrichtlinien (SCPs) nach einer Deny Erklärung für die Aktion. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre SCP, indem Sie die Deny-Anweisung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Ein Beispiel dafür, wie Sie dies tun können, finden Sie unter Verhindern, dass IAM-Benutzer und -Rollen bestimmte Änderungen vornehmen, mit Ausnahme für eine angegebene Administratorrolle im AWS Organizations -Benutzerhandbuch. Weitere Informationen zum Aktualisieren Ihrer SCP finden Sie unter Aktualisieren einer SCP im AWS Organizations -Benutzerhandbuch.

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

Zugriff aufgrund einer VPC-Endpunktrichtlinie verweigert – implizite Ablehnung

  1. Überprüfen Sie in Ihren Virtual Private Cloud (VPC)-Endpunktrichtlinien, ob eine Allow-Anweisung für die Aktion fehlt. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre VPC-Endpunktrichtlinie, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter Aktualisieren einer VPC-Endpunktrichtlinie im AWS PrivateLink -Handbuch.

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

Zugriff aufgrund einer VPC-Endpunktrichtlinie verweigert – explizite Ablehnung

  1. Überprüfen Sie, ob in Ihren Virtual Private Cloud (VPC)-Endpunktrichtlinien eine explizite Deny-Anweisung für die Aktion vorhanden ist. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre VPC-Endpunktrichtlinie, indem Sie die Deny-Anweisung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny-Anweisung beispielsweise so aktualisieren, dass der aws:PrincipalAccount-Bedingungsschlüssel zusammen mit dem StringNotEquals-Bedingungsoperator verwendet wird, um dem jeweiligen Hauptbenutzer Zugriff zu gewähren, wie unter Beispiel 7: Ausschließen bestimmter Prinzipale aus einer Deny-Anweisung gezeigt. Weitere Informationen zur Aktualisierung Ihrer VPC-Endpunktrichtlinie finden Sie unter Aktualisieren einer VPC-Endpunktrichtlinie im AWS PrivateLink -Handbuch.

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

Zugriff aufgrund einer Berechtigungsgrenze verweigert – implizite Ablehnung

  1. Überprüfen Sie, ob in Ihrer Berechtigungsgrenze eine Allow-Anweisung für die Aktion fehlt. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Berechtigungsgrenze, indem Sie die Allow-Anweisung zu Ihrer IAM-Richtlinie hinzufügen. Weitere Informationen finden Sie unter Berechtigungsgrenzen für IAM-Entitäten und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriff aufgrund einer Berechtigungsgrenze verweigert – explizite Ablehnung

  1. Überprüfen Sie, ob in Ihren Berechtigungsgrenzen eine explizite Deny-Anweisung für die Aktion vorhanden ist. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Berechtigungsgrenze, indem Sie die Deny-Anweisung in Ihrer IAM-Richtlinie ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny-Anweisung beispielsweise so aktualisieren, dass der aws:PrincipalAccount-Bedingungsschlüssel zusammen mit dem StringNotEquals-Bedingungsoperator verwendet wird, um dem jeweiligen Hauptbenutzer Zugriff zu gewähren, wie unter aws:PrincipalAccount im IAM-Benutzerhandbuch gezeigt. Weitere Informationen finden Sie unter Berechtigungsgrenzen für IAM-Entitäten und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriff aufgrund von Sitzungsrichtlinien verweigert – implizite Ablehnung

  1. Überprüfen Sie, ob in Ihren Sitzungsrichtlinien eine Allow-Anweisung für die Aktion fehlt. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Sitzungsrichtlinie, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter Sitzungsrichtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriff aufgrund von Sitzungsrichtlinien verweigert – explizite Ablehnung

  1. Überprüfen Sie, ob in Ihren Sitzungsrichtlinien eine explizite Deny-Anweisung für die Aktion vorhanden ist. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Sitzungsrichtlinie, indem Sie die Deny-Anweisung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny-Anweisung beispielsweise so aktualisieren, dass der aws:PrincipalAccount-Bedingungsschlüssel zusammen mit dem StringNotEquals-Bedingungsoperator verwendet wird, um dem jeweiligen Hauptbenutzer Zugriff zu gewähren, wie unter Beispiel 7: Ausschließen bestimmter Prinzipale aus einer Deny-Anweisung gezeigt. Weitere Informationen zur Aktualisierung Ihrer Sitzungsrichtlinie finden Sie unter Sitzungsrichtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriff aufgrund ressourcenbasierter Richtlinien verweigert – implizite Ablehnung

Anmerkung

Unter ressourcenbasierten Richtlinien sind Richtlinien wie Bucket-Richtlinien und Zugangspunkt-Richtlinien zu verstehen.

  1. Überprüfen Sie, ob in Ihrer ressourcenbasierten Richtlinie eine Allow-Anweisung für die Aktion fehlt. Prüfen Sie auch, ob die Einstellung „IgnorePublicAcls S3 Block Public Access“ auf Bucket-, Zugangspunkt- oder Kontoebene angewendet wird. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter Ressourcenbasierte Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

    Möglicherweise müssen Sie auch Ihre Einstellung IgnorePublicAcls zum Blockieren des öffentlichen Zugriffs für den Bucket, Zugangspunkt oder das Konto anpassen. Weitere Informationen erhalten Sie unter Zugriffsverweigerung aufgrund von Einstellungen für „Öffentlichen Zugriff blockieren“ und Konfigurieren von Block-Public-Access-Einstellungen für Ihre S3-Buckets.

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

Zugriff aufgrund ressourcenbasierter Richtlinien verweigert – explizite Ablehnung

Anmerkung

Unter ressourcenbasierten Richtlinien sind Richtlinien wie Bucket-Richtlinien und Zugangspunkt-Richtlinien zu verstehen.

  1. Suchen Sie nach einer expliziten Deny-Anweisung für die Aktion in Ihrer ressourcenbasierten Richtlinie. Prüfen Sie auch, ob die Einstellung „RestrictPublicBuckets S3 Block Public Access“ auf Bucket-, Zugangspunkt- oder Kontoebene angewendet wird. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Deny-Anweisung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny-Anweisung beispielsweise so aktualisieren, dass der aws:PrincipalAccount-Bedingungsschlüssel zusammen mit dem StringNotEquals-Bedingungsoperator verwendet wird, um dem jeweiligen Hauptbenutzer Zugriff zu gewähren, wie unter Beispiel 7: Ausschließen bestimmter Prinzipale aus einer Deny-Anweisung gezeigt. Weitere Informationen zur Aktualisierung Ihrer ressourcenbasierten Richtlinie finden Sie unter Ressourcenbasierte Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

    Möglicherweise müssen Sie auch Ihre Einstellung RestrictPublicBuckets zum Blockieren des öffentlichen Zugriffs für den Bucket, Zugangspunkt oder das Konto anpassen. Weitere Informationen erhalten Sie unter Zugriffsverweigerung aufgrund von Einstellungen für „Öffentlichen Zugriff blockieren“ und Konfigurieren von Block-Public-Access-Einstellungen für Ihre S3-Buckets.

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

Zugriff aufgrund identitätsbasierter Richtlinien verweigert – implizite Verweigerung

  1. Überprüfen Sie ob in identitätsbasierten Richtlinien, die der Identität angefügt sind, eine Allow-Anweisung für die Aktion fehlt. Im folgenden Beispiel ist die Aktion s3:GetObject dem Benutzer MaryMajor zugeordnet.

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter Identitätsbasierte Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriff aufgrund identitätsbasierter Richtlinien verweigert – explizite Ablehnung

  1. Überprüfen Sie, ob in identitätsbasierten Richtlinien, die der Identität angefügt sind, eine explizite Deny-Anweisung für die Aktion vorhanden ist. Im folgenden Beispiel ist die Aktion s3:GetObject dem Benutzer MaryMajor zugeordnet.

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Deny-Anweisung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny-Anweisung beispielsweise so aktualisieren, dass der aws:PrincipalAccount-Bedingungsschlüssel zusammen mit dem StringNotEquals-Bedingungsoperator verwendet wird, um dem jeweiligen Hauptbenutzer Zugriff zu gewähren, wie unter aws:PrincipalAccount im IAM-Benutzerhandbuch gezeigt. Weitere Informationen finden Sie unter Identitätsbasierte Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

Zugriffsverweigerung aufgrund von Einstellungen für „Öffentlichen Zugriff blockieren“

Die Amazon S3 Block Public Access-Funktion bietet Einstellungen für Zugriffspunkte, Buckets und Konten, mit denen Sie den öffentlichen Zugriff auf Amazon-S3-Ressourcen verwalten können. Weitere Informationen dazu, wie „öffentlich“ in Amazon S3 definiert ist, finden Sie unter Die Bedeutung von „öffentlich“.

Standardmäßig erlauben neue Buckets, Zugriffspunkte und Objekte keinen öffentlichen Zugriff. Benutzer können jedoch Bucket-Richtlinien, Zugriffspunktrichtlinien, IAM-Benutzerrichtlinien, Objektberechtigungen oder Zugriffskontrolllisten (ACLs) ändern, um den öffentlichen Zugriff zu ermöglichen. Die Einstellungen von S3 Block Public Access haben Vorrang vor diesen Richtlinien, Berechtigungen und ACLs. Seit April 2023 sind alle Einstellungen für Block Public Access für neue Buckets standardmäßig aktiviert.

Wenn Amazon S3 eine Anforderung zum Zugriff auf einen Bucket oder ein Objekt erhält, wird ermittelt, ob für den Bucket oder das Konto des Bucket-Eigentümers eine Block Public Access-Einstellung vorliegt. Wenn die Anforderung über einen Zugriffspunkt einging, prüft Amazon S3 auch auf Block Public Access-Einstellungen für den Zugriffspunkt. Wenn eine Block Public Access-Einstellung vorhanden ist, die den angeforderten Zugriff verbietet, lehnt Amazon S3 die Anforderung ab.

Amazon S3 Block Public Access bietet vier Einstellungen. Diese Einstellungen sind voneinander unabhängig und können in beliebiger Kombination verwendet werden. Jede Einstellung kann auf einen Access Point, einen Bucket oder ein ganzes AWS Konto angewendet werden. Wenn sich die Block Public Access-Einstellungen für den Zugriffspunkt, den Bucket oder das Konto unterscheiden, wendet Amazon S3 die restriktivste Kombination der Zugriffspunkt-, Bucket- und Kontoeinstellungen an.

Wenn Amazon S3 ermittelt, ob eine Operation von einer Block Public Access-Einstellung untersagt wird, werden alle Anforderungen abgelehnt, die gegen eine Zugriffspunkt-, Bucket- oder Konto-Einstellung verstoßen.

Die vier von Amazon S3 Block Public Access bereitgestellten Einstellungen lauten wie folgt:

  • BlockPublicAcls – Diese Einstellung gilt für die Anforderungen PutBucketAcl, PutObjectAcl, PutObject, CreateBucket, CopyObject und POST Object. Die BlockPublicAcls-Einstellung hat folgende Verhaltensweise zur Folge:

    • PutBucketAcl- und PutObjectAcl-Aufrufe schlagen fehl, wenn die angegebene Zugriffssteuerungsliste (ACL) öffentlich ist.

    • PutObject-Aufrufe schlagen fehl, wenn die Anforderung eine öffentliche ACL enthält.

    • Wenn diese Einstellung auf ein Konto angewendet wird, schlagen CreateBucket-Aufrufe mit einer HTTP-400-Antwort (Bad Request) fehl, wenn die Anfrage eine öffentliche ACL enthält.

    Wenn beispielsweise der Zugriff auf eine CopyObject-Anforderung aufgrund der BlockPublicAcls-Einstellung verweigert wird, erhalten Sie die folgende Meldung: 

    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— Die IgnorePublicAcls Einstellung veranlasst Amazon S3, alle öffentlichen ACLs Informationen in einem Bucket und alle darin enthaltenen Objekte zu ignorieren. Wenn die Berechtigung Ihrer Anforderung nur von einer öffentlichen ACL erteilt wird, weist die IgnorePublicAcls-Einstellung die Anforderung zurück.

    Jede Ablehnung, die sich aus der IgnorePublicAcls-Einstellung ergibt, ist implizit. Wenn beispielsweise IgnorePublicAcls eine GetObject-Anforderung aufgrund einer öffentlichen ACL ablehnt, erhalten Sie die folgende Meldung: 

    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 – Diese Einstellung gilt für PutBucketPolicy- und PutAccessPointPolicy-Anforderungen.

    Das Festlegen von BlockPublicPolicy für einen Bucket führt dazu, dass Amazon S3 Aufrufe von PutBucketPolicy ablehnt, wenn die angegebene Bucket-Richtlinie öffentlichen Zugriff erlaubt. Diese Einstellung führt auch dazu, dass Amazon S3 Aufrufe der PutAccessPointPolicy für alle Zugangspunkte desselben Kontos des Buckets ablehnt, wenn die angegebene Richtlinie öffentlichen Zugriff erlaubt.

    Das Festlegen von BlockPublicPolicy für einen Zugangspunkt führt dazu, dass Amazon S3 Aufrufe von PutAccessPointPolicy und PutBucketPolicy, die über den Zugangspunkt erfolgen, ablehnt, wenn die angegebene Richtlinie (für den Zugangspunkt oder den zugrunde liegenden Bucket) öffentlichen Zugriff erlaubt.

    Wenn beispielsweise der Zugriff auf eine PutBucketPolicy-Anforderung aufgrund der BlockPublicPolicy-Einstellung verweigert wird, erhalten Sie die folgende Meldung: 

    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— Die RestrictPublicBuckets Einstellung beschränkt den Zugriff auf einen Access Point oder Bucket mit einer öffentlichen Richtlinie nur auf AWS-Service Prinzipale und autorisierte Benutzer innerhalb des Kontos des Bucket-Besitzers und des Kontos des Access Point-Besitzers. Diese Einstellung blockiert den gesamten kontoübergreifenden Zugriff auf den Access Point oder Bucket (außer durch AWS-Service Principals), ermöglicht aber dennoch Benutzern innerhalb des Kontos, den Access Point oder Bucket zu verwalten. Diese Einstellung weist auch alle anonymen (oder unsignierten) Aufrufe zurück.

    Jede Ablehnung, die sich aus der RestrictPublicBuckets-Einstellung ergibt, ist explizit. Wenn RestrictPublicBuckets beispielsweise eine GetObject-Anforderung aufgrund einer öffentlichen Bucket- oder Zugangspunktrichtlinie verweigert, erhalten Sie die folgende Meldung: 

    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

Weitere Informationen zu diesen Einstellungen finden Sie unter Block Public Access-Einstellungen. Informationen zum Überprüfen und Aktualisieren dieser Einstellungen finden Sie unter Verwenden von Block Public Access.

Bucket-Richtlinien und IAM-Richtlinien

Vorgänge auf Bucket-Ebene

Wenn keine Bucket-Richtlinie vorhanden ist, lässt der Bucket implizit Anfragen von beliebigen AWS Identity and Access Management (IAM-) Identitäten im Konto des Bucket-Besitzers zu. Ebenso lehnt der Bucket implizit Anforderungen von anderen IAM-Identitäten von anderen Konten sowie anonyme (unsignierte) Anforderungen ab. Wenn jedoch keine IAM-Benutzerrichtlinie vorhanden ist, wird dem Anforderer (es sei denn, er ist der AWS-Konto Root-Benutzer) implizit untersagt, Anfragen zu stellen. Weitere Informationen zu dieser Evaluierungslogik finden Sie unter Ermitteln, ob eine Anforderung innerhalb eines Kontos zugelassen oder verweigert wird im IAM-Benutzerhandbuch.

Vorgänge auf Objektebene

Wenn das Objekt dem Konto gehört, das den Bucket besitzt, funktionieren die Bucket-Richtlinie und die IAM-Benutzerrichtlinie für Vorgänge auf Objektebene genauso wie für Vorgänge auf Bucket-Ebene. Wenn es beispielsweise keine Bucket-Richtlinie gibt, lässt der Bucket implizit Objektanforderungen von jeder IAM-Identität in dem Konto zu, das im Besitz des Buckets ist. Ebenso lehnt der Bucket implizit Objektanforderungen von anderen IAM-Identitäten von anderen Konten sowie anonyme (unsignierte) Anforderungen ab. Wenn jedoch keine IAM-Benutzerrichtlinie vorhanden ist, wird dem Anforderer (es sei denn, er ist der AWS-Konto Root-Benutzer) implizit untersagt, Objektanforderungen zu stellen.

Wenn das Objekt einem externen Konto gehört, kann der Zugriff auf das Objekt nur über Objektzugriffskontrolllisten () gewährt werden. ACLs Die Bucket-Richtlinie und die IAM-Benutzerrichtlinie können weiterhin verwendet werden, um Objektanforderungen zu verweigern.

Stellen Sie daher sicher, dass die folgenden Voraussetzungen erfüllt sind, um sicherzugehen, dass Ihre Bucket-Richtlinie oder IAM-Benutzerrichtlinie keinen „Zugriff verweigert“-Fehler (403 Forbidden) verursacht:

  • Für den Zugriff auf dasselbe Konto darf es weder in der Bucket-Richtlinie noch in der IAM-Benutzerrichtlinie eine explizite Deny-Anweisung gegen den Anforderer geben, dem Sie Berechtigungen gewähren möchten. Wenn Sie Berechtigungen nur mithilfe der Bucket-Richtlinie und der IAM-Benutzerrichtlinie gewähren möchten, muss eine dieser Richtlinien mindestens eine explizite Allow-Anweisung enthalten.

  • Für den kontoübergreifenden Zugriff darf es weder in der Bucket-Richtlinie noch in der IAM-Benutzerrichtlinie eine explizite Deny-Anweisung gegen den Anforderer geben, dem Sie Berechtigungen gewähren möchten. Um kontoübergreifende Berechtigungen nur mit der Bucket-Richtlinie und der IAM-Benutzerrichtlinie zu gewähren, stellen Sie sicher, dass sowohl die Bucket-Richtlinie als auch die IAM-Benutzerrichtlinie des Anforderers eine explizite Allow-Anweisung enthalten.

Anmerkung

Allow-Anweisungen in einer Bucket-Richtlinie gelten nur für Objekte, die demselben Konto gehören, das im Besitz des Buckets ist. Deny-Anweisungen in einer Bucket-Richtlinie gelten jedoch für alle Objekte, unabhängig von der Objekteigentümerschaft.

So überprüfen oder bearbeiten Sie Ihre Bucket-Richtlinie
Anmerkung

Um eine Bucket-Richtlinie anzuzeigen oder zu bearbeiten, benötigen Sie die Berechtigung s3:GetBucketPolicy.

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon S3 S3-Konsole unter http://console.aws.amazon.com/s3/.

  2. Wählen Sie im linken Navigationsbereich Buckets aus.

  3. Wählen Sie in der Liste Buckets den Namen des Buckets aus, für den Sie eine Bucket-Richtlinie anzeigen oder bearbeiten möchten.

  4. Wählen Sie die Registerkarte Berechtigungen.

  5. Wählen Sie unter Bucket-Richtlinie Bearbeiten aus. Die Seite Bucket-Richtlinie bearbeiten wird angezeigt.

Um Ihre Bucket-Richtlinie mithilfe von AWS Command Line Interface (AWS CLI) zu überprüfen oder zu bearbeiten, verwenden Sie den get-bucket-policyBefehl.

Anmerkung

Wenn Sie aufgrund einer falschen Bucket-Richtlinie aus einem Bucket ausgesperrt werden, melden Sie sich mit Ihren AWS-Konto Root-Benutzeranmeldedaten bei dem AWS Management Console an. Um wieder Zugriff auf Ihren Bucket zu erhalten, stellen Sie sicher, dass Sie die falsche Bucket-Richtlinie mithilfe Ihrer AWS-Konto Root-Benutzeranmeldedaten löschen.

Tipps zum Überprüfen von Berechtigungen

Gehen Sie wie folgt vor, um zu überprüfen, ob der Anforderer über die erforderlichen Berechtigungen für die Ausführung einer Amazon-S3-Operation verfügt:

Amazon-S3-ACL-Einstellungen

Wenn Sie Ihre ACL-Einstellungen überprüfen, überprüfen Sie zunächst Ihre Einstellungen für den Objekteigentum, um zu überprüfen, ob sie für den Bucket aktiviert ACLs sind. Beachten Sie, dass ACL-Berechtigungen nur zur Erteilung von Berechtigungen und nicht zur Ablehnung von Anfragen verwendet werden können. ACLs kann auch nicht verwendet werden, um Anforderern Zugriff zu gewähren, die durch ausdrückliche Ablehnungen in Bucket-Richtlinien oder IAM-Benutzerrichtlinien abgelehnt wurden.

Die Einstellung für Object Ownership ist auf „Bucket-Eigentümer erzwungen“ gesetzt.

Wenn die Einstellung „Bucket Owner erforced“ aktiviert ist, ist es unwahrscheinlich, dass die ACL-Einstellungen zu einem Fehler „Zugriff verweigert“ (403 Forbidden) führen, da diese Einstellung alles deaktiviert ACLs, was für Buckets und Objekte gilt. „Bucket-Eigentümer erzwungen“ ist die Standardeinstellung (und empfohlene Einstellung) für Amazon-S3-Buckets.

Die Einstellung für Object Ownership ist auf „Bucket-Eigentümer bevorzugt“ oder „Objektschreiber“ gesetzt.

ACL-Berechtigungen sind weiterhin gültig, wenn die Einstellung „Bucket-Eigentümer bevorzugt“ oder „Objektschreiber“ verwendet wird. Es gibt zwei Arten von ACLs: Bucket ACLs und Objekt. ACLs Die Unterschiede zwischen diesen beiden Typen finden Sie unter Zuordnung von ACLs ACL-Berechtigungen und Zugriffsrichtlinienberechtigungen.

Überprüfen Sie abhängig von der Aktion der zurückgewiesenen Anforderung die ACL-Berechtigungen für Ihren Bucket oder das Objekt:

  • Wenn Amazon S3 eine LIST-, PUT (für ein Objekt), GetBucketAcl- oder PutBucketAcl-Anforderung zurückgewiesen hat, überprüfen Sie die ACL-Berechtigungen für Ihren Bucket.

    Anmerkung

    Mit den Bucket-ACL-Einstellungen können Sie keine GET-Objektberechtigungen gewähren.

  • Wenn Amazon S3 eine GET-Anforderung für ein S3-Objekt oder eine PutObjectAcl-Anforderung abgelehnt hat, überprüfen Sie die ACL-Berechtigungen für das Objekt.

    Wichtig

    Wenn es sich bei dem Konto, dem das Objekt gehört, nicht um das Konto handelt, das im Besitz des Buckets ist, wird der Zugriff auf das Objekt nicht durch die Bucket-Richtlinie gesteuert.

Beheben eines Fehlers aufgrund einer Zugriffsverweigerung (403 Forbidden) bei einer GET-Objekt-Anforderung während einer kontoübergreifenden Objekteigentümerschaft

Überprüfen Sie die Einstellungen für Object Ownership des Buckets, um den Objekteigentümer zu ermitteln. Wenn Sie Zugriff auf das Objekt haben ACLs, können Sie auch das Konto des Objekteigentümers überprüfen. (Um das Konto des Objekteigentümers einzusehen, überprüfen Sie die Objekt-ACL-Einstellung in der Amazon-S3-Konsole.) Alternativ können Sie auch eine GetObjectAcl-Anforderung stellen, um die kanonische ID des Objekteigentümers zu ermitteln und so das Konto des Objekteigentümers überprüfen zu können. ACLs Erteilen Sie dem Konto des Objekteigentümers standardmäßig explizite Genehmigungsberechtigungen für GET Anfragen.

Nachdem Sie bestätigt haben, dass der Objekteigentümer nicht mit dem Bucket-Eigentümer identisch ist, wählen Sie je nach Anwendungsfall und Zugriffsebene eine der folgenden Methoden aus, um den Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) zu beheben:

  • Deaktivieren ACLs (empfohlen) — Diese Methode gilt für alle Objekte und kann vom Bucket-Besitzer ausgeführt werden. Bei dieser Methode erhält der Bucket-Eigentümer automatisch das Eigentum an jedem Objekt im Bucket und die volle Kontrolle darüber. Bevor Sie diese Methode implementieren, überprüfen Sie die Voraussetzungen für die Deaktivierung ACLs. Informationen dazu, wie Sie Ihren Bucket auf den Modus „Bucket-Eigentümer erzwungen“ (empfohlen) setzen, finden Sie unter Einstellung für Object Ownership für einen vorhandenen Bucket.

    Wichtig

    Um zu verhindern, dass der Fehler Zugriff verweigert (403 Forbidden) auftritt, sollten Sie vor der Deaktivierung ACLs die ACL-Berechtigungen auf eine Bucket-Richtlinie migrieren. Weitere Informationen finden Sie unter Beispiele für Bucket-Richtlinien für die Migration von ACL-Berechtigungen.

  • Objekteigentümer in Bucket-Eigentümer ändern – Diese Methode kann auf einzelne Objekte angewendet werden, doch nur der Objekteigentümer (oder ein Benutzer mit den entsprechenden Berechtigungen) kann die Eigentümerschaft eines Objekts ändern. Es können zusätzliche PUT-Kosten anfallen. (Weitere Informationen finden Sie unter Amazon S3 – Preise.) Diese Methode gewährt dem Bucket-Eigentümer das vollständige Eigentum an dem Objekt, sodass der Bucket-Eigentümer den Zugriff auf das Objekt über eine Bucket-Richtlinie steuern kann.

    Führen Sie einen der folgenden Schritte aus, um die Objekteigentümerschaft zu ändern:

    • Sie (der Bucket-Eigentümer) können das Objekt wieder in den Bucket kopieren.

    • Sie können die Einstellung für Object Ownership des Buckets auf „Bucket-Eigentümer bevorzugt“ setzen. Wenn die Versionsverwaltung deaktiviert ist, werden die Objekte im Bucket überschrieben. Wenn die Versionsverwaltung aktiviert ist, werden doppelte Versionen desselben Objekts im Bucket angezeigt, für die der Bucket-Eigentümer eine Lebenszyklusregel festlegen kann, damit sie ablaufen. Anweisungen zum Ändern der Einstellung für Object Ownership finden Sie unter Einstellung für Object Ownership für einen vorhandenen Bucket.

      Anmerkung

      Wenn Sie Ihre Einstellung für Object Ownership in „Bucket-Eigentümer bevorzugt“ aktualisieren, wird die Einstellung nur auf neue Objekte angewendet, die in den Bucket hochgeladen werden.

    • Sie können den Objekteigentümer das Objekt mit der vordefinierten Objekt-ACL bucket-owner-full-control erneut hochladen lassen.

    Anmerkung

    Für kontoübergreifende Uploads können Sie in Ihrer Bucket-Richtlinie auch die vordefinierte Objekt-ACL bucket-owner-full-control verlangen. Ein Beispiel für eine Bucket-Richtlinie finden Sie unter Erteilung von kontoübergreifenden Berechtigungen für das Hochladen von Objekten, wobei sichergestellt wird, dass der Bucket-Eigentümer volle Kontrolle besitzt.

  • Objektschreiber als Objekteigentümer beibehalten – Mit dieser Methode wird der Objekteigentümer nicht geändert, Sie können jedoch den Zugriff auf Objekte einzeln gewähren. Um Zugriff auf ein Objekt zu gewähren, müssen Sie über die Berechtigung PutObjectAcl für das Objekt verfügen. Um dann den Fehler Zugriff verweigert (403 Forbidden) zu beheben, fügen Sie den Anforderer als Empfänger für den Zugriff auf das Objekt im Objekt hinzu. ACLs Weitere Informationen finden Sie unter Konfiguration ACLs.

S3–Block-Public-Access-Einstellungen

Wenn die fehlgeschlagene Anforderung öffentlichen Zugriff oder öffentliche Richtlinien beinhaltet, überprüfen Sie die S3-Block-Public-Access-Einstellungen in Ihrem Konto, Bucket oder Zugangspunkt. Weitere Informationen zur Behebung von Fehlern im Zusammenhang mit S3-Block-Public-Access-Einstellungen finden Sie unter Zugriffsverweigerung aufgrund von Einstellungen für „Öffentlichen Zugriff blockieren“.

Amazon-S3-Verschlüsselungseinstellungen

Amazon S3 unterstützt die serverseitige Verschlüsselung in Ihrem Bucket. Serverseitige Verschlüsselung ist die Verschlüsselung von Daten am Zielort durch die Anwendung oder den Service, der sie erhält. Amazon S3 verschlüsselt Ihre Daten auf Objektebene, wenn es sie auf Festplatten in AWS Rechenzentren schreibt, und entschlüsselt sie für Sie, wenn Sie darauf zugreifen.

Standardmäßig wendet Amazon S3 jetzt eine serverseitige Verschlüsselung mit von Amazon S3 verwalteten Schlüsseln (SSE-S3) als Basisverschlüsselung für jeden Bucket in Amazon S3 an. Amazon S3 ermöglicht es Ihnen auch, die serverseitige Verschlüsselungsmethode beim Hochladen von Objekten anzugeben.

So überprüfen Sie den Status der serverseitigen Verschlüsselung und die Verschlüsselungseinstellungen Ihres Buckets

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon S3 S3-Konsole unter http://console.aws.amazon.com/s3/.

  2. Wählen Sie im linken Navigationsbereich Buckets aus.

  3. Wählen Sie in der Liste Buckets den Bucket aus, für den Sie die Verschlüsselungseinstellungen überprüfen möchten.

  4. Wählen Sie die Registerkarte Eigenschaften aus.

  5. Scrollen Sie nach unten zum Abschnitt Standardverschlüsselung und sehen Sie sich die Einstellungen für den Verschlüsselungstyp an.

Um Ihre Verschlüsselungseinstellungen mithilfe von zu überprüfen AWS CLI, verwenden Sie den get-bucket-encryptionBefehl.

So überprüfen Sie den Verschlüsselungsstatus eines Objekts

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon S3 S3-Konsole unter http://console.aws.amazon.com/s3/.

  2. Wählen Sie im linken Navigationsbereich Buckets aus.

  3. Wählen Sie in der Liste Buckets den Namen des Buckets aus, der das Objekt enthält.

  4. Wählen Sie in der Liste Objekte den Namen des Objekts aus, für das Sie eine Verschlüsselung hinzufügen oder ändern möchten.

    Die Seite mit den Objektdetails wird angezeigt.

  5. Scrollen Sie nach unten zum Abschnitt Serverseitige Verschlüsselungseinstellungen, um die serverseitigen Verschlüsselungseinstellungen des Objekts anzuzeigen.

Um den Verschlüsselungsstatus Ihres Objekts mithilfe von zu überprüfen AWS CLI, verwenden Sie den head-objectBefehl.

Verschlüsselungs- und Berechtigungsanforderungen

Amazon S3 unterstützt drei Arten von serverseitiger Verschlüsselung:

  • Serverseitige Verschlüsselung mit von Amazon S3 verwalteten Schlüsseln (SSE-S3)

  • Serverseitige Verschlüsselung mit AWS Key Management Service (AWS KMS) Schlüsseln (SSE-KMS)

  • Serverseitige Verschlüsselung mit vom Kunden bereitgestellten Schlüsseln (SSE-C)

Stellen Sie unter Berücksichtigung Ihrer Verschlüsselungseinstellungen sicher, dass die folgenden Berechtigungen erfüllt sind:

  • SSE-S3 – Es sind keine zusätzlichen Berechtigungen erforderlich.

  • SSE-KMS (mit einem vom Kunden verwalteten Schlüssel) – Um Objekte hochzuladen, wird die Berechtigung kms:GenerateDataKey für AWS KMS key benötigt. Um Objekte herunterzuladen und mehrteilige Uploads von Objekten durchzuführen, ist die Berechtigung kms:Decrypt für den KMS-Schlüssel erforderlich.

  • SSE-KMS (mit einem Von AWS verwalteter Schlüssel) — Der Anforderer muss aus demselben Konto stammen, dem der KMS-Schlüssel gehört. aws/s3 Der Anforderer muss außerdem über die richtigen Amazon-S3-Berechtigungen verfügen, um auf das Objekt zugreifen zu können.

  • SSE-C (mit einem vom Kunden bereitgestellten Schlüssel) – Es sind keine zusätzlichen Berechtigungen erforderlich. Sie können die Bucket-Richtlinie so konfigurieren, dass eine serverseitige Verschlüsselung mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln für Objekte in Ihrem Bucket erforderlich und beschränkt ist.

Wenn das Objekt mit einem vom Kunden verwalteten Schlüssel verschlüsselt ist, stellen Sie sicher, dass es Ihnen die KMS-Schlüsselrichtlinie gestattet, die Aktionen kms:GenerateDataKey oder kms:Decrypt auszuführen. Anweisungen zur Überprüfung Ihrer KMS-Schlüsselrichtlinie finden Sie unter Anzeigen einer Schlüsselrichtlinie im AWS Key Management Service -Entwicklerhandbuch.

S3-Einstellungen für die Objektsperre

Wenn in Ihrem Bucket die S3-Objektsperre aktiviert ist und das Objekt durch einen Aufbewahrungszeitraum oder eine rechtliche Aufbewahrungspflicht geschützt ist, gibt Amazon S3 beim Versuch, das Objekt zu löschen, einen Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) zurück.

So überprüfen Sie, ob für den Bucket eine Objektsperre aktiviert ist

  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die Amazon S3 S3-Konsole unter http://console.aws.amazon.com/s3/.

  2. Wählen Sie im linken Navigationsbereich Buckets aus.

  3. Wählen Sie in der Liste Buckets den Namen des Buckets aus, den Sie überprüfen möchten.

  4. Wählen Sie die Registerkarte Eigenschaften aus.

  5. Scrollen Sie nach unten zum Abschnitt Objektsperre. Überprüfen Sie, ob die Einstellung für Objektsperre Aktiviert oder Deaktiviert lautet.

Um festzustellen, ob das Objekt durch einen Aufbewahrungszeitraum oder eine rechtliche Aufbewahrungspflicht geschützt ist, zeigen Sie die Sperrinformationen für Ihr Objekt an.

Wenn das Objekt durch einen Aufbewahrungszeitraum oder eine rechtliche Aufbewahrungspflicht geschützt ist, überprüfen Sie Folgendes:

  • Wenn die Objektversion durch den Compliance-Aufbewahrungsmodus geschützt ist, gibt es keine Möglichkeit, sie dauerhaft zu löschen. Eine permanente DELETE Anfrage von einem beliebigen Anforderer, einschließlich des AWS-Konto Root-Benutzers, führt zu der Fehlermeldung Access Denied (403 Forbidden). Beachten Sie außerdem, dass Amazon S3 eine Löschmarkierung für das Objekt erstellt, wenn Sie eine DELETE-Anforderung für ein Objekt einreichen, das durch den Compliance-Aufbewahrungsmodus geschützt ist.

  • Wenn die Objektversion durch den Governance-Aufbewahrungsmodus geschützt ist und Sie über die Berechtigung s3:BypassGovernanceRetention verfügen, können Sie den Schutz umgehen und die Version dauerhaft löschen. Weitere Informationen finden Sie unter Umgehen des Governance-Modus.

  • Wenn die Objektversion durch eine rechtliche Aufbewahrungspflicht geschützt ist, kann eine permanente DELETE-Anforderung zu einem Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) führen. Um die Objektversion dauerhaft zu löschen, müssen Sie die rechtliche Aufbewahrungspflicht für die Objektversion aufheben. Um eine rechtliche Aufbewahrungspflicht aufzuheben, benötigen Sie die Berechtigung s3:PutObjectLegalHold. Weitere Informationen zum Aufheben einer rechtlichen Aufbewahrungspflicht finden Sie unter Konfigurieren von S3 Object Lock.

VPC-Endpunktrichtlinien

Wenn Sie über einen Virtual Private Cloud (VPC)-Endpunkt auf Amazon S3 zugreifen, stellen Sie sicher, dass die VPC-Endpunktrichtlinie Sie nicht am Zugriff auf Ihre Amazon-S3-Ressourcen hindert. Standardmäßig erlaubt die VPC-Endpunktrichtlinie alle Anforderungen an Amazon S3. Sie können die VPC-Endpunktrichtlinie auch so konfigurieren, dass bestimmte Anforderungen eingeschränkt werden. Informationen darüber, wie Sie Ihre VPC-Endpunktrichtlinie überprüfen, finden Sie in den folgenden Ressourcen:

AWS Organizations Richtlinien

Wenn Sie zu einer Organisation AWS-Konto gehören, können AWS Organizations Richtlinien Sie daran hindern, auf Amazon S3 S3-Ressourcen zuzugreifen. Standardmäßig blockieren AWS Organizations Richtlinien keine Anfragen an Amazon S3. Stellen Sie jedoch sicher, dass Ihre AWS Organizations Richtlinien nicht so konfiguriert wurden, dass sie den Zugriff auf S3-Buckets blockieren. Anweisungen zur Überprüfung Ihrer AWS Organizations Richtlinien finden Sie in den folgenden Ressourcen:

Wenn Sie Ihre Bucket-Richtlinie für ein Mitgliedskonto falsch konfiguriert haben, um allen Benutzern den Zugriff auf Ihren S3-Bucket zu verweigern, können Sie den Bucket außerdem entsperren, indem Sie eine privilegierte Sitzung für das Mitgliedskonto in IAM starten. Sobald Sie eine privilegierte Sitzung gestartet haben, können Sie die falsch konfigurierte Bucket-Richtlinie löschen, um wieder Zugriff auf den Bucket zu erhalten. Weitere Informationen finden Sie im AWS Identity and Access Management Benutzerhandbuch unter Ausführen einer privilegierten Aufgabe für ein AWS Organizations Mitgliedskonto.

CloudFront Zugriff auf Vertrieb

Wenn Sie beim Versuch, über Ihre statische S3-Website auf Ihre statische S3-Website zuzugreifen, die Fehlermeldung „Zugriff verweigert“ (403 Forbidden) erhalten CloudFront, überprüfen Sie diese häufig auftretenden Probleme:

  • Haben Sie das richtige Format für den Ursprungs-Domainnamen?

    • Stellen Sie sicher, dass Sie das S3-Website-Endpunktformat (bucket-name.s3-website-region.amazonaws.com) und nicht den REST-API-Endpunkt verwenden

    • Stellen Sie sicher, dass statisches Website-Hosting in Ihrem Bucket aktiviert ist

  • Erlaubt Ihre Bucket-Richtlinie CloudFront Zugriff?

    • Stelle sicher, dass deine Bucket-Richtlinie Berechtigungen für Origin Access Identity (OAI) oder Origin Access Control (OAC) deiner CloudFront Distribution beinhaltet

    • Vergewissere dich, dass die Richtlinie die erforderlichen s3: -Berechtigungen beinhaltet GetObject

Weitere Schritte und Konfigurationen zur Fehlerbehebung, einschließlich der Einrichtung von Fehlerseiten und Protokolleinstellungen, finden Sie unter Warum erhalte ich die Fehlermeldung „403 access denied“, wenn ich einen Amazon S3 S3-Website-Endpunkt als Ursprung meiner CloudFront Distribution verwende? im AWS re:Post Knowledge Center.

Anmerkung

Dieser Fehler unterscheidet sich von 403-Fehlern, die Sie möglicherweise erhalten, wenn Sie direkt auf S3 zugreifen. Achten Sie bei CloudFront spezifischen Problemen darauf, sowohl Ihre CloudFront Distributionseinstellungen als auch Ihre S3-Konfigurationen zu überprüfen.

Zugriffspunkteinstellungen

Wenn Sie bei Anforderungen über Amazon-S3-Zugriffspunkte einen Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) erhalten, müssen Sie möglicherweise Folgendes überprüfen:

  • Die Konfigurationen Ihrer Zugriffspunkte

  • Die IAM-Benutzerrichtlinie, die für Ihre Zugriffspunkte verwendet wird

  • Die Bucket-Richtlinie, die zur Verwaltung oder Konfiguration Ihrer kontoübergreifenden Zugriffspunkte verwendet wird

Zugriffspunktkonfigurationen und -richtlinien

Wenn der Fehler Zugriff verweigert (403 Forbidden) weiterhin besteht, nachdem Sie alle Artikel in diesem Thema überprüft haben, rufen Sie Ihre Amazon S3 S3-Anforderungs-ID ab und wenden Sie sich an uns, um Support weitere Informationen zu erhalten.

Weitere Ressourcen

Weitere Hinweise zu den Fehlern „Zugriff verweigert“ (403 Forbidden) finden Sie in den folgenden Ressourcen: