Azure Firewall für kleine Unternehmen Berlin: Netzwerksicherheit in Azure Virtual Networks

Jedes Azure-Workload, das eine Verbindung zum Internet herstellt oder zwischen virtuellen Netzwerken kommuniziert, benötigt eine definierte Netzwerkgrenze. Azure Firewall ist Microsofts verwalteter, cloudnativer Netzwerksicherheitsdienst, der den gesamten ein- und ausgehenden Datenverkehr in Ihren Azure Virtual Networks (VNets) filtert und protokolliert — ohne dass Sie zugrunde liegende Firewall-Appliances verwalten oder Betriebssysteme patchen müssen.

Für kleine und mittelständische Unternehmen in Berlin, die Workloads in Azure betreiben — ob virtuelle Maschinen, App Services, Azure Virtual Desktop oder Hybridkonnektivität über ExpressRoute — bietet Azure Firewall eine zentrale Verkehrskontrolle mit integrierter Hochverfügbarkeit und automatischer Skalierung. Dieser Beitrag erläutert Architektur, Regelkonfiguration, Sicherheitsfunktionen und die Integration mit Microsoft Defender for Cloud und Azure Policy.

Was Azure Firewall leistet

Azure Firewall ist eine statusbehaftete, vollständig verwaltete Firewall-as-a-Service, die innerhalb Ihres Azure VNet bereitgestellt wird. Der gesamte Datenverkehr zu und von Ihren Subnetzen wird über benutzerdefinierte Routen (UDR) durch die Firewall geleitet, die Regeln in einer definierten Prioritätsreihenfolge anwendet, bevor Verbindungen erlaubt oder abgelehnt werden.

Zu den wichtigsten Fähigkeiten gehören: Netzwerkregeln (Layer 3/4 IP- und Portfilterung), Anwendungsregeln (Layer 7 FQDN- und Protokollfilterung), NAT-Regeln (DNAT für eingehenden Verkehr), bedrohungsbasierte Filterung (Microsoft Threat Intelligence-Feed), DNS-Proxy und TLS-Inspektion (Standard- und Premium-SKU).

Azure Firewall SKU-Vergleich

Funktion	Basic	Standard	Premium
Netzwerkregeln (L3/L4)	✓	✓	✓
Anwendungsregeln (L7 FQDN)	✓	✓	✓
Threat Intelligence-Filterung	Nur Warnung	Warnung + Ablehnen	Warnung + Ablehnen
DNS-Proxy	✗	✓	✓
IDPS (Einbruchserkennung)	✗	✗	✓
TLS-Inspektion	✗	✗	✓
URL-Kategoriefilterung	✗	✗	✓
Typische Monatskosten (2 AZs)	~100 €	~250 €	~450 €

Für die meisten Berliner KMU bietet die Standard-SKU die richtige Balance: vollständige Anwendungsschicht-Filterung, Threat Intelligence im Deny-Modus, DNS-Proxy und strukturierte Firewall-Protokolle — zu vorhersehbaren Monatskosten.

Hub-and-Spoke-Architektur

Azure Firewall wird typischerweise in einem Hub-VNet in einer Hub-and-Spoke-Topologie bereitgestellt. Der Hub enthält gemeinsam genutzte Dienste — Firewall, VPN-Gateway oder ExpressRoute, Azure Bastion — während Spoke-VNets die Workloads enthalten. VNet-Peering verbindet Spokes mit dem Hub, und benutzerdefinierte Routen zwingen den gesamten Spoke-zu-Internet- und Spoke-zu-Spoke-Verkehr durch die Firewall.

Dieses Design gewährleistet eine zentrale Verkehrsinspektion und -protokollierung, unabhängig davon, welches Spoke-VNet die Verbindung initiiert. Azure Firewall Manager erweitert dieses Modell, um Richtlinien über mehrere Firewalls und Secured Virtual Hubs (Azure Virtual WAN-Integration) zu verwalten.

Kernkomponenten der Bereitstellung

• AzureFirewallSubnet: Dediziertes /26-Subnetz oder größer im Hub-VNet — reservierter Name, kann nicht geändert werden
• öffentliche IP: Eine oder mehrere Standard-SKU-Static-Public-IPs, die der Firewall für SNAT und DNAT zugewiesen sind
• Firewall-Richtlinie: Separate ARM-Ressource, die alle Regeln enthält — kann über Firewalls hinweg geteilt werden und erbt von übergeordneten Richtlinien
• Routingtabellen (UDR): 0.0.0.0/0 Next-Hop auf die private Firewall-IP aller Spoke-Subnetze gesetzt — erzwingt Verkehrsinspektion
• Diagnoseeinstellungen: Firewall-Protokolle an Log Analytics weiterleiten für KQL-basierte Analyse und Microsoft Sentinel-Einspeisung

Regeltypen und Priorität

Azure Firewall verarbeitet Regeln in strenger Prioritätsreihenfolge: NAT-Regeln → Netzwerkregeln → Anwendungsregeln. Innerhalb jeder Sammlung werden niedrigere Prioritätsnummern zuerst ausgewertet. Regeln sind in Regelsammlungen innerhalb einer Firewall-Richtlinie gruppiert, und Sammlungen sind in Regelsammlungsgruppen zusammengefasst.

Anwendungsregeln — FQDN-Filterung

Anwendungsregeln untersuchen HTTP/HTTPS/MSSQL-Verkehr auf Layer 7 und erlauben oder verweigern Verbindungen basierend auf vollständigen Domännamen. Beispiel: Datenverkehr von einem Spoke-Subnetz zu *.microsoft.com, *.windowsupdate.com und *.azure.com erlauben, während alle anderen internet-gebundenen HTTP/HTTPS-Verbindungen abgelehnt werden. Mit Premium-SKU entschlüsselt die TLS-Inspektion HTTPS, um den vollständigen Anforderungs-URI zu inspizieren.

FQDN-Tags vereinfachen die Allowlist gängiger Microsoft-Dienste — Tags wie WindowsUpdate, WindowsDiagnostics und MicrosoftActiveProtectionService lösen alle erforderlichen Endpunkte automatisch auf und werden aktualisiert, wenn Microsoft seine Dienst-IPs ändert.

Netzwerkregeln — IP- und Portfilterung

Netzwerkregeln arbeiten auf Layer 3/4 und filtern basierend auf Quell-/Ziel-IP, Protokoll (TCP/UDP/ICMP/Any) und Port. Verwenden Sie Netzwerkregeln für Nicht-HTTP-Verkehr: On-Premises-zu-Azure-RDP/SSH (ergänzend zu Azure Bastion für die Verwaltung), Spoke-zu-Spoke-Datenbankverbindungen oder DNS-Weiterleitung. Netzwerkregeln unterstützen IP-Gruppen — logische Gruppierungen von IP-Bereichen, die die Regelverwaltung über mehrere Regelsammlungen hinweg vereinfachen.

Threat Intelligence und DNS-Proxy

Die Threat Intelligence-Filterung verwendet Microsofts kontinuierlich aktualisiertem Feed bekannter bösartiger IPs und FQDNs. Im Warnung + Ablehnen-Modus (Standard und Premium) werden Verbindungen zu bekannten bösartigen Zielen blockiert, bevor eine andere Regel ausgewertet wird, und mit Bedrohungskategorie, Quelle und Ziel protokolliert. Dies bietet Schutz ohne Konfigurationsaufwand gegen Command-and-Control-Verkehr, Botnet-Rückrufverbindungen und Verbindungen zu bekannten Malware-Verteilungspunkten.

Der DNS-Proxy-Funktion ermöglicht es Azure Firewall, als DNS-Resolver für VNet-Ressourcen zu fungieren, und leitet Abfragen an Azure DNS oder benutzerdefinierte DNS-Server weiter. Die Aktivierung des DNS-Proxys ist eine Voraussetzung für die FQDN-basierte Filterung in Netzwerkregeln und zentralisiert die DNS-Abfrageprotokollierung — alle DNS-Anfragen von VNet-Ressourcen erscheinen in den Firewall-Diagnoseprotokollen.

Integration mit Defender for Cloud und Azure Policy

Microsoft Defender for Cloud enthält Empfehlungen für die Azure Firewall-Bereitstellung — insbesondere werden Subnetze markiert, die Internetverkehr ohne Firewall-Schutz weiterleiten. Der Microsoft Cloud Security Benchmark (MCSB) ordnet sich direkt den integrierten Azure Policy-Initiativen zu, und die Empfehlung „Azure Firewall sollte in VNets bereitgestellt werden“ erscheint automatisch in Defender for Cloud, wenn Workloads ohne zentrale Netzwerkfilterung vorhanden sind.

Azure Policy kann die Firewall-Richtlinienvererbung über Abonnements hinweg durchsetzen — beispielsweise durch eine DeployIfNotExists-Richtlinie, die sicherstellt, dass alle neuen VNets eine UDR haben, die 0.0.0.0/0 zur zentralen Firewall weiterleitet.

Protokollierung und Überwachung

Azure Firewall generiert strukturierte Protokolle über Azure Monitor-Diagnoseeinstellungen. Leiten Sie Protokolle an einen Log Analytics-Arbeitsbereich weiter und analysieren Sie mit KQL:

// Top abgelehnte Anwendungsregelaufrufe in den letzten 24 Stunden
AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| where msg_s contains "Deny"
| summarize Anzahl = count() by Fqdn = extract(@"Fqdn: ([^,]+)", 1, msg_s)
| top 20 by Anzahl

Für Threat Intelligence-Warnungen zeigen die Protokollkategorien AzureFirewallNetworkRule und AzureFirewallThreatIntel blockierte Verbindungen mit Bedrohungskategorie-Klassifizierung. Der Azure Firewall-Connector von Microsoft Sentinel nimmt diese Protokolle für die SIEM-Korrelation auf — und verbindet Firewall-Ablehnungen mit Identitätsereignissen, Endpunktwarnungen und anderen Signalen in einer einheitlichen Incident-Zeitleiste.

Praktische Bereitstellungsschritte für ein Berliner KMU

1. Hub-VNet mit AzureFirewallSubnet erstellen: Mindestens /26 — größer, wenn Sie auf mehrere Firewall-Instanzen skalieren oder Firewall Manager-verwaltete Richtlinien hinzufügen möchten
2. Azure Firewall bereitstellen (Standard-SKU): Standard-SKU-öffentliche IP zuweisen; DNS-Proxy aktivieren; Firewall-Richtlinie auswählen oder erstellen
3. Firewall-Richtlinie mit Basisregeln erstellen: FQDN-Tags erlauben (WindowsUpdate, MicrosoftActiveProtectionService), Azure-Verwaltungs-FQDNs erlauben (*.azure.com, *.microsoft.com), alle anderen Internet-HTTP/HTTPS via Anwendungsregeln ablehnen
4. Threat Intelligence im Modus Warnung + Ablehnen aktivieren: Automatischer Schutz vor bekannten bösartigen IPs/FQDNs ohne Regelkonfigurationsaufwand
5. UDRs auf Spoke-Subnetzen konfigurieren: 0.0.0.0/0 → private Firewall-IP; BGP-Propagierung in der Spoke-Routingtabelle deaktivieren
6. Diagnoseprotokolle an Log Analytics weiterleiten: Kategorien AzureFirewallApplicationRule, AzureFirewallNetworkRule, AzureFirewallThreatIntel und AzureFirewallDNSProxy aktivieren
7. Verbindung zu Microsoft Sentinel herstellen: Azure Firewall-Datenkonnektor in Sentinel aktivieren für signalübergreifende Korrelation mit Entra ID, MDE und MDI-Warnungen

Azure Firewall vs. Netzwerksicherheitsgruppen (NSG)

NSGs arbeiten auf Subnetz- und NIC-Ebene und bieten grundlegende Layer-4-Zulassungs-/Ablehnungsregeln. Azure Firewall arbeitet zentral über die gesamte VNet-Topologie und fügt Layer-7-Anwendungsfilterung, FQDN-Auflösung, Threat Intelligence und zentrale Protokollierung hinzu. Beide ergänzen sich: NSGs bieten Defense-in-Depth auf Ressourcenebene (laterale Bewegung zwischen Subnetzen verhindern), während Azure Firewall Nord-Süd-Verkehr kontrolliert und eine zentrale Egress-Richtlinie durchsetzt. Für regulierte Workloads oder jede Umgebung mit mehreren VNets ist die Verwendung beider Komponenten die empfohlene Architektur.

IT Experts Berlin entwirft und implementiert Azure Firewall-Richtlinien für Berliner KMU, die Workloads nach Azure verlagern — einschließlich Hub-and-Spoke-VNet-Architektur, Firewall Policy Regelerstellung, Log Analytics-Integration und Microsoft Sentinel-Anbindung. Kontaktieren Sie uns, um Ihre Netzwerksicherheitsanforderungen zu besprechen.