IAM mit zu weit gefassten Berechtigungen

Was ist IAM mit zu weit gefassten Berechtigungen?

Eine IAM-Richtlinie gewährt die Rechte, die darin stehen – nicht die, die ein Rollenname vermuten lässt. Wenn eine Build-Agent-Rolle jede Aktion für jede Ressource erlaubt, sind ihre unscheinbaren Zugangsdaten Administratorzugangsdaten. Sie lesen die Wildcard-Richtlinie der scheinbar wenig wertvollen Zugangsdaten und nutzen iam:PassRole, um einer selbst erstellten und aufgerufenen Funktion eine privilegierte Rolle zuzuweisen. Der Aufrufer besitzt die Administratorberechtigung nie direkt; gerade deshalb entgeht diese Rechteausweitung oft einer Prüfung. Danach ersetzen Sie die Wildcards durch konkrete Aktionen für benannte Ressourcen und weisen der Rolle eine Berechtigungsgrenze zu.

Was Sie lernen in IAM mit zu weit gefassten Berechtigungen

• Eine Wildcard-Richtlinie erlaubt tatsächlich die aufgeführten Rechte; der Name der Rolle schränkt eine weit gefasste Berechtigung nicht ein.
• Eine Rolle an einen Dienst weiterzugeben ist ein häufiger Weg zur Rechteausweitung. Der Aufrufer muss die privilegierte Rolle dabei nicht selbst übernehmen, weshalb der Weg bei Prüfungen leicht übersehen wird.
• Ersetzen Sie Wildcards durch konkrete Aktionen für benannte Ressourcen. Eine reine Ausschlussliste lässt neue Ressourcen standardmäßig zu.
• Eine Berechtigungsgrenze begrenzt die maximalen Rechte einer Rolle. Eine spätere Richtlinienänderung kann ihr darüber hinaus keine Rechte gewähren.

IAM mit zu weit gefassten Berechtigungen — Trainingsschritte

1. Unscheinbare Zugangsdaten

   Bob greift Wyndlar an, eine Frachtvermittlungsplattform, über die jährlich Zahlungen an Spediteure in Höhe von mehreren Hundert Millionen Pfund abgewickelt werden. Er hat Zugangsdaten eines Build-Agenten aus einem Pipeline-Protokoll erbeutet. Ein Build-Agent verpackt Artefakte. Auf dem Papier wirken seine Rechte gering. Bob prüft, was die Zugangsdaten tatsächlich erlauben.

2. Welche Rechte die Rolle hat

   Um die tatsächlichen Rechte einer Rolle zu kennen, muss Bob ihre Richtlinie lesen.

3. Was sonst noch im Konto ist

   Dank der Wildcard kann Bob sämtliche Rollen im Konto auflisten. Er sucht nicht nach weiteren Rechten der Build-Agent-Rolle, sondern nach einer privilegierten Rolle, die er an einen Dienst übergeben kann.

4. Die privilegierte Rolle an eine Funktion übergeben

   Das ist die Rechteausweitung. Bob übernimmt die Administratorrolle nicht selbst. Er erstellt eine Funktion und weist die Plattform an, sie unter der Administratorrolle auszuführen. Die Plattform darf die Rolle übernehmen, Bob nicht – das Ergebnis ist dasselbe.

5. Was die Administratorrolle sehen konnte

   Die Funktion führt Bobs Code mit den Rechten der Administratorrolle aus. Er ruft sie auf. Bob hat die Reichweite eines Administrators, erlangt mit Zugangsdaten, um deren Schutz sich niemand bemüht hätte.

6. Warum der Name keine Rolle spielte

7. Eine unbekannte Funktion

   Bei Wyndlars Plattformprüfung fällt eine über Nacht erstellte Funktion mit der Break-Glass-Rolle auf.

8. Lesen, was die Rolle eigentlich zulässt

   Die Antwort steht nicht in der Funktion, sondern in der Richtlinie der Rolle, die sie erstellt hat.

9. Der Build-Agent

   Vier Rollen, und eine davon ist markiert.

10. Alles, auf allem

    Hier steht es in einer einzigen Richtlinienanweisung.