In diesem Artikel wird eine Architektur für bedingten Zugriff beschrieben, die den Zero Trust-Prinzipien entspricht. Die Architektur verwendet einen personabasierten Ansatz, um ein strukturiertes Framework für bedingten Zugriff zu bilden.
Architektur für bedingten Zugriff zero Trust
Sie müssen zuerst eine Architektur auswählen. Es wird empfohlen, entweder eine Gezielte oder eine Zero Trust-Architektur für bedingten Zugriff zu berücksichtigen. Dieses Diagramm zeigt die entsprechenden Einstellungen:
Die Zero Trust Conditional Access-Architektur ist die Architektur, die am besten zu den Prinzipien von Zero Trust passt. Wenn Sie die Option Alle Cloud-Apps in einer Richtlinie für bedingten Zugriff auswählen, werden alle Endpunkte durch die bereitgestellten Erteilungssteuerelemente geschützt, z. B. bekannte Benutzer und bekannte oder kompatible Geräte. Die Richtlinie gilt jedoch nicht nur für die Endpunkte und Apps, die bedingten Zugriff unterstützen. Sie gilt für jeden Endpunkt, mit dem der Benutzer interagiert.
Ein Beispiel ist ein Geräteanmeldungsflussendpunkt, der in verschiedenen neuen PowerShell- und Microsoft Graph-Tools verwendet wird. Der Geräteanmeldungsfluss bietet eine Möglichkeit, die Anmeldung von einem Gerät zuzulassen, auf dem es nicht möglich ist, einen Anmeldebildschirm anzuzeigen, z. B. ein IoT-Gerät.
Ein gerätebasierter Anmeldebefehl wird auf dem angegebenen Gerät ausgeführt, und dem Benutzer wird ein Code angezeigt. Dieser Code wird auf einem anderen Gerät verwendet. Der Benutzer wechselt zu https://aka.ms/devicelogin und gibt seinen Benutzernamen und sein Kennwort an. Nach der Anmeldung vom anderen Gerät aus ist die Anmeldung auf dem IoT-Gerät in diesem Benutzerkontext erfolgreich.
Die Herausforderung bei dieser Anmeldung besteht darin, dass der gerätebasierte bedingte Zugriff nicht unterstützt wird. Dies bedeutet, dass niemand die Tools und Befehle verwenden kann, wenn Sie eine Basisrichtlinie anwenden, die bekanntes Benutzer- und bekanntes Gerät für alle Cloud-Apps erfordert. Es gibt andere Anwendungen, die dasselbe Problem mit dem gerätebasierten bedingten Zugriff haben.
Die andere Architektur, die gezielt, basiert auf dem Prinzip, dass Sie nur auf einzelne Apps abzielen, die Sie in Richtlinien für bedingten Zugriff schützen möchten. In diesem Fall ist die Geräteanmeldung für Endpunkte, die zuvor von allen Cloud-Apps abgedeckt wurden, z. B. Graph-Aufrufe an Microsoft Entra ID, nicht durch die Richtlinien für bedingten Zugriff geschützt, sodass sie weiterhin funktionieren.
Wenn Sie die Geräteanmeldung als Beispiel verwenden, um die beiden Architekturen zu unterscheiden, können Sie sich bei der Geräteanmeldung authentifizieren. Die Geräteanmeldung kann möglicherweise für eine oder mehrere einzelne Anwendungen zulässig sein, da jede Anwendung zielfähig ist und dadurch in einer Richtlinie für bedingten Zugriff ausgeschlossen werden kann, die eine gerätebasierte Anmeldung erfordert.
Die Herausforderung bei der gezielten Architektur besteht darin, dass Sie vergessen können, alle Ihre Cloud-Apps zu schützen. Trotzdem würden Sie alle auswählbaren Anwendungen in den Richtlinien für bedingten Zugriff auswählen. Sie lassen den Zugriff auf die Anwendungen, die nicht ausgewählt werden können, nicht geschützt. Beispiele sind der Zugriff auf das Office-Portal, das Azure EA(Enterprise Agreement)-Portal und das Sicherheitsinformationsportal, das alle sehr sensiblen Portale sind.
Eine weitere Überlegung ist, dass die Anzahl der Office 365- und Microsoft Entra-Apps im Laufe der Zeit zunimmt, da Microsoft und Partner neue Features veröffentlichen und als Ihre IT-Administratoren verschiedene Anwendungen in Microsoft Entra ID integrieren. Der Zugriff auf alle solchen Anwendungen ist nur dann geschützt, wenn Sie über einen Mechanismus verfügen, der eine neue App erkennt, die bedingten Zugriff unterstützt und automatisch eine Richtlinie darauf anwendet. Das Erstellen und Verwalten eines solchen Skripts kann schwierig sein.
Außerdem beträgt die maximale unterstützte Anzahl von Apps für eine richtlinie für bedingten Zugriff ungefähr 250. Möglicherweise können Sie bis zu 600 Apps hinzufügen, bevor Sie eine Fehlermeldung darüber erhalten, dass die Nutzlast überschritten wird, diese Zahl wird jedoch nicht unterstützt.
Personas für bedingten Zugriff
Es gibt viele Möglichkeiten zum Strukturieren von Richtlinien für bedingten Zugriff. Ein Ansatz besteht darin, Richtlinien basierend auf der Vertraulichkeit der Ressource zu strukturieren, auf die zugegriffen wird. In der Praxis kann dieser Ansatz schwierig sein, auf eine Weise zu implementieren, die den Zugriff auf Ressourcen für verschiedene Benutzer weiterhin schützt.
Sie können beispielsweise eine Richtlinie für den bedingten Zugriff definieren, die einen bekannten Benutzer und ein bekanntes Gerät für den Zugriff auf eine sensible Ressource erfordert, auf die sowohl Gäste als auch Mitarbeiter zugreifen müssen. Wenn Gäste den Zugriff von einem verwalteten Gerät aus versuchen, funktioniert die Zugriffsanforderung nicht. Sie müssen die Richtlinie für bedingten Zugriff anpassen, um beide Anforderungen zu erfüllen, was in der Regel zu einer Richtlinie führt, die die weniger sichere Anforderung erfüllt.
Ein weiterer Ansatz besteht darin, Zugriffsrichtlinien basierend auf dem Ort zu definieren, an dem sich ein Benutzer in der Organisation befindet. Dieser Ansatz kann zu vielen Richtlinien für bedingten Zugriff führen und ist möglicherweise nicht verwaltbar.
Ein besserer Ansatz besteht darin, Richtlinien im Zusammenhang mit allgemeinen Zugriffsanforderungen zu strukturieren und eine Reihe von Zugriffsanforderungen in einer Persona für eine Gruppe von Benutzern zu bündeln, die dieselben Anforderungen haben. Personas sind Identitätstypen, die gemeinsame Unternehmensattribute, Verantwortlichkeiten, Erfahrungen, Ziele und Zugriff gemeinsam nutzen.
Das Verständnis, wie Unternehmensressourcen und Ressourcen von verschiedenen Personas aufgerufen werden, ist integraler Bestandteil der Entwicklung einer umfassenden Zero Trust-Strategie.
Einige vorgeschlagene Personas für bedingten Zugriff von Microsoft werden hier gezeigt:
Microsoft empfiehlt außerdem, eine separate Persona für Identitäten zu definieren, die nicht Teil einer anderen Persona-Gruppe sind. Dies wird als globale Persona bezeichnet. Global soll Richtlinien für Identitäten erzwingen, die sich nicht in einer Persona-Gruppe befinden, und Richtlinien, die für alle Personas erzwungen werden sollen.
In den folgenden Abschnitten werden einige empfohlene Personas beschrieben.
Global
Global ist ein Persona/Platzhalter für Richtlinien, die allgemein in der Natur sind. Es wird verwendet, um Richtlinien zu definieren, die für alle Personas gelten oder die nicht für eine bestimmte Persona gelten. Verwenden Sie sie für Richtlinien, die nicht von anderen Personas abgedeckt werden. Sie benötigen diese Persona, um alle relevanten Szenarien zu schützen.
Angenommen, Sie möchten eine Richtlinie verwenden, um die Legacyauthentifizierung für alle Benutzer zu blockieren. Sie können sie zu einer globalen Richtlinie machen, anstatt eine Gruppe von Legacyrichtlinien zu verwenden, die für verschiedene Personas unterschiedlich sein können.
Ein weiteres Beispiel: Sie möchten ein bestimmtes Konto oder einen Bestimmten Benutzer aus bestimmten Anwendungen blockieren, und der Benutzer oder das Konto ist nicht Teil eines der Personas. Wenn Sie beispielsweise eine Cloudidentität im Microsoft Entra-Mandanten erstellen, ist diese Identität nicht Teil eines der anderen Personas, da ihnen keine Microsoft Entra-Rollen zugewiesen sind. Möglicherweise möchten Sie die Identität dennoch am Zugriff auf Office 365-Dienste hindern.
Möglicherweise möchten Sie den gesamten Zugriff auf Identitäten blockieren, die nicht von einer Persona-Gruppe abgedeckt sind. Oder Sie möchten einfach nur die mehrstufige Authentifizierung erzwingen.
Administratoren
In diesem Zusammenhang ist ein Administrator eine beliebige Nicht-Gastidentität, Cloud oder synchronisiert, die über eine Microsoft Entra-ID oder eine andere Microsoft 365-Administratorrolle verfügt (z. B. in Microsoft Defender für Cloud-Apps, Exchange, Defender für Endpunkt oder Compliance-Manager). Da Gäste, die über diese Rollen verfügen, in einer anderen Persona behandelt werden, werden Gäste von dieser Persona ausgeschlossen.
Einige Unternehmen verfügen über separate Konten für die vertraulichen Administratorrollen, auf denen diese Persona basiert. Optimalerweise verwenden Administratoren diese vertraulichen Konten von einer Privileged Access Workstation (PAW). Es wird jedoch häufig angezeigt, dass Administratorkonten auf Standardarbeitsstationen verwendet werden, bei denen der Benutzer einfach zwischen Konten auf einem Gerät wechselt.
Möglicherweise möchten Sie basierend auf der Vertraulichkeit von Cloudadministratorrollen unterscheiden und der Internen Persona weniger sensible Azure-Rollen zuweisen, anstatt separate Konten zu verwenden. Sie können dann stattdessen just-In-Time (JIT) Erhöhung verwenden. In diesem Fall richtet sich ein Benutzer an zwei Gruppen von Richtlinien für bedingten Zugriff, eine für jede Persona. Wenn Sie PAWs verwenden, sollten Sie möglicherweise auch Richtlinien einführen, die Gerätefilter im bedingten Zugriff verwenden, um den Zugriff einzuschränken, sodass Administratoren nur auf PAWs zulässig sind.
Entwickler
Die Persona "Entwickler" enthält Benutzer, die eindeutige Anforderungen haben. Sie basieren auf Active Directory-Konten, die mit Microsoft Entra-ID synchronisiert werden, aber sie benötigen speziellen Zugriff auf Dienste wie Azure DevOps, CI/CD-Pipelines, Gerätecodefluss und GitHub. Die Entwicklerpersona kann Benutzer enthalten, die als intern betrachtet werden und andere als extern betrachtet werden, aber eine Person sollte sich nur in einer der Personas befinden.
Internals
Interne Elemente enthalten alle Benutzer, die ein Active Directory-Konto mit Microsoft Entra-ID synchronisiert haben, die Mitarbeiter des Unternehmens sind und in einer standardmäßigen Endbenutzerrolle arbeiten. Es wird empfohlen, der Entwicklerpersona interne Benutzer hinzuzufügen.
externen
Diese Persona enthält alle externen Berater, die ein Active Directory-Konto mit Microsoft Entra-ID synchronisiert haben. Es wird empfohlen, externe Benutzer, die Entwickler sind, der Entwicklerpersona hinzuzufügen.
Gäste
Gäste enthalten alle Benutzer, die über ein Microsoft Entra-Gastkonto verfügen, das zum Kundenmandanten eingeladen wurde.
GuestAdmins
Die Persona "GuestAdmins" enthält alle Benutzer, die über ein Microsoft Entra-Gastkonto verfügen, dem eine der zuvor erwähnten Administratorrollen zugewiesen ist.
Microsoft365ServiceAccounts
Diese Persona enthält cloudbasierte Dienstkonten (Microsoft Entra ID), die für den Zugriff auf Microsoft 365-Dienste verwendet werden, wenn keine andere Lösung die Anforderungen erfüllt, z. B. die Verwendung einer verwalteten Dienstidentität.
AzureServiceAccounts-
Diese Persona enthält cloudbasierte Dienstkonten (Microsoft Entra ID), die für den Zugriff auf Azure-Dienste (IaaS/PaaS) verwendet werden, wenn keine andere Lösung den Bedarf erfüllt, z. B. die Verwendung einer verwalteten Dienstidentität.
CorpServiceAccounts
Diese Persona enthält benutzerbasierte Dienstkonten, die alle folgenden Merkmale aufweisen:
- Stammt aus lokalem Active Directory.
- Werden von einem lokalen oder von einem iaaS-basierten virtuellen Computer in einem anderen (Cloud)-Rechenzentrum verwendet, z. B. Azure.
- Werden mit einer Microsoft Entra-Instanz synchronisiert, die auf einen beliebigen Azure- oder Microsoft 365-Dienst zugreift.
Dieses Szenario sollte vermieden werden.
WorkloadIdentities-
Diese Persona enthält Computeridentitäten, z. B. Microsoft Entra-Dienstprinzipale und verwaltete Identitäten. Bedingter Zugriff unterstützt jetzt den Schutz des Zugriffs auf Ressourcen aus diesen Konten, wobei einige Einschränkungen hinsichtlich der verfügbaren Bedingungen und der Gewährung von Steuerelementen gelten.
Access-Vorlagenkarten
Es wird empfohlen, zugriffsvorlagenkarten zu verwenden, um die Merkmale für jede Persona zu definieren. Hier ist ein Beispiel:
Die Vorlagenkarte für jede Persona stellt Eingaben zum Erstellen der spezifischen Richtlinien für den bedingten Zugriff für jede Persona bereit.
Leitfaden für bedingten Zugriff
Überprüfen Sie ein Framework für bedingten Zugriff, das einen strukturierten Ansatz für Gruppierungsrichtlinien basierend auf den erstellten Personas enthält.
Beitragende
Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.
Hauptautor:
- Claus Jespersen | Principal Consultant ID&Sek.
Um nicht öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.
Nächste Schritte
- Lernpfad: Implementieren und Verwalten von Identität und Zugriff
- Was ist bedingter Zugriff?
- allgemeine Richtlinien für bedingten Zugriff