DevOps Wissensdatenbank
DevOps Wissensdatenbank

Behebung von 'Access Denied'-Fehlern und Authentifizierungsproblemen in der AWS CLI

Beheben Sie systematisch 'Access Denied'-Fehler und Authentifizierungsfehler bei der Verwendung der AWS CLI. Dieser Leitfaden behandelt wesentliche Diagnose-Schritte, beginnend mit der Validierung von Anmeldeinformationen mithilfe von `aws sts get-caller-identity`, der Untersuchung der komplexen IAM-Richtlinienauswertungshierarchie und der Behebung von Problemen, die durch temporäre Anmeldeinformationen oder ressourcenbasierte Richtlinien (wie S3-Bucket-Richtlinien) entstehen. Erfahren Sie, wie Sie Schlüsselbefehle und den IAM Policy Simulator verwenden, um Autorisierungsfehler in Ihrer AWS-Umgebung schnell zu identifizieren und zu beheben.

49 Aufrufe

Fehlerbehebung bei „Zugriff verweigert“ und Authentifizierungsproblemen in der AWS CLI

Fehler wie Access Denied oder unerwartete Authentifizierungsausfälle bei der Verwendung der AWS Command Line Interface (CLI) gehören zu den häufigsten Hürden für Entwickler und Systemadministratoren. Diese Probleme wurzeln fast immer in falsch konfigurierten Identity and Access Management (IAM)-Richtlinien, abgelaufenen temporären Anmeldeinformationen oder einer fehlerhaften Einrichtung der CLI-Umgebung.

Die erfolgreiche Behebung dieser Fehler erfordert einen systematischen Ansatz, beginnend mit der Überprüfung Ihrer Identität und Anmeldeinformationen bis hin zur detaillierten Auswertung der IAM-Richtlinien. Dieser umfassende Leitfaden bietet umsetzbare Schritte und Diagnosebefehle, um häufige Autorisierungsprobleme in der AWS CLI schnell zu identifizieren und zu beheben, sodass Sie Ihre Ressourcen effektiv verwalten können.

1. Erste Diagnose: Ermittlung des Aufrufers und der Anmeldeinformationen

Bevor Sie sich mit komplexen Richtlinienanalysen befassen, besteht der erste Schritt darin, eindeutig 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 kritischste Diagnosebefehl. Er teilt Ihnen genau mit, 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 Rolle übereinstimmt, arbeiten Sie unter dem falschen AWS-Profil oder den falschen Umgebungsvariablen.

Profilkonfiguration und Region überprüfen

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

# Konfigurierte Einstellungen für das Standardprofil prüfen
aws configure list

# Oder ein spezifisches Profil prüfen
aws configure list --profile prod-admin

Wenn die Ausgabe keine Region oder eine falsche Region anzeigt, können Vorgänge für globale Ressourcen oder regionsspezifische Dienste (wie S3-Buckets oder EC2-Instanzen) fehlschlagen, was manchmal zu einem Access Denied führt, wenn die Ressource nicht dort gefunden wird, wo die CLI sucht.

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

Umgang mit temporären Anmeldeinformationen

Wenn Sie eine IAM-Rolle verwenden (über STS AssumeRole), arbeitet die CLI mit temporären Anmeldeinformationen, die ein SessionToken enthalten. Diese Anmeldeinformationen laufen ab (typischerweise nach 1 Stunde). Obwohl die AWS CLI sie normalerweise automatisch aktualisiert, wenn sie aus der Standard-Credential-Provider-Kette stammen, können manuelle Konfigurationen fehlschlagen.

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

Lösung: Wenn Sie ein benutzerdefiniertes Skript oder eine manuell geladene Umgebung verwenden, stellen Sie sicher, dass Ihre Methode zur Annahme der Rolle einen Mechanismus zur Aktualisierung der Anmeldeinformationen bei deren Ablauf enthält.

2. Vertiefte Analyse von IAM-Richtlinien und Autorisierung

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

Die Hierarchie der IAM-Richtlinienauswertung

Autorisierungsfehler treten typischerweise aufgrund einer der folgenden Richtlinienkomponenten auf:

  1. Explizite Verweigerung (Explicit Deny): Eine explizite Deny-Anweisung in jeder zutreffenden Richtlinie (Identität, Ressource oder Grenze) überschreibt immer eine Allow-Anweisung.
  2. Fehlende Genehmigung (Missing Allow): Keine der für die Identität oder Ressource geltenden Richtlinien 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 Folgendes:

  • Fehlende Aktionen: Listet die Richtlinie explizit die erforderliche API-Aktion auf (z. B. s3:ListBucket, ec2:DescribeInstances)?
  • Ressourcenbeschränkungen: Schränkt die Richtlinie die Aktion mithilfe des Resource-Elements auf bestimmte Ressourcen ein? Ein häufiger Fehler ist die Festlegung von Resource: "*", wenn die Aktion eine spezifische ARN erfordert, oder umgekehrt.
  • Bedingungen: Gibt es Bedingungen (z. B. Quell-IP-Adresse, Tageszeit, MFA erforderlich), die nicht erfüllt sind?

B. Ressourcenbasierte Richtlinien (S3, SQS, KMS)

Bei Diensten wie S3 oder KMS verfügt die Ressource selbst über eine Richtlinie, die festlegt, wer darauf zugreifen darf. Selbst wenn Ihre IAM-Benutzerrichtlinie den Zugriff explizit erlaubt, muss auch die Ressourcenrichtlinie dem Benutzer die Durchführung der Aktion erlauben.

Beispiel: Der Versuch, auf einen S3-Bucket (Ressourcenrichtlinie) zuzugreifen, der eine explizite Deny 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 maximal zulässigen Berechtigungen innerhalb eines Kontos. Ebenso begrenzen Permission Boundaries die maximalen Berechtigungen, die eine IAM-Entität jemals besitzen kann.

Wenn die 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. Dies hilft Ihnen, genau festzustellen, welche Richtlinienanweisung die Verweigerung verursacht.

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

Szenario 1: S3 Zugriff verweigert (Ressource vs. Identität)

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

Ursache Diagnose Lösung
Fehlende Bucket-Richtlinien-Genehmigung sts get-caller-identity funktioniert, aber aws s3 ls schlägt fehl. Ändern Sie die Bucket-Richtlinie so, dass sie die aufrufende ARN explizit für die Durchführung der erforderlichen Aktionen (s3:ListBucket, s3:GetObject) zulässt.
Fehlende KMS-Entschlüsselungsberechtigungen Der Zugriff auf verschlüsselte Objekte schlägt fehl (auch wenn die S3-Richtlinie dies erlaubt). Stellen Sie sicher, dass die IAM-Entität über Berechtigungen zur Verwendung des zugrunde liegenden KMS-Schlüssels (kms:Decrypt) verfügt, 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 bewährte Sicherheitspraktiken durchsetzen, wie z. B. die Anforderung von Multi-Faktor-Authentifizierung (MFA).

Wenn Ihre Richtlinie eine Bedingung wie die folgende enthält:

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

Und Sie versuchen, einen Befehl ohne authentifiziertem 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. Temporäre Anmeldeinformationen mit Ihrem MFA-Token abrufen
aws sts get-session-token --serial-number arn:aws:iam::123456:mfa/user --token-code 123456

# 2. Die resultierenden AccessKeyId, SecretAccessKey und SessionToken als Umgebungsvariablen für Ihre CLI-Sitzung exportieren.

Szenario 3: Fehlende oder falsche Region

Obwohl dies nicht immer ein Access Denied-Fehler ist, führt der Versuch, eine Aktion für eine Ressource durchzuführen, ohne die richtige Region anzugeben, oft zu Autorisierungs- oder Ressourcen-nicht-gefunden-Fehlern, insbesondere bei der Arbeit mit regionalen Diensten wie EC2, DynamoDB oder EKS.

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

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

4. Zusammenfassung der Diagnosebefehle

Verwenden Sie diese Checkliste von Befehlen, um die Autorisierungsfehlkette 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 Prüft Profil-Einstellungen, Region und Ausgabeformat.
Richtlinien-Gültigkeit testen (IAM Policy Simulator verwenden) Prü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 anzuzeigen, bei dem die Richtlinienevaluierung fehlgeschlagen ist.

Fazit: Best Practices zur Prävention

Um Access Denied-Fehler in der AWS CLI zu minimieren, sollten Sie diese Sicherheits- und Betriebsverfahren befolgen:

  1. Prinzip der geringsten Rechte verwenden: Gewähren Sie * (Platzhalter)-Zugriff nur, wenn dies unbedingt erforderlich ist. Beschränken Sie Richtlinien eng auf erforderliche Aktionen und Ressourcen.
  2. IAM-Rollen verwenden: Bevorzugen Sie die Annahme von IAM-Rollen gegenüber der Verwendung von langlebigen IAM-Benutzerschlüsseln, insbesondere in Skripten oder CI/CD-Pipelines. Dies begrenzt die Expositionszeit, falls Anmeldeinformationen durchsickern.
  3. CloudTrail prüfen: Wenn das Problem weiterhin besteht, ist AWS CloudTrail die maßgebliche Quelle. Ein protokolliertes Ereignis für einen fehlgeschlagenen API-Aufruf enthält oft den Grund für den Fehler (z. B. Deny by Policy X, MFA required).
  4. Profile verwalten: Benennen und verwalten Sie separate Profile für verschiedene AWS-Konten oder Rollen (--profile) klar. Vermeiden Sie die Vermischung von Umgebungsvariablen mit der Profilkonfiguration.