Warum Identitäten das neue Perimeter sind
Die Art und Weise, wie wir IT-Sicherheit betrachten, hat sich radikal verändert. Früher galt das Netzwerk-Perimeter als Hauptverteidigungslinie: Eine dicke Firewall trennte vertrauenswürdige Systeme von der Außenwelt. Doch mit hybriden und Cloud-basierten IT-Infrastrukturen hat sich dieses Modell überholt. Identitäten sind heute der neue Perimeter – sie sind der Dreh- und Angelpunkt der Unternehmenssicherheit.
Aber was bedeutet das konkret? Stell dir vor, du würdest deine Haustür unverschlossen lassen, während du in einem Viertel voller Verbrechenund Diebstähle lebst. Genau das passiert, wenn Identitäten nicht ausreichend geschützt sind. Sie sind der Schlüssel zu sensiblen Daten und Anwendungen. Gerät dieser Schlüssel in die falschen Hände, drohen massive Sicherheitsvorfälle.
Welche Identitäten gibt es heute?
Neben Benutzern zählen zu den Identitäten auch:
- Geräte (Windows, macOS, mobile Endgeräte)
- Service Principals (für automatisierte Workloads)
- Applikationen (z.B. SaaS-Dienste, die mit Unternehmensdaten arbeiten)
Deshalb müssen Unternehmen umdenken: Identity & Access Management (IAM) ist die neue erste Verteidigungslinie gegen Cyberangriffe. Und genau hier setzt das Persona-based Conditional Access Framework an.
Conditional Access als “Identitäts-Firewall”
In (hybriden) Cloud-Infrastrukturen muss sich die IT-Sicherheit über traditionelle Netzwerkgrenzen hinaus erstrecken und ein verstärktes Augenmerk auf die Identitäten legen. Conditional Access-Richtlinien fungieren als eine Art „Identitäts-Firewall“ und nutzen verschiedene Signale, um den Zugriff für alle Arten von Identitäten zu steuern. Sie bündeln diese Signale, um fundierte Entscheidungen über den Ressourcenzugriff zu treffen und fungieren somit als Identitäts-Firewall oder -Perimeter für Unternehmen
Zu den Signalen, die von Conditional Access-Richtlinien ausgewertet werden können, gehören:
- Benutzer- oder Gruppenmitgliedschaften: Richtlinien können auf bestimmte Benutzer oder Gruppen (Personas) zugeschnitten werden, um beispielsweise stärkere phishing-resistente MFA-Methoden erforderlich zu machen.
- IP-Adressinformationen: Während des Anmeldeprozesses kann der Zugriff aus bestimmten Regionen vollständig blockiert werden. Dieses sogenannte Geofencing ist eine einfache Methode, um grundlegende Bedrohungen für Identitäten zu reduzieren, die häufig aus spezifischen Regionen oder Ländern stammen.
- Geräteinformationen: Es kann festgestellt werden, ob eine Anmeldung von einem unternehmensverwalteten Gerät (compliant device) oder einem privaten Gerät erfolgen darf. Dies ermöglicht eine Einschränkung des Datenzugriffs von externen (nicht verwalteten) Geräten.
- Anwendungsinformationen: Je nach Anwendung können stärkere Sicherheitsmaßnahmen gefordert werden, beispielsweise um bestimmte SharePoint-Seiten vor Datenverlust zu schützen und den Zugriff nur mit Unternehmensgeräten zu erlauben.
Durch die Auswertung dieser Signale kann sichergestellt werden, dass nur autorisierte Identitäten unter definierten Bedingungen auf Ressourcen zugreifen können.
Einfach ausgedrückt, sind Conditional Access-Richtlinien “Wenn-Dann”-Anweisungen zur Abbildung des Zero-Trust-Prinzips: Wenn eine Identität auf eine Ressource zugreifen möchte, dann muss diese bestimmte Bedingungen erfüllen. Beispielsweise kann festgelegt werden, dass ein Administrator, der auf das Azure-Portal zugreifen möchte, sich zunächst für die Multi-Faktor-Authentifizierung (MFA) registrieren muss, bevor ihm der Zugriff gewährt wird. Um die Registrierung von MFA durchzuführen als auch der Zugriff auf das Azure-Portal zu ermögliche, sollte der Zugriff von einem konformen Unternehmensgerät durchgeführt werden (device compliance).
https://learn.microsoft.com/de-de/entra/identity/conditional-access/plan-conditional-access
Das Persona-based Conditional Access Framework
Was ist das Persona Framework?
Das Persona-based Conditional Access Framework wurde maßgeblich von Claus Jespersen (Principal Consultant ID & Security, Microsoft) entwickelt und ist im Azure Architect Center dokumentiert. Es bietet einen strukturierten Ansatz zur Implementierung von Conditional Access Richtlinien basierend auf Personas und deren Zugriffsanforderungen.
Vorteile des Frameworks:
✔ Klare Differenzierung zwischen Benutzergruppen
✔ Skalierbarkeit für wachsende Unternehmen
✔ Strukturierte Implementierung für unterschiedliche Zugriffsszenarien
Welche Personas gibt es?
Das Framework unterteilt Benutzer in verschiedene Persona-Gruppen:
| Persona | Beschreibung |
|---|---|
| Global | Standardrichtlinien für alle Benutzer |
| Admins | Administratoren mit erweiterten Rechten |
| Developers | Entwickler mit Zugriff auf DevOps und CI/CD |
| Internals | Standard-Mitarbeiter mit Unternehmenszugriff |
| Externals | Externe Berater mit spezifischem Zugriff |
| Guests | Gastbenutzer im Mandanten |
| GuestAdmins | Gäste mit Admin-Rollen |
| Microsoft365ServiceAccounts | Dienstkonten für Microsoft 365 |
| AzureServiceAccounts | Dienstkonten für Azure-Dienste |
| CorpServiceAccounts | On-Premises-Dienstkonten mit Cloud-Zugriff |
| WorkloadIdentities | Maschinenidentitäten (Service Principals) |
Dieses Persona-Konzept sorgt für eine klare Trennung der Zugriffsrichtlinien und ist einfach um weitere Personas erweiterbar.
Die Namenskonvention für Conditional Access Richtlinien
Das Framework nutzt eine standardisierte Namenskonvention, um Richtlinien übersichtlich zu gestalten:
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
Beispiel:
CA0101-Admins-BaseProtection-AllApps-AnyPlatform-MFA
✅ Diese Richtlinie stellt sicher, dass die Persona Admins sich immer mit MFA anmelden müssen.
Bedeutung der Namenskomponenten:
| Namenskomponente | Beschreibung |
|---|---|
| CA Number | Identifiziert den Richtlinientyp (Persona-Nummernkreis) |
| Persona | Definiert die Benutzergruppe (Admins, Internals, Externals, etc.) |
| Policy Type | Basisschutz, Identitätsschutz, Datenzugriff, etc. |
| App | Gilt die Regel für alle Apps oder nur für bestimmte? |
| Platform | Windows, macOS, iOS, Android? |
| Grant Control | Welche Sicherheitsmaßnahme wird durchgesetzt? (MFA, Compliant Device, etc.) |
Diese Konvention sorgt für eine Dokumentation und eine einfache Verwaltung der Richtlinien.
Personas
| Persona (Entra ID Gruppe) | CA Richtlinien Prefixe (CANumber) |
| CA-Persona-Global | CA0000-CA0999 |
| CA-Persona-Admins | CA0100-CA0199 |
| CA-Persona-Internals | CA0200-CA0299 |
| CA-Persona-Externals | CA0300-CA0399 |
| CA-Persona-GuestUsers | CA0400-CA0499 |
| CA-Persona-GuestAdmins | CA0500-CA0599 |
| CA-Persona-M365ServiceAccounts | CA0600-CA0699 |
| CA-Persona-AzureServiceAccounts | CA0700-CA0799 |
| CA-Persona-CorpServiceAccounts | CA0800-CA0899 |
| CA-Persona-WorkloadIdentities | CA0900-CA0999 |
| CA-Persona-Developers | CA1000-CA1199 |
Richtlinientypen
BaseProtection
Für jede Persona existiert eine Basisschutzrichtlinie, die grundlegende Sicherheitsanforderungen abdeckt. Bei der Nutzung verwalteter Geräte umfasst dieser Schutz in der Regel bekannte Benutzer und bekannte Geräte. Für externe Gäste kann zusätzlich eine Multi-Faktor-Authentifizierung erforderlich sein.
Der Basisschutz stellt die Standardrichtlinie für alle Anwendungen innerhalb einer Persona dar. Falls eine bestimmte Anwendung abweichende Schutzmaßnahmen erfordert, sollte diese von der Basisschutzrichtlinie ausgenommen und stattdessen durch eine separate, gezielt definierte Richtlinie abgesichert werden.
Beispiel: Falls für interne Benutzer der Zugriff auf alle Cloud-Anwendungen auf bekannte Benutzer und bekannte Geräte beschränkt ist, jedoch Outlook im Web von jedem Gerät aus zugänglich sein soll, kann Exchange Online aus der Basisschutzrichtlinie ausgeschlossen werden. Eine separate Richtlinie könnte dann den Zugriff auf Exchange Online nur unter der Bedingung eines bekannten Geräts oder einer Multi-Faktor-Authentifizierung gestatten.
IdentityProtection
Zusätzlich zum Basisschutz können weitere Conditional Access-Richtlinien implementiert werden, die speziell auf den Schutz von Identitäten ausgerichtet sind.
Beispiele:
- Blockierung der Nutzung von Legacy-Authentifizierung
- Zusätzliche Multi-Faktor-Authentifizierung bei erhöhtem Benutzer- oder Anmelderisiko
- Verpflichtung zur Nutzung eines bekannten Geräts für die Registrierung der Multi-Faktor-Authentifizierung
DataProtection
Dieser Richtlinientyp ergänzt den Basisschutz durch zusätzliche Maßnahmen zur Sicherung sensibler Daten.
Beispiele:
- App-Schutzrichtlinien für iOS und Android zur Verschlüsselung von Daten auf mobilen Geräten
- Sitzungsrichtlinien, die mithilfe von Azure Information Protection sensible Daten beim Download absichern
AppProtection
Diese Richtlinien ergänzen den Basisschutz durch spezifische Sicherheitsmaßnahmen für Anwendungen.
Beispiele:
- Falls Exchange Online von jedem Gerät aus erreichbar sein soll, kann eine spezielle Richtlinie für den Zugriff auf Exchange erstellt werden, die beispielsweise nur Lesezugriff ermöglicht.
- Falls für die Registrierung im Microsoft Endpoint Manager eine Multi-Faktor-Authentifizierung erforderlich ist, kann eine App-Schutzrichtlinie definiert werden, die diese Bedingung durchsetzt.
AttackSurfaceReduction
Der Zweck dieser Richtlinien besteht darin, potenzielle Angriffsvektoren zu minimieren.
Beispiele:
- Blockierung von Zugriffsversuchen von nicht vertrauenswürdigen oder unbekannten Plattformen, um die Umgehung von Conditional Access-Richtlinien zu verhindern
- Einschränkung des Office 365-Zugriffs für Azure-Administratoren
- Sperrung von Anwendungen, die als unsicher oder schädlich bekannt sind
Compliance
Mithilfe von Compliance-Richtlinien kann sichergestellt werden, dass Benutzer bestimmte Anforderungen erfüllen, bevor ihnen Zugriff auf Unternehmensressourcen gewährt wird.
Beispiel: Eine Richtlinie kann Benutzer dazu verpflichten, die Nutzungsbedingungen zu akzeptieren, bevor sie als Gäste auf Ressourcen zugreifen können.
Richtlinienkomponenten
AllApps
Die Bezeichnung „AllApps“ zeigt an, dass eine Conditional Access-Richtlinie auf alle Cloud-Anwendungen angewendet wird. Dies umfasst sowohl Anwendungen, die Conditional Access direkt unterstützen, als auch solche, die dies nicht tun.
In bestimmten Szenarien kann die Anwendung der Richtlinie auf alle Apps problematisch sein. Daher wird empfohlen, zunächst eine allgemeine Basisschutzrichtlinie zu implementieren, die sämtliche Anwendungen abdeckt. Dadurch werden auch neu in Microsoft Entra ID registrierte Anwendungen automatisch in die Sicherheitsrichtlinie aufgenommen.
<AppName>
Der Platzhalter <AppName> steht für eine spezifische Anwendung, die durch eine Richtlinie adressiert wird. Um die Übersichtlichkeit zu wahren, sollten Namen nicht unnötig lang gewählt werden.
Beispiele:
- EXO für Exchange Online
- SPO für SharePoint Online
Plattform-Komponente
Gibt die Plattform an, die von der Richtlinie abgedeckt wird, wie iOS, Android, Windows usw.
| Plattform-Komponenten | Beschreibung/Beispiel |
| AnyPlatform | Die Richtlinie gilt für jede Plattform. Dies konfigurieren Sie in der Regel, indem Sie Any Device auswählen. (In Conditional Access-Richtlinien werden sowohl das Wort Plattform als auch das Wort Gerät verwendet.) |
| iOS | Die Richtlinie gilt für Apple iOS-Plattformen. |
| Android | Die Richtlinie gilt für Google Android-Plattformen. |
| Windows | Die Richtlinie gilt für Windows-Plattformen. |
| Linux | Die Richtlinie gilt für die Linux-Plattformen. |
| WindowsPhone | Die Richtlinie gilt für Windows Phone-Plattformen. |
| macOS | Die Richtlinie gilt für die macOS-Plattformen. |
| iOSAndroid | Die Richtlinie gilt für sowohl iOS- als auch Android-Plattformen. |
| Unknown | Die Richtlinie gilt für jede nicht vorher aufgelistete Plattform. Dies konfigurieren Sie in der Regel, indem Sie Any Device einschließen und alle einzelnen Plattformen ausschließen. |
Kontrolltypen zur Zugriffgewährung bzw. -blockierung
Bestimmt die Anforderungen für die Zugriffsgewährung, wie MFA, konformes Gerät oder hybrid verbundenes Gerät.
| Grant type | Beschreibung/Beispiele |
| Block | Die Richtlinie blockiert die Anmeldung. |
| MFA | Die Richtlinie erfordert Multi-Faktor-Authentifizierung. |
| Compliant | Die Richtlinie erfordert ein konformes Gerät, wie von Endpoint Manager bestimmt, sodass das Gerät von Endpoint Manager verwaltet werden muss. |
| CompliantorAADHJ | Die Richtlinie erfordert ein konformes Gerät ODER ein Microsoft Entra hybrid verbundenes Gerät. Ein Standard-Firmencomputer, der in die Domäne eingebunden ist, ist auch hybrid mit Microsoft Entra ID verbunden. Mobiltelefone und Windows 10-Computer, die ko-verwaltet oder Microsoft Entra verbunden sind, können konform sein. |
| CompliantandAADHJ | Die Richtlinie erfordert ein Gerät, das sowohl konform als auch hybrid mit Microsoft Entra verbunden ist. |
| MFAorCompliant | Die Richtlinie erfordert ein konformes Gerät ODER Multi-Faktor-Authentifizierung, wenn es nicht konform ist. |
| MFAandCompliant | Die Richtlinie erfordert ein konformes Gerät UND Multi-Faktor-Authentifizierung. |
| MFAorAADHJ | Die Richtlinie erfordert einen hybrid mit Microsoft Entra verbundenen Computer ODER Multi-Faktor-Authentifizierung, wenn es kein hybrid mit Microsoft Entra verbundener Computer ist. |
| MFAandAADHJ | Die Richtlinie erfordert einen hybrid mit Microsoft Entra verbundenen Computer UND Multi-Faktor-Authentifizierung. |
| RequireApprovedClient | Die Richtlinie erfordert eine genehmigte Client-App. |
| AppProtection | Die Richtlinie erfordert App-Schutz |
| Unmanaged | Die Richtlinie zielt auf Geräte ab, die Microsoft Entra ID nicht bekannt sind. Beispielsweise können Sie diesen Grant-Typ verwenden, um den Zugriff auf Exchange Online von jedem Gerät aus zu ermöglichen. |
Benannte Standorte
Definiert vertrauenswürdige IPs oder Regionen, um Zugriffsrichtlinien basierend auf dem geografischen Standort anzupassen.
Eine Übersicht aller Conditional Access Richtlinien, die im Standard ausgeliefert werden, sind im folgenden Excel Sheet dokumentiert:
Wer die Conditional Access Richtlinien nicht händig implementieren möchte, kann auf mein im Git Repository veröffentlichtes PowerShell Script zurückgreifen. Dieses Script importiert die Richtlinien aus den JSON Dateien, und legt alle notwendigen Entra ID Gruppen ensprechend automatisch an.
Das Git Repository kann hier heruntergeladen werden: https://dev.azure.com/patsel/Persona-based-Conditional-Access-Framework%20(public)
Der Import wird gestartet über:
Import-CAPolicies.ps1 -InputDir .\CAPolicies -PolicyState ' enabledForReportingButNotEnforced'
Die meiner Meinung nach wichtigste Richtlinie: „Alles ist standardmäßig blockiert“
Eine der wichtigsten Regeln im Persona Framework ist:
🔒 „Alles ist standardmäßig blockiert – nur freigegebene Personas haben Zugriff.“
Das bedeutet:
- Identitäten, die keiner Persona-Gruppe zugeordnet sind, werden automatisch ausgeschlossen.
- Jeder Benutzerzugriff muss aktiv erlaubt werden (Whitelist-Ansatz).
- Dies minimiert Sicherheitsrisiken durch unbekannte oder nicht verwaltete Identitäten.
Beispiel:
Die Regel CA00001-Global-BaseProtection-AllApps-AnyPlatform-BlockNonPersonas verhindert, dass nicht definierte Benutzer Zugriff erhalten.
Ergebnis:
❌ Kein Zugriff für nicht zugewiesene Identitäten
✅ Zugriff nur für bekannte Personas
Erstellt mit https://idpowertoys.merill.net/ Conditional Access Documenter
Praxiserfahrungen: Warum das Framework für jede Unternehmensgröße sinnvoll ist
Als Architekt für Microsoft Security höre ich oft folgende Bedenken:
„Das ist doch nur für große Unternehmen geeignet!“
Doch genau hier liegt meiner Meinung nach ein Missverständnis. Selbst kleine Unternehmen profitieren enorm von der strukturierten Verwaltung ihrer Identitäten. und Richtlinien Das Framework sorgt für:
- Skalierbarkeit – Richtlinien wachsen mit dem Unternehmen.
- Automatisierung – Standardisierte Richtlinien erleichtern das Onboarding neuer Benutzer.
- Effektiven Schutz – Gezielte Zugriffssteuerung reduziert Angriffsvektoren.
Wenn Kunden noch nicht überzeugt sind, stelle ich immer diese Frage:
„Haben Sie eine Firewall für Ihr Unternehmensnetzwerk und Regeln eingehenden Netzwerktraffic?“
Natürlich lautet die Antwort fast immer Ja. Aber warum sollte Identitätssicherheit dann weniger granular verwaltet werden als Netzwerkzugriffe?
Identitäten sind das neue Perimeter – und müssen genauso konsequent geschützt werden.
Mit dem Persona Framework wird Conditional Access zu einem echten Schutzschild gegen Identitätsdiebstahl und unautorisierte Zugriffe.
Fazit: Strukturierte Identitätssicherheit mit Conditional Access
Das Persona-based Conditional Access Framework ist ein essenzielles Modell für moderne Identitätssicherheit. Es ermöglicht Unternehmen, den Zugriff auf Ressourcen klar zu steuern, Angriffsvektoren effektiv zu reduzieren und Sicherheitsrichtlinien strukturiert durchzusetzen.
Durch die Kombination von gruppenbasierten Personas, modularen Richtlinientypen und einer klaren Whitelist-Strategie wird Conditional Access zu einem mächtigen Werkzeug für die Zero-Trust-Strategie.
🚀 Meine Empfehlung: Wer Conditional Access noch nicht nutzt oder strukturiert hat, sollte sich unbedingt mit dem Persona Framework befassen.
Toller Blog-Artikel!
Ein Script-Parameter zum Überspringen der Gruppenerstellung wäre noch wünschenswert!
Die Gruppen sind essentiell im Persona-Ansatz. Eine Parameter, um diesen Teil zu überspringen, ist meiner Meinung nach nicht zielführend.
Du kannst, wenn die Gruppen bereits in Entra ID vorhanden sind, diese mit dem Displayname in den zu importierenden JSON angeben. Dann wird beim Import festgestellt, dass die Gruppen bereits vorhanden sind.