Funktionsweise von Azure Application Gateway
Azure Application Gateway umfasst eine Reihe von Komponenten, die zusammen das sichere Weiterleiten von Anforderungen an einen Pool von Webservern sowie das Durchführen von Lastenausgleichen ermöglichen. Application Gateway umfasst die folgenden Komponenten:
- Front-End-IP-Adresse: Clientanforderungen werden über eine Front-End-IP-Adresse empfangen. Sie können eine Application Gateway-Instanz mit einer öffentlichen IP-Adresse, mit einer privaten IP-Adresse oder mit beidem konfigurieren. Eine Application Gateway-Instanz kann nicht mehr als jeweils eine öffentliche und eine private IP-Adresse umfassen.
- Listener: Application Gateway nutzt mindestens einen Listener zum Empfangen eingehender Anforderungen. Ein Listener empfängt den Datenverkehr auf einer festgelegten Kombination aus Protokoll, Port, Host und IP-Adresse. Jeder Listener leitet Anforderungen an einen Back-End-Pool von Servern gemäß der Routingregeln, die Sie festlegen. Es kann sich um einen Basislistener oder einen Listener für mehrere Standorte handeln. Ein Basislistener leiten Anforderungen lediglich anhand des Pfads in der URL weiter. Listener für mehrere Standorte können Anforderungen auch anhand des Hostnamens in der URL weiterleiten. Listener verarbeiten außerdem TLS-/SSL-Zertifikate zum Schutz Ihrer Anwendung zwischen dem Benutzer und Application Gateway.
- Routingregeln: Eine Routingregel bindet Listener an die Back-End-Pools. Eine Regel legt fest, wie die Elemente für den Hostnamen und den Pfad in der URL einer Anforderung interpretiert werden und leiten die Anforderung an den entsprechenden Back-End-Pool weiter. Routingregeln weisen außerdem zugehörige HTTP-Einstellungen auf. Diese HTTP-Einstellungen geben an, ob (und wie) der Datenverkehr zwischen Application Gateway und den Back-End-Servern verschlüsselt wird. Weitere Konfigurationsinformationen sind Protokoll, Sitzungsbindung, Verbindungsausgleich, Zeitraum für das Anforderungstimeout und Integritätstest.
Lastenausgleich in Application Gateway
Application Gateway führt mithilfe einer Roundrobinstrategie automatisch einen Lastenausgleich für Anforderungen aus, die an die Server in den Back-End-Pools gesendet werden. Der Lastenausgleich nutzt das Routing der OSI-Schicht 7 (Anwendungsschicht), die vom Application Gateway-Routing implementiert wird, d. h., dass der Lastenausgleich für die Anforderungen anhand der Routingparameter (Hostnamen und Pfade) ausgeführt wird, die von Application Gateway-Regeln verwendet werden. Im Gegensatz dazu nutzen andere Lastenausgleiche (z. B. Azure Load Balancer) die OSI-Schicht 4 (Transportschicht) und verteilen den Datenverkehr anhand der IP-Adresse des Anforderungsziels.
Sie können die Sitzungspersistenz konfigurieren, wenn Sie sicherstellen müssen, dass alle Anforderungen für einen Client in der gleichen Sitzung an denselben Server in einem Back-End-Pool weitergeleitet werden.
Web Application Firewall
Die WAF (Web Application Firewall) ist eine optionale Komponente, die eingehende Anforderungen verarbeitet, bevor sie einen Listener erreichen. Die WAF überprüft alle Anforderungen gemäß dem Open Web Application Security Project (OWASP) auf gängige Bedrohungen. Zu gängigen Bedrohungen zählen: Einschleusung von SQL-Befehlen (Injection), Cross-Site Scripting, Einschleusung von Befehlen, HTTP-Anforderungsschmuggel, HTTP-Antwortaufteilung, Remotedateieinschluss, Bots, Crawler und Scanner sowie Manipulationen und Anomalien des HTTP-Protokolls.
Im OWASP ist eine Reihe allgemeiner Regeln für die Erkennung von Angriffen definiert. Diese Regeln werden als CRS (Core Rule Set) bezeichnet. Da solche Angriffe immer komplexer werden, werden diese Regeln ständig überprüft. WAF unterstützt vier Regelsätze: CRS 3.2, 3.1, 3.0 und 2.2.9. CRS 3.1 ist die Standardeinstellung. Bei Bedarf können Sie auch nur spezifische Regeln eines Regelsatzes auswählen, die für bestimmte Bedrohungen konzipiert sind. Darüber hinaus können Sie die Firewall anpassen, um festzulegen, welche Elemente in einer Anforderung überprüft werden sollen, und um die Größe von Nachrichten einzuschränken, um die Überlastung Ihrer Server durch große Uploads zu verhindern.
Back-End-Pools
Ein Back-End-Pool ist eine Sammlung von Webservern, die aus einer festen Gruppe von VMs, einer VM-Skalierungsgruppe, einer von Azure App Services gehosteten App oder einer Sammlung lokaler Server bestehen kann.
Jeder Back-End-Pool verfügt über einen zugehörigen Lastenausgleich, der die Last auf den Pool verteilt. Beim Konfigurieren des Pools geben Sie die IP-Adresse oder den Namen der einzelnen Webserver an. Alle Server im Back-End-Pool sollten auf gleiche Weise konfiguriert sein, einschließlich ihrer Sicherheitseinstellungen.
Bei Verwendung der TLS oder von SSL verfügt der Back-End-Pool über eine HTTP-Einstellung, die auf ein Zertifikat verweist, das zum Authentifizieren der Back-End-Server verwendet wird. Das Gateway verschlüsselt den Datenverkehr mithilfe dieses Zertifikats wieder, bevor er an einen Ihrer Server im Back-End-Pool weitergeleitet wird.
Wenn Sie Azure App Service zum Hosten der Back-End-Anwendung verwenden, müssen Sie keine Zertifikate in Application Gateway installieren, um eine Verbindung mit dem Back-End-Pool herzustellen. Die gesamte Kommunikation wird automatisch verschlüsselt. Application Gateway vertraut den Servern, da sie von Azure verwaltet werden.
Application Gateway verwendet eine Regel zum Festlegen der Weiterleitung der Nachrichten, die über den Eingangsport für die Server im Back-End-Pool empfangen werden. Wenn die Server die TLS- oder SSL-Verschlüsselung verwenden, müssen Sie die Regel konfigurieren, um Folgendes anzugeben:
- Dass Ihre Server Datenverkehr über das HTTPS-Protokoll erwarten.
- Welches Zertifikat zum Verschlüsseln des Datenverkehrs und Authentifizieren der Verbindung mit einem Server verwendet werden soll.
Application Gateway-Routing
Wenn das Gateway eine Clientanforderung an einen Webserver im Back-End-Pool weiterleitet, verwendet es eine Gruppe von Regeln, die für das Gateway konfiguriert sind, um zu bestimmen, wohin die Anforderung gesendet werden soll. Es gibt zwei Hauptmethoden für das Routing des Datenverkehrs für diese Clientanforderung: pfadbasiertes Routing und Routing für mehrere Websites.
Pfadbasiertes Routing
Pfadbasiertes Routing sendet Anforderungen mit unterschiedlichen URL-Pfaden an verschiedene Pools von Back-End-Servern. Zum Beispiel können Sie Anforderungen mit dem Pfad /video/* an einen Back-End-Pool senden, der die Server enthält, die für die Verarbeitung von Videostreaming optimiert sind, und /images/*-Anforderungen an einen Pool von Servern für die Verarbeitung von Bildabrufen weiterleiten.
Routing mehrerer Sites
Das Routing mehrerer Sites ermöglicht es Ihnen, mehrere Web-Apps in derselben Application Gateway-Instanz zu konfigurieren. Bei der Konfiguration für mehrere Websites registrieren Sie mehrere DNS-Namen (CNAMEs) für die IP-Adresse der Application Gateway-Instanz und geben dabei die Namen der aller Websites an. Application Gateway verwendet für jede Website separate Listener, die auf Anforderungen warten. Jeder Listener übergibt die Anforderung an eine andere Regel, die die Anforderungen an Server in einem anderen Back-End-Pool weiterleiten kann. Sie können alle Anforderungen für http://contoso.com beispielsweise an Server in einem Back-End-Pool senden und Anforderungen für http://fabrikam.com an einen anderen Back-End-Pool. Auf der folgenden Abbildung wird diese Konfiguration veranschaulicht:
Konfigurationen mit mehreren Standorten sind für die Unterstützung von Anwendungen mit mehreren Mandanten nützlich, bei denen jeder Mandant über eigene VMs oder andere Ressourcen zum Hosten einer Web-App verfügt.
Das Routing des Anwendungsgateway umfasst auch die folgenden Features:
- Umleitung: Die Umleitung kann zum Umleiten an eine andere Website oder von HTTP an HTTPS verwendet werden.
- Erneutes Generieren von HTTP-Headern: HTTP-Header ermöglichen Client und Server das Übergeben von Parameterinformationen mit der Anforderung oder der Antwort.
- Benutzerdefinierte Fehlerseiten: Mit Application Gateway können Sie benutzerdefinierte Fehlerseiten erstellen, anstatt Standardfehlerseiten anzuzeigen. Sie können für eine benutzerdefinierte Fehlerseite Ihr eigenes Branding und Layout verwenden.
Beendigung der TLS- bzw. SSL-Verbindung
Wenn Sie die TLS- bzw. SSL-Verbindung der Application Gateway-Instanz beenden, werden Ihre Server von der CPU-intensiven TLS- bzw. SSL-Beendigungsworkload entlastet. Außerdem müssen Sie weder Zertifikate installieren noch TLS bzw. SSL für Ihre Server konfigurieren.
Wenn Sie End-to-End-Verschlüsselung benötigen, kann Application Gateway den Datenverkehr des Gateways mithilfe Ihres privaten Schlüssels entschlüsseln und anschließend wieder mit dem öffentlichen Schlüssel des Diensts verschlüsseln, der im Back-End-Pool ausgeführt wird.
Datenverkehr erreicht das Gateway über einen Front-End-Port. Sie können viele Ports öffnen, und Application Gateway kann Nachrichten auf all diesen Ports empfangen. Der Listener verarbeitet den Datenverkehr, der das Gateway über einen Port erreicht, als Erstes. Der Listener ist so eingerichtet, dass er auf einen spezifischen Hostnamen und einen spezifischen Port auf einer bestimmten IP-Adresse lauscht. Der Listener kann ein TLS- bzw. SSL-Zertifikat zum Entschlüsseln des Datenverkehrs verwenden, der das Gateway erreicht. Der Listener verwendet dann eine Regel, die Sie definieren, um die eingehenden Anforderungen an einen Back-End-Pool weiterzuleiten.
Wenn Sie Ihre Website oder Webanwendung über Application Gateway zur Verfügung stellen, heißt das auch, dass Sie keine direkte Verbindung zwischen Ihren Servern und dem Internet herstellen. Sie machen nur Port 80 oder Port 443 für das Anwendungsgateway verfügbar, sodass der Datenverkehr dann an den Back-End-Poolserver weitergeleitet wird. Bei dieser Konfiguration sind Ihre Webserver nicht direkt über das Internet zugänglich, wodurch die Angriffsfläche Ihrer Infrastruktur reduziert wird.
Integritätstests
Integritätstest bestimmen, welche Server für den Lastenausgleich in einem Back-End-Pool verfügbar sind. Application Gateway verwendet einen Integritätstest, um eine Anforderung an einen Server zu senden. Wenn der Server eine HTTP-Antwort mit einem Statuscode zwischen 200 und 399 zurückgibt, wird der Server als fehlerfrei eingestuft. Wenn Sie keinen Integritätstest konfigurieren, erstellt Application Gateway einen Standardtest, der 30 Sekunden lang wartet, bevor entschieden wird, dass ein Server nicht verfügbar ist. Integritätstest stellen sicher, dass der Datenverkehr nicht an einen Webendpunkt im Back-End-Pool weitergeleitet wird, der nicht reagiert oder der ausgefallen ist.
Automatische Skalierung
Application Gateway unterstützt die automatische Skalierung und kann je nach Veränderung der Muster für die Datenverkehrsauslastung hoch- oder herunterskalieren. Durch die automatische Skalierung entfällt auch die Notwendigkeit, während des Bereitstellens eine Bereitstellungsgröße oder eine Anzahl von Instanzen auszuwählen.
WebSocket- und HTTP/2-Datenverkehr
Application Gateway verfügt über native Unterstützung für das WebSocket- und das HTTP/2-Protokoll. Das WebSocket- und das HTTP/2-Protokoll ermöglichen die Vollduplexkommunikation zwischen einem Server und einem Client über eine TCP-Verbindung mit langer Laufzeit. Diese Kommunikation ermöglicht wiederum mehr Interaktivität bei der Kommunikation zwischen dem Webserver und dem Client, und kann auch ohne die bei HTTP-basierten Implementierungen erforderlichen Abfragen bidirektional sein kann. Diese Protokolle zeichnen sich (im Gegensatz zu HTTP) durch einen geringen Mehraufwand aus. Außerdem können sie die gleiche TCP-Verbindung für mehrere Anforderungen/Antworten verwenden, was eine effizientere Ressourcennutzung zur Folge hat. Diese Protokolle sind für die Nutzung der üblichen HTTP-Ports 80 und 443 konzipiert.