Bearbeiten

Zugriff mit höherer Sicherheit auf mehrinstanzenfähige Web-Apps aus einem lokalen Netzwerk

Azure App Service
Azure Virtual Network
Azure Private Link
Azure-Schlüsseltresor
Azure-Speicherkonten

In diesem Artikel erfahren Sie, wie Sie eine private Konnektivität mit verbesserter Sicherheit mit einer mehrinstanzenfähigen Web-App oder Funktions-App aus einem lokalen Netzwerk oder aus einem virtuellen Azure-Netzwerk einrichten. Außerdem wird gezeigt, wie Sie eine Konnektivität mit verbesserter Sicherheit zwischen der App und anderen Azure PaaS-Diensten über Azure Private Link einrichten, ohne das öffentliche Internet zu verwenden.

Architektur

Diagramm, das die Referenzarchitektur für den sicheren Zugriff auf mehrinstanzenfähige Webanwendungen von einem lokalen Netzwerk aus zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

  • Mithilfe der regionalen VNet-Integration des Azure App Service stellt die Web-App über das delegierte Subnetz VNet-Integrationssubnetz in einem virtuellen Azure-Netzwerk eine Verbindung mit Azure-Diensten dar.

    • Die Netzwerke VNet-Integrationssubnetz und Subnetz des privaten Endpunkts sind separate virtuelle Netzwerke in verschiedenen Abonnements. Beide Netzwerke werden im Rahmen einer Hub-and-Spoke-Netzwerkkonfiguration mit einem virtuellen Hubnetzwerk verbunden. Für die regionale VNet-Integration müssen sich die virtuellen Netzwerke mit Peering in derselben Azure-Region befinden.

  • Der Azure Private Link-Dienst richtet einen privaten Endpunkt für die PaaS-Dienste, Web-Apps, die Azure SQL-Datenbank, das Azure-Speicherkonto und den Azure-Schlüsseltresor in einem virtuellen Netzwerk mit privatem Endpunkt ein.

    In diesem Beispiel ist dieses virtuelle Netzwerk nur für die Bereitstellung privater Endpunkte dediziert. In diesem virtuellen Netzwerk werden keine anderen Ressourcen wie virtuelle Computer (VMs) bereitgestellt. Bei der Auswahl der Größe des Subnetzes wurde der zukünftige Bedarf an privaten Endpunkten berücksichtigt.

  • Das lokale Netzwerk und die virtuellen Azure-Netzwerke können über ein Site-to-Site-VPN (S2S) oder über privates Peering mit Azure ExpressRoute verbunden werden. Benutzer im lokalen Netzwerk greifen privat und mit verbesserter Sicherheit nur über das private Netzwerk auf die App zu.

    In diesem Beispiel werden das lokale Netzwerk und die virtuellen Azure-Netzwerke über privates ExpressRoute-Peering verbunden.

  • Für ein lokales Netzwerk, das bereits über eine DNS-Lösung (Domain Name System) verfügt, ist die lokale DNS-Lösung so konfiguriert, dass DNS-Datenverkehr über eine bedingte Weiterleitung an einen privaten Azure-DNS-Eintrag (z. B. azurewebsites.net) weitergeleitet wird, der die Anforderung an den eingehenden Endpunkt des DNS Private Resolver-Diensts weiterleitet, der in Azure bereitgestellt wird. Der DNS Private Resolver-Dienst fragt Azure DNS ab und empfängt Informationen über eine VNet-Verknüpfung mit privatem DNS von Azure. Die Auflösung erfolgt dann durch eine private DNS-Zone, die mit einem virtuellen Netzwerk verknüpft ist.

    Private DNS-Zonen werden auch im gleichen Abonnement wie ein virtuelles Netzwerk mit privatem Endpunkt bereitgestellt.

    In diesem Beispiel leitet ein DNS-Weiterleitungscomputer mit der IP-Adresse 192.168.0.254 im lokalen Netzwerk alle DNS-Auflösungsanforderungen an den Hostnamen „azurewebsites.net“ an den eingehenden Endpunkt des DNS Private Resolver-Diensts in Azure unter Adresse 10.0.0.132 weiter. Anschließend werden die Anforderungen vom von Azure bereitgestellten DNS-Dienst mit der IP-Adresse 168.63.129.16 über die Zone mit privatem Azure-DNS aufgelöst, die mit dem virtuellen Netzwerk verknüpft ist.

    Ein ausgehender Endpunkt ist erforderlich, um die Namensauflösung der bedingten Weiterleitung von Azure an lokale, andere Cloudanbieter oder externe DNS-Server mithilfe eines Regelsatzes für die DNS-Weiterleitung zu aktivieren.

    Das Konfigurieren eines Regelsatzes für die DNS-Weiterleitung ist für dieses Szenario nicht erforderlich.

    Diese App-Dienst-Konfiguration sollte vorhanden sein:

    Schlüssel Wert
    WEBSITE_DNS_SERVER 168.63.129.16

  • Virtuelle Netzwerke sind mit allen privaten Azure-DNS-Zonen verknüpft.

    • Das virtuelle Netzwerk mit privaten Endpunkten wird automatisch mit den privaten DNS-Zonen verknüpft. Sie müssen die anderen virtuellen Netzwerke separat verknüpfen.

  • Die Web-App kommuniziert mit den privaten Endpunkten der PaaS-Dienste im virtuellen Netzwerk mit privatem Endpunkt über Azure Firewall.

  • Auf Azure Firewall werden die Anwendungsregeln so konfiguriert, dass sie die Kommunikation zwischen dem VNet-Integrationssubnetz und den privaten Endpunkten von PaaS-Ressourcen ermöglichen. Vollqualifizierte Domänennamen (FQDNs) des Ziels sind:

    • *.azurewebsites.net
    • *.database.windows.net
    • *.core.windows.net
    • *.vaultcore.azure.net

  • Die Firewall- und virtuelle Netzwerkkonfiguration für Azure SQL, Azure Storage-Konto und Azure Key Vault lässt nur Datenverkehr aus dem VNET-Integrationssubnetz zu. Die Konfiguration lässt keine Kommunikation mit einem anderen virtuellen Netzwerk oder mit dem öffentlichen Internet zu.

Komponenten

  • Azure App Service hostet Webanwendungen und Funktions-Apps und ermöglicht die automatische Skalierung und Hochverfügbarkeit, ohne dass Sie die Infrastruktur verwalten müssen.
  • Azure SQL-Datenbank ist ein universeller verwalteter Dienst mit einer relationalen Datenbank, die Strukturen wie relationale Daten, räumliche Daten, JSON und XML unterstützt.
  • Azure Storage-Konto stellt einen eindeutigen Namespace für Ihre Azure Storage-Daten bereit, auf den von jedem Ort der Welt aus über HTTP oder HTTPS zugegriffen werden kann. Sie enthält alle Azure Storage-Datenobjekte: Blobs, Dateifreigaben, Warteschlangen, Tabellen und Datenträger.
  • Azure Key Vault ist ein Dienst zum sicheren Speichern und Zugreifen auf API-Schlüssel, Kennwörter, Zertifikate, kryptografische Schlüssel oder andere Geheimnisse, die von Cloud-Apps und -Diensten verwendet werden.
  • Azure Virtual Network ist der grundlegende Baustein für private Netzwerke in Azure. Über Virtual Network können Azure-Ressourcen (z. B. VMs) sicher untereinander sowie mit dem Internet und lokalen Netzwerken kommunizieren.
  • Azure Private Link stellt einen privaten Endpunkt in einem Virtual Network für Verbindungen mit Azure-PaaS-Diensten wie Azure Storage und SQL-Datenbank oder mit Kunden- oder Partnerdiensten bereit.
  • Azure ExpressRoute privates Peering erweitert lokale Netzwerke über eine private Verbindung in die Microsoft-Cloud. Sie können auch ein Site-to-Site-VPN zwischen dem lokalen Netzwerk und dem Azure-Netzwerk einrichten, anstatt Azure ExpressRoute.
  • Azure Firewall ist ein verwalteter, cloudbasierter Netzwerksicherheitsdienst, der zum Schutz Ihrer Azure VNET-Ressourcen beiträgt.
  • Privates DNS Zone bietet einen zuverlässigen und sicheren DNS-Dienst zum Verwalten und Auflösen von Domänennamen im virtuellen Netzwerk.
  • DNS Private Resolver ermöglicht die Abfrage von privaten Azure DNS-Zonen aus einer lokalen Umgebung heraus (und umgekehrt), ohne VM-basierte DNS-Server bereitstellen zu müssen.

Alternativen

Für private Konnektivität besteht ein alternativer Ansatz in der Verwendung App Service-Umgebung, um die Webanwendung in einer isolierten Umgebung zu hosten. Für die Datenbank können Sie Azure SQL Managed Instance in einem virtuellen Netzwerk nativ bereitstellen, sodass Sie keine VNET-Integration oder private Endpunkte benötigen. Diese Angebote sind in der Regel teurer, da sie eine isolierte Bereitstellung mit einem Mandanten und weitere Features bieten.

Wenn Sie über eine App Service-Umgebung verfügen, aber keine SQL Managed Instance-Instanz verwenden, können Sie weiterhin einen privaten Endpunkt für private Verbindungen mit einer Azure SQL-Datenbank verwenden. Wenn Sie bereits über eine SQL Managed Instance verfügen, aber einen mehrinstanzenfähigen App Service verwenden, können Sie die regionale VNET-Integration weiterhin verwenden, um eine Verbindung mit der privaten Adresse der SQL Managed Instance herzustellen.

Für einige andere Azure-Dienste wie Key Vault oder Storage gibt es keine Alternative zur Verwendung privater Endpunkte für äußerst sichere und private Verbindungen von Web-Apps.

Mögliche Anwendungsfälle

  • Greifen Sie privat auf eine mehrinstanzenfähige Web-App oder Funktions-App zu und erhöhen Sie die Sicherheit über ihren privaten Endpunkt über ein lokales Netzwerk oder innerhalb von virtuellen Azure-Netzwerken.
  • Verbinden von einer Web-App oder Funktions-App zu PaaS-Angeboten (Platform-as-a-Service) von Azure:
    • Andere Web-App
    • SQL-Datenbank
    • Azure Storage
    • Key Vault
    • Alle anderen Dienste, die private Azure-Endpunkte für eingehende Konnektivität unterstützen

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Die Verwendung privater Endpunkte für Ihre Web-App bietet Ihnen folgende Möglichkeiten:

  • Tragen Sie durch Konfigurieren des privaten Endpunkts dazu bei, Ihre Web-App zu schützen, wodurch eine öffentliche Verfügbarmachung beseitigt wird.
  • Verbinden mit verbesserter Sicherheit für Web-Apps aus lokalen Netzwerken, die über ein VPN oder privates ExpressRoute-Peering eine Verbindung mit dem virtuellen Netzwerk herstellen. Eingehende Verbindungen mit der Web-App sind nur aus dem lokalen Netzwerk oder aus dem virtuellen Azure-Netzwerk zulässig.
  • Vermeiden Sie die Exfiltration von Daten aus Ihrem virtuellen Netzwerk.

Sie können die Sicherheit der eingehenden Verbindung mit der Web-App weiter verbessern, indem Sie der App einen Dienst wie Azure Application Gateway oder Azure Front Door, optional mit Azure Web Application Firewall, vorschalten. Wenn Sie einen privaten Endpunkt für Ihre Web-App aktivieren, wird die Konfiguration der Zugriffsbeschränkungen der Web-App nicht ausgewertet.

Dieses Szenario verbessert auch die Sicherheit der ausgehenden Verbindung von einer App Service-Web-App zu einer Downstreamabhängigkeit wie einer Datenbank, Storage oder Key Vault.

Sie können das Anwendungsrouting so konfigurieren, dass entweder der ganze Datenverkehr oder nur privater Datenverkehr (auch als RFC1918-Datenverkehr bezeichnet) an Ihr virtuelles Netzwerk geroutet wird. Dieses Verhalten konfigurieren Sie über die Einstellung Route All (Gesamten Datenverkehr weiterleiten). Ist Route All (Gesamten Datenverkehr weiterleiten) deaktiviert, wird von der Web-App nur privater Datenverkehr an Ihr virtuelles Netzwerk weitergeleitet. Wenn Sie Datenverkehr an öffentliche Adressen blockieren möchten, aktivieren Sie die Einstellung Route All (Gesamten Datenverkehr weiterleiten) für das virtuelle Netzwerk. Sie können außerdem die Netzwerksicherheitsgruppe verwenden, um ausgehenden Datenverkehr an Ressourcen in Ihrem virtuellen Netzwerk oder im Internet zu blockieren. Ist Route All (Gesamten Datenverkehr weiterleiten) nicht aktiviert, werden NSGs nur auf RFC1918-Datenverkehr angewendet.

In diesem Beispiel muss die Web-App nicht mit einem Dienst kommunizieren, der sich nicht im virtuellen Netzwerk befindet. Daher ist Route All (Gesamten Datenverkehr weiterleiten) aktiviert.

Ein wichtiger Sicherheitsaspekt in diesem Szenario ist die Konfiguration der Firewall für PaaS-Ressourcen.

Optionen der SQL-Datenbank-Firewall

Wenn Sie keine private Konnektivität verwenden, können Sie Firewallregeln hinzufügen, die eingehenden Datenverkehr nur aus angegebenen IP-Adressbereichen zulassen. Ein weiterer Ansatz besteht darin, Azure-DienstenZugriff auf den Server zu erlauben. Dieser Ansatz sperrt die Firewall, um nur Datenverkehr aus Azure zu ermöglichen. Dieser Datenverkehr umfasst jedoch alle Azure-Regionen und andere Kunden.

Sie können auch eine restriktivere Firewallregel hinzufügen, damit nur die ausgehenden IP-Adressen der App auf die Datenbank zugreifen können. Da es sich bei App Service jedoch um einen mehrinstanzenfähigen Dienst handelt, werden diese IP-Adressen auch von anderen Kunden verwendet, und Datenverkehr von anderen Kunden im gleichen Bereitstellungsstempel wird zugelassen, bei dem dieselben ausgehenden IP-Adressen verwendet werden.

Bei Verwendung privater Konnektivität über das Virtual Network sind die folgenden Firewalloptionen verfügbar, um zu verhindern, dass andere Benutzer auf die Datenbank zugreifen:

  • Erstellen Sie in diesem Beispiel eine VNET-Regel, die nur Datenverkehr aus dem regionalen Subnetz zulässt, das von der VNET-Integration und dem VNET-Integrationssubnetz delegiert wurde. Das delegierte Subnetz muss über einen Dienstendpunkt verfügen, der für Microsoft.Sql konfiguriert ist, sodass die Datenbank Datenverkehr aus diesem Subnetz identifizieren kann.
  • Konfigurieren Sie die Firewall so, dass der Zugriff auf das öffentliche Netzwerk verweigert wird. Dadurch werden alle anderen Firewallregeln deaktiviert, und die Datenbank kann nur über ihren privaten Endpunkt zugänglich gemacht werden.

Die Option zum Verweigern des Zugriffs auf öffentliche Netzwerke ist die sicherste Konfiguration. Wenn Sie diese Option verwenden, ist der Datenbankzugriff jedoch nur über das virtuelle Netzwerk möglich, das den privaten Endpunkt hostet. Zum Herstellen einer Verbindung mit der Datenbank muss alles mit Ausnahme der Web-App über eine direkte Verbindung mit dem Virtual Network verfügen.

Beispielsweise können Bereitstellungen oder dringende manuelle Verbindungen aus SQL Server Management Studio (SSMS) auf lokalen Computern die Datenbank nur über VPN- oder ExpressRoute-Verbindungen mit dem Virtual Network erreichen. Sie können auch eine Remoteverbindung mit einem virtuellen Computer im Virtual Network herstellen und SSMS von dort aus verwenden. In Ausnahmefällen können Sie vorübergehend den Zugriff aus öffentlichen Netzwerken zulassen und das Risiko durch die Verwendung anderer Konfigurationsoptionen verringern.

Firewalloptionen Speicherkonto und Schlüsseltresor

Speicherkonten und Schlüsseltresore verfügen über einen öffentlichen Endpunkt, auf den über das Internet zugegriffen werden kann. Sie können auch private Endpunkte für Ihr Speicherkonto und Ihren Schlüsseltresor erstellen. Auf diese Weise wird diesen Diensten eine private IP-Adresse von Ihrem virtuellen Netzwerk zugewiesen und der gesamte Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem jeweiligen Dienst über eine private Verbindung gesichert.

Wenn Sie einen privaten Endpunkt erstellen, kann das VNET-Integrationssubnetz privat und mit verbesserter Sicherheit über eine private Verknüpfung auf den Dienst zugreifen. Auf das Speicherkonto und den Schlüsseltresor kann jedoch weiterhin über andere virtuelle Azure-Netzwerke zugegriffen werden. Um den Zugriff von einem anderen virtuellen Netzwerk zu blockieren, erstellen Sie den Dienstendpunkt für dieses delegierte Subnetz.

Verfügbarkeit

Private Link-Unterstützung für App Service, Azure SQL-Datenbank, Azure Storage und Azure Key Vault ist in allen öffentlichen Regionen verfügbar. Informationen zum Überprüfen der Verfügbarkeit in anderen Regionen finden Sie unter Azure Private Link-Verfügbarkeit.

Mit Private Link wird die Architektur um eine weitere Komponente erweitert, die bei den Überlegungen zur Verfügbarkeit zu berücksichtigen ist. Der Private Link-Dienst verfügt über eine SLA für Hochverfügbarkeit. Sie müssen diese SLA berücksichtigen, wenn Sie die zusammengesetzte SLA der gesamten Lösung berechnen.

Skalierbarkeit

Informationen zur Integration von Azure Private Link für PaaS-Dienste in Azure Privates DNS-Zonen in Hub-and-Spoke-Netzwerkarchitekturen finden Sie unter Private Link und DNS-Integration im großen Stil.

Globales Peering

Jeder Dienst in jeder Azure-Region, der über das virtuelle Netzwerk eine Verbindung herstellen kann, kann die privaten Endpunkte der PaaS-Dienste erreichen, z. B. über Peering virtueller Netzwerke in Hub-and-Spoke-Topologien. Bei der regionalen VNET-Integration für App Service müssen sich die Peering-Virtual Networks allerdings in derselben Azure-Region befinden.

Ohne Unterstützung für globales Peering können Sie diese Lösung nicht für regionsübergreifende Konnektivität von App Service mit einer Datenbank oder einem anderen privaten Endpunkt in einer anderen Azure-Region verwenden. Diese Lösung würde z. B. nicht bei einer Bereitstellung in mehreren Regionen funktionieren, um ein teilweises Failover zu unterstützen, bei dem die Web-App in einer Region aktiv bleibt, jedoch eine Verbindung mit einer Datenbank, für die der Failover ausgeführt wird, in einer anderen Region herstellen muss oder umgekehrt. Allerdings gibt es für diese Situation auch andere Lösungen.

Wenn Sie Web-Apps mit einem virtuellen Netzwerk in einer anderen Region verbinden müssen, können Sie die für das Gateway erforderliche VNET-Integration einrichten. Die Einschränkung ist, dass die für das Gateway erforderliche VNET-Integration nicht mit einem virtuellen Netzwerk verwendet werden kann, das mit einem Azure ExpressRoute verbunden ist.

Protokollierung und Überwachung

Azure Private Link ist in Azure Monitor integriert, sodass Sie Datenfluss erkennen können.

Sie können auch den Dienst zur Verbindungsproblembehandlung in Azure Network Watcher verwenden, um die Konnektivität von einer virtuellen Maschine in einem virtuellen Netzwerk mit dem FQDN der Ressource des privaten Endpunkts nachzuverfolgen.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Es gibt keine zusätzlichen Kosten für die regionale VNet-Integration von App Service in den unterstützten Tarifen der Pläne Basic, Standard, Premium v2, Premium v3, Isolated v2 App Service und Azure Functions Premium.

Der private Endpunkt ist verfügbar für Windows-Web-Apps und Linux-Web-Apps, containerisiert oder nicht, gehostet unter Plänen vom Typ Basic, Standard, Premium v2, Premium v3 und Isolated v2 App Service und auch für Funktions-Apps, die unter einem Premium-Plan bereitgestellt werden.

Für Azure Private Link-Dienst, der die privaten Endpunkte für PaaS-Dienste aktiviert, sind Kosten verbunden, die auf einer stündlich berechneten Gebühr zuzüglich einer Premium-Bandbreite basieren. Weitere Informationen finden Sie auf der Seite Private Link – Preise. Für Verbindungen zwischen einem virtuellen Clientnetzwerk und Azure Firewall im virtuellen Hubnetzwerk werden Gebühren berechnet. Für Verbindungen von Azure Firewall im virtuellen Hub-Netzwerk zu privaten Endpunkten in einem virtuellen Netzwerk mit Peer-Rechten werden keine Gebühren erhoben.

Die Kosten von Azure Private DNS-Zonen basieren auf der Anzahl von DNS-Zonen, die in Azure gehostet werden, sowie auf der Anzahl von empfangenen DNS-Abfragen.

Verwenden Sie die Schätzung des Azure-Preisrechners, um die Kosten für eine Umsetzung dieses Szenarios zu ermitteln. Alle in diesem Artikel beschriebenen Dienste sind mit angemessenen Standardwerten für eine kleine Anwendung vorkonfiguriert. Wenn Sie wissen möchten, welche Kosten für Ihren Anwendungsfall entstehen, können Sie die entsprechenden Variablen an Ihre voraussichtliche Nutzung anpassen.

Beitragende

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

Hauptautor:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte