Microsoft 365 absichern: Conditional Access, Defender und Audit Logs richtig konfigurieren

Key Takeaways

• Conditional Access ist kein optionales Feature – ohne Richtlinien sind alle M365-Konten potenziell ungeschützt
• Microsoft Defender for Office 365 erkennt Phishing, BEC und Malware-Anhänge nur, wenn er korrekt konfiguriert ist
• Audit Logs müssen aktiv aktiviert werden – standardmäßig ist nicht alles protokolliert
• NIS-2 und DSGVO verlangen nachweisliche Zugriffskontrollen und Protokollierungspflichten – M365 kann das erfüllen, aber nur mit gezielter Konfiguration

Warum Microsoft 365 ohne Härtung ein Einfallstor ist

Microsoft 365 ist in deutschen KMU inzwischen Standard – Exchange Online, Teams, SharePoint, OneDrive. Und genau deshalb ist es das primäre Ziel für Angreifer. Credential Stuffing, Phishing-Kampagnen, Business Email Compromise (BEC) – der Angriffspfad führt fast immer über kompromittierte M365-Konten.

Das Problem: Die meisten M365-Tenants sind im Auslieferungszustand konfiguriert. Microsoft aktiviert aus Kompatibilitätsgründen keine restriktiven Richtlinien standardmäßig. Was bedeutet das in der Praxis?

• Kein MFA-Zwang für normale Benutzerkonten
• Kein eingeschränkter Zugriff basierend auf Gerät oder Standort
• Audit Logs für bestimmte Aktionen nicht aktiviert
• Defender-Richtlinien auf dem niedrigsten Schutzniveau

Ein Angreifer mit gestohlenen Zugangsdaten kann sich von jedem Land der Welt einloggen, E-Mails lesen, SharePoint-Daten herunterladen – und das oft wochenlang unbemerkt. Laut Microsoft Detection and Response Team (DART) vergehen im Median 207 Tage zwischen Erstzugang und Entdeckung bei Tenants ohne aktives Monitoring.

Conditional Access: Das Fundament der M365-Sicherheit

Conditional Access ist das Herzstück der Azure AD / Entra ID Sicherheitsarchitektur. Es erlaubt, Zugriff auf M365-Ressourcen an Bedingungen zu knüpfen: Wer darf sich von wo, mit welchem Gerät, zu welcher Zeit einloggen?

Mindest-Richtlinien für jeden M365-Tenant

1. MFA für alle Benutzer (außer Break-Glass-Konten)

Die wichtigste Richtlinie überhaupt. Kein Konto ohne MFA.

Policy: Require MFA for all users
Assignments:
  Users: All users
  Exclude: Break-Glass-Gruppe, Service Accounts
  Cloud apps: All cloud apps
Conditions:
  Device platforms: Any
  Locations: Any
Grant controls:
  Require: Multi-factor authentication

2. Blockieren risikoreicher Anmeldeversuche

Azure AD Identity Protection bewertet jede Anmeldung mit einem Risikowert. Konten mit hohem Anmelderisiko – etwa nach erkanntem Credential Stuffing oder Anmeldungen aus einem Tor-Exit-Node – sollten automatisch blockiert werden.

Policy: Block high-risk sign-ins
Assignments:
  Users: All users
Conditions:
  Sign-in risk: High
Grant controls:
  Block access

3. Zugriff nur von compliant oder hybrid-joined Geräten

Für Tenants mit Microsoft Intune: Nur verwaltete Geräte dürfen auf Exchange, SharePoint und Teams zugreifen. Das verhindert Zugriff über private, unkontrollierte Geräte.

Policy: Require compliant device for M365 apps
Assignments:
  Cloud apps: Office 365
Conditions:
  Device platforms: Windows, macOS, iOS, Android
Grant controls:
  Require: Device to be marked as compliant
  OR Require: Hybrid Azure AD joined device

4. Legacy Authentication blockieren

Protokolle wie IMAP, POP3, SMTP AUTH und MAPI unterstützen kein modernes MFA. Angreifer nutzen sie gezielt, um MFA-Richtlinien vollständig zu umgehen – ein häufig übersehener Angriffsvektor.

Policy: Block legacy authentication
Assignments:
  Users: All users
Conditions:
  Client apps: Exchange ActiveSync clients,
               Other clients (legacy auth)
Grant controls:
  Block access

Häufige Konfigurationsfehler bei Conditional Access

• Break-Glass-Konten vergessen: Mindestens zwei Notfall-Administratorkonten ohne Conditional Access müssen existieren und deren Passwörter offline gespeichert sein – sonst riskiert man einen kompletten Tenant-Ausschluss
• Named Locations nicht gepflegt: IP-Bereiche von Bürostandorten sollten definiert sein, um gezieltere standortbasierte Richtlinien zu ermöglichen
• Report-only-Modus vergessen: Neue Richtlinien immer zuerst im Report-only-Modus testen und mindestens zwei Wochen beobachten, bevor sie scharf geschaltet werden – sonst droht produktiver Ausfall
• Service Accounts im Scope: Technische Konten für Backup, Monitoring oder Sync vertragen oft kein interaktives MFA und müssen explizit ausgeschlossen und anderweitig abgesichert werden

Microsoft Defender for Office 365: Mehr als Spam-Filter

Microsoft Defender for Office 365 (Plan 1 in Business Premium, Plan 2 ab E5) ist kein einfacher Spam-Filter. Es bietet Schutz gegen Phishing und Spear-Phishing über Anti-Phishing-Richtlinien, schädliche Anhänge über Safe Attachments, bösartige Links über Safe Links sowie Business Email Compromise über Impersonation Protection.

Safe Attachments richtig konfigurieren

Im Standard-Modus wird jeder Anhang in einer isolierten Cloud-Sandbox detoniert und auf Schadverhalten analysiert. Das dauert bis zu 30 Minuten, weshalb viele Admins auf "Monitor" oder "Off" zurückstellen. Die produktionstaugliche Konfiguration für KMU:

Safe Attachments Policy:
  Name: Default Protection
  Unknown malware response: Block
  Redirect: Enabled
  Redirect address: security-quarantine@firma.de
  Enable for SharePoint, OneDrive, Teams: Yes

Die Option Dynamic Delivery ermöglicht die Zustellung des E-Mail-Textes sofort, während der Anhang noch geprüft wird – ein guter Kompromiss zwischen Sicherheit und Usability für zeitkritische Umgebungen.

Anti-Phishing: Impersonation Protection

Gerade BEC-Angriffe basieren darauf, dass E-Mails von vermeintlichen Führungskräften oder Lieferanten nicht als Impersonation erkannt werden. Die Konfiguration muss explizit greifen:

Anti-Phishing Policy:
  Protected users:
    - ceo@firma.de
    - cfo@firma.de
    - buchhaltung@firma.de
  Protected domains:
    - firma.de
    - kritische-partnerdomains.de
  Mailbox intelligence: Enabled
  Impersonation safety tips: Enabled
  Actions on impersonated user: Quarantine
  Actions on impersonated domain: Quarantine
  Spoof intelligence: Enabled

Safe Links und URL-Detonation

Safe Links schreibt alle URLs in E-Mails um und prüft sie beim Klick in Echtzeit gegen Microsofts Threat Intelligence. Wichtig: Auch für Teams-Nachrichten und Office-Dokumente aktivieren – dort wird Safe Links häufig vergessen.

Safe Links Policy:
  Email URLs: Scan and block
  Apply to Teams messages: Yes
  Apply to Office 365 apps: Yes
  Track user clicks: Yes
  Do not allow users to click through: Yes

Das Aktivieren von "Track user clicks" ist für spätere forensische Auswertung im Fall eines Vorfalls wertvoll – es protokolliert, welche URLs angeklickt wurden, auch wenn Safe Links den Zugriff nicht blockiert hat.

Audit Logs: Was protokolliert wird und was nicht

Hier liegt einer der häufigsten Fehler in M365-Tenants: Viele IT-Verantwortliche gehen davon aus, dass Microsoft alles automatisch protokolliert. Das stimmt nur bedingt.

Was standardmäßig aktiviert ist

• Exchange Online: Postfachzugriff, Weiterleitungsregeln, Berechtigungsänderungen (90 Tage Aufbewahrung bei E3)
• Azure AD: Anmeldeereignisse, Richtlinienänderungen
• SharePoint/OneDrive: Datei-Download, externe Freigaben (begrenzt)

Was manuell aktiviert werden muss

Das Unified Audit Log (UAL) muss für den gesamten Tenant aktiviert sein. In älteren Tenants ist das nicht garantiert:

# Status prüfen
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Aktivieren, falls Ausgabe False
Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Mailbox-Audit-Logging für kritische Konten mit erweiterten Aktionen:

# Tenant-weites Audit sicherstellen
Set-OrganizationConfig -AuditDisabled $false

# Erweiterte Aktionen für exponierte Konten
Set-Mailbox -Identity "cfo@firma.de" -AuditEnabled $true `
  -AuditOwner @("MailboxLogin","Create","HardDelete","SoftDelete","Update","Move") `
  -AuditDelegate @("Create","FolderBind","HardDelete","SendAs","Update") `
  -AuditAdmin @("Create","FolderBind","HardDelete","MessageBind","Update")

Aufbewahrungsfristen und NIS-2/DSGVO

Die Standard-Aufbewahrung beträgt 90 Tage bei E3 und 180 Tage bei E5. Für NIS-2-Pflichten und DSGVO-Nachweispflichten reicht das in den meisten Fällen nicht aus. Microsoft Purview Audit (Premium) ermöglicht bis zu 10 Jahre – allerdings nur mit entsprechender Add-on-Lizenz.

Für KMU ohne E5 empfiehlt sich der regelmäßige Export über die Audit Log Search API in ein externes SIEM oder Log-Management:

# Audit Log Export der letzten 24 Stunden
$startDate = (Get-Date).AddDays(-1).ToString("MM/dd/yyyy HH:mm")
$endDate   = (Get-Date).ToString("MM/dd/yyyy HH:mm")

Search-UnifiedAuditLog `
  -StartDate $startDate `
  -EndDate $endDate `
  -Operations "MailboxLogin,FileDownloaded,UserLoggedIn,New-InboxRule" `
  -ResultSize 5000 `
| Export-Csv -Path "/audit/m365_audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation

Kritische Ereignisse, die aktiv überwacht werden sollten

Ereignis	UAL-Operation	Risikobewertung
Neue Postfach-Weiterleitungsregel	New-InboxRule	Hoch – klassischer BEC-Persistence-Mechanismus
Massen-Download aus SharePoint	FileDownloaded (>50 in 10 min)	Hoch – Datenexfiltration
Admin-Rollenzuweisung	Add member to role	Kritisch – Privilege Escalation
MFA-Deaktivierung	Disable Strong Authentication	Kritisch – Account Takeover-Vorbereitung
Legacy Auth Anmeldung	Sign-in via legacy protocol	Mittel – Credential Stuffing-Indikator
Externe Freigabe sensibler Dateien	SharingSet mit externem Empfänger	Mittel bis Hoch

Secure Score als kontinuierliche Messgröße

Microsoft bietet mit dem Secure Score unter security.microsoft.com eine Metrik, die den Sicherheitsstatus des Tenants auf einer Skala von 0–100 darstellt. Jede umgesetzte Empfehlung erhöht den Score und zeigt den Fortschritt über Zeit.

Der Secure Score ist kein absolutes Sicherheitsmaß, aber ein praktisches Werkzeug zur Priorisierung in Umgebungen ohne eigenes Security-Team. Sinnvolle Nutzung:

1. Score monatlich prüfen und dokumentieren
2. Top-5 "Recommended Actions" nach Risiko/Implementierungsaufwand priorisieren
3. Abweichungen vom Vormonat analysieren – rückläufiger Score ist ein Warnsignal

Ein Wert unter 40 % signalisiert erhebliche Handlungsbedarfe. Gut konfigurierte KMU-Tenants mit den beschriebenen Maßnahmen erreichen typischerweise 60–75 %.

NIS-2 und DSGVO: Welche Anforderungen M365 abdeckt

Unternehmen, die unter NIS-2 fallen (in Deutschland umgesetzt durch das NIS2UmsuCG, in Kraft seit März 2025), müssen unter anderem nachweisen:

• Zugangskontrollen und Authentifizierung: Conditional Access + MFA erfüllt Artikel 21 Abs. 2 lit. i direkt
• Protokollierung sicherheitsrelevanter Ereignisse: Unified Audit Log + externe SIEM-Archivierung
• Incident Detection und Response: Defender-Alerts mit definiertem Eskalationsprozess
• Risikobasiertes Sicherheitsmanagement: Secure Score + regelmäßige Dokumentation der Maßnahmen

Für die DSGVO ist insbesondere relevant: Wer hat wann auf welche personenbezogenen Daten zugegriffen? Das Unified Audit Log kann das für SharePoint und Exchange beantworten – wenn es korrekt konfiguriert und lang genug aufbewahrt wird. Ohne externe Log-Archivierung sind Auskunftspflichten nach Art. 15 DSGVO und Meldepflichten bei Datenschutzverletzungen nach Art. 33 DSGVO bei einem Vorfall kaum vollständig erfüllbar.

Fazit: Härtung ist kein Projekt, sondern ein Prozess

Die beschriebenen Maßnahmen – Conditional Access mit MFA-Zwang und blockierter Legacy Auth, Safe Attachments und Safe Links aktiv, Unified Audit Log vollständig aktiviert und extern archiviert – bilden eine solide Grundlage. Ein erfahrener Admin kann diese Basis an einem Tag umsetzen.

Die eigentliche Herausforderung für KMU ist nicht die Einmaleinrichtung, sondern das dauerhafte Monitoring: Defender-Alerts müssen ausgewertet werden. Audit Logs müssen auf Anomalien geprüft werden. Conditional Access Policies müssen bei Organisationsänderungen angepasst werden. Und neue Angriffstechniken erfordern regelmäßige Nachschärfung.

Für Unternehmen, die diese Aufgabe nicht intern stemmen können: Vyrex Security betreibt ein Managed SIEM auf Basis von Microsoft Sentinel und Wazuh, das M365-Audit Logs, Defender-Alerts und Entra ID Signale korreliert, rund um die Uhr auswertet und bei kritischen Ereignissen eskaliert – ohne dass ein eigenes SOC-Team nötig ist. Weitere Informationen gibt es unter vyrex.cloud.