Jedoch muss es immer mindestens einen Global Administrator Account für den Tenant geben, um über alle Bereiche Kontrolle zu erlangen. Dieser Account wird als Break Glass Account oder auch Emergency Access Account bezeichnet. Es ist im Grunde nur ein Global Administrator Account, der besonders abgesichert bzw. konfiguriert wird. Es kann zusätzlich zum Break Glass Account auch 1-2 Administratoren (Microsoft empfiehlt dies auf maximal vier zu begrenzen) im Unternehmen die Global Administrator Rolle per PIM zugewiesen werden. Der Break Glass Account sollte nie produktiv benutzt werden, denn er ist – wie schon erwähnt – wirklich nur für den absoluten Notfall gedacht.

Wie stellt man jetzt also sicher, dass dieser Account jederzeit einsatzfähig ist und auch in 10+ Jahren noch verfügbar ist? Gehen wir die Accounterstellung mal Step-by-Step durch. Die nachfolgenden Punkte sollten möglichst auch in dieser Reihenfolge durchgeführt werden, um z.B. die Global Administrator Rolle erst nach Absicherung des Accounts zu vergeben.

Erstellung des Break Glass Accounts

Wir erstellen zunächst den eigentlichen Break Glass Account. Diesem generieren wir ein möglichst langes Kennwort über einen Passwortgenerator. Das Passwort kann bis zu 256 Zeichen lang sein und das sollten wir auch nutzen, denn das Passwort wird für den Zugriff später nicht benötigt. Es muss jedoch möglichst lang und komplex sein, um die Sicherheit auf ein Maximum zu erhöhen, denn der Account wird später aus allen Conditional Access Policys ausgeschlossen. Es wäre somit ein Login nur mit Username & Passwort möglich. Je nach Unternehmensgröße und Struktur kann auch ein zweiter Break Glass Account sinnvoll sein.

Zugriff auf den Account

Der Break Glass Account sollte möglichst nur von der höchsten Ebene der Unternehmensführung zugänglich sein (z.B. Geschäftsführer). Da der Account jedoch regelmäßig validiert werden muss, sollte diskutiert werden, ob z.B. zusätzlich der IT-Leiter und sein Vertreter gemeinsam für den Zugriff legitimiert werden. Denn die regelmäßige Prüfung des Accounts bindet Zeit bei diesen Personen. Die Legitimation z.B. beim Notar sollte dann natürlich nur von der Geschäftsführung geändert werden können. Es kann auch überlegt werden, dass der Zugriff für die Personen, die die Validierung durchführen, nur nach Anmeldung der Geschäftsführung mindestens 7 Tage vorher möglich ist. So wäre sichergestellt, dass nur die Geschäftsführnug im Notfall ohne Anmeldung Zugriff zum Account erlangt.

Account absichern und Zugangsdaten sicher aufbewahren

Da wir den Account aus allen Conditional Access Richtlinien ausschließen werden, muss der Zugriff möglichst gut abgesichert sein. Deswegen auch das 256 Zeichen lange Kennwort. Meine Empfehlung ist den Zugriff über einen FIDO2 Hardwareschlüssels sicherzustellen. Dieser Schlüssel wird nach Einrichtung als Authentifizierungsmethode im Break Glass Account im Tresor der Geschäftsführung, einem Bankschließfach, beim Notar oder einem ähnlich sicheren Ort für den Notfall aufbewahrt. Zusammen mit der PIN des Hardwaretokens – welcher ebenfalls an einem anderen sicheren Ort aufbewahrt werden sollte – kann sich so im Notfall Zugriff zum Tenant mit vollen Rechten verschafft werden. Vom Einsatz eines FIDO2 Schlüssel mit Fingerabdrucksensor rate ich dringend ab! Denn was passiert, wenn die Person, dessen Fingerabdruck auf dem Key gespeichert ist, plötzlich verstirbt? Man muss leider auch diesen Fall bedenken.

Meine Empfehlung ist der Token2 T2F2-PIN+/Dual (siehe Bild), da dieser über einen USB-A und USB-C-Anschluss verfügt und die PIN-Komplexität vorab konfiguriert werden kann. Aber auch die Yubikey 5 Serie ist eine gute Wahl.

Ich empfehle, zwei FIDO2 Schlüssel auf den Breaking Glass Account zu registrierten. Einer der Schlüssel wird z.B. im Tresor der Geschäftsführung (Sicherer Ort 1) hinterlegt und der zugehörige PIN in einem versiegelten Umschlag mit Datum und Unterschrift beim Notar oder einem Bankschließfach (Sicherer Ort 2). Der zweite FIDO2 Schlüssel kann dann im Tresor zusammen mit der PIN des ersten Schlüssels hinterlegt werden. Im Tresor kann dann die PIN von Schlüssel 2 zusammen mit dem Schlüssel 1 hinterlegt werden. So ist auch ein Hardwaredefekt redundant abgesichert und es ist stets sichergestellt, dass beide Aufbewahrungsorte für die zugreifende(n) Person(en) zugänglich sein müssen. Denn nur mit dem Schlüssel selbst ist kein Zugriff auf den Account möglich. Sollte der Zugriff für die Validierung des Break Glass Accounts an Angestellte des Unternehmens delegiert sein, ist sichergestellt, dass nur beide Personen zusammen auf den Schlüssel zugreifen können.

Ausschließen aus Conditional Access Richtlinien

Den Break Glass Account wird aus allen Conditional Access Richtlinien ausgeschlossen. Dies hat zwei Gründe:

1. Der Zugriff mit diesem Account soll jederzeit von Überall möglich sein. CA-Richtlinien würden einen uneingeschränkten Zugriff möglicherweise verhindern. Sollte es z.B. Richtlinien geben, die den Zugriff aus bestimmten Ländern generell regulieren, dann könnte der Ausschluss aus dieser Richtlinie diskutiert werden. Denn wieso sollte der Break Glass Account z.B. aus Russland zugreifen können, wenn sonst generell niemand im Unternehmen zugreifen kann? Es muss allerdings der zweite Punkt ebenfalls mit in diese Überlegung einbezogen werden.
2. Der Exclude aus den CA-Richtlinien ist zudem dafür wichtig, dass bei einer Fehlkonfiguration in einer CA-Richtlinie der Break Glass Account noch Zugriff hat. Dies versucht Microsoft zwar auch über deutliche Warnhinweise beim Ändern einer CA-Policy zu verhindern, es ist jedoch nicht zu 100% ausgeschlossen. Es besteht allerdings trotzdem die Möglichkeit, eine CA-Policy mutwillig so anzulegen, dass auch der Break Glass Account keinen Zugriff mehr zum Tenant hat. Denn bei jeder neuen Richtlinie muss der Exclude für den Breaking Glass Account gesetzt werden.

Da gerade dieses Thema sehr komplex sein kann, gehe ich an dieser Stelle nicht tiefer darauf ein.

Registrierung des FIDO2 Schlüssels

Um den FIDO2 Schlüssel im Account hinzuzufügen, müssen wir uns mit dem neu erstellten Account einloggen. Mit den Standardsettings im Tenant wird man nach dem Login mit Passwort dazu aufgefordert, den Microsoft Authenticator zu einzurichten. Um das zu verhindern, erstellen wir für den Account vor dem ersten Login einen TAP (Temprary Access Pass).

Um direkt in die passende Eingabemaske zu gelangen, loggen wir uns in einem Inkognito Tab über folgende URL ein: https://aka.ms/mysecurityinfo
Nach dem Eingeben des Usernamens in der Loginmaske, werden wir jetzt nicht zur Eingabe eines Passwortes aufgefordert, sondern der gerade erstellte TAP wird verlangt. Dies führt dazu, dass wir direkt mit einer starken Authentifizierung im Break Glass Account angemeldet sind und nicht dazu aufgefordert werden, den MS Authenticator einzurichten. Auch wird das gesetzte Passwort nicht benötigt.

Wir folgen den Schritten, um den FIDO2 Schlüssel hinzuzufügen. Es muss die PIN des Schlüssels definiert werden und der Schlüssel muss mehrfach berührt werden. Dies ist eine weitere Sicherheitskomponente der FIDO2 Schlüssel. So kann ein dauerhaft eingesteckter Schlüssel nicht remote missbraucht werden, da physischer Zugriff zum Schlüssel vorhanden sein muss.

Nachdem der Sicherheitsschlüssel hinzugefügt wurde und der TAP wieder gelöscht wurde, sehen die Authentifizierungseinstellungen des Break Glass Accounts in Entra wie folgt aus:

SSPR für Administratorkonten deaktivieren

Zu diesem Thema habe ich bereits einen eigenen Artikel veröffentlicht. Ich möchte an dieser Stelle lediglich auf diesen verweisen. Aus meiner Sicht ist Self-Service-Password-Reset in größeren Umgebungen für Administratorkonten zu deaktivieren, um die Sicherheit weiter zu erhöhen.

Accountzugriff überwachen

Als weitere Sicherheitsmaßnahme konfigurieren wir eine Benachrichtigung an alle Administratoren, welche ausgelöst wird, sobald einer der Break Glass Accounts ein Login Event auslöst. Dies sorgt dafür, dass auch bei Missbrauch des Break Glass Accounts dies nicht unbemerkt passieren kann und die Administratoren hellhörig werden und den Zugriff prüfen. Die Konfiguration ist leider etwas aufwendiger und benötigt einen Log Analytics Workspace. Wie dies konfiguriert wird, ist in folgendem Microsoft Learn Artikel erklärt: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#monitor-sign-in-and-audit-logs

Zuweisen der Global Administrator Rechte

Erst wenn der Account entsprechend gesichert und der Login geprüft wurde, weisen wir dem Account auch die Rolle Global Administrator zu. Der Break Glass Account erhält die Global Administrator Rolle als permanent Assignment und nicht per PIM! Wie die Rolle zugewiesen wird, wird hoffentlich bekannt sein.

Regelmäßige Validierung des Accounts

Wichtig ist natürlich, dass der Account auch jederzeit funktioniert. Da sich immer mal etwas unbemerkt in der Konfiguration ändern kann, muss regelmäßig überprüft werden, ob der Zugriff mit den FIDO2 Schlüsseln auch weiterhin funktioniert. Wenn der Anspruch ist, dass nur die Geschäftsführung Zugriff auf den Break Glass Account hat, ist dies natürlich recht aufwendig und bindet bei der Geschäftsführung entsprechend Zeit.

Folgende Punkte sollten bei einer Validierung durchgeführt werden:

• Vor der Validierung wahlweise das SOC-Team über die Validierung informieren, oder eben nicht .
  Wer das SOC-Team nicht informiert, prüft im gleichen Zuge, ob die Alarmierung zeitnah funktioniert und ob die restlichen Administratoren Alarm schlagen. Wer das nicht möchte, der meldet die Validierung vorab an.
• Der Zugriff auf den Break Glass Account sollte dokumentiert werden, damit auch ein erstmalig hinzugezogener Dienstleister oder neuer Geschäftsführer alle relevanten Informationen vorliegen hat.
• Ein Ablaufplan für die Validierung muss erstellt und mit Protokoll hinterlegt werden.
• Nach dem Zugriff und Test müssen die PINs der FIDO2 Schlüssel geändert werden und vor dem erneuten hinterlegen am sicheren Ort neu versiegelt werden.

Wann sollte die Validierung gemacht werden?

• Alle 90 Tage
• Wenn es maßgebliche Änderungen an der M365 Konfiguration gab (z.B. neue Conditional Access Policys).
• Wenn es neues Personal gibt, welches in den Prozess eingebunden werden soll.
• Wenn die Entra Subscriptions in der Organisation sich geändert haben.

Fazit

Die Absicherung des Break Glass Accounts ist zwar aufwendig, aber zwingend notwendig. Denn der Microsoft 365 Tenant enthält viele wichtige Unternehmensdaten und ein Zugriff auf diesen muss in jedem Fall möglich sein. Sie sollten als Verantwortlicher für Micorosft 365 das Thema wirklich ernst nehmen und zeitnah nach der Einführung (oder spätestens nachdem Sie meinen Artikel gelesen haben ) auf den Weg bringen.

Ich hoffe, ich konnte einen guten Weg für den Notfallzugriff auf Microsoft 365 skizzieren und für das Thema sensibilisieren.

Der Beitrag Best Practices – M365 Break Glass Account erschien zuerst auf M365 Blog - Julian Stabentheiner.

Eine gut funktionierende Namensauflösung bei den Microsoft 365 Diensten ist unumgänglich für einen reibungslosen Betrieb der Microsoft Dienste. In diesem Artikel erkläre ich anhand von ein paar Beispielen, worauf speziell zu achten ist.

Normalerweise möchte man sich bei der Nutzung von Cloud Diensten keine Gedanken um das Thema Netzwerk machen. Man kauft ja schließlich fertige Dienste ein, bei denen der Anbieter schon dafür sorgt, dass Netzwerkseitig alles passt. Oft braucht man das auch nicht, da in kleineren Firmen das Netzwerk nicht sehr komplex ist und es keine Besonderheiten gibt, die einem Probleme machen können. Es gibt aber Firmennetzwerke, die einen ausführlichen Blick auf das Thema Netzwerk benötigen. Ein aktuelles Projekt brachte mich dazu, das Thema Netzwerk sehr viel genauer zu betrachten, als es in Vergangenheit nötig war. Meine Erfahrungen daraus möchte ich in diesem Artikel vertiefen.

DNS-Auflösung

Um ein Ziel im „Internet“ zu erreichen, muss der Client zunächst wissen, welchen Server er ansprechen muss. Die Hostnamen der Microsoft 365 Dienste müssen deshalb über einen DNS-Server auf die entsprechende IP-Adresse übersetzt werden. Bei einfachen Webseiten gibt es normalerweise keine Besonderheiten. Zu meinem Blog gibt es genau eine IP-Adresse des entsprechenden Webservers. Alle Anfragen, egal von wo aus der Welt diese kommen, werden zum selben Webserver mit derselben IP-Adresse geschickt.

In größeren Cloud-Konstrukten ist dies aber anders. Auf jedem Kontinent stehen mehrere Rechenzentren von Microsoft, welche die Services für Kunden bereithalten. Die Verbindung zum Exchange Online Mailserver läuft aber immer über den Hostnamen outlook.office.com.

Jetzt muss per Geo-DNS der am besten zu erreichende Server dem Client zurückgemeldet werden. Was dabei eine nicht optimale DNS-Abfrage für Folgen haben kann, möchte ich anhand von zwei Beispielen erläutern.

Der Optimalfall

Gehen wir zunächst von einem für Cloud Dienste optimalen Fall aus. Wir denken an eine kleine Firma mit vielleicht 30-50 Mitarbeitern und einem einzelnen Büro. Das Büro hat ein VLAN und einen Internetzugang. Alle Clients erhalten per DHCP vom Router ihre IP-Konfiguration und so werden alle DNS-Abfragen über den DNS-Server des Internetproviders abgehandelt. Die Mitarbeiter im Homeoffice benötigen kein VPN, da bereits alle Dienste über Microsoft 365 genutzt werden. Es gibt nur eine einfache Firewall, und der ausgehende Internetzugang ist nicht reglementiert. Der Begriff Proxyserver wurde bislang von niemandem im Unternehmen in den Mund genommen.

Wie verhalten sich nun die Cloud Dienste?

Hier wird es vermutlich keine Probleme geben. Da die Clients über den DNS-Server des Internetproviders die Hostnamen der entsprechenden Microsoft 365 Endpunkte auflösen, werden die naheliegendsten IP-Adressen vom Microsoft Rechenzentrum aufgelöst. Im Optimalfall gibt es vom Internetprovider direkt ein Peering zum Microsoft Global Network (MGN), sodass die Datenpakete nicht mehr über ein öffentliches Peering laufen, sondern direkt zu Microsoft geroutet werden. Dies spart Hops und sorgt für geringe Latenzen. Hier ein Beispiel von meinem Internetanschluss aus:

In diesem Tracert sieht man gut, dass outlook.office.com auf eine IP-Adresse in Frankfurt am Main aufgelöst wird. Hop 3-6 sind IP-Adressen meines Internetproviders (Vodafone). Ab Hop 7 gehen die Anfragen in Düsseldorf ins MGN und von dort aus über eigene Glasfaserstrecken von Microsoft ins Microsoft RZ in Frankfurt am Main.
Mein Provider hat demnach ein direktes Peering zu Microsoft. Viel kürzer können an einem privaten Internetanschluss die Datenpakete nicht bei Microsoft landen. Insgesamt 13ms vergehen, bis die Datenpakete am zuständigen Server angekommen sind.

Unternehmen mit mehreren globalen Standorten

Aber wo kann es jetzt Probleme geben? Denken wir nun an ein global agierendes Unternehmen. Der Firmensitz und somit auch die IT-Verantwortlichen sind in Australien beheimatet. Es gibt jedoch ein Büro in Düsseldorf. Da auch viele interne Server per VPN angesprochen werden müssen, wird der DNS-Server der VPN Appliance genutzt. Das VPN ist als Split-Tunnel konfiguriert. Es werden also nur die Anfragen an interne (per VPN erreichbare) Ressourcen durch den VPN-Tunnel geroutet. Die DNS Auflösung geht aber in jedem Fall an den DNS-Server am Firmenhauptsitz in Australien, damit die internen Hostnamen der über VPN erreichbaren Server aufgelöst werden können. Was soll da schon schiefgehen?

Nunja, das sieht man recht schnell mit einem erneuten Tracert auf die Adresse, die vom DNS-Server in Australien zurückgegeben wird. Der Name lässt es bereits vermuten, der Microsoft Server befindet sich in Sydney.

Im Vergleich zum ersten Beispiel sieht man schnell, dass die Datenpakete deutlich länger unterwegs sind. Zwar landen diese vom gleichen Internetanschluss auch ab Hop 7 im MGN, brauchen dann aber ca. 250ms länger, bis der Zielserver in Sydney erreicht wird. Der Weg bis nach Sydney ist halt doch etwas länger… Zwischen Hop 8 und 9 liegt vermutlich ein Seekabel zwischen Europa und Australien.

Öffentliche DNS-Server

Viele Netzwerkadministratoren setzen gerne DNS-Server wie z.B. 8.8.8.8, 9.9.9.9 oder 1.1.1.1 ein. Diese DNS-Server sind zwar sehr performant, können aber die Namensauflösung stören, wenn es um das Finden des am schnellsten zu erreichenden Servers über das MGN geht. Der DNS-Server des Internetproviders ist stets vorzuziehen.

Hier habe ich zwei DNS-Abfragen gemacht. Zunächst über die quad9 DNS-Server, und danach über den DNS-Server meines Routers, der an den DNS-Server meines Internetanbieters weiterleitet. Man sieht schön, wie unterschiedlich die DNS-Antworten sind. Die erste Antwort kommt von einem Microsoft DNS-Server aus Amsterdam, die zweite von einem Microsoft DNS-Server aus Hessen (Frankfurt).

Lessons Learned

Was lernen wir daraus? Jede Dependance eines Unternehmens sollte stets die DNS-Auflösung des lokalen Internetanbieters bzw. Internet Breakouts nutzen, um die Pakete auch zum richtigen (besten) Zielserver zu senden. Firmen, die interne WANs nutzen, müssen spätestens mit Einführung von Cloud-Diensten umdenken. Microsoft hat schließlich nicht umsonst mehrere Rechenzentren weltweit in Betrieb. Diesen Vorteil sollte man auch nutzen und nicht durch falsche DNS-Abfragen zunichtemachen.

Der Beitrag Microsoft 365 und das Netzwerk – Part 1: DNS erschien zuerst auf M365 Blog - Julian Stabentheiner.