View a markdown version of this page

Problembehandlung bei verweigertem Zugriff (403 Forbidden) Fehler 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 Vertrieb, ZugriffZugriffspunkteinstellungenWeitere Ressourcen

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

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

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

  • Eine explizite Ablehnung liegt vor, wenn eine Richtlinie eine Deny Anweisung für eine 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 einen IAM-Prinzipal standardmäßig implizit ablehnt, muss die Richtlinie dem Prinzipal explizit erlauben, eine Aktion auszuführen. Andernfalls verweigert die Richtlinie implizit den Zugriff. Weitere Informationen finden Sie unter Der Unterschied zwischen expliziten und impliziten Verweigerungen im IAM-Benutzerhandbuch. Weitere Informationen zur Richtlinienevaluierungslogik, die bestimmt, ob eine Zugriffsanforderung erlaubt oder verweigert wird, finden Sie unter Richtlinienevaluierungslogik im IAM-Benutzerhandbuch.

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

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

Anmerkung

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

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 HTTP-Fehlern (Access Denied403 Forbidden) für Anfragen an Ressourcen innerhalb derselben AWS-Konto oder derselben Organisation in AWS Organizations. Dieser 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, der bzw. die den Zugriff auf die Ressource angefordert hat.

Mit diesem zusätzlichen Kontext können Sie Zugriffsprobleme beheben, die Hauptursache für Fehler beim verweigerten Zugriff ermitteln und falsche Zugriffskontrollen beheben, indem Sie die entsprechenden Richtlinien aktualisieren. Dieser zusätzliche Kontext ist auch in AWS CloudTrail Protokollen verfügbar. Fehlermeldungen zum Thema „Erweiterter Zugriff verweigert“ für Anfragen, die sich auf dasselbe Konto oder dieselbe Organisation beziehen, sind in allen Ländern verfügbar AWS-Regionen, auch in den Regionen China AWS GovCloud (US) Regions .

Bei ausdrücklicher Ablehnung enthält die Fehlermeldung auch den Amazon-Ressourcennamen (ARN) der jeweiligen Richtlinie, die die Anfrage abgelehnt hat. Mit diesem Richtlinien-ARN können Sie schnell die genaue Richtlinie identifizieren, die für die Ablehnung verantwortlich ist, und direkt zu dieser wechseln, um die erforderlichen Änderungen vorzunehmen. Die Fehlermeldung enthält den Richtlinien-ARN für Service Control Policies (SCPs), Resource Control Policies (RCPs), identitätsbasierte Richtlinien, Sitzungsrichtlinien und Berechtigungsgrenzen.

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 explizit verweigert, weil die Richtlinie eine Deny Anweisung enthält, enthält die Fehlermeldung „Zugriff verweigert“ den folgenden Satz sowie den ARN der spezifischen Richtliniewith an explicit deny in a type policy, die die Anfrage abgelehnt hat. Wenn die Richtlinie den Zugriff implizit verweigert, enthält die Fehlermeldung „Zugriff verweigert“ den Ausdruck because no type policy allows the action action.

Wichtig

  • Meldungen über erweiterte Zugriffsverweigerungen werden nur für Anfragen mit demselben Konto oder für Anfragen innerhalb derselben Organisation in zurückgegeben. AWS Organizations Cross-account Anfragen außerhalb derselben Organisation geben eine generische Access Denied Meldung zurück.

    Informationen zur Logik der Richtlinienbewertung, die bestimmt, ob eine kontoübergreifende Zugriffsanforderung zulässig oder verweigert wird, finden Sie im IAM-Benutzerhandbuch unter Logik zur Cross-account Richtlinienbewertung. 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.

  • Bei expliziter Ablehnung enthält die Fehlermeldung den ARN der spezifischen Richtlinie, die die Anforderung abgelehnt hat. Dies gilt für Service Control Policies (SCPs), Resource Control Policies (RCPs), identitätsbasierte Richtlinien, Sitzungsrichtlinien und Berechtigungsgrenzen.

  • 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.

Der Zugriff wurde aufgrund des Typs „Blockierte Verschlüsselung“ verweigert

Um die serverseitigen Verschlüsselungstypen einzuschränken, die Sie in Ihren Allzweck-Buckets verwenden können, können Sie festlegen, dass SSE-C Schreibanforderungen blockiert werden, indem Sie Ihre Standardverschlüsselungskonfiguration für Ihre Buckets aktualisieren. Diese Konfiguration auf Bucket-Ebene blockiert Anfragen zum Hochladen von Objekten, die Folgendes angeben. SSE-C Wenn für einen Bucket gesperrt SSE-C ist, werden alle, PutObject CopyObject PostObject ,- oder mehrteiligen Upload- oder Replikationsanforderungen, die SSE-C Verschlüsselung angeben, mit einem HTTP-403-Fehler abgelehnt. AccessDenied

Diese Einstellung ist ein Parameter in der PutBucketEncryption API und kann auch mithilfe der S3-Konsole, der AWS CLI und der AWS SDKs aktualisiert werden, sofern Sie über die s3:PutEncryptionConfiguration entsprechende Berechtigung verfügen. Gültige Werte sindSSE-C, was die SSE-C Verschlüsselung für den Allzweck-Bucket blockiert und NONE die Verwendung SSE-C für Schreibvorgänge in den Bucket ermöglicht.

Wenn beispielsweise der Zugriff für eine PutObject Anfrage verweigert wird, weil die BlockedEncryptionTypes Einstellung die Angabe von Schreibanforderungen blockiert SSE-C, erhalten Sie die folgende Meldung:

An error occurred (AccessDenied) when calling the PutObject operation:   
User: arn:aws:iam::123456789012:user/MaryMajor  is not   
authorized to perform: s3:PutObject on resource:   
"arn:aws:s3:::amzn-s3-demo-bucket1/object-name" because this   
bucket has blocked upload requests that specify   
Server Side Encryption with Customer provided keys (SSE-C).   
Please specify a different server-side encryption type

Weitere Informationen zu dieser Einstellung finden Sie unter Sperren oder Entsperren SSE-C für einen Allzweck-Bucket.

Zugriff aufgrund einer Ressourcenkontrollrichtlinie verweigert – explizite Verweigerung

  1. Suchen Sie in Ihren Resource Control Policies (RCPs) nach einer ausdrücklichen Deny Aussage für die Aktion. Die Fehlermeldung enthält den Richtlinien-ARN, den Sie verwenden können, um die Richtlinie zu identifizieren und direkt zu dieser zu navigieren, die die Anfrage abgelehnt hat. 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, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/resource_control_policy/p-examplepolicyid

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 Control Policies (SCPs) eine explizite Deny-Anweisung für die Aktion vorhanden ist. Die Fehlermeldung enthält den Richtlinien-ARN, den Sie verwenden können, um die Richtlinie zu identifizieren und direkt zu dieser zu navigieren, die die Anfrage abgelehnt hat. 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 Beispiele für Service Control-Richtlinien unter GitHub. 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, with policy ARN: 
arn:aws:organizations::777788889999:policy/o-exampleorgid/service_control_policy/p-examplepolicyid

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: Bestimmte Principals von einer Deny-Anweisung ausschließen 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. Die Fehlermeldung enthält den Richtlinien-ARN, den Sie verwenden können, um die Richtlinie zu identifizieren und direkt zu dieser zu navigieren, die die Anfrage abgelehnt hat. 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, with policy ARN: 
arn:aws:iam::777788889999:policy/ExamplePermissionsBoundaryPolicy

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. Die Fehlermeldung enthält den Richtlinien-ARN, den Sie verwenden können, um die Richtlinie zu identifizieren und direkt zu dieser zu navigieren, die die Anfrage abgelehnt hat. 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: Bestimmte Principals von einer Deny-Anweisung ausschließen 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, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleSessionPolicy

Zugriff aufgrund ressourcenbasierter Richtlinien verweigert – implizite Ablehnung

Anmerkung

Resource-based Richtlinien sind Richtlinien wie Bucket-Richtlinien und Zugriffspunkt-Richtlinien.

  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 Resource-based Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

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

Zugriff aufgrund ressourcenbasierter Richtlinien verweigert – explizite Ablehnung

Anmerkung

Resource-based Richtlinien sind Richtlinien wie Bucket-Richtlinien und Access Point-Richtlinien.

  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: Bestimmte Principals von einer Deny-Anweisung ausschließen gezeigt. Weitere Informationen zur Aktualisierung Ihrer ressourcenbasierten Richtlinie finden Sie unter Resource-based Richtlinien und Bearbeiten von IAM-Richtlinien im IAM-Benutzerhandbuch.

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

User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

Zugriff aufgrund identitätsbasierter Richtlinien verweigert – implizite Verweigerung

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

  2. Aktualisieren Sie Ihre Richtlinie, indem Sie die Allow-Anweisung hinzufügen. Weitere Informationen finden Sie unter Identity-based 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. Die Fehlermeldung enthält den Richtlinien-ARN, den Sie verwenden können, um die Richtlinie zu identifizieren und direkt zu dieser zu navigieren, die die Anfrage abgelehnt hat. Im folgenden Beispiel lautet die Aktion s3:GetObject und die Identität ist der IAM-BenutzerMaryMajor.

  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 Identity-based 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, with policy ARN: 
arn:aws:iam::123456789012:policy/ExampleIdentityBasedPolicy

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 Access Point, einen Bucket oder ein ganzes AWS Konto angewendet werden. Wenn sich die Block Public Access-Einstellungen für den Zugriffspunkt, den Bucket oder das Konto unterscheiden, wendet Amazon S3 die restriktivste Kombination der Zugriffspunkt-, Bucket- und Kontoeinstellungen an.

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

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

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

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

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

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

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

    An error occurred (AccessDenied) when calling the CopyObject operation: 
User: arn:aws:sts::123456789012:user/MaryMajor is not authorized to 
perform: s3:CopyObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" 
because public ACLs are prevented by the BlockPublicAcls setting in S3 Block Public Access.

  • 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 prevented by the BlockPublicPolicy setting in S3 Block Public Access.

  • RestrictPublicBuckets— Die RestrictPublicBuckets Einstellung beschränkt den Zugriff auf einen Access Point oder Bucket mit einer öffentlichen Richtlinie auf AWS-Service Principals und autorisierte Benutzer innerhalb des Accounts des Bucket-Besitzers und des Accounts des Access Point-Inhabers. Diese Einstellung sperrt jeglichen kontoübergreifenden Zugriff auf den Access Point oder Bucket (außer für AWS-Service Principals) und ermöglicht Benutzern innerhalb des Accounts weiterhin, den Access Point oder Bucket zu verwalten. Diese Einstellung weist auch alle anonymen (oder unsignierten) Aufrufe zurück.

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

    User: arn:aws:iam::123456789012:user/MaryMajor is not authorized to perform: 
s3:GetObject on resource: "arn:aws:s3:::amzn-s3-demo-bucket1/object-name" with 
an explicit deny in a resource-based policy

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

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 Requester Pays für einen Bucket aktiviert ist, werden dem Bucket-Besitzer keine Anfragen von anderen Konten in Rechnung gestellt. AWS

Wenn Sie eine Anfrage an einen Pays-enabled Requester-Bucket stellen, ohne die erforderlichen Parameter zu übergeben, erhalten Sie die Fehlermeldung Zugriff verweigert (403 Forbidden). Um auf Objekte in einem Pays-enabled Requester-Bucket zuzugreifen, müssen Sie wie folgt vorgehen:

  1. Wenn Sie Anfragen mit der AWS CLI stellen, müssen Sie den --request-payer requester Parameter 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 mithilfe eines AWS SDK stellen, setzen Sie den x-amz-request-payer Header auf den Wertrequester. 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.

Indem Sie den --request-payer requester Parameter angeben oder den x-amz-request-payer Header festlegen, informieren Sie Amazon S3 darüber, dass Sie als Anforderer die Kosten tragen, die mit dem Zugriff auf die Objekte im Requester-Bucket verbunden sind. Pays-enabled Dadurch wird der Fehler Zugriff verweigert (403 Verboten) vermieden.

Bucket-Richtlinien und IAM-Richtlinien

Bucket-level Operationen

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

Object-level Operationen

Wenn das Objekt dem Konto gehört, das den Bucket besitzt, funktionieren die Bucket-Richtlinie und die IAM-Benutzerrichtlinie für Vorgänge auf Objektebene genauso wie für Vorgänge auf Bucket-Ebene. Wenn es beispielsweise keine Bucket-Richtlinie gibt, lässt der Bucket implizit Objektanforderungen von jeder IAM-Identität in dem Konto zu, das im Besitz des Buckets ist. Ebenso lehnt der Bucket implizit Objektanforderungen von anderen IAM-Identitäten von anderen Konten sowie anonyme (unsignierte) Anforderungen ab. Wenn jedoch keine IAM-Benutzerrichtlinie vorhanden ist, wird dem Anforderer (es sei denn, er ist der AWS-Konto Root-Benutzer) implizit 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 einzusehen, benötigen Sie die entsprechende Berechtigung. s3:GetBucketPolicy Um eine Bucket-Richtlinie zu bearbeiten, benötigen Sie die s3:PutBucketPolicy entsprechende Berechtigung.

  1. Melden Sie sich bei der an AWS-Managementkonsole 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 Berechtigungen.

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

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

Anmerkung

Wenn Sie aufgrund einer falschen Bucket-Richtlinie von einem Bucket ausgeschlossen werden, melden Sie sich mit Ihren AWS-Konto Root-Benutzeranmeldedaten bei dem AWS-Managementkonsole an. Um wieder auf Ihren Bucket zugreifen zu können, stellen Sie sicher, dass Sie die falsche Bucket-Richtlinie löschen, indem Sie Ihre AWS-Konto Root-Benutzeranmeldedaten verwenden.

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.

Behebung eines Fehlers „Zugriff verweigert“ (403 Forbidden) aufgrund einer GET-Objektanforderung während des kontoübergreifenden Objektbesitzes

Ü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. Server-side Verschlüsselung ist die Verschlüsselung von Daten am Zielort durch die Anwendung oder den Dienst, der sie empfängt. Amazon S3 verschlüsselt Ihre Daten auf Objektebene, während 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 von Amazon S3 verwalteten 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-Managementkonsole 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 get-bucket-encryption Befehl AWS CLI, um Ihre Verschlüsselungseinstellungen mithilfe von zu überprüfen.

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

  1. Melden Sie sich bei der an AWS-Managementkonsole 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 mit den Server-side Verschlüsselungseinstellungen, um die serverseitigen Verschlüsselungseinstellungen des Objekts anzuzeigen.

Verwenden Sie den head-object Befehl, um den Verschlüsselungsstatus Ihres Objekts AWS CLI mithilfe von zu überprüfen.

Verschlüsselungs- und Berechtigungsanforderungen

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

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

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

  • Server-side 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, AWS KMS key ist die kms:GenerateDataKey Berechtigung auf dem erforderlich. Um Objekte herunterzuladen und mehrteilige Uploads von Objekten durchzuführen, ist die Berechtigung kms:Decrypt für den KMS-Schlüssel erforderlich.

  • SSE-KMS (mit einem Von AWS verwalteter Schlüssel) — Der Anforderer muss aus demselben Konto stammen, dem der aws/s3 KMS-Schlüssel gehört. 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 an AWS-Managementkonsole 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 Anfrage von einem beliebigen Anforderer, einschließlich des AWS-Konto Root-Benutzers, führt zu einem Fehler „Zugriff verweigert“ (403 Forbidden). Beachten Sie außerdem, dass Amazon S3 eine Löschmarkierung für das Objekt erstellt, wenn Sie eine DELETE-Anforderung für ein Objekt einreichen, das durch den Compliance-Aufbewahrungsmodus geschützt ist.

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

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

VPC-Endpunktrichtlinien

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

AWS Organizations Richtlinien

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

Wenn Sie Ihre Bucket-Richtlinie für ein Mitgliedskonto falsch konfiguriert haben, um allen Benutzern den Zugriff auf Ihren S3-Bucket zu verweigern, können Sie den Bucket außerdem entsperren, indem Sie eine privilegierte Sitzung für das Mitgliedskonto in IAM starten. 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 Ausführen einer privilegierten Aufgabe für ein AWS Organizations Mitgliedskonto.

CloudFront Vertrieb, Zugriff

Wenn Sie versuchen, über Ihre statische S3-Website auf Ihre statische S3-Website zuzugreifen, die Fehlermeldung Zugriff verweigert (403 verboten) erhalten CloudFront, überprüfen Sie die folgenden häufig auftretenden 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 CloudFront den Zugriff?

    • Stellen Sie sicher, dass Ihre Bucket-Richtlinie Berechtigungen für die Origin Access Identity (OAI) oder Origin Access Control (OAC) Ihrer CloudFront Distribution enthält

    • Stellen Sie sicher, dass die Richtlinie die erforderlichen s3: -Berechtigungen enthält GetObject

Weitere Schritte und Konfigurationen zur Fehlerbehebung, einschließlich der Einrichtung von Fehlerseiten und Protokolleinstellungen, finden Sie unter Warum erhalte ich die Fehlermeldung „403-Zugriff verweigert“, wenn ich einen Amazon S3-Website-Endpunkt als Ursprung meiner CloudFront Verteilung 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. Überprüfen Sie CloudFront-specific bei Problemen unbedingt sowohl Ihre CloudFront Distributionseinstellungen als auch die S3-Konfigurationen.

Zugriffspunkteinstellungen

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

  • Die Konfigurationen Ihrer Zugriffspunkte

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

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

Zugriffspunktkonfigurationen und -richtlinien

Wenn der Fehler Zugriff verweigert (403 verboten) nach Überprüfung aller Artikel in diesem Thema weiterhin besteht, rufen Sie Ihre Amazon S3-Anforderungs-ID ab und wenden Sie sich an uns, um Support weitere Informationen zu erhalten.

Weitere Ressourcen

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