Neue Azure-AD-Mandanten einrichten
Erstbezug
Veröffentlicht in Ausgabe 08/2021 - PRAXIS
Die wichtigen Einstellungen beim Betrieb eines neuen oder der Übernahme eines bestehenden Azure-AD-Tenants beziehen sich auf Sicherheitseinstellungen, Benutzer, Informationen und Datenschutz. Dazu kommen Konfigurationen, die den Dienst selbst schützen. Denn von Mitarbeitern oder Geschäftspartnern erstellte Daten und Objekte sind später nur schwer wieder aufzuräumen. Hier sollten Sie sich frühzeitig Gedanken machen. All diesen wichtigen Eckpfeilern widmen wir uns im Folgenden im Detail.
Möglichst wenig Rechte vergeben
Wenn Sie Azure AD (AAD) für Office 365 und weitere Dienste nutzen, ist es wichtig, den Zugang und die vom Dienst geschützten Daten streng zu kontrollieren. Das beginnt mit der Anmeldung und dem Single Sign-On (SSO): Haben Sie eine föderierte Anmeldung mit einem Identityprovider (IDP) wie etwa ADFS konfiguriert, müssen Sie sicherstellen, dass der Zugang zum IDP, sowohl administrativ als auch durch Benutzer bei der Anmeldung, mit der gleichen Vertraulichkeit behandelt wird wie das AAD selbst. In vielen Umgebungen bedeutet dies, dass Sie den ADFS-Dienst – und im Fall von Password Hash Synchronization (PHS) auch Azure AD Connect – so schützen müssen wie lokale Domaincontroller. Das macht die hybriden Komponenten vielerorts zu Tier-0-Systemen mit entsprechenden Schutzvorkehrungen.
Innerhalb des AAD sollten Sie sich um "Least Privilege" bemühen: Die Rechte für den Global Admin sowie die Administratoren der Office-365-Dienste wie "Exchange Service Administrator" oder
Die wichtigen Einstellungen beim Betrieb eines neuen oder der Übernahme eines bestehenden Azure-AD-Tenants beziehen sich auf Sicherheitseinstellungen, Benutzer, Informationen und Datenschutz. Dazu kommen Konfigurationen, die den Dienst selbst schützen. Denn von Mitarbeitern oder Geschäftspartnern erstellte Daten und Objekte sind später nur schwer wieder aufzuräumen. Hier sollten Sie sich frühzeitig Gedanken machen. All diesen wichtigen Eckpfeilern widmen wir uns im Folgenden im Detail.
Möglichst wenig Rechte vergeben
Wenn Sie Azure AD (AAD) für Office 365 und weitere Dienste nutzen, ist es wichtig, den Zugang und die vom Dienst geschützten Daten streng zu kontrollieren. Das beginnt mit der Anmeldung und dem Single Sign-On (SSO): Haben Sie eine föderierte Anmeldung mit einem Identityprovider (IDP) wie etwa ADFS konfiguriert, müssen Sie sicherstellen, dass der Zugang zum IDP, sowohl administrativ als auch durch Benutzer bei der Anmeldung, mit der gleichen Vertraulichkeit behandelt wird wie das AAD selbst. In vielen Umgebungen bedeutet dies, dass Sie den ADFS-Dienst – und im Fall von Password Hash Synchronization (PHS) auch Azure AD Connect – so schützen müssen wie lokale Domaincontroller. Das macht die hybriden Komponenten vielerorts zu Tier-0-Systemen mit entsprechenden Schutzvorkehrungen.
Innerhalb des AAD sollten Sie sich um "Least Privilege" bemühen: Die Rechte für den Global Admin sowie die Administratoren der Office-365-Dienste wie "Exchange Service Administrator" oder
"SharePoint Service Administrator" sollten Sie auf ein Minimum beschränken. Zugriff gewähren Sie nur dann, wenn administrative Tätigkeiten notwendig sind. Denken Sie beim Entfernen von ständigen Rollenmitgliedern daran, dass Sie zumindest einen "Break Glass"-Account für Notfälle einrichten. Der Logon für diesen Account sollte losgelöst von jeglicher On-Premises-Infrastruktur sein (cloud-only) und durch ein starkes Anmeldeverfahren geschützt werden, wie etwa einen FIDO2-Schlüssel [1]. Diesem Account geben Sie auch eine E-Mailadresse als "alternative E-Mailadresse" im Azure AD mit, wobei die Adresse auf eine Verteilerliste oder ein Gruppenpostfach zeigt, das mehrere Admins lesen und betreuen. Das AAD versendet rollenspezifische Diensthinweise, Informationen und Warnungen an die hinterlegten Adressen der privilegierten Rollen, sodass alle Admins die Hinweise erhalten und nichts verloren geht. Selbiges gilt für die "Technische Ansprechpartner"-Adresse, die Sie in "Settings" im AAD-Portal hinterlegen.
AAD-Premium-P2-Lizenzen erlauben, Admin-Konten mit Privileged Identity Management (PIM) zu konfigurieren, sodass Rollen vorübergehend "eligible" (berechtigt), aber nicht permanent eingerichtet sind. Wollen dann Rolleninhaber die Rolle nutzen, müssen Sie im PIM die Rechteerhöhung anstoßen. Dabei können Sie hier auch eine Multi-Faktor-Authentifizierung (MFA) und die Genehmigung eines Vorgesetzten oder Kollegen erzwingen. PIM unterstützt damit Just-in-Time (JIT) und Just-Enough-Administration (JEA).
In jedem Fall sollten Sie die "Sign-In Logs" und die "Audit Logs", sollten Sie eine P1-Lizenz besitzen, in Ihr Log-Tool wie Splunk exportieren und aufbereiten lassen. Troubleshooting oder Nachverfolgung von Änderungen im Verzeichnis, an Verzeichnisobjekten, Adminkonten oder Privilegien lassen sich so langfristig (über 30 Tage hinaus) nachvollziehen und archivieren [2].
Zugriffe steuern
Das Regelwerk für Conditional Access (CA), das den Zugriff von "Wer, Wann, Woher, Was" steuert, sollten Sie überschaubar und klar strukturiert halten. Denn zu viele Regeln führen zu Komplexität, die die Sicherheit mindert. Versuchen Sie deshalb, das Regelwerk in einer 80-20-Balance zu halten: Für 80 Prozent der Anwendungsfälle definieren Sie Standardregeln, die für eine Vielzahl von Anwendungen passen. Kommt zum Beispiel ein Benutzer mit einem bekannten, verwalteten Gerät daher, sollte der Zugriff zu den meisten als "niedrig" oder "mittel" kategorisierten Apps erlaubt sein. Nur für Apps, deren Sicherheitsbedürfnis "hoch" ist, sollten andere Regeln gelten. Damit schaffen Sie Regeln, die nicht pro App, sondern pro App-Klassifizierung gelten, und gruppieren gleichzeitig die Apps. Neue Apps regulieren Sie beim Onboarding.
Die restlichen 20 Prozent sind Regeln, die legitime Abweichungen vom Standardregelwerk darstellen: Besondere Benutzer, Gäste, Administratorkonten für bestimmte Zielsysteme oder Systemkonten lassen sich ebenfalls klassifizieren und hoch berechtigte Admins wie "Global Admins" lassen sich in eigenen Regeln mit mehreren Apps zusammenfassen.
Ausnahmen zu bestimmten Regeln definieren Sie über die "Exclude"-Einstellung in Conditional Access. Die Option ist nützlich, wenn Sie Notfallkonten oder externe Benutzer generell von CA-Regeln ausschließen wollen. Die ausgenommenen Benutzer hinterlegen Sie entweder in Sicherheitsgruppen oder Azure-AD-Rollen, die Sie im "Exclude"-Teil nutzen. So können Sie die ganze Gruppe einer Überprüfung mit Ihrem Prozesstool oder AAD Access Reviews unterziehen. Dadurch ist es möglich, die Ausnahmenverwaltung besser zu automatisieren und einen Genehmigungsprozess mit Ablauf der Mitgliedschaft in der Ausnahmegruppe zu hinterlegen.Sie sollten sich als Ziel setzen, alle Apps mit Conditional Access zu schützen, damit das Regelsystem alle Zugriffe überprüfen und bewerten kann. Selbst wenn Sie Anwendungen betreiben, die für alle Benutzer zugänglich sein sollen, können Sie eine "Catch-All"-Regel für ein App-Onboarding definieren.
Ohne Conditional Access müssen Sie sich vergewissern, dass Sie die "Security Defaults" für Ihren Tenant einschalten [3]. Dies sorgt dafür, dass sich alle Benutzer für MFA registrieren, die "Legacy"-Protokolle automatisch abgeschaltet werden und privilegierte Aktionen MFA erzwingen. Die Security Defaults geben Ihnen nicht die Flexibilität von CA, bieten aber einen grundlegenden Schutz.
Alte Protokolle weitgehend abschalten
Bei aller Liebe zur Abwärtskompatibilität: Manche Protokolle unterstützen keine modernen Authentifizierungsverfahren, mit denen CA arbeitet. Protokolle wie POP3 oder SMTP sind nicht für MFA One-
Time-Passworte geeignet. Diese Protokolle nutzen Angreifer bevorzugt für Phishing und Brute-Force-Attacken, um Accounts zu erraten und dann an wertvolle Daten zu kommen, mit denen sich weitere Angriffe starten lassen. In neuen Office-365-Projekten schalten Sie "Legacy Authentication" am besten von Anfang an aus, denn nachgelagert ist der Vorgang komplexer, falls Benutzer oder Infrastrukturkomponenten auf die alten Protokolle angewiesen sind. Das Deaktivieren funktioniert mehrschichtig: Sie schalten die Protokolle am besten im Dienst selbst ab – für POP3 und SMTP wäre das Exchange Online [4] – sowie im AAD, indem Sie die Authentifizierung in Conditional Access stoppen [5].
Haben Sie noch kein Projekt zur Abschaltung von "Legacy Authentication" gestartet, sollten Sie das baldmöglichst tun. Auch wenn Sie die Protokolle nicht für alle Benutzer auf einen Schlag deaktivieren können, lässt sich über den flexiblen Regelsatz in CA steuern, welche Benutzer die Protokolle übergangsweise weiterhin brauchen, und auch in den jeweiligen Diensten die Protokolle benutzerbezogen abschalten.
Multi-Faktor-Authentifizierung und Strong Credentials
Nicht nur für Administratoren und deren Arbeit an den Clouddiensten erzwingen Sie besser einen zweiten Faktor, auch für Endbenutzer sollten Sie zumindest einen zweiten Faktor konfigurieren, der eine zusätzliche Identitätsvalidierung erfordert. Dabei geht es nicht um die Gängelung der Benutzer bei jeder Anmeldung – das 80-20-Regelwerk erlaubt Usern auf bekannten, gesunden Geräten den Zugriff ohne MFA. Es geht um die Definition des Faktors, den der Benutzer in Sonderfällen hervorholen und präsentieren kann. Eine erhöhte Mitarbeitermotivation zum Registrieren eines Zweitfaktors erreichen Sie über sinnvolle Freiheiten und Flexibilität. Zum Beispiel sollten Kollegen eine interne Anwendung auf diesem Wege auch von zu Hause erreichen dürfen.
Der zusätzliche Faktor ist außerdem nützlich beim Rollout von Windows Hello for Business. Wertvoll ist ein zweiter Faktor auch in Szenarien, in denen Benutzer Geräte selbst zum AAD hinzufügen können sollen und wenn Mitarbeiter ihr Passwort oder einen der MFA-Faktoren verlieren. Dies erlaubt den Anwendern, sich ohne Helpdesk selbst aus einem derartigen Dilemma zu befreien.
Erlauben Sie den Mitarbeitern, Geräte zum AAD hinzuzufügen, sollten Sie die Geräteregistrierung zumindest mit MFA schützen oder mit dem Intune-Gerätemanagement verknüpfen. Die selbst hinzugefügten Devices, die dann dem Zugriff auf Unternehmensdaten dienen, sind so geschützt. Um sich das Recht vorzubehalten, diese Geräte zu supporten, definieren Sie mit "Manage additional local Administrators on all Azure AD joined devices" Benutzer, Gruppen und Dienstkonten als lokale Admins. Die Einstellungen treffen Sie im AAD-Portal unter "Devices / Device Settings / Users may join devices to Azure AD" mit den Optionen "All" oder "Selected" für alle oder einige Mitarbeiter (via Gruppen). Zusätzlich hinterlegen Sie bei "Require Multi-Factor Auth to join devices" ein "Yes".
Da Mitarbeiter bei einer MFA-Registrierung die hinterlegten Einstellungen für ein Self-Service-Password-Reset (SSPR) verwenden können, sofern dieses aktiv ist, sollten Sie auch einen Blick in die erlaubten und gewünschten Prüfungen werfen. Setzen Mitarbeiter ihr Passwort zurück oder vollziehen eine MFA, sind nicht alle Methoden gleich vertrauenswürdig. Selbstgewählte Fragen und Antworten sowie SMS sollten Sie als weniger vertrauensvoll einstufen als ein One-Time-Password (OTP) oder Push-Nachrichten für die Authenticator-App. Generell setzt Microsoft auf die Authenticator-App als starken MFA-Faktor und FIDO2-ähnliches, starkes Credential. Planen Sie frühzeitig die Nutzung von starken Faktoren – also Anmeldeverfahren, die bereits in sich eine MFA darstellen und daher einfacher sind als Passwort in Kombination mit MFA.
Rechte für die Kollaboration
Weiterhin einer der stärksten Gründe für die Cloudnutzung ist moderne Kollaboration. Im Fall von Azure-B2B gibt es hierbei keine Benutzerkonten und Passworte zu verwalten. Damit die Kollaboration sicher und gemäß der IT-Richtlinien abläuft, sollten Sie sich einige B2B-Einstellungen ansehen. In neuen AADs können Mitarbeiter Geschäftspartner frei zur Kollaboration einladen. Wenn Sie die Liste der erlaubten Geschäftspartner vorgeben oder einschränken wollen, können Sie eine Domänen-Whitelist führen. Die Einstellung heißt "Allow invitations only to the specified do- mains (most restrictive)" in den "External Collaboration settings" im AAD-Portal.
Für die Zusammenarbeit können Sie für eine Reihe von Office-365-Funktionen Informationen aus dem Azure AD auslesen. Dazu zählen etwa andere Mitglieder in Office-365-Gruppen oder -Teams sowie die Liste der registrierten Anwendungen im AAD. Diese Voreinstellung passen Sie in "External collaboration settings" an. Der Bereich "Guest user access" erlaubt Ihnen, Gäste wie interne Benutzer zu behandeln, was den Gästen mehr Freiheiten und weitere Berechtigungen im Verzeichnis erlaubt. Oder Sie schränken die Gäste so weit ein, dass diese außer der eigenen Gruppenmitgliedschaft keine anderen Daten aus dem Verzeichnis lesen können. Bei dieser Konfiguration müssen Sie aber damit rechnen, dass Ihren Gästen einige M365-Funktionen nicht zur Verfügung stehen [6].
Sie sollten außerdem definieren, wer Einladungen aussprechen darf. Die Voreinstellung für alle Tenants ist liberal: Jeder darf einladen, inklusive Personen, die selbst per Einladung in Ihren Tenant gelangt sind. Die Einstellung gilt dabei nicht nur für das Azure-AD-Portal und Azure, sondern für alle M365-Dienste und die Einladefunktionen in Teams oder in Teilen von SharePoint. Die Einstellung "Member users and users assigned to specific admin roles can invite…" ist vernünftig, wenn Sie Gäste generell erlauben. Sie können die so vergebenen Rechte im Nachgang mit einer Whitelist einschränken. Wenn Microsoft von "specific admin roles" spricht, dann umfasst das die "Global Admins"-, die "User Admins"- und die "Guest Inviter"-Rolle.
Machen Sie sich Gedanken, wie Sie die Gastkonten, die für Geschäftspartner bei B2B-Kollaboration entstehen, verwalten wollen. Wenn die gemeinsame Arbeit endet, bleiben die Gastkonten zurück, die Sie manuell, mit Skripten [7] oder Azure AD Access Reviews überprüfen und deren Zugriff Sie entziehen oder löschen.
Checkliste neuer Azure-Mandant
Folegende Aufgaben stehen für den Admin bei einem neuen Mandanten an:- Identityprovider und Azure AD Connect als besonders schützenswert behandeln.- Rollenzuweisungen im Azure AD überprüfen und reduzieren.- "Break Glass"-Account für Notfälle definieren und besonders gut schützen.- Mindestens zwei Konten pro privilegierter Rolle mit Postfach oder Verteilerliste als alternative E-Mail versehen, um Dienstmitteilungen per E-Mail nicht zu verpassen.- Privileged Identity Management (PIM) für privilegierte Rollen nutzen.- "Security Defaults" überprüfen, wenn Conditional Access nicht eingeführt wurde.- 80-20-Balance für Conditional-Access-Regeln überprüfen und umsetzen.- Regelausnahmen für Gruppen definieren und "Break Glass"-Account sowie Admin-Accounts wo nötig ausnehmen.- Verbot alter Authentifizierungs-Protokolle planen und umsetzen. Ausnahmen streng kontrollieren und rigoros nachverfolgen.- Mitarbeiter zur Registrierung per MFA ermutigen und mindestens zwei MFA-Methoden bereitstellen.- Strategie für "Strong Credentials" erarbeiten und Alternativen zu Passwort plus MFA planen und umsetzen.- Festlegen, wie Kollaboration mit anderen Unternehmen aussehen soll: Verbot/Erlaubt-Liste oder Verbots-Liste umsetzen und Berechtigungen zum Einladungsverfahren festlegen.- Prozess und Werkzeug für den Lebenszyklus von Gästen im Tenant ausarbeiten und implementieren.- Onboarding-Strategie für Anwendungen definieren. Einstellungen für Anwendungsregistrierung und die Rechte-Genehmigung festlegen.- Definieren, wer Anwendungen Berechtigungen zu Ressourcen und APIs genehmigen darf ("Consent").- Die Einstellung überprüfen, ob Global Admins auch zum Tenant zugehörige Azure-Abonnements verwalten dürfen.
Anwendungen registrieren
Anwendungen im Azure AD mit SSO und Conditional Access zu schützen, sollte für die IT und Geschäftsbereiche möglichst einfach sein. Vorsicht ist jedoch geboten, wenn Applikationen zum Einsatz kommen, die bestehende Daten neu anzeigen, neu organisieren oder Benutzer verwalten. Denn das bedingt, dass Sie Anwendungen Zugriff auf Ihre Daten oder APIs erlauben müssen. Bevor das jedoch geht, muss die Anwendung im AAD angelegt und ihr Zugriff genehmigt werden. Beides segnen die Mitarbeiter in den Standardeinstellungen ab, sofern die App keine kritischen Daten oder APIs nutzen will. Die Definition von "kritisch" ist aber weitläufig, denn in den Standardeinstellungen können Anwender Apps zustimmen, die beispielsweise das Graph-API-Recht "Mail.Read" ausüben möchten, um des Nutzers E-Mails lesen zu können. Doch wer E-Mails lesen kann, kann auch Namen und Adressen anderer Benutzer und sonstige interessante Informationen abgreifen.
Um Anwendungen zunächst einer Überprüfung zu unterziehen, können Sie die Registrierung und den Zugang zu Ressourcen und APIs unterbinden und dies selbst übernehmen. Verfügen Sie über einen Onboarding-Prozess für Anwendungen, hinterlegen Sie einen Workflow, mit dem Benutzer Apps anfragen können. Die Apps landen dann in einer Warteschlange für die Genehmigung durch einen Admin [8]. Dieses Freischalten der Anwendungen erfordert, dass Sie im Unternehmen eindeutig festlegen, welche Berechtigungen Applikationen erhalten sollen, in welchem Kontext und wie detailliert eine Sicherheitsanalyse einer Genehmigung vorangehen muss. Das "User Settings"-Blade unter "Enterprise Applications" listet all diese Einstellungen. Zusätzlich sollten Sie definieren, ob Mitarbeiter selbst Anwendungen hinzufügen können. Im Blade für "Users" unter "User Settings" finden Sie "User can register applications". Dieser Punkt steuert, ob Ihre Entwickler selbstständig Anwendungen hinzufügen dürfen oder ob das Admins in Folge eines On-boarding-Prozesses erledigen müssen. Die Einsetllung "Restrict access to Azure AD administration portal" sperrt nicht-privilegierte Benutzer aus dem AAD-Portal aus. In der Sektion "Properties" finden Sie in "Access Management for Azure Resources" einen Schalter, der es AAD-Admins erlaubt, Azure-Subskriptionen zu verwalten. Besteht in Ihrem Unternehmen da eine klare Trennung der Verantwortlichkeiten, sollte der Schalter auf "No" stehen.
Fazit
In unserem Rundumschlag sind wir auf viele Funktionen und To-Dos eingegangen, die beim Betrieb eines Azure-AD mit Office 365 wichtig sind. Die Checkliste liefert Ihnen einen guten Ausgangspunkt für die notwendigen Arbeiten. Doch nicht alle Themen sind damit vom Tisch: Wichtige operationelle Aspekte wie das Speichern der Logs im SIEM oder Log-Tool, das Erstellen von Dashboards für die Gesundheit der einzelnen Dienste und Nutzungsdaten Ihrer Mitarbeiter, der erweiterte Lebenszyklus von Anwendungen und deren Einstellungen liegen noch vor Ihnen.
(jp)
Link-Codes
[1] Notfall-Accounts im AAD verwalten: https://docs.microsoft.com/en-us/azure/active-directory/roles/security-emergency-access/
[2] AAD-Logs archivieren: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/quickstart-azure-monitor-route-logs-to-storage-account/
[3] Security-Defaults erklärt: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults/
[4] Basis-Authentifizierung in Exchange Online abschalten: https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/disable-basic-authentication-in-exchange-online/
[5] Alte Protokolle im AAD unterbinden: https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication/
[6] Rechte von Gästen im AAD einschränken: https://docs.microsoft.com/en-us/azure/active-directory/enterprise-users/users-restrict-guest-permissions/
[7] Inaktive AAD-Accounts managen: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-manage-inactive-user-accounts/
[8] Workflow für Admin-Genehmigungen: https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/configure-admin-consent-workflow/