Cloud-Identität ist kein Nebenprodukt der On-Prem-Härtung
Viele mittelständische Unternehmen haben in den letzten Jahren erheblich in die Absicherung ihrer Active-Directory-Umgebung investiert — Tiering-Modell, Kerberoasting-Schutz, NTLM-Abschaltung, LAPS und Protected Users. Diese Maßnahmen sind richtig und wichtig. Was dabei häufig übersehen wird: Entra ID ist längst keine Erweiterung des lokalen AD mehr, sondern eine eigenständige Identitätsplattform mit eigenen Angriffsvektoren, eigenen Schwachstellen und eigenen Backup-Anforderungen.
In der Praxis finden wir in Assessments regelmäßig Umgebungen, in denen das On-Prem-AD nach BSI-Grundschutz gehärtet ist, während der Entra-ID-Tenant mit Standardkonfiguration läuft — ohne Break-Glass-Accounts, ohne Conditional-Access-Baseline, ohne Backup-Konzept. Das ist kein Randproblem: Für Unternehmen, die Microsoft 365, Azure-Dienste oder hybride Infrastrukturen nutzen, ist Entra ID die zentrale Identitätsinstanz, über die sich sämtliche Zugriffsrechte steuern.
APT28 und die neue Realität des Token-Diebstahls
Dass Cloud-Identitäten aktiv angegriffen werden, ist spätestens seit April 2026 keine theoretische Warnung mehr. Anfang April veröffentlichten Microsoft, das britische NCSC und Lumens Black Lotus Labs gemeinsam eine Analyse der Gruppe Forest Blizzard — besser bekannt als APT28 oder Fancy Bear, zugehörig zum russischen Militärgeheimdienst GRU. Die Angreifer kompromittierten über 18.000 Router, vorwiegend ältere MikroTik- und TP-Link-Geräte ohne aktuelle Firmware, und manipulierten deren DNS-Einstellungen. Sämtlicher Datenverkehr der angeschlossenen Netzwerke lief anschließend über von den Angreifern kontrollierte DNS-Server.
Der entscheidende Punkt: Die Angreifer fingen unter anderem OAuth-Tokens ab — also die Authentifizierungsnachweise, die Microsoft 365 und Outlook nach einer erfolgreichen Anmeldung inklusive MFA ausstellen. Neben Tokens wurden auch Passwörter und weitere Credentials erbeutet. Ein gestohlenes OAuth-Token gewährt Zugriff auf das Postfach, SharePoint, Teams und alle verbundenen Dienste, ohne dass der Angreifer Benutzername, Passwort oder den zweiten Faktor kennen muss. Auf dem Höhepunkt im Dezember 2025 waren mehr als 200 Organisationen und 5.000 Endgeräte betroffen — überwiegend Regierungsbehörden, aber auch Unternehmen, die über dieselben verwundbaren Router arbeiteten.
Dieser Angriff verdeutlicht ein grundlegendes Problem: Die klassische Schutzkette aus starkem Passwort und MFA endet am Token. Wer Tokens abfängt, umgeht die gesamte Authentifizierung. Und genau hier setzen die Härtungsmaßnahmen an, die viele Entra-ID-Tenants noch nicht implementiert haben.
Parallel dazu beobachten Sicherheitsforscher seit Ende 2024 einen deutlichen Anstieg von OAuth-Consent-Phishing-Kampagnen. Proofpoint dokumentierte Anfang 2025 eine laufende Kampagne, bei der Angreifer gefälschte Microsoft-OAuth-Anwendungen erstellen — getarnt als bekannte Dienste wie SharePoint, Adobe oder DocuSign. Opfer werden aufgefordert, der Anwendung Berechtigungen zu erteilen, was dem Angreifer dauerhaften Zugriff auf E-Mails, Dateien und Kontakte gewährt. Anders als beim klassischen Credential-Phishing überlebt dieser Zugang einen Passwortwechsel, weil die OAuth-Berechtigung unabhängig vom Benutzerkennwort bestehen bleibt. Unternehmen, die keine Admin-Consent-Workflows konfiguriert haben und die Benutzer-Selbstbedienung für App-Registrierungen nicht einschränken, sind besonders anfällig.
Was passiert, wenn Entra ID kompromittiert wird?
Ein kompromittierter Entra-ID-Tenant ist kein theoretisches Risiko, sondern ein konkretes Geschäftsunterbrechungsszenario. Wenn ein Angreifer Global-Administrator-Rechte erlangt — sei es über Consent-Phishing, Token-Diebstahl oder eine kompromittierte hybride Synchronisation — kontrolliert er die gesamte Identitätsinfrastruktur des Unternehmens.
Konkret bedeutet das: Der Angreifer kann sämtliche Conditional-Access-Policies deaktivieren und sich damit MFA-freien Zugang zu allen Cloud-Ressourcen verschaffen. Er kann neue Administratorkonten anlegen und bestehende sperren, sodass die IT-Abteilung den Zugriff auf den eigenen Tenant verliert. Er kann App-Registrierungen erstellen, die dauerhaften API-Zugriff auf E-Mails, Dateien und Kalender gewähren — Zugriff, der einen Passwortwechsel überlebt. Und er kann den gesamten Tenant in einen Zustand versetzen, in dem die Wiederherstellung Tage statt Stunden dauert, weil keine Backups der vorherigen Konfiguration existieren.
In einem Szenario ohne vorbereitete Break-Glass-Accounts endet dieser Angriff in einem vollständigen Tenant-Lockout. Die IT-Abteilung muss dann über den Microsoft-Support einen langwierigen Wiederherstellungsprozess einleiten — ein Prozess, der je nach Vertragslage und Reaktionszeit des Supports erhebliche Zeit in Anspruch nehmen kann. Während dieser Zeit ist das Unternehmen operativ eingeschränkt: kein E-Mail-Zugang, kein SharePoint, kein Teams, keine Azure-Ressourcen.
Erschwerend kommt hinzu, dass viele Unternehmen ihre Incident-Response-Kommunikation über Microsoft Teams abwickeln. Wenn der Tenant kompromittiert ist, fehlt im kritischsten Moment der Kommunikationskanal für die Krisenbewältigung. Ein separater, vom Tenant unabhängiger Kommunikationsweg gehört daher zu jedem belastbaren Notfallkonzept für Cloud-Identitäten.
Warum AD-Backup nicht gleich Entra-ID-Backup ist
Unternehmen, die ihre On-Prem-AD-Umgebung sorgfältig sichern — über System State Backups der Domain Controller, AD-Recycle-Bin und Forest-Recovery-Runbooks — gehen häufig davon aus, dass Entra ID über Azure AD Connect (heute Entra Connect) automatisch mitgesichert wird. Das ist ein gefährlicher Trugschluss.
Entra Connect synchronisiert Identitäten in eine Richtung: vom On-Prem-AD nach Entra ID. Cloud-only-Objekte — Benutzer ohne On-Prem-Pendant, Gastkonten, App-Registrierungen, Managed Identities, Service Principals und vor allem Conditional-Access-Policies — existieren ausschließlich in der Cloud und werden von keinem lokalen Backup erfasst. Bei einem Entra-ID-Sicherheitsvorfall, bei dem ein Angreifer Conditional-Access-Policies löscht, Rollen manipuliert oder den Tenant übernimmt, hilft das On-Prem-Backup nicht.
Die folgende Tabelle zeigt die wesentlichen Unterschiede zwischen der Wiederherstellung im lokalen AD und in Entra ID.
| Aspekt | Active Directory (On-Prem) | Entra ID (Cloud) |
|---|---|---|
| Backup-Methode | System State, Bare Metal, AD-Snapshot | Microsoft Graph API Export, Drittanbieter-SaaS |
| Recycle Bin Aufbewahrung | 180 Tage (Standard) | 30 Tage, dann unwiderruflich gelöscht |
| Wiederherstellung von Relationen | Gruppenmitgliedschaften bleiben erhalten | Gruppenmitgliedschaften, Rollenzuweisungen und App-Zuordnungen müssen manuell wiederhergestellt werden |
| Conditional-Access-Policies | Nicht relevant (GPO-basiert, im AD gesichert) | Erst seit 2025 Soft-Delete, zuvor nicht wiederherstellbar |
| Forest Recovery | Dokumentierter Prozess, offline möglich | Kein vergleichbares Konzept — Tenant-Recovery ist Microsoft-abhängig |
| Break-Glass-Zugang | DSRM-Kennwort auf dem DC | Cloud-only Break-Glass-Accounts (müssen vorab existieren) |
Microsofts nativer Entra-ID-Backup-Dienst sichert automatisch einmal täglich, bewahrt aber nur fünf Tage Backup-Historie auf. Hart gelöschte Objekte können nicht wiederhergestellt werden. Besonders problematisch: Die Wiederherstellung eines gelöschten Benutzers aus dem Recycle Bin stellt zwar das Objekt selbst wieder her, nicht aber dessen Gruppenmitgliedschaften, Rollenzuweisungen oder App-Zuordnungen. In einer Umgebung mit dutzenden sicherheitsrelevanten Gruppen und rollenbasierten Zugriffskonzepten bedeutet das stundenlange manuelle Nacharbeit — wenn die ursprüngliche Konfiguration überhaupt dokumentiert ist.
Wer umfassende Wiederherstellbarkeit braucht — und das sollte jedes Unternehmen, das produktiv auf Microsoft 365 arbeitet — muss auf Drittanbieter-Lösungen oder eigene Graph-API-Exporte setzen. Die Microsoft Graph API ermöglicht den Export von Benutzern, Gruppen, App-Registrierungen, Service Principals, Conditional-Access-Policies und Rollenzuweisungen. Ein regelmäßiger, automatisierter Export in ein unveränderliches Backup bildet die Grundlage für jeden Wiederherstellungsplan.
Dabei ist zu beachten, dass nicht alle Entra-ID-Objekte über die Graph API vollständig exportierbar sind. Bestimmte Attribute — etwa Schlüsselmaterial von Service Principals oder die internen Konfigurationsdetails von Managed Identities — lassen sich nicht extern sichern. Ein realistischer Backup-Plan muss diese Einschränkungen kennen und dokumentieren, welche Objekte im Ernstfall nicht aus dem Backup, sondern nur durch Neukonfiguration wiederhergestellt werden können.
Conditional Access als Fundament der Entra-ID-Härtung
Conditional Access ist das zentrale Policy-Framework in Entra ID und funktioniert als Zero-Trust-Engine: Jede Anmeldung wird anhand von Bedingungen wie Benutzerrisiko, Geräte-Compliance, Standort und Anmeldekontext bewertet, bevor der Zugriff gewährt wird. Ohne Conditional-Access-Policies verlässt sich der Tenant auf die Standardkonfiguration — und die ist für die meisten Unternehmensszenarien zu permissiv.
Baseline-Policies, die jeder Tenant braucht
Microsoft stellt vorkonfigurierte Templates in mehreren Kategorien bereit — darunter Secure Foundation, Zero Trust, Remote Work, Protect Administrators und Emerging Threats. Die Secure-Foundation-Kategorie sollte als absolutes Minimum gelten. In der Praxis empfehlen wir folgende Kernpolicies als Ausgangspunkt.
Für alle Benutzer sollte MFA für alle Cloud-Anwendungen erzwungen werden, wobei phishing-resistente Methoden wie FIDO2 oder Windows Hello for Business bevorzugt werden. Legacy-Authentifizierungsprotokolle müssen vollständig blockiert werden — Microsoft hat zwar seit 2025 Standardmäßig Legacy-Auth deaktiviert, aber explizite Policies verhindern nachträgliches Aufweichen. Für privilegierte Rollen gelten verschärfte Anforderungen: Administratoren sollten ausschließlich mit Compliant Devices und phishing-resistenter Authentifizierung arbeiten dürfen. Risiko-basierte Policies über Entra ID Protection ergänzen den statischen Schutz um dynamische Erkennung kompromittierter Konten.
Entscheidend ist dabei die korrekte Ausnahme der Break-Glass-Accounts. Conditional-Access-Policies, die ausnahmslos alle Benutzer einschließen, können bei einer Fehlkonfiguration den gesamten Tenant aussperren. Die Break-Glass-Accounts müssen explizit von allen blockierenden Policies ausgenommen sein — und genau das muss regelmäßig verifiziert werden.
App-Registrierungen und Consent-Kontrolle
Ein häufig unterschätzter Angriffsvektor sind OAuth-App-Berechtigungen. Wenn Benutzer eigenständig Drittanbieter-Anwendungen Zugriff auf ihre Microsoft-365-Daten gewähren können, entsteht eine unkontrollierte Angriffsfläche. Jede App-Berechtigung, die ein Benutzer per Consent erteilt, gewährt der Anwendung direkten API-Zugriff — unabhängig von Conditional-Access-Policies und auch über einen Passwortwechsel hinaus.
Die Empfehlung ist eindeutig: Benutzer-Consent für App-Registrierungen sollte auf verifizierte Publisher beschränkt oder vollständig deaktiviert werden. Stattdessen kommt ein Admin-Consent-Workflow zum Einsatz, bei dem IT-Administratoren jede App-Berechtigung vor der Freigabe prüfen. Bestehende App-Berechtigungen sollten regelmäßig auditiert und nicht mehr benötigte Berechtigungen widerrufen werden.
Migration der Legacy-Risk-Policies
Microsoft hat angekündigt, dass die älteren Risiko-Policies aus Entra ID Protection zum 1. Oktober 2026 eingestellt werden. Unternehmen, die noch mit diesen Legacy-Policies arbeiten, müssen die Migration zu Conditional-Access-basierten Risk-Policies rechtzeitig planen. Ebenso endet die Unterstützung für Per-User-MFA und die klassischen SSPR-Policies seit September 2025 schrittweise — die Authentifizierungsmethoden-Policy in Entra ID übernimmt beide Funktionen.
Token-Theft-Protection: Tokens an Geräte binden
Der APT28-Angriff zeigt, warum Passwort und MFA allein nicht ausreichen. Gestohlene Tokens funktionieren auf jedem Gerät — es sei denn, sie sind kryptografisch an das Ursprungsgerät gebunden. Genau das leistet Token Protection in Entra ID.
Bei der Registrierung eines Geräts in Entra ID wird ein Primary Refresh Token (PRT) ausgestellt und kryptografisch an den TPM-Chip des Geräts gebunden. Wird ein PRT gestohlen und auf einem anderen Gerät verwendet, erkennt Entra ID die fehlende Gerätebindung und verweigert die Token-Erneuerung. Token Protection kann über Conditional-Access-Policies als Sitzungskontrolle erzwungen werden.
Ergänzend dazu bewertet Continuous Access Evaluation (CAE) die Sicherheitslage einer Sitzung fortlaufend — nicht nur zum Zeitpunkt der Anmeldung. Wenn sich das Benutzerrisiko ändert, der Netzwerkstandort wechselt oder ein Administrator die Sitzung widerruft, erfolgt die Zugriffssperrung nahezu in Echtzeit, ohne auf den Token-Ablauf warten zu müssen. Universal CAE erweitert diesen Schutz auf Global Secure Access und schützt damit auch Netzwerkzugriffs-Tokens vor Replay-Angriffen.
Beide Mechanismen zusammen — Token Protection und CAE — bilden eine Defense-in-Depth-Strategie, die den Wert gestohlener Tokens drastisch reduziert. Wichtig ist dabei: Token Protection erfordert Entra-ID-registrierte oder -gejointe Geräte und funktioniert derzeit primär mit Windows-Clients. Unternehmen, die Bring-Your-Own-Device-Szenarien oder nicht verwaltete Geräte zulassen, müssen ergänzende Kontrollen implementieren — etwa Conditional-Access-Policies, die Anmeldungen von nicht verwalteten Geräten auf eingeschränkte Sitzungen mit kürzerer Token-Lebensdauer beschränken.
Break-Glass-Accounts: Die Lebensversicherung für den Tenant
Break-Glass-Accounts sind Notfallkonten, die ausschließlich verwendet werden, wenn alle regulären Administratorzugänge versagen — etwa bei einer MFA-Störung, einer fehlkonfigurierten Conditional-Access-Policy oder einem kompromittierten Administratorkonto. Ohne funktionierende Break-Glass-Accounts kann ein einziger Konfigurationsfehler den gesamten Tenant unzugänglich machen.
Konfigurationsanforderungen
Break-Glass-Accounts müssen cloud-only sein und die *.onmicrosoft.com-Domäne verwenden. Sie dürfen nicht an einzelne Personen oder deren Geräte gebunden sein. Die Authentifizierung sollte über FIDO2-Sicherheitsschlüssel erfolgen — nicht über die gleichen Methoden wie reguläre Administratorkonten. Das Passwort sollte mindestens 16 Zeichen lang sein (Microsoft-Minimum), in der Praxis empfehlen wir 32 Zeichen oder mehr. Es wird sicher verwahrt, getrennt von den FIDO2-Schlüsseln.
In Privileged Access Management erhalten Break-Glass-Accounts eine permanente Global-Administrator-Rolle — nicht als berechtigte, sondern als aktive Zuweisung. Sie werden explizit von allen Conditional-Access-Policies ausgenommen. Gleichzeitig muss jede Anmeldung eines Break-Glass-Accounts einen Alarm in der Sicherheitsüberwachung auslösen.
Der wichtigste Punkt wird in der Praxis am häufigsten vernachlässigt: Break-Glass-Accounts müssen regelmäßig getestet werden. Ein Notfallkonto, das nie in einer realistischen Situation verwendet wurde, ist keine Sicherheitsmaßnahme, sondern eine Annahme. Der Test sollte die vollständige Anmeldung einschließen, nicht nur die Existenz des Kontos verifizieren. In der Praxis scheitern Break-Glass-Tests häufig an abgelaufenen FIDO2-Schlüsseln, an Conditional-Access-Policies, die nachträglich ohne Ausnahme erstellt wurden, oder an MFA-Registrierungsproblemen. Jeder fehlgeschlagene Test ist eine gefundene Schwachstelle — jeder nicht durchgeführte Test eine unentdeckte.
Hybrid-Umgebungen: Zwei Welten, ein Angriffsvektor
Die meisten mittelständischen Unternehmen betreiben keine reine Cloud-Umgebung, sondern hybride Infrastrukturen mit Entra Connect. Das schafft eine bidirektionale Angriffsfläche: Ein kompromittiertes On-Prem-AD kann über die Synchronisation Entra ID infizieren, und ein übernommener Entra-ID-Tenant kann Zugriff auf On-Prem-Ressourcen ermöglichen. In der Praxis ist genau diese Hybrid-Brücke einer der am häufigsten übersehenen Angriffspfade, weil On-Prem- und Cloud-Sicherheit oft von unterschiedlichen Teams verantwortet werden.
On-Prem kompromittiert Cloud
Ein Angreifer, der im lokalen AD Domain-Admin-Rechte erlangt, kontrolliert über Entra Connect auch die synchronisierten Cloud-Identitäten. Wenn der Entra-Connect-Server auf Tier 0 nicht angemessen geschützt ist, kann der Angreifer Passwort-Hashes manipulieren, privilegierte Konten synchronisieren oder über Pass-the-Hash-Techniken Zugriff auf Cloud-Ressourcen erlangen. Eine saubere Tier-0-Absicherung des Entra-Connect-Servers ist daher genauso kritisch wie die Absicherung der Domain Controller selbst. Der Entra-Connect-Server sollte auf einer dedizierten, gehärteten PAW laufen, mit eingeschränktem Netzwerkzugriff und separatem Monitoring.
Ein besonders gefährlicher Angriffsvektor ist die Manipulation der Synchronisationsfilter: Ein Angreifer mit Zugriff auf den Entra-Connect-Server kann die Synchronisationsregeln so ändern, dass ein zuvor nicht synchronisiertes privilegiertes Konto in die Cloud repliziert wird — inklusive der zugehörigen Berechtigungen. Dieses Szenario wird von den wenigsten Monitoring-Lösungen erkannt, weil die Synchronisation technisch korrekt funktioniert.
Cloud kompromittiert On-Prem
Umgekehrt kann ein Angreifer mit Global-Administrator-Rechten in Entra ID über Cloud-Authentifizierungsflows auf hybride Ressourcen zugreifen, die an Entra ID angebunden sind. Conditional-Access-Policies, die Cloud-Zugriff absichern, greifen nicht für lokale Authentifizierung. Besonders kritisch wird es, wenn Angreifer über Entra ID Zugriffsrechte auf Azure-Ressourcen erlangen, die über VPN oder ExpressRoute mit dem lokalen Netzwerk verbunden sind — ein Szenario, das in der Praxis selten in der Risikoanalyse berücksichtigt wird.
Die Härtung beider Seiten muss daher als zusammenhängendes Konzept verstanden werden. Ein gehärtetes AD mit einem ungesicherten Entra-ID-Tenant ist genauso verwundbar wie ein gehärteter Tenant mit einem offenen AD. In Assessments empfehlen wir, die Identitätsinfrastruktur als eine logische Einheit zu betrachten: Berechtigungskonzepte, Monitoring-Strategien und Incident-Response-Pläne müssen beide Welten abdecken. Dabei ist auch zu beachten, dass unterschiedliche Teams häufig für On-Prem-AD (klassische IT-Administration) und Entra ID (Cloud-Team oder Microsoft-365-Administration) verantwortlich sind. Diese organisatorische Trennung führt regelmäßig zu blinden Flecken an den Schnittstellen — genau dort, wo Angreifer ansetzen.
Praktische Schritte zur Entra-ID-Resilienz
Die folgenden Maßnahmen bilden einen pragmatischen Startpunkt für Unternehmen, die ihre Entra-ID-Umgebung systematisch härten wollen. Sie sind nach Priorität geordnet — die ersten drei Punkte sollten zeitnah umgesetzt werden, die weiteren im Rahmen eines strukturierten Härtungsprojekts. Wir finden in Assessments regelmäßig, dass selbst Unternehmen mit ausgereifter On-Prem-Sicherheit bei den ersten drei Punkten Nachholbedarf haben — schlicht weil die Zuständigkeit für Entra ID organisatorisch zwischen IT-Administration und Cloud-Team aufgeteilt ist und niemand die Gesamtverantwortung trägt.
| Maßnahme | Priorität | Wirkung |
|---|---|---|
| Zwei Break-Glass-Accounts einrichten und testen | Sofort | Verhindert Tenant-Lockout bei MFA-Ausfall oder Policy-Fehlkonfiguration |
| Conditional-Access-Baseline implementieren | Sofort | MFA-Erzwingung, Legacy-Auth-Blockierung, risiko-basierte Zugriffskontrolle |
| Entra-ID-Backup einrichten (Conditional-Access-Policies, Rollen, App-Registrierungen) | Sofort | Wiederherstellbarkeit bei Konfigurationsverlust oder Angriff |
| Token Protection über Conditional Access aktivieren | Hoch | Schutz vor Token-Replay auf fremden Geräten |
| Continuous Access Evaluation für alle unterstützten Apps aktivieren | Hoch | Echtzeit-Widerruf kompromittierter Sitzungen |
| Entra-Connect-Server als Tier-0-Asset härten | Hoch | Verhindert Lateral Movement von On-Prem in die Cloud |
| Privilegierte Rollen auf PIM mit Just-in-Time-Aktivierung umstellen | Mittel | Reduziert die Angriffsfläche permanenter Administratorrechte |
| Legacy-Risk-Policies zu Conditional Access migrieren | Mittel | Zukunftssicherheit vor dem Stichtag Oktober 2026 |
| Sign-in-Logs und Audit-Logs an SIEM anbinden | Mittel | Erkennung anomaler Anmeldemuster und Policy-Änderungen |
| Regelmäßige Entra-ID-Security-Reviews durchführen | Fortlaufend | Konfigurationsdrift erkennen und korrigieren |
Cloud-Identität verdient denselben Schutz wie das lokale AD
Die Härtung von Entra ID ist kein optionales Zusatzprojekt für Unternehmen, die "auch etwas Cloud machen". Für jedes Unternehmen, das Microsoft 365 produktiv nutzt, ist Entra ID die primäre Identitätsplattform — und damit das primäre Angriffsziel. Der APT28-Angriff auf OAuth-Tokens zeigt, dass staatliche Akteure Cloud-Identitäten systematisch ins Visier nehmen. Die wachsende Zahl von Consent-Phishing-Kampagnen belegt, dass auch kriminelle Gruppen diesen Angriffsvektor industrialisiert haben. Und die eingeschränkten nativen Recovery-Funktionen von Microsoft zeigen, dass Unternehmen die Verantwortung für Backup und Wiederherstellbarkeit selbst übernehmen müssen.
Die gute Nachricht: Die notwendigen Maßnahmen sind technisch umsetzbar und erfordern keine neue Infrastruktur. Break-Glass-Accounts, eine solide Conditional-Access-Baseline, Token-Theft-Protection und ein durchdachtes Backup-Konzept lassen sich in bestehende Umgebungen integrieren — vorausgesetzt, jemand nimmt sich die Zeit, den Ist-Zustand systematisch zu bewerten und die Lücken zu schließen.
Wer seine On-Prem-AD-Umgebung bereits nach dem Tiering-Modell gehärtet hat, bringt die richtige Denkweise mit: Identitätsinfrastruktur als Kronjuwel behandeln, Angriffspfade systematisch eliminieren, Wiederherstellbarkeit vorab sicherstellen. Genau diese Prinzipien müssen jetzt auf Entra ID übertragen werden — mit den Werkzeugen und Mechanismen, die die Cloud-Plattform dafür bereitstellt.
Ein Identity & Access Hardening Assessment deckt Schwachstellen in Ihrer gesamten Identitätsinfrastruktur auf — On-Prem-AD und Entra ID — und liefert einen priorisierten Maßnahmenplan mit konkreten Härtungsschritten. Sprechen Sie mit uns über die Absicherung Ihrer hybriden Identitätsumgebung.