An ein Azure AD zu kommen ist maximal einfach, oft merkt man es gar nicht weil man „eigentlich“ Office 365 angeschafft hat. Und die Benutzerverwaltung im Hintergrund ist einfach so mitgekommen, meistens setzt man noch eine Synchronisation von Nutzern und Gruppen mit dem lokalen AD auf und dann ist es auch schon gut.
Wussten Sie eigentlich, dass die Standard-Einstellung für jedes neue Azure AD ist, dass alle Ihre Anwender neue Gäste einladen dürfen? Und wussten Sie, dass im Standard sogar die eingeladenen Gäste neue Gäste einladen dürfen? Ich bin kein Freund einer „Verbots-IT“ bei der alles abgeklemmt wird, im Gegenteil: Benutzer die mehr Verantwortung übernehmen (müssen) sind nach meiner Meinung die beste Sicherheitsmaßnahme für die IT. Allerdings sollte man grundlegende Entscheidungen bei dem zentralen Verzeichnisdienst der eigenen Cloud bewusst treffen und dokumentieren.
Zur Abgrenzung: Ich betrachte heute nur die Konfiguration des Azure AD nicht der gesamten Office 365 Cloud.
Die Ausgangssituation: Unser Tenant ist registriert, eine eigene Domain wurde hinzugefügt und die ersten (Test-)Nutzer werden synchronisiert.
Admin-Konten
Mein erster Blick würde jetzt auf die Liste der (Global) Admins fallen. Für die ersten Einrichtungsschritte werden hier oft an zu viele Personen Rechte verteilt, ggf. sind auch externe noch im Besitz von umfangreichen Berechtigungen. Direkt einschränken und nicht personalisierte Accounts direkt entfernen. Globale Admins sollten reine Cloud-User sein und auf die *.onmicrosoft.com Subdomain angelegt sein. Das garantiert, dass man den Tenant auch noch dann administrieren kann, wenn der AAD Connect klemmt oder der vielleicht vorhandene ADFS ein Problem hat.
Damit sich die Admins (inklusive einem selbst) gar nicht erst an zu viel Komfort gewöhnen, sollte unmittelbar die Multi-Faktor-Authentifizierung aktiviert werden. Für Kunden mit EM+S (bzw. Azure AD P1) Lizenzen ist dies am bequemsten über Conditional Access möglich. Hier existiert bereits eine passende vordefinierte Regel: „Baseline policy: Require MFA for admins“. Diese Regel muss nur noch aktiviert werden (in Zukunft wird das irgendwann automatisch aktiviert). Ohne Azure AD Premium sollte man die „klassische“ MFA-Aktivierung wählen, hat den Nachteil, dass man neu hinzugekommene Admins von Hand nachpflegen muss.
Dieser Schritt darf nie unterschätzt werden, gerade Admins nehmen gerne unsichere Passwörter (sind ja Profis, fallen nicht auf Malware & Co rein). Wenn die Admin-Konten kein MFA aktiv haben bitte direkt eine Pause beim Lesen hier einlegen und unmittelbar diese Einstellung nachholen! (Wirklich. Jetzt sofort. Auch für den eigenen Admin-User)
Gäste
Kommen wir zum nächsten Thema: Gäste. Sind Gäste ein Sicherheitsrisiko? Nein, was nicht heißt, dass es nichts zu tun gibt. Wie eingangs geschrieben bin ich auf der Optimisten-Seite was das Vertrauen in Mitarbeiter angeht (oder auf der Pessimisten-Seite, wenn es darum geht sich vor dem dümmsten anzunehmenden Mitarbeiter zu schützen). Egal wie die Entscheidungen ausfallen, folgende Optionen stehen zur Wahl:
Azure AD -> User Settings -> „Manage external collaboration settings”
Guest users permissions are limited (Default: Yes): Sofern Sie nicht möchten, dass Ihre Gäste eine Liste aller Azure AD Nutzer sehen können, sollte man hier „Yes“ ausgewählt lassen.
Admins and users in the guest inviter role can invite (Default: Yes): Hier sehe ich keinen Änderungsbedarf, außer man möchte gar keine Gäste.
Members can invite (Default: Yes): Diese Einstellung kann sehr kontrovers gesehen werden. Sofern ich bereits viele O365-Services nutze und noch gar keinen Plan habe, was Gäste damit alles anstellen können sollte man es ggf. deaktivieren. Die bessere Variante ist aber: Erlauben und in den jeweiligen Applikationen (Teams, SharePoint / OneDrive & Co) den genaueren Umgang mit Gästen regeln.
Guests can invite (Default: Yes): Obwohl ich wirklich offen bin für Self-Service finde ich, dass dieser Punkt etwas zu weit geht. Aber auch hier gilt, dass die Einstellung nicht per se unsicher ist – entsprechende Governance in den nachgelagerten O365-Diensten vorausgesetzt.
Enable Email One-Time Passcode for guests (Default: No): Für den Start würde ich die Option deaktiviert lassen sofern es keine konkreten Anforderungen von der Fachseite gibt. Zum Ende der Preview kann man erneut darüber nachdenken (wer weiß schon was bis dahin alles an Optionen dazugekommen ist).
Collaboration restrictions: Die Option bestimmte Gast-Domains per White- oder Blacklist zu erlauben kann ein guter Kompromiss zwischen Sicherheit und Funktionalität sein. Hier kommt es sicher auch auf die Größe des Unternehmens an: Ein Konzern mit einer Liste von erlaubten Zulieferern hat hier andere Voraussetzungen als ein kleines Unternehmen, dessen Zulieferer oft nicht wissen was ein Azure AD ist und ob man das essen kann.
Und jetzt sind wir fertig mit den Gästen? Noch nicht ganz – bei meinen eigenen Konten (mutmaßlich aus dem lokalen AD synchronisiert) habe ich die Gewissheit, dass die Komplexität des Passworts ausreichend hoch ist. Für potenzielle Gäste gilt das leider nicht, weshalb es eine valide Entscheidung sein kann alle Gäste mit einer Multi-Faktor-Authentifizierung zu quälen. Auch hier ist wieder Azure AD P1 als Lizenz die Voraussetzung, ist diese vorhanden geht die Einrichtung schnell:
https://docs.microsoft.com/de-de/azure/active-directory/b2b/b2b-tutorial-require-mfa
Wer jetzt im Menü für Conditional Access ist kann jetzt auch noch gleich Nutzungsbedingungen als PDF hinterlegen. Falls es eine Anforderung durch die Rechtsabteilung ist, dass Gäste einen solchen Disclaimer akzeptieren kann es hier also direkt konfiguriert werden (als Teil von Conditional Access gelten hier die Lizenzanforderungen von Conditional Access).
Anmerkung: Es reicht wenn die eigenen Nutzer für Azure AD P1 lizensiert sind, Gäste müssen nicht lizensiert werden (um ganz genau zu sein: Für jeden eigene Lizenz kann man weitere 5 Gäste mit Azure AD Premium-Features versehen, sollte ausreichend sein).
Gäste-Thema endlich fertig?
In Bezug auf Konfiguration ja, aber bisher haben wir uns nur Gedanken darüber gemacht wie Gäste reinkommen. Ohne Aufräum-Prozess bleiben unsere Gäste für immer – man sollte sich also noch Gedanken über das „Aufräumen“ machen. Um den Umfang des Artikels nicht zu sprengen gehe ich darauf ein anderes Mal ein.
Kommen wir zu den weiteren Einstellungen, die neben dem Gastzugriff noch konfiguriert werden wollen:
“Restrict Access to Azure AD access portal” (Default: No): Aus meiner Perspektive gibt es wenig Gründe den Zugriff hier einzuschränken. Das erlaubt es zwar jedem Anwender Benutzer und nicht versteckte Gruppen im Azure AD zu sehen / zu suchen, aber letztendlich ist das auch der Sinn eines Verzeichnisdienstes. Darüber hinaus wird auch nur der Zugriff auf die Weboberfläche eingeschränkt. Die Berechtigungen die gleichen Aktionen z.B. per PowerShell auszuführen werden dadurch nicht berührt. Und falls ihr euch das jetzt fragt: Ja ein normaler User ohne Admin-Rechte kann per PowerShell via Connect-AzureAD und Get-AzureADUser -All $true alle Benutzer im Azure AD auslesen.
LinkedIn Account Connections (Default: No): Laut Dokumentation werden die Kontakte eines Nutzers mit LinkedIn abgeglichen. Dazu wird zwar jeder Nutzer einzeln befragt, aber nur der Nutzer selbst, nicht die Kontakte des Nutzers. Meiner Einschätzung nach ist das ein DSGVO-Verstoß (vergleichbar mit WhatsApp wo auch sämtliche Kontakte an die Server von Facebook übertragen werden). Falls jemand genauere Informationen zum Datenaustausch hat, würde ich mich sehr darüber freuen – denn bisher kann ich hierzu nur Mutmaßungen anstellen. Vorerst empfehle ich diese Funktion auf der Voreinstellung „No“ zu belassen.
„Users can register Applications“ (Default: Yes): Hier geht es um selbstentwickelte Azure AD Applikationen. Meine Empfehlung ist es hier eine Einschränkung vorzunehmen, sodass nur ausgewählte Personen neue Applikationen registrieren können. Da es im Azure AD eine eigenständige Rolle hierfür gibt, kann man das Recht bequem an die Entwickler verteilen, die das auch wirklich benötigen.
Enterprise Applications
Wenn wir schon bei den Applications sind: Bestimmt gibt es doch auch eine Möglichkeit zu kontrollieren, ob User nicht-selbstentwickelte Applications (-> Enterprise Applications) im AzureAD registrieren dürfen? Um das herauszufinden, muss man erst einmal dieses Menü unter Azure AD -> User Settings -> „Manage how end users launch their applications“ ausfindig machen:
Doch die Option für ein simples „Deaktivieren“ gibt es dort nicht. Man muss sich also leider kurz etwas genauer mit dem Thema beschäftigen. Die oben abgebildeten Einstellungen sind mal wieder der „Standard“ für einen neuen Azure AD Tenant, im Einzelnen steuern diese folgendes:
User can consent to apps accessing company data on their behalf (Default: Yes): Diese Option erzeugt bei vielen Admins eine unmittelbare Abwehrhaltung: Laut Beschreibung darf der Nutzer offensichtlich ohne Nachfrage einer fremden Applikation Firmendaten (auf die er selbst Zugriff hat) übergeben. Microsoft selbst schreibt dazu:
Allowing users to register and consent to applications might initially sound concerning, but keep the following in mind
Ich verstehe jeden der diese Option direkt deaktiviert. Ich persönlich empfehle aber die Option aktiv zu lassen. Es gibt mittlerweile doch einige Websites, die über einen solchen Mechanismus einen Single Sign On zu ihrem Dienst anbieten. Dadurch entfällt eine Registrierung bei einem weiteren Online-Service (und wir wissen ja alle, dass Anwender ihr Passwort wiederverwenden). Die beste Option liegt hier vermutlich irgendwo in der Mitte: Erlauben, Aufklären und Kontrollieren.
Die anderen beiden Optionen bieten nicht so viel Zündstoff für eine Diskussion:
User can add gallery Apps to their Access Panel (Default: No): Hier geht es darum, ob Nutzer eigenständig Enterprise Applications (für Single Sign On) hinzufügen dürfen. Auch wenn ich ein Freund von Self-Service bin würde ich diese Option deaktiviert lassen. Hintergrund ist, dass für einen sinnvollen Single-Sign-On zusätzliche Konfigurationsschritte notwendig sind, insofern macht es mehr Sinn, wenn der Admin die Einrichtung einmal richtig ausführt.
User can only see Office 365 apps in the Office 365 portal (Default: No): Die Option sollte besser lauten “Office 365 Apps unter https://myapps.microsoft.com verstecken. Wer hier eine stärkere Trennung zwischen O365 Apps und den Third-Party-Apps haben will kann es deaktivieren – einen Einfluss auf die Sicherheit hat diese Option sicher nicht.
Mit diesen Punkten hat man die (meiner Meinung nach) wichtigsten Optionen für das Azure AD betrachtet und kann beginnen sich um die einzelnen Dienste zu kümmern. Insbesondere durch Teams und SharePoint / OneDrive werden noch einmal einige Anforderungen auf das Azure AD zukommen – diese müssen aber im Rahmen der einzuführenden Applikation betrachtet werden.