Sichern von Anwendungen im Microsoft Azure App Service mit NGINX Plus

Der Aufstieg des Cloud Computing – und insbesondere der Angebote „Platform as a Service“ (PaaS) und „Container as a Service“ (CaaS) – verändert die Art und Weise, wie Unternehmen ihre Geschäftsanwendungen bereitstellen und betreiben. Eine der wichtigsten Herausforderungen beim Entwurf von Cloud-Anwendungen besteht darin, vollständig verwaltete Cloud-Dienste auszuwählen, die Kosten und zeitaufwändige Betriebsaufgaben reduzieren, ohne die Sicherheit zu beeinträchtigen.

Dieser Blogbeitrag zeigt Ihnen, wie Sie Anwendungen auf dem Microsoft Azure App Service hosten und mit NGINX Plus sichern, um Angriffe aus dem Internet zu verhindern.

Kurzer Überblick über den Microsoft Azure App Service

Microsoft Azure App Service ist eine unternehmenstaugliche und vollständig verwaltete Plattform, mit der Organisationen Web-, API- und mobile Apps in Microsoft Azure bereitstellen können, ohne die zugrunde liegende Infrastruktur verwalten zu müssen, wie in Abbildung 1 dargestellt. Azure App Service bietet die folgenden Hauptfunktionen:

• Mit Web Apps können Sie Web-Apps in verschiedenen Sprachen und Frameworks (ASP.NET, Node.js, Java, PHP und Python) bereitstellen und ausführen. Darüber hinaus verwaltet es skalierbare und zuverlässige Webanwendungen mithilfe von Internetinformationsdiensten (IIS) mit umfassenden Anwendungsverwaltungsfunktionen (Überwachung, Wechsel von der Staging- zur Produktionsumgebung, Löschen bereitgestellter Anwendungen usw.). Es bietet außerdem eine Docker-Runtime zum Ausführen von Webanwendungen unter Linux mit Containern.
• API Apps bietet die Tools zum Bereitstellen von REST-APIs mit CORS-Unterstützung (Cross-Origin Resource Sharing). Azure API-Apps können problemlos mit Azure Active Directory, einmaligem Anmelden (SSO) in sozialen Netzwerken oder OAuth gesichert werden, ohne dass Codeänderungen erforderlich sind.
• Mobile Apps bieten eine schnelle Möglichkeit, mobile Backend-Dienste bereitzustellen, die wichtige Funktionen wie Authentifizierung, Push-Benachrichtigungen, Benutzerverwaltung, Cloud-Speicher usw. unterstützen.

Mit Azure App Service bietet Microsoft eine umfassende und schnelle Möglichkeit, Webanwendungen in der Cloud auszuführen. Entwickler können ihre Anwendungen lokal mit ASP.NET, Java, Node.js, PHP und Python entwickeln und sie dann mit Microsoft Visual Studio oder der Azure CLI problemlos in Azure App Service bereitstellen. DevOps-Teams können außerdem von der Continuous Deployment-Funktion von Azure App Service profitieren, um Anwendungsversionen schnell und zuverlässig in mehreren Umgebungen bereitzustellen.

Anwendungen im Azure App Service können auf andere in Azure bereitgestellte Ressourcen zugreifen oder über VPNs Verbindungen zu lokalen Unternehmensressourcen herstellen.

Grundlegendes zu Azure App Service-Umgebungen

Grundsätzlich wird eine mit Azure App Service erstellte Anwendung direkt dem Internet zugänglich gemacht und einer Subdomäne von azurewebsites.net zugewiesen. Für mehr Sicherheit können Sie Ihre App mit SSL-Terminierung oder mit Authentifizierungs- und Autorisierungsprotokollen wie OAuth2 oder OpenID Connect (OIDC) schützen. Es ist jedoch nicht möglich, das Netzwerk mit feinkörnigen ausgehenden und eingehenden Sicherheitsregeln anzupassen oder Middleware wie eine Web Application Firewall (WAF) anzuwenden, um böswillige Angriffe oder Exploits aus dem Internet zu verhindern.

Wenn Sie vertrauliche Anwendungen im Azure App Service ausführen und diese schützen möchten, können Sie Azure App Service-Umgebungen (ASEs) verwenden. Eine ASE ist eine isolierte Umgebung, die in einem virtuellen Netzwerk bereitgestellt und ausschließlich den Anwendungen eines einzelnen Kunden gewidmet ist. Dadurch erhalten Sie mehr Kontrolle über den ein- und ausgehenden Anwendungsnetzwerkverkehr.

Mit ASEs können Sie Web-, API-, Mobil- oder Funktions-Apps in einer sichereren Umgebung in sehr großem Maßstab bereitstellen, wie in Abbildung 2 dargestellt.

Erstellen einer neuen ASE v2

Es gibt zwei Versionen der ASE: ASE v1 und ASE v2. In diesem Beitrag diskutieren wir ASE v2.

Sie können eine neue ASE v2 manuell über das Azure-Portal oder automatisch mithilfe des Azure Resource Manager erstellen.

Beim Erstellen einer neuen ASE müssen Sie zwischen zwei Bereitstellungstypen wählen:

• Eine externe ASE stellt die ASE‑gehosteten Anwendungen über eine öffentliche IP‑Adresse bereit.
• Eine ILB ASE stellt die ASE-gehosteten Anwendungen auf einer privaten IP-Adresse bereit, auf die nur innerhalb Ihres Azure Virtual Network zugegriffen werden kann. Der interne Endpunkt ist das, was Azure als internen Lastenausgleich (ILB) bezeichnet.

Im folgenden Beispiel wählen wir eine ILB ASE, um den Zugriff aus dem Internet zu verhindern. Daher sind in unserer ASE bereitgestellte Anwendungen nur von virtuellen Maschinen (VMs) aus zugänglich, die im selben Netzwerk ausgeführt werden. Die folgenden beiden Befehle verwenden Azure Resource Manager und die Azure CLI, um einen neuen ILB ASE v2 bereitzustellen:

$ Azure-Konfigurationsmodus arm $ Azure-Gruppenbereitstellung erstellen meine Ressourcengruppe mein Bereitstellungsname --Template-uri https://raw.githubusercontent.com/azure/azure-quickstart-templates/master/201-web-app-asev2-ilb-create/azuredeploy.json

Sichern des Zugriffs auf Apps in einer öffentlich zugänglichen ASE

Wenn Ihre App hingegen über das Internet erreichbar sein soll, müssen Sie sie vor böswilligen Angreifern schützen, die versuchen könnten, die in Ihrer Anwendung gespeicherten vertraulichen Informationen zu stehlen.

Zum Sichern von Anwendungen auf Ebene 7 in einer ASE haben Sie im Wesentlichen zwei Möglichkeiten:

• Azure-Anwendungsgateway
• NGINX Plus mit dem NGINX ModSecurity WAF -Modul

(Sie können einen benutzerdefinierten Application Delivery Controller [ADC] durch WAF-Funktionen ersetzen, diesen Anwendungsfall behandeln wir hier jedoch nicht.)

Die Wahl der Lösung hängt von Ihren Sicherheitseinschränkungen ab. Einerseits bietet Azure Application Gateway eine schlüsselfertige Lösung zur Durchsetzung der Sicherheit und erfordert nicht, dass Sie die zugrunde liegende Infrastruktur warten. Andererseits erhalten Sie durch die Bereitstellung von NGINX Plus auf VMs einen leistungsstarken Stack mit mehr Kontrolle und Flexibilität zur Feinabstimmung Ihrer Sicherheitsregeln.

Die Entscheidung zwischen Azure Application Gateway und NGINX Plus zum Lastenausgleich und zur Sicherung von in einer ASE erstellten Anwendungen erfordert ein gutes Verständnis der von den einzelnen Lösungen bereitgestellten Funktionen. Während Azure Application Gateway für einfache Anwendungsfälle geeignet ist, bietet es für komplexe Anwendungsfälle nicht viele der Funktionen, die standardmäßig in NGINX Plus enthalten sind.

Die folgende Tabelle vergleicht die Unterstützung für Lastenausgleich und Sicherheitsfunktionen in Azure Application Gateway und NGINX Plus. Weitere Einzelheiten zu den Funktionen von NGINX Plus finden Sie unterhalb der Tabelle.

Wie Sie sehen, fungieren sowohl NGINX Plus als auch Azure Application Gateway als ADCs mit Layer 7-Lastausgleichsfunktionen und einer WAF, um einen starken Schutz vor gängigen Sicherheitslücken und Exploits im Internet zu gewährleisten.

NGINX Plus bietet mehrere zusätzliche Features, die in Azure Application Gateway fehlen:

• URL-Umschreiben und -Umleitung – Mit NGINX Plus können Sie die URL einer Anfrage umschreiben, bevor Sie sie an einen Backend-Server weiterleiten. Dies bedeutet, dass Sie den Speicherort von Dateien oder Anforderungspfaden ändern können, ohne die den Clients angezeigte URL zu ändern. Sie können Anfragen auch umleiten. Sie können beispielsweise alle HTTP-Anfragen auf einen HTTPS-Server umleiten.
• Verbindungs- und Ratenbegrenzungen – Sie können mehrere Begrenzungen konfigurieren, um den Datenverkehr zu und von Ihren NGINX Plus-Instanzen zu steuern . Dazu gehören Beschränkungen der Anzahl eingehender Verbindungen, der Rate eingehender Anfragen, der Verbindungen zu Backend-Knoten und der Datenübertragungsrate von NGINX Plus zu Clients.
• HTTP/2- und WebSocket-Unterstützung – NGINX Plus unterstützt HTTP/2 und WebSocket auf der Anwendungsebene (Ebene 7). Azure Application Gateway tut dies nicht; stattdessen unterstützt Azure Load Balancer sie auf der Netzwerkebene (Ebene 4), wo TCP und UDP betrieben werden.

Für zusätzliche Sicherheit können Sie Azure DDoS Protection einsetzen, um Bedrohungen auf Ebene 3 und 4 einzudämmen und so die Bedrohungsminderungsfunktionen der Ebene 7 von Azure Application Gateway oder NGINX Plus zu ergänzen.

Verwenden von NGINX Plus mit Azure App Service zum Sichern von Anwendungen

Abbildung 3 zeigt, wie NGINX Plus und Azure App Service kombiniert werden, um eine sichere Umgebung zum Ausführen von Geschäftsanwendungen in der Produktion bereitzustellen. Diese Bereitstellungsstrategie nutzt NGINX Plus wegen seiner Lastausgleichs- und WAF-Funktionen.

Die Bereitstellung kombiniert die folgenden Komponenten:

• Azure Virtual Network (VNet) – Stellt ein virtuelles Netzwerk in der Azure-Cloud dar, das Ihrer Organisation gewidmet ist. Es bietet eine logische Isolierung, die es Azure-Ressourcen ermöglicht, in einem virtuellen Netzwerk sicher miteinander zu kommunizieren. Hier haben wir zwei Subnetze definiert: Intern für Webanwendungen, die nicht direkt dem Internet ausgesetzt sind, und Waf für NGINX Plus und die zugrunde liegende Infrastruktur.

• Azure App Service-Umgebung – Diese Beispielbereitstellung verwendet zwei Beispiel-Webanwendungen – Web-App 1 und Web-App 2 – um zu demonstrieren, wie verschiedene Web-Apps mit NGINX Plus gesichert und deren Last ausgeglichen werden. In NGINX Plus verteilen Sie Anfragen an verschiedene Webanwendungen, indem Sie unterschiedliche Upstream- Blöcke konfigurieren und die Inhaltsweiterleitung auf URI-Basis mit Standortblöcken durchführen. Nachfolgend sehen Sie die minimale NGINX Plus-Konfiguration, die dieses Ziel erfüllt (hier gehen alle Anfragen an dieselbe Upstream-Gruppe):

  Upstream-Backend { Server- IP-Adresse Ihres ASE-ILB ; } Server { Standort / { Proxy-Set-Header Host $host; Proxy-Pass http://backend; } }
  

• NGINX Plus – verteilt die Last von HTTP(S)-Verbindungen über mehrere Webanwendungen hinweg. Durch die Bereitstellung von NGINX Plus in einer VM erhalten Sie mehr Kontrolle über die Infrastruktur als andere Azure-Dienste. Bei einer VM können Sie beispielsweise das Betriebssystem (Linux oder Windows) auswählen, das in einem isolierten virtuellen Netzwerk ausgeführt wird. Tatsächlich sind Azure-VMs für alle Linux-Distributionen verfügbar, die von NGINX Plus unterstützt werden (außer Amazon Linux, aus offensichtlichen Gründen).
• Azure VM-Skalierungsgruppen – VM-Skalierungsgruppen sind eine Azure-Computerressource, mit der Sie eine Gruppe identischer VMs bereitstellen und verwalten können. Sie können die Größe der VM konfigurieren und die VM dem richtigen VNet zuweisen. Für alle innerhalb des Skalierungssatzes ausgeführten VMs erfolgt der Lastenausgleich durch einen Azure Load Balancer, der TCP-Konnektivität zwischen den VM-Instanzen bereitstellt. Hier basiert jede VM im Skalierungssatz auf dem im Azure Marketplace verfügbaren NGINX Plus-Image. Skalierungssätze sind für eine echte automatische Skalierung ausgelegt.

Azure unterstützt auch Ressourcengruppen als einfache Möglichkeit, die Azure-Ressourcen für eine Anwendung auf logische Weise zu gruppieren. Die Verwendung einer Ressourcengruppe hat keine Auswirkungen auf das Design und die Topologie der Infrastruktur und wird hier daher nicht angezeigt.

NGINX Plus Hochverfügbarkeit und automatische Skalierung mit Azure VM Scale Sets

Ein Azure-VM-Skalierungssatz bietet Ihnen die Leistungsfähigkeit der Virtualisierung mit der Möglichkeit zur jederzeitigen Skalierung, ohne die physische Hardware kaufen und warten zu müssen, die die Skalierung unterstützt. Sie sind jedoch weiterhin für die Wartung der VM verantwortlich, indem Sie Aufgaben wie Konfigurieren, Patchen, Sicherheitsupdates und Installieren der darauf ausgeführten Software ausführen.

In der in Abbildung 4 dargestellten Architektur werden NGINX Plus-Instanzen für eine Aktiv-Aktiv-Hochverfügbarkeit innerhalb eines Azure-VM-Skalierungssatzes bereitgestellt. Eine Active‑Active-Konfiguration ist ideal, da alle NGINX Plus-VMs eine eingehende, von Azure Load Balancer weitergeleitete Anfrage verarbeiten können und Ihnen so kosteneffiziente Kapazität bieten.

Mit Azure VM-Skalierungssätzen können Sie auch problemlos die automatische Skalierung von NGINX Plus-Instanzen basierend auf der durchschnittlichen CPU-Auslastung einrichten. Sie müssen in diesem Fall darauf achten, die NGINX Plus-Konfigurationsdateien zu synchronisieren. Sie können zu diesem Zweck die Funktion zur Konfigurationsfreigabe von NGINX Plus verwenden, wie im NGINX Plus-Administratorhandbuch beschrieben.

Zusammenfassung

Indem Sie Azure App Service für Ihre Cloud-Anwendungen und NGINX Plus vor Ihren Web-Apps, APIs und mobilen Back-Ends verwenden, können Sie die Last dieser Anwendungen auf globaler Ebene ausgleichen und sichern. Durch die Verwendung von NGINX Plus in Verbindung mit Azure App Service erhalten Sie eine vollständig lastausgeglichene Infrastruktur mit einem hohen Maß an Schutz vor Exploits und Angriffen aus dem Internet. Dadurch wird ein robustes Design gewährleistet, um kritische Anwendungen in der Produktion auf sichere Weise auszuführen.

Ressourcen

Übersicht über Web-Apps (Microsoft)
Einführung in die App Service-Umgebungen (Microsoft)
Erstellen eines Anwendungsgateways mit einer Web Application Firewall über das Azure-Portal (Microsoft)
Vergleichen Sie die Funktionen in NGINX Open Source und NGINX Plus (NGINX).
HTTP-Lastausgleich (NGINX)

Gast-Co-Autor Cedric Derue ist Solution Architect und Microsoft MVP bei Altran. Gast-Co-Autor Vincent Thavonekham ist Microsoft Regional Director und Azure MVP bei VISEO.