In diesem Artikel wird eine Architektur für bedingten Zugriff beschrieben, die 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 mit Zero Trust
Zunächst müssen Sie eine Architektur auswählen. Es wird empfohlen, entweder eine (gezielte) Targeted- oder eine Zero Trust-Architektur für bedingten Zugriff zu erwägen. Dieses Diagramm zeigt die entsprechenden Einstellungen:
Die Zero Trust-Architektur für bedingten Zugriff ist diejenige, die den Zero Trust-Prinzipien am besten entspricht. Wenn Sie die Option Alle Cloud-Apps in einer Richtlinie für bedingten Zugriff auswählen, werden alle Endpunkte durch die bereitgestellten Gewährungssteuerelemente geschützt, z. B. bekannter Benutzer und bekanntes oder konformes Gerät. Die Richtlinie gilt jedoch nicht nur für die Endpunkte und Apps, die den bedingten Zugriff unterstützen. Sie gilt für jeden Endpunkt, mit dem der Benutzer interagiert.
Ein Beispiel hierfür ist ein Endpunkt für einen Geräteanmeldungsflow, der in verschiedenen neuen PowerShell- und Microsoft Graph-Tools verwendet wird. Ein Geräteanmeldungsflow bietet eine Möglichkeit, die Anmeldung von einem Gerät aus 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 das Kennwort an. Nach der Anmeldung vom anderen Gerät aus erfolgt die Anmeldung auf dem IoT-Gerät in diesem Benutzerkontext mit Erfolg.
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 Baselinerichtlinie anwenden, die einen bekannten Benutzer und ein bekanntes Gerät für alle Cloud-Apps erfordert. Es gibt andere Anwendungen, die das selbe Problem mit dem gerätebasierten bedingten Zugriff haben.
Die andere Architektur, die gezielte Architektur, basiert auf dem Prinzip, dass Sie nur einzelne Apps als Ziel verwenden, 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 waren, wie z. B. Graph-Aufrufe an Microsoft Entra ID, nicht durch die Richtlinien für bedingten Zugriff geschützt, so dass sie weiterhin funktionieren.
Wenn Sie die Geräteanmeldung als Beispiel verwenden, um die beiden Architekturen zu unterscheiden, können Sie sich mit der Geräteanmeldung authentifizieren. Die Geräteanmeldung kann möglicherweise für eine oder mehrere einzelne Anwendungen zulässig sein, da jede Anwendung als Ziel geeignet 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 ist, dass Sie möglicherweise vergessen, alle Ihre Cloud-Apps zu schützen. Selbst dann würden Sie alle auswählbaren Anwendungen in den Richtlinien für den bedingten Zugriff auswählen. Sie lassen den Zugriff auf die Anwendungen, die nicht ausgewählt werden können, ungeschützt. Beispiele sind der Zugriff auf das Office-Portal, das Azure EA-Portal (Enterprise Agreement) und das Sicherheitsinformationsportal, die alle sehr vertrauliche 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 Funktionen veröffentlichen und Ihre IT-Administratoren verschiedene Anwendungen mit Microsoft Entra ID integrieren. Der Zugriff auf all diese Anwendungen ist nur geschützt, wenn Sie über einen Mechanismus verfügen, der jede 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 maximal 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 einen Fehler bezüglich der Überschreitung der Nutzlast erhalten, doch diese Anzahl wird nicht unterstützt.
Personas für bedingten Zugriff
Es gibt viele Möglichkeiten, Richtlinien für bedingten Zugriff zu strukturieren. Ein Ansatz besteht darin, Richtlinien basierend auf der Vertraulichkeit der Ressource zu strukturen, auf die zugegriffen wird. In der Praxis kann es schwierig sein, diesen Ansatz so zu implementieren, dass der Zugriff auf Ressourcen für verschiedene Benutzer weiterhin geschützt ist.
Beispielsweise können Sie eine Richtlinie für bedingten Zugriff definieren, die einen bekannten Benutzer und ein bekanntes Gerät für den Zugriff auf eine vertrauliche Ressource erfordert, auf die sowohl Gäste als auch Mitarbeiter zugreifen müssen. Wenn Gäste versuchen, von einem verwalteten Gerät aus darauf zuzugreifen, funktioniert die Zugriffsanforderung nicht. Sie müssten die Richtlinie für bedingten Zugriff so anpassen, dass beide Anforderungen erfüllt werden, was normalerweise zu einer Regel führen würde, 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 praktisch nicht verwaltbar.
Ein besserer Ansatz besteht darin, Richtlinien im Zusammenhang mit allgemeinen Zugriffsanforderungen zu strukturieren und einen Satz 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, Zuständigkeiten, Erfahrungen, Ziele und Zugriffe aufweisen.
Das Verständnis, wie verschiedene Personas auf Unternehmensobjekte und -ressourcen zugreifen, ist entscheidend für die Entwicklung einer umfassenden Zero Trust-Strategie.
Einige vorgeschlagene Personas für bedingten Zugriff von Microsoft sehen Sie hier:
Microsoft empfiehlt auch, eine separate Persona für Identitäten zu definieren, die keiner anderen Personagruppe angehören. Diese wird als globale Persona bezeichnet. Global soll Richtlinien für Identitäten erzwingen, die sich nicht in einer Personagruppe befinden, sowie Richtlinien, die für alle Personas erzwungen werden sollen.
In den folgenden Abschnitten werden einige empfohlene Personas beschrieben.
Global
„Global“ ist eine Persona bzw. ein Platzhalter für Richtlinien, die allgemeiner Natur sind. Sie wird verwendet, um Richtlinien zu definieren, die für alle Personas oder für keine einzelne, 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 in eine globale Richtlinie umwandeln, anstatt eine Gruppe von Legacyrichtlinien zu verwenden, die sich für verschiedene Personas unterscheiden können.
Ein weiteres Beispiel: Sie möchten ein bestimmtes Konto oder einen bestimmten Benutzer für bestimmte Anwendungen blockieren, und der Benutzer oder das Konto gehört zu keinen der Personas. Wenn Sie beispielsweise eine Cloud-Identität im Microsoft Entra-Mandant erstellen, ist diese Identität nicht Teil einer der anderen Personas, da ihr keine Microsoft Entra-Rollen zugewiesen sind. Möglicherweise möchten Sie dennoch den Zugriff der Identität auf Office 365-Dienste blockieren.
Möglicherweise möchten Sie den gesamten Zugriff von Identitäten blockieren, die nicht von einer Personagruppe abgedeckt werden. Oder Sie möchten einfach nur die Multi-Faktor-Authentifizierung erzwingen.
Administratoren
In diesem Zusammenhang ist ein Administrator jede Nicht-Gast-Identität, ob in der 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 Endpoint oder Compliance Manager). Da Gäste mit diesen Rollen von einer anderen Persona abgedeckt werden, sind Gäste aus dieser Persona ausgeschlossen.
Einige Unternehmen verfügen über separate Konten für die sensiblen Administratorrollen, auf denen diese Persona basiert. Optimalerweise verwenden Administratoren diese sensiblen Konten über eine Arbeitsstation mit privilegiertem Zugriff (Privileged Access Workstation, PAW). Wir sehen jedoch häufig, dass Administratorkonten auf Standardarbeitsstationen verwendet werden, auf denen der Benutzer lediglich zwischen Konten auf demselben Gerät wechselt.
Möglicherweise möchten Sie basierend auf der Vertraulichkeit von Cloudadministratorrollen differenzieren und der Persona „Internals“ (Interna) weniger sensible Azure-Rollen zuweisen, anstatt gesonderte Konten zu verwenden. Sie können dann stattdessen die Just-In-Time-Rechteerweiterung (JIT) verwenden. In diesem Fall zielen zwei Gruppen von Richtlinien für bedingten Zugriff auf einen Benutzer ab, eine für jede Persona. Wenn Sie PAWs verwenden, sollten Sie auch Richtlinien einführen, die Gerätefilter beim bedingten Zugriff verwenden, um den Zugriff so einzuschränken, dass Administratoren nur auf PAWs zugelassen werden.
Entwickler
Die Persona „Developers“ (Entwickler) enthält Benutzer, die besondere Anforderungen haben. Sie basieren auf Active Directory-Konten, die mit Microsoft Entra ID synchronisiert werden. Sie benötigen jedoch einen speziellen Zugriff auf Dienste wie Azure DevOps, CI/CD-Pipelines, Device Code Flow und GitHub. Die Entwickler-Persona kann Benutzer einschließen, die als intern betrachtet werden, sowie andere, die als extern betrachtet werden. Ein Benutzer sollte aber nur zu einer der Personas gehören.
Interna
Internals enthält alle Benutzer, die über ein mit Microsoft Entra ID synchronisiertes Active Directory-Konto verfügen, die Mitarbeiter des Unternehmens sind und die in einer Standard-Endbenutzerrolle arbeiten. Es wird empfohlen, interne Benutzer, die Entwickler sind, der Entwickler-Persona hinzuzufügen.
Externals
Diese Persona enthält alle externen Berater, die über ein mit Microsoft Entra ID synchronisiertes Active Directory-Konto verfügen. Es wird empfohlen, externe Benutzer, die Entwickler sind, der Entwickler-Persona hinzuzufügen.
Guests
Guests enthält alle Benutzer, die über ein Microsoft Entra-Gastkonto verfügen, das zum Kundenmieter eingeladen wurde.
GuestAdmins
Die Persona GuestAdmins enthält alle Benutzer, die über ein Microsoft Entra-Gastkonto verfügen, dem eine der oben genannten Admin-Rollen zugewiesen ist.
Microsoft365ServiceAccounts
Diese Persona enthält auf der Cloud (Microsoft Entra ID) basierende Benutzerkonten für Dienste, die für den Zugriff auf Microsoft 365-Dienste verwendet werden, wenn keine andere Lösung den Bedarf deckt, wie z. B. die Verwendung einer verwalteten Dienstidentität.
AzureServiceAccounts
Diese Persona enthält auf der Cloud (Microsoft Entra ID) basierende Benutzerkonten für Dienste, die für den Zugriff auf Azure-Dienste (IaaS/PaaS) verwendet werden, wenn keine andere Lösung die Anforderungen erfüllt, wie z. B. die Verwendung einer verwalteten Dienstidentität.
CorpServiceAccounts
Diese Persona (Unternehmensdienstkonten) enthält benutzerbasierte Dienstkonten, die alle der folgenden Merkmale aufweisen:
- Stammen aus dem lokalen Active Directory.
- Werden lokal oder von einem IaaS-basierten virtuellen Computer aus in einem anderen (Cloud-)Rechenzentrum wie Azure verwendet.
- Werden mit einer Microsoft Entra-Instanz synchronisiert, die auf einen Azure- oder Microsoft 365-Dienst zugreift.
Dieses Szenario sollte vermieden werden.
WorkloadIdentities
Diese Persona enthält Rechneridentitäten, wie Microsoft Entra Dienstprinzipals und verwaltete Identitäten. Bedingter Zugriff unterstützt jetzt den Schutz des Zugriffs auf Ressourcen aus diesen Konten, wobei einige Einschränkungen in Bezug auf die Bedingungen und die Gewährung von Kontrollen verfügbar sind.
Zugriffsvorlagenkarten
Es wird empfohlen, Zugriffsvorlagenkarten zu verwenden, um die Merkmale für jede Persona zu definieren. Hier sehen Sie ein Beispiel:
Die Vorlagenkarte für jede Persona bietet Eingaben zum Erstellen der spezifischen Richtlinien für bedingten Zugriff für jede Persona.
Leitfaden für bedingten Zugriff
Sehen Sie sich ein Framework für bedingten Zugriff an, das einen strukturierten Ansatz zum Gruppieren von Richtlinien auf Grundlage der erstellten Personas enthält.
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
- Lernpfad: Implementieren und Verwalten von Identität und Zugriff
- Was ist bedingter Zugriff?
- Allgemeine Richtlinien für bedingten Zugriff