Wie behebe ich 403 Access Denied (Zugriff verweigert)-Fehler von Amazon S3?

Letzte Aktualisierung: 13.05.2022

Meine Benutzer versuchen, auf Objekte in meinem Amazon Simple Storage Service (Amazon S3)-Bucket zuzugreifen, aber Amazon S3 gibt den Fehler 403 Access Denied (Zugriff verweigert) zurück. Wie kann ich dieses Problem beheben?

Auflösung

Verwenden Sie das Dokument von AWS Systems Manager Automation

Verwenden Sie das Automatisierungsdokument AWSSupport-TroubleshootS3PublicRead im AWS Systems Manager. Dieses Automatisierungsdokument hilft Ihnen bei der Diagnose von Problemen beim Lesen von Objekten aus einem von Ihnen angegebenen öffentlichen S3-Bucket.

Überprüfen Sie Bucket- und Objekt-Eigentümerschaft

Prüfen Sie bei AccessDenied-Fehlern aus GetObject- oder HeadObject-Anforderungen, ob das Objekt auch dem Bucket-Eigentümer gehört. Prüfen Sie außerdem, ob der Bucket-Eigentümer über Leseberechtigungen oder vollständige Zugriffssteuerungsliste (ACL)-Berechtigungen verfügt.

Bestätigen Sie das Konto, das der Objekt-Eigentümer ist

Standardmäßig gehört ein S3-Objekt dem AWS-Konto, das es hochgeladen hat. Dies gilt auch dann, wenn der Bucket einem anderen Konto gehört. Falls andere Konten Objekte in Ihren Bucket hochladen können, überprüfen Sie, welchem Konto die Objekte gehören, auf die Ihre Benutzer nicht zugreifen können.

Hinweis: Wenn Sie beim Ausführen von AWS-CLI-Befehlen Fehler erhalten, stellen Sie sicher, dass Sie die neueste Version der AWS CLI verwenden.

1.    Führen Sie den Befehl list-buckets in der AWS Command Line Interface (AWS CLI) aus, um die kanonische Amazon-S3-ID für Ihr Konto durch Abfrage der Besitzer-ID zu erhalten.

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

2.    Führen Sie den Befehl list-objects aus, um die kanonische Amazon-S3-ID des Kontos abzurufen, dem das Objekt gehört, auf das Benutzer nicht zugreifen können. Ersetzen Sie DOC-EXAMPLE-BUCKET durch den Namen Ihres Buckets und exampleprefix durch Ihren Präfixwert.

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

Tipp: Verwenden Sie den Befehl list-objects, um mehrere Objekte zu überprüfen.

3.    Wenn die kanonischen IDs nicht übereinstimmen, sind Sie nicht der Objekt-Eigentümer. Der Objekt-Eigentümer kann Ihnen die volle Kontrolle über das Objekt gewähren, indem er den Befehl put-object-acl ausführt. Ersetzen Sie DOC-EXAMPLE-BUCKET durch den Namen des Buckets, der die Objekte enthält. Ersetzen Sie exampleobject.jpg mit Ihrem Schlüsselnamen.

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

4.    Nachdem der Objektbesitzer die ACL des Objekts in bucket-owner-full-control geändert hat, kann der Bucket-Eigentümer auf das Objekt zugreifen. Die ACL-Änderung allein ändert jedoch nicht den Besitz des Objekts. Um den Objekt-Eigentümer das Konto des Buckets zu ändern, führen Sie den Befehl cp vom Konto des Buckets aus, um das Objekt auf sich selbst zu kopieren.

Kopieren Sie alle neuen Objekte in einen Bucket in einem anderen Konto

1.    Legen Sie eine Bucket-Richtlinie fest, die vorschreibt, dass Objekte mit der bucket-owner-full-control-ACL hochgeladen werden.

2.    Aktivieren und setzen Sie anschließend die Eigentümerschaft von S3-Objekten auf den in der AWS-Managementkonsole bevorzugten Bucket-Eigentümer.

Dadurch wird der Objekt-Eigentümer automatisch in den Bucket-Eigentümer geändert, wenn das Objekt mit der bucket-owner-full-control-ACL hochgeladen wird.

Erstellen Sie eine IAM-Rolle mit Berechtigungen für Ihren Bucket

Erstellen Sie für fortlaufende kontoübergreifende Berechtigungen eine IAM-Rolle in Ihrem Konto mit Berechtigungen für Ihren Bucket. Erteilen Sie dann einem anderen AWS-Konto die Berechtigung, diese IAM-Rolle zu übernehmen. Weitere Informationen finden Sie im Tutorial: Zugriff auf mehrere AWS-Konten mittels IAM-Rollen übertragen.

Überprüfen Sie die Bucket-Richtlinie oder IAM-Benutzerrichtlinien

Überprüfen Sie die Bucket-Richtlinie oder die zugehörigen IAM-Benutzerrichtlinien auf Anweisungen, die den Zugriff eventuell verweigern. Stellen Sie sicher, dass die Anforderungen an Ihren Bucket alle Bedingungen in der Bucket-Richtlinie oder den IAM-Richtlinien erfüllen. Überprüfen Sie auf falsche Zugriffsverweigerungs-Anweisungen, fehlende Aktionen oder falsche Abstände in einer Richtlinie.

Bedingungen für Zugriffsverweigerungen

Prüfen Sie Zugriffsverweigerungen auf Bedingungen, die basierend auf den folgenden Kriterien den Zugriff blockieren:

  • Multi-Faktor Authentifizierung (MFA)
  • Verschlüsselungsschlüssel
  • spezifische IP-Adresse
  • bestimmte VPCs oder VPC-Endpunkte
  • bestimmte IAM-Benutzer oder -Rollen

Hinweis: Wenn Sie MFA benötigen und Benutzer Anfragen über die AWS CLI senden, stellen Sie sicher, dass die Benutzer die AWS CLI für die Verwendung von MFA konfigurieren.

In der folgenden Bucket-Richtlinie ermöglicht Statement1 beispielsweise den öffentlichen Zugriff auf das Herunterladen von Objekten (s3:GetObject) aus DOC-EXAMPLE-BUCKET. Statement2 verweigert jedoch jedem ausdrücklich den Zugriff auf das Herunterladen von Objekten von DOC-EXAMPLE-BUCKET, es sei denn, die Anfrage stammt vom VPC-Endpunkt vpce-1a2b3c4d. In diesem Fall hat die Zugriffsverweigerungs-Anweisung Vorrang. Das bedeutet, dass Benutzern, die versuchen, Objekte von außerhalb von vpce-1a2b3c4d herunterzuladen, der Zugriff verweigert wird.

{
  "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-Richtlinien oder IAM-Richtlinien

Überprüfen Sie, ob die Bucket-Richtlinie oder die IAM-Richtlinien die Amazon-S3-Aktionen erlauben, die Ihre Benutzer benötigen. Die folgende Bucket-Richtlinie enthält beispielsweise keine Berechtigung für die Aktion s3:PutObjectAcl. Wenn der IAM-Benutzer versucht, die Zugriffskontrollliste (ACL) eines Objekts zu ändern, erhält der Benutzer einen Access-Denied-Fehler.

{
  "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"
        ]
      }
    }
  ]
}

Andere Fehler in Richtlinien

Stellen Sie sicher, dass die Bucket-Richtlinie oder die IAM-Benutzerrichtlinien keine zusätzlichen Leerzeichen oder falsche ARNs enthalten.

Wenn beispielsweise eine IAM-Richtlinie ein zusätzliches Leerzeichen im Amazon-Ressourcennamen (ARN) arn:aws:s3:::DOC-EXAMPLE-BUCKET/*hat. In diesem Fall wird der ARN dann fälschlicherweise als arn:aws:s3: ::%20DOC-EXAMPLE-BUCKET/ ausgewertet und gibt dem IAM-Benutzer einen Access-Denied-Fehler zurück.

Stellen Sie sicher, dass die IAM-Berechtigungsgrenzen den Zugriff auf Amazon S3 erlauben

Überprüfen Sie die IAM-Berechtigungsgrenzen, die für die IAM-Identitäten festgelegt sind, die versuchen, auf den Bucket zuzugreifen. Bestätigen Sie, dass die IAM-Berechtigungsgrenzen den Zugriff auf Amazon S3 erlauben.

Überprüfen Sie die Einstellungen für Amazon S3 Block Public Access des Buckets

Wenn Ihre Benutzer den Access-Denied-Fehler bei öffentlichen Leseanforderungen erhalten, die erlaubt sein sollten, überprüfen Sie die Einstellungen für Amazon S3 Block Public Access des Buckets.

Überprüfen Sie die S3-Block-Einstellungen für den öffentlichen Zugriff sowohl auf Konto- als auch auf Bucket-Ebene. Diese Einstellungen können Berechtigungen außer Kraft setzen, die öffentlichen Lesezugriff ermöglichen. Amazon S3 Block Public Access kann auf einzelne Buckets oder AWS-Konten angewendet werden.

Überprüfen Sie die Benutzeranmeldeinformationen

Überprüfen Sie die Anmeldeinformationen, die Ihre Benutzer für den Zugriff auf Amazon S3 konfiguriert haben. AWS SDKs und die AWS CLI müssen so konfiguriert sein, dass sie die Anmeldeinformationen des IAM-Benutzers oder der IAM-Rolle mit Zugriff auf Ihren Bucket verwenden.

Führen Sie für die AWS CLI den Befehl configure aus, um die konfigurierten Anmeldeinformationen zu überprüfen:

aws configure list

Wenn Benutzer über eine Amazon Elastic Compute Cloud (Amazon EC2)-Instance auf Ihren Bucket zugreifen, überprüfen Sie dann, ob die Instance die richtige Rolle verwendet. Verbinden Sie sich zur Instance und führen Sie dann den Befehl get-caller-identity aus:

aws sts get-caller-identity

Überprüfen Sie die temporären Sicherheitsanmeldeinformationen

Wenn Benutzer Access-Denied-Fehler von temporären Sicherheitsanmeldeinformationen erhalten, die mit AWS Security Token Service (AWS STS) gewährt wurden, überprüfen Sie die zugehörige Richtlinie. Bei der Erstellung temporärer Sicherheitsanmeldeinformationen mit dem AssumeRole-API-Aufruf oder dem Befehl assume-role kann ein Administrator sitzungsspezifische Richtlinien übergeben.

Um die Sitzungsrichtlinien zu finden, die mit den Access-Denied-Fehlern von Amazon S3 verknüpft sind, suchen Sie im AWS-CloudTrail-Ereignisverlauf nach AssumeRole-Ereignissen. Stellen Sie sicher, dass Sie nach AssumeRole-Ereignissen im selben Zeitrahmen wie die fehlgeschlagenen Anforderungen für den Zugriff auf Amazon S3 suchen. Überprüfen Sie dann das Feld requestParameters in den entsprechenden CloudTrail-Protokollen auf alle policy- oder policyArns-Parameter. Vergewissern Sie sich, dass die zugehörige Richtlinie oder Richtlinie 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": "{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n  {\n  \"Effect\": \"Allow\",\n           
         \"Action\": [\n   \"s3:GetObject\"\n ],\n    \"Resource\": [\n \"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*\"\n  ]\n   }  }\n    ]\n}\n"
    }

Stellen Sie sicher, dass die Richtlinie von Amazon-VPC-Endpunkt die richtigen Berechtigungen für den Zugriff auf Ihre S3-Buckets und -Objekte enthält

Wenn Benutzer mit einer EC2-Instance auf Ihren Bucket zugreifen, die über einen VPC-Endpunkt weitergeleitet wird, überprüfen Sie die VPC-Endpunkt-Richtlinie.

Beispielsweise erlaubt die folgende VPC-Endpunkt-Richtlinie nur Zugriff auf DOC-EXAMPLE-BUCKET. Benutzer, die Anfragen über diesen VPC-Endpunkt senden, 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": "*"
    }
  ]
}

Überprüfen Sie die IAM-Richtlinie Ihres Amazon-S3-Zugriffspunkts

Wenn Sie einen Amazon-S3-Zugriffspunkt verwenden, um den Zugriff auf Ihren Bucket zu verwalten, überprüfen Sie die IAM-Richtlinie des Zugriffspunkts.

In einer Zugriffspunkt-Richtlinie erteilte Berechtigungen sind nur wirksam, wenn die zugrunde liegende Bucket-Richtlinie denselben Zugriff zulässt. Stellen Sie sicher, dass die Bucket-Richtlinie und die Zugriffspunkt-Richtlinie die richtigen Berechtigungen gewähren.

Vergewissern Sie sich, dass das Objekt nicht fehlt oder Sonderzeichen enthält

Prüfen Sie, ob das angeforderte Objekt im Bucket vorhanden ist. Andernfalls findet die Anforderung das Objekt nicht und Amazon S3 geht davon aus, dass das Objekt nicht vorhanden ist. Infolgedessen erhalten Sie einen Access-Denied-Fehler (anstelle von 404-Not-Found-Fehlern), wenn Sie nicht über die richtigen s3:ListBucket-Berechtigungen verfügen.

Beachten Sie auch, dass ein Objekt, das ein Sonderzeichen hat (beispielsweise ein Leerzeichen), eine spezielle Handhabung erfordert, um das Objekt abrufen zu können.

Führen Sie den AWS-CLI-Befehl head-object aus, um zu überprüfen, ob ein Objekt im Bucket existiert. Ersetzen Sie DOC-EXAMPLE-BUCKET durch den Namen des Buckets, den Sie überprüfen möchten.

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

Wenn das Objekt im Bucket vorhanden ist, maskiert der Access-Denied-Fehler nicht den 404-Not-Found-Fehler. Überprüfen Sie weitere Konfigurations-Anforderungen, um den Access-Denied-Fehler zu beheben.

Wenn das Objekt im Bucket nicht vorhanden ist, maskiert der Access-Denied-Fehler den 404-Not-Found-Fehler. Beheben Sie das Problem im Zusammenhang mit dem fehlenden Objekt.

Überprüfen Sie die Konfiguration der AWS-KMS-Verschlüsselung

Beachten Sie das Folgende zur AWS KMS (SSE-KMS)-Verschlüsselung:

  • Wenn ein IAM-Benutzer nicht auf ein Objekt zugreifen kann, für das der Benutzer volle Berechtigungen hat, prüfen Sie, ob das Objekt von SSE-KMS verschlüsselt ist. Sie können die Amazon-S3-Konsole verwenden, um die Eigenschaften des Objekts anzuzeigen, welche die Verschlüsselungsinformationen des Objekts enthalten.
  • Wenn das Objekt mit SSE-KMS verschlüsselt ist, stellen Sie sicher, dass die KMS-Schlüsselrichtlinie dem IAM-Benutzer die mindestens erforderlichen Berechtigungen für die Verwendung des Schlüssels gewährt. Wenn der IAM-Benutzer den Schlüssel beispielsweise nur zum Herunterladen eines S3-Objekts verwendet, muss der IAM-Benutzer über kms:Decrypt-Berechtigungen verfügen. Weitere Informationen finden Sie unter Erlauben des Zugriffs auf das AWS-Konto und die Aktivierung von IAM-Richtlinien.
  • Wenn sich die IAM-Identität und der Schlüssel im selben Konto befinden, sollten KMS:Decrypt-Berechtigungen mithilfe der Schlüsselrichtlinie erteilt werden. Die Schlüsselrichtlinie muss auf dieselbe IAM-Identität wie die IAM-Richtlinie verweisen.
  • Wenn der IAM-Benutzer zu einem anderen Konto gehört als der AWS-KMS-Schlüssel, müssen diese Berechtigungen außerdem in der IAM-Richtlinie erteilt werden. Um beispielsweise die mit SSE-KMS verschlüsselten Objekte herunterzuladen, müssen die Berechtigungen kms:Decrypt sowohl in der Schlüsselrichtlinie als auch in der IAM-Richtlinie angegeben werden. Mehr Informationen zum kontenübergreifenden Zugriff zwischen dem IAM-Benutzer und dem KMS-Schlüssel finden Sie unter Benutzern in anderen Konten die Verwendung eines KMS-Schlüssels erlauben.

Vergewissern Sie sich, dass der request-payer-Parameter von Benutzern angegeben wurde (wenn Sie Zahlung durch den Anforderer verwenden)

Wenn in Ihrem Bucket Zahlung durch den Anforderer aktiviert ist, müssen Benutzer anderer Konten den request-payer-Parameter angeben, wenn sie Anfragen an Ihren Bucket senden. Um zu überprüfen, ob Zahlung durch den Anforderer aktiviert ist, können Sie die Amazon-S3-Konsole verwenden, um die Eigenschaften Ihres Buckets anzuzeigen.

Der folgende AWS-CLI-Beispielbefehl enthält den richtigen Parameter für den Zugriff auf einen Bucket mit Zahlung durch den Anforderer:

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

Überprüfen Sie Ihre Service-Kontrollrichtlinien für AWS Organizations

Wenn Sie AWS Organizations verwenden, überprüfen Sie die Service-Kontrollrichtlinien, um sicherzustellen, dass der Zugriff auf Amazon S3 erlaubt ist. Service-Kontrollrichtlinien legen die maximalen Berechtigungen für die betroffenen Konten fest. Die folgende Richtlinie verweigert beispielsweise explizit den Zugriff auf Amazon S3 und führt zu einem Access-Denied-Fehler:

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

Weitere Informationen zu den Funktionen von AWS Organizations finden Sie unter Aktivieren aller Funktionen in Ihrer Organisation.


War dieser Artikel hilfreich?


Benötigen Sie Hilfe zur Fakturierung oder technischen Support?