Problembehandlung bei verweigertem Zugriff beheben (403 Forbidden) Fehler in Amazon S3 - Amazon Simple Storage Service
Beispiele für abgelehnte Nachrichten und deren BehebungBucket-Richtlinien und IAM RichtlinienAmazon S3 ACL S3-EinstellungenS3–Block-Public-Access-EinstellungenAmazon-S3-VerschlüsselungseinstellungenS3-Einstellungen für die ObjektsperreVPCEndpunktrichtlinienAWS Organizations RichtlinienZugriffspunkteinstellungen

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.

Problembehandlung bei verweigertem Zugriff beheben (403 Forbidden) Fehler in Amazon S3

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

  • Eine ausdrückliche Ablehnung tritt auf, 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 ablehnt, muss die Richtlinie dem Prinzipal ausdrücklich erlauben, eine Aktion auszuführen. Andernfalls verweigert die Richtlinie implizit den Zugriff. Weitere Informationen finden Sie im Benutzerhandbuch unter Der Unterschied zwischen expliziten und impliziten Verweigerungen. IAM Informationen zur Richtlinienbewertungslogik, die bestimmt, ob eine Zugriffsanforderung zulässig oder verweigert wird, finden Sie unter Bewertungslogik für Richtlinien im IAMBenutzerhandbuch.

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

Die folgenden Themen behandeln die häufigsten Ursachen für Fehler mit Zugriffsverweigerung in Amazon S3.

Anmerkung

Bei Fehlern mit Zugriff verweigert (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 Berechtigungsproblem zu beheben, beginnen Sie mit dem Beispiele für abgelehnte Nachrichten und deren Behebung Abschnitt und fahren Sie dann mit dem Bucket-Richtlinien und IAM Richtlinien Abschnitt fort. Achte außerdem darauf, die Anweisungen unter zu befolgenTipps zum Überprüfen von Berechtigungen.

Beispiele für abgelehnte Nachrichten und deren Behebung

Amazon S3 enthält jetzt zusätzlichen Kontext in Access Denied (HTTP403 Forbidden) -Fehler für Anfragen an Ressourcen innerhalb desselben AWS-Konto. 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 Rolle, der den Zugriff auf die Ressource angefordert hat.

Dieser zusätzliche Kontext hilft Ihnen bei der Behebung von Zugriffsproblemen, der Identifizierung der Hauptursache von Fehlern bei der Zugriffsverweigerung und bei der Behebung falscher Zugriffskontrollen, indem Sie die entsprechenden Richtlinien aktualisieren. Dieser zusätzliche Kontext ist auch in AWS CloudTrail Protokollen verfügbar. Verbesserte Fehlermeldungen mit dem Status „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: Benutzer-ARN ist der Amazon-Ressourcenname (ARN) des Benutzers, der keinen Zugriff erhält, action ist die Serviceaktion, die die Richtlinie verweigert, und resource-arn ist die ARN Ressource, auf die sich die Richtlinie bezieht. Das Tool context Das Feld steht für zusätzlichen Kontext zum Richtlinientyp, der erklärt, warum die Richtlinie den Zugriff verweigert hat.

Wenn eine Richtlinie den Zugriff ausdrücklich verweigert, weil die Richtlinie eine Deny Erklärung enthält, enthält die Fehlermeldung „Zugriff verweigert“ den folgenden Satzwith an explicit deny in a type policy. Wenn die Richtlinie implizit den Zugriff verweigert, enthält die Fehlermeldung „Zugriff verweigert“ den folgenden Satz. because no type policy allows the action action

Wichtig

  • Meldungen zur erweiterten Zugriffsverweigerung werden nur bei Anfragen für dasselbe Konto zurückgegeben. Bei kontoübergreifenden Anfragen wird eine generische Nachricht zurückgegeben. Access Denied

    Informationen zur Bewertungslogik für Richtlinien, mit der bestimmt wird, ob eine kontenübergreifende Zugriffsanfrage zulässig oder verweigert wird, finden Sie im Benutzerhandbuch unter Logik der IAM kontenübergreifenden Richtlinienbewertung. Eine exemplarische Vorgehensweise, die zeigt, wie Sie kontenübergreifenden Zugriff gewähren, finden Sie unter. Beispiel 2: Bucket-Eigentümer erteilt kontoübergreifende Bucket-Berechtigungen

  • Für Anfragen an Directory-Buckets werden keine Fehlermeldungen mit dem Status „Erweiterter Zugriff verweigert“ zurückgegeben. Directory-Bucket-Anfragen geben eine generische Access Denied Meldung zurück.

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

  • Wenn mehrere Richtlinientypen eine Autorisierungsanfrage ablehnen, enthält die Fehlermeldung nur einen dieser Richtlinientypen.

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

Die folgenden Beispiele zeigen das Format für die verschiedenen Arten von Fehlermeldungen mit Zugriffsverweigerung und die Problembehandlung der einzelnen Meldungstypen.

Der Zugriff wurde aufgrund einer Ressourcensteuerungsrichtlinie verweigert — explizite Ablehnung

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

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

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 Angabe für die Aktion (SCPs). Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre, SCP indem Sie die Allow Erklärung hinzufügen. Weitere Informationen finden Sie unter Aktualisieren von SCP im AWS Organizations Benutzerhandbuch.

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 Service Control-Richtlinien (SCPs) nach einer Deny Erklärung zu der Aktion. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre, SCP indem Sie die Deny Erklärung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Ein Beispiel dafür, wie Sie dies tun können, finden Sie im Benutzerhandbuch unter IAMVerhindern, dass Benutzer und Rollen bestimmte Änderungen vornehmen, mit einer Ausnahme für eine bestimmte Administratorrolle.AWS Organizations Weitere Informationen zur Aktualisierung Ihres SCP finden Sie unter Aktualisieren von 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. Suchen Sie in Ihren Virtual Private Cloud (VPC) -Endpunktrichtlinien nach einer fehlenden Allow Angabe für die Aktion. Für das folgende Beispiel lautet die Aktion s3:GetObject.

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

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. Suchen Sie in Ihren Virtual Private Cloud (VPC) -Endpunktrichtlinien nach einer ausdrücklichen Deny Erklärung für die Aktion. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre VPC Endpunktrichtlinie, indem Sie die Deny Erklärung ä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 gezeigtBeispiel 7: Bestimmte Hauptpersonen aus einer Deny Anweisung ausschließen. Weitere Informationen zur Aktualisierung Ihrer VPC Endpunktrichtlinie finden Sie im AWS PrivateLink Handbuch unter Aktualisieren einer VPC Endpunktrichtlinie.

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 Zugriffsgrenzen, indem Sie die Allow Erklärung zu Ihrer IAM Richtlinie hinzufügen. Weitere Informationen finden Sie unter Zugriffsgrenzen für IAM Entitäten und Bearbeiten von IAM Richtlinien im IAMBenutzerhandbuch.

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 Aussage 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. Weitere Informationen finden Sie unter Berechtigungsgrenzen für IAM Entitäten und IAMBearbeitungsrichtlinien im IAMBenutzerhandbuch.

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 IAMBearbeitungsrichtlinien im IAMBenutzerhandbuch.

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 Erklärung ä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 gezeigtBeispiel 7: Bestimmte Hauptpersonen aus einer Deny Anweisung ausschließen. Weitere Informationen zur Aktualisierung Ihrer Sitzungsrichtlinie finden Sie unter Sitzungsrichtlinien und IAMBearbeitungsrichtlinien im IAMBenutzerhandbuch.

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 Zugriffspunktrichtlinien 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-, Access Point- 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 IAMBearbeitungsrichtlinien im IAMBenutzerhandbuch.

    Möglicherweise müssen Sie auch Ihre Einstellung „Öffentlichen Zugriff IgnorePublicAcls blockieren“ für den Bucket, den Access Point oder das Konto anpassen. Weitere Informationen erhalten Sie unter Der Zugriff wurde aufgrund der Einstellungen zum Blockieren des öffentlichen Zugriffs verweigert 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 Zugriffspunktrichtlinien 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-, Access Point- oder Kontoebene angewendet wird. Für das folgende Beispiel lautet die Aktion s3:GetObject.

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Deny Erklärung ä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 gezeigtBeispiel 7: Bestimmte Hauptpersonen aus einer Deny Anweisung ausschließen. Weitere Informationen zur Aktualisierung Ihrer ressourcenbasierten Richtlinie finden Sie unter Ressourcenbasierte Richtlinien und IAM Bearbeitungsrichtlinien im Benutzerhandbuch. IAM

    Möglicherweise müssen Sie auch Ihre Einstellung „Öffentlichen Zugriff RestrictPublicBuckets sperren“ für den Bucket, den Access Point oder das Konto anpassen. Weitere Informationen erhalten Sie unter Der Zugriff wurde aufgrund der Einstellungen zum Blockieren des öffentlichen Zugriffs verweigert 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 an den Benutzer s3:GetObject angehängtMaryMajor.

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

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 an den Benutzer s3:GetObject angehängt. MaryMajor

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Deny Erklärung ändern, um dem Benutzer den erforderlichen Zugriff zu gewähren. Sie können Ihre Deny Erklärung 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. Weitere Informationen finden Sie unter Identitätsbasierte Richtlinien und IAMBearbeitungsrichtlinien im IAMBenutzerhandbuch.

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

Der Zugriff wurde aufgrund der Einstellungen zum Blockieren des öffentlichen Zugriffs verweigert

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 undACLs. Seit April 2023 sind alle Einstellungen für Block Public Access standardmäßig für neue Buckets 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 PutBucketAclPutObjectAcl,PutObject, CreateBucketCopyObject, und POST Object Anfragen. Die BlockPublicAcls Einstellung verursacht das folgende Verhalten:

    • PutBucketAclund PutObjectAcl Aufrufe schlagen fehl, wenn die angegebene Zugriffskontrollliste (ACL) öffentlich ist.

    • PutObjectAufrufe schlagen fehl, wenn die Anfrage ein öffentliches Objekt beinhaltetACL.

    • Wenn diese Einstellung auf ein Konto angewendet wird, schlagen CreateBucket Aufrufe mit einer HTTP 400 (Bad Request) -Antwort fehl, wenn die Anfrage ein öffentliches Objekt beinhaltetACL.

    Wenn beispielsweise der Zugriff auf eine CopyObject Anfrage 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 Genehmigung Ihrer Anfrage nur von einer Öffentlichkeit erteilt wirdACL, lehnt die IgnorePublicAcls Einstellung die Anfrage ab.

    Jede Ablehnung, die sich aus der IgnorePublicAcls Einstellung ergibt, ist implizit. Wenn Sie beispielsweise eine GetObject Anfrage aufgrund IgnorePublicAcls eines öffentlichen Zugriffs ablehnenACL, 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 PutAccessPointPolicy Anfragen PutBucketPolicy und.

    Die Einstellung BlockPublicPolicy für einen Bucket führt dazu, dass Amazon S3 Aufrufe ablehnt, PutBucketPolicy wenn die angegebene Bucket-Richtlinie öffentlichen Zugriff zulässt. Diese Einstellung veranlasst Amazon S3 auch, Anrufe an PutAccessPointPolicy alle Access Points des Buckets mit demselben Konto abzulehnen, wenn die angegebene Richtlinie öffentlichen Zugriff zulässt.

    Die Einstellung BlockPublicPolicy für einen Access Point veranlasst Amazon S3, Anrufe an PutAccessPointPolicy und über den Access Point getätigte Anrufe abzulehnenPutBucketPolicy, wenn die angegebene Richtlinie (entweder für den Access Point oder den zugrundeliegenden Bucket) den öffentlichen Zugriff zulässt.

    Wenn beispielsweise der Zugriff auf eine PutBucketPolicy Anfrage 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 Accounts 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 dieser RestrictPublicBuckets Einstellung ergibt, ist explizit. Wenn beispielsweise eine GetObject Anfrage aufgrund einer RestrictPublicBuckets öffentlichen Bucket- oder Access-Point-Richtlinie abgelehnt wird, 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 unterVerwenden von Block Public Access.

Bucket-Richtlinien und IAM Richtlinien

Vorgänge auf Bucket-Ebene

Wenn keine Bucket-Richtlinie vorhanden ist, erlaubt der Bucket implizit Anfragen von einer beliebigen AWS Identity and Access Management (IAM) Identität im Konto des Bucket-Besitzers. Der Bucket lehnt auch implizit Anfragen von anderen IAM Identitäten von anderen Konten sowie anonyme (unsignierte) Anfragen 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 Bewertungslogik finden Sie im IAMBenutzerhandbuch unter Feststellen, ob eine Anfrage innerhalb eines Kontos abgelehnt oder zulässig ist.

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 Operationen auf Objektebene genauso wie für Operationen auf Bucket-Ebene. Wenn beispielsweise keine Bucket-Richtlinie vorhanden ist, lässt der Bucket implizit Objektanforderungen von beliebigen Identitäten im Konto des Bucket-Besitzers zu. IAM Der Bucket lehnt auch implizit Objektanfragen von anderen IAM Identitäten aus anderen Konten sowie anonyme (unsignierte) Anfragen 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 () ACLs gewährt werden. Die Bucket-Richtlinie und die IAM Benutzerrichtlinie können weiterhin verwendet werden, um Objektanforderungen abzulehnen.

Um sicherzustellen, dass Ihre Bucket-Richtlinie oder IAM Benutzerrichtlinie nicht den Fehler Access Denied (403 Forbidden) verursacht, stellen Sie daher sicher, dass die folgenden Anforderungen erfüllt sind:

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

  • Für kontoübergreifenden Zugriff darf es weder in der Bucket-Richtlinie noch in der IAM Benutzerrichtlinie eine ausdrückliche Deny Aussage gegen den Antragsteller geben, dem Sie Berechtigungen erteilen möchten. Wenn Sie kontoübergreifende Berechtigungen nur mithilfe der Bucket-Richtlinie und der IAM Benutzerrichtlinie gewähren möchten, stellen Sie sicher, dass sowohl die Bucket-Richtlinie als auch die IAM Benutzerrichtlinie des Anforderers eine ausdrückliche Erklärung enthalten. Allow

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 https://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 die 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 S3-Einstellungen

Überprüfen Sie bei der Überprüfung Ihrer ACL Einstellungen zunächst Ihre Einstellungen für Object Ownership, um zu überprüfen, ob ACLs sie für den Bucket aktiviert sind. Beachten Sie, dass ACL Berechtigungen nur zur Erteilung von Berechtigungen und nicht zur Ablehnung von Anfragen verwendet werden können. ACLskann 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 deaktiviertACLs, 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.

ACLDie Berechtigungen sind weiterhin gültig, wenn die bevorzugte Einstellung für den Bucket-Besitzer oder die Einstellung für den Objekt-Writer gilt. Es gibt zwei Arten vonACLs: Bucket ACLs und ObjektACLs. Die Unterschiede zwischen diesen beiden Typen finden Sie unter Zuordnung von ACL Berechtigungen und Zugriffsrichtlinienberechtigungen. ACLs

Überprüfen Sie je nach der Aktion der abgelehnten Anfrage die ACL Berechtigungen für Ihren Bucket oder das Objekt:

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 habenACLs, können Sie auch das Konto des Objektbesitzers überprüfen. (Um das Konto des Objekteigentümers einzusehen, überprüfen Sie die ACL Objekteinstellungen in der Amazon S3 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. Standardmäßig ACLs gewähren Sie dem Konto des Objekteigentümers 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) angezeigt wird, müssen Sie die ACL Berechtigungen vor der Deaktivierung ACLs 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. Zusätzliche PUT Kosten können 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 zusammen mit dem gespeicherten Objekt bucket-owner-full-control erneut hochladen lassenACL.

    Anmerkung

    Für kontoübergreifende Uploads können Sie das bucket-owner-full-control gespeicherte Objekt auch ACL in Ihrer Bucket-Richtlinie vorschreiben. 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 Antragsteller 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 Anfrage öffentlichen Zugriff oder öffentliche Richtlinien beinhaltet, überprüfen Sie die S3-Einstellungen für Block Public Access in Ihrem Konto, Bucket oder Access Point. Weitere Informationen zur Behebung von Fehlern im Zusammenhang mit der Einstellung „Zugriff verweigert“ im Zusammenhang mit den Einstellungen zum Blockieren des öffentlichen Zugriffs in S3 finden Sie unterDer Zugriff wurde aufgrund der Einstellungen zum Blockieren des öffentlichen Zugriffs verweigert.

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 serverseitige Verschlüsselung mit verwalteten Amazon S3-Schlüsseln (SSE-S3) als Basisverschlüsselungsebene 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 https://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 mit dem 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 https://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 Status Ihrer Objektverschlüsselung mit dem 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 verwalteten Amazon S3 S3-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 (-C) SSE

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, AWS KMS key ist die kms:GenerateDataKey Berechtigung für das erforderlich. Um Objekte herunterzuladen und mehrteilige Uploads von Objekten durchzuführen, ist die kms:Decrypt Genehmigung 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 Schlüssel gehört. aws/s3 KMS 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 die KMS Schlüsselrichtlinie es Ihnen ermöglicht, die kms:GenerateDataKey kms:Decrypt OR-Aktionen auszuführen. Anweisungen zur Überprüfung Ihrer KMS Schlüsselrichtlinie finden Sie unter Schlüsselrichtlinie anzeigen 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 https://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.

VPCEndpunktrichtlinien

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 S3-Ressourcen hindert. Standardmäßig erlaubt die VPC Endpunktrichtlinie alle Anfragen an Amazon S3. Sie können die VPC Endpunktrichtlinie auch so konfigurieren, dass bestimmte Anfragen eingeschränkt werden. Informationen dazu, wie Sie Ihre VPC Endpunktrichtlinie überprüfen können, 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 startenIAM. 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.

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 Access Points verwendet wird

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

Zugriffspunktkonfigurationen und -richtlinien

  • Wenn Sie einen Zugriffspunkt erstellen, können Sie wählen, ob Sie das Internet oder VPCals Netzwerkquelle angeben möchten. Wenn der Netzwerkursprung auf VPC Nur gesetzt ist, lehnt Amazon S3 alle Anfragen an den Access Point ab, die nicht von dem angegebenen stammenVPC. Informationen zum Überprüfen des Netzwerkursprungs Ihres Zugriffspunkts finden Sie unter Erstellen von Zugriffspunkten, die auf eine Virtual Private Cloud beschränkt sind.

  • Mit Zugriffspunkten können Sie auch benutzerdefinierte Block-Public-Access-Einstellungen konfigurieren, die ähnlich wie die Block-Public-Access-Einstellungen auf Bucket- oder Kontoebene funktionieren. Informationen zu Ihren benutzerdefinierten Block-Public-Access-Einstellungen finden Sie unter Verwalten des öffentlichen Zugriffs auf Zugriffspunkte.

  • Um mithilfe von Access Points erfolgreiche Anfragen an Amazon S3 zu stellen, stellen Sie sicher, dass der Anforderer über die erforderlichen IAM Berechtigungen verfügt. Weitere Informationen finden Sie unter Konfiguration von IAM Richtlinien für die Verwendung von Access Points.

  • Wenn die Anforderung kontoübergreifende Zugriffspunkte umfasst, stellen Sie sicher, dass der Bucket-Eigentümer die Bucket-Richtlinie aktualisiert hat, um Anforderungen vom Zugriffspunkt zu autorisieren. Weitere Informationen finden Sie unter Erteilen von Berechtigungen für kontoübergreifende Zugriffspunkte.

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 AWS Support weitere Informationen zu erhalten.