In dieser kleinen Blog-Serie möchte ich einen Ansatz vorstellen, der von Microsoft 365 Kunden genutzt werden kann um für bestimmte Personen im Unternehmen die Möglichkeiten einzuschränken die ein beabsichtigtes oder unbeabsichtigtes Teilen von Dateien über die Organisationsgrenzen hinweg ermöglicht.

Der beschriebene Ansatz sollte - in dieser Ausprägung - nur eine temporäre Maßnahme sein bis zielgerichtete Methoden wie Data Loss Prevention (DLP) & Microsoft Purviev Information Protection (MIP / AIP) organisationsweit nutzbar sind. Da diese Werkzeuge in der Regel eine ausführliche Planung und Pilotierung und zumeist auch erhöhte Lizenzanforderungen haben, sind sie zumeist sehr zeit- und kostenintensiv.

Der hier beschriebene Isolations-Ansatz ist mit weniger Ressourcen zu realisieren, erlaubt aber weniger Flexibilität behandelt nur sehr explizite Risiken.

Was wir mit diesem Ansatz erreichen:

1. Betroffene Geräte können nicht mehr genutzt werden, um mit fremden Accounts in dritten Microsoft 365 Umgebungen zu arbeiten. Dieses Ergebnis bewirkt das Personen nicht bewusst einen unternehmensfremden Login für M365 nutzen, um Daten vom verwalteten Gerät abfließen zu lassen.

2. Betroffene Personen können sich mit ihrem Account nicht bei dritten Microsoft 365 Tenants anmelden. Hiermit wird vor allen Dingen erreicht, dass die Personen durch den transparenten Wechsel ihres Kontext in Teams, SharePoint und OneDrive ohne Absicht Dokumente und Informationen in diesem dritten Tenant ablegen.

Die Werkzeuge, die wir für die Umsetzung hauptsächlich nutzen sind die Entra ID Features Global Secure Access, Tenant Restrictions und Outbound Access Settings.

Für die Umsetzung des ersten Punktes nutzen wir Global Secure Access (GSA). Diese “Secure Service Edge“-Lösung (“Don’t call it VPN!“) ist noch recht neu im Microsoft Portfolio und hat das Potential echter Gamechanger in der Verbindungssicherheit für Microsoft-Umgebungen zu werden. Diese Lösung gibt es in den drei Ausprägungen “Internet Access“, “Private Access“ und “Microsoft Traffic“. Mit “Private Access“ kann man eine ortsunabhängige Verbindung zu Ressourcen im eigenen RZ (wie z.B. klassische File Server) auf Zero-Trust Standard realisieren. Mit “Internet Access“ lässt sich die Client Verbindung in das WWW und dritten SaaS ebenso absichern. Für die Realisierung unserer Anforderung nutzen wir das GSA Traffic Profile “Microsoft Traffic“. Mit diesem lässt sich die Verbindung zwischen dem Client und M365 behandeln.

Während die Profile “Internet Access“ und “Private Access“ eine separate Lizenz erfordern ist das Profil “Microsoft Traffic“ mit einer Entra ID P1 / P2 Lizenz nutzbar (Global Secure Access traffic forwarding profiles - Global Secure Access | Microsoft Learn ) und somit flächendeckend ohne besondere Zusatzkosten nutzbar.

Wir nutzen den Global Secure Access Client (verfügbar für Windows, MacOS, iOS & Android) um in Kombination mit Conditional Access - in diesem Beispiel - die sogenannten Universal Tenant Restrictions umzusetzen. Die Tenant Restrictions definieren im Prinzip eine Whitelist an Tenant ID’s die für die bestimmten Benutzergruppen verfügbar sein sollen.

Bevor GSA im Spiel war, konnten diese Tenant Restrictions auch schon genutzt werden, allerdings mussten andere dritte Komponenten wie ein Proxy die Konfiguration durchsetzen. Mit der Möglichkeit allen Traffic zu den M365 Endpunkten über den GSA-Client zu routen, wird die Durchsetzung der Tenant Restrictions nun wesentlich simpler und die Abdeckung der Lösung wird breiter.

So, kommen wir nun erstmal zum Umsetzungsbeispiel! In diesem Artikel setzen wir zunächst die erste Konfiguration durch um zu verhindern das Daten allzu leicht von verwalteten Geräten abhandenkommen können.

Profil-Aktivierung

Aktivieren des “Microsoft traffic” Profils im Global Secure Access Service

Regeln die bei der Nutzung des M365 Traffic Profil gelten

Nun ist die Funktion grundsätzlich verfügbar, ohne weitere Konfiguration ist sie aber noch nicht aktiv. Das Profil definiert für welchen Destinationen (IP’s & URL’s) der Client Traffic durch den GSA Client geschleust wird. In diesem Profil - welches ja nur den M365 Traffic behandeln soll - werden die IP’s und URLs behandelt die für M365 relevant sind.

Durch das Zuweisen einer Gruppe zu dem Profil kann dieses von den Mitgliedern grundsätzlich genutzt werden. Die eigentliche Einschränkung der Logins in fremde Tenants erfolgt zu einem späterem Zeitpunkt in den Cross Tenant Access Settings.

Global Secure Access Einstellungen

Um die Einschränkungen nutzbar zu machen, müssen wir noch zwei weitere Schalter in der GSA Service Konfiguration umlegen. Dafür navigieren wir einmal Global Secure Access > Settings > Session Management und legen aktivieren die Funktionen “Enable Tenant Restrictions for Entra ID…” & “Enable CA Signaling for Entra ID…”.

Aktivieren der Tenant Restrictions

Aktivieren von Adaptive Access

Der erste Schalter ermöglicht grundsätzlich die Nutzung der Tenant Restrictions mit dem GSA-Client. Die Konfiguration dieser Einschränkungen erfolgt später in den Cross-Tenant Access Settings. Der zweite Schalter sorgt dafür das wir den GSA Client als vertrauenswürdiges Netzwerk klassifizieren können. Dies ist zwar für die Tenant Restrictions nicht zwingend erforderlich, wird aber in dem zweiten Teil des Artikels relevant.

Einrichten der Tenant Restrictions

Nun kann die Konfiguration der expliziten Einschränkungen erfolgen. Dafür navigieren wir zu dem Entra ID Menüpunkt ”Identity” > “External Identities” > “Cross-tenant access settings”, wechseln dort in den Reiter “Default Settings” und klicken auf “Edit tenant restrictions defaults“. Hier wählen wir den Radio Button “Block access“ unter “External User and groups“ aus und setzen denselben auch bei “External Applications“.

Ab diesem Zeitpunkt können Benutzer, welche wir im Traffic Profil aktiviert haben und die den GSA-Client installiert haben, sich nicht mehr an fremden Tenants anmelden. Da wir den Client noch nicht installiert haben, ist die Einschränkung noch nicht aktiv.

Tenant Restrictions einrichten

Berechtigte Ausnahmen definieren

Vielleicht gibt es Tenants auf die auch die entsprechend limitierten User zugreifen sollen. Diese können abweichend von den soeben definierten Default Settings pro Partner-Tenant konfiguriert werden. Also gehen wir wieder zum Entra ID Menüpunkt “Identity” > “External Identities” > “Cross-tenant access settings”. Dort können wir unter “Organizational settings“ eine neue Organisation hinzufügen.

Nach dem Hinzufügen des Tenants kann eine vom Standard abweichende Konfiguration hinterlegt werden. Wir wollen für eine Subgruppe den Login und die Nutzung der Ressourcen in dem Tenant ermöglichen. Dafür klicken wir auf den Menüpunkt “Inherited from Default“ unterhalb von “Tenant restrictions“ und passen dort die Einstellungen für diesen Tenant an.

Wir setzen den Radio Button “Allow Access” in “External users and groups“ + “External applications” auf Allow access und hinterlegen die Gruppe in der “Applies to“ Einstellung.

GSA-Client

Ich gehe davon aus das der Global Secure Access-Client bald ein fester Bestandteil von Windows wird und es kein Deployment der Applikation mehr braucht. Solange das noch nicht der Fall ist, können wir den Global Secure Access Client für Windows im Entra Portal unter “Global Secure Access“ > “Connect” > “Client Download” herunterladen. Dort finden wir auch die Downloads / Links für die anderen unterstützten Betriebssysteme.

Download des Global Secure Access Clients

Damit der Client funktionieren kann, ist mindestens ein Hybrid Join erforderlich. Die Installation ist schnell erfolgt. Es gibt ein paar andere Voraussetzungen, die ich nach der Installation auf einem Testclient im Lab durch die im GSA-Client integrierten “Advanced Diagnostics“ ermitteln und behandeln konnte. In dem integrierten “Health Check” werden die Voraussetzungen und Funktionen validiert und eine verknüpfte Hilfeseite hilft beim Lösen der ermittelten Probleme.

Bei mir im Lab musste ich im Lab musste ich auf dem Client IPv4 als präferiertes Protokoll hinterlegen (IPv6 ist zum jetzigen Zeitpunkt noch nicht unterstützt) und im Edge Browser das QUIC-Protokoll deaktivieren.

Healt Check im Global Secure Access Client

Nachdem ich diese beiden Einstellungen angepasst habe, ist der GSA-Client verbunden. Das der Traffic z.B. bei der Nutzung des Teams Clients über den GSA-Client läuft, lässt sich auch über den Traffic Analyzer (der sich ebenfalls in den Advanced Diagnostics findet) nachvollziehen.

Netzwerk-Verkehr im GSA Client einsehen

In produktiven Umgebungen sollten sich Administratoren auch mit dem Hardening des Clients beschäftigen, um ein Umgehen der Maßnahme durch die User zu unterbinden. In dieser Community-Sammlung findet sich eine gute Zusammenstellung der möglichen Maßnahmen Harden Windows GSA | Global Secure Access Community Resources Hub (und viele andere gute Ressourcen).

Ergebnis

Nachdem wir nun die Basis-Konfiguration im Global Secure Access Service vorgenommen haben, die Einschränkungen in den Tenant Restrictions definiert haben und den GSA Client installiert haben, können wir das Ergebnis validieren. Ich kann auf dem Client nun weiterhin innerhalb meines Tenants die freigegebenen Applikationen nutzen. Wenn ich aber z.B. in einer InPrivate Session oder einem Edge Gast-Profil versuche mich mit einem fremden Account in einem fremden Tenant einzuloggen bekomme ich eine einigermaßen Anwenderfreundliche Fehlermeldung

Fehlermeldung bei dem Versuch auf einen blockierten Tenant zuzugreifen

In dem zweiten Teil dieses Artikels werden wir die Möglicheit einschränken das der firmeneigene Account in fremden Tenants als Gast arbeiten kann.

Disclaimer

Ich möchte noch einmal betonen das der hier gezeigte Ansatz natürlich ohne zusätzliche Maßnahmen nicht effektiv vor ungewolltem Datenabfluss schützt. Hiermit behandle ich das spezifische Risiko das Daten in dritte Tenants abfließen. Ohne weitere Maßnahmen finden die Mitarbeiter mannigfaltige andere Möglichkeiten Daten zu extrahieren.

Wenn man die gezeigte Maßnahme mit anderen Einschränkungen für den Internetzugriff Applikationen und Datenträgern kombiniert, kann der Ansatz aber eine Ansatz für eine Isolation sein.

Ich würde jederzeit andere Maßnahmen wie die Nutzung von “Data Loss Prevention” präferieren. Derartige Konfigurationen sind aber häufig mit viel Aufwand und weiteren Lizenzkosten verbunden, weshalb die hier beschriebene Methode eine Station auf dem Weg zu einer ganzheitlichen Lösung sein kann.

Ich möchte mit dem beschriebenen Weg aber vor allen Dingen verdeutlichen, wie einfach der Einstieg in die Nutzung von Global Secure Access ist. Dieser gezeigte Isolations-Ansatz kratzt nur an den Möglichkeiten, die sich mit der Nutzung ergeben. Die entsprechend behandelten User und Clients erhöhen durch diese (Lizenz-)kostenneutrale Ergänzung ihre Verbindungssicherheit und das Unternehmen kann mit Hilfe von Conditional Access auf dieser Basis Conditional Access Richtlinien effektiver gestalten.

Personen, die sich damit detaillierter auseinandersetzen wollen empfehle ich als Informationsquelle neben den offiziellen Microsoft Docs (What is Global Secure Access? - Global Secure Access | Microsoft Learn ) einmal durch die Artikel von Chris Brumm zu stöbern der das Thema ausführlich beleuchtet ( u.a. hier: Global Secure Access in Conditional Access | )