Sicherheit und Compliance in Microsoft 365: Was Microsoft schützt, und was Sie selbst tun müssen

Microsoft 365 ist für die meisten Unternehmen die meistgenutzte Anwendung überhaupt und damit ein attraktives Ziel. Steigende Ransomware- und Phishing-Wellen, verschärfte Compliance-Anforderungen (DSGVO, NIS2) und der Zugriff von überall und jedem Gerät machen Sicherheit und Compliance in M365 zur Daueraufgabe. Die entscheidende Einsicht: Microsoft schützt die Plattform. Ihre Daten und Ihre Konfiguration schützen Sie selbst.

Dieser Satz klingt nach Kleingedrucktem. Er ist die Ursache der meisten M365-Sicherheitsvorfälle, die wir sehen.

Was Microsoft übernimmt

Microsoft sichert die Plattform auf drei Ebenen:

• Physisch: biometrische Zugangskontrollen, 24/7-Sicherheit und Videoüberwachung in den Rechenzentren
• Logisch: automatisiertes Server-Management, Personalprüfung, kontrollierter Administratorzugriff, Anti-Malware
• Daten: Mandantentrennung über unabhängige „Container“ und Entra-ID-Isolation

Das ist die Grundlage, aber es ist die Sicherheit der Plattform, nicht die Sicherheit Ihrer Nutzung.

Wo die Verantwortungsgrenze tatsächlich verläuft

Konkret bedeutet das: Microsoft garantiert, dass der Dienst läuft, dass Ihre Daten von denen anderer Mandanten getrennt sind und dass die Infrastruktur darunter gepflegt wird.

Microsoft garantiert nicht:

• dass Ihre Berechtigungen sinnvoll gesetzt sind,
• dass ein kompromittiertes Konto auffällt,
• dass eine versehentlich weltweit freigegebene Datei erkannt wird,
• dass Sie nach einem Ransomware-Befall oder einer versehentlichen Massenlöschung auf einen brauchbaren Wiederherstellungspunkt zugreifen können.

Der letzte Punkt überrascht regelmäßig. Die integrierten Aufbewahrungs- und Papierkorb-Mechanismen sind kein Backup im betrieblichen Sinn: Sie halten Daten für einen begrenzten Zeitraum und decken nicht jeden Fehlerfall ab. Wer eine bestimmte Wiederherstellungsfähigkeit braucht (insbesondere über längere Zeiträume oder mit granularer Wiederherstellung), muss sie separat herstellen und regelmäßig testen. Eine Wiederherstellung, die nie geprobt wurde, ist eine Annahme, keine Fähigkeit.

Was Sie selbst konfigurieren müssen

Datenschutz:

• Rights Management Service: Verschlüsselung und identitätsbasierte Richtlinien
• Vertraulichkeitsbezeichnungen (Sensitivity Labels): Klassifizierung, die am Dokument haftet, auch wenn es den Tenant verlässt
• S/MIME und Message Encryption für E-Mail
• Integrierte Anti-Malware- und Spam-Filter

Zugriffssteuerung:

• Single Sign-On über Entra ID
• Multi-Faktor-Authentifizierung: die wirksamste Einzelmaßnahme, aber nicht mehr ausreichend allein
• Conditional Access: die eigentliche Steuerungsebene
• Mobile Device Management mit Remote-Wipe

Compliance:

• Data Loss Prevention (DLP): sensible Daten erkennen und blockieren
• Auditing und Aufbewahrungsrichtlinien
• eDiscovery: Beweissicherung für rechtliche Anforderungen

Die Lücken der Standardkonfiguration

Ein frisch aufgesetzter oder über Jahre gewachsener Tenant hat typischerweise dieselben Schwachstellen. Diese fünf lohnen eine Prüfung, bevor irgendein Produkt gekauft wird:

Veraltete Authentifizierungsprotokolle. Ältere Protokolle kennen keinen zweiten Faktor. Solange sie irgendwo aktiv sind, existiert ein Weg an der MFA vorbei und Angreifer suchen genau danach.

MFA nicht flächendeckend. „Wir haben MFA“ bedeutet in der Praxis oft: für die Administratoren. Übrig bleiben Dienstkonten, externe Gäste, Postfächer ohne persönlichen Nutzer und der eine Bereich, in dem es „nicht funktioniert hat“.

Zu viele privilegierte Konten. Globale Administratorrechte werden vergeben und selten wieder entzogen. Jede dieser Identitäten ist ein Vollzugriff auf den gesamten Tenant.

Unkontrollierte externe Freigaben. Standardeinstellungen erlauben oft mehr, als beabsichtigt ist. Der Unterschied zwischen „für Personen in meiner Organisation“ und „für alle mit dem Link“ ist ein Klick und ein Datenschutzvorfall.

Postfachregeln. Die automatische Weiterleitung nach außen ist ein klassischer Schritt nach einer Kontoübernahme: unauffällig, dauerhaft, und sie überlebt sogar eine Passwortänderung, wenn niemand die Regel entfernt.

Warum MFA allein nicht mehr reicht

MFA bleibt die wirksamste Einzelmaßnahme. Sie ist nur kein Endzustand mehr.

Angreifer haben sich angepasst. MFA-Ermüdung setzt auf Wiederholung: Wer nachts um zwei die zwölfte Push-Benachrichtigung bekommt, bestätigt irgendwann, um Ruhe zu haben. Adversary-in-the-Middle-Phishing geht weiter und umgeht den zweiten Faktor vollständig: Die gefälschte Anmeldeseite leitet die Eingaben in Echtzeit an den echten Dienst weiter, der Nutzer bestätigt seinen zweiten Faktor korrekt und der Angreifer greift das entstandene Sitzungstoken ab. Damit ist er angemeldet, ohne das Passwort zu kennen und ohne den zweiten Faktor zu besitzen.

Was dagegen hilft:

• Phishing-resistente Verfahren: FIDO2-Sicherheitsschlüssel oder zertifikatsbasierte Anmeldung binden die Authentifizierung an die echte Domäne. Eine gefälschte Seite kann sie nicht abfangen.
• Nummernabgleich statt einfacher Bestätigung: macht das gedankenlose Wegdrücken unmöglich.
• Conditional Access: Zugriff nicht nur an „wer“, sondern an Gerätezustand, Standort, Anwendung und Risikobewertung binden.
• Überwachung von Sitzungsanomalien: eine Sitzung, die plötzlich aus einem anderen Land oder mit einem anderen Client-Fingerabdruck weiterläuft, ist ein Befund.

Conditional Access ist die eigentliche Steuerungsebene

MFA beantwortet die Frage „Ist das die richtige Person?“. Conditional Access beantwortet die Frage, die im Alltag mehr entscheidet: „Unter welchen Umständen darf diese Person auf diese Anwendung zugreifen?”

Nützliche Ausgangspunkte:

• Zugriff auf sensible Anwendungen nur von verwalteten, richtlinienkonformen Geräten
• Blockade veralteter Authentifizierungsprotokolle über eine ausnahmslose Richtlinie
• Für privilegierte Rollen strengere Bedingungen als für normale Nutzer
• Risikobasierte Bedingungen: bei auffälligen Anmeldungen zusätzliche Prüfung erzwingen
• Ausnahmen dokumentieren und befristen, sonst werden aus Übergangslösungen dauerhafte Löcher

Compliance: was M365 kann und wo es aufhört

Die integrierten Compliance-Werkzeuge sind leistungsfähig. Drei Hinweise aus der Praxis:

DLP wirkt nur mit sauberer Klassifizierung. Regeln, die auf Muster wie Kreditkarten- oder Ausweisnummern reagieren, funktionieren zuverlässig. Der eigentliche Wert entsteht erst mit Vertraulichkeitsbezeichnungen, die zu Ihrem Geschäft passen und die jemand pflegen muss.

Audit-Protokolle brauchen bewusste Konfiguration. Prüfen Sie, welche Ereignisse überhaupt protokolliert werden und wie lange sie vorgehalten werden. Eine Untersuchung, die drei Monate nach dem Vorfall beginnt, scheitert an einer Aufbewahrung von 90 Tagen oder eben nicht. Warum Aufbewahrungsdauer bei Detection und Nachweispflichten so schwer wiegt, steht in Welche Log-Quellen braucht ein SIEM wirklich.

Vieles hängt an der Lizenz. Ein erheblicher Teil der fortgeschrittenen Funktionen: risikobasierte Zugriffssteuerung, erweitertes DLP, längere Audit-Aufbewahrung: ist an höhere Pläne oder Zusatzlizenzen gebunden. Prüfen Sie vor der Planung, was Ihre Lizenzen tatsächlich hergeben, statt es nach dem Konzept festzustellen.

Warum ein CASB den Unterschied macht

Die nativen Werkzeuge sind gut: enden aber an der Grenze von Microsoft 365. Ein Cloud Access Security Broker (CASB) dehnt Ihre internen Sicherheitsrichtlinien auf alle genutzten Cloud-Anwendungen aus und macht Schatten-IT sichtbar.

Das ist keine akademische Ergänzung. Daten verlassen M365 im Alltag ständig: in Dateitransfer-Dienste, Projektwerkzeuge, KI-Assistenten, private Speicherkonten. Eine Richtlinie, die nur innerhalb von M365 gilt, endet genau dort, wo das Risiko anfängt.

Wie das mit Zscaler konkret aussieht, vom lokalen Internet-Breakout bis zur Tenant Restriction, steht in Zscaler Internet Access & Microsoft 365.

Genau das ist der Übergang von „M365 absichern“ zu einer durchgängigen Zero-Trust-Architektur, in der Identität und Kontext über Zugriff entscheiden, nicht der Standort.

Eine Prüfreihenfolge, die sich bewährt hat

1. Veraltete Authentifizierungsprotokolle abschalten
2. MFA lückenlos ausrollen, inklusive Dienst- und Gastkonten
3. Privilegierte Rollen reduzieren und befristen
4. Conditional Access für sensible Anwendungen und privilegierte Rollen
5. Externe Freigaben und automatische Weiterleitungen prüfen
6. Audit-Protokollierung und Aufbewahrung an den Untersuchungsbedarf anpassen
7. Klassifizierung und DLP an den tatsächlich schützenswerten Daten ausrichten
8. Wiederherstellungsfähigkeit prüfen und einmal wirklich wiederherstellen

Die ersten fünf Punkte kosten Konfigurationsaufwand und kein Budget. Sie schließen die Lücken, über die reale Angriffe laufen.

Wie Cloud Cape unterstützt

Die saubere Tenant-Konfiguration ist Pflicht; die Ausweitung auf eine durchgängige Zugriffsarchitektur ist die Kür. Unser Managed Security Service Edge bringt CASB, DLP und identitätsbasierten Zugriff zusammen: von Core über Plus bis Elite, betrieben durch Cloud Cape und integriert mit unserem SOC. So wird Microsoft 365 nicht nur richtig konfiguriert, sondern Teil einer belastbaren Zero-Trust-Strategie.

Sprechen Sie mit uns über Managed SSE. Wir bringen Microsoft 365 und Zero Trust zusammen.