NIS2-Compliance für Microsoft 365: Eine praktische Roadmap
NIS2 ist kein Checklistenprojekt. Hier ist eine strukturierte, M365-spezifische Roadmap für IT-Teams, die sich erstmals mit der Richtlinie befassen.
Die meisten M365-Umgebungen haben dieselben strukturellen Schwächen. Hier ist, wonach Sie suchen sollten.
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.
Governance in Microsoft 365 ist nicht das Gleiche wie Berechtigungstabellen oder vierteljährliche Audits. Es sind die Strukturen, Richtlinien und Kontrollen, die bestimmen, wie die Daten Ihres Unternehmens gespeichert, abgerufen, geteilt und geschützt werden — und wer für jeden dieser Bereiche verantwortlich ist. Wenn Governance fehlt oder unvollständig ist, wird die Microsoft 365-Plattform selbst zur Haftung: Daten häufen sich ohne Struktur an, Zugriffe weiten sich ohne Überprüfung aus, und die Compliance-Posture verschlechtert sich still, bis ein Vorfall oder ein Audit die Lücken sichtbar macht.
Nach der Bewertung von mehr als 50 Microsoft 365-Umgebungen in europäischen mittelständischen Unternehmen tauchen immer wieder dieselben fünf Governance-Versäumnisse auf. Keines davon ist ein obskurer Randfall. Alle sind behebbar.
Wie es aussieht: Jeder Benutzer im Unternehmen kann eine Microsoft Teams-Gruppe erstellen, die automatisch eine SharePoint-Website, ein freigegebenes Postfach, ein OneNote-Notizbuch und ein Planner-Board bereitstellt. Zwei Jahre nach der Einführung hat der Mandant 400 Teams und 600 SharePoint-Websites, von denen die meisten von Personen betrieben werden, die das Unternehmen inzwischen verlassen haben oder die vergessen haben, dass sie die Gruppe erstellt haben.
Das Risiko: Verwaiste Teams und Websites sammeln Dateien, Konversationen und geteilte Links an, ohne dass ein Verantwortlicher sie überprüft oder verwaltet. Externe Gäste, die für ein einzelnes Projekt eingeladen wurden, bleiben jahrelang im Mandanten. Sensible Dokumente existieren in Kanälen, die nie angemessen eingeschränkt wurden.
So sieht es gut aus: Die Teams-Erstellung ist geregelt — nicht blockiert, aber kontrolliert. Ein Anfrageprozess erfasst den Geschäftszweck, weist einen Verantwortlichen zu und wendet Namenskonventionen an. Das Lebenszyklusmanagement läuft vierteljährlich: Verantwortliche erhalten eine Aufforderung zur Erneuerung oder Archivierung. Inaktive Teams werden nach einem definierten Zeitraum automatisch archiviert. Gastzugang hat ein Ablaufdatum.
Wie es aussieht: Dokumente in SharePoint und OneDrive tragen keine Klassifizierung. Es gibt keinen Unterschied zwischen einem internen Entwurfsprotokoll und einem vertraulichen Vorstandsdokument — beide existieren im selben unstrukturierten Zustand. Wenn Benutzer Dateien extern teilen, kann die Plattform sie nicht warnen, da sie nicht weiß, ob etwas sensibel ist.
Das Risiko: Übermäßiges Teilen geschieht stillschweigend. Ohne Klassifizierung können Data-Loss-Prevention-Richtlinien nicht gezielt eingesetzt werden. Wenn Microsoft Copilot eingeführt wird — viele Unternehmen planen dies — wird es Dokumente auf der Grundlage von Berechtigungen anzeigen, nicht danach, ob diese Dokumente angezeigt werden sollten. Klassifizierung ist die Voraussetzung, die niemand erfüllt hat.
So sieht es gut aus: Eine in Microsoft Purview definierte Sensibilitätslabel-Taxonomie: mindestens Öffentlich, Intern, Vertraulich und Streng Vertraulich. Labels werden automatisch auf Dateien angewendet, die bestimmte Kriterien erfüllen, und manuell von Benutzern für alles andere. DLP-Richtlinien blockieren oder warnen, wenn Inhalte der Kategorie "Vertraulich" oder höher extern geteilt werden.
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 anfragenWie es aussieht: Das IT-Team hat globalen Administratorzugriff auf seinen primären Konten, die auch für den täglichen E-Mail-Verkehr genutzt werden. Mehreren Benutzern wurden für ein Migrationsprojekt vor drei Jahren SharePoint-Administratorrechte erteilt — und sie haben diese noch immer. Dienstkonten haben Benutzerlizenzen und globale Administratorrechte.
Das Risiko: Jedes überprivilegierte Konto ist eine Angriffsfläche. Ein kompromittiertes globales Administratorkonto gibt einem Angreifer die vollständige Kontrolle über den Mandanten — die Möglichkeit, alle Postfächer zu lesen, Daten zu exfiltrieren, Backups zu löschen und das IT-Team auszusperren. Die meisten Ransomware-Angriffe auf M365-Mandanten nutzen privilegierte Konten aus, keine technischen Schwachstellen in der Plattform.
So sieht es gut aus: Least Privilege als Prinzip, nicht als Wunsch. Globale Administratorrollen reserviert für Notfall-Break-Glass-Konten mit FIDO2-MFA. Privileged Identity Management (PIM) in Entra ID für zeitlich begrenzte Rechteerweiterung. Regelmäßige Zugriffsüberprüfungen zur Bereinigung von Rollenzuweisungen. Dienstkonten nur mit den tatsächlich benötigten Berechtigungen.
Wie es aussieht: MFA ist in den alten benutzerbezogenen Einstellungen "aktiviert", aber es gibt keine Conditional-Access-Richtlinien, die sie erzwingen. Oder es gibt CA-Richtlinien, aber sie enthalten Ausnahmen für Legacy-Authentifizierungsprotokolle, die bei der Einführung hinzugefügt und nie entfernt wurden.
Das Risiko: Legacy-Authentifizierungsprotokolle umgehen MFA. Wenn SMTP AUTH, IMAP oder Basic Authentication in Ihrem Mandanten noch aktiviert sind, kann ein Angreifer mit einem kompromittierten Passwort über IMAP auf dieses Konto zugreifen, ohne eine MFA-Abfrage auszulösen. "Wir haben MFA" ist keine Sicherheitsposture, wenn Legacy-Authentifizierung noch offen ist.
So sieht es gut aus: Ein grundlegendes Conditional-Access-Richtlinienset: MFA für alle Benutzer erforderlich (keine Ausnahmen für Netzwerkstandort), Legacy-Authentifizierung vollständig blockiert, konformes Gerät für den Zugriff auf sensible Anwendungen erforderlich, Integration mit Entra ID Identity Protection für Anmeldungsrisiko und Benutzerrisiko. Diese Richtlinien werden vierteljährlich überprüft.
Wie es aussieht: Die externe Freigabe in SharePoint ist auf Mandantenebene ohne Einschränkungen aktiviert. Benutzer teilen Dateien und Ordner über "Jeder mit dem Link"-Links, die keine Anmeldung erfordern und kein Ablaufdatum haben. Die externe Zusammenarbeit erfolgt über Gastkonten, die nie überprüft wurden.
Das Risiko: "Jeder"-Links sind faktisch öffentliche URLs. Die Datei, auf die sie verweisen, ist für jeden zugänglich, der diesen Link erhält — weitergeleitet per E-Mail, geteilt in einem Chat oder von einer Suchmaschine indexiert. Es gibt keinen Prüfpfad. Für jedes Unternehmen, das personenbezogene Daten, geschäftlich sensible Informationen oder vertrauliche Inhalte verwaltet, ist dies eine erhebliche Exponierung.
So sieht es gut aus: Externe Freigabe auf der restriktivsten Stufe konfiguriert, die Geschäftsanforderungen erlauben — in der Regel "Neue und vorhandene Gäste" statt "Jeder". "Jeder"-Links deaktiviert oder auf anonyme Ansicht mit erzwungenem Ablaufdatum beschränkt. Externe Gastkonten in Zugriffsüberprüfungen einbezogen. DLP-Richtlinie blockiert externe Freigabe für sensible Daten.
Die fünf oben genannten Lücken sind häufig, aber sie haben eine gemeinsame Ursache: Microsoft 365-Governance wurde nie als fortlaufendes Programm behandelt. Sie wurde entweder gar nicht eingerichtet oder bei der Einführung einmalig konfiguriert und nicht mehr überprüft.
Unternehmen, die eine saubere M365-Posture aufrechterhalten, tun nichts Heroisches. Sie führen vierteljährliche Zugriffsüberprüfungen durch. Sie haben eine Teams-Lebenszyklusrichtlinie. Sie wissen, wie viele externe Gäste in ihrem Mandanten sind und warum. Governance ist der Unterschied zwischen einer Microsoft 365-Umgebung, die in Kontrolle wächst, und einer, die in Komplexität wächst.
Wenn Sie verstehen möchten, wo Ihr Unternehmen gegenüber diesen fünf Benchmarks steht, ist eine strukturierte M365-Governance-Bewertung der Ausgangspunkt. Sie dauert zwei bis drei Wochen und liefert eine priorisierte Sanierungsroadmap.
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.