Wer regelmäßig in Microsoft-365-Tenants unterwegs ist, kennt das: Mit der Standardkonfiguration kommt man fast nie aus. Die Angriffsfläche wird größer, mit Copilot oder SharePoint Pages kommen neue Funktionen dazu, und die alten Fehler verschwinden trotzdem nicht. Ungesicherte Postfächer, Notfallkonten, von denen niemand etwas weiß, oder zu lasche Authentifizierungsmethoden begegnen mir immer wieder. Zum Jahreswechsel nehme ich mir deshalb gern die Zeit, meine Sicherheits-Baseline für Microsoft 365 durchzugehen und bei Kunden nachzuziehen, was im Tagesgeschäft liegen geblieben ist.

Admins und Notfallkonten brauchen phishing-resistente MFA

Alles steht und fällt mit einer starken Authentifizierung. In den meisten Tenants, die ich prüfe, dürfen sich Admins noch viel zu oft per SMS oder Anruf anmelden. Für Administratoren sind phishing-resistente Methoden Pflicht, also FIDO2-Sicherheitsschlüssel, zertifikatbasierte Authentifizierung oder, mit Einschränkungen, Microsoft Authenticator mit Number Matching und Authentifizierungsschutz. Außerdem braucht jeder Tenant mindestens zwei Notfallkonten, die ausschließlich mit FIDO2 oder CBA abgesichert sind und niemals synchronisiert werden. Damit sie im Alltag nicht stören, nimmt man sie von Conditional Access aus, testet sie aber trotzdem in regelmäßigen Abständen.

Als Orientierung empfehle ich die offizielle Zero-Trust-Übersicht. Die Empfehlungen für Break-Glass-Konten sollten umgesetzt sein, bevor etwas schiefgeht. Und lassen Sie bitte nie einen synchronisierten On-Prem-Admin als Cloud-Admin zu. Was daraus werden kann, hat Storm-0501 deutlich gezeigt.

Conditional Access braucht solide Basisrichtlinien und blockiert den Device Code Flow

Mit den richtigen Richtlinien ist Conditional Access (CA) eines der wirksamsten Werkzeuge überhaupt. Als Erstes sehe ich mir die Basisrichtlinien an: MFA für alle Benutzer außerhalb vertrauenswürdiger Standorte, das Blockieren der Legacy-Authentifizierung, Ausnahmen für die Notfallkonten und das gern vergessene Blockieren des Device Code Flows, mit dem man bösartige OAuth-Apps ausbremst. Angreifer nutzen den Device Code Flow besonders gern als Einstieg, wie der Fall Midnight Blizzard zeigt. Die Umsetzung im Entra-Portal habe ich in einem eigenen Beitrag beschrieben.

Mein Tipp: Neue CA-Richtlinien starte ich immer im Modus „Report-only“, beobachte eine Weile, was sie bewirken würden, und schalte sie erst danach scharf. Damit vermeidet man unangenehme Überraschungen im laufenden Betrieb.

Wer CA strukturiert einführen möchte, findet in meinem Artikel Conditional Access in Microsoft Entra ID: Die ersten Richtlinien und in der offiziellen Planungsanleitung von Microsoft einen guten Einstieg.

Ohne App-Governance bleiben OAuth-Zugriffe im Verborgenen, wie Midnight Blizzard gezeigt hat

Etliche Angriffe aus den Jahren 2023 und 2024 haben deutlich gemacht, wie riskant unkontrollierte App-Registrierungen und OAuth-Zugriffe sind. Fast in jedem Tenant stoße ich noch auf „Zombie-Apps“ mit viel zu weitreichenden Berechtigungen oder auf Benutzereinwilligungen (User Consent) für Drittanbieter, die niemand kennt. Wer hier keine App-Governance betreibt, weiß schlicht nicht, was passiert. Unter Microsoft Entra → Identität → Anwendungen → Unternehmensanwendungen kontrolliere ich regelmäßig, welche App welche Rechte hat, und lege Consent-Richtlinien fest. Defender for Cloud Apps zeigt zusätzlich, welche Apps kaum genutzt werden oder riskant sind. Die wichtigsten Einstellungen für die OAuth-Governance fasst mein Beitrag App-Governance für OAuth: Sichtbarkeit und Kontrolle zusammen.

Wie Angreifer, OAuth-App und Benutzer zusammenspielen, lässt sich mit einem einfachen Ablaufdiagramm gut zeigen:

flowchart TD
Angreifer["Angreifer"] --> Phishing["Phishing-URL"]
Phishing --> Nutzer["Benutzer"]
Nutzer --> Consent["OAuth Consent"]
Consent --> App["bösartige App"]
App --> Zugriff["Zugriff auf Daten"]

Abbildung: So verschaffen sich Angreifer über den OAuth-Consent Zugriff auf Cloud-Daten.

Defender for Office, blockierte Weiterleitungen und Manipulationsschutz gehören zur Grundausstattung

Die voreingestellten Sicherheitsrichtlinien in Defender for Office 365 (Plan 1+) sind Pflicht, werden in der Praxis aber selten optimal genutzt. Ich kontrolliere jedes Mal, ob die „Preset Security Policies“ aktiv sind und ob eigene, schwächere Regeln sie nicht wieder aushebeln (Details dazu im Blog). Externe Weiterleitungen sperre ich grundsätzlich, damit keine Daten unbemerkt abfließen (mehr dazu hier). Der Manipulationsschutz (Tamper Protection) für Defender for Endpoint gehört auf jedes verwaltete Gerät im Tenant. Ausrollen lässt er sich zentral über das Intune- und das Defender-Portal (siehe meinen Beitrag zu Tamper Protection).

Ebenfalls wichtig sind die BitLocker-Schlüssel. Sie müssen wirklich zentral im Entra-ID-Tenant oder in Intune liegen, und die Wiederherstellung muss auch funktionieren. Nach Rollouts unter Zeitdruck fehlen häufig noch einzelne Geräte, und das kann im Ernstfall richtig teuer werden. Mehr dazu steht in meinen Lehren zur BitLocker-Wiederherstellung.

Regelmäßige Backups bewahren vor Datenverlust

Microsoft 365 Backup für Exchange, SharePoint und OneDrive ist inzwischen allgemein verfügbar (siehe hier). Seitdem gehört zu meiner Prüfung die Frage, ob die wichtigsten Datenquellen regelmäßig gesichert werden und ob es einen Wiederherstellungsplan gibt, der über die normale Versionierung hinausgeht. In Azure muss der Azure-Backup-Tresor mindestens auf „immutable“ stehen, damit er einem Ransomware-Angriff standhält. Der Aufwand dafür ist gering, die Wirkung groß (mehr dazu im Beitrag zum Azure Backup Immutable Vault).

Wenn die Backup-Strategie Lücken hat, retten einen auch der Papierkorb oder einzelne Versionen nicht mehr. Meine Erfahrung: Wer jetzt Zeit und Geld investiert, spart sich im Ernstfall viel Ärger und die Diskussion mit der IT-Versicherung gleich mit.

Copilot zwingt dazu, Oversharing einzudämmen

Seit es Copilot für Microsoft 365 gibt, beschäftigt das Thema Oversharing praktisch jedes Unternehmen. In vielen Tenants, die ich betreue, sind SharePoint-Berechtigungen und Sensitivity Labels noch nicht zu Ende gedacht, die Suchbereiche zu weit gefasst oder die DLP-Richtlinien zu grob. Für die Testphase von Copilot ist „Restricted SharePoint Search“ sehr hilfreich, weil man damit nicht gleich sämtliche Daten freigibt (siehe Blogbeitrag).

Genauso wichtig ist, dass die Sensitivity Labels in Purview auch Copilot abdecken. Die Audit-Logs für Copilot-Interaktionen sollten Sie früh aktivieren, damit die Compliance-Anforderungen erfüllt sind (mehr dazu und [/blog/copilot-interaktionen-audit-aufbewahrung-purview]).

Die Baseline bleibt eine Daueraufgabe

Eine perfekte Sicherheits-Baseline für Microsoft 365 gibt es nicht, weil sich das Ziel ständig verschiebt. Die genannten Punkte stehen für mich 2025 aber fest. Es wird neue Angriffe und neue Funktionen geben, doch die grundlegenden Kontrollen bleiben das Fundament. Wer sie regelmäßig überprüft, nachschärft und dokumentiert, erspart sich viele unnötige Risiken. In der Praxis sehe ich immer wieder, dass Schwachstellen selten an der Technik liegen, sondern daran, dass jemand nicht aufmerksam oder nicht konsequent genug war. Eine Baseline arbeitet man nicht einmal ab wie eine Migration, man pflegt sie fortlaufend. Genau das macht die Arbeit in der Cloud spannend, aber auch anspruchsvoll.