Kapitel 2: Edition-Strategie und Architekturentscheidungen

Bevor die erste Gruppenrichtlinie geschrieben oder das erste Intune-Profil angelegt wird, müssen zwei Entscheidungen getroffen sein: Welche Windows-11-Edition läuft auf welcher Geräteklasse, und welches Identitäts- und Verwaltungsmodell ist der zentrale Steuerungspunkt. Beide Entscheidungen sind im Kleinunternehmen schnell getroffen, im wachsenden Mittelstand aber oft die Quelle späterer Compliance-Probleme — etwa wenn ein Außendienstgerät versehentlich mit Windows 11 Home ausgerollt wird oder ein einzelner Standort weiterhin im klassischen Active Directory ohne Intune-Anbindung läuft, während alle Härtungs-Policies bereits auf den Settings Catalog umgestellt wurden.

In diesem Kapitel arbeiten wir die zentralen Architekturhebel der Reihe nach durch, ordnen sie nach Schutzbedarf und liefern eine Entscheidungsmatrix, die die spätere Konfiguration konsistent trägt.

Edition-Matrix mit Datenschutz-Filter

Microsoft liefert Windows 11 in mehreren Editionen aus, deren Funktionsumfang sich nicht nur in den Komfort-Features unterscheidet, sondern auch in den verfügbaren Härtungs- und Datenschutz-Hebeln. Die Auswahl der Edition entscheidet, welche Policies überhaupt greifen.

Die entscheidende Spalte ist die erste: Erst die Enterprise-/Education-/LTSC-Editionen erlauben den Diagnostic-Data-Wert 0 („Off"). Auf Pro ist der niedrigste produktiv durchsetzbare Wert 1 („Required"). Wer DSFA-relevante Verarbeitungen auf Pro-Geräten ausführt — etwa Personal- oder Gesundheitsdaten —, sollte diesen Unterschied kennen und in der Risikobewertung dokumentieren.

Windows 11 Home scheidet für Unternehmen praktisch vollständig aus. Es lässt sich nicht in eine Domäne aufnehmen, hat weder gpedit.msc noch secpol.msc, keine vollständige BitLocker-Verwaltung, keine vollständige Telemetrie-Steuerung und keine Hybrid-Join-Fähigkeit. Geräte mit Home-Vorinstallation müssen vor dem produktiven Einsatz auf Pro oder Enterprise angehoben werden — entweder durch In-Place-Upgrade per Volumenlizenz oder im Zuge eines Neu-Provisionings via Windows AutoPilot.

LTSC und IoT Enterprise LTSC

Die LTSC-Editionen (Long-Term Servicing Channel) verdienen einen eigenen Absatz, weil sie in Datenschutz-Diskussionen oft missverstanden werden. LTSC bedeutet: keine Funktionsupdates für mehrere Jahre — Windows 11 Enterprise LTSC 2024 hat einen fünfjährigen Lebenszyklus (Support bis 9. Oktober 2029), Windows 11 IoT Enterprise LTSC 2024 wird mit Extended-Support bis 10. Oktober 2034 zehn Jahre gepflegt. Beide Varianten verzichten auf Microsoft Store (eingeschränkt), Cortana, Recall, Click to Do, den integrierten Copilot und den OneDrive-Sync-Client. Microsoft Edge ist in LTSC 2024 — anders als in LTSC 2021 — als Standardbrowser enthalten. Aus reiner Datenschutz-Sicht ist LTSC trotzdem das „sauberste" Windows: Die meisten KI- und Consumer-Funktionen, die in Kapitel 5 mühsam abgeschaltet werden müssen, sind in LTSC gar nicht erst enthalten.

Die Schattenseite: LTSC ist von Microsoft nicht für allgemeine Office- und Wissensarbeiter-Arbeitsplätze vorgesehen. Die Volumenlizenzbedingungen und die Produktstrategie adressieren ausdrücklich Special-Purpose-Geräte — Industriesteuerungen, medizinische Bildgebung, Kassensysteme, Geldautomaten, Kiosk-Stationen. Wer LTSC flächendeckend als Wissensarbeiter-Plattform ausrollt, widerspricht der lizenzrechtlichen Zwecksetzung und kann in Lizenzaudits beanstandet werden. Sinnvoll ist LTSC für eng definierte Anwendungsfälle: OT-Stationen, dedizierte Kiosk-Geräte, Geräte mit Spezialsoftware, die jeden Feature-Update-Sprung blockiert.

Für die Wissensarbeiter-Flotte bleibt Enterprise (E3 oder E5) der Standard. Die Härtung der KI-Funktionen erfolgt dann zentral per Policy — der Aufwand ist überschaubar (siehe Kapitel 5).

Identitäts- und Verwaltungsmodelle

Die zweite große Architekturentscheidung betrifft die Identitäts- und Verwaltungsseite. In der Praxis sehen wir vier Modelle, die jeweils unterschiedliche Härtungs-Hebel mitbringen.

Klassisches On-Prem Active Directory mit GPO. Der traditionelle Stack — domain-joined Clients, Group Policy Objects, Software-Verteilung per Configuration Manager oder Drittwerkzeug. Alle Härtungspfade aus diesem Leitfaden sind hier umsetzbar; die Modernisierung der ADMX-Templates auf den jeweils aktuellen Windows-11-Build muss aktiv betrieben werden (Kapitel 7). Schwächen liegen in der Außendienst-Verwaltung, der fehlenden Echtzeit-Compliance-Bewertung und der eingeschränkten Steuerbarkeit moderner CSP-Settings, die teilweise nur über MDM gepflegt werden.

Microsoft Entra hybrid join (vormals „Hybrid Azure AD Join"). Geräte sind sowohl in einer lokalen AD-Domäne als auch in Entra ID registriert. GPO und MDM können parallel verwendet werden — typischerweise GPO für klassische Systemkonfiguration, Intune (oder ein anderes MDM) für moderne CSP-Settings, App-Verteilung und Compliance. Die Kollisionsregeln (Default: GPO gewinnt; per MDMWinsOverGP kippbar — siehe Kapitel 7) müssen aktiv gemanagt werden, sonst entstehen schwer diagnostizierbare Drift-Effekte.

Microsoft Entra Join (Cloud-only). Der reine Cloud-Pfad — Geräte sind ausschließlich in Entra ID registriert, GPO existiert nicht, alle Konfiguration kommt aus Intune (oder einem anderen MDM, das CSP unterstützt). Härtungstechnisch ist das der zukunftssicherste Pfad, weil Microsoft moderne Settings primär als CSP veröffentlicht und ADMX-Pendants oft mit Verzögerung folgen. Identitätsseitig ist Microsoft Entra Join der Standard für AutoPilot-Deployments; Microsoft bewirbt Autopilot Hybrid Join nicht mehr als strategischen Pfad — Greenfield-Deployments sollten cloud-nativ angelegt werden.

Unmanaged / BYOD. Geräte, die weder GPO noch MDM unterliegen. Aus Datenschutz-Sicht sind sie für produktive Verarbeitung personenbezogener Daten praktisch nicht freigebbar — weder Privacy-by-Default noch der Nachweis angemessener Maßnahmen lässt sich darauf führen. Wenn BYOD geduldet werden muss, gehört es entweder in eine Conditional-Access-Lane mit App Protection Policies (Intune App Protection für M365-Daten ohne Geräteverwaltung) oder hinter eine VDI-/Cloud-PC-Lösung (z. B. Windows 365 oder Azure Virtual Desktop), die das Gerät selbst aus der Verarbeitung herausnimmt.

Wann ist Hybrid sinnvoll, wann Cloud-only?

Die Entscheidung zwischen Hybrid und Cloud-only ist in den meisten Unternehmen eine Migration, kein Greenfield-Setup. Drei Kriterien geben die Richtung vor.

Wenn der Bestand an Drittsoftware tief in AD-spezifische Mechanismen integriert ist (Kerberos-Single-Sign-On gegen klassische Webanwendungen, AGPM-basierte GPO-Verwaltung, ältere AD-CS-Vorlagen), läuft die Migration auf Cloud-only auf einen mehrjährigen Transformationspfad hinaus — Hybrid ist dann das pragmatische Zwischenziel. Wenn dagegen die Identität bereits weitgehend über Entra ID läuft (Microsoft 365 ist Tenant-Standard, SaaS-Anwendungen sind via SAML/OIDC angebunden) und das lokale AD nur noch wenige Spezialfälle bedient, ist Cloud-only erreichbar und sollte das mittelfristige Ziel sein.

Aus Datenschutz-Sicht ist Cloud-only nicht prinzipiell „besser" oder „schlechter" als Hybrid — beide können gleich konform betrieben werden. Cloud-only erleichtert allerdings die Durchsetzung moderner CSP-Settings, die Compliance-Bewertung in Conditional Access und die Nachweisführung in einem Audit, weil alle Zustandsdaten an einer Stelle liegen.

Anti-Pattern: Microsoft-Konto am Unternehmensgerät

Ein Konfigurationsmuster sollte in jeder Härtungsstrategie explizit ausgeschlossen werden: das Anmelden mit einem persönlichen Microsoft-Konto (MSA, „Microsoft Account") an einem Unternehmensgerät. Es synchronisiert OneDrive-Inhalte, Browser-Daten, Microsoft-Store-Käufe und Werbe-Identifier mit einem Konto, das nicht der Unternehmensgewalt unterliegt — die DSGVO-Verantwortlichkeit ist in diesem Moment nicht mehr sauber abbildbar.

Die Policy Accounts: Block Microsoft accounts (im Domain-GPMC: Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options; in der lokalen gpedit.msc ohne das eingeschobene Policies-Segment) setzt den zugrunde liegenden Registry-Wert NoConnectedUser unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Gültige Werte: 0 = keine Einschränkung, 1 = Nutzer dürfen kein MSA hinzufügen, 3 = Nutzer dürfen weder hinzufügen noch sich damit anmelden („Users can't add or log on with Microsoft accounts"). Auf Intune-Seite gibt es das Pendant über den Settings Catalog (Pfad: Local Policies Security Options → Accounts Block Microsoft Accounts). Diese Policy gehört in jede Härtungs-Baseline.

Die parallele Sperre für die Erstinstallation erfolgt im AutoPilot-Profil — durch den erzwungenen Hybrid- oder Entra-Join wird die MSA-Option im Out-of-Box-Erlebnis nicht angeboten.

Entscheidungsmatrix

Die folgende Tabelle fasst die Architekturentscheidungen in drei typischen Profilen zusammen und nennt das jeweilige Edition-/Verwaltungs-Bundle.

In den meisten mittelständischen Unternehmen finden sich Profil A und C parallel, in Konzernumgebungen häufig alle drei. Wichtig ist, dass für jedes Profil eine eigene Baseline definiert wird — die Empfehlungen für eine IoT-LTSC-Werkstattzelle sind nicht identisch mit den Empfehlungen für ein E5-Notebook im Vertrieb.

Vorbereitung auf das Inventar

Die Architekturentscheidungen aus diesem Kapitel sind die Grundlage für das Inventar, das wir in Kapitel 3 aufnehmen. Bevor wir Telemetrie und KI-Features härten, brauchen wir pro Gerät: Edition (Get-ComputerInfo | Select WindowsProductName), Build und Funktionsversion (Get-ComputerInfo | Select OsBuildNumber, OsHardwareAbstractionLayer), Join-Status (dsregcmd /status), Verwaltungstool (Intune-Enrollment, GPO-Domain-Join, beides oder keines).

Die Inventar-Aufnahme entlarvt typischerweise drei Problemfälle, die in der Härtung Priorität bekommen: Pro-Geräte, die produktiv eingesetzt werden, aber DSFA-relevante Verarbeitungen ausführen (Aufwertung auf Enterprise oder eindeutige Begrenzung des Anwendungsfalls); Hybrid-Geräte mit MDM-Enrollment, aber ohne durchgesetzte Compliance-Policy (Settings-Drift); und Geräte mit persönlichem Microsoft-Konto, die im AutoPilot-Workflow als „Entra-joined" gelten, aber nie unter die zentrale Verwaltung gefallen sind.

Mit diesen Architekturentscheidungen und der Inventar-Disziplin im Rücken können wir in Kapitel 3 die Baselines auflegen — der formale Rahmen, gegen den jede einzelne Policy aus den späteren Kapiteln verglichen wird.