Wie behebe ich den Fehler „403 Access Denied“ von Amazon S3?

Behebung

Hinweis: Wenn du beim Ausführen von AWS Command Line Interface (AWS CLI)-Befehlen Fehlermeldungen erhältst, findest du weitere Informationen dazu unter Problembehandlung bei der AWS CLI. Stelle außerdem sicher, dass du die neueste Version der AWS CLI verwendest.

AWS-Systems-Manager-Automatisierungsdokument verwenden

Verwende das Automatisierungsdokument AWSSupport-TroubleshootS3PublicRead auf AWS Systems Manager, um Probleme beim Lesen von Objekten aus einem bestimmten öffentlichen S3-Bucket zu ermitteln. 

Überprüfung der Einstellungen des Buckets und der Objekteigentümerschaft

Prüfe bei den Fehlern AccessDenied bei den Anforderungen GetObject oder HeadObject, ob das Objekt und der Bucket denselben Eigentümer haben. Überprüfe außerdem, ob der Bucket-Eigentümer über Lese- oder Vollzugriff auf die Zugriffskontrollliste (ACL) verfügt.

Hinweis: Wenn du einen neuen Bucket erstellst, sind ACLs standardmäßig deaktiviert. Es hat sich bewährt, AWS Identity and Access Management (IAM, Identitäts- und Zugriffsmanagement)-Richtlinien anstelle von ACLs zu verwenden, um den Zugriff auf S3-Ressourcen zu kontrollieren.

Bestätigen des Kontos, dem die Objekte gehören

Standardmäßig besitzt das AWS-Konto, dem der Bucket gehört, in dem das Objekt gespeichert ist, auch das Objekt. Wenn andere Konten Objekte in deinen Bucket hochladen können, überprüfe die Berechtigungen der Objekte, auf die deine Benutzer nicht zugreifen können.

Gehe wie folgt vor, um zu überprüfen, ob der Bucket und das Objekt denselben Eigentümer haben:

1. Führe den AWS CLI-Befehl list-buckets aus, um die kanonische Amazon S3-ID für dein Konto abzurufen:

   aws s3api list-buckets --query "Owner.ID"

2. Führe den Befehl list-objects aus, um die Amazon S3-ID des Kontos abzurufen, dem das Objekt gehört, auf das Benutzer nicht zugreifen können: 

   aws s3api list-objects --bucket DOC-EXAMPLE-BUCKET --prefix exampleprefix

   Hinweis: Ersetze DOC-EXAMPLE-BUCKET durch den Namen deines Buckets und exampleprefix durch deinen Präfixwert. Du kannst den Befehl list-objects verwenden, um mehrere Objekte gleichzeitig zu überprüfen.

3. Wenn die kanonischen IDs nicht übereinstimmen, bist du nicht Eigentümer des Objekts. Der Objekteigentümer kann dir die volle Kontrolle über das Objekt gewähren, indem er den Befehl put-object-acl ausführt:

   aws s3api put-object-acl --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg --acl bucket-owner-full-control

   Hinweis: Ersetze DOC-EXAMPLE-BUCKET durch den Namen des Buckets, der die Objekte enthält, und exampleobject.jpg durch den Schlüsselnamen.

4. Nachdem der Objekteigentümer die ACL des Objekts in bucket-owner-full-control geändert hat, kann der Bucket-Eigentümer auf das Objekt zugreifen. Um den Objekteigentümer auch in das Konto des Buckets zu ändern, führe den Befehl cp vom Konto des Buckets aus, um das Objekt über sich selbst zu kopieren.

Erstellen einer IAM-Rolle mit Berechtigungen für den Bucket

Wenn die IAM-Rolle und der Bucket-Eigentümer demselben Konto angehören, muss entweder die IAM-Rolle oder der Bucket über Berechtigungen verfügen. Du benötigst nicht Berechtigungen sowohl für die IAM-Rolle als auch für den Bucket.

Um Berechtigungen für verschiedene Konten hinzuzufügen, erstelle in deinem Konto eine IAM-Rolle mit Berechtigungen für deinen Bucket. Gewähre dann einem anderen AWS-Konto die Berechtigung, die IAM-Rolle zu übernehmen. Weitere Informationen findest du im IAM-Tutorial: Delegieren des Zugriffs für alle AWS-Konten mithilfe von IAM-Rollen.

Überprüfen der Bucket-Richtlinie oder IAM-Benutzerrichtlinien

Überprüfe die Bucket-Richtlinie oder die zugehörigen IAM-Benutzerrichtlinien auf Anweisungen, die möglicherweise den Zugriff verweigern. Stelle sicher, dass die Anforderungen an deinen Bucket alle Bedingungen der Bucket-Richtlinie oder der IAM-Richtlinien erfüllen. Suche nach falschen Zugriffsverweigerungs-Anweisungen, fehlenden Aktionen oder Tippfehlern in einer Richtlinie.

Bedingungen für Zugriffsverweigerungs-Anweisungen

Überprüfe die Zugriffsverweigerungs-Anweisungen auf Bedingungen, die den Zugriff aus folgenden Gründen blockieren:

• Multi-Faktor-Authentifizierung (MFA)
• Verschlüsselungsschlüssel
• Spezifische IP-Adresse
• Spezifische Virtual Private Clouds (VPCs) oder VPC-Endpunkte
• Spezifische IAM-Benutzer oder -Rollen

Hinweis: Wenn du MFA anforderst und Benutzer die AWS CLI zum Senden von Anforderungen verwendest, stelle sicher, dass Benutzer die AWS CLI für die Verwendung der MFA konfigurieren.

Beispielsweise ermöglicht in der folgenden Bucket-Richtlinie Statement1 den öffentlichen Zugriff zum Herunterladen von Objekten (s3:GetObject) von DOC-EXAMPLE-BUCKET. Statement2 verweigert jedoch explizit allen Benutzern den Zugriff zum Herunterladen von Objekten von DOC-EXAMPLE-BUCKET, es sei denn, die Anforderung stammt vom VPC-Endpunkt vpce-1a2b3c4d. Da Zugriffsverweigerungs-Anweisungen Vorrang vor Zugriffserlaubnis-Anweisungen haben, wird Benutzern, die versuchen, Objekte von außerhalb von vpce-1a2b3c4d herunterzuladen, der Zugriff verweigert.

{  
  "Id": "Policy1234567890123",  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Sid": "Statement1",  
      "Action": [  
        "s3:GetObject"  
      ],  
      "Effect": "Allow",  
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",  
      "Principal": "*"  
    },  
    {  
      "Sid": "Statement2",  
      "Action": [  
        "s3:GetObject"  
      ],  
      "Effect": "Deny",  
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",  
      "Condition": {  
        "StringNotEquals": {  
          "aws:SourceVpce": "vpce-1a2b3c4d"  
        }  
      },  
      "Principal": "*"  
    }  
  ]  
}

Bucket-Richtlinie oder IAM-Richtlinien

Stelle sicher, dass die Bucket-Richtlinie oder die IAM-Richtlinien die Amazon S3-Aktionen zulassen, die deine Benutzer ausführen müssen. Die folgende Bucket-Richtlinie beinhaltet beispielsweise keine Berechtigung für die Aktion s3:PutObjectAcl:

{  
  "Id": "Policy1234567890123",  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Sid": "Stmt1234567890123",  
      "Action": [  
        "s3:PutObject"  
      ],  
      "Effect": "Allow",  
      "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",  
      "Principal": {  
        "AWS": [  
          "arn:aws:iam::111122223333:user/Dave"  
        ]  
      }  
    }  
  ]  
}

Wenn der IAM-Benutzer versucht, die ACL eines Objekts zu ändern, wird dem Benutzer der Fehler Zugriff verweigert angezeigt.

Andere Richtlinien-Fehler

Suche nach zusätzlichen Leerzeichen, einem falschen ARN oder anderen Tippfehlern in der Bucket-Richtlinie oder den IAM-Benutzerrichtlinien.

Wenn eine IAM-Richtlinie ein zusätzliches Leerzeichen im ARN enthält, wird der ARN falsch ausgewertet und der Benutzer erhält den Fehler Zugriff verweigert . Beispielsweise wird eine IAM-Richtlinie, die ein zusätzliches Leerzeichen im ARN hat: arn:aws:s3::: DOC-EXAMPLE-BUCKET/* als aarn:aws:s3:::%20DOC-EXAMPLE-BUCKET/ ausgewertet.

Sich vergewissern, dass die IAM-Berechtigungsgrenzen den Zugriff auf Amazon S3 erlauben

Vergewissere dich, dass die IAM-Berechtigungsgrenzen, die für die IAM-Entitäten eingestellt sind, den Zugriff auf Amazon S3 erlauben.

Amazon S3 Block Public Access-Einstellungen des Buckets überprüfen

Wenn du bei erlaubten öffentlichen Leseanforderungen die Fehlermeldung Zugriff verweigert erhältst, überprüfe die Amazon S3 Block Public Access-Einstellungen für das Konto und den Bucket. Diese Einstellungen können Berechtigungen überschreiben, die den öffentlichen Lesezugriff erlauben. 

Benutzeranmeldeinformationen überprüfen

Überprüfe die Anmeldeinformationen, die deine Benutzer für den Zugriff auf Amazon S3 konfiguriert haben. Benutzer müssen AWS SDKs und die AWS CLI so konfigurieren, dass sie die Anmeldeinformationen der IAM-Identität verwenden, die Zugriff auf den Bucket hat.

Führe für die AWS CLI den Befehlconfigure aus, um die Anmeldeinformationen zu überprüfen:

aws configure list

Wenn Benutzer mithilfe einer Amazon Elastic Compute Cloud (Amazon EC2)-Instance auf den Bucket zugreifen, stelle sicher, dass die Instance die richtige Rolle verwendet. Stelle eine Verbindung zur Instance her und führe dann den Befehl get-caller-identity aus:

aws sts get-caller-identity

Temporäre Sicherheitsanmeldeinformationen überprüfen

Wenn Benutzer die Fehlermeldung Zugriff verweigert aufgrund temporärer Sicherheitsanmeldeinformationen erhalten, die vom AWS Security Token Service (AWS STS) erteilt wurden, überprüfe die zugehörige Sitzungsrichtlinie. Wenn ein Administrator den API-Aufruf AssumeRole oder den Befehl assume-role verwendet, um temporäre Sicherheitsanmeldeinformationen zu erstellen, kann der Administrator sitzungsspezifische Richtlinien übergeben.

Um die zugehörigen Sitzungsrichtlinien zu finden, suche im AWS CloudTrail-Ereignisverlauf nach AssumeRole-Ereignissen innerhalb desselben Zeitrahmens wie die fehlgeschlagenen Zugriffsanforderungen. Überprüfe dann das Feld requestParameters in den CloudTrail-Protokollen auf die Parameter policy oder policyArns. Vergewissere dich, dass die zugehörige Richtlinie oder der Richtlinien-ARN die erforderlichen Amazon S3-Berechtigungen erteilt.

Der folgende Ausschnitt eines CloudTrail-Protokolls zeigt beispielsweise, dass die temporären Anmeldeinformationen eine Inline-Sitzungsrichtlinie enthalten, die DOC-EXAMPLE-BUCKET s3:GetObject-Berechtigungen gewährt:

"requestParameters": {  
    "roleArn": "arn:aws:iam::123412341234:role/S3AdminAccess",  
    "roleSessionName": "s3rolesession",  
    "policy": "{  
    "Version": "2012-10-17",  
    "Statement": [{  
            "Effect": "Allow",  
            "Action": [  
                "s3:GetObject"  
            ],  
            "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"]  
    }]  
    }"  
}

Sich vergewissern, dass die Amazon VPC-Endpunktrichtlinie über die richtigen Berechtigungen für den Zugriff auf S3-Ressourcen verfügt

Wenn Benutzer eine EC2-Instance verwenden, die über einen Amazon Virtual Private Cloud (Amazon VPC)-Endpunkt geleitet wird, um auf den Bucket zuzugreifen, überprüfe die VPC-Endpunktrichtlinie.

Die folgende VPC-Endpunktrichtlinie ermöglicht beispielsweise den Zugriff auf DOC-EXAMPLE-BUCKET. Benutzer, die den VPC-Endpunkt zum Senden von Anforderungen verwenden, können auf keinen anderen Bucket zugreifen:

{  
  "Id": "Policy1234567890123",  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Sid": "Stmt1234567890123",  
      "Action": [  
        "s3:GetObject",  
        "s3:PutObject",  
        "s3:ListBucket"  
      ],  
      "Effect": "Allow",  
      "Resource": [  
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET",  
        "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"  
      ],  
      "Principal": "*"  
    }  
  ]  
}

IAM-Richtlinie des Amazon S3-Zugriffspunkts überprüfen

Wenn du einen Amazon S3-Zugriffspunkt verwendest, um den Zugriff auf den Bucket zu verwalten, überprüfe dieIAM-Richtlinie des Zugriffspunkts.

Berechtigungen, die du in einer Zugriffspunktrichtlinie gewährst, sind nur wirksam, wenn die zugehörige Bucket-Richtlinie denselben Zugriff ebenfalls erlaubt. Vergewissere dich, dass sowohl die Bucket-Richtlinie als auch die Zugriffspunktrichtlinie die richtigen Berechtigungen gewähren.

Sich vergewissern, dass sich das Objekt im Bucket befindet und dass der Objektname keine Sonderzeichen enthält

Prüfe, ob sich das angeforderte Objekt im Bucket befindet. Andernfalls findet die Anforderung das Objekt nicht, und Amazon S3 geht davon aus, dass das Objekt nicht existiert. Wenn du keine s3:ListBucket-Berechtigungen hast, erhältst du die Fehlermeldung Zugriff verweigert anstelle des Fehlers 404 Not Found.

Hinweis: Es gibt ein anderes Verfahren, um Objekte abzurufen, deren Namen Sonderzeichen enthalten.

Führe den AWS CLI-Befehl head-object aus, um zu überprüfen, ob ein Objekt sich im Bucket befindet:

aws s3api head-object --bucket DOC-EXAMPLE-BUCKET --key exampleobject.jpg

Hinweis: Ersetze DOC-EXAMPLE-BUCKET durch den Namen deines Buckets.

Wenn sich das Objekt im Bucket befindet, maskiert der Fehler Zugriff verweigert nicht den Fehler404 Not Found. Überprüfe weitere Konfigurationsanforderungen, um den Fehler Zugriff verweigert zu beheben.

Wenn das Objekt sich nicht im Bucket befindet, maskiert der Fehler Zugriff verweigert den Fehler 404 Not Found. Behebe das Problem im Zusammenhang mit dem fehlenden Objekt.

AWS KMS-Verschlüsselungskonfiguration überprüfen

Wenn ein IAM-Benutzer vollständige Berechtigungen für ein Objekt hat, aber immer noch nicht auf das Objekt zugreifen kann, überprüfe, ob das Objekt über eine AWS Key Management Service (AWS KMS)-Verschlüsselung (SSE-KMS) verfügt. Du kannst die Amazon S3-Konsole verwenden, um die Eigenschaften des Objekts anzuzeigen und die SSE-KMS-Informationen des Objekts zu überprüfen.

Wenn das Objekt mit einem kundenverwalteten Schlüssel verschlüsselt ist, muss die KMS-Schlüsselrichtlinie es dir ermöglichen, die Aktion kms:GenerateDataKey oder kms:Decrypt auszuführen. Weitere Informationen findest du unter Erlaubt den Zugriff auf das AWS-Konto und aktiviert IAM-Richtlinien.

Wenn der IAM-Benutzer einem anderen Konto als dem AWS-KMS-Schlüssel angehört, ändere die IAM-Richtlinie, um die Berechtigung Kms:Decrypt zu gewähren. Um beispielsweise SSE KMS-Objekte herunterzuladen, musst du sowohl in der Schlüsselrichtlinie als auch in der IAM-Richtlinie die Berechtigung kms:Decrypt angeben. Weitere Informationen zum kontoübergreifenden Zugriff zwischen dem IAM-Benutzer und dem KMS-Schlüssel findest du unter Zulassen der Verwendung eines KMS-Schlüssels durch Benutzer in anderen Konten.

Sich bei Buckets, die mit Zahlung durch den Anforderer aktiviert wurden, vergewissern, dass die Benutzer den Parameter „request-payer“ angegeben haben

Wenn du im Bucket Zahlung durch den Anforderer aktiviert hast, müssen Benutzer anderer Konten den Parameter request-payer angeben, wenn sie Anforderungen an deinen Bucket senden. Um zu überprüfen, ob du „Zahlung durch den Anforderer“ aktiviert hast, verwende die Amazon S3-Konsole, um die Eigenschaften des Buckets anzuzeigen.

Das folgende Beispiel für einen AWS CLI-Befehl enthält den richtigen Parameter für den Zugriff auf einen kontoübergreifenden Bucket mit „Zahlung durch den Anforderer“:

aws s3 cp exampleobject.jpg s3://DOC-EXAMPLE-BUCKET/exampleobject.jpg --request-payer requester

Überprüfung der AWS Organizations-SCPs

Wenn du AWS Organizationsverwendest, überprüfe die Service-Kontrollrichtlinien (Service Control Policies, SCPs), um sicherzustellen, dass der Zugriff auf Amazon S3 erlaubt ist. SCPs geben die maximalen Berechtigungen für die betroffenen Konten an. Die folgende SCP verweigert beispielsweise ausdrücklich den Zugriff auf Amazon S3 und führt zum Fehler Zugriff verweigert:

{  
  "Version": "2012-10-17",  
  "Statement": [  
    {  
      "Effect": "Deny",  
      "Action": "s3:*",  
      "Resource": "*"  
    }  
  ]  
}

Weitere Informationen zu den Funktionen von AWS Organizations findest du unter Alle Funktionen für eine Organisation bei AWS Organizations aktivieren.

Ähnliche Informationen

Problembehandlung bei Zugriffsverweigerung (403 Forbidden) in Amazon S3

Amazon-S3-Anforderungs-IDs für den AWS Support abrufen