Netzwerk und Konnektivität für unternehmenskritische Workloads in Azure

Netzwerk ist ein grundlegender Bereich für eine unternehmenskritische Anwendung, angesichts des empfohlenen global verteilten Aktiv-Aktiv-Entwurfsansatzes.

In diesem Entwurfsbereich werden verschiedene Themen zur Netzwerktopologie auf Anwendungsebene unter Berücksichtigung der erforderlichen Konnektivität und redundanten Datenverkehrsverwaltung untersucht. Genauer gesagt werden wichtige Überlegungen und Empfehlungen hervorgehoben, die den Entwurf einer sicheren und skalierbaren globalen Netzwerktopologie für eine unternehmenskritische Anwendung betreffen.

Wichtig

Dieser Artikel ist Teil der Unternehmenskritisch-Workloadreihe von Azure Well-Architected . Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit einer unternehmenskritischen Workload zu beginnen?

Globales Datenverkehrsrouting

Die Verwendung mehrerer aktiver regionaler Bereitstellungsstempel erfordert einen globalen Routingdienst, der Datenverkehr an jeden aktiven Stempel verteilt.

Azure Front Door, Azure Traffic Manager und Azure Load Balancer Standard bieten die erforderlichen Routingfunktionen zum Verwalten des globalen Datenverkehrs in einer Anwendung mit mehreren Regionen.

Alternativ können globale Routingtechnologien von Drittanbietern in Betracht gezogen werden. Diese Optionen können nahezu nahtlos ausgetauscht werden, um die Verwendung von azure-nativen globalen Routingdiensten zu ersetzen oder zu erweitern. Beliebte Optionen sind Routingtechnologien von CDN-Anbietern.

In diesem Abschnitt werden die wichtigsten Unterschiede von Azure-Routingdiensten erläutert, um zu definieren, wie die einzelnen Dienste verwendet werden können, um verschiedene Szenarien zu optimieren.

Überlegungen zum Entwurf

• Ein Routingdienst, der an eine einzelne Region gebunden ist, stellt einen Single-Point-of-Failure und ein erhebliches Risiko in Bezug auf regionale Ausfälle dar.

• Wenn die Anwendungsworkload die Clientsteuerung umfasst, z. B. mit mobilen oder Desktopclientanwendungen, ist es möglich, Dienstredundanz innerhalb der Clientroutinglogik bereitzustellen.

  • Mehrere globale Routingtechnologien, z. B. Azure Front Door und Azure Traffic Manager, können aus Redundanzgründen parallel berücksichtigt werden, wobei die Clients so konfiguriert werden können, dass sie auf eine alternative Technologie umschalten, wenn bestimmte Fehlerbedingungen erfüllt sind. Die Einführung mehrerer globaler Routingdienste führt zu erheblichen Komplexitäten in Bezug auf Edgezwischenspeicherung und Web Application Firewall Funktionen sowie die Zertifikatverwaltung für SSL-Auslagerung und Anwendungsvalidierung für Eingangspfade.
  • Auch Drittanbietertechnologien können berücksichtigt werden, die globale Routingresilienz für alle Ebenen von Azure-Plattformausfällen bieten.

• Funktionsunterschiede zwischen Azure Front Door und Traffic Manager bedeuten, dass, wenn die beiden Technologien aus Redundanzgründen nebeneinander positioniert sind, ein anderer Eingangspfad oder andere Entwurfsänderungen erforderlich wären, um sicherzustellen, dass ein konsistentes und akzeptables Dienstniveau beibehalten wird.

• Azure Front Door und Azure Traffic Manager sind global verteilte Dienste mit integrierter Redundanz und Verfügbarkeit in mehreren Regionen.

  • Hypothetische Fehlerszenarien einer Größe, die groß genug ist, um die globale Verfügbarkeit dieser resilienten Routingdienste zu gefährden, stellen ein größeres Risiko für die Anwendung in Bezug auf kaskadierende und korrelierte Fehler dar.
    • Fehlerszenarien dieser Größenordnung sind nur durch gemeinsame grundlegende Dienste wie Azure DNS oder Microsoft Entra-ID möglich, die als globale Plattformabhängigkeiten für fast alle Azure-Dienste dienen. Wenn eine redundante Azure-Technologie angewendet wird, ist es wahrscheinlich, dass auch der sekundäre Dienst nicht verfügbar ist oder ein heruntergestufter Dienst auftritt.
    • Globale Routingdienstfehlerszenarien wirken sich mit hoher Wahrscheinlichkeit erheblich auf viele andere Dienste aus, die für wichtige Anwendungskomponenten über dienstübergreifende Abhängigkeiten verwendet werden. Selbst wenn eine Drittanbietertechnologie verwendet wird, befindet sich die Anwendung aufgrund der umfassenderen Auswirkungen des zugrunde liegenden Problems wahrscheinlich in einem fehlerhaften Zustand, was bedeutet, dass das Routing an Anwendungsendpunkte in Azure sowieso wenig Wert bietet.

• Die Redundanz des globalen Routingdiensts bietet eine Entschärfung für eine extrem kleine Anzahl hypothetischer Fehlerszenarien, bei denen die Auswirkungen eines globalen Ausfalls auf den Routingdienst selbst beschränkt sind.

  Um umfassendere Redundanz für globale Ausfallszenarien zu ermöglichen, kann ein Aktiv-Aktiv-Bereitstellungsansatz mit mehreren Clouds in Betracht gezogen werden. Ein Aktiv-Aktiv-Bereitstellungsansatz mit mehreren Clouds führt zu erheblicher Betriebskomplexität und dadurch zu signifikanten Risiken für die Resilienz, die wahrscheinlich die hypothetischen Risiken eines globalen Ausfalls bei weitem überwiegen.

• Für Szenarien, in denen keine Clientsteuerung möglich ist, muss auf einen einzelnen globalen Routingdienst zurückgegriffen werden, um einen einheitlichen Einstiegspunkt für alle aktiven Bereitstellungsregionen zu schaffen.

  • Wenn sie isoliert verwendet werden, stellen sie aufgrund globaler Abhängigkeiten einen Single Point of Failure auf Dienstebene dar, obwohl integrierte Redundanz und Verfügbarkeit in mehreren Regionen bereitgestellt werden.
  • Die vom ausgewählten globalen Routingdienst bereitgestellte SLA stellt die maximal erreichbare zusammengesetzte SLA dar, unabhängig davon, wie viele Bereitstellungsregionen berücksichtigt werden.

• Wenn die Clientsteuerung nicht möglich ist, können operative Maßnahmen in Betracht gezogen werden, um einen Prozess für die Migration zu einem sekundären globalen Routingdienst zu definieren, wenn der primäre Dienst durch einen globalen Ausfall deaktiviert wird. Die Migration von einem globalen Routingdienst zu einem anderen ist in der Regel ein längerer Prozess, der mehrere Stunden dauert, insbesondere wenn die DNS-Weitergabe berücksichtigt wird.

• Einige globale Routingdienste von Drittanbietern bieten eine SLA zu 100 %. Die von diesen Diensten bereitgestellte historische und erreichbare SLA liegt jedoch in der Regel unter 100 %.

  • Diese Dienstleistungen bieten zwar finanzielle Reparationsleistungen für die Nichtverfügbarkeit, aber sie kommt von geringer Bedeutung, wenn die Auswirkungen der Nichtverfügbarkeit erheblich sind, z. B. bei sicherheitskritischen Szenarien, in denen letztlich menschliches Leben auf dem Spiel steht. Technologieredundanz oder ausreichende betriebliche Maßnahmen sollten daher auch dann in Betracht gezogen werden, wenn die angekündigte rechtliche SLA 100 % beträgt.

Azure Front Door

• Azure Front Door bietet globalen HTTP/S-Lastenausgleich und optimierte Konnektivität mithilfe des Anycast-Protokolls mit geteiltem TCP, um das globale Backbone-Netzwerk von Microsoft zu nutzen.

  • Für jeden Back-End-Endpunkt wird eine Reihe von Verbindungen verwaltet.
  • Eingehende Clientanforderungen werden zuerst auf dem Edgeknoten beendet, der dem ursprünglichen Client am nächsten ist.
  • Nach jeder erforderlichen Datenverkehrsüberprüfung werden Anforderungen entweder über den Microsoft-Backbone mithilfe vorhandener Verbindungen an das entsprechende Back-End weitergeleitet oder aus dem internen Cache eines Edgeknotens bereitgestellt.
  • Dieser Ansatz ist sehr effizient, um hohe Datenverkehrsvolumen über die Back-End-Verbindungen zu verteilen.

• Stellt einen integrierten Cache bereit, der statische Inhalte von Edgeknoten bereitstellt. In vielen Anwendungsfällen kann dies auch die Notwendigkeit eines dedizierten Content Delivery Network (CDN) überflüssig werden.

• Azure Web Application Firewall (WAF) kann in Azure Front Door verwendet werden, und da es an Azure-Netzwerk-Edgestandorten auf der ganzen Welt bereitgestellt wird, wird jede eingehende Anforderung, die von Front Door in übermittelt wird, am Netzwerkrand überprüft.

• Azure Front Door schützt Anwendungsendpunkte mit Azure DDoS Protection Basic vor DDoS-Angriffen. Azure DDoS Standard bietet zusätzliche und erweiterte Schutz- und Erkennungsfunktionen und kann Azure Front Door als zusätzliche Ebene hinzugefügt werden.

• Azure Front Door bietet einen vollständig verwalteten Zertifikatdienst. Aktiviert die TLS-Verbindungssicherheit für Endpunkte, ohne den Zertifikatlebenszyklus verwalten zu müssen.

• Azure Front Door Premium unterstützt private Endpunkte, sodass Datenverkehr aus dem Internet direkt in virtuelle Azure-Netzwerke fließen kann. Dadurch entfällt die Notwendigkeit, öffentliche IP-Adressen im VNET zu verwenden, um die Back-Ends über Azure Front Door Premium zugänglich zu machen.

• Azure Front Door basiert auf Integritätstests und Back-End-Integritätsendpunkten (UrLs), die auf Intervallbasis aufgerufen werden, um einen HTTP-status Code zurückzugeben, der angibt, ob das Back-End normal ausgeführt wird, wobei eine HTTP 200-Antwort (OK) einen fehlerfreien status widerspiegelt. Sobald ein Back-End einen fehlerhaften status widerspiegelt, wird dieser Edgeknoten aus der Perspektive eines bestimmten Edgeknotens nicht mehr Anforderungen dorthin senden. Fehlerhafte Back-Ends werden daher ohne Verzögerung transparent aus dem Datenverkehrsverkehr entfernt.

• Unterstützt nur HTTP/S-Protokolle.

• Die Azure Front Door WAF und Application Gateway WAF bieten einen etwas anderen Featuresatz, obwohl beide integrierte und benutzerdefinierte Regeln unterstützen und so festgelegt werden können, dass sie entweder im Erkennungsmodus oder im Präventionsmodus ausgeführt werden.

• Der Front Door-Back-End-IP-Bereich kann sich ändern, aber Microsoft stellt die Integration in Azure-IP-Bereiche und Diensttags sicher. Es ist möglich, Azure-IP-Bereiche und -Diensttags zu abonnieren, um Benachrichtigungen über Änderungen oder Updates zu erhalten.

• Azure Front Door unterstützt verschiedene Lastenverteilungskonfigurationen:

  • Latenzbasiert: Die Standardeinstellung, die Datenverkehr vom Client an das "nächstgelegene" Back-End weitergibt; basierend auf der Anforderungslatenz.
  • Prioritätsbasiert: Nützlich für Aktiv/Passiv-Setups, bei denen Datenverkehr immer an ein primäres Back-End gesendet werden muss, es sei denn, es ist nicht verfügbar.
  • Gewichtet: Gilt für Canary-Bereitstellungen, bei denen ein bestimmter Prozentsatz des Datenverkehrs an ein bestimmtes Back-End gesendet wird. Wenn mehreren Back-Ends die gleichen Gewichtungen zugewiesen sind, wird latenzbasiertes Routing verwendet.

• Standardmäßig verwendet Azure Front Door latenzbasiertes Routing, das zu Situationen führen kann, in denen einige Back-Ends viel mehr eingehenden Datenverkehr erhalten als andere, je nachdem, woher Clients stammen.

• Wenn eine Reihe von Clientanforderungen vom gleichen Back-End verarbeitet werden muss, kann die Sitzungsaffinität im Front-End konfiguriert werden. Es verwendet ein clientseitiges Cookie, um nachfolgende Anforderungen an dasselbe Back-End wie die erste Anforderung zu senden, sofern das Back-End noch verfügbar ist.

Azure Traffic Manager

• Azure Traffic Manager ist ein DNS-Umleitungsdienst.

  • Die tatsächliche Anforderungsnutzlast wird nicht verarbeitet, stattdessen gibt Traffic Manager den DNS-Namen eines der Back-Ends zurück, das dem Pool entspricht, basierend auf konfigurierten Regeln für die ausgewählte Datenverkehrsroutingmethode.
  • Der DNS-Name des Back-Ends wird dann in seine endgültige IP-Adresse aufgelöst, die anschließend direkt vom Client aufgerufen wird.

• Die DNS-Antwort wird zwischengespeichert und vom Client für einen bestimmten Gültigkeitsdauerzeitraum wiederverwendet, und anforderungen, die während dieses Zeitraums vorgenommen werden, werden ohne Traffic Manager-Interaktion direkt an den Back-End-Endpunkt gesendet. Eliminiert den zusätzlichen Konnektivitätsschritt, der Kostenvorteile im Vergleich zu Front Door bietet.

• Da die Anforderung direkt vom Client an den Back-End-Dienst gesendet wird, kann jedes vom Back-End unterstützte Protokoll genutzt werden.

• Ähnlich wie Bei Azure Front Door basiert auch Azure Traffic Manager auf Integritätstests, um zu ermitteln, ob ein Back-End fehlerfrei ist und normal funktioniert. Wenn ein anderer Wert zurückgegeben wird oder nichts zurückgegeben wird, erkennt der Routingdienst laufende Probleme und beendet das Weiterleiten von Anforderungen an dieses bestimmte Back-End.

  • Im Gegensatz zu Azure Front Door erfolgt die Entfernung fehlerhafter Back-Ends jedoch nicht sofort, da Clients weiterhin Verbindungen mit dem fehlerhaften Back-End erstellen, bis die DNS-Gültigkeitsdauer abläuft und ein neuer Back-End-Endpunkt vom Traffic Manager-Dienst angefordert wird.
  • Darüber hinaus gibt es auch bei Ablauf der Gültigkeitsdauer keine Garantie dafür, dass öffentliche DNS-Server diesen Wert berücksichtigen, sodass die DNS-Weitergabe viel länger dauern kann. Dies bedeutet, dass Datenverkehr weiterhin für einen längeren Zeitraum an den fehlerhaften Endpunkt gesendet wird.

Azure Load Balancer Standard

Wichtig

Regionsübergreifende Load Balancer Standard ist mit technischen Einschränkungen in der Vorschau verfügbar. Diese Option wird für unternehmenskritische Workloads nicht empfohlen.

Entwurfsempfehlungen

• Verwenden Sie Azure Front Door als primären globalen Routingdienst für Datenverkehr für HTTP/S-Szenarien. Azure Front Door wird nachdrücklich für HTTP/S-Workloads empfohlen, da es optimiertes Datenverkehrsrouting, transparentes Failover, private Back-End-Endpunkte (mit der Premium-SKU), Edgezwischenspeicherung und Integration in Web Application Firewall (WAF) bietet.

• Für Anwendungsszenarien, bei denen eine Clientsteuerung möglich ist, wenden Sie eine clientseitige Routinglogik an, um Failoverszenarien zu berücksichtigen, sollte die primäre globale Routingtechnologie fehlschlagen. Zwei oder mehr globale Routingtechnologien sollten parallel eingesetzt werden, um zusätzliche Redundanz zu gewährleisten, wenn eine einzelne Dienst-SLA nicht ausreicht. Clientlogik ist erforderlich, um bei einem Ausfall des globalen Diensts eine Umleitung zur redundanten Technologie vorzunehmen.

  • Es sollten zwei unterschiedliche URLs verwendet werden, wobei eine auf jeden der verschiedenen globalen Routingdienste angewendet wird, um die gesamte Zertifikatverwaltung und Routinglogik für ein Failover zu vereinfachen.
  • Priorisieren Sie die Verwendung von Routingtechnologien von Drittanbietern als sekundären Failoverdienst, da dies die größte Anzahl von globalen Fehlerszenarien verringert, und die Funktionen, die von branchenführenden CDN-Anbietern angeboten werden, ermöglichen einen konsistenten Entwurfsansatz.
  • Es sollte auch das direkte Routing an einen einzelnen regionalen Stempel anstelle eines separaten Routingdiensts berücksichtigt werden. Dies führt zwar zu einer herabgesetzten Dienstebene, stellt jedoch einen weitaus einfacheren Entwurfsansatz dar.

Diese Abbildung zeigt eine redundante konfiguration des globalen Lastenausgleichs mit Clientfailover unter Verwendung von Azure Front Door als primären globalen Lastenausgleich.

Wichtig

Um das Risiko globaler Fehler innerhalb der Azure-Plattform wirklich zu minimieren, sollte ein Multi-Cloud-Ansatz für aktiv/aktiv bereitgestellt werden, wobei aktive Bereitstellungsstempel für zwei oder mehr Cloudanbieter gehostet werden, und redundante Routingtechnologien von Drittanbietern, die für das globale Routing verwendet werden.

Azure kann effektiv in andere Cloudplattformen integriert werden. Es wird jedoch dringend empfohlen, keinen Multi-Cloud-Ansatz anzuwenden, da er eine erhebliche Betriebskomplexität mit unterschiedlichen Bereitstellungsstempeldefinitionen und Darstellungen der Betriebsintegrität auf den verschiedenen Cloudplattformen mit sich bringt. Diese Komplexität führt wiederum zu zahlreichen Resilienzrisiken im normalen Betrieb der Anwendung, die die hypothetischen Risiken eines globalen Plattformausfalls bei weitem überwiegen.

• Obwohl nicht empfohlen, sollten Sie für HTTP-Workloads, die Azure Traffic Manager für globale Routingredundanz zu Azure Front Door verwenden, Web Application Firewall (WAF) in Application Gateway für akzeptablen Datenverkehr, der über Azure Front Door fließt, auslagern.
  • Dies führt zu einem zusätzlichen Fehlerpunkt für den Standardeingangspfad, einer zusätzlichen Komponente für kritische Pfade, die verwaltet und skaliert werden soll, und es entstehen zusätzliche Kosten, um die globale Hochverfügbarkeit sicherzustellen. Es wird das Fehlerszenario jedoch erheblich vereinfachen, indem Konsistenz zwischen den akzeptablen und nicht akzeptablen Eingangspfaden über Azure Front Door und Azure Traffic Manager bereitgestellt wird, sowohl in Bezug auf die WAF-Ausführung als auch für private Anwendungsendpunkte.
  • Der Verlust der Edgezwischenspeicherung in einem Fehlerszenario wirkt sich auf die Gesamtleistung aus, und dies muss mit einem akzeptablen Servicelevel oder einer Minderung des Entwurfsansatzes abgestimmt werden. Um eine konsistente Dienstebene sicherzustellen, sollten Sie die Edgezwischenspeicherung für beide Pfade an einen CDN-Drittanbieter auslagern.

Es wird empfohlen, einen globalen Routingdienst eines Drittanbieters anstelle zweier globaler Azure-Routingdienste zu verwenden. Dies bietet ein Höchstmaß an Minderung des Fehlerrisikos und einen einfacheren Entwurfsansatz, da die meisten in branchenführenden CDN-Anbieter Edgefunktionalität bieten, die weitgehend mit der von Azure Front Door übereinstimmt.

Azure Front Door

• Verwenden Sie den verwalteten Azure Front Door-Zertifikatdienst, um TLS-Verbindungen zu aktivieren, und entfernen Sie die Notwendigkeit, Zertifikatlebenszyklus zu verwalten.

• Verwenden Sie azure Front Door Web Application Firewall (WAF), um schutz am Edge vor gängigen Web-Exploits und Sicherheitsrisiken wie sql injection zu bieten.

• Verwenden Sie den integrierten Azure Front Door-Cache, um statische Inhalte von Edgeknoten bereitzustellen.

  • In den meisten Fällen entfällt dadurch auch die Notwendigkeit eines dedizierten Content Delivery Network (CDN).

• Konfigurieren Sie die Eingangspunkte der Anwendungsplattform, um eingehende Anforderungen durch headerbasierte Filterung mithilfe der X-Azure-FDID zu überprüfen, um sicherzustellen, dass der gesamte Datenverkehr durch die konfigurierte Front Door-instance fließt. Erwägen Sie auch die Konfiguration von IP ACLing mithilfe von Front Door-Diensttags, um zu überprüfen, ob der Datenverkehr aus dem Azure Front Door-Back-End-IP-Adressraum und den Azure-Infrastrukturdiensten stammt. Dadurch wird sichergestellt, dass der Datenverkehr über Azure Front Door auf Dienstebene fließt, aber die headerbasierte Filterung ist weiterhin erforderlich, um die Verwendung eines konfigurierten Front Door-instance sicherzustellen.

• Definieren Sie einen benutzerdefinierten TCP-Integritätsendpunkt, um kritische Downstreamabhängigkeiten innerhalb eines regionalen Bereitstellungsstempels zu überprüfen, einschließlich Datenplattformreplikaten wie Azure Cosmos DB im Beispiel, das von der grundlegenden Referenzimplementierung bereitgestellt wird. Wenn eine oder mehrere Abhängigkeiten fehlerhaft sind, sollte der Integritätstest dies in der zurückgegebenen Antwort widerspiegeln, damit der gesamte regionale Stempel aus dem Verkehr gezogen werden kann.

• Stellen Sie sicher, dass Integritätstestantworten protokolliert werden, und erfassen Sie alle von Azure Front Door verfügbar gemachten Betriebsdaten im globalen Log Analytics-Arbeitsbereich, um eine einheitliche Datensenke und eine einzelne Betriebsansicht für die gesamte Anwendung zu ermöglichen.

• Es sei denn, die Workload ist äußerst latenzempfindlich, verteilen Sie den Datenverkehr gleichmäßig auf alle betrachteten regionalen Stempel, um bereitgestellte Ressourcen am effektivsten zu nutzen.

  • Um dies zu erreichen, legen Sie den Parameter "Latenzempfindlichkeit (zusätzliche Latenz)" auf einen Wert fest, der hoch genug ist, um Latenzunterschiede zwischen den verschiedenen Regionen der Back-Ends zu berücksichtigen. Stellen Sie eine Toleranz sicher, die für die Anwendungsworkload in Bezug auf die latenz von Clientanforderungen insgesamt akzeptabel ist.

• Aktivieren Sie die Sitzungsaffinität nur, wenn dies von der Anwendung erforderlich ist, da sie sich negativ auf die Verteilung des Datenverkehrs auswirken kann. Wenn bei einer vollständig zustandslosen Anwendung der empfohlene unternehmenskritische Anwendungsentwurfsansatz befolgt wird, kann jede Anforderung von einer der regionalen Bereitstellungen verarbeitet werden.

Azure Traffic Manager

• Verwenden Sie Traffic Manager für Szenarien ohne HTTP/S als Ersatz für Azure Front Door. Die unterschiedlichen Funktionen führen zu unterschiedlichen Entwurfsentscheidungen für Cache- und WAF-Funktionen sowie für die Verwaltung von TLS-Zertifikaten.

• WAF-Funktionen sollten in jeder Region für den Traffic Manager-Eingangspfad berücksichtigt werden, wobei Azure Application Gateway verwendet wird.

• Konfigurieren Sie einen entsprechend niedrigen TTL-Wert, um die Zeit zu optimieren, die erforderlich ist, um einen fehlerhaften Back-End-Endpunkt aus dem Verkehr zu entfernen, falls das Back-End fehlerhaft wird.

• Ähnlich wie bei Azure Front Door sollte ein benutzerdefinierter TCP-Integritätsendpunkt definiert werden, um kritische Downstreamabhängigkeiten innerhalb eines regionalen Bereitstellungsstempels zu überprüfen, was sich in der Antwort widerspiegeln sollte, die von Integritätsendpunkten bereitgestellt wird.

  Für Traffic Manager sollte jedoch zusätzlich das regionale Failover auf Servicelevel berücksichtigt werden. wie "Hundelegging", um die potenzielle Verzögerung zu verringern, die mit der Entfernung eines fehlerhaften Back-Ends aufgrund von Abhängigkeitsfehlern verbunden ist, insbesondere wenn es nicht möglich ist, eine niedrige Gültigkeitsdauer für DNS-Einträge festzulegen.

• Bei verwendung von Azure Traffic Manager als primärem globalen Routingdienst sollten Drittanbieter-CDN-Anbieter berücksichtigt werden, um Edgezwischenspeicherung zu erreichen. Wenn Edge-WAF-Funktionen auch vom Drittanbieterdienst angeboten werden, sollte berücksichtigt werden, um den Eingangspfad zu vereinfachen und möglicherweise die Notwendigkeit von Application Gateway zu beseitigen.

Anwendungsbereitstellungsdienste

Der Netzwerkeingangspfad für eine unternehmenskritische Anwendung muss auch Anwendungsbereitstellungsdienste berücksichtigen, um sicheren, zuverlässigen und skalierbaren eingehenden Datenverkehr zu gewährleisten.

Dieser Abschnitt baut auf globalen Routingempfehlungen auf, indem wichtige Funktionen zur Anwendungsbereitstellung untersucht werden, wobei relevante Dienste wie Azure Load Balancer Standard, Azure Application Gateway und Azure API Management berücksichtigt werden.

Überlegungen zum Entwurf

• Die TLS-Verschlüsselung ist wichtig, um die Integrität des eingehenden Benutzerdatenverkehrs für eine unternehmenskritische Anwendung sicherzustellen, wobei die TLS-Abladung nur an der Stelle des Eingehenden eines Stempels zum Entschlüsseln des eingehenden Datenverkehrs angewendet wird. TLS-Auslagerung Erfordert den privaten Schlüssel des TLS-Zertifikats zum Entschlüsseln des Datenverkehrs.

• Ein Web Application Firewall bietet Schutz vor gängigen Web-Exploits und Sicherheitsrisiken, z. B. SQL-Einschleusung oder siteübergreifendes Skripting, und ist unerlässlich, um die maximalen Zuverlässigkeitswünsche einer unternehmenskritischen Anwendung zu erreichen.

• Azure WAF bietet mithilfe verwalteter Regelsätze sofort einsatzbereiten Schutz vor den 10 wichtigsten OWASP-Sicherheitsrisiken.

  • Benutzerdefinierte Regeln können auch hinzugefügt werden, um den verwalteten Regelsatz zu erweitern.
  • Azure WAF kann entweder in Azure Front Door, Azure Application Gateway oder Azure CDN (derzeit in der öffentlichen Vorschau) aktiviert werden.
    • Die Funktionen, die für die einzelnen Dienste angeboten werden, unterscheiden sich geringfügig. Azure Front Door WAF bietet beispielsweise Ratenbegrenzung, Geofilterung und Botschutz, die noch nicht innerhalb der Application Gateway WAF angeboten werden. Sie alle unterstützen jedoch sowohl integrierte als auch benutzerdefinierte Regeln und können so festgelegt werden, dass sie im Erkennungs- oder Präventionsmodus ausgeführt werden.
    • Die Roadmap für Azure WAF stellt sicher, dass ein konsistenter WAF-Featuresatz für alle Dienstintegrationen bereitgestellt wird.

• Waf-Technologien von Drittanbietern wie NVAs und erweiterte Eingangscontroller in Kubernetes können auch als erforderliche Schutz vor Sicherheitsrisiken betrachtet werden.

• Eine optimale WAF-Konfiguration erfordert in der Regel eine Feinabstimmung, unabhängig von der verwendeten Technologie.

  Azure Front Door

• Azure Front Door akzeptiert nur HTTP- und HTTPS-Datenverkehr und verarbeitet nur Anforderungen mit einem bekannten Host Header. Diese Protokollblockierung hilft, volumetrische Angriffe, die über Protokolle und Ports verteilt sind, sowie DNS-Verstärkungs- und TCP-Vergiftungsangriffe zu mindern.

• Azure Front Door ist eine globale Azure-Ressource, sodass die Konfiguration global an allen Edgestandorten bereitgestellt wird.

  • Die Ressourcenkonfiguration kann in großem Umfang verteilt werden, um Hunderttausende von Anforderungen pro Sekunde zu verarbeiten.
  • Updates zur Konfiguration, einschließlich Routen und Back-End-Pools, sind nahtlos und verursachen während der Bereitstellung keine Ausfallzeiten.

• Azure Front Door bietet sowohl einen vollständig verwalteten Zertifikatdienst als auch eine Bring-Your-Own-Certificate-Methode für die clientseitigen SSL-Zertifikate. Der vollständig verwaltete Zertifikatdienst bietet einen vereinfachten operativen Ansatz und trägt dazu bei, die Komplexität des Gesamtentwurfs zu reduzieren, indem er die Zertifikatverwaltung in einem einzelnen Bereich der Lösung durchführt.

• Azure Front Door rotiert "verwaltete" Zertifikate mindestens 60 Tage vor dem Ablauf des Zertifikats automatisch, um sich vor abgelaufenen Zertifikatrisiken zu schützen. Wenn selbstverwaltete Zertifikate verwendet werden, sollten aktualisierte Zertifikate spätestens 24 Stunden vor Ablauf des vorhandenen Zertifikats bereitgestellt werden. Andernfalls erhalten Clients möglicherweise abgelaufene Zertifikatfehler.

• Zertifikatupdates führen nur dann zu Ausfallzeiten, wenn Azure Front Door zwischen "Verwaltet" und "Eigenes Zertifikat verwenden" gewechselt wird.

• Azure Front Door wird durch Azure DDoS Protection Basic geschützt, das standardmäßig in Front Door integriert ist. Dies bietet eine Always-On-Datenverkehrsüberwachung, Eine Entschärfung in Echtzeit und schützt auch vor allgemeinen Layer 7-DNS-Abfragefluten oder volumetrischen Layer-3/4-Angriffen.

  • Diese Schutzmaßnahmen tragen dazu bei, die Verfügbarkeit von Azure Front Door auch bei einem DDoS-Angriff aufrechtzuerhalten. DDoS-Angriffe (Distributed Denial of Service) können dazu führen, dass eine zielorientierte Ressource nicht verfügbar ist, indem sie mit unzulässigem Datenverkehr überlastet wird.

• Azure Front Door bietet auch WAF-Funktionen auf globaler Datenverkehrsebene, während Application Gateway WAF in jedem regionalen Bereitstellungsstempel bereitgestellt werden muss. Zu den Funktionen gehören Firewallregelsätze zum Schutz vor häufigen Angriffen, Geofilterung, Adressblockierung, Ratenbegrenzung und Signaturabgleich.

  Azure-Lastenausgleich

• Die Azure Basic Load Balancer SKU wird nicht durch eine SLA unterstützt und weist im Vergleich zur Standard-SKU mehrere Funktionseinschränkungen auf.

Entwurfsempfehlungen

• Führen Sie die TLS-Auslagerung an so wenigen Stellen wie möglich durch, um die Sicherheit zu gewährleisten und gleichzeitig den Lebenszyklus der Zertifikatverwaltung zu vereinfachen.

• Verwenden Sie verschlüsselte Verbindungen (z. B. HTTPS) von dem Punkt, an dem die TLS-Auslagerung erfolgt, auf die eigentlichen Anwendungs-Back-Ends. Anwendungsendpunkte sind für Endbenutzer nicht sichtbar, sodass von Azure verwaltete Domänen wie azurewebsites.net oder cloudapp.netmit verwalteten Zertifikaten verwendet werden können.

• Stellen Sie für HTTP(S)-Datenverkehr sicher, dass WAF-Funktionen innerhalb des Eingangspfads für alle öffentlich verfügbar gemachten Endpunkte angewendet werden.

• Aktivieren Sie WAF-Funktionen an einem einzigen Dienststandort, entweder global mit Azure Front Door oder regional mit Azure Application Gateway, da dies die Optimierung der Konfiguration vereinfacht und Leistung und Kosten optimiert.

  Konfigurieren Sie WAF im Präventionsmodus, um Angriffe direkt zu blockieren. Verwenden Sie WAF nur dann im Erkennungsmodus (d. h. reine Protokollierung ohne Blockierung verdächtiger Anforderungen), wenn die Leistungseinbußen im Präventionsmodus zu hoch sind. Das damit verbundene zusätzliche Risiko muss vollständig verstanden und auf die spezifischen Anforderungen des Workloadszenarios abgestimmt werden.

• Setzen Sie vorrangig auf Azure Front Door WAF, da diese Lösung die umfangreichsten nativen Azure-Features bietet und Schutzmaßnahmen am globalen Edge anwendet, was den Gesamtentwurf vereinfacht und weitere Effizienzsteigerungen ermöglicht.

• Verwenden Sie Azure API Management nur, wenn Sie eine große Anzahl von APIs für externe Clients oder andere Anwendungsteams verfügbar machen.

• Verwenden Sie die Azure Load Balancer Standard SKU für jedes Szenario zur internen Verteilung des Datenverkehrs innerhalb von Microserviceworkloads.

  • Stellt eine SLA von 99,99 % bereit, wenn Verfügbarkeitszonen bereitgestellt wird.
  • Stellt wichtige Funktionen bereit, z. B. Diagnosen oder Ausgangsregeln.

• Verwenden Sie Azure DDoS Network Protection, um öffentliche Endpunkte zu schützen, die in jedem virtuellen Anwendungsnetzwerk gehostet werden.

Zwischenspeichern und Übermittlung statischer Inhalte

Eine spezielle Behandlung von statischen Inhalten wie Bildern, JavaScript, CSS und anderen Dateien kann sich erheblich auf die Gesamtbenutzererfahrung sowie auf die Gesamtkosten der Lösung auswirken. Das Zwischenspeichern statischer Inhalte am Edge kann die Clientladezeiten beschleunigen, was zu einer besseren Benutzererfahrung führt und auch die Kosten für Datenverkehr, Lesevorgänge und Rechenleistung für die beteiligten Back-End-Dienste reduzieren kann.

Überlegungen zum Entwurf

• Nicht alle Inhalte, die eine Lösung über das Internet zur Verfügung stellt, werden dynamisch generiert. Anwendungen stellen sowohl statische Ressourcen (Bilder, JavaScript, CSS, Lokalisierungsdateien usw.) als auch dynamische Inhalte bereit.
• Workloads mit häufig verwendeten statischen Inhalten profitieren erheblich von der Zwischenspeicherung, da dies die Last für Back-End-Dienste reduziert und die Latenz des Inhaltszugriffs für Endbenutzer reduziert.
• Die Zwischenspeicherung kann nativ in Azure mithilfe von Azure Front Door oder Azure Content Delivery Network (CDN) implementiert werden.
  • Azure Front Door bietet native Azure-Edgezwischenspeicherungsfunktionen und Routingfeatures, um statische und dynamische Inhalte zu unterteilen.
    • Durch das Erstellen der entsprechenden Routingregeln in Azure Front Door /static/* kann Datenverkehr transparent an statische Inhalte umgeleitet werden.
  • Komplexere Zwischenspeicherungsszenarien können mithilfe des Azure CDN-Diensts implementiert werden, um ein vollständiges Inhaltsübermittlungsnetzwerk für erhebliche statische Inhaltsvolumes einzurichten.
    • Der Azure CDN-Dienst ist wahrscheinlich kostengünstiger, bietet aber nicht die gleichen erweiterten Routing- und Web Application Firewall-Funktionen (WAF), die für andere Bereiche eines Anwendungsentwurfs empfohlen werden. Es bietet jedoch weitere Flexibilität bei der Integration in ähnliche Dienste von Drittanbieterlösungen wie Akamai und Verizon.
  • Beim Vergleich der Azure Front Door- und Azure CDN-Dienste sollten die folgenden Entscheidungsfaktoren untersucht werden:
    • Die erforderlichen Zwischenspeicherungsregeln können mithilfe der Regel-Engine erreicht werden.
    • Größe des gespeicherten Inhalts und die damit verbundenen Kosten.
    • Preis pro Monat für die Ausführung der Regel-Engine (berechnet pro Anforderung in Azure Front Door).
    • Anforderungen an ausgehenden Datenverkehr (Preis unterscheidet sich je nach Ziel).

Entwurfsempfehlungen

• Auch generierte statische Inhalte wie große Kopien von Bilddateien, die sich nie oder nur selten ändern, können vom Zwischenspeichern profitieren. Die Zwischenspeicherung kann basierend auf URL-Parametern und mit unterschiedlicher Zwischenspeicherungsdauer konfiguriert werden.
• Trennen Sie die Bereitstellung statischer und dynamischer Inhalte für Benutzer, und stellen Sie relevante Inhalte aus einem Cache bereit, um die Last für Back-End-Dienste zu verringern und die Leistung für Endbenutzer zu optimieren.
• Angesichts der starken Empfehlung (Netzwerk- und Konnektivitätsentwurfsbereich) zur Verwendung von Azure Front Door für globales Routing und Web Application Firewall (WAF) wird empfohlen, die Verwendung von Azure Front Door-Cachefunktionen zu priorisieren, sofern keine Lücken vorhanden sind.

Integration in ein virtuelles Netzwerk

Eine unternehmenskritische Anwendung umfasst in der Regel Anforderungen für die Integration in andere Anwendungen oder abhängige Systeme, die in Azure, einer anderen öffentlichen Cloud oder lokalen Rechenzentren gehostet werden können. Diese Anwendungsintegration kann über öffentlich zugängliche Endpunkte und das Internet oder private Netzwerke über die Integration auf Netzwerkebene erreicht werden. Letztendlich hat die Methode, mit der die Anwendungsintegration erreicht wird, erhebliche Auswirkungen auf die Sicherheit, Leistung und Zuverlässigkeit der Lösung und wirkt sich stark auf Entwurfsentscheidungen in anderen Entwurfsbereichen aus.

Eine unternehmenskritische Anwendung kann innerhalb einer von drei übergreifenden Netzwerkkonfigurationen bereitgestellt werden, die bestimmen, wie die Anwendungsintegration auf Netzwerkebene erfolgen kann.

1. Öffentliche Anwendung ohne Unternehmensnetzwerkkonnektivität.
2. Öffentliche Anwendung mit Unternehmensnetzwerkkonnektivität.
3. Private Anwendung mit Unternehmensnetzwerkkonnektivität.

Achtung

Bei der Bereitstellung innerhalb einer Azure-Zielzone konfiguration 1. sollte innerhalb einer Onlinezielzone bereitgestellt werden, während sowohl 2) als auch 3) innerhalb einer verbundenen Corp. Zielzone bereitgestellt werden sollten, um die Integration auf Netzwerkebene zu erleichtern.

In diesem Abschnitt werden diese Szenarien für die Netzwerkintegration erläutert, wobei die geeignete Verwendung virtueller Azure-Netzwerke und der umgebenden Azure-Netzwerkdienste überlappend ist, um sicherzustellen, dass die Integrationsanforderungen optimal erfüllt werden.

Entwurfsaspekte

Keine virtuellen Netzwerke

• Der einfachste Entwurfsansatz besteht darin, die Anwendung nicht in einem virtuellen Netzwerk bereitzustellen.

  • Die Konnektivität zwischen allen betrachteten Azure-Diensten wird vollständig über öffentliche Endpunkte und den Microsoft Azure-Backbone bereitgestellt. Konnektivität zwischen öffentlichen Endpunkten, die in Azure gehostet werden, durchlaufen nur den Microsoft-Backbone und werden nicht über das öffentliche Internet geleitet.
  • Die Konnektivität mit externen Systemen außerhalb von Azure wird über das öffentliche Internet bereitgestellt.

• Dieser Entwurfsansatz verwendet "Identität als Sicherheitsperimeter", um die Zugriffssteuerung zwischen den verschiedenen Dienstkomponenten und der abhängigen Lösung zu ermöglichen. Dies kann eine akzeptable Lösung für Szenarien sein, die weniger sicherheitsempfindlich sind. Auf alle Anwendungsdienste und Abhängigkeiten kann über einen öffentlichen Endpunkt zugegriffen werden, wodurch sie anfällig für zusätzliche Angriffsvektoren sind, die sich an nicht autorisiertem Zugriff orientieren.

• Dieser Entwurfsansatz gilt auch nicht für alle Azure-Dienste, da viele Dienste, z. B. AKS, eine harte Anforderung an ein zugrunde liegendes virtuelles Netzwerk haben.

Isolierte virtuelle Netzwerke

• Um die Mit unnötigen öffentlichen Endpunkten verbundenen Risiken zu minimieren, kann die Anwendung in einem eigenständigen Netzwerk bereitgestellt werden, das nicht mit anderen Netzwerken verbunden ist.

• Eingehende Clientanforderungen erfordern weiterhin, dass ein öffentlicher Endpunkt für das Internet verfügbar gemacht wird, aber die gesamte nachfolgende Kommunikation kann innerhalb des virtuellen Netzwerks erfolgen, indem private Endpunkte verwendet werden. Bei Verwendung von Azure Front Door Premium ist es möglich, direkt von Edgeknoten an private Anwendungsendpunkte weiterzuleiten.

• Während die private Konnektivität zwischen Anwendungskomponenten über virtuelle Netzwerke erfolgt, sind alle Verbindungen mit externen Abhängigkeiten weiterhin auf öffentlichen Endpunkten angewiesen.

  • Konnektivität mit Azure-Plattformdiensten kann bei Unterstützung mit privaten Endpunkten hergestellt werden. Wenn andere externe Abhängigkeiten in Azure vorhanden sind, z. B. eine andere Downstreamanwendung, wird die Konnektivität über öffentliche Endpunkte und den Microsoft Azure-Backbone bereitgestellt.
  • Konnektivität mit externen Systemen außerhalb von Azure wird über das öffentliche Internet bereitgestellt.

• In Szenarien, in denen keine Netzwerkintegrationsanforderungen für externe Abhängigkeiten bestehen, bietet die Bereitstellung der Lösung in einer isolierten Netzwerkumgebung maximale Entwurfsflexibilität. Keine Adressierungs- und Routingeinschränkungen im Zusammenhang mit einer umfassenderen Netzwerkintegration.

• Azure Bastion ist ein vollständig plattformverwalteter PaaS-Dienst, der in einem virtuellen Netzwerk bereitgestellt werden kann und sichere RDP-/SSH-Konnektivität mit Azure-VMs bereitstellt. Wenn Sie eine Verbindung über Azure Bastion herstellen, benötigen virtuelle Computer keine öffentliche IP-Adresse.

• Die Verwendung virtueller Anwendungsnetzwerke führt zu erheblichen Bereitstellungskomplexitäten innerhalb von CI/CD-Pipelines, da sowohl der Daten- als auch der Steuerungsebenenzugriff auf Ressourcen, die in privaten Netzwerken gehostet werden, erforderlich ist, um Anwendungsbereitstellungen zu vereinfachen.

  • Ein sicherer privater Netzwerkpfad muss eingerichtet werden, damit CI/CD-Tools die erforderlichen Aktionen ausführen können.
  • Private Build-Agents können in virtuellen Anwendungsnetzwerken bereitgestellt werden, um den Proxyzugriff auf durch das virtuelle Netzwerk gesicherte Ressourcen zu ermöglichen.

Verbundenen virtuellen Netzwerken

• In Szenarien mit Anforderungen an die Integration externer Netzwerke können virtuelle Anwendungsnetzwerke mit anderen virtuellen Netzwerken in Azure, einem anderen Cloudanbieter oder lokalen Netzwerken über eine Vielzahl von Konnektivitätsoptionen verbunden werden. In einigen Anwendungsszenarien kann beispielsweise die Integration auf Anwendungsebene mit anderen branchenspezifischen Anwendungen in Betracht gezogen werden, die privat in einem lokalen Unternehmensnetzwerk gehostet werden.

• Der Entwurf des Anwendungsnetzwerks muss sich an der umfassenderen Netzwerkarchitektur orientieren, insbesondere in Bezug auf Themen wie Adressierung und Routing.

• Überlappende IP-Adressräume zwischen Azure-Regionen oder lokalen Netzwerken führen zu größeren Konflikten, wenn die Netzwerkintegration in Betracht gezogen wird.

  • Eine virtuelle Netzwerkressource kann aktualisiert werden, um zusätzlichen Adressraum in Betracht zu ziehen. Wenn sich jedoch ein adressraum des virtuellen Netzwerks eines per Peering verknüpften Netzwerks ändert, ist eine Synchronisierung auf dem Peeringlink erforderlich, wodurch das Peering vorübergehend deaktiviert wird.
  • Azure reserviert fünf IP-Adressen innerhalb jedes Subnetzes, die bei der Bestimmung der geeigneten Größe für virtuelle Anwendungsnetzwerke und eingeschlossene Subnetze berücksichtigt werden sollten.
  • Einige Azure-Dienste erfordern dedizierte Subnetze, z. B. Azure Bastion, Azure Firewall oder Azure Virtual Network Gateway. Die Größe dieser Dienstsubnetze ist sehr wichtig, da sie groß genug sein sollten, um alle aktuellen Instanzen des Diensts unter Berücksichtigung zukünftiger Skalierungsanforderungen zu unterstützen, aber nicht so groß, dass Adressen unnötigerweise verschwendet werden.

• Wenn eine lokale oder cloudübergreifende Netzwerkintegration erforderlich ist, bietet Azure zwei verschiedene Lösungen zum Herstellen einer sicheren Verbindung.

  • Eine ExpressRoute-Leitung kann so dimensioniert werden, dass Bandbreiten von bis zu 100 GBit/s bereitgestellt werden.
  • Ein virtuelles privates Netzwerk (VPN) kann so dimensioniert werden, dass eine aggregierte Bandbreite von bis zu 10 GBit/s in Hub- und Spoke-Netzwerken und bis zu 20 GBit/s in Azure Virtual WAN bereitgestellt wird.

Hinweis

Beachten Sie bei der Bereitstellung innerhalb einer Azure-Zielzone, dass alle erforderlichen Verbindungen mit lokalen Netzwerken von der Implementierung der Zielzone bereitgestellt werden sollten. Der Entwurf kann ExpressRoute und andere virtuelle Netzwerke in Azure mithilfe Virtual WAN oder eines Hub-and-Spoke-Netzwerkentwurfs verwenden.

• Die Einbeziehung zusätzlicher Netzwerkpfade und -ressourcen führt zu zusätzlichen Zuverlässigkeits- und Betriebsüberlegungen für die Anwendung, um sicherzustellen, dass die Integrität beibehalten wird.

Entwurfsempfehlungen

• Es wird empfohlen, unternehmenskritische Lösungen nach Möglichkeit in virtuellen Azure-Netzwerken bereitzustellen. Dadurch werden unnötige öffentliche Endpunkte entfernt und die Angriffsfläche für Anwendungen begrenzt, um Sicherheit und Zuverlässigkeit zu maximieren.

  • Verwenden Sie private Endpunkte für die Konnektivität mit Azure-Plattformdiensten. Dienstendpunkte können für Dienste in Betracht gezogen werden, die Private Link unterstützen, sofern Datenexfiltrationsrisiken akzeptabel sind oder durch alternative Kontrollen gemindert werden.

• Für Anwendungsszenarien, die keine Konnektivität mit dem Unternehmensnetzwerk erfordern, behandeln Sie alle virtuellen Netzwerke als flüchtige Ressourcen, die ersetzt werden, sobald eine neue regionale Bereitstellung erfolgt.

• Beim Herstellen einer Verbindung mit anderen Azure- oder lokalen Netzwerken sollten virtuelle Anwendungsnetzwerke nicht als kurzlebig behandelt werden, da dies erhebliche Komplikationen beim Peering virtueller Netzwerke und VNET-Gatewayressourcen verursacht. Alle relevanten Anwendungsressourcen innerhalb des virtuellen Netzwerks sollten weiterhin kurzlebig sein, wobei parallele Subnetze verwendet werden, um blaugrüne Bereitstellungen aktualisierter regionaler Bereitstellungsstempel zu ermöglichen.

• In Szenarien, in denen Konnektivität mit dem Unternehmensnetzwerk erforderlich ist, um die Integration von Anwendungen über private Netzwerke zu erleichtern, stellen Sie sicher, dass sich der IPv4-Adressraum, der für regionale virtuelle Anwendungsnetzwerke verwendet wird, nicht mit anderen verbundenen Netzwerken überschneidet. Er muss außerdem ausreichend dimensioniert sein, um die erforderliche Skalierung zu ermöglichen, ohne die Ressourcen von virtuellen Netzwerken aktualisieren zu müssen und Ausfallzeiten zu verursachen.

  • Es wird dringend empfohlen, nur IP-Adressen aus der Adresszuordnung für das private Internet zu verwenden (RFC 1918).
    • Für Umgebungen mit eingeschränkter Verfügbarkeit privater IP-Adressen (RFC 1918) sollten Sie IPv6 verwenden.
    • Wenn die Verwendung einer öffentlichen IP-Adresse erforderlich ist, stellen Sie sicher, dass nur eigene Adressblöcke verwendet werden.
  • Richten Sie sich an organization Plänen für die IP-Adressierung in Azure aus, um sicherzustellen, dass sich der IP-Adressraum des Anwendungsnetzwerks nicht mit anderen Netzwerken über lokale Standorte oder Azure-Regionen hinweg überschneidet.
  • Erstellen Sie keine unnötig großen virtuellen Anwendungsnetzwerke, um sicherzustellen, dass ip-Adressraum nicht verschwendet wird.

• Priorisieren Sie die Verwendung von Azure CNI für die AKS-Netzwerkintegration, da sie einen umfangreicheren Featuresatz unterstützt.

  • Erwägen Sie Kubenet für Szenarien mit einer begrenzten Anzahl verfügbarer IP-Adressen, um die Anwendung in einen eingeschränkten Adressraum zu passen.

  • Priorisieren Sie die Verwendung des Azure CNI-Netzwerk-Plug-Ins für die AKS-Netzwerkintegration, und ziehen Sie Kubenet für Szenarien mit einem begrenzten Bereich verfügbarer IP-Adressen in Betracht. Weitere Informationen finden Sie unter Mikrosegmentierung und Kubernetes-Netzwerkrichtlinien .

• In Szenarien, in denen eine lokale Netzwerkintegration erforderlich ist, sollten Sie die Verwendung von ExpressRoute priorisieren, um eine sichere und skalierbare Konnektivität sicherzustellen.

  • Stellen Sie sicher, dass die zuverlässigkeitsstufe, die auf die Expressroute oder das VPN angewendet wird, die Anwendungsanforderungen vollständig erfüllt.
  • Mehrere Netzwerkpfade sollten berücksichtigt werden, um bei Bedarf zusätzliche Redundanz bereitzustellen, z. B. vernetzte ExpressRoute-Leitungen oder die Verwendung von VPN als Failoverkonnektivitätsmechanismus.

• Stellen Sie sicher, dass alle Komponenten auf kritischen Netzwerkpfaden den Zuverlässigkeits- und Verfügbarkeitsanforderungen der zugehörigen Benutzerflows entsprechen, unabhängig davon, ob die Verwaltung dieser Pfade und der zugehörigen Komponente vom Anwendungsteam der zentralen IT-Teams bereitgestellt wird.

  Hinweis

  Berücksichtigen Sie bei der Bereitstellung innerhalb einer Azure-Zielzone und der Integration in eine umfassendere Netzwerktopologie der Organisation den Netzwerkleitfaden , um sicherzustellen, dass das grundlegende Netzwerk den bewährten Methoden von Microsoft entspricht.

• Verwenden Sie Azure Bastion oder per Proxy private Verbindungen, um auf die Datenebene von Azure-Ressourcen zuzugreifen oder Verwaltungsvorgänge auszuführen.

Internet (ausgehend)

Ausgehendes Internet ist eine grundlegende Netzwerkanforderung für eine unternehmenskritische Anwendung, um die externe Kommunikation im Kontext von:

1. Direkte Benutzerinteraktion der Anwendung.
2. Anwendungsintegration mit externen Abhängigkeiten außerhalb von Azure.
3. Zugriff auf externe Abhängigkeiten, die von den von der Anwendung verwendeten Azure-Diensten erforderlich sind.

In diesem Abschnitt wird erläutert, wie ausgehende Internetdaten erreicht werden können, während gleichzeitig sichergestellt wird, dass Sicherheit, Zuverlässigkeit und nachhaltige Leistung gewährleistet werden. Dabei werden die wichtigsten Ausgangsanforderungen für Dienste hervorgehoben, die in einem unternehmenskritischen Kontext empfohlen werden.

Entwurfsaspekte

• Viele Azure-Dienste erfordern Zugriff auf öffentliche Endpunkte, damit verschiedene Funktionen der Verwaltungs- und Steuerungsebene wie vorgesehen ausgeführt werden können.

• Azure bietet verschiedene direkte ausgehende Internetkonnektivitätsmethoden, z. B. Azure NAT Gateway oder Azure Load Balancer, für virtuelle Computer oder Computeinstanzen in einem virtuellen Netzwerk.

• Wenn Datenverkehr aus einem virtuellen Netzwerk in das Internet geleitet wird, muss die Netzwerkadressenübersetzung (Network Address Translation, NAT) erfolgen. Dies ist ein Computevorgang, der innerhalb des Netzwerkstapels erfolgt und sich daher auf die Systemleistung auswirken kann.

• Wenn NAT in kleinem Umfang erfolgt, sollten die Auswirkungen auf die Leistung jedoch vernachlässigbar sein, wenn eine große Anzahl von ausgehenden Anforderungen Netzwerkprobleme auftreten können. Diese Probleme treten in der Regel in Form der Portauslastung von Source NAT (oder SNAT) auf.

• In einer mehrinstanzenfähigen Umgebung, z. B. Azure App Service, steht für jeden instance eine begrenzte Anzahl von ausgehenden Ports zur Verfügung. Wenn diese Ports nicht mehr vorhanden sind, können keine neuen ausgehenden Verbindungen initiiert werden. Dieses Problem kann behoben werden, indem die Anzahl der privaten/öffentlichen Edgedurchgänge reduziert oder eine skalierbarere NAT-Lösung wie das Azure NAT-Gateway verwendet wird.

• Zusätzlich zu NAT-Einschränkungen kann auch ausgehender Datenverkehr erforderlichen Sicherheitsüberprüfungen unterzogen werden.

  • Azure Firewall bietet geeignete Sicherheitsfunktionen, um den ausgehenden Netzwerkdatenverkehr zu schützen.

  • Azure Firewall (oder ein entsprechendes NVA) können verwendet werden, um die Ausgangsanforderungen von Kubernetes zu schützen, indem eine präzise Steuerung der ausgehenden Datenverkehrsflüsse bereitgestellt wird.

• Bei großen Mengen des ausgehenden Internets fallen Gebühren für die Datenübertragung an.

Azure NAT Gateway

• Azure NAT Gateway unterstützt 64.000 Verbindungen für TCP und UDP pro zugewiesener ausgehender IP-Adresse.

  • Einem einzelnen NAT-Gateway können bis zu 16 IP-Adressen zugewiesen werden.
  • Ein standardmäßiges TCP-Leerlauftimeout von 4 Minuten. Wenn das Leerlauftimeout in einen höheren Wert geändert wird, werden Die Flows länger gehalten, was den Druck auf den SNAT-Portbestand erhöht.

• Das NAT-Gateway kann keine sofort einsatzbereite Zonenisolation bereitstellen. Um zonale Redundanz zu erhalten, muss ein Subnetz, das zonenbasierte Ressourcen enthält, mit entsprechenden zonalen NAT-Gateways ausgerichtet werden.

Entwurfsempfehlungen

• Minimieren Sie die Anzahl der ausgehenden Internetverbindungen, da sich dies auf die NAT-Leistung auswirkt.

  • Wenn eine große Anzahl von internetgebundenen Verbindungen erforderlich ist, sollten Sie die Verwendung von Azure NAT Gateway zum Abstrahieren ausgehender Datenverkehrsflüsse in Betracht ziehen.

• Verwenden Sie Azure Firewall, wo Anforderungen zum Steuern und Überprüfen des ausgehenden Internetdatenverkehrs bestehen.

  • Stellen Sie sicher, dass Azure Firewall nicht verwendet wird, um den Datenverkehr zwischen Azure-Diensten zu überprüfen.

Hinweis

Bei der Bereitstellung innerhalb einer Azure-Zielzone sollten Sie die grundlegende Plattform Azure Firewall Ressource (oder ein entsprechendes NVA) verwenden. Wenn eine Abhängigkeit von einer zentralen Plattformressource für ausgehende Internetdaten angenommen wird, sollte die Zuverlässigkeitsebene dieser Ressource und des zugeordneten Netzwerkpfads eng an den Anwendungsanforderungen ausgerichtet sein. Betriebsdaten aus der Ressource sollten auch der Anwendung zur Verfügung gestellt werden, um potenzielle operative Maßnahmen in Fehlerszenarien zu informieren.

Wenn es hohe Anforderungen im Zusammenhang mit ausgehendem Datenverkehr gibt, sollte eine dedizierte Azure Firewall-Ressource für eine unternehmenskritische Anwendung berücksichtigt werden, um Risiken im Zusammenhang mit der Verwendung einer zentral freigegebenen Ressource zu minimieren, z. B. Szenarios für verrauschte Nachbarn.

• Bei der Bereitstellung in einer Virtual WAN-Umgebung sollte Firewall Manager berücksichtigt werden, um eine zentrale Verwaltung dedizierter Anwendungs- Azure Firewall-Instanzen bereitzustellen, um sicherzustellen, dass die Sicherheitsstatus der Organisation durch globale Firewallrichtlinien eingehalten werden.
• Stellen Sie sicher, dass inkrementelle Firewallrichtlinien über die rollenbasierte Zugriffssteuerung an Anwendungssicherheitsteams delegiert werden, um die Autonomie von Anwendungsrichtlinien zu ermöglichen.

Zonen- und regionsübergreifende Konnektivität

Auch wenn das Anwendungsdesign unabhängige regionale Bereitstellungsmarken befürwortet, können viele Anwendungsszenarien dennoch eine Netzwerkintegration zwischen Anwendungskomponenten erfordern, die in verschiedenen Zonen oder Azure-Regionen bereitgestellt werden, selbst wenn dies nur unter verschlechterten Dienstverhältnissen geschieht. Die Methode, mit der die kommunikation zwischen Zonen und Regionen erreicht wird, hat einen erheblichen Einfluss auf die Gesamtleistung und Zuverlässigkeit, die anhand der Überlegungen und Empfehlungen in diesem Abschnitt untersucht wird.

Entwurfsaspekte

• Der Anwendungsentwurfsansatz für eine unternehmenskritische Anwendung unterstützt die Verwendung unabhängiger regionaler Bereitstellungen mit zonenbasierter Redundanz, die auf allen Komponentenebenen innerhalb einer einzelnen Region angewendet wird.

• Eine Verfügbarkeitszone (Availability Zone, AZ) ist ein physisch getrennter Rechenzentrumsstandort innerhalb einer Azure-Region, der physische und logische Fehlerisolation bis auf die Ebene eines einzelnen Rechenzentrums bietet.

  Für die zonenübergreifende Kommunikation ist eine Roundtriplatenz von weniger als 2 ms garantiert. Zonen weisen bei unterschiedlichen Entfernungen und Glasfaserpfaden zwischen Zonen eine geringe Latenzabweichung auf.

• Die Konnektivität der Verfügbarkeitszone hängt von regionalen Merkmalen ab, und daher muss Datenverkehr, der über einen Edgestandort in eine Region eintritt, möglicherweise zwischen Zonen weitergeleitet werden, um das Ziel zu erreichen. Dadurch wird eine Latenz von ca. 1 ms bis 2 ms für zonenübergreifendes Routing und "Lichtgeschwindigkeit" hinzugefügt. Dies sollte jedoch nur für hyperempfindliche Workloads relevant sein.

• Verfügbarkeitszonen werden im Kontext eines einzelnen Abonnements als logische Entitäten behandelt, sodass verschiedene Abonnements möglicherweise eine andere Zonenzuordnung für dieselbe Region haben. Beispielsweise könnte Zone 1 in Abonnement A demselben physischen Rechenzentrum entsprechen wie Zone 2 in Abonnement B.

• Bei der Kommunikation zwischen Zonen innerhalb einer Region fällt eine Datenübertragungsgebühr pro GB Bandbreite an.

• Bei Anwendungsszenarien, die zwischen Anwendungskomponenten äußerst unübersichtlich sind, kann das Verteilen von Anwendungsebenen auf Zonen zu einer erheblichen Latenz und höheren Kosten führen. Es ist möglich, dies innerhalb des Entwurfs zu entschärfen, indem Sie einen Bereitstellungsstempel auf eine einzelne Zone beschränken und mehrere Stempel in den verschiedenen Zonen bereitstellen.

• Bei der Kommunikation zwischen verschiedenen Azure-Regionen fallen höhere Datenübertragungsgebühren pro GB Bandbreite an.

  • Die anwendbare Datenübertragungsrate hängt vom Kontinent der betrachteten Azure-Regionen ab.
  • Daten, die Kontinente durchlaufen, werden erheblich höher berechnet.

• ExpressRoute- und VPN-Konnektivitätsmethoden können auch verwendet werden, um verschiedene Azure-Regionen für bestimmte Szenarien oder sogar verschiedene Cloudplattformen direkt miteinander zu verbinden.

• Für die Kommunikation zwischen Diensten können Private Link für die direkte Kommunikation über private Endpunkte verwendet werden.

• Datenverkehr kann über ExpressRoute-Leitungen für lokale Konnektivität angeheftet werden, um das Routing zwischen virtuellen Netzwerken innerhalb einer Azure-Region und über verschiedene Azure-Regionen innerhalb derselben Region hinweg zu vereinfachen.

  • Durch die Haarnadelung von Datenverkehr über ExpressRoute werden die Datenübertragungskosten im Zusammenhang mit dem Peering virtueller Netzwerke umgangen, sodass die Kosten optimiert werden können.
  • Dieser Ansatz erfordert zusätzliche Netzwerkhops für die Anwendungsintegration in Azure, was Latenz- und Zuverlässigkeitsrisiken mit sich bringt. Erweitert die Rolle von ExpressRoute und zugehörigen Gatewaykomponenten aus Azure/lokal, um auch die Azure-/Azure-Konnektivität zu umfassen.

• Wenn eine Latenz unter einer Millisekunde zwischen Diensten erforderlich ist, können Näherungsplatzierungsgruppen verwendet werden, wenn sie von den verwendeten Diensten unterstützt werden.

Entwurfsempfehlungen

• Arbeiten Sie mit Peering virtueller Netzwerke, um Netzwerke innerhalb einer Region und in verschiedenen Regionen zu verbinden. Es wird dringend empfohlen, sog. „Hair Pinning“ innerhalb von ExpressRoute zu vermeiden.

• Verwenden Sie Private Link, um die Kommunikation zwischen Diensten in derselben Region oder regionenübergreifend herzustellen (Dienst in Region A, der mit dem Dienst in Region B kommuniziert.

• Erwägen Sie für Anwendungsworkloads mit sehr umfangreicher Kommunikation zwischen Komponenten, einen Bereitstellungsstempel auf eine einzige Zone zu beschränken und mehrere Stempel für die verschiedenen Zonen bereitzustellen. So wird sichergestellt, dass zonenbezogene Redundanz auf Ebene eines gekapselten Bereitstellungsstempels und nicht auf Ebene einer einzelnen Anwendungskomponente gewahrt wird.

• Behandeln Sie nach Möglichkeit jeden Bereitstellungsstempel als unabhängig und getrennt von anderen Stempeln.

  • Verwenden Sie Datenplattformtechnologien, um den Zustand regionsübergreifend zu synchronisieren, anstatt Konsistenz auf Anwendungsebene mit direkten Netzwerkpfaden zu erzielen.
  • Vermeiden Sie "Dog Legging"-Datenverkehr zwischen verschiedenen Regionen, sofern dies nicht erforderlich ist, selbst in einem Ausfallszenario. Verwenden Sie globale Routingdienste und End-to-End-Integritätstests, um einen gesamten Stempel aus dem Verkehr zu ziehen, falls eine einzelne kritische Komponentenebene ausfällt, anstatt Datenverkehr auf dieser fehlerhaften Komponentenebene an eine andere Region weiterzuleiten.

• Priorisieren Sie bei Anwendungsszenarien mit hyperlatenzempfindlichen Anwendungen die Verwendung von Zonen mit regionalen Netzwerkgateways, um die Netzwerklatenz für Eingangspfade zu optimieren.

Mikrosegmentierung und Kubernetes-Netzwerkrichtlinien

Die Mikrosegmentierung ist ein Entwurfsmuster für die Netzwerksicherheit, um einzelne Anwendungsworkloads zu isolieren und zu schützen. Dabei werden Richtlinien angewendet, um den Netzwerkdatenverkehr zwischen Workloads basierend auf einem Zero Trust-Modell zu begrenzen. Sie wird in der Regel angewendet, um die Angriffsfläche des Netzwerks zu verringern, die Eindämmung von Sicherheitsverletzungen zu verbessern und die Sicherheit durch richtliniengesteuerte Netzwerksteuerungen auf Anwendungsebene zu erhöhen.

Eine unternehmenskritische Anwendung kann Netzwerksicherheit auf Anwendungsebene mithilfe von Netzwerksicherheitsgruppen (NSG) auf Subnetz- oder Netzwerkschnittstellenebene, Dienst- Access Control Listen (ACL) und Netzwerkrichtlinien erzwingen, wenn Azure Kubernetes Service (AKS) verwendet wird.

In diesem Abschnitt wird die optimale Nutzung dieser Funktionen erläutert. Dabei werden wichtige Überlegungen und Empfehlungen zum Erreichen einer Mikrosegmentierung auf Anwendungsebene bereitgestellt.

Entwurfsaspekte

• AKS kann in zwei verschiedenen Netzwerkmodellen bereitgestellt werden:

  • Kubenet-Netzwerk: AKS-Knoten sind in ein vorhandenes virtuelles Netzwerk integriert, pods sind jedoch in einem virtuellen Überlagerungsnetzwerk auf jedem Knoten vorhanden. Datenverkehr zwischen Pods auf verschiedenen Knoten wird über kube-proxy weitergeleitet.
  • Azure Container Networking Interface (CNI)-Netzwerk: Der AKS-Cluster ist in ein vorhandenes virtuelles Netzwerk integriert, dessen Knoten, Pods und Dienste IP-Adressen aus demselben virtuellen Netzwerk empfangen haben, an das die Clusterknoten angefügt sind. Dies ist für verschiedene Netzwerkszenarien relevant, die eine direkte Konnektivität von und zu Pods erfordern. Verschiedene Knotenpools können in verschiedenen Subnetzen bereitgestellt werden.

  Hinweis

  Azure CNI erfordert im Vergleich zu Kubenet mehr IP-Adressraum. Eine ordnungsgemäße Vorabplanung und Größenanpassung des Netzwerks ist erforderlich. Weitere Informationen finden Sie in der Azure CNI-Dokumentation.

• Pods sind standardmäßig nicht isoliert und akzeptieren Datenverkehr aus jeder Quelle und können Datenverkehr an jedes Ziel senden. ein Pod kann mit jedem anderen Pod in einem bestimmten Kubernetes-Cluster kommunizieren. Kubernetes stellt keine Isolation auf Netzwerkebene sicher und isoliert keine Namespaces auf Clusterebene.

• Die Kommunikation zwischen Pods und Namespaces kann mithilfe von Netzwerkrichtlinien isoliert werden. Netzwerkrichtlinie ist eine Kubernetes-Spezifikation, die Zugriffsrichtlinien für die Kommunikation zwischen Pods definiert. Mithilfe von Netzwerkrichtlinien kann ein geordneter Satz von Regeln definiert werden, um zu steuern, wie Datenverkehr gesendet/empfangen wird, und auf eine Sammlung von Pods angewendet werden, die einem oder mehreren Bezeichnungsselektoren entsprechen.

  • AKS unterstützt zwei Plug-Ins, die Netzwerkrichtlinien implementieren: Azure und Calico. Beide Plug-Ins verwenden Linux-IPTables, um die angegebenen Richtlinien zu erzwingen. Weitere Informationen finden Sie unter Unterschiede zwischen Azure- und Calico-Richtlinien und deren Funktionen .
  • Netzwerkrichtlinien treten nicht in Konflikt, da sie additiv sind.
  • Damit ein Netzwerkfluss zwischen zwei Pods zulässig ist, muss sowohl die Ausgangsrichtlinie für den Quellpod als auch die Eingangsrichtlinie für den Zielpod den Datenverkehr zulassen.
  • Das Netzwerkrichtlinienfeature kann nur zum Zeitpunkt der Clusterinstanziierung aktiviert werden. Es ist nicht möglich, die Netzwerkrichtlinie für einen vorhandenen AKS-Cluster zu aktivieren.
  • Die Bereitstellung von Netzwerkrichtlinien ist unabhängig davon, ob Azure oder Calico verwendet wird, konsistent.
  • Calico bietet einen umfangreicheren Featuresatz, einschließlich Unterstützung für Windows-Knoten und unterstützt Azure CNI sowie Kubenet.

• AKS unterstützt die Erstellung verschiedener Knotenpools zum Trennen verschiedener Workloads mithilfe von Knoten mit unterschiedlichen Hardware- und Softwaremerkmalen, z. B. Knoten mit und ohne GPU-Funktionen.

  • Die Verwendung von Knotenpools bietet keine Isolation auf Netzwerkebene.
  • Knotenpools können unterschiedliche Subnetze innerhalb desselben virtuellen Netzwerks verwenden. NSGs können auf Subnetzebene angewendet werden, um eine Mikrosegmentierung zwischen Knotenpools zu implementieren.

Entwurfsempfehlungen

• Konfigurieren Sie eine NSG für alle betrachteten Subnetze, um eine IP-ACL bereitzustellen, um Eingangspfade zu schützen und Anwendungskomponenten basierend auf einem Zero Trust-Modell zu isolieren.

  • Verwenden Sie Front Door-Diensttags in NSGs in allen Subnetzen, die Anwendungs-Back-Ends enthalten, die in Azure Front Door definiert sind, da dadurch überprüft wird, ob der Datenverkehr aus einem legitimen Azure Front Door-Back-End-IP-Adressraum stammt. Dadurch wird sichergestellt, dass der Datenverkehr über Azure Front Door auf Dienstebene fließt, aber headerbasierte Filter sind weiterhin erforderlich, um die Verwendung einer bestimmten Front Door-instance zu gewährleisten und auch die Sicherheitsrisiken von "IP-Spoofing" zu minimieren.

  • Datenverkehr aus dem öffentlichen Internet muss auf RDP- und SSH-Ports für alle in Frage kommenden Netzwerksicherheitsgruppen deaktiviert werden.

  • Bevorzugen Sie Azure CNI-Netzwerk-Plug-Ins, und ziehen Sie Kubenet für Szenarien mit einem begrenzten Bereich verfügbarer IP-Adressen in Betracht, um die Anwendung an einen begrenzten Adressraum anzupassen.

    • AKS unterstützt die Verwendung von Azure CNI und Kubenet. Sie wird zum Zeitpunkt der Bereitstellung ausgewählt.
    • Das Azure CNI-Netzwerk-Plug-In ist ein stabileres und skalierbares Netzwerk-Plug-In und wird für die meisten Szenarien empfohlen.
    • Kubenet ist ein einfacheres Netzwerk-Plug-In und wird für Szenarien mit einem begrenzten Bereich verfügbarer IP-Adressen empfohlen.
    • Weitere Informationen finden Sie unter Azure CNI .

• Mit dem Feature „Netzwerkrichtlinie“ in Kubernetes können Sie die Regeln für ein- und ausgehenden Datenverkehr zwischen Pods in einem Cluster festlegen. Legen Sie granulare Netzwerkrichtlinien fest, um die Kommunikation zwischen Pods einzuschränken und zu begrenzen.

  • Aktivieren Sie die Netzwerkrichtlinie für Azure Kubernetes Service zum Zeitpunkt der Bereitstellung.
  • Priorisieren Sie die Verwendung von Calico , da es einen umfangreicheren Featuresatz mit einer breiteren Communityeinführung und -unterstützung bietet.

Nächster Schritt

Sehen Sie sich die Überlegungen zur Quantifizierung und Beobachtung der Anwendungsintegrität an.

Integritätsmodellierung und Beobachtbarkeit