S3 403 AccessDenied: Der vollständige Fehlerbehebungsleitfaden

Ihre Anwendung gibt diesen Fehler beim Lesen aus S3 zurück:

An error occurred (AccessDenied) when calling the GetObject operation:
Access Denied

Oder Ihre CI/CD-Pipeline schlägt fehl mit:

fatal error: An error occurred (403) when calling the HeadObject operation:
Forbidden

Der S3 403 AccessDenied-Fehler ist besonders frustrierend, weil S3 mehr Zugriffssteuerungsebenen hat als jeder andere AWS-Service. Zwischen IAM-Policies, Bucket Policies, ACLs, Block Public Access-Einstellungen, VPC-Endpoint-Policies, S3 Object Ownership und KMS-Verschlüsselung gibt es über ein Dutzend verschiedene Gründe, warum Sie eine 403-Antwort erhalten könnten. Und die Fehlermeldung ist immer das gleiche nichtssagende "Access Denied" ohne Hinweis darauf, welche Ebene den Zugriff blockiert hat.

Ich habe Hunderte von S3-Zugriffsproblemen bei Kunden debuggt. Hier sind die Ursachen in der Reihenfolge, wie häufig ich sie antreffe, zusammen mit den exakten Befehlen zur Diagnose und Behebung.

Ursache 1: S3 Block Public Access ist aktiviert

Dies ist die Hauptursache, die ich sehe, wenn Teams versuchen, Objekte öffentlich zugänglich zu machen. Seit April 2023 haben alle neuen S3-Buckets Block Public Access standardmäßig sowohl auf Konto- als auch auf Bucket-Ebene aktiviert. Dies überschreibt jede Bucket Policy oder ACL, die versucht, öffentlichen Zugriff zu gewähren.

Diagnose

Prüfen Sie sowohl die Block Public Access-Einstellungen auf Konto- als auch auf Bucket-Ebene:

# Einstellungen auf Kontoebene
aws s3control get-public-access-block \
  --account-id 123456789012

# Einstellungen auf Bucket-Ebene
aws s3api get-public-access-block \
  --bucket my-bucket

Die Ausgabe zeigt vier Einstellungen. Jede einzelne kann den Zugriff blockieren:

{
  "PublicAccessBlockConfiguration": {
    "BlockPublicAcls": true,
    "IgnorePublicAcls": true,
    "BlockPublicPolicy": true,
    "RestrictPublicBuckets": true
  }
}

Lösung

Wenn Sie absichtlich öffentlichen Zugriff benötigen (z.B. für Static Website Hosting), deaktivieren Sie die entsprechenden Einstellungen auf Bucket-Ebene:

aws s3api put-public-access-block \
  --bucket my-bucket \
  --public-access-block-configuration \
    BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false

Für die meisten Anwendungsfälle sollten Sie Block Public Access jedoch aktiviert lassen und stattdessen Presigned URLs oder CloudFront mit Origin Access Control verwenden.

Ursache 2: Explizites Deny in der Bucket Policy

Ein explizites Deny-Statement in einer Bucket Policy überschreibt alle Allow-Statements — sowohl in der Bucket Policy als auch in IAM-Policies. Dies ist ein grundlegendes IAM-Auswertungsprinzip, das viele Teams stolpern lässt.

Diagnose

Rufen Sie die Bucket Policy ab und prüfen Sie sie:

aws s3api get-bucket-policy \
  --bucket my-bucket \
  --output text | python3 -m json.tool

Suchen Sie nach Deny-Statements. Ein häufiges Muster, das Probleme verursacht, ist eine IP-Restriktions-Policy:

{
  "Sid": "DenyNonOfficeIPs",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": ["203.0.113.0/24"]
    }
  }
}

Diese Policy verweigert alle S3-Aktionen von jeder IP außerhalb des angegebenen Bereichs — einschließlich AWS-Services, Lambda-Funktionen und CI/CD-Pipelines, die nicht von diesen IPs stammen.

Lösung

Verfeinern Sie das Deny-Statement, um AWS-Service-Principals und bestimmte IAM-Rollen auszuschließen:

{
  "Sid": "DenyNonOfficeIPsExceptAWSServices",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": ["203.0.113.0/24"]
    },
    "StringNotLike": {
      "aws:PrincipalArn": [
        "arn:aws:iam::123456789012:role/LambdaRole",
        "arn:aws:iam::123456789012:role/CICDRole"
      ]
    }
  }
}

Ursache 3: Fehlende S3-Berechtigungen in der IAM-Policy

Der aufrufende IAM-Principal (Benutzer oder Rolle) hat möglicherweise nicht die erforderlichen S3-Berechtigungen. Dies ist unkompliziert, aber es lohnt sich, systematisch zu prüfen.

Diagnose

Simulieren Sie die S3-Aktion gegen die IAM-Policies des Aufrufers:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/MyAppRole \
  --action-names s3:GetObject s3:PutObject s3:ListBucket \
  --resource-arns \
    arn:aws:s3:::my-bucket \
    arn:aws:s3:::my-bucket/* \
  --query 'EvaluationResults[*].{Action:EvalActionName,Decision:EvalDecision,Matched:MatchedStatements[0].SourcePolicyId}'

Beachten Sie, dass s3:ListBucket für die Bucket-ARN gilt (arn:aws:s3:::my-bucket), während s3:GetObject für die Objekt-ARN gilt (arn:aws:s3:::my-bucket/*). Diese zu verwechseln ist ein häufiger Fehler.

Lösung

Stellen Sie sicher, dass die IAM-Policy das korrekte ARN-Format verwendet:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Read",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Sid": "AllowS3List",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListBucketVersions"
      ],
      "Resource": "arn:aws:s3:::my-bucket"
    }
  ]
}

Ursache 4: VPC-Endpoint-Policy beschränkt S3-Zugriff

Wenn Ihre Anwendung in einer VPC mit einem S3-VPC-Endpoint (Gateway-Endpoint) läuft, hat der Endpoint eine eigene Policy, die einschränken kann, welche Buckets erreichbar sind. Die Standard-Policy erlaubt alle S3-Aktionen, aber viele Organisationen wenden restriktive Endpoint-Policies an.

Diagnose

Finden Sie den VPC-Endpoint und prüfen Sie seine Policy:

# S3 Gateway-Endpoints finden
aws ec2 describe-vpc-endpoints \
  --filters "Name=service-name,Values=com.amazonaws.us-east-1.s3" \
  --query 'VpcEndpoints[*].{
    ID:VpcEndpointId,
    VpcId:VpcId,
    State:State,
    RouteTableIds:RouteTableIds
  }'

# Endpoint-Policy abrufen
aws ec2 describe-vpc-endpoints \
  --vpc-endpoint-ids vpce-0abc123 \
  --query 'VpcEndpoints[0].PolicyDocument' \
  --output text | python3 -m json.tool

Lösung

Aktualisieren Sie die Endpoint-Policy, um Zugriff auf die erforderlichen Buckets zu erlauben:

aws ec2 modify-vpc-endpoint \
  --vpc-endpoint-id vpce-0abc123 \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "AllowSpecificBuckets",
        "Effect": "Allow",
        "Principal": "*",
        "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
        "Resource": [
          "arn:aws:s3:::my-bucket",
          "arn:aws:s3:::my-bucket/*",
          "arn:aws:s3:::my-other-bucket",
          "arn:aws:s3:::my-other-bucket/*"
        ]
      }
    ]
  }'

Ursache 5: Cross-Account-Zugriff fehlkonfiguriert

Der Zugriff auf einen S3-Bucket in einem anderen AWS-Konto erfordert, dass die Bucket Policy dem aufrufenden Konto oder Principal Zugriff gewährt. IAM-Policies im Konto des Aufrufers sind notwendig, aber nicht ausreichend.

Diagnose

Prüfen Sie den Bucket-Besitzer. Wenn der Bucket in einem anderen Konto liegt, benötigen Sie Cross-Account-Zugriff:

# Dies zeigt die kanonische ID des Bucket-Besitzers
aws s3api get-bucket-acl --bucket my-bucket \
  --query 'Owner.ID'

Lösung

Im Konto des Bucket-Besitzers fügen Sie eine Bucket Policy hinzu, die Zugriff gewährt:

{
  "Sid": "CrossAccountRead",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::222222222222:role/ExternalAppRole"
  },
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ]
}

Im aufrufenden Konto benötigt die IAM-Rolle ebenfalls die gleichen S3-Berechtigungen in ihrer IAM-Policy.

Ursache 6: S3 Object Ownership und ACL-Probleme

Seit April 2023 verwenden neue Buckets standardmäßig BucketOwnerEnforced für Object Ownership, was ACLs vollständig deaktiviert. Wenn Ihre Anwendung auf ACLs angewiesen ist (z.B. bucket-owner-full-control bei Cross-Account-Uploads), kann diese Einstellung 403-Fehler verursachen.

Diagnose

Prüfen Sie die Object Ownership-Einstellung:

aws s3api get-bucket-ownership-controls \
  --bucket my-bucket

Wenn BucketOwnerEnforced zurückgegeben wird, sind ACLs deaktiviert. Jeder API-Aufruf mit einem ACL-Header schlägt mit AccessDenied fehl.

Lösung

Wenn Sie ACLs benötigen, ändern Sie die Object Ownership-Einstellung:

aws s3api put-bucket-ownership-controls \
  --bucket my-bucket \
  --ownership-controls Rules=[{ObjectOwnership=BucketOwnerPreferred}]

Der bessere Ansatz ist jedoch, ACL-Header aus Ihrer Anwendung zu entfernen und ausschließlich Bucket Policies für die Zugriffssteuerung zu verwenden.

Ursache 7: SSE-KMS-Verschlüsselung erfordert kms:Decrypt

Wenn der Bucket SSE-KMS-Verschlüsselung verwendet, erfordert das Lesen von Objekten sowohl s3:GetObject als auch kms:Decrypt-Berechtigungen für den KMS-Schlüssel. Dies überrascht viele Teams, weil der S3-Fehler KMS überhaupt nicht erwähnt.

Diagnose

Prüfen Sie die Standard-Verschlüsselung des Buckets:

aws s3api get-bucket-encryption \
  --bucket my-bucket \
  --query 'ServerSideEncryptionConfiguration.Rules[0].ApplyServerSideEncryptionByDefault'

Wenn SSEAlgorithm den Wert aws:kms hat, benötigen Sie zusätzlich zu den S3-Berechtigungen auch KMS-Berechtigungen.

Lösung

Fügen Sie KMS-Berechtigungen zur IAM-Policy hinzu:

{
  "Sid": "AllowKMSForS3",
  "Effect": "Allow",
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "arn:aws:kms:us-east-1:123456789012:key/mrk-abc123"
}

Systematische Debugging-Checkliste

Bei einer S3 403-Fehlermeldung gehen Sie diese Diagnosesequenz durch:

# 1. Block Public Access prüfen (wenn öffentlicher Zugriff erwartet)
aws s3api get-public-access-block --bucket BUCKET 2>&1

# 2. Bucket Policy auf Deny-Statements prüfen
aws s3api get-bucket-policy --bucket BUCKET --output text 2>&1

# 3. IAM-Berechtigungen simulieren
aws iam simulate-principal-policy \
  --policy-source-arn ROLE_ARN \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::BUCKET/*

# 4. Object Ownership prüfen
aws s3api get-bucket-ownership-controls --bucket BUCKET 2>&1

# 5. Bucket-Verschlüsselung prüfen (für SSE-KMS)
aws s3api get-bucket-encryption --bucket BUCKET 2>&1

# 6. VPC-Endpoint-Policies prüfen (wenn in VPC)
aws ec2 describe-vpc-endpoints \
  --filters "Name=service-name,Values=com.amazonaws.REGION.s3"

# 7. Bucket-ACL prüfen
aws s3api get-bucket-acl --bucket BUCKET

Best Practices zur Prävention

CloudTrail Data Events verwenden

Aktivieren Sie CloudTrail Data Events für S3, um jeden objektbezogenen API-Aufruf zu protokollieren. So sehen Sie genau, welcher Principal welche Aktion aufgerufen hat und was die Antwort war:

aws cloudtrail put-event-selectors \
  --trail-name my-trail \
  --event-selectors '[{
    "ReadWriteType": "All",
    "IncludeManagementEvents": true,
    "DataResources": [{
      "Type": "AWS::S3::Object",
      "Values": ["arn:aws:s3:::my-bucket/"]
    }]
  }]'

IAM Access Analyzer verwenden

IAM Access Analyzer kann S3-Buckets mit unbeabsichtigtem öffentlichem oder kontoübergreifendem Zugriff identifizieren:

aws accessanalyzer create-analyzer \
  --analyzer-name s3-access-review \
  --type ACCOUNT

Auf Bucket Policies standardisieren, nicht ACLs

Setzen Sie BucketOwnerEnforced auf allen Buckets und verwenden Sie ausschließlich Bucket Policies. Dies eliminiert eine ganze Klasse von Zugriffsproblemen:

aws s3api put-bucket-ownership-controls \
  --bucket my-bucket \
  --ownership-controls Rules=[{ObjectOwnership=BucketOwnerEnforced}]

Brauchen Sie Hilfe bei S3-Zugriffsproblemen?

Die S3-Zugriffssteuerung ist trügerisch komplex. Wir haben erlebt, wie Organisationen Tage damit verloren haben, 403-Fehler zu debuggen, die sich als eine einzige fehlkonfigurierte VPC-Endpoint-Policy oder eine übersehene Block Public Access-Einstellung herausstellten. Wenn Ihr Team zu viel Zeit mit Access-Denied-Fehlern verbringt, können wir Ihre S3-Zugriffsarchitektur überprüfen und Muster implementieren, die diese Probleme in Zukunft verhindern.

Kontaktieren Sie uns für eine kostenlose AWS-Beratung