Der KRITIS-taugliche M365-Tenant: Meine Referenzarchitektur von Identity bis SharePoint

Seit dem NIS2-Umsetzungsgesetz zählen in Deutschland rund 30.000 Unternehmen zu den regulierten Einrichtungen, nicht mehr nur die knapp 4.500 klassischen KRITIS-Betreiber von früher. Die BSI-Registrierungsfrist dafür lief am 6. März 2026 ab. Für die physische Resilienz nach dem KRITIS-Dachgesetz, zuständig ist hier nicht das BSI, sondern das BBK, endete die Registrierungsfrist gerade erst am 17. Juli 2026.

Zwei Fristen, zwei Behörden, ein gemeinsamer Kern: Wer jetzt noch glaubt, KRITIS-Absicherung sei ein Compliance-Häkchen, das man einmal setzt und dann vergisst, hat die eigentliche Anforderung nicht verstanden. Es geht um Meldefähigkeit (24 Stunden Frühwarnung, 72 Stunden erste Bewertung, spätestens 30 Tage Abschlussbericht) und um eine Architektur, die einen Vorfall überhaupt schnell genug erkennt, um diese Fristen einzuhalten.

Das hier ist meine Referenzarchitektur für einen Microsoft-365-Tenant, der dieser Realität standhält. Kein vollständiger Anforderungskatalog, sondern die Bausteine, die ich zuerst bauen würde, in der Reihenfolge, in der ich sie bauen würde.

Architektur im Überblick

Identity steht oben, nicht weil es zuerst im Alphabet kommt, sondern weil jede andere Schicht auf ihr aufbaut. Ein kompromittiertes Konto mit gültigem Token umgeht Device Compliance, umgeht Mail-Filter und umgeht DLP, solange die Anmeldung selbst nicht als riskant erkannt und gestoppt wird.

Lizenzrealität, bevor wir weitermachen

Ohne die richtigen Lizenzen ist der Rest dieses Artikels Theorie. Für die volle Architektur brauchst du im Kern:

Baustein	Lizenz
Risk-Based Conditional Access, Identity Protection	Microsoft Entra ID P2
Privileged Identity Management	Microsoft Entra ID P2 oder Entra ID Governance
Erweiterte Mail- und Collaboration-Security	Defender for Office 365 Plan 2
EDR, ASR Rules, Threat & Vulnerability Management	Defender for Endpoint Plan 2
CASB, Session Control, Shadow-IT-Discovery	Defender for Cloud Apps
Sensitivity Labels, DLP, Container-Labels	Microsoft Purview (in E5 enthalten)

In der Praxis heißt das meistens Microsoft 365 E5 oder E3 plus das E5-Security-Add-on. Wer hier spart, spart nicht am Preis, sondern an genau den Fähigkeiten, die eine KRITIS-Meldung in 24 Stunden überhaupt möglich machen.

Der wichtigste Baustein: Risk-Based Identity Protection

Alles andere in diesem Artikel ist verhandelbar in Reihenfolge und Tiefe. Das hier nicht. Wenn ich nur einen einzigen Baustein aus diesem Artikel umsetzen dürfte, wäre es dieser.

Der Grund ist simpel: In einem Cloud-first-Tenant gibt es kein Netzwerk-Perimeter mehr, das irgendetwas schützt. Jeder Zugriff auf Exchange, Teams, SharePoint oder Azure läuft über eine Anmeldung bei Entra ID. Wenn diese Anmeldung selbst nicht bewertet wird, ist jede andere Kontrolle in diesem Artikel nachgelagert.

Risikotyp	Was bewertet wird	Microsoft-Empfehlung
Sign-in Risk	Wahrscheinlichkeit, dass die konkrete Anmeldung nicht vom rechtmäßigen Besitzer stammt (anonyme IPs, unmögliche Reisegeschwindigkeit, Malware-verknüpfte IPs)	MFA erzwingen ab Medium und High
User Risk	Wahrscheinlichkeit, dass das Konto insgesamt kompromittiert ist (geleakte Zugangsdaten, wiederholte riskante Anmeldungen)	Risk Remediation erzwingen bei High

Der entscheidende Mechanismus dahinter ist Self-Remediation: Erfüllt ein Nutzer die geforderte Kontrolle (MFA bei Sign-in Risk, sicherer Passwortwechsel oder erneute starke Authentifizierung bei User Risk), gilt das Risiko als behoben. Kein Admin muss manuell eingreifen. Genau das macht das Modell in der Fläche überhaupt betreibbar, ohne dass ein SOC-Team jede einzelne Risk Detection einzeln abarbeiten muss.

Geräte: Intune und Defender for Endpoint

Erst wenn Identity steht, ergibt Device Compliance als zusätzliche Grant Control überhaupt Sinn, siehe dazu auch meinen Artikel zu Conditional Access. Für die Geräteseite selbst:

Security Baselines als Startpunkt, nicht als Endzustand. Die aktuelle Windows-Security-Baseline (25H2) ist ein solider Ausgangspunkt, ersetzt aber keine Anpassung an eure tatsächliche Umgebung.
ASR Rules in Block Mode, mit Cloud Block Level: High. Die Standardschutzregeln lassen sich in den meisten Umgebungen ohne große Vortests aktivieren, alles darüber hinaus solltet ihr erst im Audit-Modus laufen lassen, bevor ihr auf Block umstellt.
Achtung bei konfliktbehafteten ASR-Einstellungen über mehrere Profile hinweg: Intune bildet zwar eine Superset-Policy pro Gerät, aber widersprüchliche Einstellungen werden dabei stillschweigend aus dem Ergebnis herausgenommen, nicht etwa gemeldet. Das ist ein Punkt, den ich in Audits regelmäßig als blinden Fleck sehe.
Compliance Policy als Voraussetzung für die Grant Control „Require compliant device“ in Conditional Access, kombiniert mit MFA, nicht als Ersatz dafür.

Exchange Online: die Grundlagen zuerst

Bevor Defender for Office 365 irgendetwas Sinnvolles filtern kann, müssen die Basics stehen:

SPF, DKIM und DMARC für jede sendende Domain korrekt konfiguriert. Ohne saubere Authentifizierung landen legitime Mails im Quarantäne-Ordner, egal wie gut eure Anti-Phishing-Policy sonst eingestellt ist.
Basic Authentication vollständig deaktivieren, entweder über Security Defaults oder gezielt über Authentication Policies pro Protokoll (EAS, IMAP, POP, Authenticated SMTP, EWS, Outlook Anywhere). Ein KRITIS-Tenant mit offenem IMAP-Zugang über Basic Auth ist im Grunde ein offenes Scheunentor für Passwort-Spray-Angriffe.
Mailbox Audit Logging auf Organisationsebene aktiv lassen (AuditDisabled $false), das ist standardmäßig an, wird aber in älteren Tenants gelegentlich abgeschaltet vorgefunden.

Für Defender for Office 365 selbst würde ich nicht pauschal eine einzige Policy für alle fahren, sondern:

Strict Preset Security Policy für Geschäftsführung, Assistenzen der Geschäftsführung und historisch stark angegriffene Rollen wie Finance und HR, vorausgesetzt es gibt eine Admin-Kapazität, die blockierte Mails zeitnah prüft und freigibt.
Standard Preset Security Policy für alle übrigen Postfächer.

Preset Policies haben gegenüber selbstgebauten Custom Policies einen entscheidenden Vorteil für KRITIS-Kontexte: Microsoft pflegt die Einstellungen laufend gegen die aktuelle Bedrohungslage nach, ihr müsst nicht selbst hinterherpflegen, was gerade als Best Practice gilt.

Teams, SharePoint und OneDrive: Purview als Klammer

Zwei Label-Ebenen, die häufig verwechselt werden:

Item-Labels schützen einzelne Dateien und E-Mails, inklusive Verschlüsselung und Wasserzeichen.
Container-Labels schützen die Arbeitsumgebung selbst, also Teams, Microsoft-365-Gruppen und SharePoint-Sites, über externe Freigabe, Gastzugriff und Zugriff von nicht verwalteten Geräten.

Ohne Container-Labels kann ein Team mit offenem Gastzugriff entstehen, in dem trotzdem als „Vertraulich“ gekennzeichnete Dokumente landen. Die Site-Sicherheit und die Dokumenten-Klassifizierung laufen dann komplett auseinander. Für KRITIS-relevante Daten würde ich mindestens eine Label-Stufe definieren, die:

externe Freigabe komplett unterbindet
Zugriff von nicht verwalteten Geräten blockiert (in Kombination mit einer Authentication Context in Conditional Access)
private Teams-Sichtbarkeit für Gäste unterbindet

Ergänzend eine DLP-Policy für SharePoint und OneDrive, die das Teilen von Inhalten mit dem Label „Vertraulich“ oder mit erkannten sensiblen Informationstypen an externe Empfänger blockiert. Wichtig dabei: Item-Label und DLP-Regel arbeiten zusammen, das Container-Label allein schützt den Inhalt nicht, wenn jemand die Datei aus der Site herunterlädt und unverschlüsselt weiterschickt.

Defender for Cloud Apps als Klammer über allem

Defender for Cloud Apps würde ich nicht isoliert betrachten, sondern als die Schicht, die Conditional-Access-Entscheidungen in die tatsächliche Session hinein verlängert. Über Conditional Access App Control lassen sich Dinge steuern, die reine Conditional-Access-Grant-Controls nicht abdecken:

Download-Blockierung sensibler Inhalte auf nicht verwalteten Geräten, in Echtzeit und mit Inhaltsprüfung
Blockierung des Uploads unklassifizierter Dateien mit sensiblem Inhalt
Malware-Scan bei Up- und Downloads gegen Microsoft Threat Intelligence
Erzwingen einer erneuten Authentifizierung mitten in der Session, wenn eine sensible Aktion erkannt wird

Dafür braucht es eine eigene Conditional-Access-Policy mit der Session-Control „Use Conditional Access App Control“, die den Traffic durch Defender for Cloud Apps routet. Ohne diesen Schritt bleibt Defender for Cloud Apps im Wesentlichen ein Discovery- und Reporting-Werkzeug für Schatten-IT, was für sich genommen schon wertvoll ist, aber eben keine aktive Kontrolle.

Monitoring und die eigentliche Meldepflicht

Der Grund, warum ich Monitoring nicht als Nebensache behandle: Die 24-Stunden-Frühwarnfrist beginnt nicht mit der Entscheidung, ob ihr meldet, sondern mit dem Zeitpunkt, an dem der Vorfall erkennbar gewesen wäre. Fünf getrennte Portale für Endpoint, Mail, Identity und Cloud Apps, zwischen denen ein Mensch händisch korrelieren muss, sind für diese Frist schlicht zu langsam.

Defender XDR korreliert Signale aus Defender for Endpoint, Defender for Office 365, Defender for Identity und Defender for Cloud Apps zu einem einzigen Incident, inklusive automatischer Angriffskette. Das ist der Unterschied zwischen „wir haben irgendwo vier verdächtige Alerts“ und „wir haben einen Incident mit klarem Anfang, Verlauf und betroffenen Systemen“, den ihr tatsächlich innerhalb von 24 Stunden bewerten könnt.

Und ein regulatorischer Punkt, der in vielen Projekten durcheinandergeht: NIS2-Cybervorfälle meldet ihr über das BSI-Meldeportal, die physische Resilienz nach KRITIS-Dachgesetz läuft über das BBK. Zwei unterschiedliche Behörden, zwei unterschiedliche Registrierungsprozesse, beide über „Mein Unternehmenskonto“ mit ELSTER-Zertifikat vorgeschaltet. Wer das vermischt, verliert in einem echten Vorfall wertvolle Zeit mit der Frage, wo überhaupt gemeldet werden muss.

Meine Priorisierung, wenn Zeit und Budget begrenzt sind

Realistisch baut niemand alles gleichzeitig. Wenn ich priorisieren müsste:

Risk-Based Conditional Access, phishing-resistente MFA, PIM. Das ist der Baustein, der jeden anderen erst wirksam macht. Ohne ihn ist alles Weitere Absicherung eines Perimeters, den es in der Cloud gar nicht mehr gibt.
Device Compliance und ASR Rules. Die zweite Kontrollebene, die verhindert, dass ein kompromittiertes Gerät trotz sauberer Identität zum Einfallstor wird.
Defender for Office 365 mit sauberer Mail-Authentifizierung. E-Mail bleibt der häufigste Erstzugriffsvektor, das ändert sich seit Jahren nicht.
Sensitivity Labels und DLP für Teams und SharePoint. Schützt die Daten dort, wo Identity und Device bereits versagt haben könnten.
Defender for Cloud Apps als letzte Kontrollebene. Wichtig, aber am wenigsten wirksam, wenn die ersten vier Schichten nicht stehen.

Diese Reihenfolge ist kein Zufall. Sie folgt genau der Architektur-Grafik von oben. Und sie ist der Grund, warum ich am Anfang dieses Artikels so viel Zeit auf Identity Protection verwendet habe, während der Rest vergleichsweise knapp bleibt: In einem KRITIS-Tenant ist Identity nicht ein Baustein unter vielen. Es ist der Baustein, der entscheidet, ob alle anderen überhaupt noch etwas wert sind.