Geräte, die sich zunehmend außerhalb des Netzwerks befinden, können zumindest via VPN, Multifaktor-Authentifizierung (MFA) und Zertifikaten einigermaßen vertrauensvoll zurück ins Firmennetz, wo sie auf Anwendungen und Ressourcen zugreifen. Doch spätestens, wenn die Anwendung, Teile der Infrastruktur oder die Daten selbst nicht im internen Netzwerk sind, ist VPN zumindest unelegant.

 Die Sache hat jedoch einen Haken: Die VPN-Konfiguration wurde einmal – vermutlich mit Zertifikat – auf das Smartphone oder den PC gespielt, um den Rückkanal ins Firmennetz zu erlauben. Selten prüft jemand, ob das Zertifikat aber zum Gerät passt, ob es über Wege extrahiert wurde oder ob das Gerät noch bei dem Benutzer, der es ursprünglich in Betrieb nahm, im Einsatz ist. Gleiches gilt hinsichtlich der vorgesehenen Nutzung des VPN-Tunnels: Folgt diese den vorgesehenen Wegen oder gibt es dabei Anomalien?

Agieren alle Geräte, Benutzer, Apps und Ressourcen in der Cloud, sind Anomalien leichter erkennbar und die Überprüfung des Normalzustandes einfacher. Dadurch ist ein Lernvorgang möglich, der den korrekten und vertrauensvollen Zugriff mit Gewissheit attestieren oder Risiken aufzeigen kann. Nur wenn sich überprüfen lässt, dass gewisse Rahmenbedingungen für den Zugriff gegeben sind, und zwar abhängig davon, auf was zugegriffen werden soll, ist beispielsweise das Öffnen der Mailbox von einem E-Mail-Client auf einem Rechner außerhalb des Firmennetzwerks zu erlauben. Das Mindset dahinter ist "Zero Trust" – und folgt dem Ansatz, den Zugriffskontext eines Akteurs genau zu beleuchten und anhand der Prüfungsergebnisse eine Entscheidung zu treffen: Die Mailbox darf geöffnet werden oder sie bleibt zu.

Prüfen lassen sich dabei zahlreiche Aspekte: Ob der Benutzer bekannt ist und MFA bei der Anmeldung vollzogen hat, ob das Gerät geläufig ist oder sogar als "gesund" gilt, ob Benutzer und Gerät sich anhand von IP- oder GPS-Daten einer Region zuordnen lassen, die dem tatsächlichen Arbeitsort entspricht, ob die Zugriffszeit und die Arbeitsmuster über mehrere Anwendungen hinweg dem normalen Muster des Mitarbeiters entsprechen und ob die Anwendung, die auf Daten zugreift, Anlass zur Sorge gibt.

Basieren Anmeldung und Zugriffskontrolle im internen Netz auf dem Kerberos-Protokoll, ist die Umsetzung von Zero Trust mit klassischen Mitteln schwierig: Kerberos und NTLM besitzen keine Mechanismen, um einen Zugriffskontext zu evaluieren, bestenfalls noch das Gerätekonto. und die normale Ticketlebensdauer beträgt auch mehrere Stunden, bevor eine Neuprüfung des Kontexts möglich ist. Mit modernen Protokollen sind die Vorzeichen anders: Mit Tools wie Mobile Device Management (MDM), Identity Providern und Möglichkeiten in Webprotokollen zur Interaktion mit dem Benutzer lässt sich mehr und vor allem Dauerhaftes erreichen. Denn Access-Token im OAuth2-Standard sind im Regelfall nur eine Stunde gültig, wonach ein Akteur mit eingehender Neuprüfung des Zugriffskontexts ein neues Token erlangen muss. Am Ende geht es um Risikominimierung, Schutz vor unerlaubten Zugriffen und Datenabfluss, bei gleichzeitiger Wahrung der Produktivität von mobilen oder hybriden Mitarbeitern.

In der Microsoft-Cloud ist das Zero-Trust-Konzept in vielen Komponenten eingearbeitet. Die Schaltzentrale, die im Zero-Trust-Umfeld sowohl den "Policy En- forcement Point" (PEP) als auch "Policy Decision Point" (PDP) einnimmt, ist Conditional Access (CA). CA ist Teil des Token-Services, der moderne Zugriffs-Token für SAML-, OIDC- und OAuth2-Anwendungen, die in Azure AD (AAD) integriert sind, aushändigt [1]. Jeder, der auf eine Ressource wie eine Exchange-Mailbox zugreifen will, die im Azure AD integriert ist, braucht ein Token vom AAD – und das wird von Conditional Access gegengeprüft.

Vor dem Aushändigen der Zugriffs-Tokens für verbundene Ressourcen erfolgt die Prüfung des Zugriffskontexts. Das AAD selbst kann das Benutzerkonto, Gruppenmitgliedschaften und Rollenzuweisungen des Benutzers in Betracht ziehen. Mithilfe der Identity-Protection-Funktion im AAD sind erweitere Risikobewertungen für das Benutzerkonto selbst oder den konkreten Anmeldevorgang möglich. So sperrt AAD beispielsweise den Zugriff von Tor-Brow­sern, Benutzern, die laut IP-Adresskennung von zwei weit entfernten Orten nahezu gleichzeitig Zugriffstoken erfragen, oder Benutzerkonten, deren Passworte vermeintlich im Dark Web aufgetaucht sind.

Neben Identity Protection bedient sich das AAD weiterer Daten aus umliegenden Systemen. So kommt der Compliance-Status des Geräts aus Intune, das dem Gerät Übereinstimmung mit der Unternehmenskonfiguration und Gesundheit bescheinigen kann. Aus dem Windows-AD können Informationen zu Geräten mit klassischer Domänenzugehörigkeit übermittelt werden – dann sind die Geräte zumindest "bekannt", wenn auch nicht glaubwürdig auf konforme Konfiguration überprüft. Aus Microsoft Defender for Endpoint kommen aktuelle Gefährdungsinformationen für Endgeräte hinzu.

Mit diesen Prüfungen formen Administratoren Regeln, die den Zugriff beschreiben: Etwa "Mitarbeiter dürfen mit Outlook auf ihre Mailbox zugreifen, wenn Sie von einem zumindest bekannten oder verwalteten und konformen Gerät kommen" oder "Mitarbeiter, die der Gruppe "Ohne-Outlook" angehören, dürfen via Browser auf ihre Mailbox zugreifen, wenn sie von einem bekannten oder konformen Gerät kommen oder eine Multifaktor-Authentifizierung vorweisen können".

Wo möglich, lassen moderne Protokolle eine Interaktion zwischen Conditional Access und dem Benutzer zu – so muss sich CA nicht auf "Token ausstellen" oder "Token verweigern" beschränken. Ist das Vertrauen zum Endgerät des Benutzers nicht angemessen, erlaubt das Regelwerk Alternativen. Der Benutzer kann aufgefordert werden, MFA vorzuweisen, oder per Regel in den Cloudproxy von Microsoft gezerrt werden, der alle Downloads der Session sperrt und Datenabfluss verhindert. Der Mitarbeiter kann dann – nach Vorzeigen einer MFA-Methode – auf die Daten zugreifen, gleichzeitig stellt die IT aber sicher, dass keine Daten auf unbekannte Geräte abfließen. Für Apps und Workloads von Microsoft gibt es eine Möglichkeit, wenn Teile der Belegschaft keine konformen Geräte besitzen oder kein Smartphone der Firma nutzen dürfen. In diesem Fall verlangt die Unternehmens-IT per CA-Policy einfach MFA und die Nutzung einer Microsoft-App, die mit Intune-Konfiguration bestückt ist und Datenabfluss, Isolation und Copy-und-Paste regelt und einschränkt.

Zero Trust kann für diese Fälle bedeuten, dass der Zugriff nicht klassisch mit einem "Block" scheitert, sondern mit Einschränkungen der Benutzer-Session ein akzeptables und verwaltbares Risiko erreicht wird, wonach Mitarbeiter dann ihre Arbeit verrichten.

Conditional Access basiert auf Regeln (Policies), mit denen Sie erlaubte Zugriffsmuster und die Folgen wie Zugriff, Verweigerung oder Einschrän­kungen beschreiben. Da das Werkzeug eine Vielzahl zu überprüfender Datenpunkte zur Verfügung stellt und Sie zahlreiche unterschiedliche Anforderungen, Benutzergruppen und Anwendungen unter einen Hut bringen müssen, kann das Regelwerk schnell komplex werden.

Je eher Sie sich im Klaren darüber sind, welche Arbeitsmuster, Anwendungen und Geräte Sie in welcher Kombination gestatten wollen, desto schärfer können Sie den Regelsatz formen. Wenn Sie die Regeln vereinheitlichen können, ist das sogar noch besser, denn unzählige Ausnahmen und Sonderkonfigurationen für kleine Benutzerpopulationen erschweren Troubleshooting und Fehlersuche.

Sind Sie in der Lage, ein Dreigestirn aus Security, Anwendungsbesitzern und dem Produktivitäts- oder Arbeitsplatzteam zu formen, das über die erlaubten und zu vermeidenden Muster entscheidet, haben Sie viel entscheidenden Input erhalten: Security kann etwas zum Risiko und Schutzbedarf der Ressourcen sagen, die Sie mit einer CA-Regel schützen wollen. Anwendungsbesitzer helfen bei der Klassifizierung der Anwendung und der Analyse der zu erwartenden Daten und Informationen, die darin zum Einsatz kommen. Die Kollegen, die den Arbeitsplatz, die Werkzeuge und die Tools für die tägliche Arbeit betreuen, haben wichtigen Input zu Produktivität, SSO-Anforderungen (Single Sign-on) und der Nutzung der App in Sachen Häufigkeit, Endgeräte und Lokationen. Aus den Hinweisen der drei Gruppen ergibt sich im Bestfall eine Einstufung pro Anwendung, die das Regelwerk oder die Einschränkungen der Nutzung der Anwendung vorgibt.

Hieraus entwickelt sich dann schnell eine unternehmensweite Einstufung, die die Zuordnung von Anwendungen zu CA-Regeln erleichtert: Wenn sich das Dreigestirn und die IT einig sind, können kritische Anwendungen und Daten immer einem bestimmten Zugriffsmuster folgen. Beispielsweise öffnet ein vertrautes, gesundes Gerät plus MFA alle Türen und weniger kritische Anwendungen sind nur von vertrauten Geräten oder über den Cloudproxy plus MFA erreichbar. Aus dieser groben Klassifizierung mit wenigen Regeln lassen sich Szenarien für die Alltagsanwendungen der meisten Mitarbeiter erstellen – wobei eine CA-Regel für die Klassifizierung denkbar ist, in der sich mehrere Apps finden.

Ausnahmen sollten Sie gesondert betrachten: Gibt es zum Beispiel Daten und Apps, die nicht-vertrauten Geräten zugänglich sein sollen? Wenn ja, ist es gegebenenfalls legitim, als Unternehmen die Mitarbeiter zu bitten, vertraute Apps von Microsoft auf das – womöglich private – Smartphone zu installieren, um zusätzliche Szenarien abzubilden? Sollen B2B-Gäste prinzipiell niemals auf kritische Anwendungen und Daten zugreifen können oder ist der Zugriff mit gewissen Einschränkungen legitim? Eine weitere Ausnahme wäre etwa die Frage, wohin sich Admin-Konten verbinden dürfen.

Die Kunst der richtigen Klassifizierungen liegt dabei in der Mitte zwischen "so wenige Regeln wie möglich", um Übersichtlichkeit und klare Regeln zu wahren, und "so viele Regeln wie notwendig", um allen relevanten Ausnahmen gerecht zu werden. Conditional Access ist das Werkzeug, mit dem Sie Policies für den Zero-Trust-Betrieb definieren und umsetzen – eine klare Struktur und Direktive hilft, ein striktes Regelwerk zu schnüren, das nur für relevante Ausnahmen ausfranst.

Damit CA seine Arbeit erledigen und Flexibilität in der Erstellung der Regeln bieten kann, müssen Sie dem PDP zumindest die Daten zur Verfügung stellen, die Sie auch in den Regeln einsetzen wollen. Denn hierin liegt die Stärke von Zero Trust: Die Schnittstellen, die weitere Daten, Erkenntnisse und Informationen zur Bewertung miteinbeziehen, schaffen das notwendige Vertrauen.

Zumindest die Benutzeridentitäten und Gruppen- und Rollenzuweisungen sowie Geräte aus dem AD sind schonmal ein guter Start – und Sie erkennen diese als "Hybrid Azure AD Joined"-Geräte. Wollen Sie Smartphones oder Geräte ohne Domänenzugehörigkeit anbinden, müssen Sie diese mit Microsoft Intune integrieren und verwalten. Damit können Sie dann Geräte mit macOS, Android und iOS wiedererkennen und den Status der Compliance zwischen Intune und CA austauschen lassen – womit CA "Require device to be marked as compliant" anwenden kann.

Existieren vertrauenswürdige Arbeitsorte, die sich über IP-Subnetze oder GPS-Lokationen definieren lassen, hinterlegen Sie diese Orte in Conditional Access als "Trusted Location". Damit kann dann CA anhand der IP-Adresse verschiedene Regeln anwenden und beispielsweise auf MFA oder die Prüfung des Gerätestatus verzichten. Als temporäre Ausnahmenbehandlung ist der IP-Check sinnvoll, im Sinne des Zero-Trust-Gedankens sind IP-Subnetze aber zu leicht zu manipulieren, als dass sie sich sicher überprüfen lassen.

Für sichere Administration können Sie CA auch für Admin-Workstations erzwingen lassen. Dann prüft CA, ob ein Admin für die Administration nicht nur von einem vertrauten, zulässigen Gerät aus arbeitet, sondern ob es sich um ein ganz bestimmtes Device handelt. Diese Prüfung heißt "Device Filters" und erlaubt, Geräte als "Secure Admin Workstation" oder "Privileged Admin Workstation" zu markieren. Nur die erfolgreiche Prüfung "Benutzer ist in Admin-Rolle Exchange Service Administrator und auf einem vertrauten, compliant Gerät, und das Gerät ist markiert als PAW" führt dazu, dass der Zugriff auf Exchange erlaubt ist [2].

Je mehr Daten Sie Ihrem PDP als Input und dem PEP zur Risikominderung zur Verfügung stellen, desto mächtiger wird der Werkzeugkasten, mit dem Sie Vertrauen überprüfen oder gegebenenfalls durch Restriktionen oder Überprüfungen herstellen. Zur Risikominderung für Szenarien in der Microsoft-Cloud ist vor allem wichtig, dass Sie eine MFA- und Strong-Credential-Strategie sowie Self-Service-Password-Reset im Fall von Kontendiebstahl einsetzen. Wenn Sie tiefer in der Cloud aus Redmond stecken, sind limitierte Sessions und Überprüfungen durch den Cloud Access Broker ein weiteres, gutes Werkzeug.

Ein neues Konzept, das bereits in einigen Microsoft-Anwendungen im Einsatz ist, erlaubt noch schnellere Reaktionen auf Vertrauensbrüche. Dienste können so eine tiefere Integration in die Erkenntnisse von Azure AD und Conditional Access erlangen. Mithilfe eines Eventabonnements erfahren Anwendungen, dass ein Benutzer gesperrt wurde, einem Risiko ausgesetzt ist oder von einem anderen Ort arbeitet. Die Anwendung kann dann sofort nach Eintreffen des Events die Zugriffstoken invalidieren und den Benutzer zurück zum Azure AD schicken, um ein neues zu beantragen.

Das reduziert die Zeit zwischen zwei CA-Prüfungen bei der Token-Ausstellung, in der das Token gültig ist und keine Zero-Trust-Prüfung stattfinden kann. Microsoft nennt das "Continuous Access Evaluation" [3]. Diese Technologie ist bereits in Exchange, Teams und SharePoint integriert und soll mittelfristig anderen Herstellern als Standard angeboten werden.

Zero Trust beginnt mit der neuen Denkweise, wächst mit dem Schaffen einer Datenbasis für Vertrauensentscheidungen und gedeiht mit einer Kombination aus Decision- und Enforcement Points. Bei Microsoft nimmt Azure AD mit Conditional Access diesen Platz ein – und bedient sich weiterer Komponenten wie der Geräteverwaltung, Risikobetrachtung oder der User-Rollen.

Längst ist das System über das Stadium des MFA-Erzwingers hinausgewachsen und bildet komplexe Regelsätze ab, die Zero Trust nicht nur ermöglichen, sondern auch flexible Nutzung für kritische Daten, Dienste und Anwendungen über Office 365 hinaus bieten.