Identität ist die erste Plattformgrenze
Einführung · 4 Abschnitte · ~9 Min Lesezeit · Stand
Wer ruft an — und womit?
Die Control Plane einer Cloud autorisiert jeden API-Aufruf einzeln: Sie wertet pro Anfrage aus, welcher Prinzipal ruft und ob er genau diese Aktion auf genau dieser Ressource ausführen darf — es gibt kein „einmal angemeldet, dann drin“. Dasselbe Prinzip beschreibt NIST SP 800-207 als Rahmenwerk für Zero-Trust-Zugriffe auf Ressourcen: Authentifizierung und Autorisierung werden dynamisch und vor jedem Zugriff durchgesetzt. In der Cloud-Plattform triffst du es konkret bei jedem einzelnen API-Aufruf. Genau deshalb ist Identität die erste Grenze, die eine Plattform sauber ziehen muss, noch vor Netz und Ressourcen.
Prinzipale sind zwei sehr unterschiedliche Dinge. Menschen können einen zweiten Faktor bedienen, eine Sitzung beenden und eine Erhöhung begründen. Ein Workload — ein Dienst, ein Job, eine Pipeline — kann das alles nicht: Er braucht ein Credential, das ohne menschliches Zutun zustande kommt. Die klassische Antwort darauf war ein langlebiger Schlüssel. Die moderne Antwort ist eine Identität, die die Laufzeitumgebung der Workload zuweist.
- Workload startet in der Laufzeitumgebung
- Umgebung fordert für die zugewiesene Identität ein Token beim Aussteller an
- Kurzlebiges Token, typisch Minuten bis wenige Stunden
- Cloud-API prüft Aussteller, Claims und Rolle bei jedem Aufruf
- SDK holt vor Ablauf automatisch ein neues Token
| Gültigkeit | Schlüssel: bis jemand ihn aktiv widerruft · Token: läuft von selbst ab |
|---|---|
| Bindung | Schlüssel: wer ihn besitzt, ist die Identität · Token: wird nur an diese Workload in ihrer Umgebung ausgeliefert |
| Nach einem Verdachtsfall | Schlüssel: finden, ersetzen, alle Nutzer nachziehen · Token: Vertrauensbedingung ändern, der Rest verfällt |
| Kopierbarkeit | Schlüssel: Datei, Umgebungsvariable, Log, Chat · Token: ebenfalls abgreifbar, aber nur für ein kurzes Fenster |
Kurzlebig allein reicht nicht — es kommt darauf an, woran die Identität hängt. Zwei Antipattern sehen in der Praxis harmlos aus: Erstens die Identität, die am Compute-Knoten statt an der einzelnen Workload klebt. Sie ist zwar kurzlebig, aber alle Dienste auf diesem Knoten greifen in denselben Rechtetopf — die Rolle wächst auf die Vereinigung aller Bedarfe, und der Audit-Trail endet beim Knoten statt beim Verursacher. Zweitens die Wiederverwendung der Build- bzw. Deployment-Identität zur Laufzeit: Sie ist bequem, weil die Rechte schon da sind, aber Build- und Laufzeitrechte haben unterschiedliche Aufgaben und Lebensdauern — die Laufzeit erbt damit die Fähigkeit, Infrastruktur zu verändern.
Läuft die Workload außerhalb der Plattform — eigenes Rechenzentrum, anderer Anbieter, externes CI-System —, gibt es denselben Mechanismus als Federation: Die Cloud vertraut einem externen Aussteller und tauscht dessen signiertes Token gegen ein kurzlebiges Cloud-Token. Damit verschiebt sich die Sicherheitsfrage vom Schlüsselbesitz zur Vertrauensbedingung: Welche Claims — Aussteller, Subject, Umgebung — akzeptiert die Rolle? Zu weit gefasst, und beliebige andere Workloads desselben Ausstellers können dieselbe Rolle annehmen.
Wie viel darf sie? Der Umfang der Rechte
Least Privilege hat zwei Dimensionen, die regelmäßig verwechselt werden: welche Aktionen erlaubt sind und auf welchem Knoten der Hierarchie sie gelten — einzelne Ressource, Ressourcengruppe bzw. Projekt, Konto, Organisation. Rechte vererben sich nach unten. Ein präzise benanntes Recht auf Organisationsebene ist deshalb oft gefährlicher als eine etwas zu breite Rolle auf einer einzelnen Ressourcengruppe.
- Wildcard über Aktionen macht jede spätere Prüfung sinnlos: Man kann nicht mehr erkennen, was die Workload wirklich braucht.
- Wildcard über den Scope ist der leisere Fehler: richtige Aktion, falscher Knoten — sie gilt plötzlich in allen Umgebungen.
- Vordefinierte Anbieter-Rollen sind ein brauchbarer Start, aber für alle Kunden geschnitten und selten passgenau; in Produktion lohnt der Schnitt auf den eigenen Bedarf.
Woher weißt du, welche Rechte eine Workload braucht? Zwei Wege mit unterschiedlichen Voraussetzungen. Der Denial-Eintrag im Audit-Log nennt die konkret verweigerte Aktion samt Zielressource — er funktioniert ab dem ersten Fehlversuch. Die nutzungsbasierte Analyse (was hat diese Identität in den letzten Wochen tatsächlich aufgerufen?) ist der stärkere Weg zum Zurückschneiden, braucht aber Historie: Bei einem Dienst, der noch nie erfolgreich lief, ist sie leer.
Unter Zeitdruck lockt „breit vergeben, später zurückschneiden“. In einer Sandbox ist das ein legitimes Explorationsvorgehen. In Produktion fehlt der Auslöser für die Rücknahme: Sobald das Deployment grün ist, meldet niemand mehr ein Problem, und die breite Rolle wird zur Vorlage für den nächsten Dienst. Der saubere Ausweg ist ein Notfallpfad, der vorher existiert: eine Erhöhung mit Ablaufzeitpunkt, Begründung und Protokoll, deren Rücknahme automatisch passiert.
Wie wird zugewiesen? Rollen, Gruppen, Trennlinien
Rechte direkt an einzelne Prinzipale zu hängen funktioniert eine Weile. Danach wächst die Zahl der Bindungen mit Personen × Ressourcen, und eine Zugriffsüberprüfung wird unehrlich, weil niemand mehr jede einzelne Zuweisung begründen kann. Das Gegenmittel ist eine Zwischenschicht: Rechte hängen an Rollen bzw. Gruppen, Prinzipale werden nur noch Mitglieder. Eintritt, Wechsel und Austritt sind dann genau eine Mitgliedschaftsänderung — das ist auch die Antwort auf Rechte-Ansammlung nach Teamwechseln.
Vor allem wird das Modell dadurch überprüfbar: Eine Review zerfällt in zwei beantwortbare Fragen — ist die Rollendefinition angemessen (wenige, versionierte Objekte) und ist die Mitgliederliste aktuell? Bei Einzelbindungen muss stattdessen jede Zuweisung einzeln bewertet werden.
| Menschlicher Zugriff | über den zentralen Identity-Provider föderiert, Zuweisung per Gruppe, Sitzungen laufen ab, erhöhte Rechte nur auf Anforderung |
|---|---|
| Maschineller Zugriff | eigene Identität je Dienst, keine interaktive Anmeldung, Rechte aus der Rolle des Dienstes, Änderung nur über den Code |
| Gemeinsame Rolle für beide | Anti-Muster: Der Umfang wird zur Vereinigung beider Bedarfe, und der Audit-Trail kann Mensch und Automat nicht mehr auseinanderhalten |
Zwei typische Fehlschnitte: Die Gruppe ist zu grob (prod-zugriff gruppiert nach Umgebung statt nach Aufgabe — wer drin ist, darf alles), oder sie ist zu fein (eine Rolle je Person ist die Einzelbindung mit neuem Namen und einer Indirektion mehr). Praxisanker: Rollen entstehen aus Aufgaben, die sich mehrere Prinzipale teilen.
Zusammenfassung — gleich im Check
- Art des Credentials: an die Workload gebundene, kurzlebige Identität statt langlebigem Schlüssel — die Aufbewahrung ist die zweite Frage, nicht die erste.
- Umfang der Rechte: Aktionen und Scope-Knoten; Bedarf aus dem Denial ableiten; Dringlichkeit über Befristung lösen.
- Struktur der Zuweisung: Rechte an aufgabenbezogene Rollen und Gruppen, Menschen und Maschinen getrennt, damit Modell und Review skalieren.