Security Defaults, Baseline & Advanced Policies
Ausgangslage
Im alltäglichen Projektgeschäft mit Microsoft 365 Kunden stelle ich bei der ersten Kurz-Analyse des Tenants häufig fest, dass die Kernfunktionalität “Conditional Access” zur Umsetzung der Microsoft Zero-Trust Architektur leider kaum angewendet wird. Und in den seltenen genutzten Fällen, wird es entweder nicht korrekt oder nur unzureichend implementiert. Beides, Nicht-Nutzung oder mangelnde Konfiguration, führt zu erheblichen Sicherheitslücken. Als Gründe dafür sehen wir, dass:
- Autoren sich zu sehr darauf fokussieren, welche Anwendungsfälle sie zulassen wollen, und nicht, was blockiert werden soll.
- Policies oftmals rückwärts entworfen werden, wodurch ein Tenant ebenfalls anfällig für Angriffe wird.
- Verantwortliche für die Wichtigkeit von Azure AD Conditional Access als Bedingung für den Erfolg von Zero Trust nicht genügend sensibilisiert sind.
- zu wenig personelle Resourcen zur Verfügung stehen, um eine Strategie zu entwerfen, ein entsprechendes Design zu planen, dieses umzusetzen und im Rahmen von monatlichen Reviews zu verwalten.
- technisches Grundwissen und Verständnis nicht im ausreichenden Mass vorhanden sind.
Bedeutung einer lückenlosen Conditional Access Implementierung
Mit diesem Blog möchte ich dazu beitragen, dass sowohl das Design, die Notwendigkeit als auch die Bedeutung einer lückenlosen Conditional Access Implementierung besser verstanden werden. Eine bessere Sensibilisierung über Conditional Access Baseline Policies ist eine der Voraussetzungen für eine optimale Sicherheit eines M365 Tenants.
Mit Fokus auf Azure AD Security Best Practice werde ich die Einführung von Baseline Policies als “First-Step” Ansatz erläutern und welche Massnahmen für eine korrekte Implementierung, eine einfache Verwaltung und schliesslich für eine aussagekräftige Dokumentation notwendig sind.
Conditional Access vs. Security Defaults - Was ist der Unterschied?
- Conditional Access ist eine Premiumfunktion von Azure AD (Premium 1 oder 2 Lizenz)
- Conditional Access wird erst aktiviert, nachdem das Feature “Security Defaults” (seit 22.10.2019 in allen neu erstellten M365 Tenants standardmässig aktiviert) abgeschaltet wird.
- Conditional Access betrifft den Schutz von Identitäten (Benutzer und Geräte), von Daten sowie die Reduzierung von Angriffsflächen.
- Mit aktivierten “Security Defaults” werden vorkonfigurierte Security Policies durchgesetzt, welche sich ausschliesslich auf identitäts-basierte Angriffe beziehen und nicht editierbar sind:
- Administratoren müssen MFA durchführen
- Alle Benutzer müssen sich für Azure AD MFA registrieren
- Benutzer müssen nach Registrierung MFA durchführen
- Legacy-Authentifizierungs-Protokolle werden blockiert
- Schutz von privilegierten Aktivitäten (Zugriff auf Azure Portal, Azure PowerShell, Azure CLI)
Somit bietet Microsoft mit den Security Defaults ein Mindestmass an Schutzmechanismen für den bedingten Zugriff, ohne im Vorfeld eine Conditional Access Policy erstellt zu haben. Dies reduziert die Angriffsfläche bereits um ein Vielfaches, allerdings wie in Abbildung 1 zu sehen ist, bieten Security Defaults nur einen kleinen Teil von Conditional Access ab und sind für ein auf die Bedürfnisse des Kunden zugeschnittenes Design ungeeignet.
Conditional Access & Multi-Factor-Authentifcation
Im Kontext von Security Best Practice und moderner Authentifizierung sind zusätzliche Identitäts-Zugangskontrollen unerlässlich. Ausschliesslich Benutzernamen und Passwörter als Identitätsnachweis zu verwenden ist heutzutage unsicher und grenzt beinahe an ein gewisses Mass von Fahrlässigkeit.
Beispielsweise ist es für Angreifer ein Leichtes, durch Phishing-Attacken an Benutzer-Passwörter zu gelangen. Diese Angriffe sind weit verbreitet und werden ausserdem immer häufiger für den Endbenutzer als harmlos erscheinende Emails professionell getarnt, sodass Benutzer häufig in diese Falle tappen. In vielen Fällen führt der erfolgreiche Phishing Angriff letztendlich zur Kompromittierung eines Accounts. Dies bedeutet für das Risiko-Management, dass nicht die Frage, OB, sondern WANN es passieren wird, von zentraler Bedeutung ist.
Die Bereitstellung eines zweiten Schritts oder einer Aufforderung – auch bekannt als Azure Multi-Faktor-Authentifizierung (Azure MFA) – ist vorzugsweise ein Code oder eine Push-Benachrichtigung, die in einer mobilen App wie der Microsoft Authenticator App generiert wird.
Zusätzlich zu Azure MFA kann eine moderne Anwendung, zu der Webbrowser und andere Client-Anwendungen (wie Outlook, OneDrive usw.) gehören, viel mehr Informationen übermitteln als eine herkömmliche Client-Anmeldeaufforderung bei der nur Ihr Benutzername und Kennwort abgefragt werden. Die moderne Client-Anwendung gibt zum Beispiel Informationen über sich selbst an und enthält auch einige Details über das vom Endbenutzer verwendete Gerät
Empfohlenes Minimum: «Baseline & Recommended Policies»
Der Grundgedanke hierbei ist, dass Regeln erstellt werden, wie Personen auf Cloud-Ressourcen zugreifen dürfen. Jede Baseline Policy wird auf die Einstellung “All Users” angewendet. Nach Bedarf können auf der Registerkarte “Exclude” Ausnahmen hinzugefügt werden, was mitunter gut überdacht sein muss. Sobald eine Identität von MFA ausgeschlossen wird, sollte das Anmeldeverhalten der entsprechenden Accounts mittels Azure Monitor beobachtet werden und bei Erreichen von vordefinierten Schwellenwerten eine Alarm-Benachrichtigung auslösen. Beispielsweise in Bezug auf ein Szenario, indem sich aufgrund einer Fehlkonfiguration innerhalb einer Conditional Access Policy kein einziger Benutzer mehr anmelden kann, empfiehlt Microsoft prophylaktisch eine Security Group für Emergency Access zu erstellen und dieser Gruppe mindestens zwei zuvor erstellte Emergency Access Accounts zuzuweisen. Diese Gruppe muss von allen Conditional Access Policies ausgeschlossen werden, was gewollt dazu führt, dass eine MFA-Abfrage nicht stattfindet und der jeweilige Emergency Access Accounts ohne zweiten Faktor authentifiziert werden und auf diese Weise der Zugriff zur Korrektur der Konfiguration wiederhergestellt werden kann.
Für ein absolutes Minimum in einem Baseline Policy Set sind drei Policies erforderlich:
- Legacy Authentication blockieren
- Multi-Faktor-Authentifizierung für alle Benutzer verlangen
- MFA für Administratoren aus allen Netzwerken anfordern
In einer einfachen Umgebung mit wenigen Benutzern reicht dieses Set aus, um sich nicht nur auf unsichere Passwörter verlassen zu müssen. Hierbei werden alle Benutzer beim Login-Vorgang dazu aufgefordert, sich mittels MFA zu authentifizieren. Ältere Clientanwendungen, die keine zweite Authentifizierungsaufforderung unterstützen, werden zudem vollständig an der Verbindung gehindert. Dies ist im Wesentlichen gleichbedeutend mit den “Security Defaults” wie zuvor beschrieben.
Die meisten Unternehmen werden jedoch nicht nur die “Security Defaults” verwenden, sondern auch Geräte verwalten sowie Anwendungsdaten schützen wollen. Über das absolute Minimum hinaus würde ich daher den meisten KMU-Kunden folgende Richtlinien empfehlen:
- Nicht unterstützte Geräte-Plattformen blockieren
- MFA für Zugriff auf das Azure AD Admin Center / Microsoft Entra Portal
- MFA für die Geräte-Registrierung und den Azure AD DomainJoin verlangen
Und das war’s – das ist der gesamte Baseline & Recommended Policy Ansatz. Insgesamt also sechs Contional Access Policies. Einfacher geht’s nicht, um den ungeschützten M365 Tenant abzusichern. Ganz ohne Bedarf an einem komplizierten Design, einem Management oder einer versionierten Dokumentation.
Für grössere KMUs und Enterprises: Conditional Access Management und Dokumentation
In grösseren KMU oder auch in Enterprise Umgebungen bestehen definitiv höhere Anforderungen an eine smarte Zugangskontrolle. Diesen Anforderungen kann man mit weiteren Policies gerecht werden. Dies beinhaltet mehr Komplexität, auch im Regelwerk. Es empfiehlt sich in solchen Umgebungen eine gute Design-Planung und eine etappierte Umsetzung. Zudem empfehle ich ab hier eine versionierte Dokumentation zu führen, welche eine einfache Verwaltung der vorhandenen Policies ermöglicht.
Nachstehende Policies sind erforderlich zur Erreichung eines Zero-Trust Ansatzes:
- Blockieren der Legacy-Authentifizierung
- Multi-Faktor-Authentifizierung für alle Benutzer verlangen ausser aus on-Premise Umgebung (Trusted Location)
- MFA für Administratoren aus allen Netzwerken anfordern
- Multi-Faktor-Authentifizierung für alle mobilen Geräteplattformen
- Approved Client-Apps für mobile Geräte sowie App Protection Policies im Endpoint Manager
- Device Compliance für jede unterstützte Geräteplattform
- Nicht unterstützte Geräteplattformen blockieren
- Einschränkung der Registrierung von Sicherheitsinformationen
- Named Locations konfigurieren für Trusted Locations und Länder
- Blockieren von MFA Setup von untrusted Locations
- Zugriff aus unerlaubten Ländern blockieren
- Zugriff von Service Accounts blockieren (ausser trusted Locations)
- Zugriff von nicht unterstützen Apps blockieren (ausser trusted Locations)
Testing und Deployment
Bevor eine Conditional Access Policy auf alle Benutzer angewendet wird, ist es wichtig zu verstehen, welche Auswirkungen die Aktivierung einer Policy haben wird. Hierzu gibt es drei Möglichkeiten, dies im Vorfeld zu testen:
- Erstellung einer Testgruppe, der eine Policy zugewiesen wird:
Die in der Testgruppe enthaltenen Benutzer Accounts können sowohl Test- als auch Pilotbenutzer sein. - Aktivierungsmodus “Report Only”:
Hierbei wird ein Bericht im Azure AD Sign-in Log-Bereich des Tenants erstellt, in denen der Anwendungsfall protokolliert wird, die Policy selbst jedoch nicht effektiv angewendet wird, was bei der Identifizierung von allfällig betroffenen Benutzer-, Dienstkonten und Applikationen sehr hilfreich ist. - Die Verwendung der “What If” Funktion:
Dies ermöglicht zu evaluieren, was wäre wenn eine Policy auf eine bestimmte Gruppe und einen bestimmten Benutzer angewendet werden würde ohne die entsprechende Policy zu aktivieren.
Condtional Access Policy Templates
Microsoft hat im Rahmen von Vereinfachungsmassnahmen in Anlehnung eines verbesserten Conditional Access Policy Designs eine Vorlagenfunktion für Common Conditional Access Policies implementiert (Anfang 2022). Diese Funktion, welche sich aktuell noch in der Preview-Phase befindet, ermöglicht es, die wichtigsten Policies mittels eines integrierten Wizards zu implementieren. Mit der Verwendung dieser Funktion wird ein verantwortlicher Admin durch Anwendung von vorhandenen Templates, die beim Durchführungsprozess sowohl für Identitäten als auch für Geräte angeboten werden, in die Lage versetzt, auf sehr einfache Art und Weise sämtliche Zero-Trust relevanten Policies zu erstellen.
Eine ausführliche Anleitung über die Vorgehensweise wird in einem kommenden Blogbeitrag beschrieben.
Zusammenfassung
Wir haben gesehen, wann Security Defaults ausreichen, in welchem Scenario Baseline-Policies in Betracht zu ziehen sind und welche M365 Tenants mit einem erweiterten Policy Set geschützt werden sollten. Da es sich bei Letzterem in der Anzahl um wesentlich mehr Policies handelt, die es zu verstehen gilt, wird hier dringend geraten, sich das erforderliche Wissen über Azure AD Conditional Access anzueignen oder einen spezialisierten und zuverlässigen Business Partner mit der Erstellung oder Beratung zu beauftragen.
Conditional Access richtig angewendet reduziert das Risiko sich eines Tages in einer Account- Kompromittierung-Situation wiederzufinden fast auf null. Ein Restrisiko wird immer bleiben, das in der Regel aus allgemein bekannten Unzulänglichkeiten des Menschen besteht. Hierzu gibt es ebenfalls Lösungen, die wir in einem anderen Blog vorstellen.
Links
- Blog Aktivierung von MFA zur besseren Absicherung Aktivierung von Microsoft MFA zur besseren Absicherung (allgeier.ch)
- Angebot «Security Awareness Plattform» Security Awareness Training schützt vor Social Engineering (allgeier.ch)
