Interneteingang: Machen Sie Ihre Anwendung für das Internet verfügbar

Dieser Artikel hilft Ihnen, den richtigen Azure Dienst auszuwählen, um Ihre Anwendung über das Internet erreichbar zu machen. Es vergleicht öffentliche IP-Adressen, Azure Load Balancer, Anwendungsgateway, Azure Front Door und Azure Traffic Manager. Wählen Sie die Option aus, die den Protokoll-, Skalierungs- und Sicherheitsanforderungen Ihrer Workload entspricht.

Inhalt dieses Artikels

Jede Azure Workload, die externen Benutzern dient, benötigt einen Eingangspfad: eine Möglichkeit für Internetdatenverkehr, ihre Anwendung sicher und zuverlässig zu erreichen. Die Wahl des falschen Ingress-Dienstes führt zu Überprovisionierung, Sicherheitslücken oder unnötiger Komplexität. Dieser Artikel hilft Ihnen, sieben Azure Dienste zu bewerten, die eingehende Verbindungen von externen Benutzern akzeptieren und diese Verbindungen an Ihre Back-End-Ressourcen innerhalb eines virtuellen Netzwerks weiterleiten. Sie können die Kombination auswählen, die Ihrem Protokoll, Ihrem Maßstab, Ihrer Geografie und Ihrem Sicherheitsstatus entspricht.

Note

Dieser Artikel befasst sich damit, wie Datenverkehr aus dem Internet in Ihr Azure-Netzwerk gelangt. Informationen zum Ausgleich und Bereitstellen dieses Datenverkehrs über Ihre Anwendungs-Back-Ends hinweg (einschließlich detaillierter Vergleiche von Azure Load Balancer, Anwendungsgateway und Azure Front Door), finden Sie unter Anwendungsbereitstellung und -leistung.

Wer diesen Artikel benötigt

Lesen Sie diesen Artikel, wenn eine oder mehrere dieser Bedingungen gelten:

• Ihre Anwendung muss eingehende Verbindungen von Benutzern oder Systemen im Internet akzeptieren.
• Sie müssen basierend auf Protokoll und Umfang zwischen öffentlichem IP, Load Balancer, Anwendungsgateway, Front Door oder Traffic Manager wählen.
• Sie müssen einen sicheren öffentlichen Einstiegspunkt für Web-, API- oder TCP/UDP-Workloads entwerfen.
• Sie müssen die Internetexposition mit WAF, DDoS-Schutz, TLS-Beendigung oder regionaler und globaler Datenverkehrsverteilung kombinieren.

Tip

Einem Szenariopfad folgen? Wählen Sie Ihr Szenario oben auf der Seite aus, um eine maßgeschneiderte Anleitung zu erhalten. Der folgende Kernleitfaden gilt für alle Leser.

Heben und Verschieben des Fokus: Ihre migrierte App muss über das Internet erreichbar sein. Bewerten Sie, ob Sie anwendungsgateway, Front Door oder einen einfacheren öffentlichen IP-Ansatz benötigen. Viele Lift-and-Shift-Workloads sind nur intern, daher können Sie diesen Artikel vollständig überspringen, wenn Ihre migrierten Apps keine externen Benutzer bedienen.

Lesen Sie diesen Artikel, wenn Sie:

• Migrieren Sie eine lokale Webanwendung zu Azure und müssen entscheiden, wie sie öffentlich verfügbar gemacht werden soll.
• Sie müssen auswerten, ob für Ihre migrierten Workloads überhaupt ein Interneteingang erforderlich ist.
• Sie möchten die einfachste produktionsfertige Eingangsoption für eine angehobene Anwendung verstehen.

Modernisierungsfokus: Kundenbezogene Datenverkehrsmuster bestimmen die externe Form Ihrer Architektur. Front Door verarbeitet Web-Apps, Traffic Manager verarbeitet mobile und API-Apps. Ihre modernisierten PaaS-Workloads (App Service, AKS) benötigen einen klar definierten Eingangspfad, der in Ihr Hub-Spoke-Sicherheitsmodell integriert wird.

Lesen Sie diesen Artikel, wenn Sie:

• Stellen Sie eine öffentlich zugängliche Anwendung bereit, auf die externe Benutzer über das Internet zugreifen.
• Sie müssen zwischen Azure Front Door für Webanwendungen und Traffic Manager für mobile oder API-Workloads wählen.
• Sie möchten verstehen, wie Ingress als DNAT-Ziel in Ihre Hub-Firewall integriert wird.
• Über das Internet erreichbare Endpunkte müssen mit einer Webanwendungsfirewall (WAF) oder DDoS-Schutz geschützt werden.

Cloudübergreifender Fokus: Schließen Sie nur den Interneteingang ein, wenn die migrierte App öffentlich zugänglich ist. Viele cloudübergreifende Anwendungen sind nur intern und kommunizieren zwischen Clouds über private Transitpfade. Wenn Ihre Workload öffentlich zugänglich ist (z. B. eine kundenorientierte Web-App, die aus einer anderen Cloud migriert wurde), benötigen Sie einen Eingangspfad in Azure.

Lesen Sie diesen Artikel, wenn Sie:

• Migrieren Sie eine öffentlich zugängliche Anwendung von AWS oder Google Cloud zu Azure.
• Sie benötigen das Application Gateway mit WAF in einem Speichen-VNet für den migrierten Workload.
• Sie möchten die direkte öffentliche IP-Zuweisung zu virtuellen Computern während der cloudübergreifenden Migration vermeiden.

Azure Dienste und Features

Azure bietet mehrere Dienste für eingehenden Internetdatenverkehr. Jeder Dienst arbeitet auf einer anderen Ebene des Netzwerkstapels und dient einem anderen Anwendungsfall.

Service	Ebene	Geltungsbereich	Was es bietet	Wann wird es verwendet?
Öffentliche IP-Adresse (Standard-SKU)	3	Länderspezifisch	Direkt zugewiesene routingfähige IPv4- oder IPv6-Adresse. Standardmäßig zonenredundant.	Einfache Szenarien mit geringem Datenverkehr. Nicht für die Produktion ohne Lastenausgleich empfohlen.
Azure Load Balancer (Standard, öffentlich)	4 (TCP/UDP)	Länderspezifisch	Verteilt eingehenden TCP/UDP-Datenverkehr über Back-End-VMs. Zonenredundanter Frontend. Integritätstests entfernen fehlerhafte Instanzen.	Nicht-HTTP/S-Workloads, die hohe Verfügbarkeit erfordern. Gaming-Server, IoT-Endpunkte oder andere TCP/UDP-Dienste.
Azure Load Balancer (Standard, intern)	4 (TCP/UDP)	Länderspezifisch	Lastenausgleich der Ebene 4 in einem virtuellen Netzwerk. Keine öffentliche IP. Leitet den Datenverkehr zwischen internen Ebenen weiter.	Mehrstufige Apps, bei denen ein öffentliches Frontend Anfragen an Backend-VMs weiterleitet. Hub-and-Spoke Ost-West-Verkehr. Nicht direkt aus dem Internet erreichbar, aber häufig in Kombination mit einem öffentlichen Eingangsdienst eingesetzt.
Azure Application Gateway	7 (HTTP/S)	Länderspezifisch	HTTP/S-Lastenausgleich mit URL-basiertem Routing, SSL/TLS-Terminierung, Sitzungsaffinität und automatischer Skalierung.	HTTP/S-Apps in einer einzelnen Region, die pfadbasiertes Routing, cookiebasierte Sitzungsaffinität oder SSL-Offload erfordern.
Anwendungsgateway + WAF	7 (HTTP/S)	Länderspezifisch	Anwendungsgateway mit Web Application Firewall. Schützt vor OWASP top 10-Angriffen mithilfe des Standardregelsatzes (Default Rule Set, DRS), einschließlich Microsoft Threat Intelligence-Regeln.	Öffentlich zugängliche Web-Apps, die Layer 7-Lastenausgleich und WAF-Schutz in einer einzelnen Region erfordern.
Azure Front Door – der Dienst für Web-Traffic-Management	7 (HTTP/S)	Global	Globaler HTTP/S-Lastenausgleich mit integriertem CDN, WAF und Datenverkehrsrouting. Terminiert TCP/TLS an Edge-PoPs in Nutzernähe mithilfe von Split-TCP-Beschleunigung.	Apps mit mehreren Regionen mit einer globalen Benutzerbasis. Workloads, die CDN-Caching, globale WAF und automatisches Failover erfordern.
Azure Traffic Manager	DNS	Global	DNS-basiertes Datenverkehrsrouting. Gibt einen CNAME an den nächstgelegenen oder gesündersten regionalen Endpunkt zurück. Clients stellen eine direkte Verbindung her. Traffic Manager hat niemals Zugriff auf den Anwendungsdatenverkehr.	Failover auf DNS-Ebene auf mehreren Regionen. Nicht-HTTP/S-Protokolle, bei denen Front Door nicht angewendet wird. Routing nach Geografie, Leistung oder Priorität.

Note

Öffentliche IP-Adressen der Basic-SKU werden außer Betrieb genommen (September 2025). Vorhandene Grundlegende IPs bleiben funktionsfähig, werden jedoch ohne SLA nicht unterstützt. Verwenden Sie die Standard-SKU für alle neuen Bereitstellungen.

Funktionsweise der einzelnen Dienste

Das Verständnis der internen Architektur jedes Diensts hilft Ihnen, die Leistung vorherzusagen, Probleme zu beheben und Subnetzgröße zu planen.

Öffentliche IP-Adresse

Eine öffentliche Standard-SKU-IP ist eine softwaredefinierte Ressource, die eine routingfähige IPv4- oder IPv6-Adresse direkt einer Netzwerkschnittstelle, einem Lastenausgleichs-Frontend oder einem Gateway zuordnet. Die Adresse ist in unterstützten Regionen standardmäßig zonenredundant, d. h., dass die Plattform das Failover über Verfügbarkeitszonen hinweg übernimmt, ohne dass Sie etwas ändern müssen. Öffentliche IPs haben keine Datenverkehrsverarbeitung. Pakete werden direkt an die zugeordnete Ressource weitergeleitet, ohne Zustandsprüfung oder Verteilungslogik.

Azure Load Balancer (Standard, öffentlich)

Load Balancer Standard verwendet einen Hash-basierten Verteilungsalgorithmus über 5-Tupelflüsse (Quell-IP, Quellport, Ziel-IP, Zielport, Protokoll). Sie arbeitet vollständig im Datenpfad auf Layer 4, sodass sie Verbindungen niemals terminiert oder Nutzdaten inspiziert. Integritätstests (TCP, HTTP oder HTTPS) rufen kontinuierlich Back-End-Instanzen ab und entfernen fehlerhafte Instanzen innerhalb von Sekunden aus der Drehung. Der Load Balancer skaliert automatisch. Es gibt keine Kapazitätsplanung oder Instanzgröße.

Azure Load Balancer (Standard, intern)

Der interne Load Balancer arbeitet nach dem gleichen Prinzip wie sein öffentliches Pendant, verwendet jedoch eine private Frontend-IP-Adresse aus dem Subnetz des virtuellen Netzwerks. Er verteilt Datenverkehr zwischen internen Ebenen, z. B. einer Webebene, die Datenverkehr an einen API-Cluster auf mittlerer Ebene sendet. Da es keine öffentliche IP hat, ist es für das Internet unsichtbar. Kombinieren Sie es mit einem öffentlichen Ingress-Dienst wie Front Door, Application Gateway oder einem öffentlichen Load Balancer, der den externen Perimeter übernimmt.

Azure Application Gateway

Application Gateway ist eine dedizierte virtuelle Appliance, die im Subnetz Ihres virtuellen Netzwerks bereitgestellt wird. Es beendet TLS-Verbindungen am Gateway, prüft HTTP-Header und URLs und leitet Anforderungen an Back-End-Pools basierend auf Pfadregeln, Hostheadern oder benutzerdefinierten Integritätssonden weiter. Die v2-SKU unterstützt die automatische Skalierung (0 bis 125 Instanzen) und Zonenredundanz. Da es in einem VNet bereitgestellt wird, kann es private Backends erreichen, ohne dass diese Backends öffentliche IP-Adressen benötigen.

Anwendungsgateway mit WAF

Wenn Sie die WAF-Ebene hinzufügen, aktivieren Sie den OWASP-Kernregelsatz und Microsoft Threat Intelligence-Regeln direkt in der Anwendungsgateway-Verarbeitungspipeline. Jede HTTP-Anfrage durchläuft die WAF-Engine, bevor sie die Routingregeln erreicht. Die WAF unterstützt Standortrichtlinien, sodass Sie unterschiedliche Regelkonfigurationen für unterschiedliche Listener- oder Hostkombinationen auf demselben Gateway haben können. WAF arbeitet entweder im Erkennungsmodus (nur protokolliert) oder im Verhinderungsmodus (blockiert und protokolliert).

Azure Front Door – der Dienst für Web-Traffic-Management

Front Door wird über das globale Edge-Netzwerk von Microsoft (190+ Points of Presence) betrieben. Wenn ein Benutzer eine Verbindung herstellt, erfolgt der TCP-Handshake und die TLS-Aushandlung an dem nächstgelegenen Anwesenheitspunkt mithilfe von Split TCP. Der Point of Presence hält eine dauerhaft offene Verbindung zu Ihrem Ursprungsserver aufrecht, sodass die Kaltstartlatenz entfällt, die Benutzer bei einer direkten Verbindung sonst erleben würden. Front Door führt Layer 7 Routing, WAF-Inspektion, Zwischenspeicherung und Komprimierung am Rand durch, bevor die Anforderung an den nächstgelegenen gesunden Ursprung über das Microsoft Backbone-Netzwerk weitergeleitet wird.

Azure Traffic Manager

Der Datenverkehrs-Manager ist ein DNS-basierter Dienst ohne Einbindung von Datenpfaden. Wenn ein Client Ihren Traffic Manager-Hostnamen auflöst, wird ein CNAME zurückgegeben, der je nach Ihrer Routingmethode (Priorität, Gewichtung, Leistung, geografisch, Mehrwert oder Subnetz) auf den fehlerfreiesten oder nächstgelegenen Endpunkt verweist. Der Datenverkehrs-Manager überprüft kontinuierlich die Endpunktintegrität und aktualisiert DNS-Antworten entsprechend. Da der Anwendungsdatenverkehr nie angezeigt wird, funktioniert es mit jedem Protokoll: HTTP, TCP, UDP oder proprietäre Protokolle.

Kostenmodellvergleich

Jeder Eingangsdienst folgt einem anderen Abrechnungsmodell. Verwenden Sie diese Tabelle, um die Kosten für Ihr erwartetes Datenverkehrsvolumen zu schätzen.

Service	Abrechnungsmodell	Wichtige Kostentreiber	Kostenlose Stufe oder enthaltene Funktionen
Öffentliche IP-Adresse	Pro Stunde (angefügt) + pro GB ausgehend	Anzahl der angefügten Stunden; Ausstiegsgebühren	Die ersten 100 GB ausgehender Datenverkehr pro Monat kostenlos (weltweit)
Standard-Lastenausgleich	Pro Stunde und pro Regel + pro verarbeitetem GB	Anzahl der Lastenausgleichsregeln; Durch den LB verarbeitete Daten	Nichts
Application Gateway	Pro Stunde pro Instanz + verbrauchte Kapazitätseinheiten	Instanzenstunden; Rechen-, Verbindungs- und Durchsatzkapazitätseinheiten	Nichts
Anwendungsgateway + WAF	Pro Stunde und Instanz (WAF-Preisstufe) + Kapazitätseinheiten	Wie beim Application Gateway, aber mit WAF-Stundensatz	Nichts
Azure Front Door – der Dienst für Web-Traffic-Management	pro Anfrage + pro übertragenem GB + WAF-Anfragen	Routinganforderungen, Datenübertragung von Edge zu Client, WAF-Regelbewertungen	Standardebene enthält einige Basisroutings
Azure Traffic Manager	pro Million DNS-Abfragen + pro Health-Check-Endpunkt	Volumen von DNS-Abfragen; Anzahl der überwachten Endpunkte	Die ersten 1 Milliarden Abfragen haben ein gestaffeltes Preisniveau

Tip

Bei Workloads mit geringem Datenverkehr (unter 1 Millionen Anforderungen pro Monat) kann das Modell pro Anforderung von Front Door kostengünstiger sein als die Fixkosten pro Stunde des Anwendungsgateways. Wenn der Datenverkehr wächst, werden Modelle pro Stunde vorhersehbarer. Führen Sie den Azure Preisrechner mit dem erwarteten Durchsatz aus, der verglichen werden soll.

Wie man auswählt

Verwenden Sie die folgenden Entscheidungstabellen, um den richtigen Eingangsdienst für Ihre Workload auszuwählen. Beginnen Sie mit der allgemeinen Entscheidungstabelle, und verwenden Sie dann den detaillierten Vergleich, um Ihre Auswahl zu bestätigen.

Application Gateway vs. Front Door vs. Traffic Manager

Diese Tabelle hilft Ihnen bei der Auswahl zwischen den drei gängigsten HTTP- und HTTPS-Eingangsdiensten.

Ihre Notwendigkeit	Empfohlener Dienst	Warum?
HTTP/S-Datenverkehr, einzelne Region, WAF-Schutz	Anwendungsgateway mit WAF	Regionaler Layer 7-Dienst mit pfadbasiertem Routing und WAF. Wird innerhalb Ihres virtuellen Netzwerks ausgeführt.
HTTP/S-Datenverkehr, Multi-Region, globale Benutzer, CDN + WAF	Azure Front Door – der Dienst für Web-Traffic-Management	Globaler Layer 7-Dienst, der an Edge-PoPs endet. Integriertes CDN, WAF und automatisches Failover.
Routing mit mehreren Regionen für Nicht-HTTP/S-Protokolle oder nur routing auf DNS-Ebene	Azure Traffic Manager	DNS-basiertes Routing, das mit jedem Protokoll funktioniert. Keine Verbindungsbeendigung.
Multi-Region-HTTP/S mit regionalen, an VNet gebundenen Verarbeitungsanforderungen	Anwendungsgateway + Datenverkehrs-Manager	Gültig für Workloads, die eine umfassende VNet-Integration oder regionale Datenhoheit mit regionaler WAF-Inspektion erfordern. Für die meisten HTTP/S-Szenarien mit mehreren Regionen bevorzugen Sie stattdessen Front Door.

Tip

Für die meisten multiregionsübergreifenden HTTP- und HTTPS-Workloads ist Front Door die bevorzugte Wahl gegenüber dem Anwendungsgateway in Kombination mit Traffic Manager. Front Door bietet integrierte WAF-, CDN- und automatisches Failover, ohne dass Sie mehrere regionale Anwendungsgatewayinstanzen verwalten müssen. Die Kombination aus Anwendungsgateway und Datenverkehrs-Manager bleibt für Workloads gültig, die regionale VNet-gebundene Verarbeitung erfordern, Private Link Ursprünge nur innerhalb eines VNet zugänglich sind, oder behördliche Anforderungen, die regionale Datenhoheit erfordern.

Vergleich der Ingress-Services

Verwenden Sie diesen detaillierten Vergleich, wenn Sie die Funktionen der einzelnen Dienste verstehen müssen.

Service	Ebene	Global oder regional	Verbindungsende	WAF verfügbar	Gesundheitsüberprüfungen	Am besten geeignet für:
Öffentliche IP-Adresse	3	Länderspezifisch	Nein (direkt zur VM)	Nein	Nein	Entwicklungs-/Test-, Single-Instance-Workloads ohne HA-Anforderung
Load Balancer Standard (öffentlich)	4	Länderspezifisch	Nein (Passthrough)	Nein	Ja (TCP, HTTP, HTTPS)	Nicht-HTTP-Workloads: Spiele, IoT, benutzerdefinierte TCP/UDP
Load Balancer Standard (intern)	4	Länderspezifisch	Nein (Durchleitung)	Nein	Ja (TCP, HTTP, HTTPS)	Interne Ebene hinter einem öffentlichen Eingangsdienst
Application Gateway	7	Länderspezifisch	Ja (TLS-Beendigung)	Nein (WAF-Stufe hinzufügen)	Ja (HTTP/S benutzerdefiniert)	HTTP/S für eine einzelne Region mit pfadbasiertem Routing
Anwendungsgateway + WAF	7	Länderspezifisch	Ja (TLS-Beendigung)	Ja (DRS-Regelwerk)	Ja (HTTP/S benutzerdefiniert)	Single-Region-Web-Apps, die WAF benötigen
Azure Front Door – der Dienst für Web-Traffic-Management	7	Global	Ja (Split TCP bei PoP)	Ja (integriert)	Ja (HTTP/S)	HTTP/S für mehrere Regionen mit weltweiter Beschleunigung
Azure Traffic Manager	DNS	Global	Nein (nur DNS)	Nein	Ja (HTTP/S, TCP)	Regionsübergreifendes Failover auf DNS-Ebene, für alle Protokolle

Architektur des Internetausgangs

Folgendes Diagramm zeigt gängige Muster für die Dienstverkettung von eingehendem Datenverkehr für Azure-Workloads. Jedes Muster kombiniert Layer 7- und Layer 4-Dienste, um einem bestimmten Protokoll, regionalen Bereich und Sicherheitsstatus zu entsprechen.

Häufige Eingangsmuster

Die folgenden Muster kombinieren mehrere Dienste für eine vollständige Eingangsarchitektur. Wählen Sie das Muster aus, das Ihren Protokollanforderungen, dem regionalen Bereich und dem Sicherheitsstatus entspricht.

Muster 1: Globale Webanwendung mit Edgesicherheit

Dienstleistungen: Front Door → Application Gateway (mit WAF) → VMs/Container

Szenario: Eine SaaS-Anwendung, die Kunden in Nordamerika, Europa und Asien bedient, benötigt globale Beschleunigung, DDoS-Schutz am Rand und regionales pfadbasiertes Routing an verschiedene Microservices.

Front Door beendet Benutzerverbindungen am nächstgelegenen Anwesenheitspunkt (PoP), wendet globale WAF-Regeln an und speichert statische Inhalte zwischen. Der Datenverkehr wird über das Microsoft-Backbone an den regionalen Application Gateway geleitet, der URL-basiertes Routing durchführt (z. B. /api/* zum API-Pool, /static/* zu einem Storage-Back-End). Dieses Muster bietet zwei Ebenen der WAF-Inspektion: eine am Rand und eine an der Region.

Muster 2: Multiregion-Nicht-HTTP mit DNS-Failover

Dienstleistungen: Traffic Manager → Load Balancer Standard (pro Region) → VMs

Szenario: Ein Spieleunternehmen führt dedizierte Spieleserver auf UDP-Port 7777 in drei Regionen aus. Spieler stellen automatisch eine Verbindung mit der nächstgelegenen gesunden Region her.

Der Datenverkehrs-Manager verwendet die Leistungsroutingmethode, um den DNS-Eintrag für die Region mit der niedrigsten Latenz zurückzugeben. Jede Region verfügt über einen Load Balancer Standard, der den UDP-Datenverkehr über ein Virtual Machine Scale Set hinweg verteilt. Wenn Integritätssonden einen regionalen Fehler erkennen, aktualisiert Traffic Manager DNS, um Spieler an die nächste Region weiterzuleiten.

Muster 3: Einfache regionale Web-App mit WAF

Dienstleistungen: Anwendungsgateway (mit WAF) → VMs

Szenario: Eine interne Branchenanwendung, die externen Partnern verfügbar gemacht wird. Einzelne Region, moderater Datenverkehr, benötigt OWASP-Schutz und TLS-Beendigung.

Application Gateway bietet pfadbasiertes Routing, cookiebasierte Affinität für die Sitzungsverwaltung und WAF-Schutz, alles über eine einzelne regionale Ressource innerhalb des virtuellen Netzwerks. Dieses Muster vermeidet die Komplexität und Kosten eines globalen Dienstes, wenn der Datenverkehr geografisch konzentriert ist.

Muster 4: Front Door mit gesperrten privaten Ursprungsservern

Dienste: Front Door Premium → Private Link → interner Lastenausgleich → VMs

Szenario: Eine Finanzdienstleistungsanwendung mit strengen Anforderungen, dass der Ursprung keine öffentliche IP-Exposition aufweisen darf. Der gesamte Datenverkehr muss das Microsoft-Backbone-Netzwerk ohne Sprünge über das öffentliche Internet durchlaufen.

Front Door Premium verbindet sich über einen Private Link Endpunkt mit dem Ursprung. Das Origin-Backend hat keine öffentliche IP-Adresse und ist nicht dem Internet ausgesetzt. Dieses Muster bietet die Sicherheit eines vollständig privaten Ursprungs in Kombination mit den Leistungsvorteilen des globalen Edgenetzwerks von Front Door.

Regionsübergreifender Eingang mit Front Door

Das folgende Diagramm zeigt Azure Front Door als globalen Einstiegspunkt, der Benutzer bei automatischem Failover an den nächstgelegenen fehlerfreien regionalen Ursprungsserver weiterleitet.

Voraussetzungen

Bevor Sie Ihre Anwendung für das Internet verfügbar machen, stellen Sie sicher, dass die folgenden Komponenten vorhanden sind:

• Virtuelles Netzwerk bereitgestellt: Ihre Back-End-Ressourcen müssen innerhalb eines Azure virtuellen Netzwerks mit ordnungsgemäßen Subnetzen ausgeführt werden. Informationen zur Subnetzplanung finden Sie unter "Entwerfen Ihres virtuellen Netzwerks und Ihrer Subnetze ".
• Laufende Workload: Sie benötigen mindestens eine Backendressource (virtuelle Maschine, Container oder Plattformdienst), die bereit ist, Datenverkehr zu verarbeiten.
• DNS-Name: Ein öffentlicher DNS-Name, den externe Benutzer verwenden, um Ihre Anwendung zu erreichen. Sie können Azure DNS oder einen Drittanbieter-DNS-Anbieter verwenden.
• Subnetzplanung für Eingangsdienste: Für das Anwendungsgateway ist ein dediziertes Subnetz erforderlich (mindestens /24 für die Produktion empfohlen). Load Balancer Standard Back-End-Instanzen können ein Subnetz für andere Ressourcen freigeben.

Überlegungen zum Entwurf

Bewerten Sie, ob der Interneteingang für Ihre aufgehobenen Workloads erforderlich ist. Viele lokale Anwendungen sind nur intern und bleiben nach der Migration auf diese Weise erhalten. Wenn ein Eingangsschritt erforderlich ist, lassen Sie die Architektur einfach:

• Application Gateway mit WAF bietet einen regionsspezifischen Layer-7-Ingress mit TLS-Terminierung und OWASP-Schutz. Dieser Ansatz ist die am häufigsten verwendete Methode für aufgehobene Web-Apps, die sich zuvor hinter einem lokalen Reverseproxy befanden.
• Öffentliche IP mit NSG ist für Nicht-HTTP-Workloads mit geringem Datenverkehr akzeptabel (z. B. ein TCP-Dienst, mit dem Partner eine Verbindung herstellen). Beschränken Sie die NSG auf bekannte Quell-IP-Adressen.
• Vermeiden Sie das direkte Zuweisen öffentlicher IPs zu virtuellen Computern. Platzieren Sie einen Lastenausgleich oder ein Anwendungsgateway zwischen dem Internet und Ihrem Back-End.

Wenn Ihre angehobenen Anwendungen keine externen Benutzer bedienen, überspringen Sie diesen Artikel, und fahren Sie mit dem Ausgehenden Internetzugriff fort.

Ihre modernisierten Workloads weisen unterschiedliche Eingangsmuster auf der Grundlage des Anwendungstyps auf:

• Azure Front Door für kundenorientierte Webanwendungen (z. B. ContosoBiz). Front Door bietet globale Beschleunigung, integrierte WAF, CDN-Zwischenspeicherung und automatisches Failover über Regionen hinweg. Verwenden Sie gewichtetes Routing für aktive Bereitstellungen.
• Azure Traffic Manager für mobile und API-Anwendungen (z. B. ContosoCare). Der Datenverkehrs-Manager bietet DNS-basiertes Routing für Nicht-HTTP-Protokolle oder wenn Clients direkte regionale Konnektivität benötigen.
• Hubfirewall als DNAT-Ziel: Der gesamte Eingehende Datenverkehr durchläuft den Hub Azure Firewall, bevor er Anwendungsebenen erreicht. Die Firewall führt Destination NAT (DNAT) durch, um den bereinigten Datenverkehr an den richtigen Spoke weiterzuleiten. Dieser Ansatz stellt sicher, dass kein ungefilterter Internetdatenverkehr Ihre zentralisierten Sicherheitskontrollen umgeht.

Kombinieren Sie Front Door mit Anwendungsgateway in jeder Region für die zweistufige WAF-Inspektion: eine am globalen Rand und eine an der regionalen Grenze.

Stellen Sie für öffentlich zugängliche Anwendungen, die von AWS oder Google Cloud migriert wurden, im Spoke-VNet, in dem sich die Workload befindet, ein Application Gateway mit WAF bereit:

• Application Gateway + WAF in spoke VNet: Stellen Sie ein regionales Application Gateway bereit, bei dem WAF im Präventionsmodus aktiviert ist. Bei diesem Ansatz bleibt der Ingress nahe am Workload, ohne dass der Datenverkehr den Hub zur HTTP-Inspektion durchlaufen muss.
• Keine direkten öffentlichen IPs auf virtuellen Computern: Weisen Sie öffentlichen IPs niemals direkt migrierten virtuellen Computern zu. Der gesamte internetseitige Datenverkehr läuft über Application Gateway.
• Ursprungsserver absichern: Wenn sich die Anwendung zuvor hinter einem AWS Application Load Balancer (ALB) oder Google Cloud Load Balancing befand, übertragen Sie dieses eingehende Muster auf Application Gateway für regionale Workloads oder Front Door für globale Workloads.

Wenn Ihr cloudübergreifender Workload ausschließlich intern ist (Kommunikation zwischen Clouds über private Verbindungen), überspringen Sie diesen Artikel und fahren Sie mit Azure Firewall und Datenverkehrsüberprüfung fort.

Sicherheitsüberlegungen

Interneteingang ist die Eingangstür Ihrer Anwendung. Es ist die Grenze, an der nicht vertrauenswürdiger Internetdatenverkehr in Ihre Azure Umgebung eintritt. Befolgen Sie diese Methoden, um Ihren Eingangspfad zu sichern.

Virtuelle Computer niemals direkt mit öffentlichen IPs verfügbar machen

Weisen Sie der Netzwerkschnittstelle eines virtuellen Computers keine öffentliche IP-Adresse für die Bereitstellung von Anwendungsdatenverkehr an den Ports 80 oder 443 zu. Platzieren Sie stattdessen ein Lastenausgleichsmodul oder ein Anwendungsgateway zwischen dem Internet und Ihren virtuellen Computern. Dieser Ansatz bietet Ihnen:

• Integritätstests zum Entfernen fehlgeschlagener Instanzen aus der Drehung
• Ein einzelner Punkt für ssl- oder TLS-Beendigung
• Ein Ort zum Anwenden von WAF-Regeln und -Ratenbeschränkungen
• Zentralisierte Protokollierung aller eingehenden Datenverkehrs

Caution

Eine öffentliche IP direkt auf einem virtuellen Computer macht jeden offenen Port zum Internet verfügbar. Wenn die Netzwerksicherheitsgruppe des virtuellen Computers über eine falsch konfigurierte Regel verfügt, erhalten Angreifer direkten Zugriff auf das Betriebssystem.

Aktivieren von WAF im Verhinderungsmodus

Wenn Sie das Anwendungsgateway mit WAF oder Azure Front Door mit WAF bereitstellen, legen Sie den WAF-Modus für Produktionsworkloads auf den Präventionsmodus fest. Der Verhinderungsmodus blockiert böswillige Anforderungen, bevor sie Ihre Anwendung erreichen. Der Erkennungsmodus protokolliert nur Bedrohungen, ohne sie zu blockieren. Verwenden Sie den Erkennungsmodus nur während des anfänglichen Tests, um Regeln zu optimieren und falsch positive Ergebnisse zu identifizieren.

Der WAF-Standardregelsatz (DRS) schützt vor den OWASP Top-10-Angriffen, einschließlich SQL-Injection, Cross-Site-Scripting und Remotecodeausführung. DRS umfasst auch Microsoft Threat Intelligence-Regeln, die bekannte schädliche IPs und Nutzlasten erkennen.

Aktivieren von DDoS Protection

Alle virtuellen Netzwerke mit öffentlich zugänglichen Ressourcen sollten den DDoS-Schutz aktiviert haben. Azure DDoS-Netzwerkschutz bietet adaptive Optimierung, Angriffstelemetrie und Kostenschutz für Ihre öffentlichen IPs. Ohne DDoS-Schutz kann ein volumetrischer Angriff Ihre eingehende Bandbreite sättigen und Ihre Anwendung unerreichbar machen.

Ausführliche Informationen finden Sie unter DDoS-Schutz für Ihr Netzwerk.

NSGs für mehrschichtige Verteidigung verwenden

Selbst wenn Sie einen Lastenausgleich oder ein Anwendungsgateway verwenden, konfigurieren Sie Regeln für Netzwerksicherheitsgruppen in Ihren Back-End-Subnetzen, um einzuschränken, welche Datenverkehrsquellen Ihre virtuellen Computer erreichen können. Eine ordnungsgemäß konfigurierte NSG:

• Erlaubt nur Datenverkehr aus dem Subnetz oder dem Diensttag des Load Balancers
• Verweigert direkten eingehenden Datenverkehr aus dem Internet zu Back-End-VMs
• Protokolliert abgelehnten Datenverkehr zur Sicherheitsüberwachung.

Informationen zur NSG-Planung finden Sie unter Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen.

TLS 1.2 oder höher erzwingen

Konfigurieren Sie alle Eingehenden Dienste so, dass nur TLS 1.2 oder TLS 1.3 akzeptiert werden. Deaktivieren Sie TLS 1.0 und 1.1, die bekannte Sicherheitsrisiken aufweisen. Sowohl das Anwendungsgateway als auch die Front Door unterstützen die minimale TLS-Versionskonfiguration über ihre TLS-Richtlinieneinstellungen. Verwenden Sie vordefinierte Richtlinien, z AppGwSslPolicy20220101 . B. für das Anwendungsgateway, anstelle von benutzerdefinierten Verschlüsselungskonfigurationen, es sei denn, Sie verfügen über bestimmte Complianceanforderungen.

Ursprungsserver für Front Door sperren

Wenn Sie Azure Front Door verwenden, beschränken Sie Ihre Ursprungsserver auf die Annahme von Datenverkehr nur von Front Door. Wenn Ihr Ursprung Datenverkehr von einer beliebigen Quelle akzeptiert, können schlechte Akteure die WAF von Front Door umgehen, indem sie sich direkt mit der Ursprungs-IP verbinden, wodurch Ihre gesamte WAF-Investition unwirksam wird.

Die Ursprungssperre verwendet zwei unabhängige Überprüfungsmechanismen. Wenden Sie beides für die Tiefenverteidigung an:

Beschränkung von Service-Tags (Netzwerkschicht)

Konfigurieren Sie die NSG oder Azure Firewall Ihres Ursprungs, um eingehenden HTTP/HTTPS-Datenverkehr nur über das AzureFrontDoor.Backend Diensttag zuzulassen. Dieses Diensttag enthält alle IP-Bereiche, die von Front Door zum Herstellen einer Verbindung mit Ursprungsservern verwendet werden. Wenden Sie diese Regel auf das Subnetz oder die NIC an, in dem sich Ihr Ursprung befindet:

• NSG-Regel: Priorität 100, Quelle = Diensttag AzureFrontDoor.Backend, Ziel = Ihr Backendsubnetz, Ports = 80, 443, Aktion = Zulassen.
• Standardmäßig verweigern: Stellen Sie sicher, dass keine andere Regel eingehenden Datenverkehr aus dem Internet über die Ports 80/443 zulässt. Die standardmäßige NSG-Regel "DenyAllInbound" behandelt dies, es sei denn, Sie fügen eine umfassendere Zulassungsregel hinzu.

Das Service-Tag allein ist nicht ausreichend, da alle Front Door-Instanzen aller Azure-Kunden dieselben IP-Adressbereiche des Service-Tags verwenden. Ein böswilliger Akteur könnte ein eigenes Front Door-Profil erstellen und es an Ihre Ursprungs-IP weiterleiten, wodurch Ihre WAF-Regeln umgangen würden.

X-Azure-FDID Headerüberprüfung (Anwendungsschicht)

Jede Anforderung von Front Door enthält einen X-Azure-FDID Header mit dem eindeutigen Bezeichner (GUID) der Front Door-Instanz, die die Anforderung gesendet hat. Überprüfen Sie diesen Header in Ihrer Anwendung oder Reverseproxy, um zu bestätigen, dass die Anforderung aus Ihrem Front Door-Profil stammt, und nicht die eines schlechten Akteurs:

1. Suchen Sie Ihre Front Door ID im Azure Portal unter der Übersichtsseite Ihres Front Door-Profils (das Feld "Front Door ID").
2. Lehnen Sie in Ihrem Anwendungscode oder Ihrer Webserverkonfiguration jede Anfrage ab, bei der X-Azure-FDID nicht mit der von Ihnen erwarteten GUID übereinstimmt.
3. Zurückgeben von HTTP 403 für Anforderungen mit einem fehlenden oder falschen Headerwert.

Durch die Kombination des Diensttags (blockiert Nicht-Front-Door-Datenverkehr im Netzwerk) mit der Headerüberprüfung (blockiert den Front-Door-Datenverkehr anderer Kunden auf Anwendungsebene) wird sichergestellt, dass nur Ihre Front Door-Instanz Ihren Ursprungsserver erreichen kann.

Private Link-Quellen (stärkste Sperre)

Für Workloads, die die höchste Ursprungsisolation erfordern, unterstützt Front Door Premium Private Link Ursprünge. Ihr Ursprung benötigt keine öffentliche IP-Adresse. Front Door stellt über einen privaten Endpunkt eine Verbindung über das Microsoft-Backbone her. Dieser Ansatz beseitigt die Notwendigkeit von Diensttagregeln oder Headerüberprüfungen, da der Ursprung vollständig aus dem öffentlichen Internet nicht erreichbar ist.

Verwandte Artikel

• Entwerfen Sie Ihr virtuelles Netzwerk und Ihre Subnetze: Subnetzgröße für Anwendungsgateway und Load Balancer Back-Ends
• Netzwerksicherheitsgruppen und Anwendungssicherheitsgruppen: NSG-Regeln zum Einschränken des Back-End-Zugriffs nach dem Ingress
• Anwendungsbereitstellung und Performance: Performance-Optimierung, nachdem Ihr Ingress-Pfad eingerichtet wurde
• Ausgehender Internetzugriff: Steuern des Ausgangs, des ausgehenden Gegenstücks zum Eingang
• Sicherer Administratorzugriff: Administratorzugriffsmuster, die sich vom Interneteingang für Anwendungsbenutzer unterscheiden
• Webanwendungsfirewall: Detaillierte WAF-Konfiguration und -Regeloptimierung
• DDoS-Schutz für Ihr Netzwerk: DDoS-Schutzplanung für alle öffentlich zugänglichen Ressourcen

Weitere Informationen

• Was ist Azure Load Balancer?
• Was ist Azure Application Gateway?
• Was ist Azure Front Door?
• Was ist Azure Traffic Manager?
• Öffentliche IP-Adressen in Azure
• Azure-Webanwendungsfirewall im Anwendungsgateway
• Übersicht über Azure DDoS Netzwerkschutz

Nächste Schritte

Tip

Auf eigene Faust erkunden? Kehren Sie zum Übersichtsnavigator zurück, um Ihren nächsten Artikel nach Funktion zu finden.

Als Nächstes in Ihrer Lift-and-Shift-Reise:

Anwendungsbereitstellung und -leistung: Fügen Sie den Lastenausgleich von Layer 7 und die globale Bereitstellung für Ihre migrierte Workload hinzu.

Wenn Ihr angehobener Workload keinen Lastenausgleich für Layer 7 benötigt, fahren Sie mit Ausgehender Internetzugriff fort.

Als Nächstes in Ihrer Modernisierungsreise:

Anwendungsbereitstellung und -leistung: Optimieren Sie die globale Bereitstellung und Leistung für Ihre kundenorientierten PaaS-Workloads.

Als Nächstes in Ihrer cloudübergreifenden Reise:

Web Application Firewall: Schützen Sie öffentlich zugängliche Anwendungen vor HTTP-Layer-Angriffen in Ihrer Cloud.Web Application Firewall.

Wenn Ihre Workload HTTP/HTTPS nicht verwendet, springen Sie weiter zu Azure Firewall und Datenverkehrsüberprüfung.