Identity Dark Matter ist kein Randphänomen, sondern ein Nebenprodukt aus einem Jahrzehnt SaaS-Einführung, Cloud-Migration und Automatisierung. Wo Systeme schneller hinzukommen, als Identitätsprogramme sie aufnehmen können, wächst der Abstand zwischen dokumentiertem und realem Zugriff.
Klassische IAM-Berichte beschreiben vor allem Konfiguration: Gruppenmitgliedschaften, Rollenzuweisungen, Berechtigungskataloge. Sie beantworten, welcher Zugriff gewährt wurde – nicht aber, ob die Anwendung ihn durchgesetzt hat, ob das Konto noch einen menschlichen Eigentümer besitzt oder ob die Berechtigung im vergangenen Jahr überhaupt genutzt wurde. Governance-Plattformen berichten zudem meist nur über die an sie angebundenen Anwendungen. Wurde eine Anwendung nie integriert, taucht sie im Bericht nicht auf – und Abwesenheit wird mit Konformität verwechselt.
Das Ordnungsprinzip lautet deshalb Überprüfung statt Annahme. Drei Bausteine machen sie möglich: ein genaues Inventar, kartierte Zugriffsbeziehungen und fortlaufende kontextbezogene Analyse. Das Inventar listet die Akteure, die Berechtigungskarte erklärt deren Möglichkeiten, die Beziehungen verbinden beides über Systemgrenzen hinweg und zeigen effektive statt nominelle Rechte.
Die effektiven Rechte fallen häufig breiter aus als beabsichtigt: Ein Nutzer mit bescheidener Anwendungsrolle kann über eine verschachtelte Gruppe, ein gemeinsam genutztes Dienstkonto oder eine Vertrauensbeziehung zwischen Cloud-Konten administrative Fähigkeiten erben. Genau diese verketteten Pfade nutzen Angreifer bei der lateralen Bewegung. Kontinuierliche Discovery zieht Identitätsdaten direkt aus Anwendungen und Infrastruktur und legt lokale Konten, eingebettete Anmeldedaten und Authentifizierungsmethoden offen, die zentrale IAM-Plattformen nie erfasst haben.
Kontext übersetzt Funde in Prioritäten: Ein ruhendes Konto mit Lesezugriff auf ein Testsystem ist Rauschen. Ein nicht ablaufendes Automatisierungs-Zugangsdatum mit Schreibrechten in der Produktion, ohne Eigentümer und ohne Mehrfaktor-Authentifizierung trägt deutlich höheres Risiko.
In Cloud-Umgebungen zerfällt dieser Kontext an den Anbietergrenzen – nicht weil Protokollierung fehlt, sondern weil jede Plattform Identität anders modelliert und Berechtigungen in eigenem Vokabular ausdrückt. Multicloud Identity Visibility bedeutet, diese Vokabulare zu normalisieren, damit eine Identität durch alle berührten Umgebungen verfolgbar bleibt. Ohne Normalisierung entgeht Sicherheitsteams das Bindegewebe: föderiertes Vertrauen, kontoübergreifende Rollenübernahme und geteilte Anmeldedaten. Laterale Bewegung in der Cloud folgt meist diesen IAM-Vertrauensbeziehungen statt Netzwerkpfaden.
Maschinenidentitäten stellen in Cloud-Umgebungen oft die Mehrheit der Principals. Sie entstehen durch Pipelines, Terraform-Läufe und Orchestrierungswerkzeuge statt durch personalgetriebene Ein- und Austrittsprozesse und umgehen damit die für Beschäftigte gebaute Lifecycle-Governance. Besonders kritisch sind Control-Plane-Identitäten: Ein kompromittiertes Automatisierungs-Zugangsdatum kann neuen Zugriff schaffen, Protokollkonfigurationen ändern oder die Kontrollen abschalten, die es entdecken sollen. Auch nicht-menschliche Identitäten brauchen einen benannten Eigentümer, einen festgelegten Zweck, ein Ablauf- oder Rotationsdatum und aktive Überwachung.
Für diese Aufgabe hat sich die Kategorie der Identity Visibility and Intelligence Platforms (IVIP) herausgebildet, weil Governance-, Cloud-Posture- und Detection-Werkzeuge jeweils nur Teile des Problems abdeckten. Die im Quelltext genannte Anbieterliste ist ausdrücklich beispielhaft und nicht nach Leistung geordnet; die Seite wird von Orchid Security veröffentlicht, das selbst in der Liste auftaucht.
IVIP ersetzt bestehende Investitionen nicht, sondern macht sie überprüfbar: IGA erhält Belege, dass Rezertifizierungen realen Zugriff abbilden, PAM erfährt von privilegierten Konten außerhalb des Vaults, das Security Operations Center bekommt Identitätskontext, der die Rekonstruktion von Zeitachsen verkürzt. Zero Trust nach NIST SP 800-207 setzt kontinuierliche Verifizierung voraus – und die verlangt kontinuierliche Beobachtung, etwa den Nachweis, wo Durchsetzung fehlt: Anwendungen mit veralteten Authentifizierungsprotokollen oder Administratorkonten ohne MFA.
Wucherende Berechtigungen sind ein häufiger Befund, weil IAM-Richtlinien beim Ausrollen breit vergeben und danach nie zugeschnitten wurden. Als erste Ziele eignen sich herrenlose Dienstkonten mit Schreibrechten in der Produktion, Administratorkonten ohne MFA, nie rotierte Anmeldedaten und ruhende Konten ausgeschiedener Mitarbeiter. Die Reihenfolge ist wichtig, denn Discovery erzeugt Masse – und Masse ohne Behebungspfad erzeugt Alarmmüdigkeit.