Framework und Richtlinien für bedingten Zugriff
Dieser Artikel bietet ein Framework für die Implementierung einer personabasierten Architektur für bedingten Zugriff, wie die unter Zero Trust-Architektur für bedingten Zugriff beschriebene. In diesem Artikel finden Sie ausführliche Informationen zum Erstellen und Benennen der Richtlinien für bedingten Zugriff. Sie finden dort auch einen Ausgangspunkt für das Erstellen von Richtlinien.
Wenn Sie kein Framework wie das hier bereitgestellte verwenden, einschließlich eines Benennungsstandards, werden Richtlinien im Laufe der Zeit eher von verschiedenen Personen aus dem Augenblick heraus erstellt. Dies kann zu überlappenden Richtlinien führen. Wenn die Person, die eine Richtlinie erstellt hat, nicht mehr verfügbar ist, kann es für andere schwierig werden, den Zweck der Richtlinie zu erkennen.
Das Befolgen eines strukturierten Frameworks erleichtert das Verständnis der Richtlinien. Es erleichtert ferner, alle Szenarien abzudecken und in Konflikt stehende Richtlinien zu vermeiden, für die sich eine Problembehandlung nur schwer durchführen lässt.
Benennungskonventionen
Eine ordnungsgemäß definierte Benennungskonvention hilft Ihnen und Ihren Kollegen dabei, den Zweck einer Richtlinie zu verstehen, was die Richtlinienverwaltung und Problembehandlung vereinfacht. Ihre Benennungskonvention sollte zu dem Framework passen, das Sie zum Strukturieren Ihrer Richtlinien verwenden.
Die empfohlene Benennungsrichtlinie basiert auf Personas, Richtlinientypen und Apps. Dieser sieht folgendermaßen aus:
<CANumber>-<Persona>-<PolicyType>-<App>-<Platform>-<GrantControl>-<OptionalDescription>
Die Komponenten dieses Namens werden hier beschrieben:
| Namenskomponente | Beschreibung/Beispiel |
|---|---|
| ZS-Nummer | Wird verwendet, um den Bereich und die Reihenfolge des Richtlinientyps schnell zu identifizieren. Beispiel: CA001-CA099. |
| Persona | Global, Admins, Internals, Externals, GuestUsers, GuestAdmins, Microsoft365ServiceAccounts, AzureServiceAccounts, CorpServiceAccounts. |
| Richtlinientyp | BaseProtection, AppProtection, DataProtection, IdentityProtection, AttackSurfaceReduction, Compliance. |
| App | AllApps, O365 (für alle Office 365-Dienste), EXO (für Exchange Online). |
| Plattform | AnyPlatform, Unknown (Unbekannt), WindowsPhone, macOS, iOS, Android. |
| Gewährungssteuerelement | Block, ADHJ, Compliant, Unmanaged (wobei „nicht verwaltet“ in der Gerätezustandsbedingung angegeben wird). |
| Beschreibung | Optionale Beschreibung des Zwecks der Richtlinie. |
Nummerierungsschema
Um die Verwaltung zu vereinfachen, empfehlen wir dieses Nummerierungsschema:
| Personagruppe | Nummernzuordnung |
|---|---|
| CA-Persona-Global | CA001-CA099 |
| CA-Persona-Admins | CA100-CA199 |
| CA-Persona-Internals | CA200-CA299 |
| CA-Persona-Externals | CA300-CA399 |
| CA-Persona-GuestUsers | CA400-CA499 |
| CA-Persona-GuestAdmins | CA500-CA599 |
| CA-Persona-M365ServiceAccounts | CA600-CA699 |
| CA-Persona-AzureServiceAccounts | CA700-CA799 |
| CA-Persona-CorpServiceAccounts | CA800-CA899 |
| CA-Persona-WorkloadIdentities | CA900-CA999 |
| CA-Persona-Developers | CA1000-CA1099 |
Richtlinientypen
Dies sind die empfohlenen Richtlinientypen:
| Richtlinientyp | Beschreibung/Beispiele |
|---|---|
| BaseProtection | Für jede Persona gibt es einen Baselineschutz, der von diesem Richtlinientyp abgedeckt wird. Für Benutzer auf verwalteten Geräten ist dies in der Regel ein bekannter Benutzer und ein bekanntes Gerät. Für externe Gäste kann es sich um einen bekannten Benutzer und Multi-Faktor-Authentifizierung handeln. Der Basisschutz ist die Standardrichtlinie für alle Apps für Benutzer in der angegebenen Persona. Wenn eine bestimmte App eine andere Richtlinie aufweisen sollte, schließen Sie diese App aus der Basisschutzrichtlinie aus, und fügen Sie eine explizite Richtlinie hinzu, die nur auf diese App zielt. Beispiel: Angenommen, der Basisschutz für Interne besteht darin, für alle Cloud-Apps einen bekannten Benutzer und ein bekanntes Gerät zu erfordern, aber Sie möchten Outlook im Web von jedem Gerät aus zulassen. Sie könnten Exchange Online aus der Basisschutzrichtlinie ausschließen und eine separate Richtlinie für Exchange Online hinzufügen, in der Sie ein bekanntes Gerät ODER Multi-Faktor-Authentifizierung anfordern. |
| IdentityProtection | Über den Basisschutz für jede Persona hinaus können Sie Richtlinien für bedingten Zugriff haben, die sich auf die Identität beziehen. Beispiele: Blockieren von Legacyauthentifizierung, Anfordern der zusätzlichen Multi-Faktor-Authentifizierung bei hohem Benutzer- oder Anmelderisiko und Anfordern eines bekannten Geräts für die Registrierung mit Multi-Faktor-Authentifizierung. |
| DataProtection | Dieser Richtlinientyp weist auf Deltarichtlinien hin, die Daten als weitere Ebene, zusätzlich zum Basisschutz schützen. Beispiele:
|
| AppProtection | Dieser Richtlinientyp ist eine weitere Ergänzung des Basisschutzes. Beispiele:
|
| AttackSurfaceReduction | Der Zweck dieser Art von Richtlinie besteht in der Abmilderung verschiedener Angriffe. Beispiele:
|
| Kompatibilität | Sie können eine Compliancerichtlinie verwenden, um einen Benutzer dazu zu zwingen, die Nutzungsbedingungen für Gäste anzuzeigen, die auf Kundendienste zugreifen. |
App
In der folgenden Tabelle wird die App-Komponente eines Richtliniennamens beschrieben:
| App-Name | Beschreibung/Beispiele |
|---|---|
| AllApps | „AllApps“ weist darauf hin, dass die Richtlinie für bedingten Zugriff auf alle Cloud-Apps abzielt. Alle Endpunkte werden abgedeckt, einschließlich derjenigen, die bedingten Zugriff unterstützen, und jener, die dies nicht tun. In einigen Szenarien funktioniert die Ausrichtung auf alle Apps nicht gut. Es wird empfohlen, in der Basisrichtlinie auf alle Apps abzuzielen, damit alle Endpunkte von dieser Richtlinie abgedeckt werden. Neue Apps, die in Microsoft Entra ID angezeigt werden, halten auch automatisch die Richtlinie ein. |
| <AppName> | <AppName> ist ein Platzhalter für den Namen einer App, auf die die Richtlinie abzielt. Vermeiden Sie es, einen zu langen Namen zu verwenden. Namensbeispiele:
|
Plattformtyp
In der folgenden Tabelle wird die Plattformkomponente eines Richtliniennamens beschrieben:
| Plattformtyp | Beschreibung |
|---|---|
| AnyPlatform | Die Richtlinie zielt auf alle Plattformen ab. Dies konfigurieren Sie in der Regel, indem Sie Jedes Gerät auswählen. (In Richtlinien für bedingten Zugriff wird sowohl das Wort Plattform als auch das Wort Gerät verwendet.) |
| iOS | Die Richtlinie zielt auf Apple iOS-Plattformen ab. |
| Android | Die Richtlinie zielt auf Google Android-Plattformen ab. |
| Windows | Diese Richtlinie ist auf die Windows-Plattform ausgerichtet. |
| Linux | Diese Richtlinie ist auf die Linux-Plattformen ausgerichtet. |
| WindowsPhone | Die Richtlinie zielt auf Windows Phone-Plattformen ab. |
| macOS | Die Richtlinie zielt auf die macOS-Plattformen ab. |
| iOSAndroid | Die Richtlinie zielt sowohl auf iOS- als auch auf Android-Plattformen ab. |
| Unbekannt | Die Richtlinie zielt auf alle Plattformen ab, die zuvor nicht aufgeführt wurden. Dies konfigurieren Sie in der Regel, indem Sie Jedes Gerät einschließen und alle einzelnen Plattformen ausschließen. |
Typen von Gewährungssteuerelementen
In der folgenden Tabelle wird die Gewährungssteuerelementkomponente eines Richtliniennamens beschrieben:
| Gewährungstyp | Beschreibung/Beispiele |
|---|---|
| Blockieren | Die Richtlinie blockiert die Anmeldung |
| MFA | Die Richtlinie erfordert Multi-Faktor-Authentifizierung. |
| Konform | Die Richtlinie erfordert ein kompatibles Gerät, wie von Endpoint Manager festgelegt, sodass das Gerät von Endpoint Manager verwaltet werden muss. |
| CompliantorAADHJ | Die Richtlinie erfordert ein kompatibles Gerät ODER ein in Microsoft Entra hybrid eingebundenes Gerät. Ein Standardunternehmenscomputer mit Domänenbeitritt ist ebenfalls in Microsoft Entra ID eingebunden. Mobiltelefone und Windows 10-Computer, die gemeinsam verwaltet werden in Microsoft Entra eingebunden sind, können konform sein. |
| CompliantandAADHJ | Die Richtlinie erfordert ein Gerät, das kompatibel UND hybrid in Microsoft Entra eingebunden ist. |
| MFAorCompliant | Die Richtlinie erfordert ein kompatibles Gerät ODER Multi-Faktor-Authentifizierung, wenn es nicht kompatibel ist. |
| MFAandCompliant | Die Richtlinie erfordert ein kompatibles Gerät UND Multi-Faktor-Authentifizierung. |
| MFAorAADHJ | Die Richtlinie erfordert einen hybrid in Microsoft Entra eingebundenen Computer ODER Multi-Faktor-Authentifizierung, wenn es sich nicht um einen hybrid in Microsoft Entra eingebundenen Computer handelt. |
| MFAandAADHJ | Die Richtlinie erfordert einen hybrid in Microsoft Entra eingebundenen Computer UND Multi-Faktor-Authentifizierung. |
| RequireApprovedClient | Die Richtlinie erfordert eine genehmigte Client-App. |
| AppProtection | Die Richtlinie erfordert App-Schutz. |
| Nicht verwaltet | Die Richtlinie zielt auf Geräte ab, die in Microsoft Entra ID unbekannt sind. Beispielsweise können Sie diesen Gewährungstyp verwenden, um den Zugriff auf Exchange Online von jedem Gerät aus zuzulassen. |
Benannte Orte
Es wird empfohlen, diese Standardorte für die Verwendung in Richtlinien für bedingten Zugriff zu definieren:
- Vertrauenswürdige IPs/Interne Netzwerke. Diese IP-Subnetze stellen Standorte und Netzwerke dar, für die physische Zugriffseinschränkungen oder andere Kontrollen eingerichtet sind, z. B. Computersystemverwaltung, Authentifizierung auf Netzwerkebene oder Angriffserkennung. Diese Standorte sind sicherer, sodass die Erzwingung des bedingten Zugriffs lockerer gehandhabt werden kann. Überlegen Sie, ob Azure oder andere Rechenzentrumsstandorte (IPs) in diesen Standort eingeschlossen werden sollen, oder ob sie über eigene benannte Standorte verfügen sollen.
- In Citrix vertrauenswürdige IP-Adressen. Wenn Sie Citrix lokal verwenden, kann es hilfreich sein, separate ausgehende IPv4-Adressen für die Citrix-Farmen zu konfigurieren, wenn Sie aus Citrix-Sitzungen heraus eine Verbindung mit Clouddiensten herstellen können müssen. In diesem Fall können Sie diese Standorte bei Bedarf aus Richtlinien für bedingten Zugriff ausschließen.
- Zscaler-Standorte, falls zutreffend. Auf Computern ist ein ZPA-Agent installiert, und der gesamte Datenverkehr wird an oder über die Zscaler-Cloud an das Internet weitergeleitet. Daher lohnt es sich, Zscaler-Quell-IP-Adressen im bedingten Zugriff zu definieren und zu verlangen, dass alle Anforderungen von nicht mobilen Geräten Zscaler durchlaufen müssen.
- Länder/Regionen, mit denen Geschäftsverkehr zugelassen werden soll. Es kann hilfreich sein, Länder/Regionen in zwei Standortgruppen aufzuteilen: eine, die Bereiche der Welt darstellt, in denen Mitarbeiter normalerweise arbeiten, und eine, die andere Standorte darstellt. Dadurch können Sie zusätzliche Kontrollen auf Anforderungen anwenden, die von außerhalb der Bereiche stammen, in denen Ihre Organisation normalerweise tätig ist.
- Standorte, an denen Multi-Faktor-Authentifizierung schwierig oder unmöglich sein kann. In einigen Szenarien kann die Anforderung der Multi-Faktor-Authentifizierung die Arbeit der Mitarbeiter erschweren. Beispielsweise haben Mitarbeiter möglicherweise nicht die Zeit oder Gelegenheit, auf häufige Herausforderungen zur Multi-Faktor-Authentifizierung zu reagieren. Oder an manchen Orten können HF-Screening oder elektrische Interferenzen die Verwendung mobiler Geräte erschweren. In der Regel verwenden Sie andere Steuerungsmöglichkeiten an diesen Standorten, oder sie können als vertrauenswürdig festgelegt werden.
Standortbasierte Zugriffssteuerungen basieren auf der Quell-IP-Adresse einer Anforderung, um den Standort des Benutzers zum Zeitpunkt der Anforderung zu bestimmen. Es ist zwar nicht einfach, Spoofing im öffentlichen Internet durchzuführen, doch der Schutz durch Netzwerkgrenzen kann eventuell als weniger relevant angesehen werden als früher. Es wird nicht empfohlen, sich ausschließlich auf den Standort als Bedingung für den Zugriff zu verlassen. In einigen Szenarien ist dies jedoch möglicherweise die beste Kontrolle, die Sie verwenden können, z. B. wenn Sie den Zugriff von einem Dienstkonto aus einer lokalen Umgebung sichern, das in einem nicht interaktiven Szenario verwendet wird.
Empfohlene Richtlinien für bedingten Zugriff
Wir haben ein Tabellenblatt erstellt, die empfohlene Richtlinien für bedingten Zugriff enthält. Sie können das Tabellenblatt hier herunterladen.
Verwenden Sie die vorgeschlagenen Richtlinien als Ausgangspunkt.
Ihre Richtlinien werden sich wahrscheinlich im Laufe der Zeit ändern, um Anwendungsfälle zu berücksichtigen, die für Ihr Geschäft wichtig sind. Im Folgenden finden Sie einige Beispiele für Szenarien, die möglicherweise Änderungen erfordern:
- Implementieren des schreibgeschützten Zugriffs auf Exchange Online für Mitarbeiter, die ein beliebiges nicht verwaltetes Gerät verwenden, basierend auf Multi-Faktor-Authentifizierung, App-Schutz und einer genehmigten Client-App.
- Implementieren von Information Protection, um sicherzustellen, dass vertrauliche Informationen nicht ohne verbesserten Schutz heruntergeladen werden, der von Azure Information Protection bereitgestellt wird.
- Bereitstellen von Schutz vor Kopieren und Einfügen durch Gäste.
Mehrere Vorschauen werden derzeit veröffentlicht, sodass Sie Updates für die vorgeschlagene Gruppe von Startrichtlinien für bedingten Zugriff (Conditional Access, CA) erwarten können.
Leitfaden für bedingten Zugriff
Nachdem Sie nun über eine Ausgangsmenge von Richtlinien für bedingten Zugriff verfügen, müssen Sie diese kontrolliert und phasenweise bereitstellen. Es wird empfohlen, ein Bereitstellungsmodell zu verwenden.
Hier sehen Sie einen Ansatz:
Die Idee dabei ist, Richtlinien zunächst für eine kleine Anzahl von Benutzern innerhalb einer Personagruppe bereitzustellen. Sie können eine zugeordnete Microsoft Entra-Gruppe namens „Persona Ring 0“ für diese Bereitstellung verwenden. Nachdem Sie überprüft haben, dass alles funktioniert, ändern Sie die Zuweisung auf eine Gruppe, „Personaring 1“, die mehr Mitglieder hat usw.
Anschließend aktivieren Sie die Richtlinien mit demselben ringbasierten Ansatz, bis alle Richtlinien bereitgestellt sind.
Normalerweise verwalten Sie die Mitglieder von Ring 0 und Ring 1 manuell. Eine Ringgruppe 2 oder 3, die Hunderte oder sogar Tausende von Benutzern enthält, kann über eine dynamische Gruppe verwaltet werden, die auf einem Prozentsatz der Benutzer in einer bestimmten Persona basiert.
Die Verwendung von Ringen als Teil eines Bereitstellungsmodells dient nicht nur der Erstbereitstellung. Sie können diesen Ansatz auch verwenden, wenn neue Richtlinien oder Änderungen an vorhandenen Richtlinien erforderlich sind.
Nach einer fertig gestellten Bereitstellung sollten Sie auch die Überwachungskontrollen entwerfen und implementieren, die in den Prinzipien für bedingten Zugriff erläutert wurden.
Zusätzlich zur Automatisierung der Erstbereitstellung sollten Sie Änderungen an Richtlinien mithilfe von CI/CD-Pipelines automatisieren. Sie können für diese Automatisierung Microsoft365DSC verwenden.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautor:
- Claus Jespersen | Principal Consultant ID&Sec
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
Zugehörige Ressourcen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für