Azure Firewall Teil 1: Grundlagen und Einsatzzweck

Im Rahmen der Netzwerksicherheit von Azure stoßen Cloud-Einsteiger auf zahlreiche Dienste und Features wie Virtuelle Netzwerke, Netzwerksicherheitsgruppen, VNet-Peering, Dienstendpunkte oder die Azure Firewall von denen jede für sich eine Verbesserung des Schutzes deiner Backend-Ressourcen in Azure sowie deiner lokalen Ressourcen darstellt. In ihrer geschickten Kombination erhöhen sich die Sicherheit auf Netzwerkebene sogar drastisch. Dieser Beitrag befasst sich mit den Grundlagen der Azure Firewall. In der Fortsetzung findest du einen Workshop zur Einrichtung eines einfachen Szenarios.  

Du benötigst mehr Know-how rund um MS Azure? Dann empfehlen wir dir unsere Microsoft Azure Schulungen!

Legst du ein neues virtuelles Netzwerk in der Azure Cloud an, ist dieses rein privat und Cloud-Only. Benötigst du Layer-3-Konnektivität zwischen deinem on Premise Standort und einen Azure VNet, musst du dazu eine VPN- oder Express-Route-Verbindung zwischen dem On-Premise-Netzwerk und deinem Azure-Netzwerk und bereitstellen.

Virtuelle Maschinen, die in einen Azure Netzwerk platziert werden können über das implizite Internet-Gateway (Default Gateway) eines jeden Azure-VNets das Internet erreichen. Das ist zunächst eine Frage des Routings. Microsoft nennt das System-Routen. Im Unterschied zu AWS beispielsweise brauchst du dazu bei Azure keine Internet-Gateways, keine Routing-Tabellen und keine Routen anlegen. Ob eine VM tatsächlich mit dem Internet kommunizieren kann, hängt aber auch von anderen Dingen ab. So muss eine VM über eine öffentliche IP-Adresse verfügen und die Netzwerkkarte der VM oder das Subnetz, in dem sie steht, muss eine Netzwerksicherheitsgruppe (NSG) zugeordnet haben, welche die benötigten Ports/Protokolle öffnet. So eine Netzwerksicherheitsgruppe ist faktisch ein Paketfilter, vergleichbar mit Linux IP Tables und arbeitet ausschließlich auf OSI-Layer 3 / 4, d. h. du wählst Port und Protokoll für Quelle und Ziel, wobei Quelle und Ziel IP-Adressen, IP-Adresse-Bereiche oder Dienst-Tags wie „Internet“ oder „Virtual Appliance“ sein können. Außerdem gibt es wie beim Linux-Kernel Allow- und Deny-Regeln, eine Regel-Reihenfolge, die sich durch die Priorität ergibt und Stateful Inspection, d. h. für Eingangs-Datenverkehr, der bereits „related“ oder „established“ ist, musst du keine Ausgangs-Regeln schreiben. Im Zwiebelprinzip von Microsoft Defense-in-Deep-Strategie ist das die Ebene der Netzwerksicherheit.

Azure stellt jede neue VM des Kunden automatisch in ein neues VNet und schließt sie an eine neue erstellte Netzwerksicherheitsgruppe (NSG) an, deren Default-Regeln der VM ausgehende Internet-Kommunikation erlauben. Für eingehende Internet-Kommunikation musst du in der entsprechenden NSG explizite Regeln z. B. für RDP, SSH oder HHTP anlegen. Die Abbildung zeigt so eine Standard-NSG mit den Standard-Regeln (ab 65000) und zwei individuellen Eingangsregeln:

Damit leisten NSGs zwar gute Arbeit – zumal du sie als Einsteiger frei Haus bekommst – aber eben auch nicht mehr, als ein Paketfilter eben leisten kann. Daher bezeichnet man den Linux-Paketfilter in Windows-Kreisen auch nicht als Firewall. Statt nun aber ein Barracuda, Fortinet, Sophos, Palo Alto oder Checkpoint auf einer Azure-VM selbst zu betreiben, mit allem Aufwand, den Infrastructure-as-a-Service mitbringt ….

…, kannst du auch die Azure Firewall als Platform-Service nutzen. Du bekommst dann eine vollständige Stateful-Firewall „as a Service“ mit einer privaten und einer öffentlichen IP-Adresse, die du sowohl in den Firewall-eigenen Regeln, als auch in deinen Routing-Tabellen „behandeln“ kannst. Damit deine Azure-VMs und Netzwerke die Firewall auch verwenden (statt der oben skizierten System-Routen) musst du eine benutzerdefinierte Routing-Tabelle schreiben und deine zu schützenden Netzwerken zuordnen.  

Was ist Azure Firewall?

Die Azure Firewall ist in Microsofts Layers-of-Defence auf der Perimeter-Ebene angesiedelt. Microsoft bietet die Azure Firewall in zwei SKUs Standard und Premium an. Der Preis für die Standardversion liegt zwar bei 1,25 $ pro Stunde zzgl. $0,016 pro verarbeitetem GB, was sich in etwa auf 1000 $/Monat für den reinen Betrieb beläuft, allerdings bekommst du Skalierbarkeit und hohe Verfügbarkeit frei Haus. Willst du ein Spohos auf VMs mit vergleichbarer Verfügbarkeit betreiben, brauchst du mindestens zwei VMs, einen Loadbalancer, die Software-Lizenzen und du musst die Maschinen selbst warten.

Im Gegensatz zu den oben skizzierten Netzwerksicherheitsgruppen bietet die Azure Firewall nicht nur Filterregeln für den Netzwerkdatenverkehr, sondern auch FQDN-Anwendungsfilterregeln, SNAT-Unterstützung für ausgehenden Datenverkehr, DNAT-Unterstützung für eingehenden Datenverkehr, uneingeschränkte Cloudskalierbarkeit, verfügt über eine eingebaute Bedrohungsanalyse und lässt sich zonenredundant betreiben. Außerdem protokolliert Azure alles, was „in“, bzw. „über“ die Firewall passiert im Azure Monitor. Weitere Features findest du in der https://docs.microsoft.com/de-de/azure/firewall/features Dokumentation.

Damit mehrere Azure-Netzwerke (und ggf. auch On-Premise-Standorte) die Dienste der Firewall gemeinsam nutzen können, betreibt man die Azure Firewall üblicherweise in einer Hub-&-Spoke-Architektur. Das Azure Architektur Zentrum liefert passende https://docs.microsoft.com/de-de/azure/architecture/reference-architectures/hybrid-networking/hub-spoke?tabs=cli Referenzarchitekturen.

Du kannst dich für einen ersten Test aber auch mit nur einem VNet (Workload-Vnet) und einer VM darin begnügen. Dazu kommt noch das Firewall-VNet, welches per Peering mit dem Workload-VNet verbunden sein soll. Sind Netzwerk- und Peering-Verbindungen eingerichtet, implementierst du die Azure-Firewall. Wie das funktioniert zeigen wir dir im Folgebeitrag.