Identität & Zugriffsmodell

Identität beginnt mit einer konkreten Zugriffsfrage

Prinzipal — Eine eindeutig benannte menschliche oder technische Identität, deren Anfrage authentifiziert und anschließend gegen Richtlinien autorisiert wird.

Ein belastbares Zugriffsmodell beantwortet nicht nur, wer sich anmeldet. Es verbindet fünf Angaben: Prinzipal, angeforderte Aktion, Zielressource, Kontext und Entscheidung. Der Kontext kann Sitzung, Gerät, Quellumgebung, Zeitpunkt oder Attribute der Ressource enthalten. Erst daraus entsteht eine prüfbare Aussage: Die Deployment-Identität des Zahlungsdienstes darf in Produktion genau eine Queue anlegen, solange sie über den freigegebenen Pipelinepfad kommt. Ein Rollenname allein beweist das nicht.

NIST SP 800-207 trennt Vertrauen von Netzstandort und Geräteeigentum. Für die Plattformpraxis folgt daraus: Eine private Adresse, ein Unternehmensgerät oder ein erfolgreiches Login ist noch keine Berechtigung. Authentifizierung stellt fest, welche Identität und Nachweise vorliegen. Autorisierung wertet für die einzelne Ressource aus, ob die Handlung erlaubt ist. Ein Token kann gültig sein und der Zugriff trotzdem korrekt verweigert werden.

Menschen, Workloads und Notfallidentitäten brauchen getrennte Wege

Mensch

Föderierte Anmeldung, starke Authentisierung, gruppenbasierte Grundrechte und zeitlich begrenzte Erhöhung

Workload

Nicht-interaktiver Bezug kurzlebiger Credentials aus Laufzeit oder Federation; eigene Identität je Berechtigungsbedarf

Deployment

Getrennte Pipeline-Identität mit Änderungsrechten, gebunden an Repository, Branch, Umgebung und Freigabekontext

Notfall

Wenige überwachte Break-Glass-Identitäten mit eigener Alarmierung, geprüftem Zugriff und regelmäßiger Übung

Diese Wege zu vermischen vergrößert Rechte und verwischt Zurechnung. Nutzt eine Anwendung die Deployment-Identität auch zur Laufzeit, erbt sie Änderungsrechte, die sie nach dem Start nicht benötigt. Teilen mehrere Dienste eine Identität, zeigt das Audit-Log den gemeinsamen Namen, aber nicht mehr den verursachenden Dienst. Verwendet ein Administrator sein Dauerkonto für Notfälle, lässt sich Routine kaum von Ausnahme unterscheiden.

Die Trennung richtet sich am Berechtigungsbedarf und Lebenszyklus aus. Zwei identische Replikate dürfen dieselbe technische Identität nutzen, wenn sie dieselbe Aufgabe und Schutzgrenze besitzen. Zwei Komponenten desselben Produkts brauchen getrennte Identitäten, sobald eine nur lesen und die andere schreiben muss. Die Zahl der Identitäten ist kein Selbstzweck; sie soll Unterschiede sichtbar und durchsetzbar machen.

Kurzlebige Credentials begrenzen Zeit, Bindung begrenzt Herkunft

AWS empfiehlt Rollen mit temporären Credentials für Workloads; Azure Managed Identities und Google Workload Identity Federation verfolgen denselben Zweck. Der private Schlüssel eines langlebigen Servicekontos muss dann nicht an Buildsystem, Secret-Store und Laufzeit verteilt werden. Der Gewinn besteht aus weniger kopierbaren Langzeitgeheimnissen und einem automatischen Ablauf. Ein gestohlenes Token bleibt während seiner Gültigkeit nutzbar, weshalb kurze Lebensdauer nur eine Schicht der Kontrolle ist.

Die zweite Schicht ist die Bindung an die richtige Laufzeit. Eine Identität am gemeinsam genutzten Compute-Knoten steht allen Workloads offen, die an dessen Credential-Endpunkt gelangen. Eine workloadnahe Bindung verwendet dagegen einen Dienstnamen, ein Kubernetes-Servicekonto oder eine verwaltete Identität als Subjekt. Plattformteams müssen verhindern, dass Anwendungen fremde Identitäten an ihre Laufzeit hängen dürfen. Wer eine hoch privilegierte Managed Identity zuweisen kann, erhält mittelbar deren Rechte; Microsoft weist auf genau diese Zuweisungsgrenze hin.

Federation ist ein Vertrag über Aussteller, Zielgruppe und Subjekt

Bei Workload Federation vertraut die Cloud einem externen Aussteller, etwa einem anderen Cloudkonto, einem Cluster oder einer CI-Plattform. Der Token-Tausch ist nur dann eng, wenn mindestens drei Merkmale geprüft werden: issuer bezeichnet den Aussteller, audience bindet das Token an den Empfänger, und subject oder unveränderliche Attribute benennen die konkrete Workload. Eine Signatur beweist lediglich, dass der Aussteller das Token erstellt hat; sie beweist nicht, dass jedes von ihm signierte Subjekt dieselbe Cloudrolle erhalten soll.

Mehrmandanten-Aussteller brauchen Bedingungen für Organisation, Repository, Branch oder Umgebung. Eine Freigabe für alle Subjekte eines Pools skaliert gefährlich: Jede später aufgenommene Workload erbt den Zugriff. Google empfiehlt spezifische externe Identitäten oder Attributbedingungen und warnt vor einer Freigabe für den gesamten Pool. Ebenso muss die Attributabbildung Kollisionen verhindern; sonst erscheinen zwei externe Identitäten als derselbe Cloud-Prinzipal und verlieren ihre Zurechenbarkeit im Audit-Log.

Effektive Rechte sind eine Auswertung, keine Rollenliste

Ein Nutzer kann in der Konsole eine passende Rolle sehen und dennoch keinen Zugriff haben. Umgekehrt kann eine unauffällige Gruppenmitgliedschaft über Vererbung weitreichende Rechte liefern. AWS kombiniert je nach Fall Identity- und Resource-Policies, Permissions Boundaries sowie Organisationsrichtlinien; ein explizites Deny hat Vorrang. Azure RBAC summiert anwendbare Rollenzuweisungen, berücksichtigt Deny Assignments und wertet anschließend Bedingungen aus. Google betrachtet Allow-, Deny- und Principal-Access-Boundary-Richtlinien entlang der Ressourcenhierarchie.

Die betriebliche Diagnose braucht ein festes Tupel: Prinzipal, Aktion, Ressource und Kontext. Ohne Zielressource fehlt die Vererbung. Ohne Aktion sagt eine Rolle zu wenig, weil sie viele Berechtigungen bündelt. Ohne Kontext bleiben Bedingungen unsichtbar. Ein Werkzeug für effektive Rechte oder Policy Troubleshooting sollte die anwendbaren Regeln und den entscheidenden Allow- oder Deny-Pfad zeigen. Screenshots einer Rollenseite reichen dafür nicht.

Identity- oder Allow-Policy

Kann eine Aktion gewähren

Resource-Policy

Kann Zugriff direkt am Ziel gewähren oder begrenzen

Boundary oder Organisationsgrenze

Begrenzt den maximal delegierbaren Raum

Explizites Deny

Blockiert die passende Aktion trotz anderer Allows

Bedingung

Macht die Entscheidung von Attributen oder Kontext abhängig

Least Privilege hat drei Achsen

Least Privilege bedeutet mehr als eine kleine Liste von Aktionen. Erstens muss die Funktion passen: lesen, schreiben, konfigurieren oder Rechte vergeben. Zweitens muss der Scope passen: Objekt, Ressourcengruppe, Projekt, Subscription, Konto oder Organisation. Drittens muss die Zeit passen: dauerhaft, berechtigt aber inaktiv oder nur für eine genehmigte Sitzung aktiv. Eine präzise Aktion auf Organisationsebene kann mehr Schaden ermöglichen als eine breitere Datenrolle auf einem einzelnen Testbucket.

Vordefinierte Rollen sind ein sinnvoller Start, weil Anbieter sie pflegen und Dienstabhängigkeiten kennen. Für Produktion wird anschließend beobachtet, welche Aktionen wirklich vorkommen. AWS Access Analyzer kann aus CloudTrail-Aktivität Richtlinienvorschläge erzeugen; Google bietet Rollenempfehlungen und Policy Simulation. Solche Werkzeuge sehen nur die beobachtete Periode. Ein Quartalsjob oder Recovery-Schritt kann fehlen. Deshalb verbindet man Nutzungsdaten mit erwarteten seltenen Abläufen und testet die Kürzung vor dem Rollout.

Delegation braucht eine Obergrenze

Self-Service funktioniert nur, wenn Produktteams bestimmte Zuweisungen selbst vornehmen dürfen. Ohne Grenze könnten sie sich oder ihren Workloads Administratorrechte geben. Permissions Boundaries, Principal Access Boundaries, Organisationsrichtlinien und eingeschränkte Rollenvergaberechte definieren den Raum, innerhalb dessen ein Team Rollen verwenden oder vergeben darf. Die Grenze gewährt selbst keine fachliche Berechtigung; sie begrenzt, was andere Policies höchstens erlauben können.

Der Delegationsvertrag nennt erlaubte Rollenmuster, Prinzipaltypen, Zielscopes und verbotene Eskalationswege. Kritisch sind Rechte, mit denen Identitäten erstellt, Trust Policies geändert, Policies angehängt oder Workloads privilegierte Identitäten zugewiesen werden können. Ein Team kann ohne sichtbaren Administratorrollennamen effektiv Administrator werden, wenn es diese Bausteine kombinieren darf. Tests müssen Eskalationsketten prüfen, nicht nur einzelne Rollenbezeichnungen.

• Kann das Team eine neue Identität mit anderer Trust Policy erstellen?
• Kann es die eigene Permissions Boundary entfernen oder ersetzen?
• Kann es eine fremde Managed Identity an Compute binden?
• Kann es Resource-Policies ändern, die seinen Identity-Scope umgehen?
• Wird jede delegierte Zuweisung mit Auftrag und Owner protokolliert?

Privilegien werden aktiviert, nicht dauerhaft getragen

Für menschliche Administration trennt ein Just-in-Time-Modell die Berechtigung zur Aktivierung vom aktiven Privileg. Eine Person kann für eine Rolle geeignet sein, muss vor Nutzung aber starke Authentisierung, Begründung und gegebenenfalls Genehmigung erfüllen. Die Aktivierung besitzt eine maximale Dauer und endet automatisch. Microsoft Entra PIM und Google Privileged Access Manager dokumentieren solche zeitgebundenen Modelle. Der Kontrollgewinn entsteht durch Ablauf und Nachweis, nicht durch das zusätzliche Formular.

Eine gute Aktivierung ist eng in Scope und Aufgabe. Zwei Stunden globale Administration für das Ändern einer einzelnen Firewallregel bleiben überbreit. Ebenso darf der Genehmiger nicht blind dieselbe Person sein, die den Einsatz ausführt. Für Störungen braucht es einen schnelleren, vorab entworfenen Weg. Break Glass heißt nicht unkontrolliert: Zugriff wird besonders stark alarmiert, Credentials werden geschützt und geprüft, jede Nutzung wird nachbereitet, und der Pfad wird regelmäßig geübt.

Gruppen skalieren nur mit Eigentum und Lebenszyklus

Gruppen reduzieren direkte Einzelbindungen, lösen aber nicht automatisch Governance. Eine Gruppe braucht fachlichen Zweck, Owner, Mitgliederquelle und Reviewfrequenz. Organisationsverteiler sind oft schlechte Zugriffsgruppen: Personen können freiwillig beitreten, Teamnamen ändern sich, und Zusammenarbeit entspricht nicht zwingend demselben Berechtigungsbedarf. Google unterscheidet deshalb Access- und Enforcement-Gruppen von allgemeinen Kollaborations- oder Organisationsgruppen.

Joiner, Mover und Leaver müssen als Datenfluss gedacht werden. Eintritt erzeugt nur die für die Aufgabe vorgesehenen Gruppen. Ein Teamwechsel entfernt alte Mitgliedschaften, bevor neue privilegierte Pfade aktiv werden. Austritt sperrt die föderierte Identität und beendet aktive Sitzungen soweit technisch möglich. Externe Konten brauchen Sponsor und Ablaufdatum. Eine halbjährliche Review kann Fehler entdecken; ein sauberer Identitätslebenszyklus verhindert, dass sie sechs Monate bestehen bleiben.

Änderungen an Rechten haben Laufzeitverhalten

Ein Policy-Commit ist nicht derselbe Zeitpunkt wie seine Wirkung. Rollenbindungen werden verteilt, Tokens enthalten Claims, Dienste cachen Entscheidungen, und bestehende Sitzungen können bis zum Ablauf weiterarbeiten. Microsoft dokumentiert bei bestimmten Änderungen an Gruppen- oder Rollenmitgliedschaften verwalteter Identitäten Verzögerungen durch Token-Caches. Ein Entzug muss mit einem gemessenen Wirksamkeitsfenster geplant werden. Für dringende Sperren können Deaktivierung des Prinzipals, Sitzungswiderruf oder ein explizites Deny nötig sein.

Die Abnahme einer Rechteänderung prüft positive und negative Fälle. Positiv: Die vorgesehene Workload kann die benötigte Aktion ausführen. Negativ: dieselbe Workload kann eine benachbarte Aktion oder Ressource nicht verwenden; ein anderes Subjekt kann die Rolle nicht annehmen; ein Token mit falscher Audience wird abgelehnt. Danach belegt der Audit-Eintrag, welcher Prinzipal über welchen Pfad gehandelt hat. So wird aus einer Policy-Datei ein beobachteter Betriebszustand.

Audit-Evidenz verbindet Entscheidung und Handlung

Für eine Untersuchung reichen Login-Logs nicht. Benötigt werden Token- oder Föderationsereignis, angenommene Rolle, Ressourcenaufruf, Ergebnis und Änderungen der zugrunde liegenden Policies. Gemeinsame Zeitbasis und unveränderliche Prinzipal- sowie Vorgangskennungen erlauben die Korrelation. Anzeigenamen sind schwach: Sie können geändert oder wiederverwendet werden. Bei Federation sollte das Cloud-Audit das externe Subjekt so abbilden, dass ein Lauf im Ursprungssystem wiedergefunden werden kann.

Ein Zugriffsreview nutzt mehrere Sichten: Soll-Zustand aus Rollen- und Gruppencode, effektiver Zustand aus Policy-Analyse, tatsächliche Nutzung aus Auditdaten und Ausnahmen aus dem privilegierten Zugriffssystem. Abweichungen erzeugen eine Aktion mit Owner und Frist. Eine breit definierte, aber unbenutzte Rolle wird entfernt oder verkleinert. Eine häufig genutzte Notfallrolle zeigt möglicherweise einen fehlenden Standardweg. Eine Rolle ohne Owner wird bis zur Klärung begrenzt.

• Welche Identität hat gehandelt?
• Welche Policy und welcher Scope ermöglichten oder blockierten die Aktion?
• War das Privileg dauerhaft oder für eine Sitzung aktiviert?
• Lässt sich der Cloud-Audit-Eintrag zum ursprünglichen Auftrag korrelieren?
• Ist ein entzogener Zugriff nachweislich unwirksam?

Ein Zugriffsmodell braucht Abnahmekriterien

Der Vertrag nennt principalId, owner, Credential-Bezug, Aktionen, resourceScope, Trust-Bedingungen, Dauer und Delegationsgrenze. Für Menschen beschreibt er Grundzugriff, Aktivierung und Notfallpfad. Für Workloads beschreibt er Laufzeitbindung, audience und den erlaubten Ressourcenraum. Jede Gruppe besitzt Zweck, Owner und Mitgliederquelle. Policy- und Trust-Änderungen laufen über Code-Review, während zeitkritische Erhöhungen einen überwachten Ablauf besitzen.

Die technische Abnahme prüft positive und negative Fälle. Der vorgesehene Prinzipal darf die nötige Aktion ausführen; eine benachbarte Aktion, Ressource oder fremde Workload wird abgewiesen. Ein Policy-Troubleshooter erklärt den wirksamen Pfad. Der Audit-Nachweis verbindet Föderation, angenommene Rolle und Ressourcenaufruf. Zuletzt wird gemessen, wann Gewährung und Entzug tatsächlich wirken. Damit wird Least Privilege von einer Absicht zu einem prüfbaren Betriebszustand.

Zur Abnahme gehört außerdem ein kleiner Satz dauerhafter Testfälle. Ein positiver Fall verwendet die freigegebene Kombination aus subject, audience, Aktion und Ressource. Negative Fälle verändern jeweils genau eine Dimension: falscher Branch, fremdes Repository, Nachbarressource, zusätzliche Schreibaktion oder abgelaufene Aktivierung. Das Ergebnis wird mit einer stabilen requestId im Token-Tausch, im Policy-Entscheid und im Ressourcen-Audit gesucht. Für Entzug wird ein neues Token angefordert und der bisher erlaubte Aufruf wiederholt, bis das dokumentierte Wirksamkeitsziel erreicht ist. Für Break Glass prüft eine Übung Alarmierung, maximale Sitzungsdauer und nachträgliche Zuordnung zum Incident. Diese Fälle laufen nach Änderungen an Trust Policy, Rollenmodell, Gruppenquelle oder Token-Aussteller. So erkennt das Team nicht erst im Produktionsvorfall, dass eine Audience-Bedingung verschwunden ist, eine geerbte Rolle den Negativtest aushebelt oder ein Cache den entzogenen Zugriff länger wirksam hält als angenommen.

Vertrag

Prinzipal, Aktion, Ressource, Kontext, Dauer und Owner sind benannt

Durchsetzung

Trust, Allow, Deny, Boundary und Scope ergeben die vorgesehene Entscheidung

Negativtest

Fremdes Subjekt, falsche Audience und benachbarte Aktion werden verweigert

Evidenz

Token-Tausch, Rollennutzung, Ressourcenaufruf und Policy-Änderung sind korrelierbar

Lebenszyklus

Eintritt, Wechsel, Entzug, Ablauf und Notfallzugriff sind geübt