Verbessern Sie die Leistung und Sicherheit von Azure-Apps mit NGINX

NGINXaaS für Azure ermöglicht Unternehmen die sichere Bereitstellung leistungsstarker Applications in der Cloud. Es handelt sich um einen vollständig verwalteten Dienst, der auf NGINX Plus basiert und im Januar 2023 allgemein verfügbar wurde. Seit der Veröffentlichung und auch in Zukunft verbessern wir NGINXaaS für Azure kontinuierlich durch das Hinzufügen neuer Funktionen .

In diesem Blog stellen wir einige der neuesten Leistungs- und Sicherheitsfunktionen vor, mit denen Sie mehr Vorteile von NGINX Plus nutzen können, ohne Ihre eigenen NGINX Plus-Instanzen bereitstellen, warten und aktualisieren zu müssen. Allgemeine Informationen zu NGINXaaS für Azure und seinen übergreifenden Funktionen finden Sie unter Vereinfachen und Beschleunigen von Cloudmigrationen mit F5 NGINXaaS für Azure .

Abbildung 1: Übersicht über NGINXaaS für Azure

Sichern des Upstream-Verkehrs mit mTLS

Während Reverse-Proxys SSL/TLS zur Verschlüsselung des clientseitigen Datenverkehrs im öffentlichen Internet erfordern, ist gegenseitiges TLS (mTLS) für die Authentifizierung und Gewährleistung der Vertraulichkeit auf der Serverseite unverzichtbar. Mit der Umstellung auf Zero Trust muss außerdem überprüft werden, dass der Upstream-Server-Verkehr nicht verändert oder abgefangen wurde.

Abbildung 2: mTLS mit NGINXaaS

NGINXaaS für Azure unterstützt jetzt NGINX-Direktiven, um Upstream-Verkehr mit SSL/TLS-Zertifikaten zu sichern . Mit diesen Anweisungen können Sie nicht nur den Upstream-Verkehr über mTLS verschlüsselt halten, sondern auch überprüfen, ob die Upstream-Server ein gültiges Zertifikat einer vertrauenswürdigen Zertifizierungsstelle vorlegen.

Zertifikatsrotation

Ein wichtiger Teil (Wortspiel beabsichtigt) der Verwendung von TLS-Zertifikaten mit NGINXaaS für Azure ist die sichere Verwaltung dieser Zertifikate durch die Verwendung von Azure Key Vault (AKV) . AKV schützt vertrauliches, kryptografisches Material und ermöglicht NGINXaaS für Azure die Verwendung dieser Zertifikate, während gleichzeitig die versehentliche oder absichtliche Offenlegung des Schlüsselmaterials über das Azure-Portal verhindert wird.

Abbildung 3: Zertifikatrotation mit Azure Key Vault

NGINXaaS für Azure kann jetzt automatisch Zertifikate durch Ihre NGINX-Bereitstellungen rotieren , wenn sie in AKV aktualisiert werden. Neue Versionen von Zertifikaten werden innerhalb von vier Stunden in Ihre Bereitstellungen rotiert.

HTTP/2-Proxy (und zusätzliche Protokolloptionen)

Schließen Sie die Augen und denken Sie an das Jahr 1997 zurück. Wir haben zusammen mit Chumbawamba in unseren JNCO-Jeans (oder Modrobes für alle kanadischen Landsleute da draußen) Tubthumping gemacht, und HTTP/1.1 wurde veröffentlicht. Damals griffen die meisten Endbenutzer über ein DFÜ-Modem auf das Internet zu, Webseiten enthielten lediglich einige Dutzend Elemente und für das Benutzererlebnis war die Bandbreite ein weitaus wichtigeres Thema als die Latenz.

25 Jahre später nutzt ein beträchtlicher Teil der Applications immer noch HTTP/1.1 zur Bereitstellung von Inhalten. Dies kann ein Problem sein. HTTP/1.1 funktioniert zwar noch, ermöglicht jedoch nur die Bereitstellung einer Ressource gleichzeitig pro Verbindung. Mittlerweile können moderne Web-Apps Hunderte von Anfragen zur Aktualisierung einer Benutzeroberfläche stellen.

Obwohl den meisten Benutzern eine wesentlich größere Bandbreite zur Verfügung steht, hat sich die Geschwindigkeit der Datenübertragung (begrenzt durch die fundamentale Lichtgeschwindigkeit) nicht so schnell weiterentwickelt. Daher kann die kumulative Latenz aller dieser Anfragen erhebliche Auswirkungen auf die wahrgenommene Leistung Ihrer Application haben. Moderne Browser öffnen mehrere TCP-Verbindungen zum selben Server, aber jede Anfrage über diese Verbindungen ist immer noch sequenziell, was bedeutet, dass eine langsame Ressource alle anderen dahinter liegenden Ressourcen verzögern kann.

Schauen Sie sich die Homepage von F5 an, wenn sie nur mit HTTP/1.1 geladen wird:

Abbildung 4: Zugriff auf F5.com über HTTP/1.1

Sehen Sie all diese grauen Balken? Das ist wertvolle Zeit, die der Browser verschwendet, während er auf den Sitzungsaufbau wartet, eine einzelne langsame Ressource blockiert oder nach einer neuen verfügbaren TCP-Verbindung sucht.

Lassen Sie uns HTTP/2 aktivieren und es erneut versuchen:

Abbildung 5: Dieselbe Anfrage, aber mit HTTP/2

Viel besser. Es gibt zwar immer noch einige langsame Ressourcen, diese halten jedoch keine anderen Anfragen auf und es wird erheblich weniger Zeit mit Warten aufgrund von warteschlangenbedingten Verzögerungen verbracht. HTTP/2 behält die gleiche Semantik bei, die Webbrowser und Server von HTTP/1.1 kennen, fügt aber neue Funktionen hinzu, um einige Gründe für die als schlecht wahrgenommene Application zu beheben (z. B. Anforderungspriorisierung, Header-Komprimierung und Anforderungsmultiplexing).

Angesichts dieses deutlichen Unterschieds unterstützt NGINXaaS für Azure jetzt die Bereitstellung von Clientanforderungen über HTTP/2 . Bei clientseitigen Verbindungen ist die Wahrscheinlichkeit größer, dass längere Roundtrip-Zeiten die Folge sind. Sie können daher diesen Datenverkehr mit den latenzreduzierenden Vorteilen von HTTP/2 bereitstellen und gleichzeitig Ihre Upstream-Server unverändert lassen.

Auch wenn manche in der Web Application etwas anderes glauben möchten, sind wir uns darüber im Klaren, dass Ihnen neben HTTP noch weitere Protokolloptionen zur Verfügung stehen. Aus diesem Grund ist das NGINX gRPC-Modul jetzt auch in NGINXaaS für Azure verfügbar. Es bietet mehrere Konfigurationsanweisungen für die Arbeit mit gRPC-Verkehr, darunter Fehlerabfangen, Header-Manipulation und mehr.

Für Nicht-HTTP/gRPC-Verkehr ist das Stream-Modul jetzt in NGINXaaS für Azure verfügbar. Dieses Modul unterstützt Proxying und Lastenausgleich für TCP- und UDP-Verkehr.

Unterstützung für Layer 4- und Layer 7-Load-Balancing

NGINXaaS für Azure kann jetzt sowohl als Layer 4 TCP/UDP- als auch als Layer 7 HTTP/HTTP-Cloud-nativer Load Balancer fungieren. Warum ist das wichtig? Anstatt zwei verschiedene Dienste oder Lastenausgleichsmodule einzusetzen, können Sie mit NGINXaaS für Azure einen einzigen Lastenausgleichsmodul einsetzen und ihn so konfigurieren, dass er auf beiden Ebenen gleichzeitig funktioniert. Dies vereinfacht Ihre Cloud-Architektur und senkt Ihre Kosten.

Die Konfiguration können Sie hier nachlesen.

Höhere Kapazität (bis zu 160 NCUs)

NGINXaaS für Azure ist ein verbrauchsbasierter Dienst, der stündlich gemessen und monatlich in NGINX Capacity Units (NCUs) abgerechnet wird. Wir haben diese Bereitstellungskapazität kürzlich von 80 NCUs auf 160 NCUs verdoppelt. Kunden können ein kleineres System mit 20 NCUs einsetzen und bei steigender Arbeitslast auf bis zu 160 NCUs aufstocken. Darüber hinaus haben Kunden die Möglichkeit, zu Beginn bis zu 160 NCUs einzusetzen.

Hinzufügen von NGINX Plus-Direktiven

Um eine einfache Lift-and-Shift-Konfiguration von einem lokalen Angebot zu einem vollständig verwalteten Cloud-Angebot zu ermöglichen, haben wir viele NGINX Plus-Direktiven hinzugefügt. Alle NGINX Plus-Direktiven, die wir in NGINXaaS für Azure unterstützen, finden Sie hier .

Legen Sie noch heute los

Wir verbessern und erweitern ständig die Möglichkeiten, wie Sie die NGINX- und F5-Technologie nutzen können, um jede App und API zu sichern, bereitzustellen und zu optimieren – überall. Mit den oben genannten und weiteren neuen Funktionen, die zu NGINXaaS für Azure hinzugefügt wurden, können mehr Azure-Benutzer zahlreiche App- und API-Probleme mit der Leistung von NGINX Plus lösen, ohne den Aufwand für die Verwaltung einer zusätzlichen VM oder Container-Infrastruktur.

Wenn Sie mehr über NGINXaaS für Azure erfahren möchten, empfehlen wir Ihnen, die Produktdokumentation durchzusehen. Wenn Sie bereit sind, NGINXaaS für Azure auszuprobieren, besuchen Sie den Azure Marketplace oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.