AWS Permission Boundaries für Einsteiger

AWS Permission Boundaries sind verwirrend. Ich weiß, dass sie verwirrend sind, weil sie mich verwirrt haben und ich ein paar Jahre gebraucht habe, um sie zu durchschauen. Ich weiß auch deshalb, dass sie verwirrend sind, weil Corey Quinn es gesagt hat und darum gebeten hat, dass jemand sie weniger verwirrend macht.

Wahrscheinlich werde ich scheitern, aber versuchen wir es.

Kurz gesagt: Reguläre IAM-Richtlinien erlauben Ihnen Dinge, können Sie aber auch von Dingen abhalten. Permission Boundaries halten Sie nur von Dingen ab. Sie verwenden sie meist dafür, jemandem die Administration einiger IAM-Aspekte zu erlauben, aber nicht so vieler, dass diese Person Privilegien ausweiten kann (für sich selbst oder für andere). Sie sind eine Absicherung. Wenn Sie jemandem die Verwaltung von IAM in einem Konto erlauben und nicht möchten, dass diese Person Privilegien ausweiten kann, benötigen Sie fast immer eine Permission Boundary!

Die offizielle AWS-Dokumentation enthält viele Details, ist aber trotzdem etwas verwirrend. Dieser Beitrag soll Ihnen helfen, die Konzepte und den Grund für ihre Existenz zu verstehen, nicht die Feinheiten ihrer Erstellung (mit einer Ausnahme).

Tun Sie so, als wäre ich ein Fünftklässler und kein Dummkopf, und erklären Sie es noch einmal

Nun gut, wenn Sie darauf bestehen.

Vor IAM Permission Boundaries war es WIRKLICH SCHWIERIG, jemandem die Verwaltung von IAM-Berechtigungen für seine eigenen Ressourcen zu erlauben, ohne ein Sicherheitsproblem zu schaffen, indem etwa einer EC2-Instanz oder … der Person selbst zu viele Berechtigungen zugewiesen wurden. Das Problem trat vor allem dann auf, wenn Sie zulassen wollten, dass jemand IAM-Richtlinien schreibt und diese anschließend zuweist. Es ist das Problem der delegierten Administration. „Jemandem die Administration einiger IAM-bezogener Dinge erlauben, aber nicht jener Dinge.“

Das ist ein sehr verbreitetes Szenario. Entwickler erstellen häufig eine Rolle für eine Instanz, eine Lambda-Funktion oder einen Container-Task in ihrem Anwendungsstack und weisen dieser Rolle dann Berechtigungen zu. Das kann so einfach sein wie einer Instanz das Lesen von Daten aus einem S3-Bucket zu erlauben. Wie sich zeigt, ist das aus Sicherheitssicht schwierig zu handhaben:

• Wenn Sie den Entwickler eigene Richtlinien schreiben lassen, könnte er übermäßige Privilegien vergeben … etwa *.*.
• Wenn Sie den Entwickler Richtlinien zuweisen lassen, könnte er eine bestehende Richtlinie mit zu vielen Berechtigungen anhängen.
• Wenn Sie dem Entwickler erlauben, eine neue Rolle zu erstellen UND eine Richtlinie zuzuweisen … haben Sie dieselben Probleme.

Ja, Sie könnten das alles von der Security oder einem übergeordneten Administrator erledigen lassen, aber das ist ineffizient. Permission Boundaries ermöglichen Ihnen zwei Ebenen von IAM-Administratoren: die übergeordneten mit der Gesamtverantwortung für die Sicherheit und die untergeordneten, die das Tagesgeschäft erledigen.

Eine Permission Boundary ist lediglich eine IAM-Richtlinie, die die maximalen Privilegien auflistet, die eine Person oder eine Ressource haben kann. Sie hängen diese Richtlinie an, und die Entwickler, die die Ressource verwalten, können ihr niemals mehr Berechtigungen geben als in der Boundary zulässig. Sie können dem Entwickler dann sogar erlauben, neue Rollen und Benutzer zu erstellen und ihnen Berechtigungen zuzuweisen, verlangen aber, dass alles, was er erstellt, diese Permission Boundary trägt. Damit kann er niemals etwas erstellen oder ändern und ihm mehr Berechtigungen geben, als Sie möchten.

Ich bin nicht sicher, ob das für einen Fünftklässler war - vielleicht ein Beispiel?

Alice ist die Superadministratorin einer AWS-Organisation. Sie muss Hunderte von Konten überwachen, und jedes Konto hat eigene lokale Administratoren und Entwickler, die die eigentliche Entwicklung von Anwendungen übernehmen.

Bob ist einer dieser lokalen Entwickler. Bob entwickelt eine neue Anwendung, und es ist effizienter, wenn Bob seine eigenen Rollen und Richtlinien erstellt, da er weiß, was seine Anwendung benötigt.

Alice entscheidet, Bob die Verwaltung von IAM für Teile seiner Anwendung zu überlassen. Konkret:

• Bob kann neue IAM-Richtlinien mit den Berechtigungen schreiben und zuweisen, die seine Instanzen und Lambda-Funktionen benötigen.
• Es sind einige andere AWS-Services im Einsatz, die diese Komponenten niemals berühren sollten. Deshalb können Sie sie nicht einfach mit einer Service Control Policy abschalten. Das würde diese Services für die Komponenten unbrauchbar machen, die sie nutzen dürfen.
• Bob darf sich selbst keine neue Richtlinie zuweisen.

Es ist ein klassischer Fall delegierter Administration: Bob darf nur einen Teil von IAM administrieren. Hier würden Sie eine Permission Boundary einsetzen:

• Alice erstellt eine Permission Boundary „A“, die Berechtigungen für die AWS-Services zulässt, mit denen Bobs Instanzen und Lambda-Funktionen kommunizieren dürfen (z. B. S3, SNS, SQS).
• Alice erstellt eine Permission Boundary „B“, die Bob erlaubt, IAM-Rollen und -Richtlinien zu erstellen (und zuzuweisen), sie aber NICHT sich selbst zuzuweisen.
• Alice gibt Bob IAM-Berechtigungen, um neue Rollen und Richtlinien zu erstellen und zuzuweisen, jedoch müssen alle neuen Rollen die Permission Boundary „A“ tragen. Das bedeutet, dass diese Instanzen und Lambda-Funktionen NIEMALS mehr Berechtigungen haben werden als in der Boundary enthalten, wohl aber weniger.
• Alice weist Bob die Permission Boundary „B“ zu, damit er sich selbst keine Berechtigungen zuweisen kann. Nun kann er die Anforderung nicht aufheben, dass er Ressourcen mit „A“ bereitstellen muss.

Ja, es gibt mehrere Wege, dieses Problem anzugehen … aber kurz gesagt: Immer wenn Sie jemandem die Administration eines Teils von IAM in einem Konto erlauben wollen, benötigen Sie wahrscheinlich eine Permission Boundary, sofern diese Person nicht zu viel tun können soll.

Sagen Sie mir noch einmal, warum eine Service Control Policy hier nicht funktioniert

Manchmal funktioniert eine SCP, aber Sie können eine SCP nur nutzen, wenn Sie sich in einer Organization befinden, während eine Permission Boundary in jedem Konto funktioniert. Außerdem eignen sich SCPs sehr gut dafür, etwa einzuschränken, welche API-Aufrufe möglich sind (und damit welche AWS-Services genutzt werden können), sie sind aber nicht wirklich für diese Art von Granularität und Bedingungen gedacht.

Denken Sie an mein obiges Beispiel: Alice müsste die Ressourcenkennungen kennen, um den Zugriff auf Services im Konto zu erlauben, aber nicht von den durch Bob erstellten Ressourcen aus. Es gibt Möglichkeiten, das eventuell zu handhaben (z. B. Ressourcenpfade), aber sie sind nicht einfacher als unser Beispiel mit der Permission Boundary und funktionieren je nach den unterstützten Condition Keys nicht immer.

In meiner Incident-Response-Trainingsumgebung verwende ich eine SCP, um Admin-Benutzer (Teilnehmer) in den Konten daran zu hindern, meinen Zugriff auf Organizations-Ebene und einige andere Dinge zu beeinträchtigen. Das funktioniert aber nur, weil ich ihnen vollen IAM-Zugriff gewähre und sie bereits zu diesen Superadministratoren gehören. Wollte ich ihre Möglichkeit einschränken, Ressourcen mit übermäßigen Berechtigungen zu erstellen, bräuchte ich eine Permission Boundary oder eine SCP, um sie auf die Zuweisung bestimmter vorgefertigter Richtlinien zu beschränken.

Kann ich nicht einfach Deny-Richtlinien verwenden?

Nicht wirklich. Wir haben das versucht, bevor es Permission Boundaries gab, und abgesehen von der Komplexität gab es einfach zu viele Schlupflöcher.

Kann ich noch ein einfaches Beispiel bekommen?

Gerne! Hier ist eines, das wir selbst nutzen.

Einige Anwender lassen uns IAM-Änderungen in ihren Konten vornehmen. Dafür nutzen wir eine kontenübergreifende Rolle. Wenn die Anwender die Rolle bereitstellen, wenden sie eine Permission Boundary an, die es uns nie erlaubt, Berechtigungen für uns selbst zu ändern. Das verhindert eine Privilegienausweitung.

Ich glaube, ich habe es verstanden - aber wie greifen all diese IAM-Richtlinien ineinander?

Sehen Sie sich die AWS-Dokumentation zur Auswertungslogik von Richtlinien an, hier aber meine Kurzfassung:

• Service Control Policies begrenzen, was überhaupt jemand in einem Konto tun darf (z. B. können sie Services ein- und ausschalten).
• IAM-Berechtigungsrichtlinien erlauben Benutzern und Rollen, Dinge in einem Konto zu tun.
• IAM-Ressourcenrichtlinien erlauben Benutzern und Rollen, mit der Ressource zu interagieren, an die die Richtlinie angehängt ist.
• Permission Boundaries legen die maximalen Privilegien fest, die ein Benutzer oder eine Rolle haben kann. Sie erlauben Ihnen nichts, können Sie aber von Dingen abhalten.

Die Richtlinien wirken alle zusammen. Damit Sie etwas tun können, müssen Sie irgendwo im Stack eine entsprechende Berechtigung haben, und es darf Sie keine Deny-Richtlinie irgendwo daran hindern. Ein einziges Deny überschreibt jedes Allow, ganz gleich, wo es steht.

Erinnern Sie mich noch einmal, wann Permission Boundaries einzusetzen sind

Wenn Sie jemandem die Administration eines Teils von IAM in einem Konto erlauben, den Umfang aber weiterhin begrenzen wollen, sollten Sie an eine Permission Boundary denken.

Selbst wenn Sie fortschrittliche IAM-Werkzeuge wie unser neues FireMon Authorization Control einsetzen, möchten Sie möglicherweise dennoch einige Permission Boundaries verwenden, insbesondere in hochsensiblen Konten.

Was ist das eine Beispiel, das Sie ankündigten?

Obwohl Permission Boundaries dazu gedacht sind, Sie an bestimmten Aktionen zu hindern, müssen Sie dennoch sämtliche Allow-Berechtigungen angeben. Mit anderen Worten: Wenn Sie eine Permission Boundary mit einer DENY-Anweisung schreiben, um die eine Aktion zu blockieren, die dieser Benutzer bzw. diese Rolle nicht ausführen soll, benötigen Sie trotzdem eine ALLOW *-Anweisung, sonst ist überhaupt nichts möglich.

Genau dieser Punkt hat mich anfangs verwirrt, denn ich hatte die Beschreibung von Amazon falsch gelesen und dachte, man könne eine Permission Boundary einfach dazu verwenden, Aktionen zu blockieren. Das geht zwar, aber abgesehen von einem Anwendungsfall mit Resource Policies, auf den ich heute nicht eingehen möchte, muss die Permission Boundary auch alles enthalten, was Sie erlauben wollen. Sie können nicht einfach eine Aktion in der Permission Boundary mit DENY belegen und andere Aktionen in der regulären IAM-Berechtigungsrichtlinie mit ALLOW versehen und erwarten, dass das funktioniert. Die Permission Boundary muss ebenfalls die ALLOW-Anweisungen enthalten (und ja, ich schummle und verwende hier gelegentlich ALLOW *).

Ich bin immer noch verwirrt

Schreiben Sie mir eine E-Mail. Im Ernst, diese Dinge sind wirklich verwirrend.