Access Denied diagnostizieren

Einführung

Ein Berichtsleser erhält nach einer Richtlinienmigration AccessDenied. Du untersuchst Aufrufer, angeforderte Aktion, Ressource und Verweigerungsanweisung und reparierst jeweils eine Abweichung, während der eingeschränkte Umfang des Lesers erhalten bleibt.

Schließe zuerst Einem Berichtsleser minimale Berechtigungen geben ab, um Richtlinienfelder und explizites Deny kennenzulernen. Diese neue VM bereitet default für die Verwaltung und reader für die Aufgabe vor. Arbeite in /home/labex/project und vergleiche die gespeicherte Richtlinie mit tatsächlichen Lesezugriffen in AWS View.

Bezug zu Zertifizierungen

Lab-Überblick

Bestätige den Aufrufer und korrigiere die angeforderte Aktion

In diesem Schritt unterscheidest du einen Identitätsfehler von einer Richtlinienabweichung und korrigierst dann die Allow-Aktion. Derselbe Befehl mit unterschiedlichen Zugangsdaten kann ein anderes Autorisierungsergebnis erzeugen.

Die migrierte Richtlinie enthält mehrere Fehler. Nach der Korrektur eines Felds kann ein anderes Feld oder das explizite Deny die Anfrage weiterhin ablehnen. Prüfe nach jeder Änderung das gespeicherte Dokument und wiederhole dieselbe Leseranfrage; ein unverändertes AccessDenied zeigt allein nicht, ob diese einzelne Korrektur richtig war.

cd /home/labex/project

aws sts get-caller-identity --query Arn --output text

aws sts get-caller-identity --profile reader --query Arn --output text

Erwarte user/iam05-operator und user/report-reader. Die Berichtsaufgabe verwendet den Leser und nicht den Operator. Bestätige mit dem Operator, dass das Objekt existiert, und reproduziere dann den Fehler der Aufgabe als Leser.

aws s3api get-object \
  --bucket labex-iam05-reports \
  --key reports/today.txt operator-report.txt

cat operator-report.txt

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt reader-before.txt || true

Der Operator erhält Daily orders: 145; der Leser erhält AccessDenied. Ein fehlender Schlüssel oder Verbindungsfehler würde eine andere Untersuchung erfordern. || true lässt diese erwartete fehlgeschlagene Anfrage in einer eingefügten Folge enden.

Liste die Richtlinien des Lesers auf und lies das gespeicherte Dokument. Dies sind Operatorabfragen über die Identität der Aufgabe und keine Versuche, der Aufgabe Operatorzugriff zu leihen.

aws iam list-user-policies --user-name report-reader

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

Das Allow benennt s3:ListBucket, während der Fehler GetObject nennt. ListBucket listet Objektnamen auf und verwendet eine Bucket-ARN; es lädt keine Objektbytes herunter. Ändere nur die Allow-Action auf GetObject und behalte die aktuelle Resource und das Deny bei, damit du die nächste Abweichung separat diagnostizieren kannst.

cat > repair-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[
  {"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports"},
  {"Effect":"Deny","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports/reports/*"}
]}
JSON

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt reader-action-fix.txt || true

Die Anfrage liefert weiterhin AccessDenied. Action ist jetzt korrekt, aber das Korrigieren eines Feldes garantiert nicht, dass jede anwendbare Prüfung besteht.

Verwende die vollständige Objekt-ARN

In diesem Schritt reparierst du Resource und erhältst dabei die Verweigerungsanweisung. GetObject gilt für eine Objekt-ARN, die ihren Schlüssel enthält. Die Bucket-ARN arn:aws:s3:::labex-iam05-reports entspricht nicht arn:aws:s3:::labex-iam05-reports/reports/today.txt.

Ersetze die Allow-Resource durch genau die Objekt-ARN von heute. Verwende kein * über Buckets oder Schlüssel hinweg; die Aufgabe hat eine benötigte Eingabe.

cat > repair-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[
  {"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports/reports/today.txt"},
  {"Effect":"Deny","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports/reports/*"}
]}
JSON

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt reader-resource-fix.txt || true

Erwarte erneut AccessDenied. Jetzt passt das Allow sowohl zu Action als auch zu Resource, untersuche deshalb die verbleibende Anweisung. Ihr Deny passt ebenfalls zu GetObject auf reports/*, einschließlich heute. Ein passendes explizites Deny hat Vorrang vor dem Allow; das Verschieben des Allow an eine spätere Stelle im Dokument kann es nicht überschreiben.

Repariere das Deny, ohne den Zugriff zu erweitern

In diesem Schritt korrigierst du den migrierten Deny-Umfang und bestätigst die minimale Reparatur. Die vorgesehene Schutzregel schützt private Daten; sie sollte die Berichtseingabe nicht verweigern. Behalte das genaue Lese-Allow bei und begrenze das Deny auf private/*, statt Schutz zu entfernen oder breitere Berechtigungen hinzuzufügen.

cat > repair-policy.json <<'JSON'
{"Version":"2012-10-17","Statement":[
  {"Effect":"Allow","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports/reports/today.txt"},
  {"Effect":"Deny","Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam05-reports/private/*"}
]}
JSON

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --policy-document file://repair-policy.json

aws s3api get-object \
  --profile reader \
  --bucket labex-iam05-reports \
  --key reports/today.txt today.txt

cat today.txt

Erwarte Daily orders: 145. Teste die benachbarten Ressourcen als derselbe Leser; die abgeschlossene Reparatur darf seinen Umfang nicht erweitern.

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/yesterday.txt yesterday-denied.txt || true

aws s3api get-object --profile reader --bucket labex-iam05-reports --key private/payroll.txt payroll-denied.txt || true

aws s3api get-object --profile reader --bucket labex-iam05-reference --key reference.txt reference-denied.txt || true

Alle drei müssen AccessDenied zurückgeben. Eine erforderliche Leseberechtigung darf auch keine Schreibvorgänge autorisieren. Versuche den bereitgestellten Ersatz und prüfe dann, dass die ursprünglichen Berichtsbytes unverändert bleiben.

aws s3api put-object --profile reader --bucket labex-iam05-reports --key reports/today.txt --body upload.txt || true

aws s3api get-object \
  --profile reader \
  --bucket labex-iam05-reports \
  --key reports/today.txt today.txt

cat today.txt

aws iam get-user-policy \
  --user-name report-reader \
  --policy-name LabReport \
  --query PolicyDocument

Erwarte PutObject AccessDenied und unverändertes Daily orders: 145. AWS View zeigt jetzt heute Readable und die anderen Ressourcen Denied. Die Richtlinienuntersuchung erklärt die Reparatur; tatsächliche Anfragen zeigen ihre Wirkung.

Entziehe die Reparaturberechtigung und entferne eigene Daten

In diesem Schritt entfernst du LabReport und beweist, dass der Zugriff entzogen ist, während der Bericht noch existiert. Lösche anschließend nur den eigenen Berichts-Bucket und seine drei Schlüssel.

aws iam delete-user-policy --user-name report-reader --policy-name LabReport

aws iam list-user-policies --user-name report-reader

aws s3api get-object --profile reader --bucket labex-iam05-reports --key reports/today.txt revoked.txt || true

Erwarte eine leere Richtlinienliste und AccessDenied. Richtlinienentzug und Datenlöschung sind separate Prüfungen. Lasse den Referenz-Bucket unverändert.

aws s3api delete-object --bucket labex-iam05-reports --key reports/today.txt

aws s3api delete-object --bucket labex-iam05-reports --key reports/yesterday.txt

aws s3api delete-object --bucket labex-iam05-reports --key private/payroll.txt

aws s3api list-objects-v2 --bucket labex-iam05-reports

Prüfe KeyCount: 0 in einer erfolgreichen authentifizierten Antwort ohne verbleibende Objekteinträge in Contents.

aws s3api delete-bucket --bucket labex-iam05-reports

aws s3api list-buckets --query 'Buckets[].Name'

aws s3api get-object --bucket labex-iam05-reference --key reference.txt reference.txt

cat reference.txt

Nur der Referenz-Bucket mit Platform reference: keep bleibt erhalten. Dienstfehler beweisen keine Löschung. Die vorbereiteten Identitäten werden beim Ende der Umgebung entfernt; die Richtlinie der Aufgabe und die eigenen Übungsdaten sind entfernt.

Zusammenfassung

Du hast den Aufrufer bestätigt, die fehlschlagende Operation mit der Allow-Action verglichen, die vollständige Objekt-ARN verwendet und ein überlappendes explizites Deny korrigiert. Zwischenzeitliche Fehler halfen, verbleibende Hindernisse zu identifizieren. Der endgültige Leser konnte nur seinen benötigten Bericht lesen und weder darin schreiben noch unbeteiligte Daten lesen. Du hast die reparierte Berechtigung entzogen und die begrenzte Bereinigung abgeschlossen. Verwende bei der Zugriffsdiagnose dieselbe Identität und teste sowohl erfolgreiche als auch verbotene Anfragen.

Weitere Informationen bietet die AWS-Dokumentation: Diagnose verweigerter IAM-Zugriffe.