// HEISE ONLINE — HARDWARE & GADGET
Entra ID: Wer hat hier eigentlich die Schlüssel?
Entra ID birgt Risiken durch versteckte Berechtigungen. Lukas Petzi erklärt, wie Selbstaudits sie aufdecken und welche Prüfstandards helfen.
This article is also available in
English.
It was translated with technical assistance and editorially reviewed before publication.
Microsofts Entra ID ist weltweit das meistgenutzte Produkt für Identitäts- und Zugriffsmanagement. Um die Identitäten gut abzusichern und der Welt kein offenes Scheunentor zu bieten, hat sich die Methode der Selbstaudits bewährt. Lukas Petzi, einer der Titelautoren der neuen iX 11/2026, erklärt im Interview, was in die Bestandsaufnahme gehört und welche Prüfstandards dabei wirklich helfen. Er ist als Consultant für Cybersecurity und Incident Response bei der Corporate Trust GmbH auf die digitale Forensik und die Bearbeitung von IT-Sicherheitsvorfällen spezialisiert.
Was macht Entra ID so anfällig für schwer erkennbare Fehlkonfigurationen und wie können Selbstaudits Abhilfe schaffen?
Entra ID ist kein einfaches Benutzerverzeichnis, sondern ein vernetztes System aus menschlichen und technischen Identitäten, Rollen, Gruppen, Anwendungen, Dienstprinzipalen und Richtlinien. Kritische Risiken entstehen deshalb nicht nur aus offensichtlichen Fehlkonfigurationen oder Überberechtigungen, sondern durch das Zusammenspiel mehrerer unauffälliger Berechtigungen. So kann ein Benutzer oder Dienstprinzipal ohne administrative Verzeichnisrolle eine hochprivilegierte Anwendung kontrollieren und dadurch deren Anmeldeinformationen oder Konfiguration beeinflussen. Selbstaudits machen solche effektiven Berechtigungen, Ausnahmen und Eskalationspfade sichtbar.
Wer bislang noch kein Entra-ID-Selbstaudit durchgeführt hat: Mit welchen drei Fragen sollte die erste Bestandsaufnahme beginnen?
Die erste Frage sollte sein: Wer oder was besitzt privilegierten Zugriff? Dazu zählen Administratoren, privilegierte Gruppen, Anwendungen, Dienstprinzipale, Managed Identities sowie aktive und über PIM aktivierbare Rollen. Darauf folgt: Welche Schutzmechanismen greifen tatsächlich? Zu prüfen sind insbesondere MFA, Conditional Access, Notfallkonten. Und: Gibt es noch veraltete Authentifizierungsverfahren und bestehende Ausnahmen? Dann ist zu klären: Welche indirekten Beziehungen können Kontrolle über den Mandanten ermöglichen? Relevant sind weitreichende Graph-Berechtigungen, Administratorzustimmungen, Eigentümerschaften über Unternehmensanwendungen sowie nicht mehr benötigte, unzureichend geschützte oder unangemessen lange gültige Anmeldeinformationen.
Wie weit kommt man beim Audit mit Microsofts Bordmitteln und wo liegen ihre Grenzen?
Für eine erste Bestandsaufnahme kommt man mit dem Identity Secure Score und Microsoft Secure Score relativ weit. Sie zeigen offensichtliche Schwachstellen und priorisierte Härtungsempfehlungen. Transitive Berechtigungen, hybride Abhängigkeiten und vollständige Angriffspfade werden in den Score-Ansichten nicht systematisch als zusammenhängendes Risikomodell dargestellt. Microsoft weist selbst darauf hin, dass nicht jede Empfehlung für jede Umgebung geeignet ist und Sicherheit gegen Nutzbarkeit und Betriebsanforderungen abgewogen werden muss.
Welche Standards helfen besonders gut bei der Aufgabe?