Einen Bucket mit einer Ressourcenrichtlinie schützen

Einführung

Ein Bucket-Eigentümer möchte einer Berichtsrolle Zugriff gewähren und private Daten schützen. Du fügst eine Bucket-Richtlinie an, vergleichst sie mit der eigenen Richtlinie der Rolle und testest, wie sich ein passendes Deny auf den Zugriff auswirkt.

Schließe zuerst Temporäre Zugangsdaten mit einer IAM-Rolle verwenden und Einem Berichtsleser minimale Berechtigungen geben ab. Diese neue VM stellt default, report-role und other-role bereit; die Rollenprofile beschaffen bereits temporäre Sitzungen. Verwende /home/labex/project und AWS View. Halte Zugangsdaten und Caches vertraulich.

Bezug zu Zertifizierungen

Lab-Überblick

Gewähre einer Rolle Zugriff vom Bucket aus

In diesem Schritt fügst du eine Ressourcenrichtlinie an, die ReportReader Zugriff auf das Berichtspräfix gewährt. Anders als eine Identitätsrichtlinie muss die Bucket-Richtlinie Principal angeben. Verwende die IAM-Rollen-ARN, die die Rolle identifiziert; die assumed-role-Sitzungs-ARN identifiziert eine Verwendung davon.

Du hast Zugriff über eine Identität erteilt; jetzt erteilt ihn der Bucket-Eigentümer über die Ressource. Beide Rollenprofile sind vorbereitet. Lass ihre Vertrauensbeziehungen unverändert und untersuche, wie Bucket- und Rollenrichtlinie dieselben Anfragen beeinflussen.

Eine Ressourcenrichtlinie wird auf der Ressource gespeichert. Eine S3-Bucket-Richtlinie ist ein Beispiel: Ihr Principal identifiziert, wessen Anfragen die Anweisung abdeckt. Vergleiche dies mit einer Identitätsrichtlinie, die auf einem Benutzer oder einer Rolle gespeichert wird.

Bestätige die zwei aktiven Sitzungsidentitäten und die zunächst leere Liste der Berechtigungsrichtlinien der Berichtsrolle.

cd /home/labex/project

aws sts get-caller-identity --profile report-role --query Arn --output text

aws sts get-caller-identity --profile other-role --query Arn --output text

aws iam list-role-policies --role-name ReportReader

Erwarte assumed-role/ReportReader/report-run und assumed-role/OtherReader/other-run sowie eine leere Liste PolicyNames. Die Authentifizierung als Rolle allein autorisiert keinen S3-Zugriff. Teste den aktuellen Lesezugriff:

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt before.txt || true

Erwarte AccessDenied. || true verhindert, dass ein erwarteter Fehler eine eingefügte Folge anhält. Verbindungsfehler beweisen keine Verweigerung.

Schreibe die Bucket-Richtlinie. GetObject gewährt Objektlesezugriffe; Resource begrenzt sie auf reports/ in diesem einen Bucket. Der Rollen-Principal schließt OtherReader aus und gewährt keinen öffentlichen Zugriff.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

aws s3api get-bucket-policy --bucket labex-iam04-reports --query Policy --output text

Die Bucket-Richtlinie ist jetzt auf dem Bucket gespeichert und nicht an die Rolle angefügt. Innerhalb desselben Kontos kann dieses anwendbare Ressourcen-Allow der Rolle Zugriff ohne separates Rollen-Identitäts-Allow gewähren, sofern kein relevantes Deny ihn blockiert.

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt

cat today.txt

aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object --profile report-role --bucket labex-iam04-reference --key reference.txt reference-denied.txt || true

ReportReader erhält Daily orders: 145; alle drei anderen Anfragen erhalten AccessDenied. Die Bucket-Berechtigung deckt weder eine andere Rolle noch ein anderes Präfix oder einen anderen Bucket ab. AWS View stellt dieselben tatsächlichen Rollenleseanfragen.

Schütze private Daten vor einem zusätzlichen Identitäts-Allow

In diesem Schritt beobachtest du, wie eine Rollen-Identitätsberechtigung mit einer Bucket-Berechtigung zusammenwirkt, und schützt dann private Daten mit einem Bucket-Deny. Für diese Anfragen innerhalb desselben Kontos werden anwendbare Allows kombiniert; die zwei Richtlinienquellen werden nicht automatisch als Schnittmenge ausgewertet. Ein explizites Deny in einer der anwendbaren Richtlinienquellen überschreibt ein Allow.

Erweitere vorübergehend den Identitätsleseumfang von ReportReader auf Objekte in diesem eigenen Bucket. Dieser kontrollierte Vergleich umfasst synthetische Daten und gewährt keinen Zugriff auf andere Buckets.

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

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key private/payroll.txt private-before-deny.txt

cat private-before-deny.txt

Erwarte Synthetic payroll: restricted. Das Identitäts-Allow gilt, obwohl das Bucket-Allow nur reports/ abdeckt. Ergänze ein Bucket-Deny, das auf diese Rolle und das private Präfix begrenzt ist, und behalte das Berichts-Allow bei.

cat > bucket-policy.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key private/payroll.txt private-denied.txt || true

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt

cat today.txt

Private gibt jetzt trotz des Identitäts-Allow AccessDenied zurück; der Bericht liefert weiterhin 145. Das Deny benennt ReportReader, deshalb kann der Operator die Referenz weiterhin untersuchen und erhalten. Die Reihenfolge der Anweisungen lässt ein Allow kein passendes Deny überschreiben.

Bestätige, dass ein Identitäts-Deny ein Bucket-Allow überschreibt

In diesem Schritt testest du die umgekehrte Richtung: Ein Rollen-Identitäts-Deny überschreibt ein Bucket-Allow. Behalte die aktuelle Leseberechtigung bei und ergänze ein Deny für Schreibvorgänge auf das Berichtspräfix.

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

aws iam put-role-policy \
  --role-name ReportReader \
  --policy-name ReadAllOwned \
  --policy-document file://role-read.json

Ergänze für einen kontrollierten Vorrangtest vorübergehend ein Bucket-Allow für dieselbe Rolle und dasselbe Schreibpräfix. Wende das Identitäts-Deny zuerst an, damit der Bericht geschützt bleibt.

cat > bucket-write-test.json <<'JSON'
{
  "Version":"2012-10-17",
  "Statement":[
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"},
    {"Effect":"Deny","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:GetObject","Resource":"arn:aws:s3:::labex-iam04-reports/private/*"},
    {"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::123456789012:role/ReportReader"},"Action":"s3:PutObject","Resource":"arn:aws:s3:::labex-iam04-reports/reports/*"}
  ]
}
JSON

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-write-test.json

aws s3api put-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt --body upload.txt || true

Erwarte PutObject AccessDenied, obwohl der Bucket es erlaubt. Das Identitäts-Deny gewinnt. Entferne das temporäre Schreib-Allow sofort, indem du die im vorherigen Schritt gespeicherte Richtlinie mit zwei Anweisungen wiederherstellst.

aws s3api put-bucket-policy \
  --bucket labex-iam04-reports \
  --policy file://bucket-policy.json

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt today.txt

cat today.txt

aws s3api get-object --profile other-role --bucket labex-iam04-reports --key reports/today.txt other-denied.txt || true

Der Bericht muss Daily orders: 145 bleiben und OtherReader bleibt abgewiesen. Die temporäre Schreibberechtigung ist entfernt. AWS View zeigt die Bucket-Richtlinie und die Identitätsrichtlinie der Rolle neben den tatsächlichen Leseergebnissen.

Entferne beide Berechtigungsquellen und räume auf

In diesem Schritt entziehst du beide Richtlinienquellen, bevor du die eigenen Daten löschst. Das Entfernen eines Allow reicht nicht aus, wenn eine andere Richtlinie weiterhin dieselbe Aktion gewährt.

Lösche die Bucket-Richtlinie und wiederhole dann den Berichtslesezugriff. ReadAllOwned gewährt diesen Lesezugriff weiterhin aus der Identitätsrichtlinie der Rolle.

aws s3api delete-bucket-policy --bucket labex-iam04-reports

aws s3api get-object \
  --profile report-role \
  --bucket labex-iam04-reports \
  --key reports/today.txt remaining-grant.txt

cat remaining-grant.txt

Erwarte Daily orders: 145. Lösche jetzt ReadAllOwned und teste erneut, während der Bericht noch existiert.

aws iam delete-role-policy --role-name ReportReader --policy-name ReadAllOwned

aws s3api get-object --profile report-role --bucket labex-iam04-reports --key reports/today.txt revoked.txt || true

aws iam list-role-policies --role-name ReportReader

Erwarte AccessDenied und eine leere Richtlinienliste. Die vorbereiteten Rollen und ihr Aufrufervertrauen bleiben intakt; du entfernst die in dieser Übung erstellten S3-Berechtigungen.

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

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

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

Prüfe KeyCount: 0 in dieser erfolgreichen Antwort, lösche dann den leeren Berichts-Bucket und bestätige die Referenzbytes.

aws s3api delete-bucket --bucket labex-iam04-reports

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

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

cat reference.txt

Nur der Referenz-Bucket mit Platform reference: keep bleibt erhalten. Netzwerkfehler sind kein Nachweis einer Löschung. AWS View zeigt jetzt keine Bucket- oder Rollenberechtigungsrichtlinie und Reports bucket removed. Vorbereitete Identitäten, Referenzen und lokale temporäre Caches werden beim Ende der entbehrlichen Umgebung entfernt.

Zusammenfassung

Du hast mit Principal einer Rolle Zugriff über eine Bucket-Richtlinie gewährt, beobachtet, wie Identitäts- und Ressourcen-Allows kombiniert werden, und den Vorrang expliziter Verweigerungen in beiden Richtungen getestet. Der verbotene Schreibvorgang änderte keine Berichtsbytes. Du hast beide Berechtigungsquellen vor der begrenzten Bereinigung entzogen und vorbereitete Identitäten sowie unbeteiligte Daten erhalten. Untersuche alle anwendbaren Richtlinienquellen, wenn eine Anfrage weiterhin autorisiert oder unerwartet verweigert wird.

Weitere Informationen bietet die AWS-Dokumentation: Auswertung identitäts- und ressourcenbasierter Richtlinien.