Aufbau eines IAM-Richtliniendokuments

In AWS werden Berechtigungen durch Policies ausgedrückt: JSON-Dokumente, die den Zugriff auf Aktionen für Ressourcen erlauben oder verweigern. Eine Policy sicher lesen zu können, ist eine zentrale SCS-C02-Fähigkeit, da es bei fast jeder Zugriffsfrage darauf hinausläuft, was eine Policy erlaubt, verweigert oder nicht abdeckt. In dieser Lektion wird die Struktur Schritt für Schritt analysiert.

Eine Policy enthält ein Feld Version (verwenden Sie "2012-10-17") und ein Element Statement, das aus einem einzelnen Statement oder einem Array von Statements besteht. Jedes Statement ist eine unabhängige Regel. AWS wertet jedes Statement aus. Daher kann ein einzelnes Dokument bestimmte Aktionen erlauben und andere ausdrücklich verweigern.

Jedes Statement hat als Effect entweder Allow oder Deny. AWS verweigert standardmäßig: Wenn kein passendes Allow vorhanden ist, wird eine Anfrage abgelehnt. Ein passendes Deny hat immer Vorrang vor einem Allow. Prüfen Sie beim Bewerten des Zugriffs zuerst den Effect jedes Statements.

Das Element Action listet die API-Operationen auf, für die das Statement gilt. Sie werden im Format service:operation angegeben, zum Beispiel s3:GetObject. Wildcards sind zulässig, etwa s3:* oder s3:Get*. Das Gegenstück NotAction gilt für jede Aktion außer den aufgeführten Aktionen und kann leicht falsch verwendet werden. Deshalb wird es in der Prüfung besonders sorgfältig behandelt.

Das Element Resource gibt an, für welche Ressourcen die Aktionen gelten, und verwendet dazu ARNs (Amazon Resource Names). Dies kann beispielsweise ein bestimmter Bucket und seine Objekte sein. Der Wert "*" steht für alle Ressourcen. NotResource trifft auf alles außer den aufgeführten ARNs zu. Eine möglichst genaue Eingrenzung der Ressourcen ist ein zentraler Bestandteil des Prinzips der geringsten Rechte.

Diese Identity-Policy erlaubt ausschließlich das Lesen von Objekten aus einem Bucket. Achten Sie auf die Aktion, den spezifischen ARN auf Objektebene und den ausdrücklichen Effect Allow.

Ein optionaler Condition-Block schränkt mithilfe von Kontextschlüsseln und Operatoren ein, wann ein Statement gilt. Sie können beispielsweise den Zugriff nur erlauben, wenn die Anfrage TLS verwendet (aws:SecureTransport) oder von einer bekannten IP-Adresse stammt. Mit Conditions lässt sich zusätzlich zu Aktion und Ressource eine detaillierte, kontextabhängige Zugriffskontrolle umsetzen.

Identity-basierte Policies enthalten kein Element Principal, da sie bereits an einen Principal angehängt sind. Ressourcenbasierte Policies, etwa eine S3-Bucket-Policy, enthalten Principal, um festzulegen, für wen die Regel gilt. Ob eine Policy einen Principal enthält, verrät Ihnen, welchen Policy-Typ Sie gerade lesen.

Wildcards wie "Action": "*" und "Resource": "*" gewähren zusammen vollständigen administrativen Zugriff. In Prüfungen wird häufig eine übermäßig großzügige Policy gezeigt, die Sie einschränken sollen. Ersetzen Sie dazu die Wildcards durch konkrete Aktionen und ARNs und wenden Sie das Prinzip der geringsten Rechte an.

Ein ARN hat die Form arn:partition:service:region:account:resource. Bei einigen Services fehlen Region oder Konto; bei S3 fehlen für den Bucket-Teil beide Angaben. Wenn Sie ARNs genau lesen, können Sie erkennen, ob eine Policy auf eine einzelne Ressource, ein einzelnes Konto oder auf alles abzielt. Das wirkt sich unmittelbar auf den gewährten Zugriff aus.

Gehen Sie bei der Analyse jeder Policy folgendermaßen vor: Prüfen Sie den Effect, lesen Sie die Action (achten Sie auf NotAction und Wildcards), grenzen Sie die Resource ein (achten Sie auf "*") und prüfen Sie alle Condition-Blöcke. Denken Sie daran: Ein ausdrückliches Deny schlägt ein Allow, und standardmäßig wird verweigert. Mit etwas Übung können Sie die tatsächliche Reichweite einer Policy in wenigen Sekunden beurteilen – genau das verlangt die Prüfung.

Testen Sie Ihre Fähigkeit, Policies zu lesen.

Eine IAM-Policy ist ein JSON-Dokument mit Version und einem Statement-Array. Jedes Statement enthält einen Effect (Allow/Deny), eine Action (oder NotAction), eine über ARNs angegebene Resource (oder NotResource) und optional eine Condition. Ressourcenbasierte Policies enthalten zusätzlich einen Principal. Standardmäßig wird verweigert, ein ausdrückliches Deny hat immer Vorrang, und Wildcards weisen auf zu weitreichende Berechtigungen hin, die eingeschränkt werden sollten.