Fehlerbehebung bei 'Access Denied' und Authentifizierungsproblemen in der AWS CLI

Access Denied in der AWS CLI ist frustrierend, da die Nachricht oft den fehlgeschlagenen API-Aufruf nennt, aber nicht die Richtlinienzeile, die ihn verursacht hat. Diese Probleme sind fast immer auf falsch konfigurierte Identity and Access Management (IAM)-Richtlinien, abgelaufene temporäre Anmeldeinformationen oder eine falsche Einrichtung der CLI-Umgebung zurückzuführen.

Eine nützliche Gewohnheit ist es, das Problem in zwei Fragen aufzuteilen: Wer ruft die CLI auf, und welche Richtliniengrenze hindert diese Identität daran, die Aktion auszuführen?

1. Erste Diagnose: Identifizierung des Aufrufers und der Anmeldeinformationen

Bevor Sie sich in eine komplexe Richtlinienanalyse stürzen, besteht der erste Schritt darin, definitiv zu bestätigen, welche IAM-Identität die AWS CLI verwendet und ob diese Anmeldeinformationen noch gültig sind.

Aktuelle Identität prüfen: `sts get-caller-identity`

Dies ist der wichtigste Diagnosebefehl. Er zeigt Ihnen genau an, welche Benutzer-ARN, Rollen-ARN oder angenommene Rollensitzung die nachfolgenden AWS-Befehle ausführt.

aws sts get-caller-identity

Erwartete Ausgabe:

{
    "UserId": "AIDAIAMUSERID",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/DevUser"
}

Wenn die zurückgegebene ARN nicht mit dem erwarteten Benutzer oder der erwarteten Rolle übereinstimmt, arbeiten Sie mit dem falschen AWS-Profil oder den falschen Umgebungsvariablen.

Profilkonfiguration und Region überprüfen

Stellen Sie sicher, dass das richtige AWS-Profil verwendet wird, entweder über das Flag --profile oder über die Umgebungsvariable AWS_PROFILE.

# Überprüft die konfigurierten Einstellungen für das Standardprofil
aws configure list

# Oder überprüft ein bestimmtes Profil
aws configure list --profile prod-admin

Wenn die Ausgabe keine Region oder eine falsche Region anzeigt, können Operationen an globalen Ressourcen oder regionsspezifischen Diensten (wie S3-Buckets oder EC2-Instanzen) fehlschlagen, was manchmal zu einem Access Denied führt, wenn die Ressource dort nicht gefunden wird, wo die CLI sucht.

Tipp: Wenn der Befehl sts get-caller-identity selbst mit einem Authentifizierungsfehler fehlschlägt, deutet dies auf ein grundlegendes Problem mit den Zugriffsschlüsseln hin (sie könnten gelöscht, widerrufen oder falsch sein).

Umgang mit temporären Anmeldeinformationen

Wenn Sie eine IAM-Rolle (über STS AssumeRole) verwenden, arbeitet die CLI mit temporären Anmeldeinformationen, die einen SessionToken enthalten. Diese Anmeldeinformationen laufen nach der für die Sitzung konfigurierten Dauer ab, bei Standardeinstellungen oft nach einer Stunde. Während die AWS CLI sie normalerweise automatisch aktualisiert, wenn sie aus der standardmäßigen Anbieterkette für Anmeldeinformationen stammen, können manuelle Konfigurationen fehlschlagen.

Symptom: Befehle funktionieren zunächst, schlagen aber nach einer bestimmten Zeitspanne (z. B. 60 Minuten) mit einem Authentifizierungsfehler fehl.

Lösung: Wenn Sie ein benutzerdefiniertes Skript oder manuell geladene Umgebungsvariablen verwenden, stellen Sie sicher, dass Ihre Methode zum Annehmen der Rolle einen Mechanismus zum Aktualisieren der Anmeldeinformationen bei Ablauf enthält.

2. Tiefergehende Analyse von IAM-Richtlinien und Autorisierung

Sobald Sie die verwendete Identität bestätigt haben, besteht der nächste Schritt darin, herauszufinden, warum dieser Identität die erforderlichen Berechtigungen fehlen. AWS-Autorisierungsfehler sind komplex, da mehrere Richtlinien gleichzeitig ausgewertet werden.

Die IAM-Richtlinienbewertungshierarchie

Autorisierungsfehler treten typischerweise aufgrund einer der folgenden Richtlinienkomponenten auf:

Explizite Verweigerung: Eine explizite Deny-Anweisung in jeder anwendbaren Richtlinie (Identität, Ressource oder Grenze) überschreibt immer eine Allow-Anweisung.
Fehlende Erlaubnis: Keine für die Identität oder Ressource geltende Richtlinie gewährt die spezifische Aktion.

A. Identitätsbasierte Richtlinien (Benutzer und Rollen)

Überprüfen Sie die IAM-Richtlinien, die direkt an den Benutzer oder die angenommene Rolle angehängt sind. Achten Sie auf:

Fehlende Aktionen: Listet die Richtlinie die erforderliche API-Aktion speziell auf (z. B. s3:ListBucket, ec2:DescribeInstances)?
Ressourceneinschränkungen: Schränkt die Richtlinie die Aktion mit dem Element Resource auf bestimmte Ressourcen ein? Ein häufiger Fehler ist das Setzen von Resource: "*", wenn die Aktion eine bestimmte ARN erfordert, oder umgekehrt.
Bedingungen: Gibt es Bedingungen (z. B. Quell-IP-Adresse, Tageszeit, MFA erforderlich), die nicht erfüllt werden?

B. Ressourcenbasierte Richtlinien (S3, SQS, KMS)

Bei Diensten wie S3 oder KMS hat die Ressource selbst eine Richtlinie, die festlegt, wer darauf zugreifen kann. Für den Cross-Account-Zugriff und bei vielen ressourcenspezifischen Designs muss die Ressourcenrichtlinie auch den Prinzipal zulassen. Im selben Konto hängt die genaue Interaktion vom Prinzipaltyp und Dienst ab, gehen Sie also nicht davon aus, dass eine Identitätsrichtlinie allein jedes Ergebnis erklärt.

Beispiel: Der Versuch, auf einen S3-Bucket (Ressourcenrichtlinie) zuzugreifen, der eine explizite Deny-Anweisung für alle Benutzer außerhalb eines bestimmten VPC-Endpunkts enthält, führt zu Access Denied, unabhängig von der IAM-Richtlinie des Benutzers.

C. Berechtigungsgrenzen und SCPs

Wenn Ihre Organisation AWS Organizations verwendet, definieren Service Control Policies (SCPs) die maximalen Berechtigungen, die innerhalb eines Kontos erlaubt sind. Ebenso begrenzen Permission Boundaries die maximalen Berechtigungen, die eine IAM-Entität jemals besitzen kann.

Wenn das SCP oder die Grenze die erforderliche Aktion verweigert, schlägt der CLI-Vorgang fehl, selbst wenn die Identitätsrichtlinie die Berechtigung erteilt.

Praktisches Werkzeug: IAM Policy Simulator

Bei der Fehlerbehebung komplexer Fehler ist der IAM Policy Simulator in der AWS Management Console von unschätzbarem Wert. Sie können eine bestimmte Aktion (z. B. s3:GetObject) gegen eine bestimmte Ressource (z. B. arn:aws:s3:::my-bucket/key) testen und die IAM-Entität angeben, was hilft, genau die Richtlinienanweisung zu identifizieren, die die Verweigerung verursacht.

3. Häufige 'Access Denied'-Szenarien und Lösungen

Szenario 1: S3 Access Denied (Ressource vs. Identität)

S3 Access Denied ist berüchtigt, da es entweder von der Benutzerrichtlinie oder der Bucket-Richtlinie herrühren kann.

Ursache	Diagnose	Lösung
Fehlende Bucket-Richtlinien-Erlaubnis	`sts get-caller-identity` funktioniert, aber `aws s3 ls` schlägt fehl.	Ändern Sie die Bucket-Richtlinie, um der aufrufenden ARN explizit die Ausführung der erforderlichen Aktionen zu erlauben (`s3:ListBucket`, `s3:GetObject`).
Fehlende KMS-Entschlüsselungsberechtigungen	Zugriff auf verschlüsselte Objekte schlägt fehl (auch wenn die S3-Richtlinie es erlaubt).	Stellen Sie sicher, dass die IAM-Entität Berechtigungen zur Nutzung des zugrunde liegenden KMS-Schlüssels (`kms:Decrypt`) hat, der das Objekt verschlüsselt hat.
Requester Pays	Versuche, große Dateien herunterzuladen, schlagen fehl.	Wenn der Bucket `Requester Pays` erfordert, muss der CLI-Befehl das Flag `--request-payer requester` enthalten.

Szenario 2: Implizite Verweigerung aufgrund fehlgeschlagener Bedingungen

Viele Richtlinien verwenden Bedingungen, die Sicherheitsbest Practices durchsetzen, wie z. B. die Anforderung einer Multi-Faktor-Authentifizierung (MFA).

Wenn Ihre Richtlinie eine Bedingung wie diese enthält:

"Condition": {
    "Bool": {
        "aws:MultiFactorAuthPresent": "true"
    }
}

Und Sie versuchen, einen Befehl ohne authentifiziertes MFA auszuführen, wird die Aktion implizit verweigert.

Lösung: Für Befehle, die MFA erfordern, müssen Sie zuerst eine STS-Sitzung erstellen, die mit Ihrem MFA-Gerät authentifiziert ist:

# 1. Holen Sie sich temporäre Anmeldeinformationen mit Ihrem MFA-Token
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Exportieren Sie die resultierende AccessKeyId, SecretAccessKey und SessionToken als Umgebungsvariablen für Ihre CLI-Sitzung.

Szenario 3: Fehlende oder falsche Region

Obwohl es sich nicht immer um einen Access Denied-Fehler handelt, führt der Versuch, eine Aktion für eine Ressource ohne Angabe der richtigen Region durchzuführen, oft zu Autorisierungs- oder Ressourcen-nicht-gefunden-Fehlern, insbesondere bei der Arbeit mit regionalen Diensten wie EC2, DynamoDB oder EKS.

Lösung: Definieren Sie die Region explizit in Ihrem Befehl oder stellen Sie sicher, dass Ihr Profil korrekt konfiguriert ist.

aws ec2 describe-instances --region us-west-2

Dienstspezifische Prüfungen, die Zeit sparen

IAM-Fehler sind einfacher zu debuggen, wenn Sie AWS nicht als ein einziges Berechtigungssystem betrachten. Jeder Dienst fügt sein eigenes Ressourcenmodell und seine eigenen Bedingungsschlüssel hinzu.

Für S3 trennen Sie Bucket-Ebene-Aktionen von Objekt-Ebene-Aktionen. s3:ListBucket verwendet die Bucket-ARN, während s3:GetObject und s3:PutObject Objekt-ARNs unter dem Bucket verwenden. Eine Richtlinie, die s3:GetObject auf arn:aws:s3:::my-bucket gewährt, ist falsch geformt; der Objektzugriff benötigt arn:aws:s3:::my-bucket/*. Der umgekehrte Fehler ist beim Auflisten genauso häufig.

Für KMS überprüfen Sie sowohl die Schlüsselrichtlinie als auch die IAM-Richtlinie. Eine Rolle kann scheinbar kms:Decrypt haben, aber wenn die Schlüsselrichtlinie diesen Rollenpfad nicht zulässt, schlägt die Entschlüsselung dennoch fehl. Dies zeigt sich beim Herunterladen verschlüsselter S3-Objekte, beim Abrufen verschlüsselter EBS-Snapshots oder beim Lesen von Geheimnissen, die einen vom Kunden verwalteten Schlüssel verwenden.

Für ECR müssen Docker-Login und Image-Pull mehrere Dienste aufeinander abstimmen. Die CLI-Identität benötigt möglicherweise ecr:GetAuthorizationToken, und die Repository-Richtlinie muss möglicherweise Pull-Aktionen zulassen, wenn das Repository kontenübergreifend gemeinsam genutzt wird. Wenn die Cluster-Knotenrolle das Image pullt, bringt das Debuggen mit Ihrem persönlichen Admin-Profil wenig; testen Sie als Knotenrolle oder Aufgabenausführungsrolle.

Für STS Assume-Role-Workflows betrachten Sie beide Seiten der Vertrauensbeziehung. Der Aufrufer benötigt die Berechtigung, sts:AssumeRole aufzurufen, und die Vertrauensrichtlinie der Zielrolle muss dem Aufrufer vertrauen. Wenn in der Vertrauensrichtlinie eine externe ID oder MFA-Bedingung vorhanden ist, muss der Assume-Role-Befehl diese erfüllen.

Die Umgebungspriorität kann erfahrene Benutzer täuschen

Die AWS CLI liest nicht nur ~/.aws/credentials. Sie durchläuft eine Anbieterkette für Anmeldeinformationen, die Befehlszeilen-Flags, Umgebungsvariablen, benannte Profile, SSO-Cache-Einträge, Web-Identity-Tokens, EC2- oder ECS-Metadaten und im Profil konfigurierte Rollenannahmen umfassen kann. Deshalb ist aws configure list nützlicher als das Öffnen einer Datei.

Ein häufiger lokaler Fehler sieht so aus: Sie führen export AWS_PROFILE=dev aus und fügen später temporäre Produktionsanmeldeinformationen in AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN ein. Die Umgebungsschlüssel können die Kontrolle übernehmen, sodass Befehle, die wie die Verwendung von dev aussehen, tatsächlich die exportierte Sitzung verwenden. Führen Sie in einem Terminal, das den ganzen Tag geöffnet war, Folgendes aus:

env | sort | grep '^AWS_'

Wenn Sie häufig Konten wechseln, verwenden Sie separate Terminal-Tabs, einen Credential Helper oder Wrapper-Skripte, die die Aufruferidentität vor destruktiven Befehlen ausgeben. Die zusätzliche Zeile in der Ausgabe ist billiger als das Löschen aus dem falschen Konto.

4. Zusammenfassung der Diagnosebefehle

Verwenden Sie diese Checkliste von Befehlen, um die Fehlerkette bei der Autorisierung schnell zu diagnostizieren:

Ziel	Befehl	Zweck
Identität überprüfen	`aws sts get-caller-identity`	Bestätigt die ARN, die den Befehl ausführt.
Konfiguration überprüfen	`aws configure list`	Überprüft Profileinstellungen, Region und Ausgabeformat.
Richtliniengültigkeit testen	(IAM Policy Simulator verwenden)	Überprüft, ob eine IAM-Identität eine bestimmte API-Aktion für eine Ressource ausführen kann.
Richtlinienverweigerungen identifizieren	`aws cloudtrail lookup-events ...`	Verwenden Sie CloudTrail, um den genauen Ereignisdatensatz zu sehen, bei dem die Richtlinienauswertung fehlgeschlagen ist.

Ein echter Debugging-Pfad

Ein guter erster Durchlauf sieht so aus. Führen Sie den fehlschlagenden Befehl erneut mit explizit angegebenem Profil und Region aus, auch wenn Sie glauben, dass Ihre Shell bereits eingestellt ist:

AWS_PROFILE=prod-readonly aws s3 ls s3://example-audit-logs --region us-east-1
aws sts get-caller-identity --profile prod-readonly
aws configure list --profile prod-readonly

Wenn die Identität falsch ist, hören Sie dort auf. Überprüfen Sie AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_PROFILE und AWS_REGION in der Umgebung. Umgebungsanmeldeinformationen können Vorrang vor einem Profil haben und die CLI dazu bringen, als eine Rolle zu handeln, von der Sie vergessen haben, dass Sie sie zuvor exportiert haben. In CI geben Sie aws sts get-caller-identity in der Nähe des fehlschlagenden Schritts aus, damit das Build-Protokoll die zur Laufzeit verwendete Rolle beweist.

Wenn die Identität richtig ist, notieren Sie die genaue API-Aktion. Hochrangige Befehle können dies verbergen. aws s3 cp benötigt möglicherweise s3:GetObject, s3:PutObject, s3:ListBucket, kms:Decrypt oder kms:GenerateDataKey, je nach Richtung, Verschlüsselung und ob die CLI den Bucket inspizieren muss. Wenn die Fehlermeldung AccessDenied enthält, aber nicht die Aktion, gibt CloudTrail normalerweise den Ereignisnamen und die Ressource an.

Für S3 überprüfen Sie Bucket-Richtlinie, Objektbesitz, Block Public Access-Einstellungen, VPC-Endpunkt-Richtlinie und KMS-Schlüsselrichtlinie. Für KMS-verschlüsselte Objekte reicht eine S3-Erlaubnis nicht aus; der Aufrufer benötigt auch die entsprechende KMS-Berechtigung, und die Schlüsselrichtlinie muss den Prinzipalpfad zulassen. Für Organisationen überprüfen Sie SCPs, bevor Sie Identitätsrichtlinien bearbeiten. Ein SCP kann keinen Zugriff gewähren, aber es kann begrenzen, was ein Prinzipal im Konto tun darf.

Prävention ist meist langweilige Hygiene: kurzlebige Rollenanmeldeinformationen, klar benannte Profile, Least-Privilege-Richtlinien, die gegen die tatsächliche ARN getestet wurden, und CloudTrail, das aktiviert ist und von Ingenieuren tatsächlich abgefragt werden kann. Die beste Lösung ist nicht ein breiteres Action: "*"; es ist das Finden der einen fehlenden Aktion oder der einen Verweigerungsbedingung, die mit der Anfrage übereinstimmt.