Stellen Sie sich vor, Sie starten Ihren Arbeitstag und nichts geht mehr. Kein Outlook, kein Teams, nicht einmal der Zugriff auf lokale Dateien ist möglich, weil das Betriebssystem in einer Endlosschleife mit der Cloud hängt. Was wie ein Weltuntergangsszenario für IT-Administratoren klingt, wurde im Januar 2026 bittere Realität. Der jüngste Microsoft Cloud-Ausfall hat einmal mehr bewiesen, dass die totale Abhängigkeit von einem einzigen Anbieter ein unkalkulierbares Risiko darstellt.

In diesem Artikel analysieren wir die technischen Ursachen des „Januar-Kollapses“, beleuchten, warum die Cloud eben nicht automatisch Ausfallsicherheit bedeutet, und warum die EU dringend handeln muss, um Microsoft im Rahmen von NIS-2 und KRITIS stärker in die Pflicht zu nehmen.

1. Die Chronologie des Versagens: Januar 2026

Der Ausfall kam nicht aus dem Nichts. Er war das Ergebnis einer fatalen Verkettung von fehlerhafter Software und einer überforderten Cloud-Infrastruktur.

Der Patch-Tuesday als Initialzündung

Alles begann am 13. Januar 2026. Microsoft veröffentlichte das Sicherheitsupdate KB5074109. Eigentlich sollten damit 110 Sicherheitslücken geschlossen werden. Doch stattdessen löste das Update weltweit Chaos aus. Systeme froren ein („Black Screens“), sobald sie versuchten, auf Cloud-Ressourcen zuzugreifen. Besonders hart traf es Outlook-Nutzer: Wer PST-Dateien auf OneDrive gespeichert hatte, erlebte einen kompletten Stillstand der Anwendung.

Die Eskalation in der Cloud

Am 21. und 22. Januar weitete sich das Problem auf die Azure-Infrastruktur aus. In Nordamerika fielen Microsoft 365-Dienste flächendeckend aus. Der Versuch von Microsoft, den Traffic mittels Load Balancern umzuverteilen, scheiterte grandios und führte zu massiven „Traffic Imbalances“, die weitere Rechenzentren in die Knie zwangen.

2. Technische Analyse: Was ist bei Microsoft falsch gelaufen?

Als Experten müssen wir tief graben, um zu verstehen, warum ein einzelnes Update eine solche Kaskade auslösen kann.

Mangelhafte Qualitätssicherung (QA)

Es ist offensichtlich, dass das Update KB5074109 nicht in ausreichenden Enterprise-Szenarien getestet wurde. Dass grundlegende Funktionen wie die Authentifizierung bei Azure Virtual Desktop (Fehler 0x80080005) versagen, deutet auf eine lückenhafte Test-Matrix hin. Microsoft scheint hier die Geschwindigkeit der Veröffentlichung über die Stabilität zu stellen.

Die „Cloud-Sperre“ (Synchronisations-Hänger)

Ein fundamentales Problem liegt in der Architektur von Windows selbst. Die enge Verzahnung von lokalen Prozessen mit Cloud-Diensten wie OneDrive führte dazu, dass lokale Programme blockierten, sobald die Cloud-Synchronisation hängen blieb. Dies entlarvt die gefährliche Abhängigkeit: Wenn die Cloud nicht erreichbar ist, streikt die lokale Hardware.

Komplexität frisst Resilienz

Die Infrastruktur-Ausfälle vom 22. Januar zeigten ein „komplexes Systemversagen“. Die Korrekturmaßnahme – das Umleiten des Datenverkehrs – wurde selbst zum Fehlervektor. In einer Welt, in der alles mit allem vernetzt ist, führen kleine Fehler oft zu unkontrollierbaren Kettenreaktionen.

3. Die Cloud-Falle: Illusion vs. Realität

Unternehmen lassen sich oft von Marketing-Versprechen blenden. Doch die Realität sieht anders aus.

Die Illusion der Ausfallsicherheit

Microsoft wirbt oft mit 99,9 % Verfügbarkeit. Doch diese Statistik ist wertlos, wenn Ihr lokales System den Zugang zur Cloud verliert. Cloud-Sicherheit und Verfügbarkeit sind zwei verschiedene Paar Schuhe. Ein Cloud-Ausfall bei einem Monopolisten wie Microsoft bedeutet für Millionen von Unternehmen den sofortigen Stillstand.

Single Point of Failure: Das Monopol-Problem

Da Microsoft das Betriebssystem, die Bürosoftware, das Identitätsmanagement (Entra ID) und den Speicherplatz aus einer Hand liefert, gibt es keine Redundanz. Fällt ein Dominosteinchen bei Microsoft, fällt die gesamte IT-Infrastruktur des Kunden. Diese Konzentration von Macht und Risiko ist ein strategischer Fehler für jede moderne Volkswirtschaft.

4. Politische Forderung: NIS-2 und KRITIS für Microsoft

Es kann nicht sein, dass kritische Infrastrukturen (KRITIS) in Europa stillstehen, weil ein US-Konzern seine Hausaufgaben bei der Qualitätssicherung nicht macht.

Verbindliche Standards durch die EU

Die EU muss Microsoft und andere Hyperscaler zwingen, die strengen Anforderungen der NIS-2-Richtlinie vollumfänglich zu erfüllen. Wenn Microsoft-Dienste für staatliche Stellen oder Krankenhäuser essenziell sind, müssen sie wie kritische Infrastrukturen behandelt werden. Das bedeutet:

• Nachweisbare Redundanz: Ausfälle in einem Rechenzentrum dürfen nicht globalen Stillstand bedeuten.
• Haftung bei Fahrlässigkeit: Wenn mangelhafte QA zu Milliardenverlusten führt, muss der Anbieter zur Rechenschaft gezogen werden.
• Interoperabilität: Kunden müssen in der Lage sein, Dienste kurzfristig zu anderen Anbietern umzuziehen (Multi-Cloud-Strategie).

5. Strategien für Unternehmen: So schützen Sie sich

Was können Sie als IT-Entscheider tun, um nicht das nächste Opfer eines Cloud-Kollapses zu werden?

1. Diversifikation statt Monokultur: Setzen Sie nicht auf „Alles von Microsoft“. Nutzen Sie alternative Anbieter für Backup, Sicherheit oder E-Mail-Archivierung.
2. Offline-Fähigkeit sicherstellen: Prüfen Sie, ob Ihre kritischen Geschäftsprozesse auch ohne Internetverbindung für mindestens 24 Stunden funktionieren.
3. Update-Management überdenken: Implementieren Sie eine „N-1“-Strategie. Installieren Sie neue Microsoft-Patches erst, nachdem sie in einer Testumgebung geprüft wurden und keine globalen Probleme gemeldet wurden.
4. Multi-Cloud-Ansatz: Verteilen Sie kritische Workloads auf verschiedene Cloud-Anbieter (z.B. Azure und AWS oder lokale europäische Anbieter).

Fazit: Zeit für ein Umdenken

Der Microsoft Cloud-Ausfall vom Januar 2026 war ein Weckruf. Cloud ist nicht gleich Sicherheit. Cloud ist nicht gleich Redundanz. Es ist eine Dienstleistung, die mit erheblichen Abhängigkeiten erkauft wird. Wir brauchen in Europa eine Rückbesinnung auf digitale Souveränität und echte Redundanz.

Es ist Zeit, dass die Politik handelt und Konzerne wie Microsoft zu echter Rechenschaft zwingt. Für Unternehmen gilt: Wer sich blind auf die Cloud verlässt, verlässt sich auf das Glück – und das ist in der IT keine seriöse Strategie.

Der Beitrag Microsoft Cloud-Ausfall: Warum die Cloud zur Gefahr wird erschien zuerst auf Grams IT - Blog.

Quelle: datenschutz.hessen.de

Einleitung: Das Ende der Rechtsunsicherheit – Microsoft 365 in der Kommune

Microsoft 365 ist längst mehr als nur eine Bürosoftware; es ist das zentrale Nervensystem moderner digitaler Verwaltung. Dennoch hängt über seiner Nutzung in deutschen Kommunen weiterhin die Wolke der Rechtsunsicherheit. Die digitale Transformation im öffentlichen Sektor ist auf effiziente, vernetzte Lösungen angewiesen, doch die strikten Vorgaben der Datenschutz-Grundverordnung (DSGVO) und die komplexen Implikationen des Schrems II-Urteils bremsen den Fortschritt massiv aus. Insbesondere die Frage, wie ein US-amerikanischer Cloud-Anbieter datenschutzkonform als Auftragsverarbeiter (AV) fungieren kann, beschäftigt juristische Abteilungen und IT-Leiter gleichermaßen.

Mit der Veröffentlichung des wegweisenden Berichts des Hessischen Beauftragten für Datenschutz und Informationsfreiheit (HBDI) vom 15. November 2025 – einer Blaupause für die gesamte Öffentliche Verwaltung Cloud-Nutzung – ist nun endlich ein klarer Fahrplan vorgegeben. Dieser umfassende Leitfaden basiert auf der detaillierten Analyse des HBDI-Berichts und bietet Ihnen, den Verantwortlichen in Kommunen, die konkrete Schritt-für-Schritt-Anleitung, wie Sie Microsoft 365 rechtssicher einführen und betreiben können. Wir tauchen tief in die Materie ein, von den obligatorischen Technischen und Organisatorischen Maßnahmen (TOMs) über die Herausforderung der Telemetriedaten Microsoft bis hin zur korrekten Umsetzung der Standardvertragsklauseln M365. Nutzen Sie diese Expertise, um Ihre Verwaltung zukunftssicher und M365 datenschutzkonform zu gestalten.

1. Die Quintessenz des HBDI-Berichts (15.11.2025): Neue Mindestanforderungen

Der von vielen Stellen lange erwartete Bericht des HBDI schafft Klarheit und definiert Sieben Mindestanforderungen, ohne deren konsequente Umsetzung eine datenschutzkonforme Nutzung von Microsoft 365 in der Öffentlichen Verwaltung Cloud nicht mehr statthaft ist. Der Bericht erkennt den Mehrwert der Plattform an, stellt aber unmissverständlich fest: Der bloße Abschluss des Auftragsverarbeitungsvertrages (AVV) und der Standardvertragsklauseln (SCCs) reicht alleine nicht mehr aus. Die juristische Hürde des US Cloud Act muss durch verstärkte TOMs aufseiten der Kommune überwunden werden.

1.1 Das Drei-Säulen-Modell der Compliance

Der HBDI-Bericht baut seine Analyse auf drei fundamentalen Säulen auf, die in ihrer Gesamtheit die Risiken der Datenübermittlung in die USA minimieren sollen:

1. Rechtliche Fundierung (Säule I): Die korrekte Kaskadierung von AVV und den neuen SCCs als zwingende Basis, ergänzt durch spezifische vertragliche Zusätze zur Informationspflicht.
2. Technische Risiko-Minimierung (Säule II): Die Implementierung von Ende-zu-Ende-Verschlüsselung (E2EE) für bestimmte Datenkategorien und die vollständige Kontrolle über Telemetriedaten.
3. Organisatorische Verantwortung (Säule III): Die lückenlose Datenschutzfolgeabschätzung (DSFA) und die permanente Schulung der Mitarbeiter bezüglich sensibler Daten.

Der Bericht weist Kommunen die alleinige Verantwortung für die Einhaltung der DSGVO zu. Microsoft ist zwar Auftragsverarbeiter, doch die Entscheidung und die Haftung für die Angemessenheit der getroffenen Maßnahmen obliegt der verantwortlichen Stelle, sprich, der Kommune.

1.2 Die zentralen, juristischen HBDI-Forderungen

Die strengste Anforderung des HBDI zielt auf die Minimierung des Zugriffsrisikos durch US-Behörden (im Sinne von Schrems II) ab.

A. Nachweis der effektiven SCC-Zusatzmaßnahmen (Artikel 46 DSGVO)

Kommunen müssen nun aktiv nachweisen, dass die vertraglich vereinbarten Standardvertragsklauseln M365 durch zusätzliche, wirksame Maßnahmen ergänzt werden. Der HBDI fordert eine detaillierte Dokumentation, die über eine einfache Checkliste hinausgeht.

Verbindliche Elemente der Nachweisdokumentation:

• Risikoanalyse des Drittlandtransfers (TTA): Eine spezifische Analyse, welche Datenkategorien (z.B. Sozialdaten, Personaldaten) in welche M365-Dienste übertragen werden, und eine Bewertung des Zugriffsrisikos durch US-Behörden für jeden Dienst (Exchange Online, SharePoint Online, Teams).
• Definition der „Red-Line“-Daten: Eindeutige Festlegung, welche Daten (z.B. Kommunalwahlen, Bauakten) unter keinen Umständen unverschlüsselt in die Cloud gelangen dürfen. Für diese Daten gilt ein absolutes E2EE-Gebot.
• Vertragliche Zusicherung der Transparenz: Die Kommune muss von Microsoft vertraglich die Zusage einfordern, über jegliche Anfragen von US-Behörden unverzüglich und vollumfänglich informiert zu werden, selbst wenn dies – theoretisch – gegen US-Recht verstoßen könnte (sog. „Transparency-Klausel“).

B. Klarstellung zur Datenverantwortung

Der Bericht betont, dass die Kommune nicht nur für die Auftragsverarbeitung Microsoft 365 verantwortlich ist, sondern auch klar definieren muss, wann sie (hypothetisch) mit Microsoft als gemeinsam Verantwortlicher handelt. Dies betrifft insbesondere die Konfiguration der Dienste und die Nutzung von Features, die über die reine Verarbeitung von Weisungsdaten hinausgehen (z.B. Cortana-Funktionen, bestimmte AI-Assistenten). Der HBDI fordert, dass diese Grenzziehung in der DSFA detailliert und nachvollziehbar dargelegt wird.

2. Telemetrie und Diagnosedaten: Die Achillesferse entschärfen

Der HBDI-Bericht identifiziert die Erfassung und Übermittlung von Telemetriedaten Microsoft – also Daten über die Nutzung und den Zustand der Software – als den kritischsten und oft unterschätzten datenschutzrechtlichen Knackpunkt. Diese Daten sind essenziell für Microsoft zur Wartung und Verbesserung des Dienstes, können aber auch Rückschlüsse auf individuelle Nutzungsmuster, IP-Adressen, Gerätekennungen und unter Umständen sogar auf in den Dateinamen enthaltene personenbezogene Informationen zulassen.

2.1 HBDI-Diktat: Volle Kontrolle über Telemetriedaten

Der Bericht legt fest, dass Kommunen die Kontrolle über diese Daten vollständig übernehmen müssen. Es wird eine Zero-Trust-Policy für die automatische Übermittlung von Diagnosedaten gefordert, es sei denn, die Übermittlung ist technisch zwingend für die Funktion des Dienstes erforderlich und kann nicht vermieden werden.

Konkrete Konfigurationsvorgaben im Detail

Der HBDI unterscheidet zwischen drei Kategorien von Telemetriedaten und legt für jede klare Anforderungen fest:

Die Pflicht zur Netzwerkanalyse

Als neue, verschärfte TOM verlangt der HBDI von Kommunen, vor der Produktivsetzung eine detaillierte Netzwerkanalyse durchzuführen. Dabei muss protokolliert werden, welche Endpunkte (URLs, IP-Adressen) von den M365-Clients im „Required“-Modus kontaktiert werden und welche Datenpakete dabei gesendet werden.

• Ziel: Die Kommune muss sich vergewissern, dass Microsoft die vertraglichen Zusicherungen zur Telemetrie-Begrenzung auch technisch einhält.
• Ergebnis: Die Analyse muss Bestandteil der DSFA sein. Nur wenn die Datenübermittlung auf das absolute Minimum beschränkt ist, ist die Nutzung zulässig.

2.2 Microsoft Purview als Kontrollzentrum

Der HBDI-Bericht hebt die Notwendigkeit hervor, die bereitgestellten Tools zur Kontrolle der Datenflüsse konsequent zu nutzen. Microsoft Purview (ehemals Compliance Center) wird dabei zum zentralen Kontrollzentrum der Kommune.

Vier kritische Purview-Funktionen:

1. Audit-Logging: Aktivierung der erweiterten Überwachung (Advanced Auditing) und die mindestens 5-jährige Speicherung der Protokolle. Dies dient dem Nachweis im Falle einer Datenpanne und der Einhaltung der kommunalen Aufbewahrungspflichten.
2. eDiscovery: Die Fähigkeit, auf Basis des HBDI-Berichts schnell und präzise auf etwaige Anfragen von US-Behörden reagieren zu können (sog. „Red-Button-Fähigkeit“). Die Kommune muss nachweisen, dass sie innerhalb kürzester Zeit (z.B. 48 Stunden) alle betroffenen Daten identifizieren und den Zugriff sperren könnte.
3. Data Loss Prevention (DLP): Zwingende Implementierung von DLP-Regeln, die das unautorisierte Teilen und Speichern von Sozialdaten und Kommunalgeheimnissen in unverschlüsselten M365-Diensten (z.B. OneDrive-Ordner ohne E2EE) unterbinden.
4. Information Protection (Sensitivity Labels): Klassifizierung aller Daten mit Sensitivity Labels. Diese Labels (z.B. „VS-NUR FÜR DIENSTLICHEN GEBRAUCH“, „PERSONENBEZOGEN – KLARNAME“) müssen die technische E2EE-Verschlüsselung bei der Speicherung in der Cloud erzwingen. Dies ist die wichtigste TOM zur Überwindung der Schrems II Microsoft 365 Problematik.

3. Die rechtliche Gratwanderung: Auftragsverarbeitung und Schrems II

Die zweite juristische Säule der HBDI-Analyse dreht sich um die rechtskonforme Ausgestaltung des Verhältnisses zwischen der Kommune (Verantwortlicher) und Microsoft (Auftragsverarbeiter) unter Berücksichtigung der Drittlandtransfers gemäß Schrems II (EuGH C-311/18).

3.1 Das Dilemma der US-Cloud-Anbieter

Der HBDI-Bericht bekräftigt, dass die US-Gesetze, insbesondere der Cloud Act und die FISA 702, weiterhin ein fundamentales Problem darstellen, da sie US-Behörden unter bestimmten Umständen den Zugriff auf Daten ohne Kenntnis des europäischen Verantwortlichen ermöglichen. Die einfache Nutzung von Rechenzentren in der EU (z.B. Deutschland oder den Niederlanden) ist nicht ausreichend, da Microsoft als US-Unternehmen diesen Gesetzen unterliegt.

A. Die Rolle der Standardvertragsklauseln

Die Standardvertragsklauseln M365 (neue SCCs) dienen als Ersatz für ein Angemessenheitsniveau und sind die Grundlage für den Datentransfer. Der HBDI fordert, dass die Kommune nicht nur die SCCs unterzeichnet, sondern auch eine lückenlose Wirksamkeitsprüfung vornimmt.

Drei Punkte zur Wirksamkeitsprüfung (TTA – Transfer Impact Assessment):

1. Rechtsvergleich: Detaillierte Prüfung, ob das Schutzniveau der SCCs durch das Recht des Drittlandes (USA) untergraben wird. Der HBDI liefert hierfür eine Muster-Rechtsvergleichsanalyse, die die Kommune nur noch unterschreiben und in ihre DSFA integrieren muss.
2. Technische Maßnahmen als Ultima Ratio: Die technische E2EE-Verschlüsselung wird zur zwingenden Zusatzmaßnahme. Die Kommunen müssen festlegen, dass für alle Daten, deren Offenlegung bei einem Zugriff von US-Behörden einen „hohen oder sehr hohen Schaden“ für die Betroffenen (Bürger, Mitarbeiter) verursachen würde, eine E2EE implementiert sein muss.
3. Häufigkeit der Überprüfung: Die gesamte TTA und die damit verbundenen technischen TOMs müssen mindestens jährlich überprüft und vom Datenschutzbeauftragten (DSB) der Kommune freigezeichnet werden.

B. Klarstellung zur Datenresidenz und Pseudonymisierung

Der HBDI-Bericht stellt klar, dass Datenresidenz in der EU zwar erwünscht, aber kein Allheilmittel ist. Die datenschutzrechtliche Verantwortung bleibt beim Verantwortlichen.

• Geografische Einschränkung: Die Kommune muss die Speicherung der Kundendaten (Core Customer Data) vertraglich auf die EU begrenzen. Dies geschieht über die Konfigurationsoptionen im M365 Admin Center.
• Pseudonymisierung: Für alle nicht E2EE-geschützten Metadaten und Telemetriedaten, die zwangsläufig an Microsoft übermittelt werden, muss die Kommune die Pseudonymisierungsfunktionen der Clients nutzen, um eine direkte Identifizierbarkeit zu verhindern. Hierzu zählt die Nutzung von Nutzer-IDs anstelle von Klarnamen in den Logfiles.

3.2 Die perfekte Auftragsverarbeitung

Der Auftragsverarbeitungsvertrag zwischen Kommune und Microsoft muss die im HBDI-Bericht geforderten Spezifikationen enthalten, die über die Standardklauseln hinausgehen.

Mindestens drei zwingende, neue vertragliche Zusätze:

1. Reaktionskette im Notfall: Detaillierte Regelung, wie Microsoft die Kommune im Falle einer Datenzugriffsanfrage von US-Behörden unmittelbar informiert und welche rechtlichen Schritte Microsoft in Absprache mit der Kommune einleitet (z.B. Einspruch gegen die Herausgabepflicht).
2. Audit-Recht: Der Kommune muss explizit das Recht eingeräumt werden, eigene unabhängige Audits der technischen und organisatorischen Umgebung bei Microsoft durchzuführen (Audit-Recht). Dies dient der kontinuierlichen Überprüfung der vertraglichen Zusicherungen (Art. 28 Abs. 3 lit. h DSGVO).
3. Kündigungsrecht bei Rechtsänderung: Ein Sonderkündigungsrecht muss vereinbart werden, das die Kommune zur sofortigen Kündigung ermächtigt, falls sich die US-Gesetzeslage (z.B. Verschärfung des Cloud Act) so ändert, dass die Einhaltung der DSGVO-Grundsätze unmöglich wird.

4. Technische und Organisatorische Maßnahmen (TOMs) als Schlüssel zur Compliance

Der HBDI-Bericht widmet den Technischen und Organisatorischen Maßnahmen (TOMs) das größte Kapitel und macht deutlich, dass nur eine perfekt konfigurierte M365-Umgebung als M365 datenschutzkonform gelten kann. Die Kommunen müssen hierfür einen erheblichen Aufwand betreiben.

4.1 Die Pflicht zur Ende-zu-Ende-Verschlüsselung (E2EE)

Die E2EE ist das zentrale TOM zur Überwindung der Schrems II Microsoft 365 Problematik. Der HBDI-Bericht definiert klar, wann E2EE zwingend erforderlich ist:

• Kategorie A (Zwingendes E2EE):
  • Sozialdaten: Alle Daten aus Sozialämtern, Jugendämtern, etc.
  • Besondere Kategorien personenbezogener Daten (Art. 9 DSGVO): Gesundheitsdaten (Amtsarzt), politische Meinungen (Wahlämter), religiöse Zugehörigkeit.
  • Kommunal- und Staatsgeheimnisse: Hochsensible Akten (z.B. Vergabeunterlagen, innere Sicherheit der Kommune).

Umsetzung der E2EE-Anforderung

Kommunen müssen hierfür eine Kombination aus bordeigenen M365-Features und Drittanbieterlösungen nutzen:

• Double Key Encryption (DKE): Dies wird vom HBDI für die Kategorie A Daten empfohlen. DKE ermöglicht der Kommune, einen eigenen Schlüssel (Key 1) zu halten, während Microsoft nur den zweiten Schlüssel (Key 2) verwaltet. Nur die Kommune kann die Daten entschlüsseln, was einen Zugriff durch US-Behörden – selbst mit einer richterlichen Anordnung gegen Microsoft – technisch unmöglich macht. Die Nutzung von DKE erfordert eine spezifische Lizenzierung (z.B. E5 Compliance).
• Sensitivity Labels: Verwendung von Microsoft Information Protection (MIP). Die Labels müssen so konfiguriert werden, dass sie die DKE-Verschlüsselung automatisch erzwingen, sobald ein Dokument mit einem Kategorie-A-Label versehen wird.

4.2 Der Schutz der Identitäten: Authentifizierung und Zugriffsmanagement

Der HBDI-Bericht macht eine starke Identitäts- und Zugriffsverwaltung zur zwingenden Voraussetzung für eine datenschutzkonforme Nutzung.

A. Multi-Faktor-Authentifizierung (MFA) – Ohne Ausnahme

Die Multi-Faktor-Authentifizierung für alle Benutzer, insbesondere aber für Administratoren, ist obligatorisch. Der Bericht fordert:

• MFA für alle: Ausnahmslos jeder M365-Nutzer in der Kommune muss MFA nutzen.
• FIDO2-Keys/Smartcards: Für Administratoren und Nutzer, die mit Kategorie A-Daten arbeiten, wird die Nutzung von Hardware-Tokens (FIDO2) anstelle von SMS- oder App-basierten MFA-Methoden dringend empfohlen, da diese resistenter gegen Phishing sind.

B. Conditional Access Policies

Mittels Azure AD Conditional Access muss die Kommune sicherstellen, dass der Zugriff auf M365-Dienste nur unter Einhaltung strenger Bedingungen erfolgt:

1. Trusted Devices: Zugriff nur von Geräten, die von der Kommune verwaltet und als sicher eingestuft sind (z.B. über Intune registrierte und gehärtete Endgeräte).
2. Geographic Restrictions: Sperrung des Zugriffs aus bestimmten Ländern (z.B. allen Ländern außerhalb der EU) als zusätzliche Hürde gegen externe Angriffe.
3. Risk-Based Access: Nutzung von Azure AD Identity Protection zur automatischen Sperrung von Konten mit ungewöhnlichem Anmeldeverhalten (z.B. Anmeldung aus Fuldabrück und fünf Minuten später aus Shanghai).

4.3 Die Härtung des Mandanten

Der HBDI-Bericht fordert die Kommunen zur konsequenten Aushärtung (Hardening) des M365-Mandanten auf. Dies bedeutet, alle Standardeinstellungen zu ändern, die datenschutzrechtlich problematisch sind.

Fünf obligatorische Härtungs-Maßnahmen:

• SharePoint/OneDrive Default Sharing: Die Standard-Freigabeeinstellungen müssen von „Jeder mit dem Link“ auf „Nur spezifische Personen“ umgestellt werden. Externe Freigaben sind auf Gastkonten mit MFA zu beschränken.
• Deaktivierung problematischer Features: Alle Features, die eine unkontrollierte Datenübermittlung in Drittländer auslösen können, sind zu deaktivieren. Dies umfasst (je nach Lizenz): Cortana-Integration, die automatische Indexierung von Dokumenten durch bestimmte AI-Dienste, und die Deaktivierung des „Fast-Search“ Index für sensible Bibliotheken.
• Logging und Auditing: Ununterbrochene Aktivierung des Audit-Logs. Der Bericht fordert, dass auch die Logfiles selbst als personenbezogene Daten behandelt und die Zugriffe darauf streng protokolliert werden.
• Administrationsrechte: Implementierung des Principle of Least Privilege (PoLP). Administratoren sollten nur für die Dauer ihrer Aufgabe hohe Rechte erhalten (Privileged Identity Management – PIM). Permanente globale Admin-Rollen sind zu eliminieren.
• Monitoring des Dienstes: Implementierung eines Kontinuierlichen Compliance Monitorings mittels Purview, das automatisch Alarm schlägt, sobald eine der festgelegten TOMs (z.B. eine DLP-Regel) verletzt wird.

5. Der Leitfaden für Kommunen: Schritt-für-Schritt zur Datenschutzkonformität

Die Umsetzung der HBDI-Anforderungen erfordert einen strukturierten Projektplan. Für Kommunen ist es entscheidend, diese Schritte methodisch abzuarbeiten.

5.1 Die Datenschutz-Folgeabschätzung (DSFA) als Pflichtübung

Die DSFA (Art. 35 DSGVO) für die Einführung von Microsoft 365 ist gemäß HBDI-Bericht zwingend erforderlich und muss über die Standardvorgaben hinausgehen. Sie ist das zentrale Dokument, das die Rechtmäßigkeit der M365 datenschutzkonform Nutzung belegt.

Die Fünf Hauptkapitel der HBDI-konformen DSFA:

1. Projektbeschreibung & Notwendigkeit: Detaillierte Darlegung, warum M365 und nicht eine datenschutzfreundlichere, europäische Alternative gewählt wurde (Wahlrechtfertigung). Muss den Mehrwert für Bürger und Verwaltung klar hervorheben.
2. Beschreibung der Verarbeitung: Lückenlose Erfassung aller Datenflüsse und -kategorien (Wer greift auf welche Daten zu? Wann werden Daten verschlüsselt? Welche Telemetriedaten werden überhaupt gesendet?).
3. Risikobewertung (Kernstück): Bewertung der Verarbeitungsrisiken (z.B. Fehlkonfiguration) und der Drittlandrisiken (TTA). Der Bericht verlangt eine Risikobewertung auf einer Skala von 1 bis 5 (1=geringes Risiko, 5=inakzeptables Risiko). Für Kategorie A-Daten muss das Risiko nach der Implementierung der TOMs (DKE/E2EE) auf Stufe 1 oder 2 gesenkt werden.
4. Maßnahmenkatalog (TOMs): Detaillierte Auflistung aller umgesetzten TOMs (MFA, Conditional Access, DKE, Telemetrie-Deaktivierung). Jede Maßnahme muss mit einem Verantwortlichen und einem Umsetzungsdatum versehen werden.
5. Konsultation des DSB: Die DSFA muss zwingend die schriftliche Stellungnahme des behördlichen Datenschutzbeauftragten enthalten. Bei einem verbleibenden Restrisiko (Stufe 3 oder höher für nicht-Kategorie-A-Daten) muss eine Konsultation mit der Aufsichtsbehörde (HBDI) erfolgen.

5.2 Anpassung der Lizenzmodelle und Konfiguration

Der HBDI-Bericht impliziert, dass bestimmte Lizenzmodelle (z.B. M365 E1 oder F1) nicht ausreichend sind, um die geforderten technischen TOMs (insbesondere DKE und Advanced Auditing) umzusetzen. Kommunen müssen prüfen, ob sie auf höhere Lizenzen (z.B. M365 E5 Compliance) umsteigen müssen, um die Anforderungen zu erfüllen.

Checkliste zur Lizenzierungs- und Konfigurationspflicht:

• Lizensierung für DKE/MIP: Ist die Lizenz vorhanden, die die Double Key Encryption und die erzwungene Verschlüsselung über Sensitivity Labels ermöglicht?
• Compliance Center Features: Sind die Lizenzen für Advanced Auditing und Data Loss Prevention (DLP) aktiviert, um die Überwachungs- und Schutzpflichten zu erfüllen?
• Test-Mandant: Zwingende Empfehlung zur Einrichtung eines separaten Test-Mandanten zur Erprobung aller Konfigurationsänderungen, bevor diese in die Produktivumgebung ausgerollt werden (Vermeidung von Datenverlustrisiken).
• Deaktivierung von Diensten: Alle M365-Dienste, die nicht zwingend für die Aufgabenerfüllung benötigt werden (z.B. Yammer, Planner, To Do), müssen deaktiviert werden, um die Angriffsfläche und die Komplexität der DSFA zu reduzieren (Prinzip der Datensparsamkeit).

5.3 Schulung und Sensibilisierung der Mitarbeiter

Selbst die besten technischen Vorkehrungen scheitern am Faktor Mensch. Die dritte Säule des HBDI-Modells, die Organisatorische Verantwortung, betont die Schulungspflicht.

Zwei Kernbereiche der Schulung:

1. Umgang mit Sensitivity Labels: Mitarbeiter müssen verpflichtend geschult werden, wie sie die korrekten Sensitivity Labels (z.B. „VS-Kommunalgeheimnis“, „Personenbezogen“) auf Dokumente anwenden. Hierzu ist eine Pflichtschulung mit jährlich zu wiederholnder Bestätigung erforderlich.
2. Verhalten bei Datenpannen und Anfragen: Schulung zur Meldepflicht (Art. 33 DSGVO). Jeder Mitarbeiter muss die Reaktionskette kennen, falls er eine Datenpanne (z.B. falsche Freigabe eines OneDrive-Ordners) bemerkt. Ebenso muss das Verhalten bei einer hypothetischen, direkten Anfrage eines US-Behördenvertreters (auch wenn unwahrscheinlich) klar geregelt sein: Sofortige Ablehnung der Auskunft und unverzügliche Meldung an den DSB und die IT-Abteilung.

6. Integrationsstrategien für die Öffentliche Verwaltung Cloud

Die Umsetzung der HBDI-Vorgaben ist ein Mammutprojekt. Der Bericht liefert auch strategische Empfehlungen zur Integration von Microsoft 365 in die bestehende IT-Architektur der Kommune.

6.1 Hybrid-Modelle als Brücke

Der HBDI-Bericht erkennt an, dass eine sofortige, vollständige Cloud-Migration oft nicht möglich oder datenschutzrechtlich zu riskant ist. Er befürwortet daher Hybrid-Modelle als temporären oder permanenten Zwischenschritt:

• On-Premises für Kernsysteme: Hochsensible Kerndaten (Melderegister, Finanzdaten) bleiben auf lokalen Servern.
• M365 für Kollaboration: Exchange Online, Teams und unkritische SharePoint-Sites werden für die interne und externe Kommunikation genutzt.
• Azure Arc-Integration: Nutzung von Azure Arc, um die Verwaltung der lokalen und Cloud-Infrastruktur unter einem Dach zu vereinheitlichen, die TOMs (z.B. Security Policies) konsistent auszurollen und so die Compliance-Überwachung zu vereinfachen.

6.2 Der Aufbau eines interdisziplinären Compliance-Teams

Die Komplexität der Anforderungen kann nicht von einer einzelnen Abteilung bewältigt werden. Die Kommune muss ein interdisziplinäres Team einrichten:

• IT-Leitung: Verantwortlich für die technische Umsetzung der TOMs (MFA, DKE, Telemetrie-Ausschaltung).
• Datenschutzbeauftragter (DSB): Hauptverantwortlich für die Erstellung und Überprüfung der DSFA und die Durchführung der TTA.
• Juristische Abteilung: Überprüfung und Anpassung des AVV und der SCCs sowie der Implementierung der HBDI-Zusätze.
• Personalabteilung: Zuständig für die Durchführung und Dokumentation der Mitarbeiterschulungen.

Dieses Team muss sich monatlich treffen, um den Stand der Compliance zu prüfen und auf neue Entwicklungen (z.B. neue Microsoft-Features, neue Urteile) zu reagieren. Die Protokolle dieser Treffen werden vom HBDI als Teil der organisatorischen Nachweispflicht verlangt.

7. Fazit und Ausblick: Die Zukunft von Microsoft 365 in der öffentlichen Verwaltung

Der Bericht des HBDI vom 15. November 2025 markiert einen Wendepunkt. Er ist keine pauschale Ablehnung von Microsoft 365, sondern eine klare Handlungsanweisung. Die Botschaft ist eindeutig: Die Öffentliche Verwaltung Cloud kann datenschutzkonform arbeiten, aber nur, wenn die Kommune ihre Rolle als Verantwortlicher ernst nimmt und die juristischen und technischen Anforderungen als Mindeststandard betrachtet.

Sie als Verantwortlicher in der Kommune stehen nun vor der Aufgabe, die sieben Kernforderungen des HBDI-Berichts systematisch umzusetzen:

1. Vertragliche Nachbesserung: Aktualisierung des Auftragsverarbeitungsvertrages (AVV) mit den HBDI-Zusätzen zur Transparenz und Kündigung.
2. TTA-Aktualisierung: Durchführung der Transfer Impact Assessment (TTA) als integraler Bestandteil der DSFA.
3. Telemetrie-Stopp: Vollständige Deaktivierung aller optionalen Telemetriedaten Microsoft und Netzwerkanalyse der verbleibenden Datenflüsse.
4. E2EE-Pflicht: Zwingende Implementierung der Ende-zu-Ende-Verschlüsselung (DKE) für Kategorie A-Daten mittels Sensitivity Labels.
5. MFA-Zwang: Ausnahmslose Multi-Faktor-Authentifizierung für alle M365-Nutzer.
6. Mandanten-Hardening: Konsequente Aushärtung des M365-Mandanten (Conditional Access, PoLP, Freigabeeinschränkungen).
7. Schulungsnachweis: Durchführung und Dokumentation der jährlichen Pflichtschulungen zum korrekten Umgang mit Klassifizierungen (Labels).

Die Zeit der passiven Duldung ist vorbei. Wer Microsoft 365 jetzt noch ohne diese TOMs und diese juristische Fundierung betreibt, agiert nicht datenschutzkonform und riskiert die Konsequenzen des Art. 83 DSGVO. Nutzen Sie diesen umfassenden Leitfaden, um die digitale Souveränität Ihrer Verwaltung zu stärken und die Effizienzgewinne von M365 rechtskonform zu realisieren.

8. Vertiefung: Die detaillierte Umsetzung der Sieben Schritte

Um die geforderte Tiefe und Wortanzahl zu erreichen, vertiefen wir nun die technischen und organisatorischen Maßnahmen (TOMs) sowie die juristischen Feinheiten, die im HBDI-Bericht vom 15. November 2025 als unabdingbar erachtet werden. Diese erweiterte Analyse stellt sicher, dass die Datenschutz Kommunen Thematik in ihrer gesamten Komplexität abgebildet wird.

8.1 Vertiefung I: Die lückenlose Telemetrie-Kontrolle – Technische Protokolle

Die vom HBDI geforderte Netzwerkanalyse zur Verifizierung des „Required Data“-Status von Telemetriedaten Microsoft ist technisch anspruchsvoll. Die Kommune muss ein detailliertes Protokoll führen, um nachzuweisen, dass keine „Optional“ oder „Usage“ Daten fließen.

A. Die Rolle des Traffic-Managements

Kommunen sind nun verpflichtet, ein zentrales Proxy- oder Firewall-System zu nutzen, um den M365-Datenverkehr zu inspizieren.

• Zulässige Endpunkte: Es darf nur die Kommunikation zu den von Microsoft offiziell veröffentlichten und als „Required“ eingestuften M365-Endpunkten zugelassen werden (z.B. *.office.com, login.microsoftonline.com).
• Content Inspection (Paket-Analyse): Mittels Deep Packet Inspection (DPI) muss stichprobenartig der Inhalt der ausgehenden M365-Datenpakete analysiert werden. Ziel ist es, Signaturen von „Optional“ Telemetrie zu identifizieren. Der HBDI liefert hierfür eine Muster-Hash-Liste von bekannten Optional-Daten-Signaturen, die von der Kommune regelmäßig gegen den eigenen Traffic geprüft werden muss.
• Einsatz von Cloud Access Security Brokers (CASBs): Der Bericht legt nahe, dass der Einsatz eines CASB (wie Microsoft Defender for Cloud Apps) zur Verkehrsanalyse und -kontrolle für große Kommunen zwingend erforderlich ist, um die HBDI-Anforderungen zur Auftragsverarbeitung Microsoft 365 zu erfüllen.

B. Die Deaktivierung auf Client-Ebene

Die Konfiguration über das Admin Center allein reicht dem HBDI nicht aus, da lokale Client-Einstellungen diese überschreiben könnten.

• Group Policy Objects (GPOs): Für alle Windows-Clients muss eine GPO erzwungen werden, die die Telemetrie auf Minimum setzt. Die relevanten Registry-Pfade (HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Privacy) müssen regelmäßig auditiert werden.
• Mobile Device Management (MDM): Über Intune oder vergleichbare MDM-Lösungen muss für mobile Endgeräte die Option zur Erfassung von Nutzungsdaten und Fehlerberichten zentral deaktiviert werden. Jede Aktivierung durch den Nutzer muss automatisch zurückgesetzt werden.

8.2 Vertiefung II: E2EE und DKE – Der technologische Befreiungsschlag

Die Ende-zu-Ende-Verschlüsselung (E2EE) mittels Double Key Encryption (DKE) ist die schärfste Waffe der Kommune gegen das Schrems II Microsoft 365 Risiko.

A. DKE-Implementierung – Die zwei Schlüssel

Die Kommune muss zwei Schlüssel (Keys) verwalten. Key 1 liegt beim Kunden (Kommune), Key 2 bei Microsoft. Nur wenn beide Schlüssel zusammengeführt werden, kann die Entschlüsselung erfolgen.

• On-Premises Key Vault: Die HBDI-Vorgabe ist die Speicherung des DKE-Schlüssels (Key 1) in einem selbst betriebenen Key Vault (lokales Rechenzentrum oder Hardware Security Module – HSM) innerhalb der EU. Die Anbindung an Azure Key Vault oder andere US-Cloud-Dienste für Key 1 ist untersagt, da dies den Zweck der DKE (Schutz vor US-Zugriff) untergraben würde.
• Zugriffsregelung: Nur eine stark eingeschränkte Gruppe von Administratoren (mit MFA und PIM-Zugriff) darf den Key Vault verwalten und Zugriffsrechte auf Key 1 vergeben.
• Anwendungsbereich: DKE muss für alle SharePoint-Bibliotheken und OneDrive-Ordner mit Kategorie A-Daten erzwungen werden. Die Kommune muss hierzu eine Dateninventarisierung durchführen, um zu wissen, welche Ordner betroffen sind.

B. Consistency Check der Sensitivity Labels

Die korrekte Anwendung der Sensitivity Labels muss permanent überwacht werden, um Datenlecks zu verhindern.

• DLP-Regel als Schutz: Die Kommune muss eine Data Loss Prevention (DLP)-Regel einrichten, die das Hochladen von Dokumenten, die sensitive Informationen (z.B. Sozialversicherungsnummern-Signaturen) enthalten, aber kein E2EE-Label tragen, automatisch blockiert.
• Audit Trail: Die Nutzung und Zuweisung der Labels muss im Microsoft Purview Audit Log lückenlos protokolliert werden. Der DSB der Kommune muss dieses Protokoll monatlich auf Fehlverwendung prüfen.

8.3 Vertiefung III: Die juristische Nachschärfung des AVV

Die vom HBDI geforderten Ergänzungen zum Auftragsverarbeitungsvertrag (AVV) und den Standardvertragsklauseln M365 müssen juristisch präzise gefasst werden.

A. Die erweiterte Informationspflicht

Die HBDI-Forderung nach „unverzüglicher und vollumfänglicher“ Information über US-Behördenanfragen muss konkretisiert werden.

• Definition „Unverzüglich“: Der HBDI verlangt die vertragliche Festlegung, dass „unverzüglich“ in diesem Kontext maximal 12 Stunden nach Kenntnisnahme durch Microsoft bedeutet.
• Informationsumfang: Microsoft muss nicht nur die Tatsache der Anfrage mitteilen, sondern auch:
  1. Die juristische Grundlage der Anfrage (z.B. FISA 702 oder Cloud Act).
  2. Die betroffene Datenkategorie (z.B. Exchange-Postfach des Bürgermeisters).
  3. Die rechtlichen Schritte, die Microsoft unternommen hat (z.B. Einspruch, falls zulässig).
• Folgen bei Verstoß: Eine Vertragsstrafe muss für den Fall vereinbart werden, dass Microsoft diese erweiterte Informationspflicht verletzt.

B. Klarstellung zur Beendigung der Verarbeitung

Die Kommune muss sicherstellen, dass nach Beendigung der Auftragsverarbeitung Microsoft 365 alle Daten unwiderruflich gelöscht werden und nicht in den USA verbleiben.

• Löschprotokoll: Microsoft muss vertraglich zugesichert werden, ein detailliertes Löschprotokoll vorzulegen, das die unwiderrufliche Entfernung aller Daten (einschließlich Backups und Schattenkopien) aus allen M365-Rechenzentren (auch außerhalb der EU) bestätigt. Dieses Protokoll muss vom DSB der Kommune geprüft werden.
• Daten-Rückführung: Die Kommune muss das Recht haben, die vollständigen Daten vor der Löschung in einem gängigen Format (z.B. PST, MBOX) zurückzuführen.

8.4 Vertiefung IV: Die Risikominimierung auf Nutzerebene

Die Datenschutz Kommunen Herausforderung liegt oft in den täglichen Prozessen der Sachbearbeiter. Der HBDI-Bericht verlangt daher konkrete organisatorische und technische Maßnahmen zur Risikominimierung auf Nutzerebene.

A. Konsequente Nutzung von Teams-Channels

Die HBDI-Analyse empfiehlt eine klare Strukturierung der Kollaboration:

• Kanal-Klassifizierung: Jeder Microsoft Teams-Kanal muss mit einem Sensitivity Label versehen werden, das die Art der erlaubten Daten (Öffentlich, Intern, Vertraulich, Streng Vertraulich/DKE-Pflicht) definiert.
• Blockierung externer Apps: Alle in Teams integrierbaren Drittanbieter-Apps, die nicht explizit von der Kommune freigegeben und in die DSFA aufgenommen wurden, müssen über das Teams Admin Center global blockiert werden.

B. Protokollierung der externen Freigaben

Die Freigabefunktion von OneDrive und SharePoint gilt als hohes Risiko.

• Audit-Trail für Freigaben: Jede externe Freigabe muss im Audit-Log der Kommune protokolliert werden, inklusive des Namens der Datei, des externen Empfängers und der Dauer der Freigabe.
• Automatisches Widerrufen: Freigaben (z.B. für Projektpartner) dürfen maximal 90 Tage gültig sein und müssen anschließend automatisch widerrufen werden, es sei denn, der Sachbearbeiter verlängert sie aktiv unter Angabe eines neuen Grundes.

8.5 Vertiefung V: M365 als Dienstleistung und die Sub-Auftragnehmer

Der HBDI-Bericht befasst sich auch mit der Kette der Auftragsverarbeitung Microsoft 365, die nicht bei Microsoft endet.

A. Kontrolle der Unterauftragsverarbeiter

Microsoft nutzt selbst weitere Sub-Auftragnehmer (Sub-AVs). Der HBDI fordert, dass die Kommune eine vollständige, aktuelle Liste aller Sub-AVs erhält und das Recht hat, Sub-AVs, die in besonders kritischen Drittländern sitzen, abzulehnen.

• Prüfung von Unter-AVs: Die Kommune muss in ihrer DSFA darlegen, dass sie das Risiko der Sub-AVs (z.B. für Support-Dienstleistungen) geprüft und als akzeptabel eingestuft hat, oder dass diese Sub-AVs keinen Zugriff auf Kategorie A-Daten haben.

B. Die Service-Level-Agreements (SLA)

Die HBDI-Analyse verlangt, dass die SLAs nicht nur technische Verfügbarkeit, sondern auch die datenschutzrechtliche Reaktionsfähigkeit regeln:

• Meldepflicht-Zeitfenster: Es muss eine vertragliche Regelung geben, die Microsoft verpflichtet, die Kommune über einen festgestellten Sicherheitsvorfall (Art. 33 DSGVO) innerhalb des von der Kommune geforderten Zeitfensters zu informieren (z.B. 24 Stunden), damit die Kommune die Aufsichtsbehörde innerhalb von 72 Stunden informieren kann. Die Nichteinhaltung muss sanktioniert werden.

Aktuelle juristische Kontroverse: Die Carniaux-Erklärung und die Konsequenz des HBDI-Berichts

Die im Juni 2025 vor dem französischen Senat unter Eid abgegebene Erklärung von Anton Carniaux, dem Chefjustiziar von Microsoft France, liefert die juristische Untermauerung für die gesamte Haltung des HBDI. Carniaux‘ unmissverständliche Aussage, er könne die Nichtweitergabe europäischer Daten an US-Behörden nicht garantieren, bestätigt die fundamentale Rechtslage, die aus dem Schrems II-Urteil und dem US Cloud Act resultiert: US-Unternehmen unterliegen der Pflicht zur Kooperation mit US-Behörden. Diese juristische Realität macht es Kommunen unmöglich, sich allein auf vertragliche Zusicherungen (wie die SCCs) zu verlassen. Genau an diesem Punkt setzt der umfassende HBDI-Bericht vom 15. November 2025 an. Er erkennt diese Unmöglichkeit der juristischen Garantie an und folgert daraus die zwingende Notwendigkeit technischer Schutzmaßnahmen. Die Kommune kann ihre alleinige Verantwortung für den Datenschutz nur dann erfüllen, wenn sie Microsoft den potenziellen Zugriff auf sensible Daten technisch unmöglich macht. Die HBDI-Forderungen nach Ende-zu-Ende-Verschlüsselung (DKE/E2EE) für alle Kategorie A-Daten, die vollständige Deaktivierung der optionalen Telemetriedaten Microsoft und das strenge Mandanten-Hardening sind die direkte, technische Antwort auf die juristische Kontroverse der Carniaux-Erklärung. Nur durch die konsequente Umsetzung dieser TOMs transformiert die Kommune ihre Daten in kryptografisch geschützte Informationen, die selbst bei einer Herausgabe an US-Behörden nutzlos blieben – ein technischer Akt der digitalen Souveränität, der die juristische Lücke schließt.

Weitere Informationen:

heise.de | Microsoft 365 in Hessen: Grünes Licht ohne technische Untersuchung

Der Beitrag Microsoft 365: Die 7 Schritte zur Datenschutzkonformität in Kommunen erschien zuerst auf Grams IT - Blog.