M365-Sicherheit in der Praxis

Management Summary

Microsoft 365 hat sich in den letzten Jahren zum zentralen digitalen Arbeitsplatz vieler Unternehmen entwickelt – und damit auch zu einem beliebten Angriffsziel für Cyberkriminelle. Dieser Praxisleitfaden zeigt auf, wie Sie Ihre Microsoft 365-Umgebung ganzheitlich absichern können. Dabei geht es um technische Architektur, konsequente Umsetzung von Sicherheitsmaßnahmen, den laufenden Betrieb inklusive Überwachung sowie Governance und Compliance-Aspekte. In lockerem, pointiertem Ton – aber immer fachlich präzise und herstellerneutral – berichte ich aus meiner Beratungspraxis, welche Ansätze sich bewährt haben. Ich schildere Best Practices, häufige Stolpersteine und Anti-Pattern und gebe Ihnen konkrete Checklisten sowie Artefakte an die Hand. So können IT-Leitung, CISO, Compliance-Verantwortliche, Microsoft 365-Administratoren und Revision schnell erfassen, worauf es ankommt.

Als erfahrener Berater und Autor (Ulrich B. Boddenberg) führe ich alle vorgestellten Leistungen persönlich durch. Ich biete gezielte Workshops, Architektur-Reviews, Health-Checks und Coaching an – aber keine Managed Services. Das heißt, ich begleite Ihr Team langfristig beratend und befähigend, ohne mich operativ „einzunisten“. Mein Tagessatz beträgt 1.500 € (zzgl. MwSt., Reisekosten separat), was ich an einigen Stellen im Dokument als Grundlage für Beispielpreise meiner Beratungspakete nutze.

Auf den folgenden finden Sie strukturiert gegliedert:

• Eine Ausgangslage & Bedrohungsbild – warum überhaupt M365-Sicherheit ein zentrales Thema ist.
• Technische Kernbereiche der Sicherheit: von Identitäten & Zugriff über Endgerätesicherheit, Threat Protection, Datenklassifikation bis hin zu spezifischen Aspekten für Teams/SharePoint/Exchange.
• Übergreifende Aspekte: Governance, Compliance, organisatorische Prozesse.
• Lizenzierungsfragen: Welche Sicherheitsfunktionen stehen in E3, E5 oder als Add-on zur Verfügung?
• Ein umsetzungsorientierter Fahrplan (Quick Wins 0–30 Tage, Ausblick 30–90 und 90–180+ Tage).
• Typische Risiken, Stolpersteine & Anti-Pattern, die Ihnen in der Praxis begegnen können.
• Nützliche Artefakte & Checklisten: Top-20-Sicherheitsmaßnahmen, Notfallkarte, KPI-Vorlagen, RACI-Matrix, etc.
• Beratungspakete (Starter, Professional, Enterprise) zur Unterstützung, alle persönlich durch mich durchgeführt, mit transparenter Preisformel.
• Ein umfangreiches FAQ mit 15 häufigen Fragen rund um Entscheidungen und Umsetzung der M365-Sicherheit.
• Zum Abschluss drei konkrete nächste Schritte und ein HInweis, wie Sie meine Unterstützung in Anspruch nehmen können.

Management-Kernerkenntnis: Die Sicherheit von Microsoft 365 lässt sich mit bord­eigenen Mitteln drastisch erhöhen – wenn man sie richtig einsetzt. Multi-Faktor-Authentifizierung, richtlinienbasierter Zugriff (Conditional Access), Geräte-Management, moderne Threat Protection und konsequente Datenklassifizierung sind die Eckpfeiler. Doch Technik allein genügt nicht: Ohne definierte Prozesse, klare Verantwortlichkeiten und regelmäßige Überprüfung bleibt viel Potenzial ungenutzt. Dieser Leitfaden hilft Ihnen, beides zu verbinden – Technik und Organisation – um Ihre Cloud sicher und compliant zu betreiben, ohne die Nutzer zu vergrätzen. Nutzen Sie die Schnelligkeit und Effizienz der Cloud, aber bitte mit angelegtem Sicherheitsgurt!

1. Ausgangslage & Bedrohungsbild

Ausgangslage: Unternehmen jeder Größe verlagern ihre Dienste in die Cloud – Microsoft 365 (M365) mit Azure/Entra ID, Exchange Online, SharePoint, Teams & Co. bildet oft das Rückgrat der modernen Kommunikation und Zusammenarbeit. Mit dieser Konzentration von Daten und Prozessen in der Cloud steigt jedoch auch das Risiko: Angreifer haben längst erkannt, dass sich ein erfolgreicher Angriff auf M365 richtig lohnt. Ein kompromittiertes Office 365-Konto kann Türen öffnen zu vertraulichen E-Mails, Teams-Chats, sensiblen SharePoint-Dokumenten und mehr.

Bedrohungsbild: Die Angriffsszenarien sind vielfältig und entwickeln sich stetig weiter. Hier eine Auswahl typischer Bedrohungen, denen ich in der Praxis begegne:

• Phishing & Credential Theft: Nach wie vor der Klassiker. Benutzer werden per gefälschter E-Mail oder Chat-Nachricht auf eine nachgebaute Anmeldeseite gelockt, um ihre Zugangsdaten preiszugeben. Ohne zusätzliche Schutzmaßnahmen wie MFA sind Accounts so allzu leicht zu kapern. Selbst mit MFA versuchen Angreifer, Benutzer auszutricksen (MFA Fatigue Attack – so lange MFA-Anfragen senden, bis der genervte Nutzer auf „Approve“ drückt).
• Brute-Force und Password Spray: Durch die weit verbreitete Nutzung von persönlichen Microsoft-Konten und Azure AD sind Login-URLs öffentlich erreichbar. Skriptkiddies bis hin zu APT-Gruppen probieren millionenfach häufige Passwörter durch oder verwenden geleakte Passwortlisten, um sich in Cloud-Konten einzuloggen. Konten mit schwachen Passwörtern oder ohne MFA sind hier leichte Beute.
• Token Theft & Session Hijacking: Moderne Angriffe zielen vermehrt darauf ab, das OAuth-Token oder andere Session-Zugriffstoken zu stehlen (z.B. via Malware auf dem Gerät), um Zugang zu erhalten, ohne das Passwort kennen zu müssen. Ein gestohlenes gültiges Token kann den Angreifern Zugriff gewähren, selbst wenn das Passwort zwischendurch geändert wird.
• Malware & Ransomware via Cloud: E-Mails mit gefährlichen Anhängen, Links in Office-Dokumenten, oder getarnte OneDrive/SharePoint-Freigaben mit Schadsoftware – die Cloud wird auch als Verteilungsplattform für Malware genutzt. In der Folge drohen Verschlüsselung von Dateien (Ransomware), Datendiebstahl oder Ausführung von Spionagesoftware.
• Insider Threats & fahrlässige Mitarbeiter: Nicht alle Risiken kommen von außen. Ein Mitarbeiter, der versehentlich vertrauliche Daten an den falschen Empfänger sendet, kann genauso Schaden anrichten wie ein frustrierter Insider, der in böser Absicht Dokumente exfiltriert. Cloud-Plattformen erleichtern den Datenzugriff von überall, was im Positiven die Produktivität steigert, aber auch Missbrauch erleichtern kann, wenn keine Schutzmechanismen greifen.
• Gezielte Angriffe auf Privileged Accounts: Besonders im Visier stehen Administrator- und andere privilegierte Konten. Angreifer wissen: Wenn sie einen Global Admin in M365 übernehmen, haben sie praktisch die gesamte Umgebung unter Kontrolle. Solche Angriffe erfolgen oft mittels Spear-Phishing, Pass-the-Hash/Pass-the-Ticket in hybriden Umgebungen oder über umgehung von MFA (z.B. SIM-Swapping bei SMS-basiertem MFA).
• OAuth-Consent-Phishing (Illegitime Apps): Ein neuartiger Trick: Nutzer werden verleitet, einer scheinbar nützlichen Drittanbieter-App Zugriffsberechtigungen auf ihr M365-Konto zu geben („Consent“). In Wahrheit steckt dahinter eine bösartige App, die mit den Berechtigungen dann E-Mails lesen, Files abgreifen oder im Namen des Nutzers Nachrichten versenden kann – ohne dass je ein Passwort geklaut werden musste. Das M365-Ökosystem ermöglicht die Integration externer Apps, was viel Produktivität bringt, aber auch Schlupflöcher eröffnen kann, wenn man Wildwuchs nicht zügelt.

Dieses Bedrohungsbild zeigt: Cloud-Sicherheit ist keine Kür, sondern Pflicht. Aber die gute Nachricht: Microsoft 365 liefert bereits sehr viele Werkzeuge mit, um diese Gefahren abzuwehren oder Schäden zu begrenzen. Die Herausforderung liegt darin, die richtigen Funktionen zu kennen und sinnvoll zu konfigurieren. Was nützen die besten Sicherheitsfeatures, wenn sie niemand aktiviert? Ich erlebe oft, dass Unternehmen E5-Lizenzen besitzen, aber nur einen Bruchteil der Sicherheitsfunktionen tatsächlich einsetzen. Oder aber es werden isoliert einige Tools genutzt, ohne ein Gesamtkonzept – was zu Lücken führt.

Architektur-Frage: Zudem muss die Sicherheitsarchitektur zu den Geschäftsanforderungen passen. Beispiel: Viele Unternehmen haben eine hybride Identitätsinfrastruktur (On-Premises AD synchronisiert mit Azure AD). Hier gilt es, die Cloud-Sicherheit ganzheitlich zu denken – ein schwach gesichertes On-Premises-Konto kann über Synchronisation den Cloud-Tenant gefährden und umgekehrt. M365-Sicherheit erfordert also oft auch einen Blick auf lokale Komponenten (z.B. AD, ADFS oder Hybrid-Exchange).

Zusammenfassend: Das Bedrohungsbild ist ernst, aber beherrschbar. In den nächsten Abschnitten stelle ich die wichtigsten Sicherheitshebel in Microsoft 365 vor: Identitäten, Geräte, Bedrohungsschutz, Datenschutz, etc. – jeweils mit praktischen Empfehlungen für Architektur, Umsetzung, Betrieb und Governance. Ziel ist, ein mehrschichtiges Schutzkonzept aufzubauen (Stichwort „Defense-in-Depth“ und Zero Trust: „Vertraue nichts und niemandem, verifiziere alles“). So können Sie das Risiko deutlich senken, ohne den Tagesbetrieb lahmzulegen oder Benutzer mit übertriebener Paranoia zu verschrecken.

Legen wir los mit der ersten und wichtigsten Säule der Cloud-Security: Identitäten und Zugriffe.

2. Identitäten & Zugriff (Entra ID, PIM, Conditional Access)

Identität ist das neue Perimeter: In der Cloud-Welt schützen nicht mehr Burgmauern und Firewalls allein das Unternehmen, sondern die Identitäten der Benutzer sind der Schlüssel. Microsoft Entra ID (vormals Azure AD) bildet das Herz der Zugriffskontrolle in M365. Hier werden Benutzer authentifiziert, Berechtigungen geprüft und Zugriffe auf sämtliche Dienste gesteuert. Entsprechend ist ein sicheres Identitätsmanagement fundamental.

2.1 Zugriff absichern: MFA, bedingter Zugriff & Legacy-Auth

Der erste, einfachste und wirkungsvollste Schritt ist die Einführung von Multi-Faktor-Authentifizierung (MFA) für alle Benutzer. In meiner Beratungspraxis ist „MFA überall“ stets Maßnahme Nummer 1. Warum? Weil ein gestohlener Benutzername+Passwort dann allein nicht mehr ausreicht, um ins Konto zu gelangen. Ideal ist die Umsetzung per App-basiertem MFA (Microsoft Authenticator Push-Benachrichtigung oder Code). Alternativ tun es auch FIDO2-Sicherheitsschlüssel oder zumindest SMS-Tokens – Hauptsache mehr als nur das Passwort. Entscheidend ist, MFA für sämtliche Accounts durchzusetzen: also nicht nur für Admins, sondern auch alle regulären User, Dienstkonten (soweit möglich) und unbedingt für externe Gastbenutzer mit Zugang zu sensiblen Daten.

Parallel dazu sollten Sie „Legacy Authentication“ deaktivieren. Damit sind alte Protokolle/Mechanismen gemeint, die keine MFA-Unterstützung haben (z.B. Basic Auth für SMTP, IMAP/POP3, ältere Office-Clients). Microsoft hat Ende 2022 zwar Basic Auth für Exchange Online großteils abgeschaltet, aber in jedem Tenant kann es noch Dienste geben, die Legacy-Auth nutzen. Ein Angreifer, der z.B. per IMAP mit Passwort ins Postfach will, könnte Erfolg haben, wenn dieses Protokoll nicht blockiert ist – MFA greift dann nämlich nicht. Conditional Access (dazu gleich mehr) oder die Security-Default-Einstellungen von Azure AD bieten Möglichkeiten, Legacy Auth komplett zu unterbinden. In einer sicheren M365-Umgebung hat Legacy Auth nichts zu suchen.

Die Microsoft Entra Conditional Access ist der zentrale Policy-Motor, um Zugriffe bedingt zu steuern. Ich erkläre es meinen Kunden gern bildhaft: „Conditional Access ist der Türsteher vor Ihrer Cloud, der je nach Ausweis und Laune des Besuchers entscheidet, ob er rein darf, einen extra Check (MFA) machen muss oder draußen bleibt.“ Mit CA-Richtlinien können Sie z.B. festlegen:

• MFA erzwingen: z.B. bei jedem Login (weniger ideal für Benutzerkomfort) oder risikobasiert (Azure AD Identity Protection erkennt riskante Anmeldeversuche – bei hohem Risiko dann MFA erzwingen oder Zugang blockieren).
• Gerätestatus prüfen: Nur Geräte, die compliant sind oder hybrid ins AD eingebunden, dürfen auf bestimmte Ressourcen zugreifen. Beispiel: „Unternehmensdaten nur von Intune-verwalteten Geräten“. So verhindern Sie, dass sich jemand mit privaten, evtl. unsicheren Geräten an SharePoint oder Teams anmeldet und dort Daten herunterlädt.
• Standortbasierte Regeln: Zugriffe von bestimmten Ländern blockieren, wenn Ihr Geschäft z.B. nur in DACH stattfindet. Vorsicht: Die Welt ist mobil – ein zu enges Geofencing stört ggf. legitime Benutzer im Urlaub. Aber zumindest ungewöhnliche Länder kann man auf die Watchlist setzen.
• Zeitliche Einschränkungen oder Sitzungskontrollen: Beispielsweise erfordern, dass nach X Tagen Inaktivität neu angemeldet wird, oder dass besonders heikle Anwendungen nur zu Geschäftszeiten genutzt werden dürfen (selten angewendet, aber möglich).
• Ausschlüsse & Ausnahmen: Etwa für Break-Glass-Accounts (Notfall-Admin-Konten, siehe weiter unten) CA-Regeln ausnehmen, damit diese im Notfall nicht ausgesperrt sind.

Praktisch gesehen, sollten Sie mit einigen Basis-Policies starten, die erfahrungsgemäß 80% der Risiken abdecken, zum Beispiel:

1. MFA für alle Benutzer erzwingen (ggf. mit Ausnahmen für Service Accounts/Notfallkonten).
2. Blockieren aller Legacy-Auth-Protokolle (sofern nicht schon geschehen).
3. MFA zwingend für alle Admins bei jeder Anmeldung + ggf. weitere Härtung für Admins: z.B. Admin-Zugriff nur von firmeneigenen Geräten.
4. Blockieren von Anmeldungen aus Hochrisiko-Ländern (sofern Ihr Unternehmen dort keine Aktivitäten hat).
5. Anmeldungen mit hohem Risiko (Azure AD meldet „hohes Risiko“ bei Nutzern oder Sign-ins, z.B. wenn das Konto in einer Passwort-Leak-Liste auftaucht) automatisch blockieren.

Durch solche Regeln schaffen Sie einen robusten Grundschutz. Wichtig: Testen Sie neue CA-Policies zunächst im Report-Only-Modus oder auf eine Pilotgruppe, um nicht versehentlich die halbe Firma auszusperren („Oops, alle externen Mitarbeiter kommen nicht mehr rein…“). Conditional Access ist mächtig, aber mit großer Macht kommt große Verantwortung – sprich Change Management: führen Sie Policies kontrolliert ein, kommunizieren Sie sie an die Anwender (z.B. „Ab nächster Woche nur noch Zugriff auf Outlook, wenn Firmen-Gerät oder MFA genutzt wird“) und überwachen Sie die Auswirkungen.

2.2 Privilegierte Konten im Griff: Just-in-Time-Admin dank PIM

„Wer hat die Schlüssel zum Königreich?“ – Diese Frage sollten Sie sich in Bezug auf Ihre M365-Umgebung täglich stellen. In vielen Unternehmen gibt es eine Handvoll Global Administrators, die ständig alle Rechte haben. Aus Sicht der Sicherheit ist das ein Albtraum: Jeder dieser Admins ist ein attraktives Ziel für Angriffe. Prinzip der minimalen Rechte heißt daher die Devise: So wenig ständige Administratoren wie möglich!

Microsoft Entra ID bietet mit PIM (Privileged Identity Management) ein Werkzeug, um aus statischen Admin-Rollen dynamische, bedarfsweise vergebene Rollen zu machen. Konkret funktioniert PIM so: Ein Benutzer ist z.B. „berechtigt“ (eligible) für die Rolle Global Admin, aber nicht 24/7 aktiv darin. Will er eine Admintage ausführen, aktiviert er die Rolle just-in-time – je nach Konfiguration muss er dazu MFA bestätigen, vielleicht eine Begründung angeben und/oder eine Genehmigung durch einen weiteren Administrator einholen. Die Rolle bleibt dann z.B. 1 oder 2 Stunden aktiv und verfällt danach automatisch. PIM protokolliert jede Aktivierung und kann auch Warnungen senden („User X hat gerade Global Admin aktiviert“).

In der Praxis setze ich PIM gern folgendermaßen auf:

• Break-Glass-Konten: Legen Sie 1–2 Notfall-Administratorkonten an, die nicht PIM-geschützt sind (sie sollen ja im Notfall immer verfügar sein), aber diese Konten nicht im Alltag nutzen! Sie bekommen ein super langes Kennwort, MFA, keinen Mailpostfach (damit sie nicht Phishing-Opfer werden) und werden in einem Tresor offline verwahrt. Nur wenn alle Stricke reißen (z.B. MFA-Dienst ausgefallen oder alle Admins im Urlaub und ein Notfall tritt ein), greift man auf diese zurück. Überwachen Sie deren Nutzung per Alert – ein Login sollte nie vorkommen außer im echten Notfall.
• PIM für alle ständigen Admin-Rollen: Global Admin, Exchange Admin, SharePoint Admin, Teams Admin, Compliance Admin usw. – alle auf „eligible“ setzen, keiner bleibt „aktiv“. So haben Sie keine ständigen Superuser mehr im System. Viele Organisationen sind überrascht, wie selten man eigentlich Global Admin dauerhaft braucht. Meist genügt es, bei Bedarf sich hochzustufen.
• MFA-Pflicht für Aktivierung & kurze Dauer: Jede PIM-Aktivierung erfordert bei unsicherheitsbewussten Kunden ein MFA (selbst wenn der Nutzer sich gerade erst angemeldet hat) – sicher ist sicher. Außerdem setzen wir die Rollendauer restriktiv: z.B. 1 Stunde Global Admin reicht meistens aus, selten braucht jemand 8 Stunden durchgehend Domänenadministrator zu spielen.
• Justification & Approval: Für Top-Rollen wie Global Admin kann man einen Genehmigungsworkflow einführen. D.h. Admin A will Rolle aktivieren, Admin B muss per Klick zustimmen. Das hält zwar im Notfall etwas auf, aber hindert auch den einen Admin daran, alleine Schindluder zu treiben, falls sein Konto kompromittiert wäre oder er mal auf dumme Gedanken kommt.
• Regelmäßige Überprüfung (Access Reviews): PIM hat auch die Möglichkeit, regelmäßig Überprüfungen zu starten – wer hat noch welche Rechte, sind die noch nötig? Lassen Sie z.B. quartalsweise durch einen Verantwortlichen bestätigen, dass jeder „eligible“ Admin überhaupt noch diese Berechtigung benötigt. So fängt man auf, wenn ehemalige Admins die Firma verlassen haben oder Rollen sich geändert haben.

Ohne PIM (Azure AD P2 Lizenz benötigt) bleibt zumindest der Ratschlag: reduzieren Sie die Anzahl ständiger Admin-Konten drastisch, nutzen Sie die speziell dafür vorgesehene Rolle „Globaler Leser“ für Audits und vergeuden Sie keine E5-Lizenz an Ex-Mitarbeiter 😉. Schützen Sie Admin-Konten mindestens mit eigenem MFA (nicht dem gleichen wie fürs normale Konto) und verwenden Sie getrennte Admin-Accounts je Administrator, die nur für administrative Tätigkeiten genutzt werden. Es mag unbequem erscheinen, aber der Schaden eines kompromittierten Admin-Accounts ist immens. Ich sage oft: „Lieber 30 Sekunden extra Aufwand beim Anmelden als 30 Tage Totalausfall wegen eines Hackers, der Ihr Azure AD übernommen hat.“

2.3 Weitere Identitäts-Governance: Richtlinien und Gastzugriff

Im Identitäten-Bereich gibt es darüber hinaus einige Governance-Aspekte, die ich kurz anreißen möchte:

• Passwort-Richtlinien & Passwortschutz: Azure/Entra ID hat an sich fixe Passwort-Policies (Cloud Only), aber via „Azure AD Password Protection“ können Sie eine Sperrliste von verbotenen Passwörtern (z.B. Firmennamen, Saison 2023! etc.) definieren – on-prem und Cloud. Nutzen Sie diese, um triviale Passwörter zu verhindern. In Cloud-Only Umgebungen aktivieren Sie möglichst den „Kennwortlos“-Ansatz: mit MFA überall ist das Passwort an Bedeutung am Abnehmen, FIDO2-Keys oder Windows Hello erlauben sogar logins ohne klassisches Passwort.
• Benutzerlebenszyklus & JIT Provisioning: Legen Sie Prozesse fest, wie neue Mitarbeiter schnell ins System kommen und vor allem, wie Austritte sauber gehandhabt werden (Deaktivieren/Löschen des Kontos sofort am Austrittsdatum, Entfernen aus Gruppen etc.). Azure AD bietet mit Entitlement Management (Access Packages) Möglichkeiten, Berechtigungs-Zuweisung inkl. Ablaufdatum zu automatisieren – allerdings selten von KMUs genutzt. Wichtig ist: kein Ex-Mitarbeiter darf monatelang nach dem Ausscheiden noch aktiven Account haben.
• Gastbenutzer (B2B) kontrollieren: Viele Firmen öffnen ihre M365-Tenant für Gäste (externe Benutzer, z.B. Partner, Kunden, die in Teams oder SharePoint eingeladen werden). Das ist super für die Kollaboration, aber ohne Kontrolle entsteht Wildwuchs. Über Azure AD B2B-Einstellungen können Sie steuern, wer Gäste einladen darf, ob Gast-Einladungen einer Approval bedürfen, aus welchen Domains Gäste zugelassen sind etc. Ich empfehle mindestens: nur bestimmte Personen oder Admins dürfen Gäste einladen, und regelmäßige Überprüfung der Gastkonten (z.B. vierteljährlich schauen: welche externen User sind drin und werden die noch gebraucht?). Inaktiven Gästen den Zugang entziehen, um „Karteileichen“ zu vermeiden, die irgendwann zum unbemerkten Einfallstor werden.
• Anwendungsberechtigungen und Consent: Prüfen Sie im Azure AD App-Registrierungen und Enterprise Applications – welche Anwendungen haben Zugriffsrechte auf Ihre Daten? Deaktivieren Sie Nutzer-consent für Drittanwendungen, sodass nicht jeder User irgendeiner App Rechte geben kann, sondern das nur ein Admin nach Prüfung macht. Damit stoppen Sie das oben erwähnte OAuth-Consent-Phishing. Microsoft Entra erlaubt auch eine integrierte „Verified Publisher“-Kennzeichnung und Consent-Richtlinien, um die App-Nutzung abzusichern.
• Monitoring & Reporting: Aktivieren Sie auf jeden Fall das Azure AD Audit und Anmeldungsprotokoll (im M365 admin center unter Überwachung), falls nicht per Default schon aktiv. Hier sehen Sie, wer sich wann angemeldet, fehlgeschlagene Logins, Passwortänderungen, etc. Für sicherheitskritische Aktionen (z.B. Mehrfach-Login-Fehler, Anmeldungen von neuen Ländern, Massen-Additionen von Usern) können Sie Alerts definieren. Falls die Logs länger als 30/90 Tage vorgehalten werden sollen oder mit on-prem SIEM verknüpft, bietet sich Azure Monitor/Sentinel an – das sprengt hier den Rahmen, aber im Kapitel Monitoring taucht es kurz auf.

Zusammengefasst: Schützen Sie Ihre Identitäten wie den Kronjuwelenschatz. Durch MFA und Conditional Access bauen Sie eine solide Mauer, durch PIM lassen Sie nur kontrolliert Administratoren ans Steuer, und durch saubere Richtlinien verhindern Sie Wildwuchs. Oder mit meinen Worten: „Azure AD ist der Türsteher – geben Sie ihm Wachdienstverstärkung (MFA, CA) und nehmen Sie ihm den Generalschlüssel weg (PIM), dann kommen nur die richtigen Leute in den Club.“ Im nächsten Schritt widmen wir uns den Geräten und Apps, denn wer drin ist, soll sich schließlich auch nur auf sicheren Geräten bewegen dürfen.

3. Endgeräte & Apps (Intune, MAM, Gerätestatus)

„Unsere Daten sind in der Cloud, was scheren uns die Geräte?“ – Dieser Trugschluss kommt teuer zu stehen. Die Endgeräte (PCs, Laptops, Smartphones, Tablets) sind der Zugangsweg zur Cloud und oft der schwächste Punkt, wenn sie unverwaltet oder unsicher sind. Microsoft Intune (Bestandteil von Microsoft 365) ermöglicht Mobile Device Management (MDM) und Mobile Application Management (MAM), um genau diese Geräte abzusichern. Im Zusammenspiel mit Conditional Access (siehe Kapitel 2) stellen wir sicher, dass nur vertrauenswürdige, konforme Geräte auf Cloud-Daten zugreifen.

3.1 Geräteverwaltung mit Intune: Basis für Gerätestatus und Compliance

Intune als MDM-Plattform: Microsoft Intune (manchmal auch „Endpoint Manager“ genannt) erlaubt die zentrale Verwaltung von Windows-PCs, Macs, und mobilen Geräten (iOS, Android). Die Kernidee: Ein Gerät wird im Intune registriert (enrolled) und erhält damit Richtlinien, Einstellungen und ggf. Software aus der Cloud. Aus Sicht der Sicherheit sind besonders wichtig:

• Compliance-Richtlinien: Sie definieren, wann ein Gerät als „konform“ gilt. Z.B. muss BitLocker eingeschaltet sein, ein PIN/Passwort mit bestimmten Anforderungen, das Gerät darf nicht gejailbreakt/rooted sein, Virenschutz (Defender) muss aktiv sein, bestimmte kritische Updates nicht älter als X Tage, usw. Geräte, die diese Kriterien nicht erfüllen, werden als non-compliant markiert – und dank Conditional Access können solche dann von M365-Diensten ausgeschlossen werden. So erreichen Sie z.B.: „Kein Zugriff auf Unternehmens-E-Mails, wenn das Gerät nicht verschlüsselt ist oder kein aktueller Patchstand vorliegt.“
• Konfigurationsprofile: Darüber stellen Sie sicher, dass Sicherheitsfeatures aktiv sind. Beispiele: Richtlinie, die BitLocker-Verschlüsselung automatisch aktiviert (und den Wiederherstellungsschlüssel sicher in Azure AD hinterlegt). Oder eine Richtlinie, die Windows Defender als Virenschutz nicht deaktivierbar macht. Oder eine iOS-Richtlinie, die das Installieren unsignierter Apps verhindert. Hiermit setzen Sie Ihr Sicherheitsbaseline technisch durch.
• Updates & Patch-Management: Intune integriert mit Windows Update for Business, sodass Sie Windows- und Office-Updates steuern können. Definieren Sie Update-Ringe (für gestaffelte Rollouts), erzwingen Sie regelmäßige Neustarts, damit Sicherheitsupdates zeitnah wirksam werden. Nichts ist schlimmer als ein Notebook, das seit 18 Monaten keine Updates gesehen hat – außer vielleicht 100 solcher Notebooks im Homeoffice.
• Conditional Access Integration: Ein Intune-verwaltetes Gerät kann seine Compliance-Info an Azure AD liefern. CA-Policies nutzen das (Stichwort Gerätestatus in CA). Beispielsweise: Gerät muss compliant sein, sonst kein Zugriff. Oder Gerät muss „Hybrid Azure AD Join“ (domänenverbunden) sein, um eine Legacy-App nutzen zu dürfen. Diese Verzahnung schafft einen Technologiekreis: Intune setzt Vorgaben auf dem Gerät durch, Azure AD prüft beim Login den Gerätestatus. Gerät nicht okay => kein Login. Das ist wie ein Türsteher, der nicht nur Ihren Ausweis prüft, sondern auch schaut, ob Sie saubere Schuhe anhaben 😉.

In der Praxis beginne ich oft mit einem Pilot für Intune: Einige Dutzend Geräte enrollen, die wichtigsten Compliance-Regeln testen (Achtung: zu Beginn nicht zu strikt, sonst sperrt man sich ggf. selbst aus – z.B. eine All-or-nothing Regel „Gerät muss compliant sein“ kann am Anfang viele aussperren, wenn noch niemand compliant ist. Hier gestuft vorgehen!). Sobald Grundkonfiguration steht, rollen wir nach und nach auf alle Firmen­geräte aus. Wichtig ist auch das Thema Inventarisierung: Intune liefert stets Übersicht, welche Geräte es gibt, wem sie zugewiesen sind, wann zuletzt online, ob sie Jailbreak-Spuren zeigen, etc. Das hilft ungemein auch für Audits.

3.2 BYOD und MAM: Schutz auch auf privaten Geräten

Nicht jeder Mitarbeiter hat ein Firmenlaptop – vor allem bei Partnern, temporären Kräften oder bestimmten Rollen (Beispiel: externe Berater, die nur auf Teams eingeladen sind) kommen oft private Geräte zum Einsatz. Hier beißt sich manchmal die Katze in den Schwanz: Man will Sicherheit, aber kann/möchte nicht jedes Privatgerät voll ins MDM nehmen („mein Chef will sein privates iPhone nicht von der Firma managen lassen“). Dafür gibt es MAM: Mobile Application Management.

MAM ohne Enrollment bedeutet: Anstatt das ganze Gerät unter Verwaltung zu nehmen, werden nur einzelne Apps und deren Firmendaten verwaltet und geschützt. In Microsoft 365 geht das so: Sie definieren App-Schutz-Richtlinien in Intune, z.B. für die Outlook-App, Teams-App, Word/Excel auf mobilen Geräten. Diese Richtlinien erzwingen Dinge wie: App darf keine Daten in andere private Apps kopieren (Copy/Paste-Schutz), App-Daten dürfen nur in OneDrive gespeichert werden und nicht z.B. in die persönliche Dropbox, die App muss mit PIN oder Fingerabdruck entsperrt werden, und im Notfall kann man aus der Ferne alle Firmendaten innerhalb der App löschen (ohne das ganze Gerät anfassen zu müssen).

Ein typisches BYOD-Szenario: Die Mitarbeiter installieren Outlook und Teams aus dem App Store. Sobald sie sich mit dem Firmenkonto anmelden, erkennt Azure AD via Conditional Access: „Aha, diese App erfordert MAM-Schutz“. Die App wird gezwungen, die Intune-Richtlinie zu aktivieren – der Benutzer merkt es daran, dass er z.B. aufgefordert wird, einen PIN für Outlook festzulegen. Ab dann sind alle Firmen-E-Mails innerhalb Outlook verschlüsselt gespeichert und können z.B. nicht via Screenshot oder Copy-Paste einfach rausgetragen werden. Verlässt der Mitarbeiter die Firma oder das Gerät geht verloren, kann der Admin einen Selective Wipe ausführen: Outlook und Teams setzen sich zurück und entfernen alle Unternehmensdaten – das private Phone bleibt ansonsten unberührt.

Somit erreichen wir einen Kompromiss: Sicherheit für Firmendaten auch auf privaten Geräten, ohne die volle Kontrolle übers Gerät zu nehmen (was datenschutzrechtlich und praktisch oft problematisch wäre). Natürlich sind MAM-geschützte Apps nicht ganz so sicher wie voll gemanagte Geräte, aber sie schließen eine wichtige Lücke. Wichtig: MAM funktioniert aktuell primär für Mobile Apps (iOS, Android). Auf Windows/macOS gibt es ähnliche Konzepte (Windows Information Protection), aber in der Praxis setze ich lieber auf volles MDM für Rechner, da dort BYOD seltener ist. Die meisten User arbeiten am PC doch lieber auf einem Firmen-Gerät, allein schon wegen VPN, Softwarelizenzen etc.

3.3 Gerätelandschaft: Praxis-Tipps und Stolpersteine

Ein paar Anmerkungen aus Erfahrung, worauf Sie beim Thema Endgeräte & Sicherheit achten sollten:

• Defender for Endpoint Integration: Wenn Sie Microsoft Defender for Endpoint (MDE) im Einsatz haben (gehört zur Defender-Suite, E5-Lizenz), können Sie Intune und MDE koppeln. Dann fließen Sicherheits-Signale vom Gerät (z.B. „Malware erkannt“, „Verdächtige Aktivitäten“) in die Compliance-Bewertung ein. Sie könnten z.B. eine Regel machen: Gerät ist nicht compliant, wenn der MDE einen aktiven Bedrohungsalarm meldet. Dann sperrt Conditional Access sofort den Cloud-Zugriff für dieses Gerät – elegant, oder? Der Nutzer ruft an „Warum komme ich nicht mehr an meine Mails?“, Admin: „Weil dein Rechner wahrscheinlich infiziert ist, kümmere dich mit IT drum“. So verhindert man, dass ein kompromittiertes Gerät weiter Schaden anrichtet.
• Lokale Adminrechte eindämmen: Ein ewiges Thema. Nutzer mit lokalen Adminrechten auf ihrem Windows öffnen Malware Tür und Tor. Intune kann via Richtlinie dafür sorgen, dass Standardnutzer nicht lokale Admins sind. Für Admin-Aufgaben kann man dann z.B. das neue „Endpoint Privilege Management“ (Preview in Intune) nutzen, um kontrolliert temporär Adminrechte zu vergeben. Oder althergebracht: separate lokale Admin-Konten. Wichtig ist, dieses Thema anzugehen – sonst scheitern viele Schutzmaßnahmen daran, dass der Benutzer sie umgehen kann (Beispiel: User als lokaler Admin könnte den Intune-Client abschalten – schlecht!).
• Geräte-Hygiene: Verwaiste Geräte (alt, nicht mehr genutzt) sollten regelmäßig aus Intune/Azure entfernt werden. Nur lebende Geräte sollen Zugriff haben. Führen Sie eine Geräte-Inventur mind. jährlich durch. Intune-Reports helfen, Kandidaten zu finden (z.B. „nicht gesehen seit 90 Tagen“).
• Nutzerakzeptanz & BYOD-Policy: Kommunizieren Sie klar, welche Freiheiten und Grenzen gelten. Mitarbeiter sollten wissen: „Wenn ich mich mit meinem privaten Handy bei Outlook anmelde, erzwingt die Firma gewisse Schutzregeln, löscht aber nicht meine Fotos.“ Sorgen Sie für Transparenz, dann gibt es auch weniger Widerstand. Oft empfehle ich eine BYOD-Richtlinie (schriftlich), die jeder Mitarbeiter erhält: Darin steht, was MAM/Intune auf dem Gerät tut und was nicht. Das schafft Vertrauen und Rechtssicherheit.
• Spezialgeräte nicht vergessen: Was ist mit Shared Devices, Kiosks, Konferenzraum-Systemen? Intune bietet spezielle Profile für gemeinsam genutzte Geräte (z.B. kein persistenter Benutzer, automatischer Logout). Auch solche Geräte sollten Sie, wo möglich, unter Management nehmen, denn gerade ein unbeaufsichtigtes Kiosk-Tablet mit Teams-Raumkonto ist ein attraktives Ziel im Foyer.
• Mobile Application Management Stolperstein: Nicht jede App ist von MAM steuerbar – es funktioniert nur mit Apps, die das Intune SDK unterstützen (die Microsoft-Apps, Adobe, Zoom u.a. populäre Apps tun es, viele kleine nicht). Wenn jemand z.B. per IMAP mit der iPhone-Mail-App auf Exchange Online will, greift MAM nicht. Daher: mittels Conditional Access können Sie steuern, welche Apps zugreifen dürfen. Setzen Sie z.B. eine Policy „Exchange Online darf nur via Outlook Mobile zugegriffen werden“. Dann hat der eingebaute Mailclient oder Thunderbird etc. keinen Erfolg.

Fazit für Geräte & Apps: Sorgen Sie dafür, dass Zugriff nur von gesicherten Geräten aus erfolgt. Intune ist Ihr Freund, um die Geräteflotte zu bändigen – seien es Domänenrechner im Homeoffice, iPhones von Vorständen oder Android-Tablets im Lager. Machen Sie Geräte „compliant“ (verschlüsselt, gepatcht, keine Malware) und koppeln Sie diese Compliance an den Zugriff. Private Geräte schließen Sie nicht aus, aber umsorgen sie mit App-Schutz, damit Ihre Firmendaten nicht schutzlos herumliegen. Ein gut verwaltetes Gerät ist wie ein gesunder, geimpfter Kurier: er trägt die wichtigen Dokumente ans Ziel, ohne selbst eine Seuche einzuschleppen.

4. Bedrohungserkennung & Abwehr (Defender-Suite)

Selbst mit starken Türen (Identitäten) und Alarmanlagen (Geräte- und Zugriffsregeln) werden Einbrecher versuchen hereinzukommen. Einige werden es schaffen oder es zumindest hartnäckig versuchen. Hier kommt die Microsoft Defender Suite ins Spiel – quasi das Sicherheitspersonal, das im Gebäude patrouilliert, Einbruchsversuche erkennt und im Ernstfall den Schlagstock zückt. Microsoft hat in den letzten Jahren seine Threat-Protection-Produkte vereinheitlicht. Unter dem Namen Microsoft 365 Defender arbeiten verschiedene Dienste Hand in Hand:

• Defender for Endpoint ( früher Windows Defender ATP): Endpoint Detection & Response (EDR) für Ihre Geräte. Läuft auf Windows 10/11, Windows Server, macOS, Linux, iOS, Android. Erkennt verdächtige Aktivitäten auf dem Gerät (Malware, Exploits, auffällige Prozesse, Anomalien) und kann automatisch oder auf Klick Gegenmaßnahmen einleiten (Prozess killen, Gerät isolieren, Datei quarantänieren).
• Defender for Office 365 (ATP): Schutz für E-Mail und Kollaborationsdienste. Kernfunktionen: Safe Attachments (Anhänge werden in Sandbox geöffnet und geprüft, bevor sie dem User zugestellt werden) und Safe Links (URLs in E-Mails/Teams werden erst durch einen Filter geleitet, der bekannte bösartige Links blockt bzw. beim Anklicken in Echtzeit checkt). Zudem Anti-Phishing-Algorithmen, die z.B. markieren, wenn jemand in einer Mail vorgibt Ihr CEO zu sein (Impersonation detection).
• Defender for Identity (früher Azure ATP): Speziell für hybride Umgebungen, läuft auf Ihren Domain Controllern on-prem und analysiert dort den Datenverkehr/die Logs auf verdächtiges Verhalten (z.B. jemand versucht Pass-the-Hash, oder ungewöhnliche LDAP-Anfragen, oder ein Account wird auf zig Maschinen gleichzeitig gesehen). Damit überwachen Sie Ihr Active Directory auf Angriffe, die dann eventuell Richtung Cloud gehen könnten.
• Defender for Cloud Apps (früher MCAS – Microsoft Cloud App Security): Eine Cloud Access Security Broker (CASB). Überwacht Nutzeraktivitäten und Datenflüsse in Cloud-Anwendungen – primär natürlich M365, aber auch Drittapps wie Google Workspace, Box, etc. MCAS kann z.B. erkennen: Benutzer lädt ungewöhnlich viele Dateien aus SharePoint herunter, oder ein OAuth-Token wird an eine unbekannte App gegeben, oder Daten fließen zu Dropbox obwohl verboten. Man kann Policies definieren, die solche Vorgänge blockieren oder melden. Auch die Conditional Access App Control läuft über dieses Modul: Damit können Sie z.B. sagen „Wenn ein Nutzer über einen Webbrowser aus dem Internet auf SharePoint zugreift, darf er zwar lesen, aber Downloads werden geblockt“ – das wird dann live im Sessionfluss kontrolliert.
• Microsoft 365 Defender Portal: Dies ist die einheitliche Oberfläche, in der die Signale aller o.g. Dienste zusammenlaufen (oft spricht man hier von XDR – Extended Detection and Response). D.h., wenn z.B. Defender for Endpoint auf einem PC Malware entdeckt und kurz davor eine Phishing-Mail an denselben User gemeldet wurde, kann das Portal dies als verbundenen Vorfall darstellen. Für die Security-Analysten ergibt sich so ein Gesamtbild der Attacke statt lauter losen Einzelmeldungen.

Wie setzt man die Defender-Suite konkret ein? Meistens so:

• Defender for Endpoint auf allen Geräten ausrollen: Windows 10/11 haben den Defender Antivirus ja bereits vorinstalliert. Mit einer E5-Lizenz oder Defender for Endpoint Plan 2 Lizenz schalten Sie zusätzlich die EDR-Komponenten frei. In Intune oder via Skript onboarden Sie alle Geräte ins Defender-Portal. Ab dann sehen Sie jeden PC mit seinem Risikostatus, bekommen Alerts, wenn z.B. eine verdächtige EXE ausgeführt wurde, und können sogar von der Cloud aus auf das Gerät reagieren (Isolieren vom Netzwerk, forensische Untersuchung starten etc.). Wichtig: Tuning nicht vergessen – z.B. sogenannte Attack Surface Reduction (ASR) Rules einschalten. Das sind Regeln wie „Office darf kein Script starten“ oder „Blockiere verdächtige Behaviours von PSExec“ usw. Diese kann man über Intune oder Group Policy aktivieren und sie verhindern schon viele typische Angriffswege bevor überhaupt ein Virenscanner anschlagen muss.
• Defender for Office 365 – Policies konfigurieren: Viele Kunden glauben, E5 einschalten genügt. Weit gefehlt: Sie müssen im Security & Compliance Center (bzw. mittlerweile im Defender Portal unter Policies) die entsprechenden Richtlinien einrichten. z.B. eine Safe Attachments Policy: „Prüfe alle Mails mit Anhängen, stelle sie verzögert zu bis Scan fertig“ oder im dynamischen Modus „stelle sofort zu, aber sperre den Anhang und entsperre ihn nachträglich wenn sauber“. Gleiches mit Safe Links: definieren, für welche Nutzer/URLs das greifen soll, ob Links in Teams oder Office-Anwendungen umgeschrieben werden etc. Tipp: Erst mit Reporting-Modus testen um zu sehen, wie viele Mails betroffen wären, dann scharf schalten.
• Phishing-Schutz einstellen: Defender4O365 hat Optionen wie Impersonation Protection (schützt vor Angriffen, wo z.B. ein Angreifer mit Absender „Vorstand_Meyer@fakedom.de“ schreibt – das System erkennt Name „Meyer“ ähnelt echtem Geschäftsführer, warnt den Empfänger). Aktivieren Sie diese und pflegen Sie ggf. benutzerdefinierte Listen (z.B. eigene Domänen oder VIP-Namen).
• Defender for Identity – wenn AD on-prem vorhanden: Deployen Sie die Sensoren auf allen Domänencontrollern. In E5 ist die Lizenz drin, es wäre verschenkt, es nicht zu nutzen – gerade wenn Sie noch einen Fuß on-prem haben, denn viele Advanced Threats bewegen sich seitwärts durchs AD. Im Portal tauchen dann Alarme auf wie „Reconnaissance using LDAP“, „Brute Force Attack on AD Account“ etc. So etwas würde man in reiner Cloud gar nicht sehen.
• Defender for Cloud Apps – Cloud-Monitoring: Hier ist initial etwas Aufwand nötig, damit es Wert bringt. Ich rate: Erstellen Sie ein paar sinnvolle Policies, z.B. „Massenhaftes Herunterladen von Dateien“ (wenn User >1000 Dateien in einer Stunde aus SharePoint/OneDrive runterlädt -> Alarm), „Anmelden aus unmöglicher Reise“ (Azure AD meldet das eigentlich schon, aber MCAS kann es auch aufgreifen), oder „OAuth-App mit zu hohen Rechten autorisiert“ (wenn jemand einer App All-Access aufs Mailbox gibt -> Alert). Auch beliebt: Shadow IT Discovery – sofern Sie Proxy- oder Firewall-Logs ans MCAS senden, erkennt es, welche Cloud-Dienste im Unternehmen genutzt werden, und bewertet deren Risikoprofil. Sie erfahren evtl., dass Mitarbeiter Dropbox, WeTransfer & Co. nutzen, was Governance-Themen auslösen kann. MCAS ist ein Universalschweizermesser, aber man sollte gezielt 4-5 Hauptanwendungsfälle definieren, sonst verliert man sich in den Möglichkeiten.

So reagiert man im Ernstfall: Die beste Erkennung nützt nichts, wenn keiner reagiert. Hier sollte ein Incident Response Prozess definiert sein (siehe Governance Kapitel). Microsoft 365 Defender erleichtert die Reaktion mit automatisierten Playbooks: z.B. kann Defender for Endpoint so eingestellt werden, dass es bei bestimmten Bedrohungen das Gerät auto-isoliert oder die schädliche Datei auf allen Geräten in Quarantäne setzt (Threat Intelligence: „Datei X kommt auf Block-Liste, falls auf anderen Geräten vorhanden, dort auch entfernen“). Aber ganz ohne Menschen geht es nicht: Ihre Security-Analysten oder Admins sollten das Portal regelmäßig prüfen oder besser noch Alerts per E-Mail/Teams bekommen bei High Severity Incidents.

Ich empfehle vielen Kunden, ab einer gewissen Größe, die Integration mit einem SIEM (z.B. Microsoft Sentinel oder ein bestehendes Splunk/QRadar) zu prüfen, oder zumindest die Einrichtung von automatischen Abos: man kann Power Automate Flows oder Logic Apps bauen, die bei neuen Incidents eine Nachricht an ein Teams-Kanal posten, damit es nicht untergeht.

Noch ein Hinweis: Defender ist nicht gleich Defender. Microsoft verwendet den Namen inflationär. Achten Sie genau auf die Lizenzierung: Einige Basis-Schutzmechanismen hat man schon mit Office 365 E3 (z.B. Exchange Online Protection Anti-Spam/Malware, Grundfunktionen von Defender Antivirus in Windows 10). Die hier beschriebenen Premium-Funktionen (EDR, Threat Hunting, Safe Links etc.) erfordern in der Regel M365 E5 oder die entsprechenden Add-On-Lizenzen. Im Lizenzkapitel dazu mehr. Wichtig ist, zu verstehen, welche Komponenten man hat. Ich stoße bei Kunden manchmal auf falsch konfigurierte Umgebungen: Man glaubt, die EDR laufe, aber in Wirklichkeit fehlt die Lizenz oder der Onboarding-Schritt. Daher: Machen Sie am Anfang einen Security Baseline Check (gern im Rahmen meines Starter-Pakets 😉), um festzustellen, welche Defender-Features schon aktiv sind und welche brachliegen.

Resümee Threat Protection: Mit der Defender-Suite verfügen Sie über ein umfassendes Alarmsystem und Abwehrwaffen. Stellen Sie sich vor, Microsoft 365 ist ein Gebäude: Defender for Endpoint sind die Kameras und Wachhunde im Gebäude, Defender for Office 365 ist der Scanner und Sprengstoff-Spürhund an der Poststelle, Defender for Identity ist der Türspion am Keller, und Defender for Cloud Apps sind Bewegungsmelder in allen Räumen. Und Microsoft 365 Defender führt alles in einer Sicherheitszentrale zusammen. Aber: Sie müssen die Systeme auch scharf schalten, warten und besetzen. Nichts ist gefährlicher als eine Sirene, die heult und keiner hört hin. Lieber weniger Policies, aber die wichtigen im Blick, als 100 Alarme pro Tag, die keiner mehr ernst nimmt (Stichwort Alarmmüdigkeit).

Im nächsten Kapitel kümmern wir uns um das, was geschützt werden soll: die Daten. Wie klassifizieren und schützen wir Informationen in M365, sodass sie gar nicht erst in falsche Hände geraten?

5. Datenklassifikation & Schutz (Purview, DLP, Insider Risk)

Daten sind das „Gold“ Ihres Unternehmens. Identitäten und Geräte sind die Tresortüren, aber wir sollten auch sicherstellen, dass das Gold selbst einen Farbstoff hat, sodass man es erkennen würde, wenn es jemand stiehlt. Oder weniger bildlich: Wir klassifizieren Daten nach Sensibilität, schützen sie durch Verschlüsselung und verhindern mit Richtlinien, dass vertrauliche Informationen unkontrolliert abfließen. Microsoft hat hierfür die Purview-Suite (früher unter dem Schlagwort Compliance/MIP – Microsoft Information Protection – bekannt).

5.1 Sensitivity Labels & Verschlüsselung (MIP/Purview Information Protection)

Der erste Baustein ist die Datenklassifikation mittels Sensitivity Labels. Als Unternehmen sollten Sie definieren, welche Klassen von Informationen es gibt – z.B. Öffentlichkeit, Intern, Vertraulich, Geheim (oder was immer zu Ihnen passt). Für jede Klasse legen Sie fest, welche Schutzmaßnahmen gelten. Microsoft Purview ermöglicht, diese Klassen als Labels direkt in Dokumente und E-Mails einzubetten. Beispielsweise:

• Label „Öffentlich“: Kein Schutz nötig, evtl. nur ein kleiner Footer im Dokument „öffentlich“.
• Label „Vertraulich – intern“: Dokument wird als vertraulich markiert, optional mit einem Wasserzeichen oder Header „Company Confidential“. Technisch könnte man hinterlegen, dass z.B. das Dokument nur von Mitarbeitern der eigenen Firma geöffnet werden darf (Integration mit Azure AD-Berechtigungen).
• Label „Streng geheim“: Dokument wird verschlüsselt, nur Benutzer in bestimmten Gruppen (z.B. Vorstand) dürfen es öffnen, Weiterleiten per E-Mail ist blockiert, Drucken evtl. untersagt. In Excel könnte man Copy/Paste deaktivieren, etc. Zusätzlich wird auf dem Dokument ein dicker roter Hinweis eingeblendet, damit jeder gleich weiß: Achtung, hochsensibel.

Diese Labels kann der Benutzer manuell setzen (meist per Dropdown im Office-Menü „Vertraulichkeit“). Man sollte die Mitarbeiter schulen, wann welches Label zu verwenden ist. Alternativ oder ergänzend kann man automatische Label-Zuweisung einrichten: z.B. wenn ein Dokument Personalausweisnummern oder Kreditkartennummern enthält, könnte es automatisch als „Vertraulich“ markiert werden. Das erfordert allerdings Purview (früher AIP) P2-Lizenzen und etwas Feintuning.

Technisch im Hintergrund sorgt das MIP-Framework dafür, dass bei verschlüsselten Labels die Keys verwaltet werden (entweder von Microsoft oder BYOK/Hold Your Own Key bei Bedarf), und die Office-Anwendungen wissen, wie sie geschützte Inhalte behandeln müssen. Ein Outlook erkennt z.B.: Mail als „Nur intern“ gelabelt -> dann kann es verhindern, dass ein externer Empfänger im „To“ steht. Oder Office verweigert das Öffnen eines „Strictly Confidential“-Dokuments auf einem Gerät, das nicht im Firmen-AAD angemeldet ist.

Praxis-Tipp: Starten Sie einfach – definieren Sie zunächst 3–4 Klassifizierungen. Viele machen anfangs den Fehler, 7 Stufen mit komplizierten Regeln zu definieren, keiner blickt durch und die User labeln gar nichts. Besser: Weniger ist mehr. Auch gut: Auto-Labeln in Exchange Online aktivieren für bestimmte Dinge – z.B. jede Mail, die an externe Empfänger geht und bestimmte Schlagworte/Daten enthält, bekommt automatisch Label X. So wird das Bewusstsein geschärft.

Beachten Sie die Balance: Nicht alles muss verschlüsselt werden. Wenn ein Team ein Dokument intern als vertraulich markiert, muss es vielleicht nicht verschlüsselt sein, solange es in SharePoint bleibt. Zu restriktive Verschlüsselung führt zu Produktivitätsverlust („Ich kann das Dokument nicht öffnen – mein Key geht nicht“). Oft ist ein visuelles Labeling (Wasserzeichen/Kennzeichnung) schon ein Schritt, damit Mitarbeiter bewusster mit Infos umgehen. Die Technik sollte die Kultur unterstützen: Klassifizierung funktioniert nur, wenn alle mitziehen.

5.2 Data Loss Prevention (DLP) – damit nichts rauspurzelt

DLP-Policies sind sozusagen die Datensicherheits-Nanny: Sie passen auf, dass vertrauliche Informationen nicht unerlaubt nach draußen gelangen. Microsoft Purview DLP lässt sich in verschiedenen Kanälen einsetzen: Exchange (Mails), SharePoint/OneDrive, Teams Chat und sogar für Endpunkte (Win10/11 Geräte mit Intune/MDE Integration).

Ein klassisches Beispiel: Sie wollen verhindern, dass jemand versehentlich Kundendaten an einen externen Empfänger mailt. Sie erstellen eine DLP-Regel: „Wenn eine E-Mail an extern geht und mehr als 10 personenbezogene Datensätze enthält oder als ‚Vertraulich‘ gelabelt ist, dann blockiere die Mail und informiere den Absender.“ Outlook würde dann die Mail nicht senden und eine Meldung anzeigen: „Diese Nachricht enthält vertrauliche Infos und darf das Unternehmen nicht verlassen.“ Man kann Ausnahmen definieren (z.B. bestimmte Manager dürfen trotzdem oder bestimmte Empfängerdomänen sind erlaubt, etc.) – aber Sie haben einen Schutz vor dem versehentlichen Leak.

Ähnlich in Teams: Schreiben User im Teams-Chat z.B. Kreditkartennummern, kann Teams den Beitrag unterdrücken („Nachricht blockiert, vertrauliche Informationen erkannt“) – sehr nützlich, um Mitarbeiter auch in Chats zu sensibilisieren. In SharePoint/OneDrive kann DLP das Teilen unterbinden: Beispiel: jemand versucht, eine streng geheime Datei via „Freigeben-Link“ an einen externen Gast freizugeben. Wenn die Datei als streng geheim markiert oder inhaltlich sensibel ist, kann DLP diese Aktion blocken oder zumindest melden.

Endpoint DLP erweitert das aufs Gerät: etwa das Kopieren einer sensiblen Datei auf einen USB-Stick verhindern oder das Hochladen ins Web via Browser stoppen. Das ist allerdings E5-Terrain und erfordert die richtige Clientkonfiguration.

Praxis: Ich setze mit Kunden oft ein paar Kern-DLP-Richtlinien auf, z.B.:

• Persönliche Daten schützen (DSGVO): Blockieren oder warnen, wenn Datensätze wie Personalausweisnummer, Sozialversicherungsnummer, Gesundheitsdaten etc. extern gehen.
• Finanzinformationen schützen: Kreditkartennummern, Bankverbindung – ähnlich, limitieren auf berechtigte Empfänger (z.B. Zahlungen nur an Bank via definierter Schnittstelle, nicht wild per E-Mail).
• Vertrauliche Klassifizierung respektieren: Wenn ein Dokument als „Intern vertraulich“ gelabelt ist, soll es nicht an externe gesendet werden dürfen.
• Quellcode/Geheimhaltung: Falls relevant, definieren wir eigene Patterns (z.B. Projektnamen, interne Klassifikationsmarker) und verhindern deren Austritt.

DLP hat auch die Möglichkeit, „Policy Tips“ anzuzeigen, anstatt direkt zu blockieren. Das ist didaktisch wertvoll: Der User bekommt z.B. beim E-Mail-Schreiben einen gelben Hinweis „Achtung, das sieht nach sensiblen Daten aus, wollen Sie das wirklich verschicken?“. Dann kann er es trotzdem tun (wird aber geloggt). So lernen Nutzer, was geht und was nicht, ohne dass gleich der Mailversand hängt. Später kann man die Schraube fester ziehen (auf „Block“ statt „Warnung“ stellen), wenn alle sich dran gewöhnt haben.

Aufsicht & Mitbestimmung: In deutschen Unternehmen sind DLP/Insider-Funktionen ggf. mitbestimmungspflichtig (Betriebsrat) – schließlich werden damit Mitarbeiteraktivitäten überwacht. Ich habe Projekte erlebt, die daran scheiterten, dass der Betriebsrat auf die Barrikaden ging („überwacht uns nicht!“). Daher: Binden Sie früh Ihre Datenschutz- und Compliance-Stellen ein. Transparenz ist wichtig: definieren Sie klar, welche Regeln warum eingeführt werden und kommunizieren Sie sie an die Belegschaft („Wir verhindern damit, dass Ihr versehentlich das Falsche teilt – es schützt auch euch!“). Dann gibt’s auch weniger Widerstand.

5.3 Insider Risk Management & weitere Purview-Features

Insider Risk Management (IRM) ist ein fortgeschrittenes Tool aus der Purview-Suite, das verschiedene Signale zusammenführt, um menschliches Fehlverhalten zu erkennen. Das kann böswillig sein (z.B. ein Mitarbeiter, der vor Kündigung noch Kundenlisten stiehlt) oder unbewusst (ständiges Verstoßen gegen Sicherheitsrichtlinien aus Unwissenheit). IRM wertet Telemetrie aus: Dateiaktivitäten, DLP-Verstöße, anstößige Sprachwahl in Mails/Teams (falls aktiviert), Anmeldemuster etc. und erstellt Risikoprofile von Benutzern. Taucht jemand oft mit Regelverstößen auf, kann ein Case eröffnet werden. Security/HR können das prüfen und ggf. Untersuchungen einleiten.

Beispiel: Ein Mitarbeiter lädt innerhalb einer Woche 10 GB Firmendaten auf sein privates Cloud-Konto hoch (erkannt durch Defender for Cloud Apps) und hat kurz zuvor seine Kündigung eingereicht (Signal aus HR-System manuell eingegeben). Insider Risk würde hier Alarm schlagen – Gefahr von Datenabfluss durch austretenden MA. Man kann dann reagieren, z.B. genau prüfen was er hochgeladen hat, Gespräche führen oder das Konto sofort sperren, je nach Schwere.

Wichtig: IRM ist kein Selbstläufer. Man benötigt jemanden (CISO-Team, Compliance), der sich aktiv damit beschäftigt und Cases verfolgt. Zudem sind datenschutzrechtliche Aspekte zu bedenken: solche Überwachung bedarf in der Regel Zustimmung des Betriebsrats oder zumindest Information der Mitarbeiter laut Datenschutzgesetz. In manchen Branchen ist es schon üblich (Banken, Pharma), in anderen sehr sensibel.

Neben IRM bietet Purview noch weitere relevante Funktionen, kurz genannt:

• Audit (Unified Audit Log): zentrales Protokoll aller wichtigen Aktivitäten (Anmeldung, Mail verschickt, Datei gelöscht, eDiscovery Zugriff etc.). Für forensische Zwecke Gold wert. In E3 haben Sie 90 Tage Aufbewahrung, in E5 bis 1 Jahr (und mit Add-on sogar 10 Jahre). Also wer tiefergehende Audits braucht, E5 Compliance oder extra Lizenz einplanen.
• eDiscovery: Falls mal rechtliche Fälle auftreten (oder DSGVO Auskunftsersuchen), können Sie mit Purview eDiscovery Daten durchsuchen und exportieren. Advanced eDiscovery (E5) erlaubt es, Workflows zu definieren, deduplizieren, Tagging etc. Für unsere Sicherheitsthematik ist es am Rande interessant: z.B. nach einem Vorfall kann eDiscovery helfen, alle Kommunikation eines verdächtigen Users zu durchleuchten.
• Retention / Records Management: Umfasst Aufbewahrungsrichtlinien für Daten. Sicherheitsrelevant ist z.B.: Wenn jemand einen Teams-Chat löscht – bleibt er trotzdem abrufbar? Mit Aufbewahrung (Retention) können Sie sicherstellen, dass bestimmte Daten nicht (sofort) gelöscht werden, auch nicht vom Nutzer. Gerade für die Nachvollziehbarkeit nach Sicherheitsvorfällen oder für die Revision ist das unerlässlich. Beispiel: 1 Jahr Aufbewahrung aller Team-Chats, auch wenn der Nutzer sie löscht, bleiben sie im Purview-Archiv. So kann niemand durch Löschen seine Spuren vollends verwischen.
• Compliance Score / Manager: Hilft, gesetzliche Vorschriften und interne Standards zu managen – eher strategisch. Für Security-Leute ist eher der Secure Score (im Defender Portal) spannender, der konkrete Sicherheitsmaßnahmen vorschlägt. Aber im Compliance Manager können Sie z.B. sehen, wie gut Sie bestimmte Controls (nach DSGVO, ISO27001 etc.) erfüllt haben, inkl. technischer und organisatorischer Maßnahmen.

Zusammengefasst: Datenklassifizierung und -schutz ist oft die zweite Welle, nach dem Absichern von Identitäten/Geräten. Es geht hier viel um Policy und Governance: Sie müssen wissen, was geschützt werden soll, wer Zugriff haben soll und wohin Daten fließen dürfen oder nicht. Die Microsoft-Tools sind mächtig und können viel automatisieren – aber man muss sie mit Bedacht konfigurieren. Fangen Sie mit klar umrissenen Policies an (die 2-3 wichtigsten Datenarten schützen) und erweitern Schritt für Schritt. Und vergessen Sie nicht, die Mitarbeiter mitzunehmen: Eine schöne Klassifikation hilft nichts, wenn 90% der Belegschaft weiter alles als „Öffentlich“ markiert, weil es bequemer ist. Kultur und Technik gehen Hand in Hand.

Weiter geht’s nun mit der Sicherheit unserer täglichen Arbeitsplattformen: Teams, SharePoint und Exchange. Wie stellt man sicher, dass gerade in diesen offenen, kollaborativen Tools nichts aus dem Ruder läuft?

6. Teams/SharePoint/Exchange-Sicherheit

Microsoft Teams, SharePoint Online und Exchange Online (Outlook) sind die zentralen Anwendungen, mit denen Benutzer tagtäglich arbeiten. Hier fließen die Informationen, hier passieren aber auch viele Sicherheitsvorfälle (sei es durch Phishing-Mails, falsch geteilte Dokumente oder ungebetene Gäste in Teams-Meetings). In diesem Abschnitt betrachten wir spezifische Sicherheitstipps für diese Dienste – wobei vieles bereits durch die vorherigen Kapitel abgedeckt ist (z.B. greifen MFA, Conditional Access, Defender, DLP natürlich auch hier!).

6.1 Teams-Sicherheit: Gäste, Gruppen & Governance

Microsoft Teams ist quasi der Hub für Zusammenarbeit – und damit auch ein potenzieller Daten-Hotspot. Einige Empfehlungen für Teams:

• Gastzugriff steuern: Teams erlaubt es, externe Gäste in Teams einzuladen (B2B-Gäste in Azure AD, wie in Kapitel 2 besprochen). Stellen Sie grundsätzlich Richtlinien auf: Wer darf Gäste hinzufügen? Welche Informationen dürfen in Teams mit Gästen geteilt werden? Technisch können Sie in Teams Guest Access generell erlauben oder abschalten (Tenant-weite Einstellung). Meist will man es erlauben, aber kontrolliert. Setzen Sie z.B. via Azure AD Entitlement oder Skript durch, dass neue Gäste erstmal in einer „Waiting“-Gruppe landen, bis ein Admin freischaltet. Auch können Sie Teams-Sensitivity Labels nutzen: Es gibt die Möglichkeit, ein ganzes Team als „Vertraulich“ zu labeln – je nach Label werden bestimmte Team-Funktionen eingeschränkt (etwa, dass Gäste gar nicht hinzugefügt werden dürfen, oder dass das Team nicht nach außen sichtbar ist). Diese Labels definieren Sie im Purview Compliance Center unter Information Protection und verknüpfen sie mit Team-Sicherheitseinstellungen.
• Teams Meeting-Sicherheit: In Zeiten von Homeoffice sind Video-Meetings Dauerzustand. Sorgen Sie dafür, dass Meetings nicht zum Sicherheitsleck werden: nutzen Sie Lobby-Funktionen (externen Teilnehmer erst manuell zulassen), verhindern Sie, dass jeder präsentator sein kann (Standardpolicy so einstellen, dass nur Organisator präsentiert, oder gezielt freigibt), schalten Sie Aufzeichnungen und Transkripte auf Wunsch aus, wenn brisante Themen (oder achten Sie umgekehrt drauf, dass Aufzeichnungen auch entsprechend geschützt abgelegt werden). Ein oft übersehener Punkt: Teams Chat mit Externen – man kann in Teams direkt mit externen Konten chatten (Federation). Überlegen Sie, ob Sie das nur mit bestimmten Domänen erlauben wollen (Allow list) oder generell offen (Risk: Mitarbeiter chattet mit „Kollege“ auf externem Account, könnte aber auch ein Fake sein).
• Datenresidenz & Monitoring: Teams speichert Dateien im SharePoint des Teams bzw. in OneDrive der Nutzer (für 1:1 Chats). DLP greift dort (Kapitel 5). Stellen Sie sicher, dass Teams-Chats auch aufbewahrt werden, falls Compliance es verlangt (Retention Policy). Überlegen Sie, ob bestimmte Teams private Channels verwenden sollten, um heikle Themen nur einem kleinen Kreis zugänglich zu machen. Und überwachen Sie öffentliche Teams (falls Sie welche haben, die jeder joinen kann), dass dort keine sensiblen Sachen geteilt werden, die lieber privat sein sollten.
• Lebenszyklus & Berechtigungen: Jedes Team entspricht einer Microsoft 365-Gruppe, inkl. SharePoint Site. Wer ein Team erstellt, wird Besitzer und kann weitere Besitzer/Mitglieder hinzufügen. Sie sollten eine Governance haben, die verhindert, dass Teams nach dem Motto „ungepflegt wachsen“. Löschen Sie alte Teams, oder nutzen Sie Azure AD Policies, die Inaktive Gruppen archivieren/löschen nach X Monaten ohne Nutzung (mit Warnung an Besitzer vorher). Und: Schauen Sie hin, wer alles Besitzer von wichtigen Teams ist. Besitzer können Gäste hinzufügen und haben Vollzugriff. Prinzipiell sollten pro Team mindestens 2 Besitzer sein (Redundanz), aber auch nicht viel mehr (Kontrollverlust).
• Third-Party-Apps in Teams: Teams ermöglicht die Integration vieler Apps (von Confluence bis Wetter-Bot). Zertifizieren Sie am besten einen Katalog erlaubter Apps. Nicht, dass ein schlauer Nutzer eine App installiert, die Daten abzieht. In den Teams-Einstellungen im Admin Center können Sie steuern, ob Benutzer selbst Apps hinzufügen dürfen oder nur Admins. Eine Whitelist vertrauenswürdiger Apps (und alle anderen standardmäßig blockiert) ist die sichere Variante in sensiblen Umgebungen.

6.2 SharePoint & OneDrive: Datenspeicher mit Tücken

SharePoint Online (und darunter subsumiert OneDrive for Business, was technisch einfach „Mein persönliches SharePoint“ pro User ist) ist der Datei-Dreh- und Angelpunkt. Sicherheit hier dreht sich vor allem um Zugriffskontrolle und Freigaben:

• Externe Freigaben: Definieren Sie eine Policy für externes Teilen. Mögliche Einstellungen: komplett aus (sehr restriktiv), nur mit externen Gästen, die im AD registriert sind (etwas restriktiv, kein anonymer Link), oder mit anonymen Links (sehr offen, jeder mit Link hat Zugriff). Für sensible Daten empfiehlt sich, anonyme Links zu verbieten. Lieber „Nur benannte Gäste“. Und selbst dann: Überlegen Sie, in welchen Sites externe freigegeben sein dürfen. SharePoint erlaubt, pro Site die externen Freigabeeinstellungen anzupassen. Ich habe z.B. bei einem Kunden die Regel: Es gibt eigene Sites für Extranet-Zusammenarbeit, dort dürfen Owner Gäste einladen. Alle anderen internen Sites: keine externen Freigaben erlaubt. So schließt man aus, dass jemand versehentlich den Ordner „Personalabteilung\Gehaltslisten“ extern teilt.
• Berechtigungen & Vererbung: SharePoint ist flexibel, was Berechtigungen angeht – zu flexibel manchmal. Es endet oft in Chaos, wer alles Zugang hat. Meine Empfehlung: Bauen Sie ein strukturiertes Berechtigungskonzept: Nutzen Sie die Standardgruppen (Besitzer, Mitglied, Besucher) pro Site und packen Sie dort AD-Gruppen rein statt individuelle User, wo es geht. Minimieren Sie das Aufbrechen der Vererbung auf Dokumentenebene – das wird schnell unübersichtlich. Lieber eigene Bibliotheken oder Ordner mit eindeutig getrennten Rechten als 100 einzelne Berechtigungen kreuz und quer.
• Sensitivitätsbezeichnung für Sites: Es gibt die Möglichkeit, Sites automatisch mit einem Sensitivity Label zu versehen (via PowerShell oder Center), wenn z.B. das Team oder die Gruppe dahinter ein Label hat. Dadurch kann man z.B. regeln: „Site als streng geheim gelabelt => keine externen Freigaben möglich, erfordert eine Teams-Meeting-Lobby für Meetings im Team“ usw. Dies ist ein mächtiges Governance-Tool, bedarf aber initialer Konfiguration.
• Überwachung und Alerts: Aktivieren Sie Auditing auf SharePoint (sollte Standard sein) – so können Sie nachvollziehen, wer welche Datei angesehen, heruntergeladen, gelöscht hat. Bei Datenlecks ist das Gold wert. Setzen Sie Alarmregeln: z.B. „Mehr als 500 Dateien in 5 min heruntergeladen“ => Alarm (könnte Indiz für Massendownload durch gehackten Account sein). Diese Mechanismen sind teils im Defender for Cloud Apps enthalten oder über das Unified Audit Log.
• Synchronisation & BYOD: Viele nutzen OneDrive Sync oder öffnen SharePoint über Home-PCs. Über Conditional Access können Sie Downloads blockieren auf unsicheren Geräten oder nur Webzugriff erlauben. Nutzen Sie das: Wenn jemand sich extern auf SharePoint einloggt, können Sie per Session Policy erzwingen, dass im Browser alles nur schreibgeschützt ist. So bleiben Daten auf dem Server und landen nicht auf dem fremden Gerät.
• OneDrive Richtlinien: Stellen Sie sicher, dass OneDrive für verlassende Mitarbeiter gehandhabt wird (Stichwort „OneDrive retention for deleted users“ – automatisch dem Manager Zugriff geben und Daten nach X Tagen löschen). Sonst haben Sie Leichen liegen oder Datenverlust, wenn keiner dran denkt.

6.3 E-Mail/Exchange: Alter Wein in neuen Schläuchen

Exchange Online ist „E-Mail in der Cloud“ – einerseits revolutionär mit KI-gestütztem Spamfilter, andererseits sind E-Mails immer noch E-Mails, mit den gleichen altbekannten Risiken: Spam, Phishing, falsche Empfänger, menschliche Fehler. Ein paar spezielle Hinweise:

• E-Mail-Authentifizierung (SPF, DKIM, DMARC): Stellen Sie sicher, dass Ihre Domains geschützt sind gegen Spoofing. Ein SPF-Eintrag sollte gesetzt sein (verhindert nicht alles, aber gehört dazu). DKIM: Signieren Sie ausgehende Mails mit DKIM-Schlüsseln, um Ihre Domain zu legitimieren. DMARC: Implementieren Sie eine DMARC-Richtlinie (idealerweise „reject“ für falsche Absender), um zu verhindern, dass jemand in Ihrem Namen Mails zustellt. Das verringert die Chance, dass Ihre Domain für Phishing missbraucht wird.
• Exchange Transport Rules & DLP: Neben Purview DLP (Kapitel 5) gibt es auch klassische Exchange-Transportregeln. Nutzen Sie diese für einfache globale Richtlinien, z.B. ein Disclaimer mit Sicherheitshinweis an alle externen Mails dranhängen („Achtung, diese Mail kommt von extern – seien Sie wachsam bei Anhängen!“). Oder blockieren Sie bestimmte gefährliche Dateitypen (falls nicht schon durch Defender) oder E-Mails an bestimmte Domains.
• Mailbox-Aufbewahrung & rechtssicheres Archiv: Prüfen Sie, ob Sie Aufbewahrungspflichten für E-Mails haben (Stichwort GoBD, HGB für Geschäftsbriefe). In Exchange Online kann man mit Retention Tags Mails x Jahre aufbewahren und dann löschen oder mit Litigation Hold einfach alles ewig speichern (kostet aber Speicher). Wichtig: Machen Sie sich einen Plan, sonst wachsen Postfächer ins Unendliche. Und löschen Sie keine Mails, die gesetzlich 6-10 Jahre aufbewahrt werden müssen. Hier müssen Legal/Compliance und IT zusammenspielen.
• Mailbox-Zugriffe überwachen: Wenn ein Admin mal in ein Postfach reinschaut (Stichwort eDiscovery oder im Supportfall), wird das protokolliert. Schauen Sie ins Auditing rein, um sicherzugehen, dass z.B. kein Admin „neugierig“ in Chef-Postfächern stöbert. Prinzip: Vertrauen ist gut, Kontrolle ist besser.
• Phishing Simulation & Schulung: E-Mail bleibt Haupt-Einfallstor. Überlegen Sie, Tools wie Attack Simulator (im Defender O365 P2) zu nutzen, um Phishing-Tests zu fahren. Oder externe Awareness-Kampagnen. Je mehr Ihre Mitarbeiter Phishing erkennen, desto weniger muss die Technik ausbaden.
• Verschlüsselung von Mails: Empfehlen Sie, wo sinnvoll, verschlüsselte Mails (S/MIME oder Office Message Encryption via Sensitivity Labels) für den Versand sensibler Daten. Gerade an externe Partner kann man via Office 365 Message Encryption E-Mails senden, die nur nach Authentifizierung geöffnet werden können. Das verhindert, dass z.B. eine vertrauliche Mail im falschen Postfach landet und gelesen wird.
• Kein Open Relay & interne Mailflüsse: Wenn Sie noch On-Premises Mailserver angebunden haben, sichern Sie die Verbindungen gut ab (TLS, IP-Einschränkungen). Verhindern Sie, dass über Ihre hybriden Pfade Spam injiziert wird. Microsoft schaltet ja generell offene Relays dicht, aber hybride Setups können Lücken aufreißen, wenn On-Prem kompromittiert wird.

Zusammenfassung für Kollaborationsdienste: Viele der Sicherheitsfeatures sind bereits in vorherigen Kapiteln adressiert (z.B. DLP schützt auch E-Mail/Teams, MFA schützt OWA etc.). Wichtig ist, die spezifischen Einstellungen dieser Apps nicht zu vergessen. Teams als modernes Tool hat andere Stellschrauben als das klassische Exchange. Und SharePoint als Datendrehscheibe muss restriktiver betrachtet werden als früher der Fileserver, weil Freigabe über Unternehmensgrenzen hinweg so einfach geworden ist. Ich sage manchmal: „Früher musste man Dateien umständlich per Mail rausschicken oder USB-Stick klauen – heute reicht ein Klick auf ‚Teilen‘ in SharePoint. Also brauchen wir digitale Schutzgeländer, damit niemand aus Versehen über die Brüstung fällt.“

7. Governance, Compliance & Prozesse

Nachdem wir nun die technischen Bausteine durchgegangen sind, bleibt die Frage: Wer kümmert sich eigentlich um all das dauerhaft? Hier kommt der organisatorische Teil ins Spiel: Governance (die Steuerung durch Richtlinien und Verantwortlichkeiten), Compliance (Einhaltung von Vorschriften) und definierte Prozesse (für Betrieb, Änderungen und Vorfälle). Technik ohne Organisation ist wie ein Sportwagen ohne Fahrer – könnte super fahren, tut’s aber nicht alleine.

7.1 Rollen, Verantwortlichkeiten & RACI

Die Einführung von M365-Sicherheitsmaßnahmen erfordert klare Zuständigkeiten. Ein bewährtes Mittel ist eine RACI-Matrix, die für wichtige Aufgaben festlegt, wer verantwortlich ist (R = Responsible), wer die letzte Entscheidung hat (A = Accountable), wer konsultiert wird (C = Consulted) und wen man einfach informiert (I = Informed). Unten ein Beispiel für eine solche Matrix in einem typischen mittelständischen Unternehmen:

Aufgabe / Prozess	IT-Leitung (CIO/IT-Leiter)	CISO / IT-Security	M365-Admin-Team	Compliance Officer / Datenschutz	Revision / Audit
Sicherheitsstrategie & Policies festlegen	A (Genehmigt Strategie)	R (Erstellt Konzepte)<br>C (mit CIO abstimmen)	C (technische Machbarkeit)	C (regulatorische Anforderungen einbringen)	I (bekommt Richtlinien)
Zugriffsrechte & Identitäten verwalten	I (überschaut grob)	C (beratend für Privilegien)	R (führt User- und Admin-Management durch)<br>A (für operativen Prozess)	I (bei kritischen Rollen)	I
Sicherheitsvorfälle behandeln (Incident Response)	C (entscheidet bei Eskalation)	A (führt IR-Prozess an)<br>R (Analyse, Koordination)	R (sofortmaßnahmen technisch umsetzen)	C (bei Datenschutzverletzungen)	I (Bericht am Ende)
M365-Sicherheitskonfiguration (MFA, CA, etc)	I	R (gibt Vorgaben, Best Practices)	A/R (setzt im Tenant um)	C (bei Ausnahmen, Policy-Freigabe)	I
Monitoring & Reporting (Sec. Score, Logs)	I	R (definiert KPI, überwacht regelmäßig)	R (erstellt Reports, Dashboards)	C (erhält Compliance-Reports)	A (prüft Wirksamkeit, fordert Nachweise)
Schulung & Awareness der Nutzer	A (Budget und Priorität)	R (Inhalte und Kampagnen definieren)	C (Input zu technischen Themen)	C (Compliance-Inhalte, z.B. DSGVO)	I
Änderungen/Changes an Sicherheitssettings	C (bei großer Tragweite)	C (Risikoabschätzung)	R (plant und implementiert Change)<br>A (für Durchführung)	I (falls Policies betroffen sind)	I
Überprüfung von Berechtigungen (Access Reviews)	I	R (initiiert Prozess)	R (führt technisch aus, berichtet)	C (Sicht auf kritische Datenzugriffe)	I

(Hinweis: Die obige Matrix ist ein Beispiel. Die tatsächlichen Zuordnungen variieren je nach Organisation; in kleinen Firmen trägt manchmal eine Person mehrere Hüte, in großen gibt es dedizierte Teams. Wichtig ist, klar festzuhalten, wer was macht.)

Wie man sieht, spielen mehrere Rollen zusammen: IT-Leitung sorgt für Rückendeckung und Budget, der CISO (falls vorhanden) oder generell Sicherheitsverantwortliche treibt Konzeption und Kontrolle, das M365-Admin-Team setzt um, Compliance/Datenschutz achtet auf regulatorische Aspekte, und Revision/Audit überprüft unabhängig, ob alles wirksam umgesetzt ist. Selbst wenn Sie keinen dedizierten CISO haben, sollte jemand die Security-Agenda innehaben – besser nicht „nebenbei“ durch rein technische Admins, da diese oft im Tagesgeschäft untergehen.

7.2 Prozesse: Vom Change Management bis zum Notfallplan

Ein oft unterschätzter Teil: Prozessdefinition. Folgende Prozesse sollten Sie im Kontext M365-Sicherheit etabliert haben:

• Change Management für Sicherheitsfeatures: Wie führen Sie neue Security-Configs ein? (Stichwort: CA-Policy erst testen, dann global ausrollen, mit Freigabe durch Change Advisory Board oder zumindest durch 4-Augen-Prinzip). Dokumentieren Sie Änderungen an sicherheitsrelevanten Einstellungen in einem Log. Nichts ist schlimmer, als wenn eine Einstellung geändert wird und niemand weiß es – bis es knallt. Beispiel: Ein Admin schaltet aus Versehen den Conditional Access aus und merkt es nicht…
• Access Management Prozess: Eintritt, Wechsel, Austritt von Mitarbeitern. Muss formal geregelt sein: Wer meldet IT den Eintritt? Welche Standard-Zugriffsprofile gibt es? Was passiert bei Abteilungswechsel? Und vor allem: Offboarding-Checkliste (Account sperren/löschen, Gruppe entfernen, Gerät zurück, OneDrive an Vorgesetzten übertragen etc.). Je definierter dieser Prozess, desto geringer das Risiko von Karteileichen oder übersehenen Berechtigungen.
• Incident Response Plan: Erstellen Sie einen Notfallprozess für Cloud-Sicherheitsvorfälle. Das sollte enthalten: Wer ist im Incident Response Team? (z.B. CISO + M365 Admin + PR + Legal je nach Schwere). Wie erreicht man sich 24/7? (Rufbereitschaft?). Was sind erste Schritte je nach Szenario: Bsp. „Global Admin Account kompromittiert“ –> Sofort PIM deaktivieren, Break-Glass-Account nutzen, Passwort Reset, Tokens invalidieren, dann forensisch untersuchen; oder „Massenphishing im Gange“ –> alle User Warnmail schicken, Exchange Rule zum Löschen der Mail setzen, etc. Schreiben Sie das nieder, zumindest als Notfallkarte (siehe Artefakte Kapitel). Im Ernstfall rettet ein kühler, vorbereiteter Kopf viel.
• Regelmäßige Überprüfungen / Audits: Legen Sie Intervalle fest: z.B. vierteljährlicher Security Health Check (Logs durchsehen, Secure Score vergleichen, offene Tasks identifizieren), halbjährlicher Rechte-Audit (prüfen, ob zu viele GA’s, ob alle Gäste noch notwendig etc.), jährlicher Compliance-Review (erfüllen wir alle Anforderungen neuer Gesetzeslagen? DSGVO-Check, ISO27001 falls relevant). Diese Aufgaben sollten jemand auf dem Zettel haben (siehe RACI).
• Supplier/Third-Party Management: Falls Sie Dienstleister an Ihren Tenant lassen (z.B. ein externer Admin von einer IT-Firma), regeln Sie das vertraglich und technisch: z.B. Privileged Access per PIM auch für externe, eigenes Gast-Konto je Support-Mitarbeiter, MFA-Pflicht. Dokumentieren Sie, wer externen Zugang hat und prüfen Sie das regelmäßig. Viele vergessen solche „Hintertüren“.
• Backup/Recovery Prozesse: Microsoft übernimmt viel (z.B. Hochverfügbarkeit, Redundanz). Dennoch: Überlegen Sie, wie Sie versehentliche oder böswillige Datenlöschung auffangen. Beispielfragen: Könnten Sie eine wichtige Mail wiederherstellen, die vor 120 Tagen gelöscht wurde? (E3 könnte eng werden ohne extra Archiv). Haben Sie im Notfall Zugriff auf alle Daten (z.B. E-Discovery?), wer darf das anordnen? Manche Unternehmen setzen dennoch auf Dritthersteller-Backups für M365, um schneller einzelne Elemente wiederherstellen zu können. Abwägen: es kostet extra, aber erhöht Komfort und Sicherheit bei Datenwiederherstellung. Prozessual: Testen Sie ab und zu Desaster-Szenarien („Angenommen, ein Ransomware verschlüsselt SharePoint, kommen wir an die Versionen/Backups?“ – gut zu wissen, wie).
• Kommunikations- und Eskalationswege: Definieren Sie, wie sicherheitsrelevante Informationen geteilt werden. Bsp: Ein Benutzer meldet ein verdächtiges Mail („ich glaube, Phishing“), an wen geht das weiter? Helpdesk first-level? Oder direkt Security-Team? Wie informieren Sie die gesamte Firma im Fall einer akuten Phishing-Welle? (Ich empfehle, bereits fertige Mail/Teams-Nachricht Vorlagen parat zu haben, damit man im Ernstfall schnell warnen kann).
• Betriebsdokumentation: Halten Sie alle wichtigen Einstellungen und Architekturentscheidungen schriftlich fest. Im Auditfall oder beim Personalwechsel ist das Gold wert. Idealerweise haben Sie eine Knowledge Base: z.B. wo steht, welche Conditional Access Policies es gibt und warum, welche DLP-Regeln aktiv sind, wie der PIM konfiguriert ist etc. Das erleichtert auch die Revision enorm.

7.3 Compliance-Management & Zertifizierungen

Je nach Branche müssen Sie bestimmte Compliance-Vorgaben erfüllen (ISO 27001, TISAX, BSI-Grundschutz, HIPAA, etc.). M365-Sicherheit muss in diese Rahmen eingepasst werden:

• Mapping zu Controls: Nutzen Sie Tools wie den Compliance Manager in Purview, der viele Microsoft 365 Controls zu gängigen Frameworks mapped. So sehen Sie, wo Sie stehen. Beispiel: Für ISO 27001 gibt es Anforderungen an Zugangskontrolle – Sie können dokumentieren, dass MFA/CA/PIM dies erfüllen.
• Dokumentation für Audit: Bereiten Sie Unterlagen vor, die ein Prüfer sehen will: Policies (gern möchte ein Auditor die schriftlichen Sicherheitsrichtlinien sehen), Nachweise (Reports über MFA-Nutzung, PIM-Aktivierungen, Logs von Zugriffsverletzungen). Viele Auditoren kennen M365 mittlerweile, aber es hilft, ihnen die Infos mundgerecht zu liefern: z.B. ein Export der Risky Sign-In Reports, oder ein Auszug der Azure AD Roles und ihrer Assignments, etc.
• Mitbestimmung & Datenschutz: Gerade Funktionen wie Überwachung, DLP, IRM bedürfen Abstimmung mit dem Betriebsrat in DE/CH. Holen Sie diese vorab ins Boot, klären Sie die Spielregeln (z.B. wer darf Ergebnisse von Insider Risk sehen? i.d.R. nur ein spezielles Gremium, nicht jeder Admin). Legen Sie im Datenschutzkonzept fest, welche Mitarbeiterdaten wie verarbeitet werden (z.B. Logfiles, wer liest die aus). Ich rate: Lieber offen darlegen und gemeinsam Leitlinien erarbeiten, als heimlich aktivieren und riskieren, dass der Betriebsrat es spitzkriegt – dann hängt der Haussegen schief.
• Herstellerneutralität & Cloud-Risikoabschätzung: Auch wenn wir hier Microsoft-Tools nutzen, sollten Sie zumindest einmal geprüft haben: Ist das akzeptabel für uns, Daten in der Cloud zu haben? Die meisten werden sagen ja (Argumente: Microsoft hat extrem hohe Sicherheitsstandards, ISO/Zertifikate, Datenhaltung in EU etc.). Einige streng regulierte Bereiche (öffentlicher Sektor, Geheimschutz) haben eventuell zusätzliche Vorgaben. Als Governance-Maßnahme sollte es einen Board-Beschluss oder eine offizielle Entscheidung geben, dass man M365 nutzt, mit Abwägung der Risiken (Cloud Act, Ausfallrisiken etc.) und entsprechenden Mitigations (z.B. Verschlüsselung, Backup, vertragliche Zusätze wie DPA, EU Standard Clauses). Falls die Revision fragt „Warum durften wir überhaupt in die Cloud?“, sollte die Doku parat liegen.
• Continuous Improvement: Governance heißt auch, dranzubleiben. Die Bedrohungslage ändert sich, Microsoft bringt neue Features raus (z.B. seit 2023 Continuous Access Evaluation, oder neue Entra Services). Planen Sie ein, Ihre Sicherheitsmaßnahmen jährlich zu überprüfen und anzupassen. Was heute Cutting Edge ist, kann in 2 Jahren Standard sein und etwas Neues nötig. Beispielsweise war vor ein paar Jahren MFA optional, heute Pflicht; morgen vielleicht passwordless als Standard? Seien Sie bereit, Ihre Governance nachzuschärfen. Cloud heißt auch: neue Möglichkeiten kommen frequentiert per Update – als Sicherheitsverantwortlicher sollte man die relevanten News verfolgen (oder so jemanden wie mich haben, der im Rahmen eines Coachings regelmäßig auf Neuerungen hinweist 😉).

Kernbotschaft: M365-Sicherheit ist kein Projekt, das man abschließt, sondern ein dauerhafter Prozess. Governance & Compliance geben dem Ganzen den Rahmen und stellen sicher, dass nicht nur technisch etwas eingerichtet wird, sondern dass es gelebt wird. Es ist wie beim Fußball: Taktik (Policy) und Training (Schulung, Prozesse) sind genauso wichtig wie die eigentlichen Spieler (Tools). Ohne klare Spielregeln und einen Trainer, der das Team orchestriert, gewinnt man kein Spiel – egal wie teuer die Schuhe sind.

8. Lizenzen & Varianten (E3, E5, Add-ons)

„Brauche ich wirklich die teure E5-Lizenz, um sicher zu sein?“ Diese Frage höre ich oft. Die Antwort lautet: Es kommt darauf an. Microsoft hat Sicherheits- und Compliance-Funktionen auf verschiedene Lizenzen verteilt. Hier ein Überblick über die wichtigsten Features in den gängigen Paketen E3 vs. E5 sowie Zusatzoptionen:

Microsoft 365 E3 (bzw. Office 365 E3 + EMS E3) enthält bereits:

• Azure AD Premium P1: Das bedeutet, Conditional Access, grundsätzliche MFA-Unterstützung (z.B. via CA oder Security Defaults) und Features wie Passwortschutz, grundlegendes Identity Governance (aber nicht PIM). P1 ermöglicht auch Hybrid Join, Intune Compliance etc.
• Intune (Endpoint Management): Vollumfängliches MDM/MAM, Gerätemanagement wie beschrieben.
• Azure Information Protection P1: Grundlegende Sensitivity Labels und manuelles Klassifizieren, jedoch keine automatischen oder trainierbaren Klassifizierer, kein User Defined Permissions Label (das ist P2).
• Office 365 DLP (Basis): Sie können DLP-Regeln für E-Mail, SharePoint/OneDrive anlegen (nicht für Teams-Chats, das kam erst mit E5). Ebenso grundlegende Datenkennzeichnung im Content.
• Defender Antivirus (Windows built-in): Alle Win10/11 haben Defender AV, aber ohne EDR Cloud-Anbindung.
• Exchange Online Protection (EOP): Basis-Spamschutz und Malwarefilter für E-Mails, aber keine Safe Links/Attachments.
• Audit-Logs & Alerts: Standard Audit Log (90 Tage), einige grundlegende Alerts.
• Compliance Basics: Aufbewahrungsrichtlinien, Content Search, und eDiscovery Standard.
• Defender for Cloud Apps (Teils): Im E3/EMS E3 ist Cloud App Discovery (Shadow IT) in begrenzter Form enthalten, aber nicht die volle MCAS Suite.

Microsoft 365 E5 umfasst alles aus E3 plus im Wesentlichen:

• Azure AD Premium P2: Hierdurch erhalten Sie Privileged Identity Management (PIM), Azure AD Identity Protection (Erkennung von riskanten Anmeldungen, Leaked Credentials), und Access Reviews, Entitlement Management etc.
• Microsoft Defender for Endpoint Plan 2: Volles EDR, Bedrohungsanalyse, zentral gesteuertes AV mit Cloud KI, Gerätekontrolle (USB etc.), Threat & Vulnerability Management.
• Microsoft Defender for Office 365 Plan 2: Inkl. Safe Links, Safe Attachments, Phishing-Filter mit KI, Attack Simulator, Threat Explorer (Detailanalyse von Vorfällen), und automatische Response Playbooks für Mails.
• Defender for Identity: On-Prem AD Sensoren und Cloud-Analyse des AD Traffics.
• Defender for Cloud Apps: Vollversion CASB mit App Control, Conditional Access App Control, Cloud Discovery, Policy Enforcement etc.
• Microsoft 365 Defender unified portal mit Incident correlation (kommt quasi mit den obigen zusammen).
• Purview Advanced Features:
• DLP für Endpoints und Teams (erst E5 schaltet Geräteschutz und Teams-Chat-DLP frei).
• Insider Risk Management,
• Communication Compliance (Erkennung von z.B. Belästigung oder Insider Trading Indikatoren in Kommunikation),
• Advanced eDiscovery (mit Hold, Review Sets, Analysefunktionen),
• Customer Key (eigener Verschlüsselungskey Hinterlegung),
• Records Management (erweiterte Funktionen).
• Audit-Log bis 1 Jahr (und erweiterte Events im Log, z.B. Mailfachinhalte).
• Microsoft Sentinel Rabatt: E5 beinhaltet 5 MB/User Tag an kostenlose Sentinel Log-Ingestion (nicht viel, aber erwähnenswert falls SIEM).
• Microsoft Defender for Teams? (Kleiner Spaß am Rande: Es gibt kein separates, aber Safe Links schützt auch Teams in E5).

Add-On Varianten: Wenn E5 für alle User zu kostspielig ist, gibt es Optionen:

• Microsoft 365 E5 Security Add-On: Dies packt die Sicherheitskomponenten (Defender Suite + AAD P2) auf eine E3 drauf. Preislich ca. 11–12 € User/Mon (Stand 2025), also deutlich günstiger als volles E5 (das um die 30+ € liegt), dafür fehlen die Compliance-Features.
• Microsoft 365 E5 Compliance Add-On: Enthält Purview Advanced (Insider Risk, eDiscovery, Compliance Mgr) ohne die Security (Defender). Ggf. interessant für regulierte Branchen, die Compliance-Tools brauchen, aber bei Security andere Lösungen nutzen.
• Einzelne Workloads: Einige Dinge kann man standalone lizenzieren: z.B. Defender for Office 365 Plan 1 oder Plan 2 als Addon für E3 (Plan1 ~2 €, Plan2 ~5 € pro User/Mon). Oder Azure AD P2 separat für einzelne Admin-Accounts (~5 €). Oder Defender for Endpoint P1 (eine abgespeckte EDR ohne Threat Hunting, ca. 2,50 €). Die Standalone-Optionen machen Sinn, wenn man z.B. nur für einige Benutzer etwas braucht: Etwa P2 nur für Admins (für PIM), oder Defender O365 P2 nur für die, die viele Attachments bekommen.
• Microsoft 365 Business Premium: Für Vollständigkeit – falls Ihr Unternehmen <300 User hat, könnte Business Premium eine kosteneffiziente Lösung sein: Es enthält nämlich Intune, Azure AD P1, Defender for O365 P1, Defender for Endpoint P1. Damit hat man viele Sicherheitsfeatures aus E3/E5 im Paket ~18 €/User. Allerdings fehlen P2-Sachen und Limit 300 Nutzer. Für Enterprise-Kunden nicht relevant, aber KMUs sollten das kennen.
• Teams Phone / Viva etc.: Diese Addons tangieren Sicherheit kaum, außer evtl. Compliance Recording in Teams (Aufzeichnung für Regulierung, separate Lizenz).

Die Lizenzwahl sollte sich an Ihren Anforderungen orientieren:

• Brauchen Sie PIM und Identity Protection -> AAD P2 -> E5 oder at least E5 Security Addon.
• Brauchen Sie vollumfängliche Threat Protection (EDR, Safe Attach) -> ebenfalls E5/E5 Security.
• Legen Sie großen Wert auf Insider Risk & erweiterte Compliance -> E5 Compliance.
• Wenn Budget knapp: priorisieren. Ich sage oft: MFA geht auch ohne alles (via Security Defaults) – also keine Ausrede. Conditional Access braucht P1 – das hat man in E3. PIM & Defender Suite sind die Game-Changer, die E5 rechtfertigen, zumindest für Admins & High-Risk-User. Man kann auch Mischlizenzen fahren: z.B. nur 50 E5 für die Schlüsselpersonen, Rest E3. Microsoft erlaubt das technisch, man muss dann aber aufpassen, wie man Policies formuliert (z.B. eine CA-Policy mit „Require P2 features“ darf nur User treffen, die P2 haben).
• Achtung: Lizenz-Compliance nicht vergessen – wenn Sie z.B. CA für alle nutzen, sollte laut Vertrag jeder User auch AAD P1 haben. Microsoft prüft das selten, aber Audit könnte es ankreiden. Also offiziell: entweder allen P1/E3 geben oder Feature nur auf lizenzierte Subset anwenden. In der Praxis… Grauzonen, aber als Berater muss ich’s erwähnen.

Hier noch eine kleine Tabelle wichtiger Security-Funktionen vs. Lizenz:

Funktion	In E3?	In E5?	Hinweise
Multi-Faktor-Authentifizierung	Ja*	Ja	*MFA generell verfügbar, aber P1/P2 (E3/E5) nötig für CA und Feinsteuerung. Security Defaults auch ohne P1 nutzbar, aber eingeschränkt.
Conditional Access (grundlegend)	Ja (P1)	Ja	In E3 durch AAD P1 abgedeckt.
Azure AD Privileged Identity Mgmt	Nein	Ja	PIM erfordert AAD P2 (E5).
Azure AD Identity Protection (Risk-Based MFA)	Nein	Ja	Ebenfalls P2.
Intune (MDM, MAM)	Ja	Ja	Intune ist in E3/E5 gleichermaßen enthalten (EMS E3/E5).
Defender for Endpoint (EDR)	Teilw.**	Ja	**In E3 nur Defender AV (kein EDR). P1 (nur Win10 basic EDR) separat lizenzierbar. Voller EDR nur E5.
Defender for Office 365 (Safe Links/Attachments)	Nein (nur Standard EOP)	Ja	Plan 1/2 als Addon möglich für E3.
Defender for Identity (Azure ATP)	Nein	Ja	Nur mit E5 (oder E5 Security).
Defender for Cloud Apps (CASB)	Eingeschränkt	Ja	E3: Cloud Discovery only, E5: volle CASB.
Purview DLP E-Mail/SharePoint	Ja	Ja	Grund-DLP in E3, aber keine Endpoint/Teams-DLP.
Purview DLP für Endpunkte/Teams	Nein	Ja	E5 erforderlich für diese Kanäle.
Sensitivity Labels (manuell)	Ja	Ja	AIP P1 reicht für manuelles Labeln & verschlüsseln.
Auto-Labeling & trainable classifier	Nein	Ja	P2 Feature (E5 Compliance).
Insider Risk Management	Nein	Ja	E5 Compliance.
Audit Log 1 Jahr (und spezielle Events)	Nein	Ja	E5 Compliance (Advanced Audit).
eDiscovery Standard	Ja	Ja	In beiden, aber E5 hat Advanced eDisc.
Compliance Manager	Ja	Ja	Grundfunktionen in allen, aber einige Premium Assessments nur E5.
Teams Advanced Comms (Aufzeichnung Compliance)	Add-on	Add-on	Separates Add-On falls benötigt.

(Tabelle: nicht vollständig, aber fokussiert auf Security/Compliance Features.)

Lizenzkosten vs. Nutzen: Rechnen wir als Beispiel: Ein E3 kostet ca. 32 €/Monat/User, ein E5 ca. 55 €. Das ist 23 € mehr im Monat. Dafür erspart Ihnen E5 vielleicht den Kauf separater Lösungen (z.B. SIEM-Lizenzen, DLP-Tools, CASB von Drittanbietern). Und womöglich einen teuren Sicherheitsvorfall. Trotzdem: Nicht jeder braucht alles. Man kann gezielt entscheiden: für 100% der Nutzer E3 reicht, aber für 20% holen wir E5 Security, etc.

Noch ein Punkt: Lizenzverwaltung – Achten Sie darauf, dass ausgeschiedene Mitarbeiter die teuren Lizenzen nicht behalten. Ich fand mal bei einem Kunden 50 ungenutzte E5 zu je ~50€, macht 30k€ im Jahr sinnlos ausgegeben. Also: Prozesstechnisch nachverfolgen.

Abschließend: Die Lizenz soll Mittel zum Zweck sein. Lieber mit E3 sinnvoll abgesichert (MFA, CA kann man ja) als E5 kaufen und nicht konfigurieren. Ich hab beides gesehen. Das Optimum natürlich: die passenden Lizenzen kaufen und dann maximal ausnutzen. Dann haben Sie auch ROI in Form von Risikoreduktion.

9. Roadmap & Quick Wins (0–30, 30–90, 90–180+ Tage)

Rome wasn’t built in a day – und Ihre M365-Sicherheitsarchitektur auch nicht. Wichtig ist ein gestaffelter Fahrplan: Was sollte man sofort tun? Was mittelfristig? Was langfristig? Hier skizziere ich eine mögliche Roadmap, basierend auf der Erfahrung, was in den ersten 6 Monaten nach Start eines Security-Projekts typischerweise umgesetzt wird. Natürlich kann die Reihenfolge je nach Reifegrad variieren, aber nehmen wir an, Sie fangen relativ am Anfang an:

Quick Wins (0–30 Tage)

In den ersten 4 Wochen sollten Sie die „Low Hanging Fruits“ ernten – Maßnahmen, die hohe Wirkung bei relativ wenig Implementierungsaufwand haben:

1. MFA für alle aktivieren: Falls noch nicht geschehen, sofort MFA erzwingen. Anfangs kann man Security Defaults aktivieren oder eine simple Conditional Access Policy „MFA for all users“ (mit Ausnahmen für Break-Glass). Dazu Kommunikation an Anwender mit Hilfestellung (Authenticator einrichten). Das reduziert das Account-Kompromittierungsrisiko schlagartig um über 99% für die meisten Angriffe.
2. Passwort-Reset-Option & Monitoring: Stellen Sie sicher, dass alle Benutzer eine Methode hinterlegt haben, um ihr Kennwort selbst zurückzusetzen (SSPR, falls lizenziert) – reduziert den Helpdesk und erhöht Sicherheit (weil Nutzer nicht einfache PW wählen aus Angst vorm Vergessen). Außerdem: Azure AD Logging an, prüfen ob risky users/sign-ins vorliegen (wenn ja, direkt handeln: PWs zurücksetzen, User schulen).
3. Administratoren absichern: Überprüfen Sie die Admin Accounts: Wer ist Global Admin? Sofort auf das Minimum reduzieren. Aktivieren Sie für alle Admins bedingte Zugriffsregeln (z.B. MFA immer erforderlich, Zugang nur von Firmen-IP/VPN). Falls PIM verfügbar: gleich einrichten für Global Admin als Start.
4. Baseline-Sicherheitsrichtlinien: In Intune (sofern Geräte vorhanden) aktivieren Sie Baseline Policies oder erstellen z.B. eine generelle Konfig: BitLocker an, Bildschirmsperre nach 5 Min, Antivirus aktiv. In Defender Portal: Safe Attachments und Safe Links zumindest für hochriskante Empfänger (z.B. Vorstand, Finanzen) einschalten, wenn E5 vorhanden. In Exchange Online: Schalten Sie Basic Auth ab (falls Microsoft das nicht längst tat) – kann man per PowerShell schnell disablen.
5. Schnelle Sensibilisierung: Schicken Sie eine kurze Awareness-Nachricht an alle: dass neue Sicherheitsmaßnahmen kommen, warum MFA wichtig ist, wie man Phishing erkennt. Wenn vorhanden, nutzen Sie vielleicht gleich den Attack Simulator um ein harmloses Phishing-Testchen zu machen – wer draufklickt, bekommt Lernmaterial.
6. Notfallkonzept grob skizzieren: Identifizieren Sie sofort einen Notfall-Admin-Account (Break Glass) und testen Sie, dass der funktioniert (also exempt von MFA). Dokumentieren Sie ihn sicher. Legen Sie fest: Wer wird im Falle X angerufen? (Auch wenn der ganze IR-Plan in 30 Tagen nicht fertig ist, wenigstens die wichtigsten Kontakte und Maßnahmen parat haben). So sind Sie ab Tag 1 vorbereitet, falls doch was passiert.

Diese Quick Wins sind oft schon während der Projektplanung umsetzbar. Sie schaffen sofortigen Schutz in kritischen Bereichen und verschaffen Luft für die aufwändigeren Dinge.

Phase 2 (30–90 Tage)

In den nächsten 2 Monaten geht es daran, das Fundament zu festigen und erweitern:

1. Conditional Access ausbauen: Jetzt definieren Sie differenzierte CA-Policies: z.B. Gerätekonformität verlangen für SharePoint/Teams Zugriff (nur managed devices ans sensible Zeug), Blockieren riskanter Logins automatisch, evtl. Block Legacy Auth (wenn noch nötig) – falls noch im Report-Only getestet, jetzt enforced. Führen Sie ggf. Named Locations ein (bekannte Firmenstandorte als „vertrauenswürdig“, aber trotzdem MFA nach x Tagen).
2. Intune Rollout großflächig: In 0–30 haben Sie vlt. Pilot gemacht, jetzt alle Firmen-Devices enrollen. Parallel BYOD-Konzept veröffentlichen: wer will, kann sein Gerät mit Firmen-Apps nutzen (MAM). Stellen Sie Compliance-Richtlinien fertig ein und definieren Sie, wie mit nicht-konformen Geräten umgegangen wird (z.B. Grace-Period von 7 Tagen zum Patchen, dann Ausschluss).
3. PIM für restliche Rollen: Falls PIM vorhanden, konfigurieren Sie in dieser Phase alle wichtigen Admin-Rollen in PIM (Exchange, SharePoint, Teams Admin etc.). Schulen Sie die Admins, wie sie Rollen anfordern. Entfernen Sie alle User aus Rollen, die nicht nötig sind.
4. Defender Suite Feintuning: Jetzt nehmen Sie sich Defender for Endpoint vor: rollen Sie den Sensor auf allen Maschinen aus (via Intune oder Script), richten Sie automatische Threat Response für kritische Alarme ein (z.B. High Severity Auto-Isolate). Schauen Sie sich Secure Score und Device Vulnerabilities an – priorisieren Sie 2–3 Punkte (z.B. „oh, auf 50 Rechnern ist Firefox ungepatcht – gleich mal Updaten forcieren“). Für Defender for O365: polieren Sie Anti-Phishing-Policies (VIPs definieren), aktivieren Sie Spam-Quarantäne Benachrichtigung an Nutzer, etc.
5. DLP & Labels Pilot: Starten Sie ein Pilotprojekt für Sensitivity Labels: Definieren Sie Ihr Labelschema (z.B. ÖFFENTLICH, INTERN, VERTRAULICH). Erstellen Sie die Labels in Purview, konfigurieren Sie einfachen Schutz (VERTRAULICH = nur intern lesbar). Rollen Sie es testweise in einer Abteilung oder bei den Power-Usern aus, holen Sie Feedback. Ebenso DLP: bauen Sie 1–2 Policies (z.B. block Kreditkartennummer extern) im Test-Modus („Audit only“) und schauen, was gefunden würde. So verursachen Sie erstmal kein Aufschrei, gewinnen aber Erkenntnisse über die Datenflüsse.
6. Prozesse & Doku aufsetzen: Bis Tag 90 sollte der Incident Response Plan ausgearbeitet und abgestimmt sein. Machen Sie vielleicht einen kleinen Table-Top-Test: Simulieren Sie intern mal einen Vorfall („Was tun wir, wenn CFO-Account übernommen?“ – Ablauf durchsprechen). Ebenfalls in dieser Phase: finalisieren Sie alle Sicherheitsrichtlinien-Dokumente (Passwortpolicy, Acceptable Use, Klassifizierungspolicy etc.) und lassen Sie sie vom Management absegnen. Starten Sie Schulungen für Admins zu den neuen Tools (z.B. wie PIM funktioniert, wie man mit Defender Alerts umgeht).
7. Lizenz-Review: Wenn Sie gemischte Lizenzen fahren: Check nach 60 Tagen, ob Anpassungen nötig. Vielleicht merken Sie „hey, wir brauchen doch E5 für mehr Leute als gedacht“ oder umgekehrt. Jetzt wäre Zeit nachzujustieren bevor Jahresverträge fix sind. Auch: Aktivieren Sie Trials, falls unsicher (Microsoft bietet 90-Tage Trials für E5 z.B., perfekt um Phase 1+2 alles zu testen).
8. Governance-Board etablieren: Rufen Sie ein monatliches Security Board Meeting ins Leben (falls nicht schon existent). Teilnehmer: IT-Leiter, Security-Verantw., Admin-Team, Compliance. Dort Fort­schritte, Incidents, neue Bedrohungen besprechen. Das schafft Transparenz und hält das Thema präsent.

Am Ende der 90 Tage sollte das Gröbste erledigt sein: alle User haben MFA, die wichtigsten CA-Regeln schützen Zugriffe, Endgeräte sind unter Kontrolle, Admins entmachtet (im positiven Sinne 😉), Grundklassifizierung eingeführt, Prozesse definiert. Sie haben jetzt ein solides Grundgerüst.

Phase 3 (90–180 Tage und laufend)

Nun geht es in die tieferen Gewässer und Optimierung:

1. Ausbau von DLP/Compliance: Die in Phase 2 getesteten DLP-Regeln schalten Sie nun produktiv (ggf. mit Block/Warn). Erweitern Sie Abdeckung: z.B. Endpoint-DLP ausrollen, Teams-Chat DLP aktivieren. Führen Sie automatische Labeling für bestimmte SharePoint Libraries ein (z.B. alles im Finance-Site automatisch „Vertraulich“). Etablieren Sie Insider Risk Management falls gewünscht: d.h. holen Sie jetzt Betriebsrat ins Boot, definieren Sie Policies in IRM und schulen Sie das dedizierte IRM-Team, das solche Alerts behandelt (oft sind das Leute aus Sec/HR/Legal).
2. Schärfen der Sicherheitsrichtlinien: Jetzt wo das Basis läuft, können Sie z.B. MFA-Exceptions minimieren (in Phase 1 evtl. einigen ganz schwierigen Kollegen noch ne Ausnahme gelassen? Jetzt abschalten!). Oder Geolocation restriktiver setzen, oder strengere Session-Timeouts. Ebenso bei Intune: Compliance-Regeln strenger machen (z.B. Nach 30 Tagen ohne Kontakt -> non-compliant und sperren).
3. Erweiterte Threat Detection: Überlegen Sie den Schritt zu SIEM/SOAR: Microsoft Sentinel implementieren, um Logs langfristig zu speichern und komplexe Korrelationen/Automationen zu ermöglichen. Oder bestehendes SIEM anbinden. Erstellen Sie custom hunting queries in Defender (e.g. KQL in Advanced Hunting, um Proaktiv nach schädlichen Patterns zu suchen). Falls noch nicht, überlegen Sie 24/7 Monitoring – geht das intern? Sonst MSSP? (Achtung, ich weiß, keine Managed Services von mir, aber der Kunde kann ja trotzdem z.B. nen SOC beauftragen, falls nötig).
4. Kontinuierliche Schulung & Phishing-Tests: In der 180+ Tage Phase hat die Belegschaft sich an vieles gewöhnt, jetzt ist Zeit das Wissen zu vertiefen: Führen Sie regelmäßige Phishing-Simulationen durch (vierteljährlich), belohnen Sie gutes Erkennen, schulen Sie Nachzügler. Machen Sie vielleicht mal einen kurzen Security-Newsletter intern mit Tipps („Wussten Sie, dass Teams jetzt meldet wenn…“).
5. Zertifizierungen/Audits vorbereiten: Wenn geplant, können Sie nach ~6 Monaten genug implementiert haben, um eine ISO 27001 Zertifizierung anzugehen oder ein Kundenaudit zu bestehen. Machen Sie einen internen Audit-Check: Auditieren Sie z.B. 10 zufällige Accounts auf least privilege, 5 Teams auf Guest-Sharing, etc. – quasi Trockenübung vor echter Revision.
6. Maturity Assessment & Plan v2: Nach 180 Tagen ziehen Sie Bilanz: Wo stehen wir? Was fehlt noch? Erreichen wir schon „Level 2“ auf unserer internen Skala? Planen Sie darüber hinaus: evtl. Zero Trust Architektur weiter ausbauen (Netzwerksegmentierung, Verified ID?), Microsoft Entra Workload Identities sichern (Service Principals, etc.), DevOps Anbindung (falls Sie Cloud Apps entwickeln, z.B. GitHub OIDC etc.). Die Reise hört nie auf, aber nach 6 Monaten sind Sie so weit, nicht mehr nur Feuer zu löschen, sondern proaktiv Security als Enabler zu sehen.

Quick Wins vs. Langläufer: Es ist normal, dass einige Themen länger brauchen – z.B. Kulturänderungen (Klassifizierung) oder formaljuristisches (Betriebsrat, Policies vom Vorstand absegnen). Das Wichtige ist, parallel an den schnellen und den aufwändigen Themen zu arbeiten. Der Fahrplan soll sicherstellen, dass Sie schnell das Risiko senken, aber nichts Wesentliches auf ewig vor sich herschieben.

Aus eigener Erfahrung: Nach 180 Tagen kann man mit etwas Stolz zurückblicken, was erreicht wurde – und man wird auch erste Kennzahlen vorweisen können (z.B. „MFA-Abdeckung nun 99%, früher 10%“, „Phishing-Click-Rate von 20% auf 5% gesunken“ etc.). Das hilft, intern weiter Rückenwind fürs Thema zu erhalten und zu zeigen, dass sich die Investitionen lohnen.

10. Risiken, Stolpersteine & Anti-Pattern

Auch mit den besten Absichten kann bei der Umsetzung von M365-Sicherheit einiges schiefgehen. Hier nenne ich typische Stolpersteine und Anti-Muster, die ich immer wieder beobachte – damit Sie diese Fehler vermeiden können:

• Anti-Pattern 1: „Wir haben E5, also sind wir sicher.“ – Falscher geht’s kaum. Eine teure Lizenz schaltet zwar theoretisch Features frei, aber keine davon wirkt ohne Konfiguration. Ich habe leider Fälle gesehen, wo Kunden für Millionen E5 lizenzierten, aber MFA war aus (!), Defender nicht eingerichtet etc. Besser: günstiger lizenzieren und dafür 100% der Features nutzen, als umgekehrt.
• Anti-Pattern 2: Security by Obscurity – Manche glauben, wenn sie ihre Tenant-URL möglichst kryptisch haben oder Benutzer umbenennen, werden sie weniger angegriffen. Fakt ist: Angreifer scannen breit und benutzen geleakte Passwörter, da hilft es nicht, dass Ihr Global Admin „admin@firma.onmicrosoft.com“ heißt statt „Administrator“. Setzen Sie auf echte Kontrollen (MFA, CA) statt Scheinlösungen.
• Stolperstein: Zu viel, zu schnell – Wenn Sie auf einen Schlag 50 CA-Policies, 30 DLP-Regeln und 5 neue Security-Tools ausrollen, überfordern Sie sowohl die IT als auch die Endbenutzer. Folge: Chaos, Pannen (Admins ausgesperrt, User kommen nicht mehr an Dateien, Helpdesk glüht) und dann der Rückschlag: das Management will vielleicht alles wieder deaktivieren („Das stört das Business!“). Besser schrittweise vorgehen, Prioritäten setzen (siehe Roadmap) und Erfolge demonstrieren, statt Big Bang.
• Stolperstein: Unklare Verantwortlichkeiten – Wenn niemand genau weiß, wer sich um Security Alerts kümmert („Dafür haben wir doch IT, oder?“ – „Ich dachte, die InfoSec schaut da rein…“), dann bleiben Angriffe unentdeckt. Definieren Sie klar: Wer monitort die Systeme, wer reagiert zuerst, wann wird eskaliert. Sonst fällt etwas durchs Raster.
• Anti-Pattern 3: Ignorieren der Nutzerperspektive – Sicherheit, die die Usability komplett ignoriert, schlägt oft fehl. Beispiel: Sie verbieten Downloads aus SharePoint streng, aber Vertriebler müssen PDFs lokal fürs Kundengespräch speichern – was tun sie? Finden Schlupflöcher (Screenshot, private Mail schicken etc.). Besser: Mit den Fachbereichen Kompromisse finden, Pilotgruppen einbeziehen. Manchmal ist eine 90%-Lösung, die akzeptiert wird, wirkungsvoller als eine 100%-Security-Hammer-Maßnahme, die dann umgangen oder abgeschaltet wird.
• Anti-Pattern 4: Kein Plan für den Notfall – Augen zu und hoffen, es brennt nie, ist fahrlässig. Wer keine Notfallplanung hat, reagiert im Ernstfall kopflos. Ich habe erlebt, wie bei einem Ransomware-Angriff das Unternehmen tagelang brauchte, um grundlegende Schritte einzuleiten, weil niemand vorbereitet war. Halten Sie zumindest eine Notfall-Checkliste griffbereit und üben Sie sie einmal durch.
• Stolperstein: Kommunikationslücken – IT-Security wird oft als reines IT-Thema gesehen. Dabei müssen Abteilungen wie HR, Recht, Management ins Boot. Wenn z.B. die Personalabteilung nicht weiß, dass bei Kündigungen sofort gemeldet werden muss für Access Removal, bleibt mancher Account offen. Oder wenn Legal nicht mitteilt, welche Daten wir nie löschen dürfen, fehlt evtl. die richtige Retention. Silo-Denken ist hier Gift. Lieber eine bereichsübergreifende Runde etablieren (Security Committee).
• Anti-Pattern 5: „Das macht doch unser Dienstleister“ – Auslagern von Aufgaben ist okay, aber Verantwortung können Sie nicht auslagern. Wenn Sie einen Partner haben, der Ihre Umgebung betreut, müssen Sie trotzdem intern jemanden haben, der drauf schaut und Anforderungen vorgibt. Blindes Vertrauen in Dritte ohne Kontrolle ist riskant. (Übrigens: deshalb biete ich auch keine Managed Services an, weil ich überzeugt bin, dass Unternehmen ihre Security selber steuern sollten – ich helfe, coache, aber Sie müssen am Drücker bleiben.)
• Stolperstein: Fehlende Ausfallszenarien – M365 ist zuverlässig, aber was, wenn doch mal Cloud down oder Internet weg? Manche Firmen haben alles in Teams, und als mal ein Teams-Ausfall war, stand die Arbeit still. Planen Sie Workarounds: z.B. alternative Kommunikationswege, lokale Backups kritischer Dokumente für Notfälle (vorsichtig abzuwägen gegen Datenfrische), etc. Cloud heißt auch Abhängigkeit – minimieren Sie die Auswirkungen von Cloud-Störungen in Ihren Risikoanalysen.
• Anti-Pattern 6: Nichtstun aus Perfektionismus – Das Gegenteil von zu viel Aktionismus: Manche diskutieren ewig im Kreis, welche Lösung die allerbeste ist, und setzen derweil nichts um. Nach dem Motto: „Bevor wir MFA einführen, brauchen wir eine Strategie für Hardware-Tokens vs App vs SMS und erst das Okay vom Betriebsrat und Schulungen…“ – Währenddessen sind Accounts schutzlos. Manchmal ist es besser, unperfekte Zwischenlösungen einzuführen (z.B. temporär Security Defaults an und SMS-MFA erlauben, auch wenn man langfristig auf FIDO will), als Monate ohne Schutz zu lassen. Bewegliches Ziel: implementieren, lernen, iterieren.
• Stolperstein: Technische Schulden ignorieren – Haben Sie noch 2008er Domain Controller? Alte Office-Versionen ohne Modern Auth? User mit Windows 7? Solche Legacy-Baustellen können Sicherheitsprojekte hemmen (z.B. kann man Legacy Auth nicht abdrehen, weil alte Apps es brauchen). Ignorieren Sie diese Altlasten nicht – machen Sie einen Plan zum Ablösen oder Absichern (vielleicht via Applikationsproxy etc.). Cloud Security setzt oft gewisse Modernität voraus.
• Anti-Pattern 7: Einzelkämpfer-Mentalität – Ein Sicherheitsbeauftragter allein im stillen Kämmerlein wird nicht viel bewirken. Security ist Team-Sport. Binden Sie die Admins, Entwickler, Mitarbeiter ein. Holen Sie externes Wissen rein (Bücher, Community, Beratung) – man muss das Rad nicht neu erfinden. Wer meint „Ich mache das alles alleine, aber keiner darf’s wissen“, bleibt stecken.

Fehler sind menschlich – wichtig ist, daraus zu lernen. Wenn mal eine Policy schiefging (z.B. halbe Firma ausgesperrt durch einen Filter), dann analysieren, offen kommunizieren und verbessern. Keine Panikreaktionen („Dann halt gar keine Policies mehr!“), sondern kontinuierliches Verbessern. M365 bietet auch nette Tools, um Konfiguration zu vergleichen (Secure Score, Baselines), nutzen Sie das, um Anti-Pattern früh zu erkennen (z.B. Score sagt „Zu viele Global Admins“ – Aha!).

Ich sage meinen Kunden gern: „Wir müssen nicht perfekt sein, wir müssen besser sein als gestern und schnell reagieren, wenn was passiert.“ Das trifft es in der Cloud Security ganz gut.

11. Artefakte & Checklisten (Top-20-Maßnahmen, Notfallkarte, KPI-Vorlagen)

In diesem Abschnitt stelle ich einige praktische Artefakte und Checklisten vor, die Ihnen bei der Umsetzung und im Betrieb der M365-Sicherheit helfen können. Diese können Sie anpassen und in Ihre Dokumentation aufnehmen.

11.1 Top-20 Maßnahmen für M365-Sicherheit (Checkliste)

Nach all der Theorie hier eine condensierte Checkliste der wichtigsten Maßnahmen, die praktisch jedes Unternehmen in Microsoft 365 umsetzen sollte. Nutzen: Gehen Sie die Liste durch und haken Sie ab, was bereits erledigt ist – die offenen Punkte ergeben Ihren Action Plan:

1. MFA für alle Benutzer aktivieren – inkl. externe Gäste, Admins mit separatem Admin-MFA.
2. Legacy Authentication deaktivieren – Basic Auth, alte Protokolle abschalten oder per CA blocken.
3. Break-Glass-Adminkonten einrichten – 2 Notfallkonten, MFA-exempt, sicher verwahrt und überwacht.
4. Privileged Identity Management (PIM) implementieren – Falls AAD P2, sonst manuell Adminanzahl minimieren.
5. Conditional Access Baseline einführen – MFA erzwingen, riskante Logins blocken, Gerätetypen/Standorte steuern.
6. Azure AD Roles & Admin Zugriffe reviewen – Keine unnötigen Global Admins, Prinzip der minimalen Rechte umsetzen.
7. Intune Gerätemanagement ausrollen – Alle Firmengeräte enrollen, Compliance-Richtlinien setzen (Verschlüsselung, Patchstand etc.).
8. MAM für BYOD einrichten – App-Schutz für mobile Geräte ohne Enrollment konfigurieren (Outlook, Teams).
9. Windows Defender Antivirus/Firewall sicher konfigurieren – via Intune oder GPO Defender-AV aktiv lassen, Firewall an, Cloud Protection on.
10. Microsoft Defender for Endpoint aktivieren – Geräte onboarden, EDR Alerts monitoren, ASR-Regeln (Angriffsflächenreduzierung) aktivieren.
11. Microsoft Defender for Office 365 aktivieren – Safe Attachments, Safe Links Policies für E-Mail (und Teams/SharePoint) einrichten, Phishing-Schutz konfigurieren.
12. Alerting einrichten – Wichtige Alarme (z.B. neues Admin-Konto, Massen-Download, DLP-Verstoß) per Mail/Teams an Admins senden.
13. Sensitivity Labels definieren und ausrollen – 3–5 Stufen, mit entsprechendem Schutz (mind. Visual Labels, für hohe Stufen Verschlüsselung und eingeschränkte Freigabe).
14. Data Loss Prevention (DLP) Policies einführen – für E-Mail, SharePoint/OneDrive (und Teams, Endpunkte falls möglich) – zuerst überwachen, dann blockieren. Fokus auf personenbezogene Daten, vertrauliche Doku.
15. Teams-Gastzugriff und Sharing kontrollieren – Governance: Gäste nur via Policy zulassen, Teams-Sensitivity nutzen, externe Freigaben in SharePoint regulieren.
16. Retention Policies anwenden – Mailbox und Teams-Chats: Aufbewahrung nach Compliance-Vorgaben (z.B. 1 Jahr Chats, 6 Jahre Mails etc.), um forensisch und gesetzlich safe zu sein.
17. Secure Score prüfen & verbessern – Regelmäßig den M365 Secure Score ansehen, die top empfohlenen Aktionen umsetzen (viele davon sind in dieser Liste ohnehin enthalten).
18. Benutzer-Schulungen durchführen – Mindestens jährliches Security-Awareness Training, plus gezielte Phishing-Tests und Feedback.
19. Incident Response Plan erstellen – Notfallkontakte, Ablauf für typische Vorfälle (Account kompromittiert, Malware-Fund, Datenleck) niederschreiben; Team mit Rollen definieren.
20. Regelmäßige Audits & Reviews – z.B. vierteljährlich: Adminrechte überprüfen, Protokolle (Audit Log) stichprobenartig prüfen, neuen Bedrohungen nachjustieren. Jährlich: alle Sicherheitsrichtlinien auf Aktualität und Effektivität prüfen.

Diese Top-20 decken einen Großteil der zuvor besprochenen Inhalte praktisch ab. Natürlich gibt es branchenspezifisch weitere (z.B. Verschlüsselungspflichten, spezielle Protokollierung), aber als generelle Roadmap sind diese Punkte ein guter Maßstab.

11.2 Notfallkarte für Sicherheitsvorfälle (Pocket Guide)

Im Eifer des Gefechts denkt man nicht immer an alles. Daher empfehle ich eine „Notfallkarte“ – ein kurzes, griffbereites Dokument (im Idealfall auf einer Karteikarte oder OnePager), das im Krisenfall an den Wänden der IT hängt oder digital schnell abrufbar ist. Darauf stehen:

• Wichtige Kontakte: z.B. CISO / Security Officer Mobil +41…, Azure AD Global Admin OnCall: Name, Mobil, Microsoft Premier Support Hotline: …, Forensik-Dienstleister: …, Datenschutzbeauftragter: …, PR-Ansprechpartner (für öffentliche Kommunikation).
• Erste Schritte bei kritischen Vorfällen:
• Kompromittiertes Benutzerkonto: 1) Benutzerzugang sperren (in AAD Block-SignIn), 2) Passwort zurücksetzen, 3) alle Sessions token revoken (PowerShell/Portal), 4) Benutzer informieren und Rechner isolieren, 5) Überprüfen, was mit dem Account getan wurde (Audit-Log, Mail-Sent-Items).
• Malware-/Ransomware-Ausbruch: 1) Betroffene Geräte per Intune oder Defender isolieren (kein Netz), 2) Unternehmen weite Info raus („Bitte alle PCs verbunden lassen, nicht abschalten“ – oder Gegenteil je nach Fall), 3) Notfall-Team versammeln (ggf. war room in Teams einrichten), 4) Backups prüfen für Wiederherstellung, 5) Forensik einschalten.
• Datenleck (externe Freigabe oder Mail falsch): 1) SharePoint Link sofort invalidieren (Admin Center oder Löschen der Datei), 2) Falls Mail: Versuch Retract (wenn intern/Exchange), 3) Betroffenen Empfänger kontaktieren mit Löschbitte, 4) Info an Datenschutzbeauftragten (Meldepflicht bewerten, 72h Frist beachten bei DSGVO), 5) Ursache analysieren (War es DLP Versäumnis? Nutzerfehler?).
• Totalausfall M365 oder Tenant-Lockout: 1) Überprüfen, ob globales Problem (Azure Status), 2) Falls eigener Tenant Lockout (z.B. CA falsch konfiguriert, keiner kommt rein): Break-Glass Account benutzen (daher wichtig: offline parat haben!), 3) Microsoft Support anrufen falls nötig Tenant wieder freizuschalten, 4) Interne Notkommunikation aktivieren (z.B. Telefonliste, privates Email, WhatsApp Notfallgruppe – vorher definieren).
• Dokumentation & Kommunikation: Erinnerung: „Logbuch führen!“ – Uhrzeit, Ereignis, Maßnahmen notieren. Später für Report unerlässlich. Und „Kommunikation ist key“ – zeitnah Management updaten, bei Datenpanne ggf. Kunden informieren (nach Abstimmung). Lieber proaktiv informieren als dass es herauskommt.
• Verweis auf Playbooks: Wenn vorhanden, Pfade oder SharePoint zu detaillierten Playbooks („siehe Intranet/Notfall Ordner für detaillierte Anleitung Ransomware“).

Die Karte soll kein seitenlanges Doku-PDF ersetzen, sondern kurze, knappe Handlungsanweisungen und Kontakte bieten, damit niemand im Stress sucht „Wo war noch gleich die Nummer von…“. Diese kann man auch an externes Security-Personal verteilen (z.B. Wachdienst an Wochenenden: wen rufen die an bei IT-Alarm?).

11.3 KPI- und Alarm-Übersicht (Wichtige Kennzahlen)

Um den Erfolg Ihrer Security-Maßnahmen zu messen und im Blick zu behalten, lohnen sich einige KPI (Key Performance Indicators) und definierte Alarm-Schwellen:

Beispiel-KPIs:

• MFA-Abdeckung (%) – Anteil der Benutzerkonten, die MFA aktiv nutzen (Ziel: 100%). Metrik z.B. aus Azure AD Sign-in Logs: Unique Users with MFA / total users.
• Anzahl blockierter Anmeldeversuche – z.B. pro Woche, aufgeschlüsselt nach Grund (falsches Passwort, geblockt wegen CA). Zeigt Angriffsvolumen und Erfolg der Abwehr.
• Secure Score Wert – Microsoft Secure Score (global sowie pro Kategorie). Ziel hier ist Trend (sollte steigen) und im Vergleich zu Industriebenchmark (Microsoft gibt oft Durchschnitt an).
• Durchschnittliche Incident Response Zeit – Zeit von Alarm generiert bis Analyst nimmt ihn auf / bis Abschluss. Hier kann man anpeilen, kritische Incidents innerhalb X Stunden zu bearbeiten.
• Phishing-Erkennungsrate – z.B. bei internen Phishing-Tests: wieviel % erkannten (nicht geklickt) vs. wieviel klickten. Ziel: Klickrate unter Y%.
• Geräte-Compliance-Quote – Anteil der Intune-verwalteten Geräte, die compliant sind (Ziel: >95%).
• Patching-Level – z.B. % der Geräte mit <= 1 Monat altem Patchstand.
• DLP-Vorfälle – Anzahl DLP Policy Hits pro Monat (ggf. aufgeteilt in false positives vs echte).
• Anzahl kritischer Alerts im Defender-Portal – idealerweise geht die nach Erst-Sturm zurück und bleibt niedrig; falls steigend, Indikator für anhaltende Attacken oder Misskonfiguration (z.B. viele false positives).
• Lizenznutzung vs. Lizenzkosten – z.B. E5-Security Features aktiviert von X möglichen. Diese Rechtfertigungs-KPI ist intern fürs Management interessant: Nutzen wir, wofür wir zahlen?

Beispiel-Alarmierungen: (die sollten möglichst automatisiert sein)

• Massenhafte Anmeldefehler eines Accounts – > N Fehlschläge in 1 Stunde -> Alarm, könnte Hinweis auf Brute Force oder Passwortspray sein.
• Risky Sign-In detected (hoch) – Alarm sobald Azure AD einen riskanten Login als „hoch“ markiert (z.B. von Tor Node, impossible travel) – auch wenn AAD es blockt, lieber Fall aufmachen, warum es passieren konnte.
• Neue OAuth-App consented mit hohen Rechten – Alarm, wenn User eine App genehmigt, die z.B. „Read all files“ Rechte hat. (MCAS Policy).
• Ungewöhnlicher Massen-Download – Alarm, wenn User >X Dateien in kurzer Zeit zieht (wie erwähnt).
• DLP Block Aktion – Jedes Mal, wenn wirklich eine Mail oder File durch DLP geblockt wurde, sollte Sec/Admin informiert werden (man will nachfassen: war es legitimer False Positive oder ein echter Vorfall).
• Administrator zu Global Admin hinzugefügt – Alarm, falls jemand ohne PIM ein GA wird (sprich: falls man PIM umgeht oder Break-Glass verwendet wurde).
• Defender Geräte-Alarm kritisch – Natürlich, wenn Defender auf einem Endpoint „GoldenTicket Attack detected“ oder „Ransomware Activity“ ruft, dann Alarm ans Handy des On-Call Admin.
• Mailbox forwarding extern eingerichtet – Alarm, falls ein Regel „leite alle Mails an extern“ auftaucht (häufiges Mal-Behavior nach Compromise).
• Compliance Deadlines – Nicht technisch, aber organisatorisch: Reminder wenn z.B. in 3 Tagen ein DSGVO-Breach der Behörde gemeldet sein muss – kann man im Ticketing so abbilden.

All diese KPIs und Alarme sollten irgendwo visualisiert oder zumindest geloggt werden. Viele nutzen ein Sicherheits-Dashboard (in PowerBI oder Azure Monitor), wo man auf einen Blick sieht: „Grün, alles im Soll“ oder Handlungsbedarf. Insbesondere für Management-Reporting sind Visuals toll: z.B. Graph der MFA-Abdeckung im Zeitverlauf, oder ein Piechart der DLP-Vorfälle nach Kategorie.

11.4 Risiko- & Maßnahmenregister (Beispiel)

Als Teil der Governance ist es sinnvoll, ein Risiko-Register zu führen: Hier werden identifizierte Risiken gelistet und die zugehörigen Gegenmaßnahmen dokumentiert und getrackt. Ein Auszug daraus könnte so aussehen:

Risiko	Auswirkung	Wahrscheinlichkeit	Bewertung	Maßnahme(n)	Status
Benutzer fällt auf Phishing rein, Account wird kompromittiert	Datendiebstahl, Malspam an Kunden, evtl. weiterer Einbruch in Systeme.	Hoch (Phishing-Mails täglich)	Hoch	– MFA für alle einführen<br>– Phishing-Schulungen & Tests<br>– Defender for O365 Safe Links/Attachments einrichten	MFA: erledigt<br>Schulung: rollt<br>Safe Links: in Arbeit (Q4)**
Verlorenes/gestohlenes Laptop mit unverschlüsselter HDD	Zugriff auf lokale M365-Daten, evtl. Token noch aktiv -> Fremdzugriff auf Cloud, Datenleck.	Mittel	Mittel	– BitLocker via Intune forcen<br>– Gerät via Intune löschbar (Remote Wipe)<br>– Auto-Logout via CA (Geräte nach 14d offline require reauth)	BitLocker: erledigt<br>Wipe: Policy da<br>CA: offen (geplant)**
Missbrauch von Global Admin Rechten (intern oder extern)	Totalverlust Kontrolle Tenant, Manipulation Daten, Abschalten Sicherheitsfunktionen.	Niedrig (wenige Personen) aber Impact kritisch	Hoch	– PIM für alle Admin Rollen<br>– Break-Glass Accounts mit Monitoring<br>– Admin Activity Alerts (UnifiedAudit)	PIM: 50% (GA fertig, Rest offen)<br>BG Accounts: erstellt, Monitoring via Log**
Insider exfiltriert sensible Daten kurz vorm Austritt	Know-how-Verlust, Compliance-Verstoß DSGVO falls personenbezogen, Reputationsschaden.	Niedrig (Einzelfälle)	Mittel	– DLP auf Massenexports<br>– Insider Risk Mgmt aktivieren<br>– Offboarding Prozess: Zugriffe sofort entziehen bei Kündigung<br>– Logging + Alerts auf ungewöhnliches Download-Verhalten	DLP: aktiv<br>IRM: in Planung<br>Offboarding: Policy erstellt<br>Alerts: aktiv**
Kein Zugriff auf Tenant (alle Admins MFA locked)	Handlungsunfähigkeit bei Vorfall, Betriebsstopp.	Niedrig	Mittel	– 2 Break-Glass-Accounts ohne MFA<br>– Notfallzugriff-Doku extern speichern<br>– Regelmäßiger Test der Break-Glass Logins	Accounts: vorhanden<br>Doku: verteilt<br>Test: quartalsweise angesetzt**

(Bewertung: qualitativ oder numerisch je nach Risk-Management. Status: hier exemplarisch.)

So ein Register sorgt dafür, dass kein bekanntes Risiko unter den Teppich gekehrt wird. Man aktualisiert es z.B. quartalsweise, streicht erledigte Maßnahmen, fügt neue Risiken hinzu (z.B. neue Bedrohung „Session Cookie Theft“ mit Gegenmaßnahme Continuous Access Evaluation implementieren etc.). Es zeigt dem Management auch schwarz auf weiß: ja, es gibt Restrisiken, aber wir haben sie erkannt und tun A, B, C dagegen.

Die hier vorgestellten Artefakte – Checklisten, Notfallplan, KPI-Liste, Risikoregister – sind als Hilfsmittel gedacht, um die komplexe Aufgabe greifbarer zu machen. Nutzen Sie sie ruhig als Vorlage und passen Sie sie an Ihre Bedürfnisse an. In meiner Beratung erstelle ich solche Unterlagen oft gemeinsam mit dem Kunden, damit sie wirklich praxistauglich sind. Sie können diese Dokumente auch für Audits heranziehen, um zu demonstrieren, wie systematisch Sie das Thema Sicherheit angehen.

Beratungspakete (Starter, Professional, Enterprise)

Um Sie auf Ihrem Weg zu einer sicheren Microsoft 365-Umgebung zu unterstützen, biete ich drei Beratungspakete an. Wichtig: Alle Pakete werden persönlich von mir (Ulrich B. Boddenberg) durchgeführt – Sie buchen also mich als erfahrenen Consultant, kein anonymes Team. Und keine Sorge: Es handelt sich um zeitlich begrenzte Beratungsleistungen, keine dauerhaften Managed Services. Mein Ziel ist es immer, Ihr Team zu befähigen, nicht es zu ersetzen.

Starter-Paket

Zielgruppe: Unternehmen, die schnell einen Überblick und erste Verbesserungsschritte wollen – quasi ein Sicherheits-„Starter-Kit“ für M365.

Inhalte (typisch):

• M365 Security Health-Check (2 PT): Ich prüfe Ihre Tenant-Konfiguration auf die wichtigsten Sicherheitsaspekte (MFA, CA, Adminrollen, Exchange/SharePoint Freigaben, Secure Score etc.). Dazu nutze ich Checklisten ähnlich der Top-20.
• Ergebnis-Workshop (0,5 PT): Präsentation der Befunde, Prioritätenempfehlung und grober Maßnahmenplan. Hier bekommen Sie schon eine Roadmap 0–180 Tage skizziert.
• Quick-Win-Umsetzung (0,5 PT): Auf Wunsch setze ich 1–2 Quick Wins direkt um oder begleite Ihr Team dabei (Beispiele: Security Defaults aktivieren, eine CA-Policy einrichten, Logging aktivieren).
• Dokumentation & Management Summary: Sie erhalten einen kompakten Bericht mit den Ergebnissen, empfohlenen Maßnahmen und „Argumentationshilfe“ für Ihr Management, warum welche Schritte nötig sind.

Umfang: ca. 3 Tage Beratung, die idealerweise innerhalb 2–3 Kalenderwochen abgeschlossen werden (zur Fokussierung).

Preis: 3 PT × 1.500 € = 4.500 € (zzgl. MwSt., Reisekosten separat, wobei Starter meist remote machbar ist).

Professional-Paket

Zielgruppe: Unternehmen, die bereits wissen, wo es hakt, und nun mehrere Bereiche strukturiert verbessern wollen – mit externer Expertise zur Beschleunigung und Best Practices.

Inhalte (typisch, anpassbar):

• Workshop „Security Architecture“ (1 PT): Gemeinsames Design Ihrer M365-Sicherheitsarchitektur und Policies. Wir erarbeiten z.B. Ihr CA-Policy-Set, PIM-Role-Design, Intune Compliance Framework und Klassifikationsmodell, passend zu Ihrem Business.
• Begleitung Umsetzung (5 PT): Hands-on Unterstützung über mehrere Wochen: Ich helfe beim Einrichten von PIM, Definieren von DLP-Regeln, Konfigurieren von Defender, Testen von Szenarien. Praktisch arbeite ich eng mit Ihrem Admin-Team zusammen, als Coach und Mit-Handanleger (kein Body-Leasing, aber sehr praxisnah).
• Governance & Dokumentation (1 PT): Wir erstellen gemeinsam die nötigen Richtliniendokumente (z.B. Security Policy, Admin Guide für PIM, Notfallhandbuch) und richten ggf. ein Security Operations Meeting auf.
• Abschluss-Review & Optimierung (1 PT): Nach Umsetzung der wichtigsten Maßnahmen machen wir einen Review: welche KPI verbessert, wo noch Lücken? Feinjustierung der Einstellungen (z.B. Policiestuning nach erstem User-Feedback). Abschlussbericht mit Soll-Ist-Vergleich.

Umfang: ca. 8 Tage Beratung über einen Zeitraum von etwa 2–3 Monaten verteilt (z.B. 1–2 Tage/Woche im Peak, plus Nachbereitung).

Preis: 8 PT × 1.500 € = 12.000 € (zzgl. MwSt.). Hinweis: Reisezeiten/-kosten kommen hinzu, falls vor Ort Workshops gewünscht sind; vieles kann aber remote erledigt werden.

(Wenn z.B. der Bedarf 10 PT ist, wird entsprechend angepasst – flexibel nach Absprache.)

Enterprise-Paket

Zielgruppe: Größere Organisationen oder hochregulierte Unternehmen, die eine umfassende Security-Transformation ihres M365 anstreben, inkl. langfristiger Roadmap, Integration in Unternehmenssicherheit und ggf. Vorbereitung auf Audits/Zertifizierung.

Inhalte (Beispiel, tatsächlich sehr individuell):

• Strategie & Planungsphase (2 PT): Tiefergehende Analyse vorhandener Security- und Compliance-Strukturen, Anforderungen (z.B. ISO 27001, BSI Grundschutz). Erstellung eines maßgeschneiderten Sicherheitskonzeptes für M365 als Teil Ihrer Gesamt-IT-Security.
• Projektbegleitung & Umsetzung (mind. 10 PT): Über ~6 Monate begleite ich Ihr Projektteam. Wir setzen nicht nur die technischen Maßnahmen um (alle aus Professional-Paket und mehr), sondern kümmern uns auch um Organisatorisches: Schulungskonzepte, Betriebsratsworkshops (ich erkläre gerne technisch, was die Tools tun, um Ängste abzubauen), Prozessimplementierung. Ich stehe quasi als „Security-Advisor“ auf Abruf bereit während der Transformationsphase.
• Spezial-Themen nach Bedarf: z.B. Integration von M365-Logs in Ihr SIEM, Hybrid-Identität Spezialfälle, Custom-Skripting (PowerShell Automatisierung von Kontrollen), spezifische Compliance-Reports für Auditoren, etc. Hier bringe ich meine Erfahrung aus vielen Großprojekten ein.
• Abnahme & Audit-Vorbereitung (2 PT): Gemeinsame Durchsicht aller implementierten Controls, Probelauf für anstehenden Audit (wenn z.B. TÜV-Prüfung oder Kunden-Audit bevorsteht). Feinschliff an Dokumentationen, Erstellen einer Management-Präsentation mit den Ergebnissen der Security-Initiative (die können Sie dann im Vorstand vorzeigen 😉).

Umfang: mindestens 15 PT, oft eher 20–25 PT über 6–12 Monate (je nach Projektgröße). Die Verteilung ist flexibel, i.d.R. Mischung aus vor-Ort Workshops und remote Begleitung.

Preis: z.B. 15 PT × 1.500 € = 22.500 € (zzgl. MwSt.). Wird individuell kalkuliert nach Umfang – die Tagessatz-Formel 1.500 € bleibt als Basis immer bestehen, so haben Sie maximale Transparenz.

Gemeinsamkeiten aller Pakete: Sie bezahlen immer nur die Personentage meiner Beratungsleistung – keine versteckten Kosten, keine Provision für Lizenzen (herstellerneutral), keine Weiterverkauf von Managed Services. Nach Abschluss stehe ich Ihnen gern weiterhin zur Verfügung (z.B. im Rahmen eines Coaching oder regelmäßigen Health-Checks, abrechnungsbasiert), aber Sie entscheiden frei, ob und wann Sie weiteren Support brauchen. Mein Anspruch ist, dass Sie nach dem Projekt selbstständig und sicher weiterfahren können – quasi „Hilfe zur Selbsthilfe“, aber auf Expertenniveau.

Preisübersicht der Beratungspakete:

Paket	Leistungsumfang (ca.)	Preis (zzgl. MwSt.)
Starter	3 Personentage (kurzer Review & Quick Wins)	4.500 € + Reisekosten
Professional	8 Personentage (Workshop + Umsetzung Begleitung)	12.000 € + evtl. Reisekosten
Enterprise	15+ Personentage (umfangreiche Projektbegleitung)	ab 22.500 € (je nach PT)

(Reisekosten werden separat nach Aufwand berechnet – bei Vor-Ort-Einsätzen, etwa Anfahrt ab Dortmund und ggf. Übernachtung. Viele Leistungen lassen sich aber remote via Teams erbringen.)

Wenn Sie unsicher sind, welches Paket passt: Kein Problem. In einem unverbindlichen Vorgespräch klären wir Ihren Bedarf, und ich mache Ihnen einen Vorschlag. Manchmal starten Kunden mit Starter, und bauen dann auf Professional aus – iterativ geht auch. Wichtig ist mir, dass Sie genau die Unterstützung bekommen, die Sie brauchen, nicht mehr und nicht weniger.

FAQ – Häufige Fragen zur M365-Sicherheit

Im Folgenden beantworte ich 15 typische Fragen, die mir Kunden (IT-Leiter, CISOs, Admins und manchmal auch Geschäftsführer) zum Thema Microsoft 365 Security immer wieder stellen. Kurz und prägnant – und natürlich in lockerem Ton, so wie Sie mich kennen:

1. Brauche ich wirklich E5-Lizenzen, um M365 sicher zu machen?
Nicht zwingend für die Grundabsicherung. Die wichtigsten Basics wie MFA, Conditional Access und Geräteverwaltung gehen schon mit E3 (bzw. teils sogar ohne Zusatzkosten). E5 bringt „Luxus“-Features: tiefergehende Threat Detection, Automatisierung, Insider Risk, etc. Wenn Budget knapp ist: kombinieren – z.B. nur Admins/High-Risk-User mit E5 ausstatten. Aber MFA ist ein Muss, egal welche Lizenz. Meine Empfehlung: Erst die Pflicht (mit E3), dann die Kür (E5 gezielt dazunehmen).

2. Ist die Cloud (Microsoft 365) wirklich sicherer als unser früheres On-Premises?
Im Grundsatz ja, aber nur wenn man sie richtig konfiguriert. Microsoft steckt Milliarden in Security, viel mehr als ein Mittelständler on-prem stemmen kann. Datacenter sind hochsicher, Updates kommen ständig. ABER: Cloud heißt Shared Responsibility – Microsoft sichert die Plattform, Sie müssen Zugänge, Daten und Konfiguration sichern. „Per se sicher“ gibt’s nicht. Richtig angewandt, kann M365 aber sehr sicher sein, oft sicherer als 10 Jahre alter Firmenserver im Keller neben der Putzfrau 😉.

3. Reicht es nicht, einfach MFA zu aktivieren und fertig?
MFA ist der größte Schritt, aber leider nicht die einzige Baustelle. Angreifer finden immer Wege: Tokenklau, Insider, unsichere Geräte. MFA schützt Identität, ja – aber was, wenn der Nutzer MFA bestätigt und dann eine verseuchte Datei öffnet? Oder wenn ein Externer Daten abzieht? Daher: MFA ist Schritt 1 von 20 (siehe Top-Liste). Ohne MFA brauchen wir über den Rest nicht reden, aber nach MFA kommt noch Conditional Access, Defender, DLP… Die Security-Schichten sind wie ein Käse mit Löchern – je mehr Schichten, desto unwahrscheinlicher, dass ein Loch komplett durchgeht.

4. Wie gehen wir mit BYOD um? Müssen wir jetzt jedem ein Firmen-Gerät geben?
Nein, BYOD ist weiterhin möglich, aber mit Richtlinien. Dank Intune MAM können wir private Geräte auf App-Ebene absichern (Business-Daten in Outlook/Teams geschützt, Rest des Handys bleibt privat). Man muss klare Regeln kommunizieren: wer sein privates Gerät nutzt, stimmt dem App-Schutz zu. In vielen Fällen reicht das völlig. Bei PCs/Laptops ist BYOD kniffliger – da würde ich eher empfehlen, soweit machbar, Firmen-Laptops zu stellen oder nur über virtuelle Desktops zu arbeiten. Aber Smartphones/Tablets: kein Grund zur Panik, da haben wir Tools für, ohne allen einen zweiten Telefon zu kaufen.

5. Was tun, wenn doch mal ein Datenleck oder Hack passiert?
Dann heißt es: kühlen Kopf bewahren und dem Notfallplan folgen. Zuerst Schaden begrenzen (z.B. kompromittierten Account sperren, geteilten Link entziehen), dann Forensik (was ist passiert, Umfang?), dann Meldung an Betroffene/Behörden falls nötig, und Lessons Learned. Wichtig: Das Szenario vorher durchdenken! Ich frage Kunden: „Wenn morgen alle Exchange-Mails verschlüsselt wären – wissen Sie, was zu tun ist?“ Falls nein: dringend Notfallplan erstellen (siehe Notfallkarte). Und natürlich, viele der hier besprochenen Maßnahmen verhindern 90% der Vorfälle. Aber 100% Sicherheit gibt’s nicht – Vorbereitung ist alles.

6. Wer in unserem Unternehmen sollte sich federführend um M365-Sicherheit kümmern?
Idealerweise ein Team aus IT und Security-Funktion. Die IT-Administration (M365-Admins) muss technisch umsetzen und den Betrieb machen. Aber die Richtung geben sollte jemand mit Gesamtblick – CISO oder IT-Leiter in Abstimmung mit Datenschutz/Compliance. In KMUs ohne CISO übernimmt oft der IT-Leiter diese Rolle, oder ein externer Berater unterstützt als virtueller CISO. Wichtig ist: Verantwortung klar zuordnen (siehe RACI-Matrix). Und: die Geschäftsleitung muss dahinter stehen – Security als Chefsache, sonst läuft’s ins Leere.

7. Wie aufwändig ist es, all diese Sicherheitsmaßnahmen umzusetzen?
Ehrlich: Etwas Aufwand ist es schon, aber vieles geht schneller als man denkt. MFA einschalten – ein Tag Planung, Mail an Nutzer, fertig. Conditional Access – einige Tage für Policies testen & ausrollen. Intune – paar Wochen Pilot, dann Rollout per Auto-Enroll. Komplexer sind DLP/Klassifizierung, weil hier interne Abstimmungen nötig sind (das dauert manchmal länger, bis alle einig sind). Aber verglichen mit klassischen on-prem Projekten (Firewalls austauschen etc.) ist Cloud-Security oft agiler. Außerdem lässt sich iterative vorgehen (siehe Quick Wins in 30 Tagen). Und: Sie müssen es ja nicht allein machen – mit etwas externer Hilfe (hust, meine Wenigkeit) geht’s deutlich schneller, weil Best Practices übernommen werden können statt Trial & Error.

8. Welche Angriffe sehen Sie aktuell am häufigsten auf M365?
Phishing, Phishing, Phishing – in allen Varianten. Das bleibt die Nummer 1. Dann das Abgreifen von Session-Cookies via Malware, um MFA zu umgehen – hier ist guter Endpoint-Schutz wichtig. Oft beobachtet: Consent Phishing (böse Apps) – viele Admins sind erstaunt, dass User einfach Apps Rechte geben können. Und natürlich Brute Force/Spray auf schwache Accounts (daher MFA/PW-Policy). In letzter Zeit auch vermehrt „AiTM“ (Adversary-in-the-Middle): Hacker stellen einen Proxy zwischen User und Microsoft, klauen so Auth-Cookie trotz MFA – dagegen hilft MFA in Verbindung mit Conditional Access (z.B. CA-Token Bindings oder FIDO), Microsoft entwickelt da ständig weiter. Summa summarum: Menschlicher Faktor via Phishing bleibt Top, dicht gefolgt von Attacken auf Identitäten (darum die Betonung auf Identitätsschutz).

9. Schützt Defender for Office 365 uns vor Ransomware?
Es reduziert das Risiko stark, aber absolute Sicherheit gibt es nicht. Defender O365 mit Safe Attachments filtert viele böse Anhänge raus oder detoniert sie in Sandbox – das fängt die meisten Ransomware-Mails ab. Außerdem erkennt Defender for Endpoint typische Ransomware-Verhaltensweisen auf dem PC und kann eingreifen. Und OneDrive/SharePoint haben Versionierung, d.h. verschlüsselte Dateien kann man oft wiederherstellen. ABER: ein umsichtiges Backup-Konzept für essentielle Daten ist trotzdem ratsam. Und am wichtigsten: User-Schulung. Wenn ein Mitarbeiter eine merkwürdige EXE von einem USB-Stick startet, hilft Defender zwar oft, aber Verlassen würde ich mich nicht drauf. Also, ja, Defender bietet sehr guten Schutz – in Tests oft top – aber ich schlafe besser, wenn ich weiß, wir haben ein Offsite-Backup der kritischsten Daten, nur für den worst case.

10. Wie gestalten wir den Zugriff für externe Partner sicher?
Mit Augenmaß und Kontrolle: Geben Sie externen Partnern möglichst dedizierte Gastkonten in Ihrem Tenant, statt generische Logins zu teilen. So können Sie deren Aktivitäten tracken und im Zweifel den Zugang einzeln entziehen. Nutzen Sie Teams oder SharePoint für die Zusammenarbeit und legen Sie Daten dort ab, statt wild E-Mails zu schicken – so können DLP und Zugriffspolicies auch für Gäste greifen. Setzen Sie Conditional Access: z.B. Gastzugriff nur mit MFA (können Sie per Policy verlangen, auch Gäste müssen sich per MFA bei ihrem Heimatorganisation anmelden). Und regelmäßige Review der Gastbenutzer: wer braucht noch Zugriff, wer nicht mehr? Viele Firmen lassen Gäste jahrelang drin, die längst kein Projekt mehr haben – raus damit, schließt potentielle Lücken. Kurz: Externe ja, aber nach dem Prinzip “Trust but verify”: minimale benötigte Rechte, MFA erzwingen, Logging/Auditing, und klare Regeln (vielleicht NDA unterzeichnen lassen etc.).

11. Sollten wir unsere M365-Daten zusätzlich backupen, oder reicht Microsofts Sicherung?
Kommt drauf an, wie riskant Datenverlust für Sie wäre und wie komfortabel Sie Wiederherstellung wollen. Microsoft sorgt für Geo-Redundanz, Hardware-Ausfallsicherheit etc. – also so schnell verliert Microsoft Ihre Daten nicht. Und Versionierung/Recycle Bin fangen viel auf (SharePoint behält gelöschte Dateien 93 Tage, Mails 14 Tage in Deletions). ABER: Wenn z.B. jemand versehentlich viele Daten löscht und Sie merken es erst nach 4 Monaten, könnten die weg sein, weil Papiereimer leer. Oder bei Ransomware, die auch Versionen löscht (gibt Ansätze). Drittanbieter-Backups (Veeam, Veritas, etc.) geben extra Schutz: Sie könnten auch einzelne E-Mail oder ein ganzes Team sehr bequem zurückspielen, selbst wenn der User es gelöscht hat. Viele meiner Kunden machen Backups zumindest von kritischen SharePoint-Sites und Mailboxen – belt and suspenders. Ist es ein Muss? Nicht zwingend, wenn Sie Microsofts built-in Retention und Recycling klug nutzen. Aber es ist eine Abwägung: Business Continuity vs. Kosten. Ich sage: Für „Lebenswichtige“ Daten (z.B. Finanzarchive) lohnt ein Backup. Für das normale Team-Sharepoint eher selten nötig, wenn Retention gut eingestellt und Nutzer wissen, was sie tun.

12. Was, wenn ein Admin-Konto gehackt wird?
Dann haben wir ein echt ernstes Problem, deshalb vorbeugen! PIM und strikte Admin-Trennung sorgen dafür, dass eigentlich kein Admin dauerhaft alle Rechte hat – das minimiert die Wahrscheinlichkeit. Sollte dennoch eins kompromittiert werden (z.B. Admin nutzt dasselbe Passwort woanders und es wird geleakt), dann: sofortiger Notfallmodus – Break-Glass-Admin nimmt alle Rollen weg, setzt kompromittierten Admin auf Block Sign-In, überprüft Logs, was der Angreifer getan haben könnte (Backdoor-Accounts angelegt? Mail-Transport-Regeln verändert? App-Consent erteilt?). Dann alle Betroffenen Stellen informieren. Man muss hier fast von einem vollständigen Tenant-Compromise ausgehen und alles prüfen. Der Schaden kann immens sein. Deshalb in der Notfallkarte ein eigenes Kapitel „Admin Compromise“. Und ideal: nichts passiert ohne 2 Admins – z.B. GA via PIM + Approval, so dass ein einzelner kompromittierter Admin nicht ungehindert Unfug treiben kann. Außerdem: MFA für Admins mit FIDO2 oder separate Geräte, damit Kompromittierung unwahrscheinlicher ist als bei Standardusern.

13. Wie passt das Konzept „Zero Trust“ zu unserem M365-Sicherheitsansatz?
Sehr gut, denn vieles, was wir tun, ist Zero Trust in Aktion. Zero Trust Prinzipien: Verifiziere jeden Zugriff, minimaler Zugriff nur, und durchgängige Überwachung. M365 implementiert das mit Conditional Access (jeder Login kontextgeprüft), MFA (starke Verifizierung), PIM (keine Dauerberechtigungen), Microsegmentierung z.B. via Sensitivity Labels/SharePoint (nicht jeder auf alles), und Telemetrie durch Defender/MCAS (Überwachung). Also wenn Sie all die Empfehlungen hier umsetzen, leben Sie praktisch Zero Trust im Cloud-Umfeld. Wichtig ist Zero Trust ist ein Modell, kein Produkt: Es erfordert auch Mindset-Change. Beispiel: Früher VPN ins Firmennetz = „drin und frei beweglich“. Heute Zero Trust: Auch innerhalb (oder via VPN) werden Zugriffe geprüft und nicht automatisch vertraut. Microsoft 365 + Entra ID sind technisch gut aufgestellt für Zero Trust, aber man muss das Konzept in den Policies konsequent anwenden. Anmerkung: Zero Trust heißt nicht „Trust nobody“ im Sinne Paranoia, sondern „kontinuierliche Überprüfung“. Microsoft nennt Azure AD Conditional Access auch die „Zero Trust Policy Engine“. Also ja, wir bauen hier genau darauf auf.

14. Welche Rolle spielt Microsoft Secure Score?
Secure Score ist ein nützliches Hilfsmittel, aber kein Zertifikat. Es liefert einen Wert (0–100%) basierend darauf, wie viele empfohlene Aktionen Sie umgesetzt haben. Steht da 30%, heißt es: da ist noch viel offen. 80% heißt: Schon vieles gemacht, nur noch teils Feintuning. Ich nutze es gern als Conversational Starter und Prioritätsliste. Aber man sollte Score nicht blind nachjagen – manche Aktionen passen evtl. nicht zur Umgebung. Beispiel: Score sagt „Block legacy auth“ – absolut tun, Wertvoll. Score sagt aber auch „Kennwortlose Auth aktivieren“ – super Sache, aber wenn Ihre User noch nicht bereit sind, nicht sofort verkrampfen, das kommt später. Und Score bewertet nur Microsoft-empfohlene Dinge – risikospezifische Sachen (wie „schule Benutzer“ oder „reduziere Gastaccounts“) sind da nicht direkt drin. Also: Nutzen Sie es wie einen Check-up beim Arzt, aber entscheiden Sie mit gesundem Menschenverstand, was wirklich wichtig ist. Und ja, manche Chefs wollen den Score hoch sehen („bei uns muss Ampel grün sein!“) – dann kann man das natürlich als Ziel heranziehen. Schaden tut es nicht, aber Inhalt vor Zahl.

15. Können Sie uns auch langfristig unterstützen, ohne dass wir gleich einen Managed Service Vertrag brauchen?
Aber sicher doch! Genau das ist mein Ansatz. Ich biete flexibles Coaching und Health-Check Services an. Das heißt, z.B. quartalsweise komme ich für einen Tag vorbei (oder remote) und wir schauen gemeinsam Ihre Umgebung durch: neue Risiken, neue Features die man nutzen könnte, kleine Adjustments. Oder ich stehe als Ansprechpartner zur Verfügung, wenn Sie bei einem Incident eine Zweitmeinung wollen. Alles nach Bedarf, auf Tagessatz-Basis, kein „12-Monats-Abo mit Knebelvertrag“. Viele Kunden schätzen das: Sie behalten die Verantwortung und Tagesgeschäft inhouse, haben aber einen erfahrenen Experten, den Sie punktuell hinzuziehen können – gewissermaßen ein Mentor oder externer Sicherheitsbeauftragter „light“. Und sollte doch mal ein großes Projekt anstehen (Migration, M&A Integration etc.), kennen wir uns schon und ich kann einspringen. Also ja: langfristige Partnerschaft gern, aber immer flexibel und kundengesteuert, nicht als Outsourcing-Gebilde.

Fazit und nächste Schritte

Die Sicherheit in Microsoft 365 ist kein Selbstläufer – aber mit den richtigen Maßnahmen und etwas Ausdauer lässt sich ein hohes Schutzniveau erreichen, ohne die Vorteile der Cloud einzubüßen. Ich hoffe, dieser praxisorientierte Leitfaden hat Ihnen gezeigt, worauf es ankommt und wie Sie strukturiert vorgehen können. Zum Abschluss möchte ich drei konkrete nächste Schritte empfehlen, wie Sie ins Tun kommen:

Schritt 1: Standortbestimmung durchführen – Verschaffen Sie sich als erstes einen klaren Überblick: Wo stehen wir aktuell bei M365-Security? Nutzen Sie dazu gern die Top-20-Maßnahmen-Checkliste aus Abschnitt 11.1. Markieren Sie, was schon umgesetzt ist und was offen ist. Prüfen Sie Secure Score und aktuelle Config. Das Ergebnis sollte intern vorgestellt werden („das sind unsere Lücken/Risiken“), um Bewusstsein zu schaffen. Wenn Ihnen die interne Expertise oder Zeit fehlt: ziehen Sie jemanden hinzu (z.B. im Rahmen eines Starter-Pakets übernehme ich diese Standortbestimmung schnell und fundiert).

Schritt 2: Quick Wins sofort anpacken – Identifizieren Sie die dringendsten Lücken und beheben Sie diese kurzfristig. Aus Erfahrung: MFA ausrollen, Admin-Konten sichern, Baseline Conditional Access sind praktisch immer ganz oben. Setzen Sie sich eine 30-Tage-Frist, um die Top-5 Quick Wins umzusetzen. Holen Sie das Management-Backing dafür ein („können kurz mal Störungen geben, aber das ist wichtig“). Durch die schnellen Verbesserungen senken Sie sofort das Risiko erheblich – das gibt Ihnen Luft für die größeren Brocken.

Schritt 3: Langfristige Roadmap und Verantwortlichkeiten festzurren – Parallel zu den Quick Wins sollte eine kleine Task Force (IT + Security + evtl. Compliance) die Roadmap für die nächsten 6–12 Monate erarbeiten. Orientieren Sie sich an Kapitel 9 (0–180 Tage). Legen Sie fest, wer welche Teilprojekte leitet (z.B. „Intune-Rollout – Admin X“, „DLP & Labels – Compliance Officer Y mit IT-Unterstützung“). Verankern Sie das Thema in der Organisationsstruktur: z.B. regelmäßiges Meeting, Bericht an CIO. Planen Sie auch Schulungen und Change Management mit ein. Die Roadmap muss ambitioniert, aber realistisch sein – lieber kleine Schritte als Perfektion nie erreichen. Und vergessen Sie nicht Meilensteine zu feiern („100% MFA erreicht – super, Lunch für’s Team!“).

Erinnerung: Sie sind nicht allein auf diesem Weg. Als Berater mit 25+ Jahren Erfahrung in Microsoft-Technologien biete ich Ihnen gerne meine persönliche Unterstützung an – sei es in Form eines Workshops, konkreter Umsetzungshilfe oder strategischem Coaching. Alle Leistungen erfolgen durch mich selbst, zu meinem transparenten Tagessatz von 1.500 € (zzgl. MwSt., Reisekosten). Keine Blackbox, keine lange Bindung – Sie bekommen exakt die Expertise, die Sie benötigen. Mein Ziel ist es, dass Sie danach selbstständig und sicher weiterarbeiten können, wohlwissend, dass Sie bei Bedarf jederzeit einen Sparringspartner anrufen können.

Ihr Vorteil: Mit meiner Hilfe vermeiden Sie viele der typischen Stolpersteine, sparen Zeit und Nerven und kommen schneller zum Ziel – einer sicheren, gut gemanagten Microsoft 365-Umgebung, die Ihr Business schützt, ohne es auszubremsen.

Packen wir’s an – die Cloud gehört gesichert! Wenn Sie bis hier gelesen haben, haben Sie offensichtlich den Willen dazu. Also, worauf warten? Legen Sie los mit den ersten Schritten und melden Sie sich gern bei mir, wenn Sie auf dem Weg einen erfahrenen Begleiter wollen. Gemeinsam machen wir Ihre M365-Umgebung zum Fort Knox – natürlich ohne den Benutzerkomfort zu opfern. In diesem Sinne: Bleiben Sie sicher, aber bleiben Sie auch pragmatisch.

Vielen Dank fürs Lesen – und viel Erfolg bei der Umsetzung!

 

Weitere Beiträge zum Thema Security und Compliance