Last Week in Azure & Tech – Vol. 4 – Schluss mit Default Outbound: Azure erzwingt Zero Trust im Netzwerk

Ende März wird Microsoft die Default Outbound Internet Access für neue Virtual Networks und Ressourcen abschalten. Wer jetzt keine explizite Outbound-Konnektivität konfiguriert hat, steht vor einem Problem – Windows Activation, Intune Sync und Updates brechen ohne NAT Gateway oder vergleichbare Lösung schlicht weg. Für den DACH-Mittelstand ist das ein Weckruf: Zero Trust Networking ist ab sofort kein Nice-to-have mehr, sondern Pflicht.

🔥 Top-Thema der Woche

Default Outbound Internet Access wird für neue VNets entfernt

Microsoft entfernt Ende März 2026 die Default Outbound Internet Access für alle neuen Virtual Networks und Ressourcen. Bisher erhielten VMs und Dienste automatisch ausgehenden Internetzugang – ohne explizite Konfiguration. Das ändert sich jetzt grundlegend. Neue Deployments benötigen zwingend einen expliziten Outbound-Pfad: Azure NAT Gateway, Azure Firewall, Load Balancer Outbound Rules oder Public IPs. (Microsoft Learn)

Warum das relevant ist: Diese Änderung betrifft jede Organisation, die neue Workloads in Azure deployt. Bestehende VNets sind zunächst nicht betroffen – aber neue VMs in neuen VNets verlieren ohne Vorbereitung die Outbound-Konnektivität. Windows Activation, OS Updates, Intune-Enrollment und NTP-Sync sind die offensichtlichsten Opfer. Weniger offensichtlich: Viele Third-Party-Agents und Monitoring-Lösungen setzen ebenfalls impliziten Outbound voraus.

Meine Einschätzung: Das ist der konsequenteste Schritt, den Microsoft bisher in Richtung Zero Trust Networking gegangen ist. Richtig so – Default Outbound war schon immer ein Sicherheitsrisiko, das nur aus Bequemlichkeit existierte. Wer seine IaC-Templates und Landing Zones noch nicht auf expliziten Egress umgestellt hat, muss das jetzt tun. Besonders Terraform- und Bicep-Module sollten sofort geprüft werden. Der Impact auf bestehende CI/CD-Pipelines, die neue Ressourcen erstellen, wird in vielen Organisationen unterschätzt.

🤖 KI & Azure AI

• GPT-5.4 in Microsoft Foundry (GA): OpenAIs bisher leistungsfähigstes Modell ist in Microsoft Foundry verfügbar – optimiert für komplexe professionelle Aufgaben mit schnelleren und zuverlässigeren Ergebnissen in Produktion. Relevant für Teams, die Agentic Workflows und komplexe Reasoning-Tasks auf Enterprise-Niveau fahren. (Microsoft Foundry)
• Grok 4.0 und Qwen3.5 Medium in Azure AI Foundry: Zwei weitere Modelle erweitern den Model Catalog – Grok 4.0 als neues LLM von xAI und die Qwen3.5 Medium-Serie als kosteneffiziente Alternative für Standard-Tasks. (Azure Update)
• Phi-4-Reasoning-Vision: Microsofts neues multimodales Small Language Model kombiniert visuelle und sprachliche Reasoning-Fähigkeiten – interessant für Edge-Szenarien und On-Device-Inferenz. (Azure Update)
• Mistral Document AI in Microsoft Foundry: Enterprise-Grade Document Processing mit 95,9% Genauigkeit bei Multi-Column Layouts, handschriftlichen Annotationen und mehrsprachigen Dokumenten. Starke Option für Dokumentenverarbeitung in regulierten Branchen. (Tech Community)

📢 Azure Core Updates

Hybrid & Modern Work

• Dynamic Sessions in Azure Container Apps (GA): Isolierte, kurzlebige Sandboxes, die in Millisekunden starten und on-demand skalieren. Ideal für die sichere Ausführung von KI-generiertem Code in Agentic Workflows – ein Baustein, der im Enterprise-Umfeld bisher gefehlt hat. (Microsoft Learn)
• Databricks VNet Injection Migration (GA): Bestehende Databricks Workspaces können jetzt von Databricks-managed VNets auf eigene VNets migriert werden – ohne Neudeployment. Das vereinfacht die Netzwerkintegration in bestehende Hub-and-Spoke-Architekturen erheblich. (Microsoft Learn)
• Azure Container Registry Premium: Erweiterte Kapazität: Premium-Tier-Registries erhalten höhere Storage-Limits – relevant für Organisationen mit großen Container-Flotten und Multi-Arch-Images. (Azure Update)

🔐 Security & Identity

• SyncJacking Safeguards Enforcement: Microsoft erzwingt ab März 2026 neue Schutzmechanismen gegen Account-Takeover via Hard Match Abuse in Entra Connect. Die Enforcement-Logik prüft jetzt OnPremisesObjectIdentifier und blockiert Remapping-Versuche. Audit Logs wurden entsprechend erweitert. (Microsoft Learn)
• Service-Principal-Less Authentication Retirement (31.03.2026): Alle Applikationen ohne zugehörigen Service Principal verlieren den Login-Zugang. Wer Custom Apps oder Legacy-Integrationen betreibt, muss jetzt prüfen und migrieren. (Microsoft Learn)
• External Authentication Methods (EAM) – GA: Third-Party-MFA-Lösungen lassen sich jetzt nahtlos in Entra ID integrieren. Organisationen mit bestehenden MFA-Investments (Duo, RSA, etc.) können diese als First-Class-Citizen in Conditional Access nutzen. (Microsoft Learn)
• Sentinel UEBA Behaviors Layer (GA): Die User and Entity Behavior Analytics in Sentinel konvertieren High-Volume-Logs in lesbare Behavioral Insights – „Wer hat was mit wem gemacht“ ohne manuelle Korrelation. (Microsoft Defender News)
• Security Dashboard for AI (Preview): Unified, real-time Sicht auf KI-Bedrohungen über Agents, Apps und Plattformen hinweg. Verbindet Signale aus Defender, Entra und Purview – ohne Zusatzlizenz für bestehende Microsoft Security-Kunden. (Microsoft Defender News)

⚠️ Abkündigungen & Breaking Changes

💰 FinOps-Tipp der Woche

NAT Gateway statt Public IPs – so sparst du beim Default Outbound Removal: Mit dem Ende der Default Outbound Access stellt sich die Frage: NAT Gateway, Azure Firewall oder Load Balancer Outbound Rules? Für reine Outbound-Szenarien ist NAT Gateway die kosteneffizienteste Lösung. Der Break-even gegenüber einzelnen Public IPs liegt bei ca. 5-10 VMs pro Subnet. Schneller Check, welche VMs aktuell Default Outbound nutzen:

bash

az graph query -q "Resources | where type == 'microsoft.compute/virtualMachines' | where properties.networkProfile.networkInterfaces[0].properties.ipConfigurations[0].properties.publicIPAddress == null | project name, resourceGroup, location" --first 100

Prüfe für jede VM ohne Public IP, ob ein NAT Gateway oder eine andere explizite Outbound-Methode konfiguriert ist – sonst bricht die Konnektivität nach dem Stichtag.

💡 Deep Dive: Default Outbound Removal – was du jetzt tun musst

Die Abschaltung der Default Outbound Internet Access ist keine kleine Konfigurationsänderung – sie verändert fundamental, wie Azure Networking für neue Deployments funktioniert. Bisher hat Azure jeder VM in einem VNet automatisch ausgehenden Internetzugang über eine ephemere Public IP bereitgestellt. Dieses Verhalten war bequem, aber aus Security-Sicht problematisch: Keine Kontrolle über Egress-Traffic, kein Logging, keine Möglichkeit zur Filterung.

Ab Ende März 2026 gilt für alle neuen VNets und Ressourcen: Kein expliziter Outbound-Pfad = kein Internet. Die vier offiziell unterstützten Optionen sind Azure NAT Gateway, Azure Firewall, Load Balancer Outbound Rules und Public IPs direkt auf der NIC.

Für Enterprise-Architekturen im DACH-Mittelstand empfiehlt sich eine klare Strategie: NAT Gateway als Standard für unkritische Workloads, Azure Firewall für Szenarien mit URL-Filtering und Threat Intelligence, und Load Balancer Rules dort, wo bereits ein LB im Einsatz ist. Die Kombination aus NAT Gateway und Azure Firewall im Hub-and-Spoke-Modell deckt 90% der Enterprise-Anforderungen ab.

Besonders kritisch: IaC-Templates und Landing Zones. Wer Terraform, Bicep oder ARM Templates nutzt, muss jeden Template-Satz auf implizite Outbound-Abhängigkeiten prüfen. Custom Script Extensions, Cloud-Init-Skripte und Post-Deployment-Konfigurationen, die Pakete aus dem Internet laden, werden ohne expliziten Egress scheitern.

Die Empfehlung: Sofort alle Landing Zone-Definitionen und IaC-Module auditieren. NAT Gateway als Minimum in jede VNet-Definition einbauen. Bestehende VNets sind vorerst nicht betroffen – aber der Zeitpunkt für die Migration ist jetzt, nicht wenn Microsoft den Scope erweitert.

Vollständiger Artikel folgt auf rayscloudblog.com

Eine Maßnahme für diese Woche:

Outbound-Konnektivität aller Landing Zones prüfen: Die Default Outbound Removal kommt Ende März – und betrifft alle neuen Deployments. Prüfe jetzt deine IaC-Templates:

bash

# Alle VNets ohne NAT Gateway auflisten
az graph query -q "Resources | where type == 'microsoft.network/virtualnetworks' | where isnull(properties.subnets[0].properties.natGateway) | project name, resourceGroup, location" --first 100

Falls VNets ohne NAT Gateway oder andere explizite Outbound-Lösung auftauchen: Jetzt NAT Gateway einplanen, nicht erst wenn neue Deployments fehlschlagen.