Beheben von „Zugriff verweigert“-Fehlern (403 Forbidden) in Amazon S3 - Amazon Simple Storage Service
Beispiele für „Zugriff verweigert“-Meldungen und deren BehebungZugriff verweigert aufgrund von „Zahlung durch den Anforderer“-EinstellungenBucket-Richtlinien und IAM-RichtlinienAmazon-S3-ACL-EinstellungenS3-Block-Public-Access-EinstellungenAmazon-S3-VerschlüsselungseinstellungenS3-Einstellungen für die ObjektsperreVPC-EndpunktrichtlinienAWS Organizations-RichtlinienCloudFront-VerteilungszugriffZugriffspunkteinstellungenWeitere Ressourcen

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

„Zugriff verweigert“-Fehler (HTTP 403 Forbidden) treten auf, wenn AWS eine Autorisierungsanforderung explizit oder implizit ablehnt.

  • Eine explizite Ablehnung tritt auf, wenn eine Richtlinie eine Deny-Anweisung für die spezifische AWS-Aktion enthält.

  • 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 einem IAM-Prinzipal standardmäßig implizit den Zugriff verweigert, muss die Richtlinie den Prinzipal ausdrücklich dazu berechtigen, 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 „Zugriff verweigert“-Fehlern (HTTP 403 Forbidden) berechnet Amazon S3 dem Bucket-Eigentümer keine Gebühren, wenn die Anforderung außerhalb des individuellen AWS-Kontos des Bucket-Eigentümers oder der AWS-Organisation des Bucket-Eigentümers 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 oder derselben AWS Organizations 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 für verweigerten Zugriff bei Anfragen für dasselbe Konto oder dieselbe Organisation sind jetzt in allen AWS-Regionen verfügbar, einschließlich der AWS GovCloud (US) Regions und der China-Region.

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 Dienstaktion, die die Richtlinie verweigert, und resource-arn ist der ARN der Ressource, auf die die Richtlinie wirkt. Das context-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 Zugriffsverweigerungsmeldungen werden nur für Anfragen desselben Kontos oder für Anfragen innerhalb derselben Organisation in AWS Organizations zurückgegeben. Bei kontoübergreifenden Anfragen außerhalb derselben Organisation wird eine allgemeine Meldung Access Denied 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.

  • Für Anfragen innerhalb der gleichen Organisation in AWS Organizations:

    • Erweiterte Zugriffsverweigerungsmeldungen werden nicht zurückgegeben, wenn eine Verweigerung aufgrund einer Virtual Private Cloud (VPC)-Endpunktrichtlinie erfolgt.

    • Erweiterte Zugriffsverweigerungsmeldungen werden immer dann bereitgestellt, wenn sowohl der Bucket-Eigentümer als auch das Anruferkonto zur selben Organisation in AWS Organizations gehören. Obwohl Buckets, die mit den S3 Object Ownership-Einstellungen Bucket owner preferred oder Object writer konfiguriert sind, Objekte enthalten können, die verschiedenen Konten gehören, hat die Objekteigentümerschaft keinen Einfluss auf erweiterte Zugriffsverweigerungsmeldungen. Erweiterte Zugriffsverweigerungsmeldungen werden für alle Objektanfragen zurückgegeben, solange der Bucket-Eigentümer und der Aufrufer derselben Organisation angehören, unabhängig davon, wer Eigentümer des spezifischen Objekts ist. Informationen zu den Einstellungen und Konfigurationen des Objektbesitzes finden Sie unter Weitere Informationen finden Sie unter Steuern des Eigentums an Objekten und Deaktivieren von ACLs für Ihren Bucket..

  • 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 (RCPs) nach einer Deny-Anweisung zur Aktion. 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. Überprüfen Sie, ob in Ihren Service-Kontrollrichtlinien (SCPs) eine Allow-Anweisung für die Aktion fehlt. 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. Überprüfen Sie, ob in Ihren Service-Kontrollrichtlinien (SCPs) eine Deny-Anweisung für die Aktion vorhanden ist. 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 finden 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 finden 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, Zugangspunktrichtlinien, IAM-Benutzerrichtlinien, Objektberechtigungen oder Zugriffskontrolllisten (ACLs) ändern, um öffentlichen Zugriff zu ermöglichen. Die S3-Block-Public-Access-Einstellungen überschreiben diese 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 Zugriffspunkt, einen Bucket oder ein gesamtes 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 – Wenn Sie diese Option auf IgnorePublicAcls festlegen, ignoriert Amazon S3 alle öffentlichen ACLs auf einem Bucket und alle darin enthaltenen Objekte. 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 Zugangspunkt oder einen Bucket mit einer öffentlichen Richtlinie nur auf AWS-Service-Prinzipale und autorisierte Benutzer innerhalb des Kontos des Bucket-Eigentümers und des Kontos des Zugangspunkteigentümers Diese Einstellung blockiert alle kontoübergreifenden Zugriffe auf den Zugangspunkt oder den Bucket (außer durch AWS-Service-Prinzipale) und ermöglicht gleichzeitig Benutzern innerhalb des Kontos die Verwaltung des Zugangspunkts oder Buckets. 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.

Zugriff verweigert aufgrund von „Zahlung durch den Anforderer“-Einstellungen

Wenn für den Amazon S3-Bucket, auf den Sie zugreifen möchten, die Funktion „Zahlung durch den Anforderer“ aktiviert ist, müssen Sie sicherstellen, dass Sie bei Anfragen an diesen Bucket die richtigen Anforderungsparameter übergeben. Das Feature „Zahlung durch den Anforderer“ in Amazon S3 ermöglicht es dem Anforderer, anstelle des Bucket-Eigentümers die Datenübertragungs- und Anfragekosten für den Zugriff auf Objekte im Bucket zu bezahlen. Wenn „Zahlung durch den Anforderer“ für einen Bucket aktiviert ist, werden dem Bucket-Besitzer keine Gebühren für Anfragen von anderen AWS-Konten berechnet.

Wenn Sie eine Anfrage an einen Bucket stellen, der für „Zahlung durch den Anforderer“ aktiviert ist, ohne die erforderlichen Parameter zu übergeben, erhalten Sie die Fehlermeldung „Zugriff verweigert (403 Verboten)“. Um auf Objekte in einem Bucket zuzugreifen, in dem Zahlungen für Antragsteller aktiviert sind, müssen Sie Folgendes tun:

  1. Bei Anfragen über die CLI AWS müssen Sie den Parameter --request-payer requester angeben. Um beispielsweise ein Objekt mit dem Schlüssel object.txt aus dem S3 Bucket s3://amzn-s3-demo-bucket/ an einen Speicherort auf Ihrem lokalen Rechner zu kopieren, müssen Sie auch den Parameter --request-payer requester übergeben, wenn in diesem Bucket die Option „Zahlung durch den Anforderer“ aktiviert ist. 

    aws s3 cp s3://amzn-s3-demo-bucket/object.txt /local/path \
--request-payer requester

  2. Wenn Sie programmatische Anfragen mit einem AWS SDK stellen, setzen Sie den x-amz-request-payer Header auf den Wert requester. Ein Beispiel finden Sie unter Herunterladen von Objekten aus Buckets mit Zahlung durch den Anforderer.

  3. Vergewissern Sie sich, dass der IAM-Benutzer oder die IAM-Rolle, der/die die Anfrage stellt, über die erforderlichen Berechtigungen für den Zugriff auf den Bucket „Zahlung durch den Anforderer“ verfügt, z. B. die Berechtigungen s3:GetObject und s3:ListBucket.

Durch Einfügen des Parameters --request-payer requester oder Setzen des Headers x-amz-request-payer teilen Sie Amazon S3 mit, dass Sie als Anforderer, die mit dem Zugriff auf die Objekte in einem für Zahlung durch den Anforderer aktivierten Bucket verbundenen Kosten übernehmen. Dadurch wird der Fehler Zugriff verweigert (403 Verboten) vermieden.

Bucket-Richtlinien und IAM-Richtlinien

Vorgänge auf Bucket-Ebene

Wenn es keine Bucket-Richtlinie gibt, lässt der Bucket implizit Anforderungen von jeder AWS Identity and Access Management (IAM)-Identität in dem Konto zu, das im Besitz des Buckets ist. Ebenso lehnt der Bucket implizit Anforderungen von anderen IAM-Identitäten von anderen Konten sowie anonyme (unsignierte) Anforderungen ab. Wenn jedoch keineIAM-Benutzerrichtlinie vorhanden ist, wird der Anforderer (sofern es sich nicht um den AWS-Konto-Root-Benutzer handelt) implizit daran gehindert, Anforderungen 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 der Anforderer (sofern es sich nicht um den Root-Benutzer handelt) implizit daran gehindert, Objektanforderungen zu stellen.

Wenn das Objekt einem externen Konto gehört, kann der Zugriff auf das Objekt nur über Objekt-Zugriffssteuerungslisten (ACLs) gewährt werden. 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 AWS-Managementkonsole an und öffnen Sie die Amazon-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 Permissions (Berechtigungen).

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

Verwenden Sie den Befehl get-bucket-policy, um Ihre Bucket-Richtlinie über die AWS Command Line Interface (AWS CLI) zu überprüfen oder zu bearbeiten.

Anmerkung

Wenn Sie aufgrund einer falschen Bucket-Richtlinie von einem Bucket ausgeschlossen werden, melden Sie sich mit Ihren AWS-Konto-Root-Benutzer-Anmeldeinformationen bei der AWS-Managementkonsole an. Um wieder Zugriff auf Ihren Bucket zu erhalten, löschen Sie die Bucket-Richtlinie unter Verwendung Ihrer AWS-Konto-Root-Benutzer-Anmeldeinformationen.

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 Einstellung für Object Ownership, um festzustellen, ob ACLs für den Bucket aktiviert sind. Beachten Sie, dass ACL-Berechtigungen nur zum Erteilen von Berechtigungen und nicht zum Zurückweisen von Anforderungen verwendet werden können. ACLs können auch nicht verwendet werden, um Anforderern Zugriff zu gewähren, denen der Zugriff durch explizite Ablehnungen in Bucket-Richtlinien oder IAM-Benutzerrichtlinien verweigert wurde.

Die Einstellung Object Ownership ist auf Bucket owner enforced gesetzt

Wenn die Einstellung Bucket-Eigentümer erzwungen aktiviert ist, ist es unwahrscheinlich, dass die ACL-Einstellungen einen Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) verursachen, da diese Einstellung alle ACLs deaktiviert, die für Buckets und Objekte gelten. Bucket-Eigentümer erzwungen ist die Standardeinstellung (und empfohlene Einstellung) für Amazon-S3-Buckets.

Die Einstellung Object Ownership ist auf Bucket owner preferred oder Object writer 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 Arten von ACLs finden Sie unter Mapping der 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 die Objekt-ACLs haben, 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. Standardmäßig gewähren ACLs explizite Berechtigungen für GET-Anforderungen an das Konto des Objekteigentümers.

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:

  • ACLs deaktivieren (empfohlen) – Diese Methode gilt für alle Objekte und kann vom Bucket-Eigentümer 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 von 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 einen Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) zu verhindern, müssen Sie die ACL-Berechtigungen in eine Bucket-Richtlinie migrieren, bevor Sie ACLs deaktivieren. 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 Fehler aufgrund einer Zugriffsverweigerung (403 Forbidden) zu beheben, fügen Sie dann den Anforderer als Empfänger für den Zugriff auf das Objekt in den ACLs des Objekts hinzu. Weitere Informationen finden Sie unter Konfigurieren von 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 diese auf Festplatten in AWS-Rechenzentren schreibt, und entschlüsselt die Daten für Sie, wenn Sie auf diese 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 AWS-Managementkonsole an und öffnen Sie die Amazon-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.

Verwenden Sie den Befehl get-bucket-encryption, um Ihre Verschlüsselungseinstellungen über die AWS CLI zu überprüfen.

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

  1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-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.

Verwenden Sie den Befehl head-object, um Ihren Objektverschlüsselungsstatus über die AWS CLI zu überprüfen.

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 Schlüsseln, die von AWS Key Management Service (AWS KMS) (SSE-KMS) verwaltet werden

  • 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 demselben Konto angehören, das den aws/s3-KMS-Schlüssel besitzt. 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-Object Lock aktiviert ist und das Objekt durch eine Aufbewahrungsfrist oder eine gesetzliche Aufbewahrungspflicht geschützt ist und Sie versuchen, ein Objekt zu löschen, gibt Amazon S3 je nachdem, wie Sie versucht haben, das Objekt zu löschen, eine der folgenden Antworten zurück:

  • Permanente DELETE-Anfrage – Wenn Sie eine permanente DELETE Anfrage gestellt haben (eine Anfrage, die eine Versions-ID angibt), gibt Amazon S3 den Fehler „Zugriff verweigert“ (403 Forbidden) zurück, wenn Sie versuchen, das Objekt zu löschen.

  • Einfache DELETE Anfrage – Wenn Sie eine einfache DELETE Anfrage gestellt haben (eine Anfrage, die keine Versions-ID enthält), gibt Amazon S3 eine 200 OK Antwort zurück und fügt eine Löschmarkierung in den Bucket ein, und diese Markierung wird zur aktuellen Objektversion mit einer neuen ID.

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

  1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-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-Anforderung eines Anforderers, einschließlich des AWS-Konto-Root-Benutzers, führt zu einem „Zugriff verweigert“-Fehler (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 Ihr AWS-Konto einer Organisation gehört, können AWS Organizations-Richtlinien Sie am Zugriff auf Amazon-S3-Ressourcen hindern. Standardmäßig blockieren AWS Organizations-Richtlinien keine Anforderungen an Amazon S3. Stellen Sie jedoch sicher, dass Ihre AWS Organizations-Richtlinien nicht so konfiguriert sind, dass der Zugriff auf S3 Buckets blockiert wird. Anleitungen zum Überprüfen Ihrer -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. Nachdem 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 Privilegierte Aufgabe in einem AWS Organizations-Mitgliedskonto ausführen.

CloudFront-Verteilungszugriff

Wenn Sie beim Versuch, über CloudFront auf Ihre statische S3-Website zuzugreifen, einen Fehler "Zugriff verweigert" (403 Verboten) erhalten, überprüfen Sie diese allgemeinen Probleme:

  • Haben Sie das richtige Format für den Domain-Namen?

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

    • Überprüfen Sie, ob das Hosting einer statischen Website in Ihrem Bucket aktiviert ist

  • Erlaubt Ihre Bucket-Richtlinie den Zugriff auf CloudFront?

    • Stellen Sie sicher, dass Ihre Bucket-Richtlinie Berechtigungen für die Ursprungszugriffsidentität (OAI) oder die Ursprungszugriffskontrolle (OAC) Ihrer CloudFront-Distribution enthält

    • Überprüfen Sie, ob die Richtlinie die erforderlichen s3:GetObject-Berechtigungen enthält

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-Website-Endpunkt als Quelle meiner CloudFront-Distribution verwende? im AWS re:Post Knowledge Center.

Anmerkung

Dieser Fehler unterscheidet sich von 403-Fehlern, die Sie beim direkten Zugriff auf S3 erhalten können. Bei CloudFront-spezifischen Problemen sollten Sie sowohl Ihre CloudFront-Verteilungseinstellungen als auch Ihre S3-Konfigurationen ü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 aufgrund einer Zugriffsverweigerung (403 Forbidden) auch nach der Überprüfung aller Elemente in diesem Thema weiterhin besteht, rufen Sie Ihre Amazon-S3-Anforderungs-ID ab und wenden Sie sich an Support, um weitere Informationen zu erhalten.

Weitere Ressourcen

Weitere Hinweise zu Fehlern, die den Zugriff verweigern (403 Forbidden), finden Sie in den folgenden Ressourcen: