Zero Trust mit Azure Firewall, DDoS Protection und WAF

Zero Trust ist einer der meiststrapazierten Begriffe in der IT. Jeder Hersteller behauptet, sein Produkt sei „Zero Trust-ready". Jedes Sicherheitsrahmenwerk referenziert es. Und doch: Für ein Unternehmen, das Zero Trust tatsächlich in Azure umsetzen möchte, bleibt die Frage, welche Dienste man wählt, in welcher Reihenfolge und mit welcher Konfiguration — selten klar beantwortet.

Dieser Beitrag behandelt drei konkrete Azure-Dienste — Azure Firewall, Azure DDoS Protection und Azure Web Application Firewall — und wie sie zusammenwirken, um eine echte mehrschichtige Verteidigung aufzubauen. Das ist der Kern dessen, was wir in unserer Cloud-Security-Praxis liefern. Nicht in der Theorie, sondern in der Praxis — mit realen Angriffsszenarien und Konfigurationshinweisen, die für Unternehmen in Deutschland und der EU relevant sind.

Was Zero Trust auf Netzwerkebene konkret erfordert

Das Zero-Trust-Modell, ursprünglich von John Kindervag bei Forrester Research formuliert, geht von einer einzigen Annahme aus: Der Netzwerkperimeter existiert nicht. Jedes Gerät, in jedem Netzwerk, könnte kompromittiert sein. Daher muss jede Zugriffsanfrage verifiziert werden — kein Traffic darf allein deshalb als vertrauenswürdig gelten, weil er aus dem eigenen Netz stammt.

Auf Netzwerkebene bedeutet das drei konkrete Anforderungen:

1. Gesamten Traffic inspizieren — auch den zwischen internen Diensten, nicht nur eingehenden Internet-Traffic.
2. Least-Privilege-Zugriff auf Netzwerkebene durchsetzen — eine kompromittierte VM in einem Subnetz soll nicht frei mit einer Datenbank in einem anderen kommunizieren können.
3. Breach annehmen — die Architektur so gestalten, dass ein erfolgreicher Einbruch in einer Schicht keinen automatischen Zugriff auf alles andere gewährt.

Hier spielen Azure Firewall, WAF und DDoS Protection jeweils eine spezifische Rolle. Sie sind keine Redundanz — sie operieren auf unterschiedlichen OSI-Schichten und schützen gegen grundlegend verschiedene Angriffsklassen.

Azure DDoS Protection: Schutz am Edge

Ein Distributed-Denial-of-Service-Angriff überflutet Ihre Infrastruktur mit Datenverkehr, dem legitime Nutzer nichts entgegensetzen können. Azure DDoS Protection Network operiert auf den Schichten 3 und 4 — Netzwerk- und Transportschicht — und filtert Angriffs-Traffic, bevor er Ihr Virtual Network erreicht.

Azure stellt allen Kunden kostenlos einen grundlegenden DDoS-Schutz bereit. Der Standard-Tier (jetzt Teil von Azure DDoS Protection) ergänzt adaptives Tuning: Das System lernt die normalen Traffic-Muster Ihrer Anwendung und passt die Mitigation-Schwellenwerte automatisch an. Er liefert außerdem Angriffs-Telemetrie und Post-Angriffs-Berichte, die für die Vorfallsdokumentation nützlich sind.

Für die meisten DACH-Unternehmen ist die Frage, ob Standard notwendig ist. Die Antwort hängt davon ab, was Sie öffentlich exponieren. Wenn Sie öffentlich zugängliche Webanwendungen, APIs oder Kundenportale in Azure betreiben, lohnt sich Standard. Die Kosten sind erheblich — etwa 2.500 € pro Monat für die ersten 100 geschützten Ressourcen — und müssen gegen das tatsächliche Risikoprofil Ihrer Anwendungen abgewogen werden. Die meisten kleinen Unternehmen brauchen DDoS Standard nicht; die Kombination aus WAF und Firewall deckt den Großteil der Risiken bereits ab. DDoS Standard wird relevant, wenn Sie etwas betreiben, das unter einem anhaltenden volumetrischen Angriff tatsächlich ausfallen würde und sich diese Ausfallzeit nicht leisten kann.

Azure Web Application Firewall: Schutz Ihrer Anwendungen auf Schicht 7

Die WAF operiert auf der Anwendungsschicht — Schicht 7 — und inspiziert den Inhalt von HTTP- und HTTPS-Anfragen, nicht nur IP-Adressen und Ports. Sie sitzt vor Ihren Webanwendungen via Azure Application Gateway oder Azure Front Door und blockiert Angriffe, die eine Netzwerk-Firewall schlicht nicht erkennen kann.

Was die WAF blockiert

• SQL Injection: Ein Angreifer hängt SQL-Syntax an ein Formularfeld oder einen URL-Parameter an, um Ihre Datenbank zu manipulieren. Die WAF erkennt das Payload-Muster und blockiert die Anfrage, bevor sie die Anwendung erreicht.
• Cross-Site Scripting (XSS): Schadhafte Scripts, die in Ihre Webseiten eingeschleust werden, um Session-Tokens zu stehlen oder Nutzer auf Phishing-Seiten umzuleiten.
• Remote File Inclusion und Path Traversal: Angriffe, die versuchen, auf Dateien außerhalb des Web-Roots zuzugreifen — ein häufiger Angriffsvektor gegen PHP-Anwendungen und Content-Management-Systeme.
• Bot-Traffic: Azure WAF enthält Bot-Management-Regeln, die zwischen legitimen Crawlern (z. B. Googlebot) und bösartigen Scrapern oder Credential-Stuffing-Bots unterscheiden.

Core Rule Sets und benutzerdefinierte Regeln

Azure WAF verwendet das OWASP Core Rule Set (CRS) als Grundlage. Der aktuelle Standard ist CRS 3.2, das direkt den OWASP Top 10-Schwachstellen entspricht. Sie können die WAF zunächst im Erkennungsmodus betreiben — Regelübereinstimmungen werden protokolliert, ohne zu blockieren — um False Positives zu identifizieren, bevor Sie auf den Präventionsmodus umschalten.

Benutzerdefinierte Regeln ermöglichen geschäftsspezifische Logik: Anfragen aus bestimmten geografischen Regionen blockieren, bestimmte Header voraussetzen oder aggressive IPs rate-limitieren. Für eine deutsche B2B-Anwendung, die keinen legitimen Grund hat, Traffic aus bestimmten Regionen zu empfangen, ist Geo-Blocking via WAF-Regeln eine effektive erste Verteidigungslinie.

Azure Firewall Premium: Deep Inspection und ausgehende Kontrolle

Azure Firewall ist der zentrale Inspektionspunkt für den gesamten Traffic, der durch Ihr Virtual Network fließt. Der Premium-Tier ergänzt Fähigkeiten, die für eine echte Zero-Trust-Implementierung notwendig sind:

• TLS-Inspektion: Entschlüsselt ausgehenden HTTPS-Traffic, um ihn auf Malware und Datenexfiltration zu prüfen, bevor er wieder verschlüsselt wird. Ohne das umgeht verschlüsselter Traffic jede Inhaltsinspektion.
• IDPS (Intrusion Detection and Prevention System): Verwendet Microsofts Threat-Intelligence-Feed, um bekannte bösartige Muster im Netzwerkverkehr zu erkennen und zu blockieren — einschließlich Command-and-Control-Traffic von Malware, die bereits an der Endpunkt-Abwehr vorbeigekommen ist.
• URL-Filterung: Blockiert den Zugriff auf bekannte bösartige Seiten und ermöglicht einen Allowlist-Ansatz für ausgehenden Web-Zugriff von Servern.
• East-West-Traffic-Kontrolle: Setzt Segmentierung zwischen Subnetzen durch. Ein kompromittierter Anwendungsserver kann Ihr Datenbank-Subnetz nicht erreichen, solange das nicht explizit durch eine Firewall-Regel erlaubt ist.

BSI IT-Grundschutz-Ausrichtung

Der BSI IT-Grundschutz-Baustein NET.3.2 (Firewall) und NET.3.4 (Netztrennung) gelten beide für Azure-Firewall-Deployments. Konkret verlangt NET.3.2.A1, dass Firewall-Regeln dem Prinzip der minimalen Kommunikation folgen — nur explizit erlaubter Traffic soll fließen. Der Default-Deny-Ansatz von Azure Firewall erfüllt diese Anforderung, aber die Regelbasis muss so gestaltet und dokumentiert werden, dass die Compliance nachgewiesen werden kann. Die Verwendung von Azure Firewall Policy und Azure Policy-Zuweisungen liefert den Audit-Trail, den das BSI erwartet.

Wie die drei Dienste zusammenwirken: eine Referenzarchitektur

Eine vollständige Azure-Netzwerksicherheitsarchitektur positioniert diese Dienste in einer bestimmten Reihenfolge:

1. Eingehender Internet-Traffic wird zunächst von Azure DDoS Protection auf Virtual-Network-Ebene verarbeitet — volumetrische Angriffe werden abgefangen, bevor sie irgendeinen Dienst erreichen.
2. HTTP/HTTPS-Anwendungs-Traffic trifft dann auf Azure Application Gateway mit aktivierter WAF — SQL-Injection, XSS und Bot-Traffic werden auf Schicht 7 blockiert.
3. Der gesamte restliche Traffic — einschließlich ausgehendem Traffic von VMs und East-West-Traffic zwischen Subnetzen — wird von Azure Firewall Premium inspiziert, das Segmentierung durchsetzt, bekannte bösartige IPs blockiert und verschlüsselten ausgehenden Traffic inspiziert.

Das ist die Hub-and-Spoke- oder Azure Virtual WAN-Topologie, die Microsoft für Enterprise-Azure-Deployments empfiehlt. Die Firewall sitzt in einem zentralen Hub-Virtual-Network, und alle Spoke-VNets leiten ihren Traffic darüber. So erhalten Sie eine zentral protokollierte und zentral durchgesetzte Netzwerksicherheitsrichtlinie — statt Sicherheitsgruppen, die über jedes einzelne Subnetz verteilt verwaltet werden.