Prüfen Sie Entra ID, bevor Cloud-Drift zum Vorfall wird
EtcSec führt 158 Erkennungen in 9 Microsoft-Entra-ID-Kategorien aus. Die Abdeckung fokussiert sich auf die Kontrollen, die Angreifer in Microsoft 365 und Azure zuerst missbrauchen: Lücken in Conditional Access, fehlende MFA, riskante permanente Admins, gefährliche App-Berechtigungen, Guest-Sprawl und schwache Reaktion auf risky users oder risky sign-ins.
Die Sammlung verwendet ausschließlich Microsoft Graph API mit Anwendungsberechtigungen. Es ist keine delegierte Sitzung erforderlich, kein Endpoint-Agent wird installiert und das Audit verändert den Tenant nicht.
Das Audit prüft, ob alle Benutzer und Admin-Rollen abgedeckt sind, ob MFA erzwungen wird, Legacy Authentication blockiert ist, Device Compliance oder Token Protection genutzt werden und ob zu breite Ausnahmen Lücken hinterlassen.
Der Collector bewertet PIM-Nutzung, permanente Zuweisungen, Break-Glass-Konten, Approval- und Justification-Einstellungen, Aktivierungsdauer und Service Principals mit Admin-Rollen.
Der Katalog deckt tenantweiten Consent, Admin-Consent-Policy, privilegierte Graph-Berechtigungen, Implicit Grant, Multi-Tenant, fehlende Owner, abgelaufene Secrets und zu lange Credentials ab.
Guest Admins, unkontrollierte Einladungen, veraltete Gastkonten, fehlende Guest-MFA, Cross-Tenant-Trust und B2B-Exposition sind Teil des grundlegenden Entra-Reviews.
Die 9 Kategorien passen zu realem Missbrauch von Cloud-Identität
Das Entra-Audit ist kein generischer Cloud-Score. Es ist ein Control Review, das um Conditional Access, Privilegien, App-Consent, externe Governance und risikobasierte Reaktion aufgebaut ist.
Identity und MFA
25 Erkennungen zu Registration Policies, starken Methoden, Passwordless, veralteten Benutzerkonten, SSPR und Password Protection.
Anwendungen und Service Principals
24 Erkennungen zu gefährlichen Graph-Berechtigungen, tenantweiten Consents, App-Ownern, Implicit Grant, Multi-Tenant und Secret-Hygiene.
Conditional Access
20 Erkennungen zur Abdeckung aller Benutzer und Admins, MFA, Legacy-Auth-Block, Device Compliance, risikobasierten Policies und Ausnahmen.
Privileged Access und PIM
18 Erkennungen zu PIM, permanenten Zuweisungen, Notfallkonten, Approval, Justification, MFA bei Aktivierung und Anzahl der Global Admins.
Guests, Gruppen und Konfiguration
39 Erkennungen zu Gästen, Cross-Tenant-Trust, dynamischen Gruppen, role-assignable groups, Tenant-Einstellungen und Log-Export.
Compliance und Risk Protection
18 Erkennungen zu P2-Lizenzen, Access Reviews, Identity-Protection-Posture, Risky Users und Lücken in automatisierter Reaktion.
Warum Teams EtcSec für Entra-ID-Reviews einsetzen
Cloud-Identität verändert sich laufend. Ein nützliches Audit muss nach Policy-Änderungen, App-Onboarding, externer Zusammenarbeit oder Privileged-Access-Reviews erneut ausführbar sein.
Schreibgeschützter Graph-Workflow
Das Audit basiert auf Graph-Anwendungsberechtigungen. Für die Findings sind weder delegierte Benutzersitzungen noch Tenant-Mutationen nötig.
Schnell genug für Change Windows
Die typische Laufzeit liegt je nach Tenant-Größe und Graph-Throttling zwischen 8 und 30 Sekunden. Das macht wiederkehrende Reviews realistisch.
Benannte Findings passend zu Operator-Aufgaben
Owner für Conditional Access, IAM, App-Plattform und Governance sehen die Findings ihres Verantwortungsbereichs anstelle eines vermischten Cloud-Scores.
Ein Collector für Cloud und On-Prem
Derselbe ETC Collector kann Active Directory und Microsoft Entra ID im selben Workflow prüfen. So lassen sich hybride Risiken verfolgen, ohne Tool oder Sammlungsmodell zu wechseln.
Was ein ernstzunehmendes Entra-ID-Audit explizit machen muss
Cloud-Posture wird zu oft auf „haben wir MFA?“ reduziert. Der veröffentlichte Katalog zeigt, warum das nicht reicht: Berechtigungen, Tenant-Einstellungen, Guest-Governance und Reaktion auf Risiko greifen ineinander.
Schreibgeschützte Graph-Sammlung und zentrale Endpunkte
Das Audit liest `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy` sowie relevante Audit- und Identity-Protection-Endpunkte. Findings bleiben dadurch an konkrete Objekte gebunden statt an allgemeine Aussagen zur Cloud-Posture.
Anwendungsberechtigungen machen den Workflow zudem gut automatisierbar. Security-Teams brauchen keine interaktive Admin-Session, um zu prüfen, ob eine Policy noch alle Admins schützt oder ob ein App-Onboarding wieder übermäßige Berechtigungen eingeführt hat.
Die 9 Kategorien und welche Operator-Fragen sie beantworten
| Kategorie | Kontrollen | Was der Operator lernt |
|---|---|---|
| Identity | 25 | Ob MFA, Passwortrichtlinie, SSPR, Enrollment und veraltete Konten modernen Angriffen standhalten. |
| Applications | 24 | Ob App Registrations, Service Principals, Consents und Credentials übermäßigen oder verwaisten Zugriff schaffen. |
| Conditional Access | 20 | Ob die Abdeckung vollständig für alle Benutzer, Admins, Legacy, Risiko und Sessions ist. |
| Privileged Access | 18 | Ob PIM richtig genutzt wird, Break-Glass-Konten existieren und Admin-Rollen dauerhaft vergeben sind. |
| Guest External | 15 | Ob Gäste, Einladungen und Cross-Tenant-Zusammenarbeit begrenzt und auditierbar bleiben. |
| Config | 12 | Ob Tenant-Einstellungen, Diagnostik, Consents und App Registration einen sicheren Betrieb unterstützen. |
| Groups | 12 | Ob dynamische, role-assignable oder von Externen gesteuerte Gruppen Privilegien verbergen. |
| Compliance | 8 | Ob der Tenant für Access Reviews und Identity Protection lizenziert und konfiguriert ist. |
| Risk Protection | 10 | Ob risky users und risky sign-ins erkannt und automatisiert behandelt werden. |
Die Erkennungsfamilien, die am häufigsten Remediation auslösen
Conditional-Access-Lücken
Zu den Schlüsselfindings gehören CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN und CA_POLICY_REPORT_ONLY.
- Zeigt, ob der Tenant auf teilweiser Abdeckung basiert.
- Trennt risikobasierte Kontrollen vom MFA-Baseline-Level.
- Macht Ausnahmen sichtbar, die oft im JSON versteckt bleiben.
Privileged-Access-Drift
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS und PA_SERVICE_PRINCIPAL_ADMIN zeigen, ob Privilegien dauerhaft und schwach geschützt bleiben.
- Hilfreich für IAM, Cloud-Plattform und Governance.
- Trennt Break-Glass-Konto-Design von PIM-Hygiene.
- Hebt Service Principals hervor, da MFA dort nicht ausgleicht.
Anwendungsrisiko und Consent
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY und SP_HIGH_PRIVILEGE legen die häufigsten Eskalations- und Exfiltrationspfade offen.
- Kombiniert App-Registration-Review und Service-Principal-Posture.
- Hebt Credential-Hygiene hervor, nicht nur Berechtigungen.
- Hilft beim Aufräumen nach M&A oder Cloud-Sprawl.
Guest- und Cross-Tenant-Governance
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS und GUEST_NO_ACCESS_REVIEW zeigen, ob externe Zusammenarbeit kontrolliert bleibt.
- Besonders nützlich in Partner- oder M&A-Umgebungen.
- Trennt Invitation Policy von tatsächlich veralteter Gastpopulation.
- Zeigt, wo Gäste bereits in sensiblen Gruppen vorhanden sind.
Identity Protection und Reaktion auf Risiko
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS und RISK_USERS_NOT_REMEDIATED zeigen, ob der Tenant reagiert, wenn Microsoft ein Konto oder Sign-in als riskant markiert.
- Detection ohne Reaktion bedeutet weiterhin aktives Kompromittierungsrisiko.
- Verknüpft Lizenz, Policy-Konfiguration und operative Reaktion.
- Trennt bloße Telemetrie von tatsächlich durchgesetztem Schutz.
Wie Findings an Verantwortungsgrenzen anschließen
Owner von Conditional Access betrachten zuerst die CA-Kategorie, aber ihre Entscheidungen beeinflussen auch den Schutz von Admins, Gästen und Risky Users. Plattform-Owner brauchen die Applications-Findings, weil Consents und Service-Principal-Privilegien häufig außerhalb des zentralen IAM-Prozesses entstehen. Governance konzentriert sich auf Compliance und Risk Protection, weil diese Kategorien zeigen, ob PIM, Identity Protection und Access Reviews tatsächlich genutzt werden.
Eine nützliche Entra-Seite muss daher mehr leisten als nur „wir auditieren Entra ID“. Sie muss zeigen, wie Findings zu konkreten Betriebsmodellen gehören: App-Onboarding, Vergabe von Admin-Rollen, externe Zusammenarbeit, automatisierte Risikoreaktion und hybride Sichtbarkeit.
- IAM und Cloud Engineering verantworten Conditional Access und PIM.
- Applikationsteams verantworten Registrations, Owner und Secret-Rotation.
- Governance verantwortet Access Reviews, Compliance-Nachweise und Risikoreaktion.
- Hybride Programme brauchen einen gemeinsamen Cloud- und On-Prem-Workflow.
Warum der Collector selbst für rein Cloud-zentrierte Reviews wichtig ist
Die Collector-Dokumentation zeigt denselben Workflow für Entra über Graph sowie für Active Directory über LDAP oder SMB. So lassen sich hybride Risiken in einer gemeinsamen Review erklären, statt Cloud- und On-Prem-Probleme getrennt zu behandeln.
EtcSec ergänzt den Collector um Dashboard und Operating Layer. Das Ergebnis ist der Schritt von rohem Cloud-Control-Review hin zu wiederkehrender Remediation und historischem Tracking statt nur zu einem CSV-Export.
Häufige Fragen
Was deckt das Entra-ID-Audit genau ab?
Der veröffentlichte Katalog listet 158 Erkennungen in Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8) und Risk Protection (10).
Benötigt das Audit delegierte Rechte oder eine interaktive Admin-Session?
Nein. Das Review basiert auf Microsoft-Graph-Application-Permissions und erfordert keine interaktive delegierte Sitzung. Das macht den Workflow automatisierungsfähig.
Kann man Entra und Active Directory im selben Workflow prüfen?
Ja. ETC Collector unterstützt Entra ID und Active Directory, damit hybride Teams beide Reviews mit demselben Sammlungsmodell ausführen können.
Warum sind App-Berechtigungen und Guest-Governance Themen erster Ordnung?
Weil viele Cloud-Identity-Incidents mit Consent Phishing, übermäßigen Graph-Berechtigungen, veralteten Service Principals oder zu offenen externen Collaboration-Einstellungen beginnen und nicht nur mit einem fehlenden MFA-Häkchen.
Verwandte Seiten zur Identity Security
Sehen Sie den On-Prem-Katalog, der das Entra-Review in hybriden Identity-Programmen ergänzt.
Prüfen Sie die benannten Erkennungen, die die Cloud- und On-Prem-Seiten speisen.
Verstehen Sie Collection Workflow, Standalone-Modus, Daemon und API-Oberfläche.
Vergleichen Sie die Open-Source-Collection-Engine mit der SaaS-Layer für Dashboards und Nachverfolgung.
Starten Sie Ihr Microsoft Entra ID Audit
Verbinden Sie sich mit read-only Graph Permissions, prüfen Sie Conditional Access, Privilegien, Anwendungen, Gäste und Risiko und machen Sie daraus wiederkehrende Remediation.