Microsoft 365 Security Baseline: pragmatisch einführen, sauber betreiben
Eine Microsoft 365 Security Baseline definiert einen verbindlichen Mindeststandard an sicheren Konfigurationen in Microsoft 365. Ziel ist nicht „mehr Tools“, sondern weniger Angriffsfläche: klare Zugriffsregeln, kontrollierte Freigaben und nachvollziehbare Änderungen.
- Startpunkt: Entra ID (MFA, Conditional Access, Admin-Schutz) und dann M365-Workloads
- Erfolg wird messbar über Policy-Drift, Ausnahmen, Secure Score und Audit-Logs
- Wirkung entsteht erst mit Verifikation, Monitoring und Reporting im Betrieb
Eine Baseline, die nur einmal gesetzt wird, driftet im Alltag schnell weg und verliert ihren Schutz.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Eine Microsoft 365 Security Baseline ist ein Microsoft-recommended Mindeststandard für Konfigurationen und Policies in Microsoft 365, der einen „secure“ Grundzustand für Identität, Zugriff und Collaboration-Workloads beschreibt. Sie ist kein vollständiges Sicherheitskonzept, ersetzt keine Incident Response und ist nicht gleichbedeutend mit Compliance-Garantien.
Einleitung
Wenn Microsoft 365 schon läuft, heißt das noch nicht, dass die Konfiguration konsistent sicher ist: Legacy-Auth bleibt aktiv, Freigaben wachsen, Admin-Rechte werden nicht genug eingeschränkt. Eine Microsoft 365 Security Baseline hilft dir, Standards zu definieren, sauber auszurollen und später nachweisbar einzuhalten. Das spart Zeit im IT-Betrieb, reduziert Risiko und macht Security gegenüber Audit, Management und Compliance greifbar.
Welche Komponenten eine Baseline typischerweise abdeckt
Baseline Security bedeutet in Microsoft 365 immer „across Tenants“ gedacht: Identität und Zugriff (Entra ID) plus die produktiven Workloads, in denen Daten und Kommunikation liegen. Praktisch betrifft das Microsoft 365 Apps for enterprise (Office), SharePoint Online, Exchange Online und Teams.
- Microsoft Entra ID: Authentication, Conditional Access policies, Admin-Schutz
- Exchange Online: E-Mail- und Zugriffskanäle (z. B. EWS/Legacy) absichern
- SharePoint Online & Teams: File-Sharing, Gastzugriff, externe Zusammenarbeit kontrollieren
Kern-Policies: was „Baseline“ in der Praxis heißt
Die Baseline steht und fällt mit Zugriffskontrollen. 80% der Probleme entstehen nicht durch fehlende Features, sondern durch inkonsistente Policies, zu viele Ausnahmen und fehlendes Change-Management.
Identität & Zugriff (Entra ID)
- MFA überall dort durchsetzen, wo Risiko und Wirkung hoch sind (Admins zuerst), und Legacy-Authentication konsequent blocken
- Conditional Access nach Risiko, Standort, App und Gerätestatus: erlauben, einschränken oder blocken
- Admin-Management: Rollen minimieren, privilegierte Aktionen über PIM zeitlich begrenzen
Office/Apps, SharePoint, Exchange, Teams
- Office-Dateien: Makro- und OLE-Risiken reduzieren (File-Block, trusted sources, Schutz vor externen Inhalten)
- Freigaben: externe Links, Gastzugriff und „Jeder“-Freigaben in SharePoint/Teams begrenzen und auditierbar machen
- Exchange Online: riskante Protokolle und Zugriffspfade prüfen, alte Zugriffe gezielt abschalten statt „alles offen“
Schritt-für-Schritt: Einführung als Checkliste
Eine Baseline ist ein Rollout von Änderungen. Wer direkt in „Enforce“ geht, bekommt Reibung, Supportlast und im schlimmsten Fall Fachbereichs-Blocker. So bleibt es kontrolliert:
- 1) Ist-Zustand: Policies, Ausnahmen, Legacy-Zugriffe, Admin-Rollen, Gast-/Sharing-Settings dokumentieren
- 2) Zielbild: Baseline-Policies definieren (was wird geblockt, was braucht Ausnahmen) und „Baseline mode“ als Zielzustand festlegen
- 3) Rollout: Pilotgruppe, dann stufenweise Deploy; Änderungskommunikation und Fallback-Regeln vorbereiten
Mini-Story aus der Praxis: Ein Unternehmen blockt Legacy-Auth global, ohne EWS-Abhängigkeiten zu prüfen. Ergebnis: einzelne Fachanwendungen stoppen Mail-Verarbeitung, die IT schaltet Ausnahmen „kurz“ frei, und die Baseline verwässert. Mit Vorab-Inventarisierung und befristeten Ausnahmen wäre der Block sauber geblieben.
Voraussetzungen und Lizenzierung: realistischer Kostenrahmen
Die Baseline selbst ist vor allem Konfiguration, aber nicht „kostenlos“ im Betrieb: Aufwand entsteht durch Testing, Ausnahmen, Monitoring und regelmäßige Anpassungen. Lizenzseitig hängen einige Controls (z. B. erweiterte Conditional Access, Identity Governance, bestimmte Defender-Funktionen) von euren Microsoft 365- und Entra-Plänen ab; ohne passende Lizenzen bleibt die Baseline technisch lückenhaft oder nur als Empfehlung dokumentiert.
Wichtig für Budget/Beschränkungen: Erst die Baseline für Identität & Zugriff stabilisieren, dann Workloads. Das liefert schnell Protection pro investierter Stunde und reduziert spätere Nacharbeit.
Verifikation, Monitoring und Reporting: so bleibt die Baseline wirksam
Baseline-Drift ist normal: neue Apps, neue Admins, neue Teams, neue Ausnahmen. Darum braucht es Messbarkeit und ein regelmäßiges Reporting, nicht nur Konfiguration.
- Verifikation: Secure Score und Control-Status im Microsoft 365 admin center als Trend, nicht als Selbstzweck
- Monitoring: Unified Audit Logging aktiv nutzen; Abweichungen bei Policies und Admin-Aktionen sichtbar machen
- Reporting: monatlicher Baseline-Status (was ist compliant, was nicht, welche Ausnahmen laufen aus)
Nutzen: Du kannst Security gegenüber Management und Compliance erklären, ohne Technikfolien. Und du findest Abweichungen früh, bevor daraus ein Incident wird.
Wann externe Unterstützung sinnvoll wird
Externe Unterstützung lohnt sich, wenn Zeitaufwand und Risiko im Rollout nicht mehr intern abfangbar sind oder wenn ihr verlässliche Messbarkeit braucht. Typische Trigger:
- Ihr habt viele Tenants, viele Admins oder hohe Änderungsfrequenz und niemand betreibt die Policies kontinuierlich
- Ihr müsst „compliance“ nachweisen, aber Logs, Ausnahmen und Changes sind nicht sauber dokumentiert
- Ihr wollt blocken statt nur empfehlen, habt aber Angst vor Produktionsausfällen ohne Pilotierung
Fazit
Eine Microsoft 365 Security Baseline ist der praktikabelste Weg, um einen überprüfbaren Mindeststandard in Entra ID, Office, SharePoint Online, Exchange Online und Teams zu etablieren. Entscheidend ist nicht die erste Konfiguration, sondern der Betrieb: Verifikation, Monitoring, Reporting und sauberes Exception-Management. Wenn du Baseline-Policies einführen willst, ohne dein Team mit Testing, Drift und Dauer-Ausnahmen zu überlasten, lohnt sich ein klarer Betriebsprozess mit festen Verantwortlichkeiten.
Häufige Fragen
Reicht eine Microsoft 365 Security Baseline als Schutz aus?
Nein. Sie reduziert Angriffsfläche durch Standards, ersetzt aber keine laufende Überwachung, kein Incident Handling und keine Reaktion auf echte Threats. Ohne Betrieb driftet die Konfiguration weg.
Ist das nicht zu teuer, wenn wir Budgetgrenzen haben?
Teuer wird meist der ungeplante Aufwand: Ausnahmen, Supporttickets, Sicherheitsvorfälle und fehlende Nachweise. Budget-schonend ist ein stufenweiser Start: MFA/Conditional Access und Admin-Schutz zuerst, dann Workloads.
Wie vermeiden wir Risiko bei der Implementierung?
Mit Pilotgruppen, klar dokumentierten und befristeten Ausnahmen sowie einem Rollout in Stufen. Zusätzlich hilft ein vorheriger Check auf Legacy-Zugriffe und abhängige Apps, bevor etwas global geblockt wird.
Wie messen wir, ob die Baseline wirkt?
Über Trend-Metriken statt Bauchgefühl: Secure Score-Entwicklung, Anzahl/Alter von Ausnahmen, Policy-Drift, Audit-Log-Abdeckung und ein regelmäßiges Reporting, das Veränderungen nachvollziehbar macht.
