Zero Trust ist keine spezifische Maßnahme, sondern ein fortlaufender Prozess. Microsoft nennt es eine Reise, die nicht wirklich endet. Warum eine Reise? Weil es stetig etwas zu entdecken gibt: Bestehende Technologien werden kritisch hinterfragt und neue Ansätze geprüft. Ein Kreislauf, der sich ständig wiederholt.

Zwei Punkte stellen dabei besondere Herausforderungen dar: Zum einen das Bewusstsein, dass bei Zero Trust, speziell im Zusammenhang mit Identitäten in Entra ID, der Zugriff auf besonders sensible Bereiche über das Internet erfolgt. Das verändert die Spielregeln. Zum anderen ist da die Denkweise vieler IT-Verantwortlicher, geprägt durch jahrzehntelange Tätigkeit in klassischen On-Premises-Umgebungen. Dort sind beispielsweise Domänencontroller durch Firewalls geschützt. Die Identitäten sind somit verhältnismäßig gut abgesichert. In Entra ID sieht dies anders aus, hier ist ein Umdenken erforderlich, denn hier ist die Identität der neue Perimeter.

Insbesondere administrative Konten, ausgestattet mit umfassenden Rechten, sind von kriminellen Aktivitäten bedroht. Daher ist für diese Accounts ein Höchstmaß an Sicherheit unerlässlich. Genau hier setzen die Szenarien an, die wir betrachten. Das Ziel soll sein, mit Entra ID ein Sicherheitsniveau zu erreichen, das On-Premises-Produkte übertrifft.

Der Werkzeugkasten in Entra ID ist hierfür umfangreich ausgestattet, eines der zentralen Tools darin: Conditional-Access-Policies. Sie gehören zu den mächtigsten Steuerungsinstrumenten, die Ihnen als Admin zur Verfügung stehen. Damit legen Sie genau fest, wer unter welchen Bedingungen auf welche Ressourcen zugreifen darf. Ein Mechanismus, der für Admin-Konten besonders viel Sinn ergibt. Möglich wird das, weil bei jeder Anmeldung an Entra ID beziehungsweise bei der Nutzung von Anwendungen eine Vielzahl von Signalen fließt, die dann im Conditional-Access-Policy-Regelwerk zur Zugriffsentscheidungen beitragen: Von welchem Gerät stammt die Anfrage? Von welchem Standort? Auf welche Anwendung? Und einige Aspekte mehr.

So lassen sich vielfältige Szenarien umsetzen: Ein Administrator darf nur dann auf das Entra Admin Center zugreifen, wenn er sich im Firmennetzwerk und von seiner autorisierten Workstation anmeldet. Befindet er sich außerhalb, zum Beispiel in einem Cafè, und arbeitet er mit einem Smartphone, wird die Anfrage abgelehnt. Oder Mitarbeiter des Betriebsrats nutzen Standard-MFA mit der Authenticator App. Möchten sie jedoch auf besonders sensible Anwendungen mit Mitarbeiterdaten zugreifen, kann eine zusätzliche Bedingung greifen, beispielsweise die Verwendung eines FIDO2-Keys für stärkere Authentifizierung oder eine Authentifizierung bei jedem Zugriff auf die Anwendung. Eventuell im Browsercache befindliche Zugriffstoken bleiben dabei außen vor. Das sind nur zwei Beispiele, Conditional Access ist noch deutlich mächtiger und bildet das Herzstück einer dynamischen und kontextbezogenen Zugangskontrolle.

Um dieses Beispiel weiter zu konkretisieren, schauen wir uns an, welche Konfigurationen erforderlich sind, um eine Anwendung speziell abzusichern. Wir bleiben hier beim Betriebsrat und stellen uns vor, dass bei jedem Zugriff auf die besagte Anwendung eine starke MFA-Methode notwendig sein muss. In diesem Fall passwortlos und mit einem Passkey – und auch wenn der Benutzer die Anwendung eben erst geschlossen hat und sie direkt wieder aufruft, soll trotzdem eine erneute Authentifizierung erfolgen.

Im praktischen Einsatz ist das übrigens gar nicht so abwegig: Ein Mitarbeiter schließt das Browserfenster und verlässt den Arbeitsplatz, ohne den PC zu sperren. Ein Kollege setzt sich an den Rechner und öffnet den Browser mit der zuletzt benutzten Anwendung. Session-Token, die unsere Arbeit erleichtern, werden hier zum unfreiwilligen Mittäter, denn alles für den Zugriff auf die Anwendung Erforderliche hat der Browser im Zwischenspeicher griffbereit. Genau das möchten wir mit unserer CA-Policy verhindern. Wir navigieren dazu im Entra Admin Center zu den Conditional-Access-Policies. Diese finden Sie in der linken Navigationsleiste unter dem Punkt "Protection".

Im Conditional-Access-Dashboard stehen verschiedene Optionen zur Verfügung. Besonders relevant für unser Beispiel sind die Bereiche "Policies" und "Authentication Strengths". Letztere verdeutlichen, dass MFA nicht gleich MFA ist: So können Sie hier eigene Authentifizierungsstärken definieren, die dann anstelle der Standard-MFA zum Einsatz kommen. Bereits enthalten sind Voreinstellungen wie "Passwordless MFA" oder "Phishing-resistant MFA". An dieser Stelle lohnt sich der Hinweis auf eine neue Funktion in Entra ID: Die Microsoft-Authenticator-App lässt sich nun auch als FIDO2-kompatibler Passkey nutzen. Die Einrichtung ist unkompliziert, und der so definierte Passkey steht anschließend als eigene Authentication Strength zur Verfügung [1].

Zurück zu unserem Beispiel: Wir gehen davon aus, dass der Benutzer die MFA-Methoden für sein Konto bereits eingerichtet hat. Nur dann kann er die durch Conditional Access geforderten Authentifizierungen auch erbringen. Übrigens haben Anwender die Möglichkeit, ihre konfigurierten Methoden über die URL "https://mysignins.microsoft.com/security-info" jederzeit selbst einzusehen und zu verwalten. Eine neu definierte Authentifizierungsstärke oder die standardmäßig gesetzte wird dann Teil der gewünschten Conditional-Access-Policy.

In der Richtlinie widmen wir uns den Zuweisungen (Assignments) und wählen eine Sicherheitsgruppe aus, in der sich beispielsweise alle Mitglieder des Betriebsrats befinden. Im nächsten Schritt definieren wir unter "Target Resources" die Zielanwendung, in unserem Fall die Anwendung des Betriebsrats, die es zu schützen gilt. Zur Auswahl stehen hier alle Applikationen, die im Entra-ID-Tenant registriert sind. Den Abschnitt "Conditions" lassen wir unberührt; optional sind hier weitere Kriterien wie bestimmte Gerätetypen oder Standorte (etwa basierend auf IP-Adressen) definierbar, um die Wirkung der Richtlinie noch genauer zu fokussieren.

Der entscheidende Bereich liegt bei "Access Controls", genauer gesagt unter "Grant". Dort legen Sie die gewünschte MFA-Methode fest. In der Auswahl erscheinen alle zuvor definierten Authentication Strengths – inklusive benutzerdefinierter Optionen wie etwa einem Passkey, der im Vorfeld eingerichtet wurde.

Greift ein Anwender auf die Anwendung zu und befindet sich innerhalb des Geltungsbereichs der Richtlinie, muss er die definierte Authentifizierungsmethode bedienen, um Zugang zur Anwendung zu erhalten. Die Abfrage der neuen MFA-Stärke findet in jedem Fall statt, selbst wenn sich der Benutzer erst kürzlich an seinem Rechner angemeldet und dabei seine standardmäßige MFA verwendet hat.

Damit die zweite Anforderung unseres Beispiels erfüllt ist, nämlich die Authentifizierung bei jedem Zugriff auf die Anwendung, bleiben wir direkt in der Policy und orientieren uns ebenfalls bei den "Access Controls", jetzt aber bei den Session-Optionen und wählen hier bei "Sign-In frequency" die Option "Every time". Das wars und eine deutlich verbesserte Absicherung der Zugriffe auf die Anwendung ist eingerichtet.

Conditional-Access-Policies eignen sich hervorragend, um mit verschiedenen Szenarien zu experimentieren und das Verhalten bei Anmeldungen oder Zugriffsversuchen zu testen. Eine separate Testumgebung ist dafür nicht zwingend erforderlich, auch im produktiven Umfeld lässt sich gefahrlos testen. Über gezielte Filterkriterien kann der Geltungsbereich der Richtlinie so eingestellt werden, dass nur einzelne Benutzer oder Gruppen im Scope der Richtlinie liegen.

Conditional-Access-Policies entfalten ihre Möglichkeiten besonders im Zusammenspiel mit anderen Zero-Trust-Technologien. Ein Beispiel hierfür ist der "Authentication Context" – eine Funktion, die zwar nicht im Mittelpunkt der Zero-Trust-Funktionspalette steht, aber dennoch eine leistungsstarke Ergänzung darstellt. Conditional Access spielt dabei eine wichtige Rolle bei der Sicherung und interagiert mit anderen Technologien wie Privileged Identity Management (PIM).

PIM konzentriert sich auf die Absicherung administrativer Rollen und umfasst zwei wichtige Aspekte des Zero-Trust-Modells: Just-in-Time (JIT) und Just-Enough-Access (JEA). Insbesondere JIT bezieht sich auf die bedarfsgesteuerte und zeitlich begrenzte Gewährung von Zugriffsrechten in Entra ID und der Azure-Infrastruktur. Die Mitgliedschaft in einer Rolle oder Gruppe wird nur für die notwendige Dauer gewährt und danach wieder entzogen. Dies verhindert, dass Benutzerkonten dauerhaft hochrangige Berechtigungen besitzen, wie es beispielsweise bei der Gruppe der Domänenadministratoren im Active Directory der Fall ist. Permanente Mitgliedschaften in hochrangigen Rollen sollten in Entra ID definitiv der Vergangenheit angehören.

In PIM kann ein Administrator entweder permanent einer Rolle oder einer Sicherheitsgruppe zugewiesen sein oder die Rolle ist ihm als "eligible" zugeordnet. In letzterem Fall hat der Benutzer das Recht, die Rollenmitgliedschaft anzufordern. Die Dauer und die Art der Aktivierung der Rollenmitgliedschaft hängt von den für die jeweilige Rolle festgelegten Einstellungen ab. PIM ermöglicht eine kontrollierte Anforderung von Rollen. So lässt sich beispielsweise festlegen, ob bei der Aktivierung einer Rolle MFA erforderlich ist oder ob die Anforderung von einer dritten Person genehmigt werden muss. Falls Sie mit PIM nicht vertraut sind, finden Sie unter [2] eine gute Einführung in das Thema.

Wir erweitern die PIM-Funktion um Conditional Access, um ihre Wirksamkeit zu erhöhen. Der Schlüssel hierzu liegt im bereits erwähnten "Authentication Context". Im Wesentlichen handelt es sich um eine Zeichenkette, die Sie sich wie einen "Tag" oder einen Bezeichner vorstellen können. Diese definieren Sie im Conditional-Access-Dashboard in der linken Funktionsleiste. Das Hinzufügen eines "Authentication Context" ist weitestgehend selbsterklärend.

Ein mögliches Anwendungsszenario könnte folgendermaßen aussehen: Sie möchten die Aktivierung einer PIM-Rolle an bestimmte Bedingungen knüpfen, beispielsweise daran, dass sie nur auf bestimmten Gerätetypen genutzt werden darf. Konkret ließe sich beispielsweise verhindern, dass Admins Conditional-Access-Policies vom Smartphone aus bearbeiten. Ein durchaus nachvollziehbarer Ansatz, denn diese Richtlinien bilden das Rückgrat Ihres gesamten Identity-Setups und ein einziger Tippfehler kann schwerwiegende Auswirkungen für alle Benutzer im Tenant haben.

Voraussetzung ist, dass die entsprechenden Administratoren in PIM bei der Rolle "Conditional Access Administrator" als "eligible" zugewiesen sind. Nun geht es darum, deren Einstellungen anzupassen. Hierzu navigieren wir zu der gewünschten Rolle, in unserem Beispiel "Conditional Access Administrator", und öffnen die Settings. Unter der Option "On activation, require" stehen drei Auswahlmöglichkeiten zur Verfügung:

- None: Die Aktivierung erfolgt ohne zusätzliche Authentifizierung.

- MFA: Eine klassische Multifaktor-Authentifizierung ist gefragt.

- Authentication Context: Hier lässst sich ein spezifischer Authentifizierungskontext angeben.

In unserem Beispiel haben wir den Authentifizierungskontext auf den Namen "Admin compliant" festgelegt. Der Name ist frei wählbar, muss dann aber hier als Option selektiert werden. Eine Listbox zeigt alle im CA-Dashboard definierten Kontexte.

Damit wird die Verbindung zur entsprechenden Conditional-Access-Policy bei Aktivierung der Rolle hergestellt. Führt die Richtlinie beispielsweise zu einer Zugriffsbeschränkung, schlägt auch die Aktivierung der Rolle fehl – ein gezielter Schutzmechanismus, der zusätzliche Sicherheit schafft. Was jetzt noch bleibt, ist die Konfiguration in der Conditional-Access-Policy, damit diese auslöst, wenn eine Rollenaktivierung in PIM erfolgt. Navigieren Sie hierzu in der CA-Policy zu den "Assignments" und der Option "Target". Über eine Listbox definieren Sie dort das Ziel der Policy. Hier wählen Sie nun den "Authentication context" aus, der in unserem Beispiel "Admin compliant" heißt. Dabei stehen Ihnen alle definierten Bezeichner (Tags) zur Verfügung, für den Fall, dass Sie mehrere hinzugefügt haben. Die Wahl sollte auf denjenigen fallen, den Sie in PIM bei der Rolle gewählt haben.

Damit haben wir das Ziel (bei den Targets) eingerichtet. Als nächstes sind die auszuschließenden Geräte zu definieren, oder andere Bedingungen, die Sie als Administrator für wichtig erachten. Wir konzentrieren uns auf die "Conditions" und dort auf die Option "Device platforms". An dieser Stelle wählen wir alle Geräteplattformen aus, die wir ausschließen möchten: "iOS", "Android" und "Windows Phone". Da unsere Policy eine sogenannte Deny-Policy ist, bedeutet das, dass der Zugriff auf die in der Bedingung genannten Elemente nicht gestattet ist. Daher müssen wir bei den "Access Controls" noch "Block access" auswählen.

Ein Administrator wurde damit der PIM-Rolle "Conditional Access Administrator" als berechtigt (eligible) zugewiesen. Die Aktivierung der Rolle löst dann den "Authentication Context" aus, der Teil der Signalverarbeitung in Entra ID ist. Dadurch wird eine CA-Policy ausgewertet, die auf den Kontext reagiert und anhand ihrer Kriterien prüft, ob alle Bedingungen erfüllt sind. Ist dies nicht der Fall, wie im Beispiel beim Einsatz eines Smartphones, schlägt der Vorgang fehl.

In unserem Beispiel haben wir die Definition für die Rolle der "Conditional Access Administratoren" geändert. Was geschieht aber, wenn in einem Unternehmen für die Aktivierung einer Rolle unterschiedliche Vorgehensweisen gelten sollen? Ein Teil der Admins soll bei der Aktivierung MFA verwenden, für andere wiederum soll eine Conditional-Access-Policy, wie in unserem Beispiel, bei der Entscheidung helfen und so weiter. Wenn es nur eine Einstellmöglichkeit pro Rolle gibt, lassen sich mehrere Anforderungen so nicht umsetzen. Die Lösung hierfür bietet "PIM for Groups".

Auf diese Weise erstellen Sie Sicherheitsgruppen im Tenant als Cloud-only-Objekte und binden sie in PIM ein. Dort lassen sie sich wie Entra- oder Azure-Rollen verwalten – inklusive eigener Optionen zur Aktivierung pro Instanz. Jede eingebundene Einheit verfügt über individuelle Einstellungen zur Mitgliedschaftsaktivierung. Diese wiederum sind fest mit administrativen Rollen verknüpft. Auf diese Art lassen sich beliebig viele Konstrukte einbinden, wobei jede Instanz über eigene Konfigurationsmöglichkeiten verfügt. So lässt sich für eine Rolle mehrfach eine unterschiedliche Aktivierung definieren, da der Mechanismus stets über die zugewiesene Einheit mit ihren spezifischen Optionen erfolgt.

Es gibt noch einen weiteren Vorteil von "PIM for Groups". Über Mehrfachzuweisungen von Rollen zu einer Gruppe lassen sich mit einem Rutsch mehrere Rollen gemeinsam aktivieren, wenn diese der Gruppe zugewiesen sind, was mit PIM-Rollen allein nicht möglich ist. Gruppen in PIM sind somit auf jeden Fall einen Blick wert, so lassen sich ganz individuelle Szenarien umsetzen.

Wie erwähnt, ist der "Authentication context" eine Zeichenkette beliebigen Werts. Neben dem Einsatz in PIM leistet dieses Label auch andernorts im Zusammenspiel mit Conditional Access gute Dienste. Ein Beispiel hierfür sind die sogenannten "Protected Actions". Wie der Name bereits andeutet, handelt es sich dabei um schützenswerte Aktionen, die Sie im Bereich "Roles & Admins" im Entra Admin Center finden. Geschützte Aktionen umfassen aktuell die Tätigkeiten beim Bearbeiten von Conditional-Access-Policies, Einstellungen der Cross Tenant Settings und neuerdings das endgültige Entfernen von gelöschten Objekten, den sogenannten „Hard-Delete“. Es ist immens wichtig die Unterschiede beim Löschen von Elementen in Entra ID zu kennen. Aus diesem Grund widmen wir uns dem Thema später noch einmal. Wir schauen uns aber erst an, wie ein Authentifizierungskontext in diesem Zusammenhang den Administrator unterstützt.

Auf der Seite der schützenswerten Aktionen fügen wir eine weitere "Protected Action" hinzu, verbinden diese mit einem Authentication Context, der wieder bei den Conditional-Access-Policies referenziert wird, ähnlich wie beim PIM-Beispiel zuvor. Führt ein Administrator nun eine geschützte Aktion aus und ist diese mit einem "Label" versehen, feuert die dazugehörige CA-Policy. Auch hierbei werden alle Kriterien und Signale ausgewertet und eine Entscheidung getroffen, ob dieser Vorgang erlaubt ist oder in diesem Kontext eben nicht. Das ist eine weitere mögliche Einsatzfacette von Conditional-Access-Policies im Zusammenhang mit anderen Technologien in Entra ID. Mehr Details zu den Protected Actions finden Sie im Artikel unter [3].

Viele, aber nicht alle, Objekte landen im Papierkorb, wenn Sie diese aus dem Entra Admin Center löschen. Das handhabt Microsoft recht unterschiedlich und für einen Administrator ist es sehr wichtig, die Details zu kennen. Conditional-Access-Policies verschwinden sofort und unwiederbringlich, Sicherheitsgruppen ebenfalls. Microsoft-365-Gruppen sowie Benutzerkonten wiederum landen im Papierkorb. Dies bezeichnet Microsoft als "soft deleted" und diese Elemente landen erst nach 30 Tagen im digitalen Nirvana. Administrative Units werden auch soft deleted, hier gibt es aber keinen Papierkorb, sondern die Wiederherstellung muss über die Deleted-Item-API beziehungsweise die Graph-Schnittstelle erfolgen. Dadurch erleichtert Microsoft seinen Nutzern das Leben im Umgang mit gelöschten Objekten nicht unbedingt. Zumindest haben die Redmonder die Unterschiede gut dokumentiert [4].

Einmal endgültig gelöschte Objekte (hard deleted) lassen sich mit keinem Mittel wiederherstellen. Setzen Sie Tools ein, die diese Objekte von einem Backup wieder in den Tenant bringen, werden diese neu erstellt, was eine neue Objekt-ID mit sich bringt. Das ist die ID, auf die sich die Verwendung der Objekte bezieht, beispielsweise wenn Sie diese in Conditional-Access-Policies einschließen (include) oder ausschließen (exclude). Dort wird zwar immer der Name eingetragen, unter der Haube kommt aber die Object-ID zum Einsatz. Aus diesem Grund hat Microsoft nun für das manuelle Entfernen von Objekten aus dem Papierkorb die besagte Protected Action etabliert, was je nach administrativen Prozessen viel Sinn ergeben kann. Aber Vorsicht: Das betrifft nur das manuelle Entfernen der Objekte aus dem Papierkorb, besser gesagt von der Deleted-Item-API. Der automatische Vorgang, der nach 30 Tagen Objekte endgültig entfernt, bleibt davon unberührt.

Eine weitere sehr leistungsstarke Funktionalität sind "Access Reviews". Wer kennt das nicht: Benutzer treten Gruppen bei – und bleiben dann dauerhaft Mitglied. Genau hier setzen Access Reviews an. Diese lassen sich auf Ebene von Gruppen definieren und gestatten es, zu einem bestimmten Zeitpunkt eine Erinnerung auszulösen. Das lässt sich recht granular gestalten und reicht von einem Hinweis an das Gruppenmitglied oder den Owner, der dann entscheidet, ob der Zugriff noch nötig ist oder nicht, bis hin zur Integration Dritter, die an einem Entscheidungsprozess teilnehmen und über eine weitere Mitgliedschaft entscheiden.

Der Entscheidungsprozess hört sich mächtig an, und er ist es auch. Hier lassen sich mehrere sogenannte "Approver" für das Access Review einrichten, die dann über die Webseite "myaccess.microsoft.com" über die Mitgliedschaften in den Gruppen entscheiden. Dies gilt für einen bestimmten Zeitraum und während dieser Zeit kann jeder Approver seine Meinung kundtun und sein Urteil über Mitgliedschaften in den Gruppen fällen. Auch die Reaktionen anderer sind einsahbar, alles kommentiert versteht sich. Es lässt sich auch festlegen, was geschehen soll, wenn keiner der Approver reagiert und vieles mehr.

Das ist sinnvoll beispielsweise in umfangreichen Projekten, wenn häufig Mitgliedschaften in Gruppen wechseln. Das Gute hierbei: Die Benutzer, die über weitere Zugriffe entscheiden, sind keine Administratoren. Das Entra Admin Center wird hierzu nicht benötigt. Dieser Ansatz funktioniert sowohl per E-Mail als auch über die erwähnte Webseite "myaccess.microsoft.com". Das entlastet Admins, da diese Aufgaben beispielsweise in einem Projekt-office erledigt werden können. Sollten Sie mit dieser Funktion noch nicht vertraut sein, finden Sie unter [5] eine hilfreiche Einführung in das Thema.

Wir schauen uns eine interessante Möglichkeit der Access Reviews an, die im Umgang mit Gastkonten eine große Unterstützung bietet. Je nachdem, wie Sie die Möglichkeiten, neue Gastkonten einzuladen, in den Einstellungen für den Tenant konfiguriert haben, können beliebige Benutzer eine Einladung an externe Benutzer senden, die dann per E-Mail Zugriff auf den Tenant erhalten. Das lässt sich sogar derart erweitern, dass Gastbenutzer wiederum andere Gastbenutzer einladen dürfen und so weiter. Wie wahrscheinlich ist es hier, dass Gastkonten vergessen werden und somit ein Sicherheitsrisiko darstellen? Diese verwaisten und unnützen Konten werden auch "Stale Accounts" genannt, und es gibt eine Möglichkeit diese unnützen Altlasten mit Access Reviews sang und klanglos zu entfernen.

Wenn Sie über Access Reviews alle ungenutzten Gastkonten vollautomatisiert entfernen möchten, die seit 180 Tagen inaktiv sind, gehen Sie wie folgt vor. Sie finden die Access Reviews im Bereich "Identity Governance" im Entra Admin Center. Beim Erstellen eines neuen Reviews zeigt die erste Seite wichtige Informationen zum Umgang mit ungenutzten Gastkonten, wenn Sie bei "Review scope" die Option "Teams + Groups" ausgewählt haben, können Sie gezielt den Wirkungskreis des Access Reviews auf die Mitglieder dieser Gruppe legen. Es besteht aber auch die Möglichkeit, die Funktionalität mittels "All M365 Groups with guest user" auf den ganzen Tenant zu erweitern. Weitere Optionen an dieser Stelle sind selbsterklärend. Neben der Zeitspanne, die Gastkonten inaktiv sein müssen, um gelöscht zu werden, ist das Optionsfeld "Inactive users" besonders wichtig, da es sich gezielt auf ungenutzte Konten konzentriert.

Auf den Folgeseiten beim Erstellen des "Access Reviews" stoßen Sie auf weitere Optionen. Viele davon sind für das Entfernen von Gastkonten nicht relevant. Neben Startdatum und Wiederholungsintervall sind einige weitere Einstellungen wichtig: Auf der Seite "Review" müssen Sie einen "Reviewer" angeben. Dies kann ein beliebiges Konto sein, spielt aber in unserem Beispiel keine Rolle, da wir Gastkonten ohne Eingreifen entfernen möchten. Mit "Review recurrence" legen Sie den Wiederholungszeitpunkt fest, zu dem regelmäßig nach inaktiven Gastkonten gesucht wird. Auf der letzten Seite "Settings" aktivieren Sie zum Schluss die Optionen "Auto apply to resource" und "Remove access". Ein gutes Zeitfenster für ungenutzte Gastkonten sind übrigens 180 Tage. Es empfiehlt sich, die Einstellungen gründlich zu testen. Sollten trotzdem Gastkonten entfernt werden, die doch benötigt werden, haben Sie 30 Tage Zeit, diese aus dem Papierkorb wiederherzustellen.

Die wachsende Palette an Zero-Trust-Tools und die zunehmende Vernetzung von Technologien, wie zum Beispiel PIM und Conditional Access, bieten einerseits den Vorteil mit einer Fülle von Funktionen, andererseits besteht die Gefahr, dass ein Admin nach und nach neue Sicherheitsfunktionen hinzufügt. Das führt mitunter zu einem komplexen Setup, das die Administration und die Fehlersuche erschwert. Daher ist ein solides Konzept unerlässlich.

Zero Trust steht auch für Einfachheit. Es ist wichtig, den Gesamtkontext im Auge zu behalten und zu bewerten, ob bestimmte Probleme nicht einfacher gelöst werden können, insbesondere wenn Microsoft neue Funktionen veröffentlicht und eine Verknüpfung mehrerer Werkzeuge miteinander ist immer gut abzuwägen.