Vom Identitätsmanagement

Identitätsmanagement ist die unsichtbare Verfassung jedes IT-Systems. Es entscheidet, wer handeln kann, wer nur zuschauen darf und wer sich, still und sauber, als jemand anderes ausgeben kann. Jede Organisation hat ein IAM, auch jene, die behauptet, sie habe keins. Dann heisst es bloss anders: Gruppenwildwuchs, geteilte Postfächer, lokale Admin-Passwörter, temporäre Ausnahmen, die seit Jahren nie mehr temporär waren, und ein Audit-Trail, der nur noch das Versagen protokolliert. Per Saldo entsteht nicht Freiheit, sondern Unklarheit. Und Unklarheit ist das Habitat des Angreifers.

Der grössere Kontext ist simpel. Der klassische Netzwerkperimeter ist verdampft. Cloud, SaaS, Remote Work, API-Ökosysteme, Service Accounts, kurzlebige Workloads und föderierte Identitäten haben die Burgmetapher ersetzt. Wer Sicherheit weiterhin über IP-Adressen, VLANs und drinnen vs. draussen definiert, produziert bloss trügerische Wärme. Vertrauen wandert in Tokens, Claims, Sessions, Gerätezustände, Risikosignale. Dort sitzt die tatsächliche Durchsetzung. Dort entscheidet sich, ob ein Fehler eine lokale Anomalie bleibt oder zum Totalverlust eskaliert.

Ich schreibe darüber nicht, weil mir an Begriffspflege gelegen wäre, sondern weil die meisten Sicherheitskatastrophen, die ich in der Praxis sehe, semantisch beginnen. Menschen verwechseln Namen mit Identität, Login mit Sicherheit, Admin mit Effizienz, und sie wundern sich dann über laterale Bewegung, über Datenabfluss, über unklare Verantwortlichkeiten. Das sind keine Schicksalsschläge. Das sind Designfehler.

Identität

Unter Identität verstehe ich im IAM nicht die private Selbstdeutung, sondern eine modellierte Entität: ein digitales Subjekt, das im System als Datensatz existiert, mit Attributen, Zuständen und einem Lebenszyklus. Diese Identität kann eine Person sein, ein Gerät, ein Dienstkonto, ein Workload-Prinzipal, ein API-Client, ein Automations-Job. Nur was als Identität repräsentiert ist, kann verlässlich adressiert, begrenzt, auditiert und beendet werden.

Eine Identität ist damit kein Name, keine E-Mail-Adresse, kein Anzeigename im Verzeichnis. Sie ist ein Bündel von Behauptungen, das ich entweder selbst pflege oder aus Autoritäten ableite: Vertragsstatus, organisatorische Zugehörigkeit, Zuständigkeiten, Sicherheitsfreigaben, Gerätezustand, Schlüsselmaterial, Zertifikate, Risikoindikatoren. Ich behandle Identität als Objekt im Sinne einer Systemarchitektur: Es gibt Erzeugung, Mutation, Sperrung, Reaktivierung, Löschung. Diese Zustandsmaschine ist kein Luxus. Sie ist die Grundlage dafür, dass „Joiner, Mover, Leaver“ nicht als Schlagwort endet, sondern als kontrollierter Prozess beginnt.

Besonders unappetitlich wird es dort, wo Identitäten nicht menschlich sind. Service-Identitäten haben keine Intuition, kein Unrechtsgefühl, keine Müdigkeit. Sie haben Keys. Diese Keys werden kopiert, weitergereicht, in Logs geleakt, in Images gebacken, in Build-Systeme geklebt, in Tickets gepostet. Wer Service-Identitäten wie Nebenfiguren behandelt, bekommt Hauptrollen im Incident. Darum verlange ich, dass nicht nur Personen, sondern auch Dienste, Geräte und Workloads eine saubere Identitätsrepräsentation haben, inklusive Besitzerschaft, Rotationsregime, Ablaufdatum, Deprovisioning und Protokollierung.

Identifikation

Identifikation ist der Schritt, in dem ein Subjekt sagt, wer es sein will. Benutzername, Zertifikats-Subject, Gerätekennung, Service-Principal-Name. Identifikation erzeugt eine Kandidatenzuordnung: Das System weiss, auf welchen Identity-Record es gleich schauen soll. Mehr nicht. Identifikation ist Behauptung, nicht Beweis.

Diese Trennung wirkt akademisch, bis man die Praxis anschaut: E-Mail als Login, Display-Name als User, URL-Parameter als Autor. Jeder dieser Shortcut-Reflexe ist ein Muster für Verwechslung. Verwechslung erzeugt Angriffsfläche. Der Angreifer liebt Systeme, die Namen als Wahrheit behandeln, weil er dann nur noch die Namensschicht kapern muss, nicht den Beweis.

Saubere Identifikation ist darum kein kosmetischer Schritt. Sie verlangt eindeutige, stabile Identifikatoren, die nicht nach Marketinglogik wechseln. Sie verlangt auch, dass man zwischen Identifikator und Attribut trennt: E-Mail ist Attribut, oft veränderlich, manchmal mehrfach vergeben, gelegentlich kompromittiert. Eine interne, nicht wiederverwendete ID ist Identifikator. Diese Differenz ist trocken. Sie spart im Ernstfall Tage, manchmal Wochen.

Authentisierung

Authentisierung ist Beweisführung. Ich belege, dass ich die Identität bin, die ich eben genannt habe. Das kann Wissen sein, Besitz, Inhärenz, oft auch Kontext. In modernen Systemen ist es faktisch immer eine Kombination, weil Single-Factor im Internet die IT-Variante von „Tür offen, aber ich hoffe, niemand merkt es“ ist.

Die NIST Digital Identity Guidelines SP 800-63-41 liefern einen nützlichen Rahmen: Identitätsnachweis, Authenticator-Stärke und Föderation werden getrennt betrachtet, mit einer risikobasierten Einordnung in IAL2, AAL3 und FAL4. Das ist nicht heilig, aber es zwingt zu einer sauberen Frage: Welche Schadensklasse droht, welche Angriffe sind plausibel, welcher Beweis ist verhältnismässig, welche Nutzerpopulation ist realistisch, welche Kompensationskontrollen existieren tatsächlich.

Authentisierung produziert in der Regel eine Session und damit ein neues Objekt: den authentisierten Kontext. Tickets, Assertions, Tokens, Kerberos5, SAML6, OIDC7, mTLS8. Dieser Kontext ist die eigentliche Währung, mit der nachher Zugriffe bezahlt werden. Wer den Unterschied zwischen Authentisierung und Session-Management unterschätzt, bekommt Replay9 in neuer Garderobe: nicht pass-the-hash10, sondern pass-the-cookie11, nicht „Credential Stuffing“12, sondern „Token Theft“13, nicht „Login Kompromittierung“14, sondern „Session Hijack“15. Die Semantik bleibt, die Verpackung ändert.

Darum muss Authentisierung stets auch Bindung heissen: Bindung an Gerät, an Kanal, an Proof-of-Possession16, an kurze Lebensdauer, an Reauth bei Risiko. Und Bindung heisst Protokollierung auf dem richtigen Level: nicht nur „Login ok“, sondern welche Authentisierungsmethode, welche Assurance, welcher Kontext, welche Abweichung vom Normalprofil. Das ist nicht Kontrollwut. Das ist die einzige Grundlage für spätere Zurechenbarkeit.

Autorisierung

Autorisierung ist nicht Beweis, sondern Entscheidung. Nach erfolgreicher Authentisierung stellt sich nicht die Frage „wer bist du“, sondern „was darfst du jetzt, hier, an diesem Objekt, mit dieser Methode, in diesem Zeitfenster“. Ich betone jetzt und hier, weil Berechtigung ohne Kontext bloss eine fromme Hoffnung ist.

Autorisierung lebt von Policies. Sie kann rollenbasiert sein, attributbasiert, beziehungsbasiert, oder eine Mischung. Entscheidend ist nicht das Buzzword, sondern die Präzision der Abgrenzung: Welche Ressourcenklasse, welche Operation, welche Nebenbedingungen, welche Protokollierung, welche Eskalationspfade. Das ist im Kern politische Ökonomie in Codeform. Jede Admin-Rolle, die alles darf, ist ein stilles Budget für Schaden, nur ohne Buchungssatz.

Ich halte eine Unterscheidung für zwingend, weil sie in zu vielen Organisationen kollabiert: Authentisierung sagt, dass eine Identität echt ist; Autorisierung sagt, dass eine Aktion erlaubt ist. Wer diese Ebenen verklebt, bekommt gut authentisierte Katastrophen. Der CEO kann sich hervorragend authentisieren und trotzdem keine Produktionsdatenbank löschen dürfen. Ein Build-Job kann formal authentisch sein und trotzdem nicht in den Secrets-Store schauen dürfen. Genau darum existiert Autorisierung.

Diese Ebene ist auch der Ort, an dem Governance zur Technik wird. Rollen sind nicht Job Titles. Rollen sind Bündel von Fähigkeiten. Attribute sind nicht nice to have. Attribute sind Policy-Inputs. Ohne saubere, gepflegte Semantik wird Autorisierung zur Zufallsvariable. Und Zufall ist keine Sicherheitsstrategie.

Least Privilege

Least Privilege ist kein Moralappell, sondern ein technisches Prinzip, das aus der Realität von Fehlern geboren ist. Saltzer und Schroeder formulierten es als Designprinzip, flankiert von „complete mediation“ und „fail-safe defaults“.17 Ich nehme diese alte Schule gerade deshalb ernst, weil sie im Cloud-Zeitalter erneut brutal wahr wird: Fehlkonfigurationen sind normal, Komplexität ist normal, Zeitdruck ist normal. Der einzige robuste Gegenentwurf ist Minimierung der Schadensfläche, bevor der Fehler passiert.

Least Privilege hat drei Achsen, die sich gegenseitig verstärken: Umfang der Ressourcen, Umfang der Fähigkeiten, Umfang der Zeit. Es genügt nicht, weniger Rechte zu vergeben, wenn die Rechte unbegrenzt gelten, lateral delegierbar sind oder sich unbemerkt durch Gruppenverschachtelung vererben. Es genügt auch nicht, Admin-Rechte auf nur drei Personen zu konzentrieren, wenn diese drei Personen täglich damit arbeiten, weil dann Phishing, Token-Diebstahl oder Browser-Exploit unmittelbar in Totalverlust kippt.

Die saubere Umsetzung heisst nicht nie Admin, sondern Admin als Ausnahmezustand. Just-in-Time und Just-Enough, getrennte Identitäten, strikte Session-Bindung, kurze Token-Laufzeiten, Step-up-Authentisierung, Break-Glass mit Audit. Das klingt nach Aufwand. Es ist Aufwand. Der Aufwand ist der Preis für Zurechenbarkeit, und Zurechenbarkeit ist der Preis für Rechtsstaatlichkeit im IT-Betrieb. Ohne Zurechenbarkeit gibt es nur noch Erzählung und Schuldverteilung.

MAC

Mandatory Access Control18, ist der Punkt, an dem viele Enterprise-Teams nervös werden, weil hier die naive Eigentümer-Logik endet. Unter MAC entscheidet nicht der Owner eines Objekts per ACL19 20, sondern eine zentrale Sicherheitsrichtlinie, typischerweise über Labels. Subjekte und Objekte tragen Sicherheitsattribute, der Zugriff wird durch eine obligatorische Policy gesteuert. Wer MAC als akademische Folklore abtut, verkennt den Zweck: Der Zweck ist nicht Komfort, sondern Durchsetzbarkeit.

Das Trusted Computer System Evaluation Criteria Dossier21 hat MAC und Label-Mechaniken in eine staatliche Evaluationslogik gegossen, inklusive explizitem Bezug auf Bell-LaPadula22 als Vertraulichkeitsmodell. Das ist historisch. Der Mechanismus dahinter bleibt aktuell: Zentralität, Konsistenz, Auditierbarkeit. Auch moderne Policy-Engines, die attributbasiert entscheiden, sind funktional ein MAC-Denken, sofern die Policy nicht von individuellen Besitzern ausgehöhlt werden kann.

MAC hat eine unangenehme Konsequenz, die ich als Vorteil betrachte: Es zwingt zur Vorabentscheidung. Man muss Labels definieren, man muss ihre Semantik festlegen, man muss Ausnahmen begründen, man muss Durchsetzungspunkte sauber identifizieren. Das ist das Gegenteil von wir geben mal Zugriff und schauen später. Später kommt nie.

Bell-LaPadula

Bell-LaPadula ist ein Modell für Vertraulichkeit in Multi-Level-Security-Umgebungen. Es kodiert zwei Regeln, die man sich gut merkt, weil sie so unfreundlich sind: kein Lesen nach oben, kein Schreiben nach unten. Das ist keine Folklore, sondern eine formale Regelmenge zur Verhinderung von Datenabfluss entlang einer Klassifikationshierarchie. Die ursprünglichen Arbeiten von Bell und LaPadula zeigen, wie man Sicherheit als Invariante formuliert, statt als Absichtserklärung.23

Was soll das im IAM? Sehr viel, sofern man versteht, dass IAM Attribute liefert und Autorisierung Attribute auswertet. Ein BLP-artiger Schutz braucht Labels am Subjekt, Labels am Objekt, und eine Policy, die diese Labels in Entscheidungen übersetzt. IAM wird damit zum Lieferanten von Clearance, Kategorien und Need-to-Know24, nicht als Bauchgefühl, sondern als gepflegte, auditierbare Attribute. Der Enforcement-Punkt kann im Kernel sitzen, in einer Datenbank, in einem API-Gateway, in einer Dateiablage, oder im Zusammenspiel mehrerer Kontrollen.

Wichtig ist auch, was BLP nicht leistet: Integrität. Vertraulichkeit ist Schutz gegen unbefugte Offenlegung. Integrität ist Schutz gegen unbefugte oder fehlerhafte Veränderung. Wer beides in einen Topf wirft, baut Policies, die hübsch aussehen und in der Krise versagen. Und wer Vertraulichkeit ruft, aber Daten in Logs kippt, hat kein Modellproblem, sondern ein Disziplinproblem.

Und weitere Sicherheitsmodelle

Biba dreht die Richtung um und denkt Integrität als Schutz vor Kontamination: kein Lesen von tieferer Vertrauensstufe, kein Schreiben in höhere.25 Clark-Wilson verankert Integrität nicht in Labels, sondern in Prozessen: wohlgeformte Transaktionen, Trennung von Pflichten, Audit als Teil der Wahrheitserzeugung.26 Brewer-Nash, die „Chinese Wall“, modelliert Interessenkonflikte dynamisch: Zugriff auf A sperrt den Zugriff auf konkurrierendes B.27 Diese Modelle sind untereinander verschieden. Ihre gemeinsame Eigenschaft ist strenger: Sie erzwingen, dass ich präzise benenne, welches Übel ich verhindere.

Der Gewinn ist nicht, dass man jedes Modell implementiert. Der Gewinn ist, dass man aus ihnen Fragen gewinnt, die ein System aushalten muss. Wie wird verhindert, dass eine niedrigintegritäre Quelle in hochintegritäre Prozesse schreibt. Wie wird verhindert, dass klassifizierte Inhalte über Downstream-Kanäle abfliessen. Wie wird verhindert, dass Rollen sich gegenseitig entgrenzen, weil Delegation ohne Schranke betrieben wird. Wie wird verhindert, dass Owner als Begriff zur Lizenz für Wildwuchs degeneriert.

Ein weiteres, oft unterschätztes Werkzeug ist das Gitterdenken, die Lattice-Idee. Sie steckt implizit in Bell-LaPadula, aber sie reicht weiter: Sicherheitsattribute werden partiell geordnet, Zugriffe werden als Vergleich in dieser Ordnung entschieden. Wer heute attributbasierte Policies schreibt, baut faktisch ein Gitter, nur ohne zuzugeben, dass es eines ist. Das ist gefährlich, weil Gittermodelle präzise über Monotonie und Informationsfluss sprechen können, während ein unreflektiertes ABAC-Konstrukt gerne in Ausnahmen ertrinkt.

Ebenso hilfreich sind Modelle, die weniger von Labels sprechen und mehr von Rechten als übertragbaren Objekten. Harrison, Ruzzo und Ullman haben gezeigt, wie schnell ein Zugriffssystem analytisch entgleitet, sobald Rechte erzeugt und weiterdelegiert werden können.28 Das ist im IAM-Alltag der Normalfall: Gruppenmitgliedschaften, Rollenvererbung, Delegation, Token-Exchange. Ohne formale Gedankenführung wird aus Delegation ein Selbstläufer.

Notabene hat auch das vermeintlich moderne RBAC29 eine Modellgeschichte. Rollen sind nicht per se gut; sie sind gut, wenn sie klein, stabil, nachvollziehbar und strikt vom Organigramm getrennt sind. Das Organigramm ist Politik, Rollen sind technische Fähigkeiten. Vermischt man beides, entsteht ein Berechtigungssystem, das jede Reorganisation als Sicherheitsoperation behandelt und jedes Projekt als Ausnahme legitimiert. Dann ist man wieder beim Nebel.

Ich verwende diese Modelle als Prüfsteine: Kann ich meine Policy als Invariante formulieren. Kann ich erklären, welche Attributänderung welche Zugriffskante schaltet. Kann ich garantieren, dass eine Delegationskette nicht in eine Allmachtrolle kippt. Kann ich Audit so gestalten, dass es mehr ist als ein nachträglicher Roman.

Hier lohnt ein kurzer, expliziter Schnitt zwischen Beobachtung, Modell, Interpretation und Werturteil, weil IAM notorisch zur Ideologie wird, sobald jemand „Zero Trust“30 sagt.

In realen Organisationen werden Identität, Authentisierung und Autorisierung oft vermischt; Rechte akkumulieren über Zeit; Ausnahmen werden selten rückgebaut; Service-Identitäten werden schlechter gepflegt als Personen-Identitäten. Der Effekt ist eine Rechte-Topologie, die niemand mehr vollständig überblickt.

IAM ist ein formales Abbildungssystem. Es bildet Subjekte auf Identitätsobjekte ab, bindet Beweise an Sessions, und evaluiert Policies gegen Ressourcenoperationen. Sicherheitsmodelle wie Bell-LaPadula, Biba oder Clark-Wilson sind formale Heuristiken, um diese Policies als Invarianten, Kontaminationsregeln oder Prozessdisziplin zu formulieren.

Der häufigste Grund für IAM-Versagen ist nicht fehlende Technologie, sondern fehlende Semantik. Wer nicht präzise benennt, was Identität ist, welchen Beweis Authentisierung liefern soll, und welche Entscheidungslogik Autorisierung exekutiert, lässt die Organisation in einem Nebel aus „Zugriff irgendwie“ arbeiten. Dieser Nebel ist bequem, weil er Verantwortung diffundiert.

Diese Bequemlichkeit ist inakzeptabel. Sie externalisiert Risiko auf Betroffene, auf Kundschaft, auf Partner, auf die Öffentlichkeit. Ein IAM, das funktioniert, aber weder „Least Privilege“31 durchsetzt noch MAC-artige Konsistenz erzwingt, ist keine Sicherheitsarchitektur, sondern eine höfliche Einladung an den nächsten Vorfall.

Schlussbemerkung

IAM ist die Stelle, an der abstrakte Begriffe wie Vertrauen, Verantwortung und Zurechenbarkeit in Maschinenlogik übersetzt werden. Wer diesen Übersetzungsvorgang schlampig behandelt, handelt nicht pragmatisch, sondern fahrlässig. Ich akzeptiere, dass Komplexität nicht verschwindet. Ich akzeptiere auch, dass Menschen Fehler machen. Genau deshalb akzeptiere ich kein Identitätsmanagement, das auf Hoffnung basiert. Hoffnung ist kein Kontrollmechanismus. Hoffnung ist bloss ein Narrativ, das man nachher in der Incident-Kommunikation verwendet, wenn die Realität längst entschieden hat.

  1. https://pages.nist.gov/800-63-4/sp800-63.html ↩︎
  2. „Identity Assurance Level (IAL) refers to identity proofing functions.“ Ebd. ↩︎
  3. „Authentication Assurance Level (AAL) refers to authentication functions.“ Ebd. ↩︎
  4. „Federation Assurance Level (FAL) refers to federation functions when the relying party (RP) is connected to a credential service provider (CSP) or an identity provider (IdP) through a federated protocol.“ Ebd. ↩︎
  5. https://de.wikipedia.org/wiki/Kerberos_(Protokoll) ↩︎
  6. https://de.wikipedia.org/wiki/Security_Assertion_Markup_Language ↩︎
  7. https://de.wikipedia.org/wiki/OpenID_Connect ↩︎
  8. https://en.wikipedia.org/wiki/Mutual_authentication#mTLS ↩︎
  9. https://en.wikipedia.org/wiki/Replay_attack ↩︎
  10. https://en.wikipedia.org/wiki/Pass_the_hash ↩︎
  11. https://www.dr-datenschutz.de/pass-the-cookie-angriff-wie-sicher-ist-multi-faktor-authentifizierung/ ↩︎
  12. https://en.wikipedia.org/wiki/Credential_stuffing ↩︎
  13. https://www.triskelelabs.com/understanding-token-theft ↩︎
  14. https://proton.me/de/blog/how-passwords-become-compromised ↩︎
  15. https://de.wikipedia.org/wiki/Session_Hijacking ↩︎
  16. https://csrc.nist.gov/glossary/term/proof_of_possession ↩︎
  17. https://web.mit.edu/saltzer/www/publications/rfc/csr-rfc-060.pdf ↩︎
  18. https://en.wikipedia.org/wiki/Mandatory_access_control ↩︎
  19. https://en.wikipedia.org/wiki/Access-control_list ↩︎
  20. https://csrc.nist.gov/glossary/term/access_control_list ↩︎
  21. https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc-1998/final/docs/early-cs-papers/dod85.pdf ↩︎
  22. https://de.wikipedia.org/wiki/Bell-LaPadula-Sicherheitsmodell ↩︎
  23. https://apps.dtic.mil/sti/citations/AD0770768 ↩︎
  24. https://en.wikipedia.org/wiki/Need_to_know ↩︎
  25. https://seclab.cs.ucdavis.edu/projects/history/papers/biba75.pdf ↩︎
  26. https://www.semanticscholar.org/paper/A-Comparison-of-Commercial-and-Military-Computer-Clark-Wilson/f97356ffef4cab0adc41e57f7c5b8df53ba481db ↩︎
  27. https://www.cs.purdue.edu/homes/ninghui/readings/AccessControl/brewer_nash_89.pdf ↩︎
  28. Harrison, Michael A.; Ruzzo, Walter L.; Ullman, Jeffrey D. (August 1976). „Protection in Operating Systems“. Communications of the ACM. 19 (8): 461–471. CiteSeerX 10.1.1.106.7226. doi:10.1145/360303.360333 ↩︎
  29. https://en.wikipedia.org/wiki/Role-based_access_control ↩︎
  30. https://csrc.nist.gov/glossary/term/zero_trust ↩︎
  31. https://en.wikipedia.org/wiki/Principle_of_least_privilege ↩︎

Primärquellen

NIST, Digital Identity Guidelines SP 800-63-4 (Final). National Institute of Standards and Technology.
Saltzer, Jerome H.; Schroeder, Michael D.: The Protection of Information in Computer Systems. Proceedings of the Symposium on Operating Systems Principles, 1975.
Bell, D. Elliott; LaPadula, Leonard J.: Secure Computer Systems: Mathematical Foundations and Model. MITRE, 1973.
Department of Defense: Trusted Computer System Evaluation Criteria (TCSEC), „Orange Book“, 1985.
Biba, Kenneth J.: Integrity Considerations for Secure Computer Systems. MITRE, 1977.
Clark, David D.; Wilson, David R.: A Comparison of Commercial and Military Computer Security Policies. IEEE Symposium on Security and Privacy, 1987.
Brewer, David F. C.; Nash, Michael J.: The Chinese Wall Security Policy. IEEE Symposium on Security and Privacy, 1989.
Anderson, Ross: Security Engineering. Third Edition. Wiley, 2020.
Bishop, Matt: Computer Security. Addison-Wesley, 2003.

Categories: IT, IT-Security
Tags: , , , , ,
Search: