Zero-Trust-Netzwerk für Webanwendungen mit Azure Firewall und Anwendungsgateway

In diesem Leitfaden wird eine Strategie für die Implementierung Zero-Trust- Sicherheit für Web-Apps zur Überprüfung und Verschlüsselung beschrieben. Das Zero-Trust-Paradigma umfasst viele andere Konzepte, z. B. die ständige Überprüfung der Identität der Akteure oder die Verringerung der Größe der impliziten Vertrauensbereiche auf ein Minimum. Dieser Artikel bezieht sich auf die Verschlüsselungs- und Inspektionskomponente einer Zero-Trust-Architektur für datenverkehrsgebunden aus dem öffentlichen Internet. Lesen Sie weitere Zero-Trust-Dokumente für weitere Aspekte der sicheren Bereitstellung Ihrer Anwendung, z. B. Authentifizierung. Für den Zweck dieses Artikels funktioniert ein mehrschichtiger Ansatz am besten, bei dem die Netzwerksicherheit eine der Ebenen des Zero-Trust-Modells bildet. In dieser Ebene prüfen Netzwerkgeräte Pakete, um sicherzustellen, dass nur legitimer Datenverkehr Anwendungen erreicht.

In der Regel untersuchen unterschiedliche Netzwerkgerätetypen unterschiedliche Aspekte von Netzwerkpaketen:

• Webanwendungsfirewalls suchen nach Mustern, die auf einen Angriff auf der Webanwendungsebene hinweisen.
• Firewalls der nächsten Generation können auch nach generischen Bedrohungen suchen.

In einigen Situationen können Sie verschiedene Arten von Netzwerksicherheitsgeräten kombinieren, um den Schutz zu erhöhen. Ein separates Handbuch, Firewall und Anwendungsgateway für virtuelle Netzwerke, beschreibt Entwurfsmuster, mit denen Sie die verschiedenen Appliances anordnen können. Dieses Dokument konzentriert sich auf ein gängiges Muster zur Maximierung der Sicherheit, bei dem Azure Application Gateway vor Azure Firewall Premium fungiert. Das folgende Diagramm veranschaulicht dieses Muster:

Laden Sie eine Visio-Datei dieser Architektur herunter.

Diese Architektur verwendet das TLS-Protokoll (Transport Layer Security), um Datenverkehr in jedem Schritt zu verschlüsseln.

• Ein Client sendet Pakete an das Anwendungsgateway, einen Lastenausgleich. Sie wird mit der optionalen Ergänzung Azure Web Application Firewallausgeführt.

• Das Anwendungsgateway entschlüsselt die Pakete und sucht nach Bedrohungen für Webanwendungen. Wenn keine Bedrohungen gefunden werden, verwendet sie null vertrauenswürdige Prinzipien, um die Pakete zu verschlüsseln. Anschließend wird sie freigegeben.

• Azure Firewall Premium führt Sicherheitsprüfungen aus:

  • TRANSPORT Layer Security (TLS)-Inspektion entschlüsselt und untersucht die Pakete.
  • Angriffserkennung und -schutz Features überprüfen die Pakete auf böswillige Absichten.

• Wenn die Pakete die Tests bestehen, führt Azure Firewall Premium die folgenden Schritte aus:

  • Verschlüsselt die Pakete
  • Verwendet einen DNS-Dienst (Domain Name System), um den virtuellen Anwendungscomputer (VM) zu ermitteln.
  • Leitet die Pakete an den virtuellen Anwendungscomputer weiter.

Verschiedene Inspektionsmodule in dieser Architektur stellen die Datenverkehrsintegrität sicher:

• Die Webanwendungsfirewall verwendet Regeln, um Angriffe auf der Webebene zu verhindern. Beispiele für Angriffe sind sql code injection und cross-site scripting. Weitere Informationen zu Regeln und dem OWASP-Kernregelsatz (Open Web Application Security Project) finden Sie unter Webanwendungsfirewall CRS-Regelgruppen und -regeln.
• Azure Firewall Premium verwendet allgemeine Regeln zur Erkennung und Verhinderung von Angriffen. Diese Regeln helfen dabei, schädliche Dateien und andere Bedrohungen zu identifizieren, die auf Webanwendungen abzielen.

Diese Architektur unterstützt verschiedene Arten von Netzwerkdesign, die in diesem Artikel erläutert werden:

• Herkömmliche Hub- und Spoke-Netzwerke
• Netzwerke, die Azure Virtual WAN als Plattform verwenden
• Netzwerke, die Azure Route Server verwenden, um das dynamische Routing zu vereinfachen

Azure Firewall Premium und Namensauflösung

Bei der Überprüfung auf böswilligen Datenverkehr überprüft Azure Firewall Premium, ob der HTTP-Hostheader mit der Paket-IP-Adresse und dem TCP-Port übereinstimmt. Angenommen, Anwendungsgateway sendet Webpakete an die IP-Adresse 172.16.1.4 und TCP-Port 443. Der Wert des HTTP-Hostheaders sollte in diese IP-Adresse aufgelöst werden.

HTTP-Hostheader enthalten in der Regel keine IP-Adressen. Stattdessen enthalten die Header Namen, die dem digitalen Zertifikat des Servers entsprechen. In diesem Fall verwendet Azure Firewall Premium DNS, um den Hostheadernamen in eine IP-Adresse aufzulösen. Das Netzwerkdesign bestimmt, welche DNS-Lösung am besten funktioniert, wie in späteren Abschnitten beschrieben.

Digitale Zertifikate

Das folgende Diagramm zeigt die allgemeinen Namen (CNs) und Zertifizierungsstellen (CAs), die von den TLS-Sitzungen und Zertifikaten der Architektur verwendet werden:

TLS-Verbindungen

Diese Architektur enthält drei unterschiedliche TLS-Verbindungen. Digitale Zertifikate überprüfen jeweils:

Von Clients zu Anwendungsgateway

Im Anwendungsgateway stellen Sie das digitale Zertifikat bereit, das Clients sehen. Eine bekannte Zertifizierungsstelle wie DigiCert oder Let's Encrypt stellt in der Regel ein solches Zertifikat aus.

Vom Anwendungsgateway zu Azure Firewall Premium

Um TLS-Datenverkehr zu entschlüsseln und zu prüfen, generiert Azure Firewall Premium dynamisch Zertifikate. Azure Firewall Premium präsentiert sich auch als Webserver für das Anwendungsgateway. Eine private Zertifizierungsstelle signiert die Zertifikate, die Azure Firewall Premium generiert. Weitere Informationen finden Sie unter Azure Firewall Premium-Zertifikate. Das Anwendungsgateway muss diese Zertifikate überprüfen. In den HTTP-Einstellungen der Anwendung konfigurieren Sie die Stammzertifizierungsstelle, die Azure Firewall Premium verwendet.

Von Azure Firewall Premium zum Webserver

Azure Firewall Premium richtet eine TLS-Sitzung mit dem Zielwebserver ein. Azure Firewall Premium überprüft, ob eine bekannte Zertifizierungsstelle die TLS-Pakete des Webservers signiert.

Komponentenrollen

Anwendungsgateway und Azure Firewall Premium behandeln Zertifikate anders als beieinander, da sich ihre Rollen unterscheiden:

• Das Anwendungsgateway ist ein Reversewebproxy-. Sie schützt Webserver vor böswilligen Clients, indem http- und HTTPS-Anforderungen abgefangen werden. Sie deklarieren jeden geschützten Server im Back-End-Pool des Anwendungsgateways mit seiner IP-Adresse oder vollqualifizierten Domänennamen. Legitime Clients sollten auf jede Anwendung zugreifen können. Daher konfigurieren Sie das Anwendungsgateway mit einem digitalen Zertifikat, das eine öffentliche Zertifizierungsstelle signiert hat. Verwenden Sie eine Zertifizierungsstelle, die von jedem TLS-Client akzeptiert wird.
• Azure Firewall Premium ist ein Weiterleitungswebproxy oder einfach ein Webproxy. Sie schützt Clients vor böswilligen Webservern, indem TLS-Aufrufe von den geschützten Clients abgefangen werden. Wenn ein geschützter Client eine HTTP-Anforderung sendet, übernimmt der Weiterleitungsproxy den Identitätswechsel des Zielwebservers, indem digitale Zertifikate generiert und dem Client präsentiert werden. Azure Firewall Premium verwendet eine private Zertifizierungsstelle, die die dynamisch generierten Zertifikate signiert. Sie konfigurieren die geschützten Clients so, dass sie dieser privaten Zertifizierungsstelle vertrauen. In dieser Architektur schützt Azure Firewall Premium Anforderungen vom Anwendungsgateway an den Webserver. Das Anwendungsgateway vertraut der privaten Zertifizierungsstelle, die Azure Firewall Premium verwendet.

Routing und Datenverkehrsweiterleitung

Das Routing unterscheidet sich je nach Topologie Ihres Netzwerkentwurfs geringfügig. In den folgenden Abschnitten werden die Einzelheiten der Beispiele für Hub- und Spoke-, Virtual WAN- und Routingservertopologie erläutert. Es gibt jedoch einige Aspekte, die allen Topologien gemeinsam sind:

• Das Azure-Anwendungsgateway verhält sich immer als Proxy, und Azure Firewall Premium verhält sich auch bei der Konfiguration für die TLS-Inspektion: Die TLS-Sitzungen von Clients werden vom Anwendungsgateway beendet, und neue TLS-Sitzungen werden in Richtung Azure Firewall erstellt. Azure Firewall empfängt und beendet die TLS-Sitzungen, die vom Anwendungsgateway stammen, und erstellt neue TLS-Sitzungen für die Workloads. Diese Tatsache hat Auswirkungen auf die IDPS-Konfiguration von Azure Firewall Premium, Abschnitte weiter unten enthalten weitere Details dazu.
• Die Workload sieht Verbindungen aus der Subnetz-IP-Adresse der Azure-Firewall. Die ursprüngliche Client-IP-Adresse wird im vom Anwendungsgateway eingefügten X-Forwarded-For HTTP-Header beibehalten.
• Datenverkehr vom Anwendungsgateway an die Workload wird in der Regel mithilfe von Azure-Routingmechanismen an die Azure-Firewall gesendet, entweder mit User-Defined Routen, die im Subnetz des Anwendungsgateways konfiguriert sind, oder mit Routen, die von Azure Virtual WAN oder Azure Route Server eingefügt werden. Obwohl die explizite Definition der privaten IP-Adresse der Azure Firewall im Back-End-Pool des Anwendungsgateways möglich ist, wird es technisch nicht empfohlen, da einige der Funktionen der Azure-Firewall wie Lastenausgleich und Klebigkeit entfernt werden.

In den folgenden Abschnitten werden einige der am häufigsten verwendeten Topologien für Azure Firewall und Application Gateway ausführlich beschrieben.

Hub- und Speichentopologie

In der Regel stellt ein Hub- und Spoke-Design gemeinsam genutzte Netzwerkkomponenten im virtuellen Hubnetzwerk und anwendungsspezifische Komponenten in den Speichen bereit. In den meisten Systemen ist Azure Firewall Premium eine freigegebene Ressource. Die Webanwendungsfirewall kann jedoch ein freigegebenes Netzwerkgerät oder eine anwendungsspezifische Komponente sein. Aus den folgenden Gründen ist es in der Regel am besten, Anwendungsgateway als Anwendungskomponente zu behandeln und in einem virtuellen Speichennetzwerk bereitzustellen:

• Es kann schwierig sein, Webanwendungsfirewall-Warnungen zu behandeln. In der Regel benötigen Sie fundierte Kenntnisse der Anwendung, um zu entscheiden, ob die Nachrichten, die diese Alarme auslösen, legitim sind.
• Wenn Sie Das Anwendungsgateway als freigegebene Ressource behandeln, überschreiten Sie möglicherweise Azure-Anwendungsgateway-Grenzwerte.
• Möglicherweise treten rollenbasierte Zugriffssteuerungsprobleme auf, wenn Sie das Anwendungsgateway im Hub bereitstellen. Diese Situation kann entstehen, wenn Teams verschiedene Anwendungen verwalten, aber dieselbe Instanz des Anwendungsgateways verwenden. Jedes Team hat dann Zugriff auf die gesamte Anwendungsgateway-Konfiguration.

Mit herkömmlichen Hub- und Spoke-Architekturen bieten DNS-private Zonen eine einfache Möglichkeit, DNS zu verwenden:

• Konfigurieren Sie eine private DNS-Zone.
• Verknüpfen Sie die Zone mit dem virtuellen Netzwerk, das Azure Firewall Premium enthält.
• Stellen Sie sicher, dass ein A-Eintrag für den Wert vorhanden ist, den Das Anwendungsgateway für Datenverkehr und Integritätsprüfungen verwendet.

Das folgende Diagramm zeigt den Paketfluss, wenn sich das Anwendungsgateway in einem virtuellen Speichennetzwerk befindet. In diesem Fall stellt ein Client eine Verbindung aus dem öffentlichen Internet her.

1. Ein Client sendet eine Anforderung an einen Webserver.
2. Das Anwendungsgateway fängt die Clientpakete ab und untersucht sie. Wenn die Pakete die Prüfung bestehen, sendet das Anwendungsgateway das Paket an die Back-End-VM. Wenn das Paket auf Azure trifft, leitet eine benutzerdefinierte Route (UDR) im Anwendungsgateway-Subnetz die Pakete an Azure Firewall Premium weiter.
3. Azure Firewall Premium führt Sicherheitsprüfungen für die Pakete aus. Wenn sie die Tests bestehen, leitet Azure Firewall Premium die Pakete an den virtuellen Anwendungscomputer weiter.
4. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf das Anwendungsgateway fest. Ein UDR im VM-Subnetz leitet die Pakete zu Azure Firewall Premium um.
5. Azure Firewall Premium leitet die Pakete an das Anwendungsgateway weiter.
6. Das Anwendungsgateway antwortt auf den Client.

Der Datenverkehr kann auch über ein lokales Netzwerk statt aus dem öffentlichen Internet eingehen. Der Datenverkehr fließt entweder über ein standortbasiertes virtuelles privates Netzwerk (VPN) oder über ExpressRoute. In diesem Szenario erreicht der Datenverkehr zuerst ein virtuelles Netzwerkgateway im Hub. Der rest des Netzwerkflusses entspricht dem vorherigen Fall.

1. Ein lokaler Client stellt eine Verbindung mit dem virtuellen Netzwerkgateway bereit.
2. Das Gateway leitet die Clientpakete an das Anwendungsgateway weiter.
3. Das Anwendungsgateway untersucht die Pakete. Wenn sie die Prüfung bestehen, leitet ein UDR im Anwendungsgateway-Subnetz die Pakete an Azure Firewall Premium weiter.
4. Azure Firewall Premium führt Sicherheitsprüfungen für die Pakete aus. Wenn sie die Tests bestehen, leitet Azure Firewall Premium die Pakete an den virtuellen Anwendungscomputer weiter.
5. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf das Anwendungsgateway fest. Ein UDR im VM-Subnetz leitet die Pakete zu Azure Firewall Premium um.
6. Azure Firewall Premium leitet die Pakete an das Anwendungsgateway weiter.
7. Das Anwendungsgateway sendet die Pakete an das virtuelle Netzwerkgateway.
8. Das Gateway antwortt auf den Client.

Virtuelle WAN-Topologie

Sie können den Netzwerkdienst auch virtual WAN- in dieser Architektur verwenden. Diese Komponente bietet viele Vorteile. So entfällt beispielsweise die Notwendigkeit von BENUTZER-verwalteten UDRs in virtuellen Speichennetzwerken. Sie können stattdessen statische Routen in Virtuellen Hub-Routentabellen definieren. Die Programmierung jedes virtuellen Netzwerks, das Sie mit dem Hub verbinden, enthält dann diese Routen.

Wenn Sie Virtual WAN als Netzwerkplattform verwenden, ergeben sich zwei Hauptunterschiede:

• Sie können DNS-private Zonen nicht mit einem virtuellen Hub verknüpfen, da Microsoft virtuelle Hubs verwaltet. Als Abonnementbesitzer verfügen Sie nicht über Berechtigungen zum Verknüpfen privater DNS-Zonen. Daher können Sie keine PRIVATE DNS-Zone mit dem sicheren Hub verknüpfen, der Azure Firewall Premium enthält. Um die DNS-Auflösung für Azure Firewall Premium zu implementieren, verwenden Sie stattdessen DNS-Server:

  • Konfigurieren Sie die Azure Firewall-DNS-Einstellungen für die Verwendung benutzerdefinierter DNS-Server.
  • Stellen Sie die Server in einem virtuellen Netzwerk für gemeinsame Dienste bereit, das Sie mit dem virtuellen WAN verbinden.
  • Verknüpfen Sie eine private DNS-Zone mit dem virtuellen Netzwerk für gemeinsame Dienste. Die DNS-Server können dann die Namen auflösen, die das Anwendungsgateway in HTTP-Hostheadern verwendet. Weitere Informationen finden Sie unter Azure Firewall DNS Settings.

• Sie können virtual WAN nur verwenden, um Routen in einer Speichen zu programmieren, wenn das Präfix kürzer (weniger spezifisch) als das Präfix des virtuellen Netzwerks ist. In den Diagrammen über dem Speichen-VNet ist beispielsweise das Präfix 172.16.0.0/16 vorhanden: in diesem Fall: Virtual WAN könnte keine Route einfügen, die dem VNet-Präfix (172.16.0.0/16) oder einem der Subnetze (172.16.0.0/24, 172.16.1.0/24) entspricht. Mit anderen Worten: Virtuelles WAN kann keinen Datenverkehr zwischen zwei Subnetzen gewinnen, die sich im selben VNet befinden. Diese Einschränkung wird deutlich, wenn sich anwendungsgateway und der Zielwebserver im selben virtuellen Netzwerk befinden: Virtual WAN kann nicht erzwingen, dass der Datenverkehr zwischen Dem Anwendungsgateway und dem Webserver durch Azure Firewall Premium geleitet wird (eine Problemumgehung wäre manuell das Konfigurieren von benutzerdefinierten Routen in den Subnetzen des Anwendungsgateways und Webservers).

Das folgende Diagramm zeigt den Paketfluss in einem Fall, in dem virtual WAN verwendet wird. In dieser Situation erfolgt der Zugriff auf das Anwendungsgateway über ein lokales Netzwerk. Ein Standort-zu-Standort-VPN oder ExpressRoute verbindet dieses Netzwerk mit virtual WAN. Der Zugriff über das Internet ist ähnlich.

1. Ein lokaler Client stellt eine Verbindung mit dem VPN bereit.
2. Das VPN leitet die Clientpakete an das Anwendungsgateway weiter.
3. Das Anwendungsgateway untersucht die Pakete. Wenn sie die Prüfung bestehen, leitet das Anwendungsgateway-Subnetz die Pakete an Azure Firewall Premium weiter.
4. Azure Firewall Premium fordert DNS-Auflösung von einem DNS-Server im virtuellen Netzwerk für gemeinsame Dienste an.
5. Der DNS-Server beantwortet die Lösungsanforderung.
6. Azure Firewall Premium führt Sicherheitsprüfungen für die Pakete aus. Wenn sie die Tests bestehen, leitet Azure Firewall Premium die Pakete an den virtuellen Anwendungscomputer weiter.
7. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf das Anwendungsgateway fest. Das Anwendungssubnetz leitet die Pakete zu Azure Firewall Premium um.
8. Azure Firewall Premium leitet die Pakete an das Anwendungsgateway weiter.
9. Das Anwendungsgateway sendet die Pakete an das VPN.
10. Das VPN antwortt auf den Client.

Mit diesem Design müssen Sie möglicherweise das Routing ändern, das der Hub für die virtuellen Speichennetzwerke angibt. Insbesondere unterstützt Application Gateway v2 nur eine Route von 0.0.0.0/0, die auf das Internet verweist. Routes with this address that don't point to the internet break the connectivity that Microsoft requires for managing Application Gateway. Wenn Ihr virtueller Hub eine Route von 0.0.0.0/0 angibt, verhindern Sie, dass diese Route an das Subnetz des Anwendungsgateways weitergegeben wird, indem Sie eine der folgenden Schritte ausführen:

• Erstellen Sie eine Routentabelle mit einer Route für 0.0.0.0/0 und einem nächsten Hoptyp von Internet. Ordnen Sie diese Route dem Subnetz zu, in dem Sie Das Anwendungsgateway bereitstellen.
• Wenn Sie das Anwendungsgateway in einer dedizierten Speichen bereitstellen, deaktivieren Sie die Verteilung der Standardroute in den Einstellungen für die virtuelle Netzwerkverbindung.

Routenservertopologie

Route Server bietet eine weitere Möglichkeit zum automatischen Einfügen von Routen in Speichen. Mit dieser Funktionalität vermeiden Sie den verwaltungstechnischen Aufwand beim Verwalten von Routentabellen. Route Server kombiniert virtuelle WAN- und Hub- und Speichenvarianten:

• Mit Route Server verwalten Kunden virtuelle Hubnetzwerke. Daher können Sie das virtuelle Hubnetzwerk mit einer privaten DNS-Zone verknüpfen.
• Route Server hat dieselbe Einschränkung wie virtuelles WAN bezüglich IP-Adresspräfixen. Sie können Routen nur in eine Speichen einfügen, wenn das Präfix kürzer (weniger spezifisch) als das Präfix des virtuellen Netzwerks ist. Aufgrund dieser Einschränkung muss sich das Anwendungsgateway und der Zielwebserver in verschiedenen virtuellen Netzwerken befinden.

Das folgende Diagramm zeigt den Paketfluss, wenn Route Server das dynamische Routing vereinfacht. Beachten Sie die folgenden Punkte:

• Route Server erfordert derzeit das Gerät, das die Routen eingibt, um sie über das Border Gateway Protocol (BGP) zu senden. Da Azure Firewall Premium BGP nicht unterstützt, verwenden Sie stattdessen eine Network Virtual Appliance (NVA) eines Drittanbieters.
• Die Funktionalität des NVA im Hub bestimmt, ob Ihre Implementierung DNS benötigt.

1. Ein lokaler Client stellt eine Verbindung mit dem virtuellen Netzwerkgateway bereit.
2. Das Gateway leitet die Clientpakete an das Anwendungsgateway weiter.
3. Das Anwendungsgateway untersucht die Pakete. Wenn sie die Überprüfung bestehen, leitet das Application Gateway-Subnetz die Pakete an einen Back-End-Computer weiter. Eine Vom Route Server eingefügte Route im ApplicationGateway-Subnetz leitet den Datenverkehr an eine NVA weiter.
4. Der NVA führt Sicherheitskontrollen für die Pakete aus. Wenn sie die Tests bestehen, leitet die NVA die Pakete an den virtuellen Anwendungscomputer weiter.
5. Der virtuelle Computer antwortet und legt die Ziel-IP-Adresse auf das Anwendungsgateway fest. Eine route, die vom Routingserver in das VM-Subnetz eingefügt wird, leitet die Pakete an die NVA um.
6. Der NVA leitet die Pakete an das Anwendungsgateway weiter.
7. Das Anwendungsgateway sendet die Pakete an das virtuelle Netzwerkgateway.
8. Das Gateway antwortt auf den Client.

Wie bei virtual WAN müssen Sie möglicherweise das Routing ändern, wenn Sie Route Server verwenden. Wenn Sie die Route "0.0.0.0/0" ankündigen, wird sie möglicherweise an das Anwendungsgateway-Subnetz weitergegeben. Das Anwendungsgateway unterstützt diese Route jedoch nicht. Konfigurieren Sie in diesem Fall eine Routentabelle für das Anwendungsgateway-Subnetz. Fügen Sie eine Route für 0.0.0.0/0 und einen nächsten Hoptyp von Internet in diese Tabelle ein.

IDPS und private IP-Adressen

Wie in Azure Firewall IDPS Ruleserläutert, entscheidet Azure Firewall Premium, welche IDPS-Regeln je nach Quell- und Ziel-IP-Adressen der Pakete angewendet werden sollen. Azure Firewall behandelt standardmäßig private IP-Adressen in den RFC 1918-Bereichen (10.0.0.0/8, 192.168.0.0/16 und 172.16.0.0/12) und RFC 6598-Bereich (100.64.0.0/10) als intern. Wenn das Anwendungsgateway wie in den Diagrammen in diesem Artikel in einem Subnetz in einem dieser Bereiche bereitgestellt wird (172.16.0.0/24 in den obigen Beispielen), berücksichtigt Azure Firewall Premium den Datenverkehr zwischen dem Anwendungsgateway und der Workload als intern, und es werden nur IDPS-Signaturen verwendet, die auf internen Datenverkehr oder auf jeden Datenverkehr angewendet werden. IDPS-Signaturen, die für eingehenden oder ausgehenden Datenverkehr angewendet werden sollen, werden nicht auf den Datenverkehr zwischen dem Anwendungsgateway und der Workload angewendet.

Die einfachste Möglichkeit zum Erzwingen von IDPS-Regeln für eingehende Signaturen, die auf den Datenverkehr zwischen Dem Anwendungsgateway und der Workload angewendet werden, besteht darin, das Anwendungsgateway in einem Subnetz mit einem Präfix außerhalb der privaten Bereiche zu platzieren. Sie müssen nicht unbedingt öffentliche IP-Adressen für dieses Subnetz verwenden, sondern sie können die IP-Adressen anpassen, die Azure Firewall Premium als intern für IDPS behandelt. Wenn Ihre Organisation z. B. den 100.64.0.0/10 Bereich nicht verwendet, können Sie diesen Bereich aus der Liste der internen Präfixe für IDPS entfernen (siehe privaten IPDS-Bereiche von Azure Firewall Premium weitere Informationen dazu) und das Anwendungsgateway in einem Subnetz bereitstellen, das mit einer IP-Adresse in 100.64.0.0/10konfiguriert ist.

Beitragende

Dieser Artikel wird von Microsoft verwaltet. Sie wurde ursprünglich von den folgenden Mitwirkenden verfasst.

Hauptautor:

• Jose Moreno | Principal Customer Engineer

Nächste Schritte

• Sichere Netzwerke mit null vertrauenswürdigen
• Routing virtueller Netzwerkdatenverkehr
• Funktionsweise eines Anwendungsgateways

Verwandte Ressourcen

• [Sichern und Steuern von Workloads mit Segmentierung auf Netzwerkebene][Sichern und Steuern von Workloads mit Segmentierung auf Netzwerkebene]
• Implementieren eines sicheren Hybridnetzwerks
• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN