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:
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.
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.
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
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:
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:
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.
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:
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:
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.
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
Wer steckt eigentlich hinter Allgeier? Marina verstärkt bei Allgeier seit Juli 2023 das Finanzteam. Im Interview erfahren wir mehr über ihre beruflichen Herausforderungen, worauf es in ihrem Job ankommt und wo man sie in ihrer Freizeit findet.
Ausgestattet mit modernster KI-Technologie, bietet die Plattform eine optimierte Verwaltung und Analyse digitaler Inhalte.
Kann AR die Produktion revolutionieren? Wo liegen mögliche Einsatzfelder und konkrete Vorteile? Im vierten Blog der Smart Maintenance Reihe werfen wir einen Blick in die Zukunft.
Smart Maintenance ist kein Trend, sondern eine Notwendigkeit, um wettbewerbsfähig zu bleiben. Doch welche Phasen durchläuft die Implementierung einer intelligenten Wartung?
Dass Smart Maintenance nicht nur für die Industrie relevant ist, zeigte der Vortrag von Mirko Maurer bei der maintenance Schweiz. Was Resilienz damit zu tun hat, erfahren Sie hier.
KI goes Microsoft 365: Was der intelligente Assistent Copilot kann und wie er die Zusammenarbeit auf neue Beine stellt.
Smarte Technologien, wertvolle Daten und vernetzte Mitarbeiter: Von der Herausforderung Smart Maintenance zu implementieren und wie man sie bewältigt. Alles im aktuellen Blog!
Vernetzt, automatisiert und mit Echtzeit-Daten gespickt – das sind die Kennzeichen von Industrie 4.0. Doch welche Rolle spielt Smart Maintenance dabei konkret? Wie kann es zur Effizienzsteigerung und Kostenreduktion führen – das verraten wir im neuen Blogbeitrag.
Zwischen Flexibilität und Festungsanlage: Wie Unternehmen in der modernen Arbeitswelt Sicherheit gewährleisten können. Ein Expertengespräch mit Christian Dunkel über Secure Workplace.
