Einem Berichtsleser minimale Berechtigungen geben

Einführung

Ein Berichtsleser benötigt den heutigen Bericht, während andere Berichte und Gehaltsdaten privat bleiben sollen. Du erlaubst diesen Lesezugriff, begrenzt seinen Umfang, testest die Berechtigungsgrenze und entziehst ihn vor der Bereinigung.

Nutze dein Wissen über Aufruferidentität und ARNs aus AWS Foundations und über Objektdownloads aus S3. Diese neue VM bereitet die CLI und zwei Identitäten vor: default verwaltet die Übung; reader repräsentiert die Aufgabe. Arbeite in /home/labex/project und vergleiche Anfragen mit AWS View oben.

Bezug zu Zertifizierungen

Lab-Überblick

Gib dem Leser Zugriff auf Berichte

In diesem Schritt schreibst du eine Identitätsrichtlinie und fügst sie an, um das Lesen von Berichten zu erlauben. Eine Identitätsrichtlinie wird an einen Benutzer, eine Gruppe oder eine Rolle angefügt. Sie beschreibt erlaubte oder verweigerte Aktionen; sie enthält keine Zugriffsschlüssel.

In S3 hast du bereits Objektinhalte heruntergeladen. Hier braucht der Berichtsjob denselben Download mit einer eigenen eingeschränkten Identität: Der Operator ändert Berechtigungen, der Leser prüft das Ergebnis. Die Berichtsdaten sind vorbereitet, damit du dich auf die Autorisierung konzentrieren kannst.

AWS Identity and Access Management (IAM) steuert, welche Identität eine Aktion auf einer Ressource ausführen darf. Das Prinzip der minimalen Berechtigungen gewährt nur, was eine Aufgabe benötigt.

Ein AWS-CLI-Profil wählt Zugangsdaten und Einstellungen aus; es gewährt keine Berechtigungen. Hier ist default der Übungsoperator, während reader report-reader auswählt. Bestätige zuerst beide Identitäten. --profile reader wählt die Aufgabe für einen Befehl aus. get-caller-identity meldet die Identität des Aufrufers, ohne Zugangsdaten auszugeben.

cd /home/labex/project

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

Die Standard-ARN endet mit user/iam01-operator. Verwende dieses Operatorprofil für die Richtlinienverwaltung und das Leserprofil zum Testen der Aufgabe. Dieser Lab-Operator ist für die Verwaltung vorbereitet. Eine Berichtsanwendung in der Produktion würde eine eingeschränkte Rolle verwenden, die du später übst.

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

Die Leser-ARN endet mit user/report-reader. Eine ARN, oder Amazon Resource Name, identifiziert eine Ressource. Für ein S3-Objekt enthält sie den Bucket und den vollständigen Objektschlüssel; eine Bucket-ARN allein identifiziert kein Objekt darin.

Der Leser hat zunächst keine Richtlinie. Teste einen Lesezugriff, bevor du etwas erlaubst:

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

Erwarte AccessDenied und keinen Berichtsdownload. || true lässt diesen absichtlich fehlschlagenden Befehl enden, ohne eine eingefügte Befehlsfolge anzuhalten. Lies den Fehler: Ein Verbindungsfehler beweist keine IAM-Verweigerung.

Eine JSON-Richtlinie verwendet drei wesentliche Felder: Effect ist Allow oder Deny; Action benennt eine Dienstoperation; Resource begrenzt, welche ARN diese Operation betreffen darf. s3:GetObject erlaubt das Lesen von Objektbytes. Das * unten erfasst Objektschlüssel im Präfix reports/, einschließlich heute und gestern. Es erfasst weder private/ noch einen anderen Bucket. Version wählt die Richtliniensprache aus und nicht die Berichtsversion.

Das folgende Here-Dokument schreibt die Zeilen zwischen den JSON-Markierungen in report-policy.json. > ersetzt diese lokale Datei und die Markierung in Anführungszeichen verhindert, dass die Shell ihren Inhalt expandiert.

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

Allein das Schreiben einer Datei autorisiert den Leser nicht. put-user-policy fügt eine Inline-Richtlinie an, die direkt auf diesem Benutzer gespeichert wird. --policy-name identifiziert diese Richtlinie; die spätere Verwendung desselben Namens aktualisiert sie. file:// weist die CLI an, das Dokument aus deiner lokalen Datei zu lesen.

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

Eine erfolgreiche Aktualisierung gibt normalerweise nichts aus. Fordere jetzt die Berichte mit den Zugangsdaten des Lesers an. Das letzte Argument ist die lokale Zieldatei.

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

cat today.txt

Erwarte Daily orders: 145. S3-Antwortfelder wie ETag identifizieren das heruntergeladene Objekt; die Datei selbst enthält die Berichtsbytes.

aws s3api get-object \
  --profile reader \
  --bucket labex-iam01-reports \
  --key reports/yesterday.txt yesterday.txt

Auch gestern ist erfolgreich, weil die Richtlinie das gesamte Berichtspräfix abdeckt. Für die Geschäftstätigkeit wird nur der heutige Bericht benötigt, daher verringerst du jetzt diesen Umfang.

Begrenze die Ressource auf den heutigen Bericht

In diesem Schritt ersetzt du eine Präfixberechtigung durch eine einzelne Objekt-ARN und weist nach, dass andere Ressourcen unzugänglich bleiben. Eine implizite Verweigerung bedeutet, dass keine anwendbare Richtlinie die Anfrage erlaubt. Du benötigst kein separates Deny für jedes unbeteiligte Objekt.

Ersetze die lokale Richtlinie. Die einzige Änderung ist Resource: Der genaue Schlüssel reports/today.txt ersetzt reports/*.

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

Aktualisiere dieselbe Inline-Richtlinie auf demselben Leser. Das Bearbeiten der Datei aktualisiert IAM erst, wenn du diesen Befehl sendest.

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

Lies die gespeicherte Richtlinie zurück. --query PolicyDocument wählt das Dokument aus der Antwort aus; es verändert die Berechtigungen nicht.

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

Prüfe, dass Resource mit reports/today.txt endet. Teste dann den Leser erneut.

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

Der benötigte Bericht wird weiterhin heruntergeladen. Jede folgende Anfrage sollte mit AccessDenied fehlschlagen, weil ihre Objekt-ARN nicht der Berechtigung entspricht.

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

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

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

Diese Objekte existieren; der Operator kann sie lesen. Eine Antwort NoSuchKey würde ein fehlendes Objekt diagnostizieren, während diese Berechtigungsfehler die Ressourcengrenze des Lesers zeigen. In AWS View ist heute Readable und die anderen drei Objekte sind Denied. Diese Ansicht stellt tatsächliche Leseanfragen als derselbe Leser.

Unterscheide eine explizite Verweigerung von einem fehlenden Allow

In diesem Schritt schützt du das private Präfix ausdrücklich und testest die Aktionsgrenze. Eine explizite Verweigerung ist eine passende Deny-Anweisung. Sie hat Vorrang vor einem Allow einer anderen anwendbaren Identitätsrichtlinie. Die Reihenfolge der Anweisungen lässt ein Allow sie nicht überschreiben.

Ergänze eine zweite Anweisung und behalte die genaue Leseberechtigung bei. s3:* erfasst alle S3-Aktionen, aber dieses Deny ist auf Objekte unter dem Präfix private/ dieses Buckets begrenzt. Es verweigert nicht den Zugriff auf den heutigen Bericht.

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

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

Das Deny verstärkt die private Grenze. Um seinen Vorrang zu beobachten, füge vorübergehend eine zweite Leseberechtigung für diesen Bucket an. Dies ist ein kontrollierter Test; entferne sie unmittelbar danach.

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

aws iam put-user-policy \
  --user-name report-reader \
  --policy-name TemporaryRead \
  --policy-document file://temporary-read.json

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

Erwarte AccessDenied, obwohl TemporaryRead diesen Schlüssel erlaubt. Die passende explizite Verweigerung gewinnt. Entferne die vorübergehende Berechtigung, um minimale Berechtigungen wiederherzustellen.

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

Eine Leseberechtigung erlaubt keine Schreibvorgänge. upload.txt ist ein bereitgestellter, nicht freigegebener Ersatz. put-object versucht, seine Bytes unter dem heutigen Schlüssel zu speichern, und der Leser muss abgewiesen werden.

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

Erwarte AccessDenied für PutObject; behandle fehlende Dateien oder Dienstfehler nicht als dieses Ergebnis. Lies heute erneut, um zu bestätigen, dass der fehlgeschlagene Schreibvorgang nichts geändert hat.

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

cat today.txt

Er muss weiterhin Daily orders: 145 enthalten. Lies die endgültige Richtlinie zurück und bestätige das enge Allow und das private Deny.

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

Entziehe den Zugriff und entferne eigene Ressourcen

In diesem Schritt entziehst du dem Leser seine Richtlinie und entfernst nur den Berichts-Bucket dieser Übung. IAM-Richtlinienbereinigung und Datenbereinigung sind getrennt: Das Löschen einer Richtlinie löscht keine Objekte und das Löschen von Objekten widerruft keine Zugangsdaten.

Verwende den Standardoperator, um ReportRead zu entfernen. delete-user-policy entfernt eine Inline-Richtlinie anhand ihres Namens.

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

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

Erwarte, dass PolicyNames leer ist. Teste, während der Bericht noch existiert, dass der Leser seinen Zugriff verloren hat.

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

Erwarte AccessDenied. Entferne jetzt als Operator die drei genauen Schlüssel der Übung. Der Referenz-Bucket gehört zur vorbereiteten Plattformreferenz und muss intakt bleiben.

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

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

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

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

Prüfe, dass KeyCount 0 ist und keine Objekte in Contents erscheinen. Diese erfolgreiche authentifizierte Antwort zeigt, dass der eigene Bucket vor der Löschung leer ist.

aws s3api delete-bucket --bucket labex-iam01-reports

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

Nur labex-iam01-reference bleibt übrig. Bestätige seine ursprünglichen Bytes:

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

cat reference.txt

Erwarte Platform reference: keep. AWS View zeigt jetzt No inline policy und Reports bucket removed. Ein Dienstausfall würde als nicht verfügbar angezeigt und nicht als erfolgreiche Bereinigung. Die vorbereiteten, entbehrlichen Identitäten werden beim Ende deiner Lab-Umgebung entfernt; du hast die vom Lernenden erstellten Berechtigungen und die Übungsdaten entfernt und die unbeteiligte Referenz erhalten.

Zusammenfassung

Du hast eine IAM-Identitätsrichtlinie angefügt und überarbeitet, Action und Resource zur Einschränkung einer Berichtsaufgabe verwendet, implizite und explizite Verweigerungen verglichen und bewiesen, dass eine Leseberechtigung keinen Schreibvorgang autorisiert. Du hast die Richtlinie entzogen und nur die eigenen Daten entfernt. Teste bei jeder Zugriffsprüfung sowohl den vorgesehenen Erfolg als auch verbotene Operationen; eine gespeicherte Richtlinie allein beweist nicht, dass eine Anwendung korrekt autorisiert ist.

Weitere Informationen bietet die AWS-Dokumentation: IAM-Richtlinientypen und Berechtigungsanweisungen.