# Identität & Zugriffsmodell > Workload Identity statt statischer Credentials, Rollenmodell und Least Privilege durchsetzen. Track: [Cloud Infrastructure & Platform Engineering](https://opsmith.app/learn/cloud-infra) Kanonische Fassung: https://opsmith.app/learn/cloud-infra/identity-access-model Stand: 2026-07-30 Interaktiver Teil: 3 Checks (nur im Browser) ## Identität ist die erste Plattformgrenze ### 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. > **Merksatz:** Aufbewahrung ist nicht dasselbe wie Art. Ein langlebiger Schlüssel bleibt langlebig, auch in einem guten Secret-Store. Erste Frage im Design: **muss** dieses Geheimnis überhaupt existieren? ### 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. > **Merksatz:** Zeitdruck rechtfertigt **Befristung**, nicht **Breite**. Ein Ticket ist keine Ablaufzeit. ### 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. > **Merksatz:** Eine Zuweisung, die sich nicht in einem Satz begründen lässt, übersteht keine Zugriffsüberprüfung — sie wird nur nicht bemerkt. ### 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. > **Gleich im Check:** In den nächsten drei Entscheidungen wählst du genau diese Achsen selbst — jeweils in einer Situation, in der die bequeme Antwort real verlockend ist. ## Quellen - NIST SP 800-207: Zero Trust Architecture (2020) — https://csrc.nist.gov/pubs/sp/800/207/final - AWS Well-Architected Framework, Security Pillar — SEC02-BP02 Use temporary credentials — https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_identities_unique.html - AWS: Security best practices in IAM — https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html - Google Cloud: Use IAM securely — https://cloud.google.com/iam/docs/using-iam-securely - Google Cloud: Workload Identity Federation — https://cloud.google.com/iam/docs/workload-identity-federation - NIST SP 800-53 Rev. 5 — AC-6 Least Privilege — https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final - ANSI/INCITS 359 Role-Based Access Control (NIST RBAC) — https://csrc.nist.gov/projects/role-based-access-control