Identity & Access: Eingrenzung des Microsoft 365-Zugriffs auf Unternehmensgeräte

Zugriff auf Dateien, Chats und alles drumherum – jederzeit und von überall. Was sich für  Endanwender verlockend anhört, stellt Unternehmen vor eine Herausforderung. Denn abhängig von  deren IT-Strategie und der allgemeinen Vorgehensweise im Kontext Modern-/New-Work kommt es  allzu häufig vor, dass das mobile Arbeiten zwar jederzeit und von überall ermöglicht werden soll, die  Verwendung von privaten Geräten für den Zugriff jedoch nicht erwünscht ist.

Was im ersten Moment nicht allzu komplex erscheint, bringt wie so häufig jedoch einen nicht  unerheblichen Aufwand für die Konzeption und Implementierung mit sich. Denn – ein einfaches  Absichern des Zugriffs per MFA-Methoden wie beispielsweise einer Authenticator-App stellt noch  lange nicht sicher, dass die Anwender auch nur von Unternehmensgeräten aus auf die  entsprechenden Dienste zugreifen können.

Um dieses Problem zu lösen, stellt Microsoft seinen Kunden verschiedene Möglichkeiten zur  Verfügung, welche für die Abbildung dieser Anforderung genutzt werden können.

Microsoft setzt an verschiedenen Punkten an, um das Aussperren privater Geräte möglich zu  machen. Im Folgenden setzen wir uns mit vier Vorgehensweisen auseinander:

• Eingrenzung auf IP-Adressen und Gerätefilterung 
• Nutzung der certificate based authentication (CBA) 
• Voraussetzung eines Hybrid Azure AD Joins
• Prüfung des Compliance-Status

Die vier genannten Punkte unterscheiden sich in ihrer Funktionsweise teils sehr grundlegend  voneinander. Teilweise kann es deshalb auch sinnvoll sein, sie zu kombinieren. Auch die Ergänzung  der Methoden durch die Hinzunahme „klassischer“ MFA-Methoden kann in manchen Fällen dabei  helfen auch sehr anspruchsvolle Sicherheitsanforderungen abzubilden.

Die Steuerung und Anwendung der Authentifizierung auf diese Art wird über die Verwendung von  Conditional Access möglich. Ein Dienst, welcher insbesondere bei den größeren Microsoft 365- Lizenzen beinhaltet ist und in der Planung und Konfiguration sehr intuitiv gestaltet werden kann.

Die technisch einfachste Einschränkung kann durch die Eingrenzung auf spezifische IPs/IP Adressbereiche und die Anwendung der Gerätefilterung erreicht werden. Microsoft spricht hier bei der Verwendung von IPs von den sogenannten „Trusted Locations“. Diese  können innerhalb des Dienstes im Rahmen der „Named Locations“ hinterlegt werden.

Eine Trusted  Location ist eine einfache Sammlung von IP-Adressen, welche als vertrauenswürdig erachtet werden  kann. Verwendet werden hier in der Regel jene IP-Adressen, von welchen der Zugriff in das Internet  erfolgt. 

Nimmt man nun ein vereinfachtes Unternehmensnetzwerk mit einem einzelnen Break-out-Point ins  Internet und einer einzelnen öffentlichen IP als Beispiel, so könnte innerhalb einer Policy konfiguriert  werden, dass der Zugriff auf die Online-Ressourcen nur von dieser Trusted Location möglich ist.

Problem gelöst, oder? Bei weitem nicht! Denn – sind wirklich alle Geräte, welche von meiner  öffentlichen IP-Adresse auf die Online-Dienste zugreifen, auch wirklich unternehmenseigene Geräte?  Was wenn die lokalen Hotspots gerne auch von Mitarbeitern mit ihren privaten Smartphones genutzt werden, um auf das Internet zuzugreifen? Aus Netzwerk-Security-Sicht zwar hochkritisch und weit  fernab der Best Practice, in der Realität jedoch leider trotzdem häufig der Fall.

Es muss also ein zusätzlicher Faktor verwendet werden, um auch wirklich die Anmeldung in Gänze einzuschränken. Dieser Faktor ist die Filterung auf Geräte.

Hierdurch kann erreicht werden, dass nur jene Geräte auf die Microsoft 365-Ressourcen zugreifen  können, welche sich im Unternehmensnetzwerk befinden und zusätzlich auch noch dem  Unternehmen bekannt sind. Die Wahl der entsprechenden Filtereigenschaften muss aber wohl  überlegt sein und die Geräte müssen zusätzlich dem Azure Active Directory (aktuell mag ich den  Begriff noch mehr als Entra ID) bekannt sein. Eine Voraussetzung, welche in manchen Fällen ein  Killer-Kriterium darstellen kann.

Letzteres ist für die Verwendung der certificate based authentication keine Grundvoraussetzung. Hier müssen die Geräte nicht in Richtung des Azure Active Directory synchronisiert werden und  überhaupt ist die Methode variabler in der Art der Geräte, deren Zugriff damit gesteuert werden  kann.

CBA wurde vor noch gar nicht allzu langer Zeit als Möglichkeit eingeführt, den Zugriff auf Ressourcen  per Zertifikat einzuschränken. Der Begriff Zertifikat bezieht sich hier auf die „klassischen“ User- und  Benutzerzertifikate, wie sie auch häufig für die Nutzung von VPN oder die Einwahl in WLANs  verwendet werden.

Um diese Methode nutzen zu können, müssen natürlich die entsprechenden Zertifikate auf dem  Gerät vorhanden sein. Diese müssen darüber hinaus eine Art eindeutigen Identifier beinhalten. Das  kann der User Principal Name oder die Mailadresse sein. Es stehen aber auch noch andere Methoden zur Verfügung. Zusätzlich muss der entsprechende Zertifikatspfad dem Azure Active Directory  bekannt gemacht werden.

Ist dies nun implementiert und läuft die Authentifizierung basierend auf Zertifikaten, erhalten die  Anwender bei der Anmeldung eine Aufforderung ein entsprechendes Zertifikat auszuwählen. Dieses  wird anschließend auf die Übereinstimmung der Benutzerattribute, den genannten eindeutigen  Identifier geprüft und bei Erfolg erhält der User seinen Zugriff.

Aber Vorsicht! – Das Zertifikat selbst stellt noch nicht sicher, dass es sich um ein Unternehmensgerät  handelt. Es muss unbedingt darauf geachtet werden, dass der Private Key des Zertifikats nicht  exportiert werden kann. Sonst könnte ein findiger Anwender das Zertifikat mitsamt Private Key  einfach exportieren und auf seinem privaten Gerät einbinden, was das Ziel der Implementierung  verfehlt.

Die Voraussetzung des Hybrid Azure AD Joins stellt die vielleicht beliebteste Methode für die  Eingrenzung auf Unternehmensgeräte dar. Das dürfte an der „relativ“ einfachen Implementierung  liegen.

Wird der HAADJ vorausgesetzt, so wird bei der Authentifizierung am Cloud-Dienst geprüft, ob das  Gerät sowohl in der lokalen Domäne eingebunden als auch im Azure Active Directory registriert ist.  Nur wenn beides der Fall ist, erhält das Gerät den Status Hybrid Azure AD joined und der Benutzer  erhält seinen Zugriffstoken.

Warum die Lösung so einfach und charmant ist? Weil lediglich die lokal in der Domäne  eingebundenen Geräte in Richtung des Azure Active Directories synchronisiert werden müssen.  Dieser Prozess erfolgt User-unabhängig und bietet den Vorteil, dass mehrere Benutzer sich ggfls. von  einem Unternehmensgerät aus anmelden können.

Hört sich doch hervorragend an. Warum dann nicht immer einfach den HAADJ nutzen? Weil diese  Funktion nur für Windows-Geräte zur Verfügung steht, welche bereits in einer lokalen Domäne  eingebunden sind. Alle anderen Arten von Betriebssystemen werden nicht unterstützt. Die Kontrolle  des Zugriffs von beispielsweise iOS-Geräten kann dadurch nicht gesteuert werden.

Für dieses Szenario kommt die letzte Methode ins Spiel. Die Prüfung auf den Compliance Status des Gerätes, von welchem die Anmeldung erfolgt. Dieser Status kommt in der Regel aus der MDM- und MAM-Lösung Intune, kann aber auch von Drittanbietern wie beispielsweise Jamf oder MobileIron importiert werden. Das ist besonders dann hilfreich, wenn eine Implementierung des Dienstes Microsoft Intune aktuell noch nicht für eine Organisation relevant ist und sie deshalb weiterhin ihre bisherige MDM-Lösung nutzen möchte.

Grundsätzlich ist der Compliance-Status ein einfaches Attribut, welches entweder true oder false ist. Hört sich einfach an – ist aber in der Realität ein komplexes Thema. Denn – wann ist ein Gerät compliant und wann nicht? Soll es hierbei eine Regel für alle Geräte geben oder sollen verschiedene verwendet werden? Fragen, welche teilweise nicht einfach zu beantworten sind und häufig abteilungsübergreifend geklärt werden müssen.

Sind aber die Compliance-Richtlinien konfiguriert, können diese auf die Geräte angewendet und ihre Compliance dadurch kontrolliert werden. Damit dies durch den Dienst Microsoft Intune möglich wird, müssen die Geräte im Azure Active Directory vorhanden sein und innerhalb des Dienstes registriert werden. Hierbei ist unbedingt darauf zu achten, dass Anwender nicht ihre privaten Geräte innerhalb des Azure AD registrieren oder joinen können.

Ist alles sauber konfiguriert kann somit der Zugriff auf unternehmenseigene Geräte eingeschränkt und zusätzlich sogar noch auf weitere Aspekte der Geräte wie den aktuellen Gerätezustand oder die aktuelle Betriebssystemversion getestet werden, bevor der Zugriff des Users erfolgen kann.