Eine praktische Basiskonfiguration für Microsoft 365 — über die Standardeinstellungen hinaus
Tobias Schüle ist Senior Microsoft 365-Architekt und Gründer von Opsora, mit über einem Jahrzehnt Erfahrung in der IT-Transformation europäischer mittelständischer Unternehmen.
Conditional Access ist die wichtigste Sicherheitskontrolle in Microsoft 365. Sie sitzt auf der Identitätsebene — dem Punkt, durch den jede Zugriffsanfrage fließt — und bestimmt, ob diese Anfrage fortgesetzt wird, eine zusätzliche Verifizierung erfordert oder vollständig blockiert wird. Alles andere im Microsoft-Sicherheits-Stack setzt voraus, dass die Identität korrekt verwaltet wird. Wenn Conditional Access falsch konfiguriert ist, ist der Rest der Sicherheitsposture auf einem instabilen Fundament aufgebaut.
Microsoft bietet eine Reihe von Standard-Conditional-Access-Richtlinien an. Diese Standardeinstellungen sind vernünftige Ausgangspunkte für eine neue Organisation ohne bestehende Richtlinien. Für eine Organisation, die bereits eine Weile operiert, sind sie keine Sicherheitsposture — sie sind eine Untergrenze. Die meisten mittelständischen Unternehmen benötigen wesentlich mehr als die Standardeinstellungen.
Dies ist die Baseline-Conditional-Access-Richtlinienkonfiguration für 2026. Acht Richtlinien, jede mit einem klaren Zweck, einem häufigen Konfigurationsfehler und, wo relevant, einem Hinweis auf die NIS2-Ausrichtung.
Was sie tut: Jede Benutzeranmeldung bei einer Microsoft 365-Anwendung erfordert Multi-Faktor-Authentifizierung. Der zweite Faktor kann die Microsoft Authenticator App, ein SMS-Code oder ein Hardware-FIDO2-Schlüssel sein.
Warum es wichtig ist: Passwortkompromittierung ist der häufigste initiale Zugriffsvektor in Microsoft 365-Umgebungen. MFA reduziert den Wert eines kompromittierten Passworts nahezu auf null. Dies ist die einzelne wirksamste Sicherheitskontrolle, die Sie implementieren können.
Häufiger Konfigurationsfehler: MFA wird über die alten benutzerbezogenen Einstellungen aktiviert, anstatt über eine Conditional-Access-Richtlinie erzwungen. In den benutzerbezogenen Einstellungen können Benutzer, die sich noch nicht für MFA registriert haben, sich weiterhin ohne sie anmelden. Eine Conditional-Access-Richtlinie erzwingt MFA beim Zugriffspunkt — unabhängig davon, ob der Benutzer die MFA-Registrierung abgeschlossen hat.
NIS2-Ausrichtung: Spricht direkt Artikel 21(2)(i) an — die Verwendung von Multi-Faktor-Authentifizierung.
Was sie tut: Blockiert alle Anmeldeversuche mit Protokollen, die keine MFA unterstützen — SMTP AUTH, IMAP, POP3, Basic Authentication und ältere Office-Client-Authentifizierungsflows.
Warum es wichtig ist: Legacy-Authentifizierungsprotokolle umgehen MFA konzeptionell. Wenn diese Protokolle in Ihrem Mandanten aktiviert sind, kann ein Angreifer mit einem gültigen Benutzernamen und Passwort über IMAP authentifizieren, unabhängig davon, ob MFA in der Conditional-Access-Richtlinie erforderlich ist. Jede Organisation, die MFA aktiviert, aber Legacy-Authentifizierung nicht blockiert hat, hat eine wesentlich schwächere Sicherheitsposture als sie glaubt.
Häufiger Konfigurationsfehler: Eine Richtlinie zur Blockierung von Legacy-Authentifizierung existiert, enthält aber eine IP-Bereichs-Ausnahme für das Unternehmensnetzwerk. Diese Begründung — dass On-Network-Geräte vertrauenswürdig sind — ist fehlerhaft. Netzwerkstandort ist kein Identitätssignal. Legacy-Authentifizierung sollte bedingungslos blockiert werden.
NIS2-Ausrichtung: Unterstützt Artikel 21(2)(i), indem sichergestellt wird, dass die MFA-Durchsetzung nicht umgangen werden kann.
Opsora führt strukturierte Bewertungen für europäische IT-Teams durch. Sprechen Sie direkt mit einem erfahrenen Architekten — kein Vertriebsteam, keine vorbereitete Präsentation.
Briefing anfragenWas sie tut: Verlangt, dass jedes Gerät, das auf Microsoft 365-Anwendungen zugreift, in Intune registriert ist und die Compliance-Richtlinienbedingungen erfüllt (Festplattenverschlüsselung, aktuelles Betriebssystem, Bildschirmsperre, Endpunktschutz aktiv).
Warum es wichtig ist: Verwaltete, konforme Geräte bieten wesentlich höhere Sicherheit als nicht verwaltete. Eine Anforderung für konforme Geräte stellt sicher, dass auf Organisationsdaten nicht von ungepatchten persönlichen Maschinen oder nicht kontrollierten Endpunkten zugegriffen wird.
Häufiger Konfigurationsfehler: Die Richtlinie wird auf alle Cloud-Anwendungen statt auf eine gezielte Gruppe sensibler Anwendungen angewendet. Richten Sie die Richtlinie auf Anwendungen aus, bei denen die Daten die Kontrolle rechtfertigen: SharePoint, OneDrive, Exchange und alle anderen Anwendungen, die vertrauliche Daten verarbeiten.
NIS2-Ausrichtung: Unterstützt Artikel 21(2)(e) — Sicherheit beim Erwerb, der Entwicklung und Wartung von Netz- und Informationssystemen.
Was sie tut: Verwendet benannte Standorte in Entra ID, um vertrauenswürdige Standorte (Büronetzwerk-IP-Bereiche, VPN-Ausgangspunkte) zu definieren und zusätzliche Überprüfung oder Blockierung für Anmeldungen von Standorten außerhalb dieses Sets anzuwenden.
Warum es wichtig ist: Credential-Stuffing-Angriffe und Brute-Force-Versuche stammen überwiegend aus IP-Bereichen und geografischen Standorten, die nichts mit Ihrer Benutzerbasis zu tun haben. Das Blockieren von Anmeldungen aus Regionen, in denen keine Mitarbeiter tätig sind, eliminiert eine ganze Klasse von Angriffsvektoren ohne Auswirkungen auf legitime Benutzer.
Häufiger Konfigurationsfehler: Benannte Standorte werden nach der Erstkonfiguration nie aktualisiert. Das Unternehmensnetzwerk ändert sich (neuer Bürostandort, geänderter ISP, aktualisierter VPN-Endpunkt), aber die Conditional-Access-Richtlinie verweist noch auf die alten IP-Bereiche. Benannte Standorte müssen als lebende Konfiguration behandelt werden.
NIS2-Ausrichtung: Unterstützt Artikel 21(2)(a) — Politiken zur Risikoanalyse und Informationssystemsicherheit.
Was sie tut: Eine separate, strengere Richtlinie, die für alle privilegierten Entra ID-Rollen gilt — Globaler Administrator, Exchange-Administrator, SharePoint-Administrator und die vollständige Gruppe privilegierter Verzeichnisrollen. Erfordert Phishing-resistente MFA (FIDO2-Schlüssel oder zertifikatsbasierte Authentifizierung).
Warum es wichtig ist: Administratorkonten sind die hochwertigsten Ziele in jeder Microsoft 365-Umgebung. Reguläre MFA (Microsoft Authenticator Push-Benachrichtigung) ist anfällig für MFA-Fatigue-Angriffe — Angreifer überfluten den Benutzer mit Genehmigungsanfragen, bis eine versehentlich genehmigt wird. Phishing-resistente MFA eliminiert diesen Angriffsvektor.
Häufiger Konfigurationsfehler: Admin-Konten sind die primären Benutzerkonten des IT-Teams — dasselbe Konto für E-Mail und tägliche Arbeit hat auch globale Admin-Rechte. Das korrekte Modell: ein separates, cloud-only-Konto ausschließlich für Admin-Aufgaben, ohne Postfach und mit erzwungener Phishing-resistenter MFA.
NIS2-Ausrichtung: Spricht direkt Artikel 21(2)(i) für privilegierte Konten an.
Was sie tut: Integriert die Benutzerrisikobewertung von Entra ID Identity Protection. Benutzer, die als hochriskant eingestuft werden — basierend auf Signalen einschließlich geleakter Zugangsdaten, verdächtigen Aktivitätsmustern und unmöglichen Reisen — werden daran gehindert, auf Anwendungen zuzugreifen, bis ihr Risiko gemindert ist.
Warum es wichtig ist: Identity Protection verarbeitet kontinuierlich Signale, die individuelle Conditional-Access-Richtlinien nicht können — geleakte Zugangsdaten aus dem Dark Web, anomale Verhaltensmuster. Hochrisiko-Benutzer-Blockierung stellt sicher, dass bei Erkennung eines Kompromittierungssignals der Zugriff automatisch eingeschränkt wird.
Häufiger Konfigurationsfehler: Die Richtlinie wird im Nur-Bericht-Modus konfiguriert und nie auf Durchsetzung umgestellt. Der Nur-Bericht-Modus ist für die erste Bereitstellung angemessen, um die Auswirkungen zu verstehen — bietet aber keinen Schutz.
NIS2-Ausrichtung: Unterstützt Artikel 21(2)(b) — Incident Handling und Artikel 21(2)(a) — Risikomanagement.
Was sie tut: Stellt sicher, dass der Zugriff auf Exchange Online-E-Mails und Teams von mobilen Geräten über von Microsoft verwaltete Anwendungen (Outlook Mobile, Teams) und nicht über die native iOS-Mail-App erfolgt. Intune-App-Schutzrichtlinien können dann auf diese genehmigten Apps angewendet werden.
Warum es wichtig ist: Native mobile Betriebssystem-Anwendungen, einschließlich der iOS-Mail-App, unterstützen keine modernen Authentifizierungsflows oder Intune App Protection Policies. Auf diese Weise zugegriffene Daten können nicht verwaltet werden.
Häufiger Konfigurationsfehler: Die Richtlinie gilt für alle Plattformen, einschließlich Windows-Desktop. Beschränken Sie diese Richtlinie auf iOS und Android.
Was sie tut: Für Benutzer, die von nicht verwalteten Geräten auf Microsoft 365 zugreifen, werden Sitzungskontrollen über Microsoft Defender für Cloud Apps angewendet: Download-Blockierung für sensible Dokumente, Zwischenablage-Einschränkungen und Abmeldung nach Inaktivität.
Warum es wichtig ist: Einige legitime Anwendungsfälle erfordern den Zugriff von nicht verwalteten Geräten — Auftragnehmer, Partner, Benutzer, die von einem persönlichen Gerät aus auf Reisen zugreifen. Sitzungskontrollen ermöglichen eingeschränkte Interaktion mit Organisationsdaten von nicht verwalteten Endpunkten ohne das Risiko von Downloads.
Häufiger Konfigurationsfehler: Sitzungskontrollen werden auf alle Anwendungen angewendet. Konzentrieren Sie Sitzungskontrollen auf SharePoint und OneDrive, wo der Dokumenten-Download das primäre Risiko darstellt.
Bei jeder Organisation, bei der Conditional-Access-Richtlinien im Rahmen einer umfassenderen Sicherheitsbewertung überprüft werden, taucht dieselbe Lücke mit bemerkenswerter Häufigkeit auf: MFA ist in den Mandanteneinstellungen aktiviert, wird aber nicht über Conditional Access erzwungen. Die IT meldet, dass MFA vorhanden ist. Die Realität ist, dass ein Prozentsatz der Benutzer — typischerweise 10–30 % — sich nie für MFA registriert hat und sich ohne sie anmeldet.
Die Lösung ist unkompliziert: Richtlinie 1 oben zwei Wochen lang im Nur-Bericht-Modus implementieren, um zu sehen, welche Benutzer blockiert würden, die nicht registrierten Benutzer sanieren, dann auf Durchsetzung umstellen. Der gesamte Prozess dauert typischerweise drei bis vier Wochen und verbessert die Sicherheitsposture der Organisation sofort.
Diese acht Richtlinien sind eine Basiskonfiguration, kein Endzustand. Die Bedrohungslandschaft ändert sich. Neue Angriffsvektoren entstehen. Die Zugriffsmuster Ihrer Organisation entwickeln sich weiter.
Conditional-Access-Richtlinien erfordern vierteljährliche Überprüfungen: Sind alle benannten Standorte aktuell? Gibt es neue administrative Rollen, die Abdeckung benötigen? Wurden Notfallausnahmen hinzugefügt und nicht entfernt?
Wenn Sie eine unabhängige Überprüfung Ihres aktuellen Conditional-Access-Richtliniensets wünschen, umfassen unsere Security-Hardening- und Zero-Trust-Bewertungen ein vollständiges CA-Audit als Standardkomponente.
NIS2 ist kein Checklistenprojekt. Hier ist eine strukturierte, M365-spezifische Roadmap für IT-Teams, die sich erstmals mit der Richtlinie befassen.
Copilot gibt Daten zurück, auf die Ihre Benutzer bereits Zugriff haben. Wenn Berechtigungen und Klassifizierung falsch sind, macht Copilot das sichtbar — und zwar schnell.
Opsora begleitet europäische IT-Führungskräfte bei genau diesen Herausforderungen. Ein typisches Engagement beginnt mit einem 30-minütigen Briefing und einem klaren Projektumfang innerhalb einer Woche.