Bearbeiten

Freigeben über

Sicher verwaltete Webanwendungen

Azure App Service
Azure Application Gateway
Azure SQL-Datenbank
Azure VPN Gateway
Azure Web Application Firewall

Dieser Artikel ermöglicht einen Überblick über die Bereitstellung sicherer Anwendungen mit der App Service-Umgebung. Um den Zugriff auf Anwendungen über das Internet zu beschränken, werden der Azure Application Gateway-Dienst und die Azure Web Application Firewall verwendet. Dieser Artikel enthält auch eine Anleitung zu Continuous Integration und Continuous Deployment (CI/CD) für App Service-Umgebungen mit Azure DevOps.

Dieses Szenario wird häufig in Branchen wie dem Bankwesen und der Versicherungsbranche verwendet, in denen die Kunden neben der Sicherheit auf Anwendungsebene auch auf die Sicherheit auf Plattformebene achten. Zur Veranschaulichung dieser Konzepte verwenden wir eine Anwendung, mit der Benutzer Kostenabrechnungen einreichen können.

Mögliche Anwendungsfälle

Erwägen Sie dieses Szenario für folgende Anwendungsfälle:

  • Erstellen einer Azure-Web-App, bei der zusätzliche Sicherheit erforderlich ist.
  • Es wird ein dedizierter Mandant anstelle von App Service-Plänen für freigegebene Mandanten bereitgestellt.
  • Verwenden Sie Azure DevOps mit einer internen Application Service-Umgebung mit Lastenausgleich (ILB).

Aufbau

Diagramm, das die Beispielszenarioarchitektur für die sichere ILB App Service-Umgebungsbereitstellung zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  1. HTTP/HTTPS-Anforderungen gelangen zuerst zum Application Gateway.
  2. Optional (nicht im Diagramm dargestellt) können Sie die Authentifizierung von Microsoft Entra ID für die Web-App aktivieren. Nachdem der Datenverkehr zum ersten Mal beim Application Gateway eingetroffen ist, wird der Benutzer aufgefordert, Anmeldeinformationen für die Authentifizierung mit der Anwendung anzugeben.
  3. Benutzeranforderungen durchlaufen den internen Lastenausgleich (ILB) der Umgebung, die wiederum den Datenverkehr an die Web-App „Expenses“ (Ausgaben) weiterleitet.
  4. Der Benutzer fährt dann mit der Erstellung einer Kostenabrechnung fort.
  5. Bei der Erstellung der Kostenabrechnung wird die bereitgestellte API-App aufgerufen, um den Namen und die E-Mail-Adresse des Benutzers abzurufen.
  6. Die erstellte Kostenabrechnung wird in der Azure SQL-Datenbank gespeichert.
  7. Um eine kontinuierliche Bereitstellung zu ermöglichen, wird Code in die Azure DevOps-Instanz eingecheckt.
  8. Für die Build-VM ist der Azure DevOps-Agent installiert, der es der Build-VM ermöglicht, die Bits für die Web-App zur Bereitstellung in der App Service-Umgebung per Pullvorgang abzurufen (da die Build-VM in einem Subnetz in demselben virtuellen Netzwerk bereitgestellt wird).

Komponenten

  • Die App Service-Umgebung verfügt über eine vollständig isolierte dedizierte Umgebung für den sicheren Betrieb der Anwendung mit umfangreicher Skalierung. Weil sich die App Service-Umgebung und die darauf ausgeführten Workloads hinter einem virtuellen Netzwerk befinden, bietet sie darüber hinaus eine zusätzliche Sicherheits- und Isolationsebene. Die Anforderung einer hohen Skalierung und Isolation hat dazu geführt, dass die ILB App Service-Umgebung ausgewählt wurde.
  • Diese Workload verwendet den Tarif „App Service (isoliert)“, bei dem die Anwendung in einer privaten dedizierten Umgebung in einem Azure-Rechenzentrum ausgeführt wird, für die schnellere Prozessoren, SSD-Speicher (Solid-State Drive) und ein doppelt so hohes Arbeitsspeicher-zu-Kern-Verhältnis wie bei „Standard“ genutzt werden.
  • Azure App Service-Web-App und API-App hosten Webanwendungen und RESTful-APIs. Diese Apps und APIs werden im Service-Plan „Isoliert“ gehostet, der auch die automatische Skalierung, benutzerdefinierte Domänen usw. bietet, jedoch in einem dedizierten Tarif.
  • Azure Application Gateway ist ein Lastenausgleich für Webdatenverkehr, der auf Layer 7 durchgeführt wird und den an die Webanwendung fließenden Datenverkehr verwaltet. Er ermöglicht die SSL-Abladung. Hiermit wird für die Webserver, die die Web-App hosten, der zusätzliche Aufwand für die Entschlüsselung des Datenverkehrs beseitigt.
  • Die Web Application Firewall ist ein Feature von Application Gateway. Das Aktivieren der Web Application Firewall im Application Gateway erhöht die Sicherheit weiter. Die Web Application Firewall verwendet OWASP-Regeln (Open Worldwide Application Security Project), um die Webanwendung vor Angriffen wie Cross-Site-Scripting, Sitzungsübernahmen und der Einschleusung von SQL-Befehlen zu schützen.
  • Azure SQL-Datenbank wurde ausgewählt, da die meisten Daten in dieser Anwendung relationale Daten sind (einige Daten liegen als Dokumente und Blobs vor).
  • Azure-Netzwerk bietet verschiedene Netzwerkfunktionen in Azure und die Netzwerke können mit anderen virtuellen Netzwerken in Azure gepeert werden. Verbindungen können auch mit lokalen Rechenzentren über ExpressRoute oder Standort zu Standort aufgebaut werden. In diesem Fall wird ein Dienstendpunkt im virtuellen Netzwerk aktiviert, um sicherzustellen, dass die Daten nur zwischen dem virtuellen Azure-Netzwerk und der SQL-Datenbankinstanz ausgetauscht werden.
  • Azure DevOps wird als Hilfe für Teams verwendet, die während Sprints zusammenarbeiten und Features nutzen, mit denen die „agile Entwicklung“ unterstützt wird. Darüber hinaus können hiermit Build- und Releasepipelines erstellt werden.
  • Es wurde eine Azure-Build-VM erstellt, damit der installierte Agent den jeweiligen Build abrufen und die Web-App in der Umgebung bereitstellen kann.

Alternativen

Die App Service-Umgebung kann normale Web-Apps unter Windows ausführen, oder die innerhalb der Umgebung bereitgestellten Web-Apps werden – wie in diesem Beispiel – jeweils als Linux-Container ausgeführt. App Service-Umgebung wurde ausgewählt, um diese als Container ausgeführten Einzelinstanzanwendungen zu hosten. Es gibt auch Alternativen. Berücksichtigen Sie beim Entwerfen Ihrer Lösung die unten beschriebenen Überlegungen.

  • Azure Service Fabric: Wenn Ihre Umgebung größtenteils Windows-basiert ist, Ihre Workloads in erster Linie auf .NET Framework basieren und Sie nicht erwägen, auf .NET Core umzusteigen, sollten Sie Service Fabric verwenden, um Windows Server-Container zu unterstützen und bereitzustellen. Darüber hinaus unterstützt Service Fabric C#- oder Java-APIs für die Programmierung. Für die Entwicklung nativer Microservices können die Cluster als Windows- oder Linux-Cluster bereitgestellt werden.
  • Azure Kubernetes Service (AKS) ist ein Open-Source-Projekt und eine Orchestrierungsplattform, die besser zum Hosten komplexer Anwendungen mit mehreren Containern geeignet ist, für die üblicherweise eine Microservice-basierte Architektur verwendet wird. AKS ist ein verwalteter Azure-Dienst, der die Komplexität der Bereitstellung und Konfiguration eines Kubernetes-Clusters abstrahiert. Allerdings sind für den Support und die Wartung der Kubernetes-Plattform umfangreiche Kenntnisse erforderlich, sodass das Hosting einer Reihe von Einzelinstanz-Webanwendungen in Containern unter Umständen nicht die beste Option ist.

Andere Optionen für die Datenschicht:

  • Azure Cosmos DB: Wenn der Großteil der Daten im nicht-relationalen Format vorliegt, ist Azure Cosmos DB eine gute Alternative. Dieser Dienst bietet eine Plattform für andere Datenmodelle, wie z. B. MongoDB, Cassandra, Graphdaten oder einfacher Tabellenspeicher.

Überlegungen

Bei der Verwendung von Zertifikaten in der ILB App Service-Umgebung sind einige Besonderheiten zu beachten. Sie müssen ein Zertifikat generieren, das mit einem vertrauenswürdigen Stamm verbunden ist, ohne dass eine Zertifikatsignieranforderung erforderlich ist, die von dem Server generiert wird, auf dem das Zertifikat schließlich gespeichert wird. Bei Internetinformationsdiensten (IIS) besteht beispielsweise der erste Schritt darin, eine CSR (Certificate Signing Request, Zertifikatsignieranforderung) von Ihrem IIS-Server zu generieren und diese dann an die Zertifizierungsstelle zu senden, die das SSL-Zertifikat ausstellt.

Sie können keine Zertifikatsignieranforderung über den internen Load Balancer (ILB) einer App Service-Umgebung ausstellen. Um diese Einschränkung zu umgehen, verwenden Sie das Platzhalterverfahren.

Das Platzhalterverfahren ermöglicht es Ihnen, den Besitznachweis für einen DNS-Namen anstelle einer Zertifikatsignieranforderung zu verwenden. Wenn Sie über einen DNS-Namespace verfügen, können Sie einen speziellen DNS-TXT-Eintrag einfügen. Das Platzhalterverfahren überprüft, ob der Eintrag vorhanden ist. Wenn er gefunden wird, weiß der Dienst, dass Sie der Besitzer des DNS-Servers sind, da Sie über den richtigen Eintrag verfügen. Basierend auf diesen Informationen stellt er ein Zertifikat aus, das unter einem vertrauenswürdigen Stamm registriert ist und das Sie dann in Ihren ILB hochladen können. Für die einzelnen Zertifikatspeicher in den Web-Apps sind keine weiteren Schritte erforderlich, da Sie im ILB über ein vertrauenswürdiges SSL-Stammzertifikat verfügen.

Bringen Sie selbstsignierte oder intern ausgestellte SSL-Zertifikatarbeit zum Laufen, wenn Sie sichere Aufrufe zwischen Diensten tätigen möchten, die in einer ILB-App Service-Umgebung ausgeführt werden. Eine andere zu berücksichtigende Lösung, wie man eine ILB App Service-Umgebung mit intern ausgestellten SSL-Zertifikaten zum Laufen zu bringen und wie man die interne Zertifizierungsstelle zum vertrauenswürdigen Stammspeicher hinzufügt.

Berücksichtigen Sie beim Bereitstellen der App Service-Umgebung die folgenden Einschränkungen, wenn Sie einen Domänennamen für die App Service-Umgebung auswählen. Domänennamen können nicht sein:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Darüber hinaus dürfen sich der für Apps verwendete benutzerdefinierte Domänenname und der von der ILB App Service-Umgebung verwendete Domänenname nicht überschneiden. Für eine ILB App Service-Umgebung mit dem Domänennamen „contoso.com“ können Sie keine benutzerdefinierten Domänennamen für beispielsweise folgende Apps verwenden:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Wählen Sie eine Domäne für die ILB App Service-Umgebung aus, die keinen Konflikt mit diesen benutzerdefinierten Domänennamen verursacht. Sie können z.B. contoso-internal.com für die Domäne Ihrer Umgebung für dieses Beispiel verwenden, da sie keinen Konflikt mit benutzerdefinierten Domänennamen, die auf .contoso.com enden, verursacht.

Ein weiterer zu berücksichtigender Punkt ist DNS. Damit Anwendungen innerhalb der App Service-Umgebung miteinander kommunizieren können, z. B. eine mit einer API kommunizierende Webanwendung, müssen Sie DNS für Ihr virtuelles Netzwerk konfigurieren, das die Umgebung enthält. Sie können entweder Ihr eigenes DNS oder private Azure DNS-Zonen verwenden.

Verfügbarkeit

Skalierbarkeit

Sicherheit

Resilienz

Bereitstellen dieses Szenarios

In diesem Tutorial wird Schritt für Schritt beschrieben, wie Sie die einzelnen Komponenten manuell bereitstellen. Wählen Sie App Service-Umgebung v3 anstelle von v2 aus, wenn Sie dem Tutorial folgen. Außerdem enthält dieses Tutorial eine .NET-Beispielanwendung, mit der eine einfache Contoso-Kostenabrechnung durchgeführt wird.

Preise

Erkunden Sie die Kosten für die Ausführung dieses Szenarios. In dem Kostenrechner sind bereits alle Dienste vorkonfiguriert. Wenn Sie wissen möchten, welche Kosten für Ihren spezifischen Anwendungsfall entstehen, passen Sie die entsprechenden Variablen an Ihren voraussichtlichen Datenverkehr an.

Auf der Grundlage des zu erwartenden Datenverkehrsaufkommens haben wir drei exemplarische Kostenprofile erstellt:

  • Klein: Dieses Preisbeispiel stellt die Komponenten dar, die für eine minimale Instanz auf Produktionsebene erforderlich sind, die ein paar tausend Benutzer pro Monat bedient. Die App nutzt eine einzelne Instanz einer Standard-Web-App, die für die automatische Skalierung ausreicht. Alle anderen Komponenten werden auf einen Basic-Tarif skaliert, um die Kosten zu minimieren und trotzdem sicherzustellen, dass SLA-Support (Service-Level Agreement, Vereinbarung zum Servicelevel) und ausreichend Kapazität vorhanden sind, um eine Workload auf Produktionsebene verarbeiten zu können.
  • Mittel: Dieses Preisbeispiel stellt die Komponenten dar, die für eine Bereitstellung mittlerer Größe benötigt werden. Hier erwarten wir ungefähr 100.000 Benutzer im Laufe eines Monats. Der erwartete Datenverkehr wird über eine einzelne App-Service-Instanz mit einem mittleren Standardebene verarbeitet. Außerdem werden dem Rechner mittlere Cognitive Services-Tarife und Suchdiensttarife hinzugefügt.
  • Groß: Dieses Preisbeispiel stellt eine Anwendung mit hohen Anforderungen und einer Größenordnung von mehreren Millionen Benutzern pro Monat sowie mit Daten im Terabyte-Bereich dar. Auf dieser Nutzungsebene mit hoher Leistung müssen Web-Apps im Premium-Tarif in mehreren Regionen bereitgestellt werden, und der Einsatz von Traffic Manager ist erforderlich. Die Daten umfassen die folgenden Komponenten: Speicher, Datenbanken und CDN (alle für Daten im Terabyte-Bereich konfiguriert).

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

  • Faisal Mustafa | Senior Customer Engineer

Nächste Schritte