Gesicherter Durchgang

von Dr. Guido Söldner Dr. Constantin Söldner

Eine Alternative zum lokalen Betrieb eines Loadbalancers sind gemanagte Angebote in der Public Cloud. Diese decken bereits viele typische Anforderungen hinsichtlich Hochverfügbarkeit, Skalierbarkeit, aber auch Security ab. Solche Dienste bringen zwar häufig nicht den kompletten Funktionsumfang wie etwa F5 Big-IP oder Citrix Netscaler mit, bestechen aber durch ihre Einfachheit beim Aufsetzen und im Betrieb. In der Azure-Cloud bietet Microsoft als Layer-7-Loadbalancer das Azure Application Gateway an.

Loadbalancer sind ein zentraler Baustein für das Betreiben von Web-applikationen – sowohl für VM- als auch containerbasierte Anwendungen. Allerdings stellt deren klassische Ausprägung IT-Verantwortliche vor einige Herausforderungen, insbesondere was den Betrieb, aber auch das benötigte Know-how angeht. Soll die Anwendung beispielsweise Anforderungen hinsichtlich Hochverfügbarkeit und Skalierbarkeit erfüllen, müssen einige Voraussetzungen gegeben sein: Je nach Kritikalität sind mehrere Rechenzentren, aber auch Management- sowie Monitoringwerkzeuge erforderlich.

Für das Hosting von Webapplikationen kommt typischerweise ein Layer-7-Loadbalancer zum Einsatz, der auf HTTP-Ebene arbeitet. Diese Technologie unterliegt aber ebenso den eben geschilderten Herausforderungen. Doch in Azure will Microsoft dies mit dem Azure Application Gateway (AAG) vereinfachen – dazu gleich mehr. Um Verwechslungen auszuschließen, hier alle Lastverteiler in Azure:

- Azure Loadbalancer: ein Layer-4 Dienst, der auf TCP/UDP-Basis arbeitet.

- Azure Front Door: globaler Layer-7-Loadbalancer, der insbesondere für User aus unterschiedlichen geographischen Regionen geeignet ist.

- Azure Traffic Manager: ein DNS-basierter Dienst, der Nutzer anhand der Latenz, des Standorts sowie weiteren Kriterien auf ein bestimmtes Backend leitet.

Architekur des Azure Application Gateway

Das Azure Application Gateway ist Microsofts Standard für das Layer-7-Loadbalancing und unterstützt die Protokolle HTTP, HTTPS sowie HTTP/2. Der Anbieter positioniert AAG aber auch als Application Delivery Controller, da es auch Sicherheitsfunktionen wie etwa den Schutz vor DDoS-Angriffen bietet. Um die Funktionsweise des AAG aufzuzeigen, gehen wir im Folgenden auf die einzelnen Komponenten ein, die in Bild 1 dargestellt sind.

Die "Frontend IP" ist, wie der Name schon sagt, die IP-Adresse auf der das Application Gateway auf eingehende Anfragen hört. Je nach Anwendungsfall lässt sich eine öffentliche sowie eine private IP-Adresse oder auch nur eine öffentliche IP-Adresse konfigurieren. Insgesamt steht pro AAG jedoch nur jeweils eine private und eine öffentliche IP-Adresse zur Verfügung.

Ein Listener horcht auf eingehende Verbindungen für eine bestimmte Kombination aus Port, Protokoll, Hostname und IP-Adresse. Der Admin kann dabei zwischen dem "Basic" und dem "Multi-Site"-Listener wählen. Während beim Einsatz der Basic-Variante nur eine Anwendung pro Port unterstützt ist, erlaubt der Multi-Site-Listener auf einem Port mehrere Webapplikationen mit unterschiedlichen Hostnamen zu bedienen. Soll der Listener auf HTTPS horchen, ist ein SSL-Zertifikat erforderlich.

Die "Request Routing Rules" bestimmen, zu welchem Backend-Pool Anfragen geroutet werden. Dies verknüpft eine bestimmte Webapplikation mit einem bestimmten Backend. In Sachen "Backend- Pools" unterstützt AAG sowohl Backends in der Azure Cloud als auch lokale. Der IT-Verantwortliche kann dazu als Backend sowohl Azure-NICs als auch öffentliche und interne IP-Adressen angeben. Backends können physische und virtuelle Maschinen, aber auch Container sein. Zusätzlich werden auch "Azure Scale Sets" sowie Managed Services wie Azure App Service unterstützt. In Sachen "Ports" stehen für das Frontend theoretisch alle Ports zwischen 1 und 64.999 mit Ausnahme von Port 22 (SSH) zur Verfügung.

Die "HTTP Settings" sind Teil der "Request Routing Rule" und spezifizieren die Verbindungsdetails zu den Backend-Systemen. Dazu gehören der zu verwendende Backend-Port, das eingesetzte Protokoll (HTTP oder HTTPS), aber auch Einstellungen zum Connection Draining sowie für Health Checks der Backend-Systeme. Connection Draining erlaubt es, eine Backend-Instanz so als Loadbalancing-Ziel zu entfernen, dass es noch bestehende Verbindungen abarbeiten kann.

Die "Custom Probes" sind benutzerdefinierte Health Checks, die das Application Gateway gegen die Backend-Instanzen durchführt. Um eine solche Instanz als funktionsfähig einzustufen, schickt ein Health Check regelmäßige Anfragen an eine vom Nutzer angegebene URL und überwacht, ob die Backend-Instanz die erwartete HTTP-Antwort schickt (zum Beispiel einen Statuscode von 200 oder eine bestimmte Zeichenfolge im Response Body).

Anwendungen anbinden

Um mehrere Anwendungen zu hosten, müssen Sie nicht mehrere Application Gateways bereitstellen, sondern können mehrere Anwendungen hinter einem AAG platzieren. Dies ist insbesondere für Microservice-basierte Architekturen relevant, die Anwendungsbestandteile auf verschiedene Services aufteilen. In diesem Fall kommt häufig das URL-basierte Routing zum Einsatz, bei dem sich anhand der URL entscheidet, von welchem Backend eine Anfrage verarbeitet wird.

Neben dem Routing anhand der URL können Routing-Entscheidungen aber auch anhand des Host-Namens getroffen werden. Um mehrere Domains hinter der gleichen Port-Nummer zu hosten, müssen Sie zwei Multiple-Site-Listener konfigurieren. In diesem Fall werden beide URLs zwar auf die gleiche IP-Adresse aufgelöst, das Application Gateway kann diese aber anhand des Host-Headers unterscheiden.

Hochverfügbarkeit und Skalierbarkeit

Ein wichtiger Aspekt für das Hosting von geschäftskritischen Anwendungen ist die Hochverfügbarkeit sowie die Skalierbarkeit des Loadbalancers. Da das Azure Application Gateway ein gemanagter Service ist, müssen Sie sich nicht darum sorgen, dass genügend Instanzen zur Verfügung stehen. Azure macht es Ihnen hier ziemlich einfach: Sie müssen nur die Anzahl der AAG-Instanzen sowie deren Availability Zones (AZ) festlegen. Eine Availability Zone entspricht einem Rechenzentrumsstandort von Azure, der von anderen Availability Zones isoliert ist. Die Azure-Region "Germany West Central (Frankfurt)" besteht aus aktuell drei solcher Zonen, für ein AAP sind demnach Instanzen in bis zu drei verschiedenen Standorten verfügbar. Für Anwendung ohne besondere Hochverfügbarkeitsanforderungen ist es aber auch möglich, das AAG nur in einer einzigen AZ zu betreiben.

Insgesamt erlaubt ein AAG bis zu 125 Instanzen, was für eine einzige Webapplikation in den allermeisten Fällen aber wohl überdimensioniert wäre. Dieses hohe Limit ist dann auch dafür gedacht, mehrere Anwendungen hinter einem AAG bereitzustellen (Multiple-Site-Hosting) Sollte eine Instanz ausfallen, sorgt Azure automatisch für Ersatz. Azure kümmert sich außerdem darum, dass die einzelnen Instanzen in verschiedenen Fault- sowie Update-Domains beheimatet sind.

Azure nimmt sich auch der Skalierung des Application Gateways an. Sie können dazu Autoscaling aktivieren, bei dem Azure je nach Auslastung weitere AAG-Instanzen bereitstellt (oder auch wieder löscht). Wie beim klassischen Autoscaling von virtuellen Maschinen konfigurieren Sie hierbei eine "Minimum Capacity" sowie eine "Maximum Capacity", also die minimale und maximale Anzahl der Loadbalancer-Instanzen. Innerhalb dieser Grenzen skaliert Azure automatisch hoch oder runter. Dies ermöglicht es, auf hohe Ressourcenbedarfe (Peaks) zu reagieren, aber gleichzeitig Kosten zu sparen, wenn weniger Kapazität erforderlich ist.

Zu einem ganzheitlichen Scaling-Konzept gehört allerdings nicht nur die Loadbalancing-Schicht, sondern auch die Backends. Viele Backend-Typen bringen schon von Haus aus Skalierungsmechanismen mit, bei anderen müssen Sie sich selbst darum kümmern. Der Standard-Mechanismus zum Skalieren von virtuellen Maschinen in Azure ist das sogenannte "Virtual Machine Scale Set" (VMSS), das die VMs zum Beispiel in Abhängigkeit einer wählbaren Metrik hoch- oder runterskaliert. Neben dem metrikbasierten Autoscaling kann dieses auch auf einem Zeitplan beruhen (Scheduled Autoscaling) oder beim "Predictive Scaling" auf der Auslastung einer Applikation in der Vergangenheit basieren.

Falls Sie Container in einem Azure Kubernetes-Cluster (AKS) als Backend verwenden, gibt es auch hier die Möglichkeit der Skalierung. Für Container, die auf Kubernetes laufen, können der "Horizontal Pod Autoscaler" beziehungsweise Drittanbieterwerkzeuge wie KEDA eingesetzt werden. Betreiben Sie Webapplikation mithilfe des Azure App Services, kommen Sie ebenfalls in den Genuss von Autoscaling.

Verschlüsselung des Applikationsverkehrs

Eine Standardanforderung für moderne Anwendungen ist die Verschlüsselung des Traffics über SSL/TLS. Da der Aufbau von SSL-Verbindungen einen gewissen Performance-Overhead mit sich bringt, stellt sich die Frage, wer für die SSL-Terminierung verantwortlich sein soll. Grundsätzlich gibt es drei Ansätze:

- Durchgehende Verschlüsselung ohne Terminierung auf dem Loadbalancer: Die Verbindung zwischen dem Client und der Webapplikation ist durchgehend verschlüsselt und wird erst auf dem Webserver terminiert (Passthrough). Diese Variante wird jedoch nicht vom AAG unterstützt, sondern erfordert, dass Sie reguläre Azure-Loadbalancer einsetzen, die auf Layer 4 arbeiten. Ein weiterer Nachteil von Passthrough ist, dass der Loadbalancer die dem HTTP-Request mitgeschickten Header nicht entschlüsseln und daher auch keine Routing-Entscheidungen anhand der Header durchführen kann. Damit kann der Loadbalancer verschiedene Services nicht unterscheiden.

- SSL/TLS-Terminierung auf dem Loadbalancer ohne Re-Encryption: Die Verbindung ist nur zwischen dem Client und dem Loadbalancer verschlüsselt, während diejenige zwischen Lastverteiler und Backend-Instanzen unverschlüsselt bleibt (SSL/TLS-Ter- mination erfolgt auf dem Loadbalancer). Diese Variante ist insbesondere aus Performancesicht sehr günstig, da die Backend-Server sich dann nicht mehr um die SSL/TLS-Terminierung kümmern müssen und sich auf die Auslieferung des Contents konzentrieren können. Dies erfordert das gesonderte Einspielen eines SSL-Zertifikats auf dem Lastverteiler.

- SSL/TLS-Terminierung auf dem Loadbalancer mit Re-Encryption: Die Verbindung zwischen dem Client und dem Loadbalancer ist verschlüsselt und es wird eine neue TLS-Session zwischen dem Loadbalancer und den Backend-Instanzen aufgebaut. Diese Variante bietet erhöhte Sicherheit und ist in bestimmten Branchen auch aus regulatorischen Gesichtspunkten notwendig. In diesem Fall ist ein SSL-Zertifikat sowohl auf dem Loadbalancer als auch auf den Backend-Instanzen vonnöten.

DDOS-Abwehr mit integrierter WAF

Eine immer größere Bedrohung für Webapplikationen, die im Internet erreichbar sind, sind DDoS-Angriffe. Das Ziel solcher Attacken ist, ein System durch eine hohe Anzahl von Anfragen in die Knie zu zwingen, damit es nicht mehr für legitime Aufgaben erreichbar ist. DDoS-Angriffe nehmen in ihrer Anzahl und Größe mit jedem Jahr stark zu, was viele Firmen dazu veranlasst, entsprechende Abwehrmechanismen einzuführen.

Eines der wichtigsten Mittel sind Web Application Firewalls (WAF), die vor Angriffen auf Layer 7 (HTTP) schützen. Eine WAF wehrt dabei typischerweise gängige Bedrohungen wie zum Beispiel SQL-Injection oder Cross-Site Scripting ab. Zusätzlich kann die AAG-WAF über das "IP Reputation Ruleset" auch IP-Adressen blockieren, die bereits häufiger bei Angriffen aufgefallen sind.

Da das Azure Application Gateway vor der eigentlichen Anwendung steht und eingehende Requests zuerst verarbeitet, ist es sinnvoll, dass es auch gleichzeitig als WAF fungiert. Azure hat eine dedizierte WAF im Angebot, die sich mit dem AAG integriert. Dies setzt allerdings voraus, dass Sie beim Anlegen des Application Gateways den Tier "WAF" oder "WAF v2" wählen. Für die zusätzliche WAF-Funktionalität müssen Sie allerdings auch extra zahlen – zu den Kosten kommen wir gleich noch im Detail. Eine WAF benötigt, um Anwendungen schützen zu können, entsprechende Regelsätze, anhand derer sie die eingehenden HTTP-Anfragen analysiert. Azure WAF basiert auf dem "Core Rule Set" (CRS) der OWASP, Sie können aber auch eigene Policies erstellen.

Bei der WAF-Konfiguration haben Sie die Wahl zwischen "Detection Mode" und "Prevention Mode". Beim Detection Mode werden die eingehenden Requests sowie die potenzielle Entscheidung, ob ein Request eine Bedrohung darstellt oder nicht, nur protokolliert, es wird aber keine Anfrage blockiert. Dieser Modus soll beispielsweise sicherzustellen, dass die WAF nicht zu viele False Positives identifiziert, also Anfragen, die als Bedrohung kategorisiert werden, aber dennoch legitim sind. Ist der Prevention Mode aktiv, schickt die WAF eine "403 Unauthorized Access Response", wenn ein Request bedrohlich erscheint und blockiert ihn damit gleichzeitig.

Lastenausgleich in Kubernetes

AAG kann auch eine Lastverteilung auf Containern in Kubernetes (Kubernetes Pods) durchführen. Die dafür notwendige Konfiguration erfolgt allerdings nicht direkt auf dem Gateway, sondern Sie steuern dies durch das Anlegen eines Ingress-Objekts direkt im Kubernetes-Cluster. Ein Ingress ist eine Kubernetes-API-Ressource, die Sie in Form einer YAML-Datei spezifizieren.

Das Ingress-Objekt erzeugen Sie in der Regel mithilfe des Kommandozeilen-Tools "kubectl". Damit der Loadbalancer die im Ingress angegebenen Routen auch übernimmt, ist ein sogenannter Ingress-Controller notwendig – eine Kubernetes-Applikation, die die Kubernetes-API auf das Anlegen eines neuen Ingresses überwacht. Sobald ein neuer Ingress erstellt wird, konfiguriert der Ingress-Controller den Loadbalancer mit den Informationen daraus. Für AAG benötigen Sie als Ingress-Controller den "Application Gateway Ingress Controller" (AGIC). Nutzen Sie den Azure Kubernetes Service, lässt sich der Ingress-Controller über ein Add-on installieren, alternativ ist aber auch die Installation über ein Helm Chart möglich.

Kosten für das Application Gateway

Der Preis für AAG hängt davon ab, ob Sie v1 oder v2 einsetzen. Da v1 allerdings schon als Legacy gilt, betrachten wir hier nur die Kosten für Version 2. Zudem zahlen Sie, wie bereits angesprochen, einen höheren Preis, sofern Sie die WAF-Funktionalität provisionieren. Der Preis setzt sich aus zwei Komponenten zusammen, einem fixen Preis pro Stunde sowie einem variablen Anteil (Capacity Units pro Stunde). Im Falle des App Gateway ohne WAF beträgt der fixe Anteil 0,20 US-Dollar pro Gateway-Stunde, mit WAF kostet die Gateway-Stunde 0,36 Dollar. Pro Capacity Unit sind in der Stunde 0,008 Dollar zu entrichten, mit WAF sind es 0,0144 Dollar pro Stunde.

Die Capacity Units sind etwas komplexer zu berechnen, da sie drei Parameter umfassen: eine Capacity Unit beinhaltet 2500 persistente Verbindungen, 2,22 Mbit/s Durchsatz und eine Compute Unit, die wiederum von weiteren Berechnungsoperationen abhängt. Wird einer dieser drei Parameter überschritten, wird eine weitere Capacity Unit abgerechnet. Anhand des Preismodells zeigt sich, dass es schon etwas Erfahrung benötigt, die Kosten des App Gateways genau abschätzen zu können.

Fazit

Im Vergleich mit anderen Loadbalancern bietet der Azure Application Gateway nicht die gleiche Anzahl der Features und damit an Funktionalität. Haben Sie jedoch keine spezifischen Anforderungen, bekommen Sie mit AAP ein solides Werkzeug der Lastverteilung. Zudem weist AAG eine gute Integration in die Azure-Welt auf – insbesondere bei der Integration mit Azure Monitor. Der große Vorteil des Azure App Gateways ist allerdings, dass es ein gemanagter Dienst ist, Sie müssen also kaum Ressourcen für das Einrichten und den Betrieb einsetzen.