Windows Server 2025: Security, Zero Trust & Infrastruktur neu gedacht

Eines der zentralen Themen ist Zero Trust DNS (ZTDNS). Microsoft integriert dabei den DNS-Client direkt in die Windows Filtering Platform – ausgehender Netzwerkverkehr ist standardmäßig blockiert, und Verbindungen sind nur erlaubt, wenn die Zieladresse zuvor über einen explizit konfigurierten Protective-DNS-Server (PDNS) aufgelöst wurde. Direkte IP-Verbindungen ohne Namensauflösung? Nicht mehr möglich. Die Namensauflösung erfolgt ausschließlich verschlüsselt über DNS over HTTPS (DoH) oder DNS over TLS (DoT).

Wichtige Klarstellung zur Verfügbarkeit:

ZTDNS ist aktuell allgemein verfügbar für Windows 11 Enterprise und Windows 11 Education. Für Windows Server 2025 befindet sich die Client-seitige Nutzung im Aufbau, während DoH-Unterstützung im Windows DNS Server selbst seit dem Februar-2026-Update in der Public Preview ist. Wer ZTDNS heute evaluieren möchte, sollte daher genau prüfen, welche Szenarien und Editionen bereits produktionsreif sind.

Warum das relevant ist:

• Schutz vor DNS-Hijacking und manipulierten Resolvern
• Blockade von Malware-Kommunikation (Command & Control)
• Verhinderung von Datenexfiltration ohne legitime DNS-Auflösung
• Keine Abhängigkeit von Paketinspektion oder SNI-Auswertung – funktioniert auch bei vollständig verschlüsseltem Transport
• Prozessstarts mit vollständigen Kommandozeilen-Argumenten
• Netzwerkverbindungen mit Prozesszuordnung
• Datei- und Registry-Aktivitäten
• Prozessmanipulationen und WMI-Persistenz

Aus meiner Erfahrung in Datacenter- und Hybrid-Umgebungen ist das ein konsequenter Schritt – aber auch einer mit spürbaren Auswirkungen. Mechanismen wie mDNS, LLMNR, WebRTC-basierte Anwendungen oder bestimmte Peer-to-Peer-Szenarien funktionieren nur noch mit gezielten Ausnahmen. Der von Microsoft vorgesehene Audit-Modus ist deshalb kein Nice-to-have, sondern zwingend notwendig, um Abhängigkeiten sauber zu identifizieren, bevor man in den Enforcement-Modus wechselt.

Beim Thema Verschlüsselung geht Microsoft ebenfalls einen konsequenten Schritt weiter. BitLocker nutzt bei unterstützter Hardware dedizierte Crypto-Engines in CPU oder SoC – kryptografische I/O-Operationen werden aus dem allgemeinen CPU-Kontext ausgelagert, Schlüsselmaterial bleibt hardwareseitig isoliert, und standardmäßig kommt XTS-AES-256 zum Einsatz.

Gerade in NVMe-basierten Storage-Architekturen zeigt sich der Mehrwert deutlich: höhere Performance bei gleichzeitig geringerer Angriffsfläche. Für IT-Admins bleibt die Kontrolle erhalten – etwa über GPOs oder MDM-Richtlinien. Der aktive Modus lässt sich sauber per manage-bde -status überprüfen.

Aus Infrastrukturperspektive wird hier klar: Verschlüsselung ist kein nachgelagertes Feature mehr, sondern fester Bestandteil der Storage-Architektur. Das setzt allerdings voraus, dass die eingesetzte Hardware diese Funktionen auch unterstützt – ein Punkt, den ich bei Bestandsumgebungen regelmäßig prüfen muss.

Ein echtes Highlight für den Betrieb ist die bevorstehende native Sysmon-Integration. Microsoft hat auf der Ignite 2025 angekündigt, Sysmon-Funktionalität im Laufe von 2026 als optionales Windows-Feature in Windows 11 und Windows Server 2025 einzubringen – verteilt über Windows Update, ohne separate Sysinternals-Downloads.

Zur Einordnung: Sysmon ist derzeit noch nicht standardmäßig aktiv, sondern wird als optionales Feature ausgerollt. Administratoren aktivieren es explizit. Die Events landen – wie gewohnt – im Log unter Microsoft\Windows\Sysmon\Operational.

Erfasst werden unter anderem:

Für den Betrieb bedeutet das eine spürbare Vereinfachung: weniger manuelle Deployments, konsistente Versionierung, und die Telemetrie fließt direkt in SIEM, Threat Hunting und forensische Analysen. Wer heute bereits mit Sysmon arbeitet, sollte bestehende Konfigurationen und Detektionsregeln schon jetzt auf Kompatibilität prüfen – das erspart Überraschungen beim Rollout.

Viele der neuen Security-Features erscheinen zunächst in Insider Builds. Diese lassen sich direkt über Windows Update verteilen und erlauben In-Place-Upgrades zwischen Build-Ständen – was strukturierte Tests deutlich vereinfacht.

Meine klare Empfehlung aus der Praxis: Insider Builds sind reine Testsysteme. Sie eignen sich gut für die Validierung von Upgrade-Pfaden, Treiber- und Netzwerk-Tests sowie die Bewertung neuer Sicherheitsarchitekturen. Für produktive Workloads sind sie ausdrücklich nicht gedacht – Funktionsumfang, UI-Elemente und Schnittstellen können zwischen Builds schwanken, und nicht finale Features gehören zum Konzept.

Mit Windows Server 2025 erweitert Microsoft SMB over QUIC um die Unterstützung alternativer UDP-Ports. Das erleichtert Dateizugriffe über restriktive oder unsichere Netzwerke, erlaubt feinere Firewall-Regeln und ermöglicht sicheren Remote-Zugriff ohne den Overhead klassischer VPN-Tunnel.

Gerade im Zusammenspiel mit hybriden Identitätsmodellen steigt damit aber auch die Verantwortung für saubere Zugriffskonzepte und konsequentes Monitoring. SMB over QUIC ist kein Ersatz für ein durchdachtes Zugriffsmodell – es ist ein Werkzeug, das ein solches voraussetzt.

Mit Native NVMe verkürzt Microsoft den I/O-Pfad und reduziert die SCSI-Abstraktion. Das bringt nicht nur Performance, sondern auch mehr Kontrolle und Vorhersehbarkeit im Storage-Stack – ein Punkt, der in I/O-intensiven Workloads wie Datenbanken oder virtualisierten Umgebungen schnell zum Unterschied macht.

Spannend wird es in Kombination mit lokaler KI: Windows ML erkennt verfügbare CPU- und GPU-Ressourcen, Inference-Workloads laufen lokal statt in der Cloud, und GPU-P sowie Discrete Device Assignment sorgen für saubere Isolation in virtuellen Maschinen.

Für viele meiner Kunden ist das ein entscheidender Punkt: KI-Funktionen lassen sich nutzen, ohne Daten aus dem eigenen Rechenzentrum herauszugeben – ein klares Plus für Compliance und Datenhoheit