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

Networking ist ein grundlegender Bereich für eine unternehmenskritische Anwendung, angesichts des empfohlenen global verteilten aktiv-aktiven Designansatzes.

In diesem Entwurfsbereich werden verschiedene Themen der Netzwerktopologie auf Anwendungsebene untersucht, unter Berücksichtigung der erforderlichen Konnektivität und redundanter Datenverkehrsverwaltung. Genauer gesagt werden wichtige Überlegungen und Empfehlungen hervorgehoben, die darauf abzielen, die Gestaltung einer sicheren und skalierbaren globalen Netzwerktopologie für eine unternehmenskritische Anwendung zu informieren.

Wichtig

Dieser Artikel ist Teil der Reihe der unternehmenskritischen Arbeitsauslastungen von Azure Well-Architected. Wenn Sie mit dieser Reihe nicht vertraut sind, empfehlen wir Ihnen, mit dem zu beginnen, was eine unternehmenskritische Workload ist?

Globales Datenverkehrsrouting

Die Verwendung mehrerer aktiver regionaler Bereitstellungsstempel erfordert einen globalen Routingdienst, um Datenverkehr an jeden aktiven Stempel zu verteilen.

Azure Front Door, Azure Traffic Manager und Azure Load Balancer Standard bieten die erforderlichen Routingfunktionen zum Verwalten des globalen Datenverkehrs über eine Mehrregion-Anwendung hinweg.

Alternativ können Global Routing-Technologien von Drittanbietern berücksichtigt werden. Diese Optionen können fast nahtlos ausgetauscht werden, um die Verwendung von azure-nativen globalen Routingdiensten zu ersetzen oder zu erweitern. Beliebte Auswahlmöglichkeiten umfassen Routingtechnologien von CDN-Anbietern.

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

Ü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 im Bereich der Edgezwischenspeicherung und der Webanwendungsfirewall sowie zur Zertifikatverwaltung für SSL-Offload und Anwendungsüberprüfung für Eingangspfade.
  • Drittanbietertechnologien können auch berücksichtigt werden und bieten globale Routingresilienz für alle Ebenen von Azure-Plattformfehlern.

• Funktionsunterschiede zwischen Azure Front Door und Traffic Manager bedeuten, dass, wenn die beiden Technologien zur Redundanz nebeneinander positioniert werden, eine andere Weg- oder Entwurfsänderung erforderlich wäre, um sicherzustellen, dass ein konsistentes und akzeptables Serviceniveau Standard 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 großen Größe, um die globale Verfügbarkeit dieser ausfallsicheren Routingdienste zu gefährden, stellt ein breiteres Risiko für die Anwendung in Bezug auf Kaskadierungs- und korrelierte Fehler dar.
    • Ausfallszenarien dieser Größenordnung sind nur durch gemeinsame Foundation-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 der sekundäre Dienst auch nicht verfügbar ist oder ein beeinträchtigter Dienst auftritt.
    • Ausfallszenarien des globalen Routingdiensts wirken sich sehr wahrscheinlich erheblich auf viele andere Dienste aus, die für wichtige Anwendungskomponenten über Interserviceabhängigkeiten verwendet werden. Selbst wenn eine Drittanbietertechnologie verwendet wird, befindet sich die Anwendung wahrscheinlich aufgrund der breiteren Auswirkungen des zugrunde liegenden Problems in einem fehlerhaften Zustand, was bedeutet, dass das Routing an Anwendungsendpunkte in Azure trotzdem wenig Wert bietet.

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

  Um umfassendere Redundanz für globale Ausfallszenarien bereitzustellen, kann ein mehrcloud aktiver Bereitstellungsansatz berücksichtigt werden. Ein multicloud aktiver Bereitstellungsansatz führt zu erheblichen betrieblichen Komplexitäten, die erhebliche Resilienzrisiken darstellen, was wahrscheinlich die hypothetischen Risiken eines globalen Ausfalls weit überwiegt.

• 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 einzelnen Fehlerpunkt 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 betriebsbedingte Gegenmaßnahmen berücksichtigt werden, um einen Prozess für die Migration zu einem sekundären globalen Routingdienst zu definieren, wenn ein globaler Ausfall den primären Dienst deaktiviert. 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-Verteilung berücksichtigt wird.

• Einige globale Routingdienste von Drittanbietern stellen eine SLA von 100 % bereit. Die historische und erreichbare SLA, die von diesen Diensten bereitgestellt wird, ist jedoch in der Regel niedriger als 100 %.

  • Während diese Dienstleistungen finanzielle Ausgleichsleistungen für die Nichtverfügbarkeit bieten, ist es von geringer Bedeutung, wenn die Auswirkungen der Nichtverfügbarkeit von Bedeutung sind, z. B. mit sicherheitskritischen Szenarien, in denen das menschliche Leben letztendlich auf dem Spiel steht. Technologieredundanz oder ausreichende operative Entschärfungen sollten daher auch dann berücksichtigt 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.

  • Eine Reihe von Verbindungen wird für jeden Back-End-Endpunkt Standard beibehalten.
  • Eingehende Clientanforderungen werden zuerst am Edgeknoten beendet, der dem ursprünglichen Client am nächsten kommt.
  • Nach jeder erforderlichen Datenverkehrsüberprüfung werden Anforderungen entweder über das Microsoft-Backbone mithilfe vorhandener Verbindungen an das entsprechende Back-End weitergeleitet oder vom internen Cache eines Edgeknotens bereitgestellt.
  • Dieser Ansatz ist effizient bei der Verbreitung von hohen Datenverkehrsvolumen über die Back-End-Verbindungen.

• 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) beseitigen.

• Die Azure-Webanwendungsfirewall (WAF) kann auf Azure Front Door verwendet werden, und da sie an Azure-Netzwerk-Edgestandorten auf der ganzen Welt bereitgestellt wird, werden alle eingehenden Anforderungen, die von Front Door übermittelt werden, am Netzwerkrand geprüft.

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

• Azure Front Door bietet einen vollständig verwalteten Zertifikatdienst. Ermöglicht tls-Verbindungssicherheit für Endpunkte, ohne den Zertifikatlebenszyklus verwalten zu müssen.

• Azure Front Door Premium unterstützt private Endpunkte, sodass Datenverkehr direkt aus dem Internet in virtuelle Azure-Netzwerke fließen kann. Dies würde die Notwendigkeit vermeiden, öffentliche IPs auf dem VNet zu verwenden, um die Back-Ends über Azure Front Door Premium zugänglich zu machen.

• Azure Front Door basiert auf Integritätsüberprüfungen und Back-End-Integritätsendpunkten (URLs), die auf Intervallbasis aufgerufen werden, um einen HTTP-Statuscode zurückzugeben, der angibt, ob das Back-End normal ausgeführt wird, wobei eine HTTP 200 (OK)-Antwort einen fehlerfreien Status widerspiegelt. Sobald ein Back-End einen fehlerhaften Status wiedergibt, wird aus Sicht eines bestimmten Edgeknotens das Senden von Anforderungen an diesen Edgeknoten beendet. Ungesunde Back-Ends werden daher ohne Verzögerung transparent aus dem Datenverkehrsverkehr entfernt.

• Unterstützt nur HTTP/S-Protokolle.

• Das Waf- und Anwendungsgateway-WAF von Azure Front Door bieten einen etwas anderen Featuresatz, obwohl sowohl integrierte als auch benutzerdefinierte Regeln unterstützt werden und entweder im Erkennungsmodus oder im Präventionsmodus ausgeführt werden können.

• Der Front Door-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 Konfigurationen für die Lastverteilung:

  • Latenzbasiert: die Standardeinstellung, mit der Datenverkehr vom Client an das "nächstgelegene" Back-End weitergeleitet wird; basierend auf der Anforderungslatenz.
  • Prioritätsbasiert: nützlich für aktiv-passive 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 Canarybereitstellungen, bei denen ein bestimmter Prozentsatz des Datenverkehrs an ein bestimmtes Back-End gesendet wird. Wenn mehrere Back-Ends dieselbe Gewichtung zugewiesen haben, 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, wo Clients stammen.

• Wenn eine Reihe von Clientanforderungen vom gleichen Back-End verarbeitet werden muss, kann die Session Affinity auf dem Frontend konfiguriert werden. Es verwendet ein clientseitiges Cookie, um nachfolgende Anforderungen an dasselbe Back-End wie die erste Anforderung zu senden, vorausgesetzt, das Back-End ist weiterhin verfügbar.

Azure Traffic Manager

• Azure Traffic Manager ist ein DNS-Umleitungsdienst.

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

• Die DNS-Antwort wird vom Client für einen bestimmten TTL-Zeitraum (Time-To-Live) zwischengespeichert und wiederverwendet, und Anforderungen, die während dieses Zeitraums vorgenommen wurden, werden direkt zum Back-End-Endpunkt ohne Interaktion mit Dem Traffic Manager geleitet. Beseitigt den zusätzlichen Konnektivitätsschritt, der Kostenvorteile im Vergleich zur Fronttür bietet.

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

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

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

Azure Load Balancer Standard

Wichtig

Regionsübergreifende Load Balancer Standard steht in der Vorschau mit technischen Einschränkungen zur Verfügung. 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 stark für HTTP/S-Workloads eingesetzt, da es optimiertes Datenverkehrsrouting, transparentes Failover, private Back-End-Endpunkte (mit der Premium-SKU), Edgezwischenspeicherung und Integration in die Webanwendungsfirewall (WAF) bereitstellt.

• 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 allgemeine Zertifikatverwaltungs- 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 Ausfallszenarien mindert und die von branchenführenden CDN-Anbietern angebotenen Funktionen einen konsistenten Entwurfsansatz ermöglichen.
  • Darüber hinaus sollte die direkte Weiterleitung an einen einzelnen regionalen Stempel und nicht an einen separaten Routingdienst erfolgen. Dies führt zwar zu einem beeinträchtigten Serviceniveau, stellt aber einen viel einfacheren Entwurfsansatz dar.

Diese Abbildung zeigt eine redundante konfiguration für den globalen Lastenausgleich mit Clientfailover mit Azure Front Door als primäres globales Lastenausgleichsmodul.

Wichtig

Um das Risiko globaler Fehler innerhalb der Azure-Plattform wirklich zu verringern, sollte ein mehrcloud aktiver Bereitstellungsansatz berücksichtigt werden, wobei aktive Bereitstellungsstempel in zwei oder mehr Cloudanbietern gehostet werden und redundante Routingtechnologien von Drittanbietern für globales Routing verwendet werden.

Azure kann effektiv in andere Cloudplattformen integriert werden. Es wird jedoch dringend empfohlen, einen Multicloud-Ansatz nicht anzuwenden, da es erhebliche betriebstechnische Komplexität mit unterschiedlichen Bereitstellungsstempeldefinitionen und Darstellungen des Betriebszustands auf den verschiedenen Cloudplattformen einführt. Diese Komplexität führt wiederum zu zahlreichen Resilienzrisiken innerhalb des normalen Betriebs der Anwendung, die die hypothetischen Risiken eines globalen Plattformausfalls weit überwiegen.

• Obwohl nicht empfohlen, sollten Sie für HTTP(s) Workloads, die Azure Traffic Manager für globale Routingredundanz zu Azure Front Door verwenden, in Betracht ziehen, die Webanwendungsfirewall (WAF) in das Anwendungsgateway zu entladen, um akzeptablen Datenverkehr über Azure Front Door zu ermöglichen.
  • Dadurch wird ein zusätzlicher Fehlerpunkt auf den Standardeingangspfad, eine zusätzliche Komponente für kritische Pfade zum Verwalten und Skalieren eingeführt, und es entstehen auch zusätzliche Kosten, um die globale Hochverfügbarkeit sicherzustellen. Es wird jedoch das Ausfallszenario erheblich vereinfachen, indem die Konsistenz zwischen den akzeptablen und nicht akzeptablen Eingangspfaden durch Azure Front Door und Azure Traffic Manager bereitgestellt wird, sowohl hinsichtlich der WAF-Ausführung als auch privater Anwendungsendpunkte.
  • Der Verlust der Edgezwischenspeicherung in einem Fehlerszenario wirkt sich auf die Gesamtleistung aus, und dies muss mit einem akzeptablen Dienstniveau oder einer Milderung des Entwurfsansatzes übereinstimmen. Um ein einheitliches Serviceniveau zu gewährleisten, sollten Sie das Entladen der Edgezwischenspeicherung für beide Pfade in einen CDN-Anbieter eines Drittanbieters in Betracht ziehen.

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 die Notwendigkeit zum Verwalten von Zertifikatlebenszyklus zu entfernen.

• Verwenden Sie die Azure Front Door Web Application Firewall (WAF), um Schutz vor allgemeinen Web-Exploits und Sicherheitsrisiken wie sql injection bereitzustellen.

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

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

• Konfigurieren Sie die Eingangspunkte der Anwendungsplattform, um eingehende Anforderungen mithilfe der X-Azure-FDID mithilfe der X-Azure-FDID zu überprüfen, um sicherzustellen, dass der gesamte Datenverkehr über die konfigurierte Front Door-Instanz fließt. Erwägen Sie auch die Konfiguration von IP ACLing mithilfe von Front Door Service Tags zum Überprüfen des Datenverkehrs aus dem Azure Front Door-IP-Adressraum und Azure-Infrastrukturdiensten. Dadurch wird sichergestellt, dass der Datenverkehr über Azure Front Door auf Dienstebene fließt, die Headerbasierte Filterung ist jedoch weiterhin erforderlich, um sicherzustellen, dass eine konfigurierte Front Door-Instanz verwendet wird.

• Definieren Sie einen benutzerdefinierten TCP-Integritätsendpunkt, um kritische downstreame Abhängigkeiten innerhalb eines regionalen Bereitstellungsstempels zu überprüfen, einschließlich Datenplattformreplikate, z. B. Azure Cosmos DB im Beispiel der grundlegenden Referenzimplementierung. Wenn eine oder mehrere Abhängigkeiten ungesund werden, sollte die Integritätssonde dies in der zurückgegebenen Antwort wiedergeben, damit der gesamte regionale Stempel aus dem Verkehr gezogen werden kann.

• Stellen Sie sicher, dass Die Antworten auf Integritätssonden protokolliert und alle betriebstechnischen Daten erfasst werden, die von Azure Front Door im globalen Log Analytics-Arbeitsbereich verfügbar gemacht werden, um eine einheitliche Datensenke und eine einheitliche Betriebsansicht in der gesamten Anwendung zu ermöglichen.

• Es sei denn, die Workload ist äußerst latenzempfindlich, verteilen Sie den Datenverkehr gleichmäßig über alle als regionalen Stempel betrachteten, um die bereitgestellten 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 erfüllen. Stellen Sie eine Toleranz sicher, die für die Anwendungsarbeitsauslastung in Bezug auf die gesamte Latenz der Clientanforderung akzeptabel ist.

• Aktivieren Sie die Sitzungsaffinität nur, wenn sie von der Anwendung benötigt wird, da sie negative Auswirkungen auf die Datenverkehrsverteilung haben kann. Bei einer vollständig zustandslosen Anwendung kann jede Anforderung von einer der regionalen Bereitstellungen behandelt werden, wenn der empfohlene, unternehmenskritische Anwendungsentwurfsansatz befolgt wird.

Azure Traffic Manager

• Verwenden Sie Traffic Manager für Nicht-HTTP/S-Szenarien 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 Datenverkehrs-Manager-Eingangspfad mit Azure-App lication Gateway berücksichtigt werden.

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

• Ähnlich wie bei Azure Front Door sollte ein benutzerdefinierter TCP-Integritätsendpunkt definiert werden, um kritische nachgeschaltete Abhängigkeiten innerhalb eines regionalen Bereitstellungsstempels zu überprüfen, der in der Antwort von Integritätsendpunkten widergespiegelt werden sollte.

  Für Traffic Manager sollten jedoch zusätzliche Überlegungen an regionale Fehler auf Dienstebene übergeben werden. z. B. "Dog Legging", 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 TTL für DNS-Einträge festzulegen.

• Berücksichtigen Sie die CdN-Anbieter von Drittanbietern, um die Edgezwischenspeicherung bei Verwendung von Azure Traffic Manager als primären globalen Routingdienst zu erzielen. Wenn edge-WAF-Funktionen auch vom Drittanbieterdienst angeboten werden, sollten Sie berücksichtigen, um den Eingangspfad zu vereinfachen und die Notwendigkeit für das Anwendungsgateway potenziell zu beseitigen.

Anwendungsbereitstellungsdienste

Der Netzwerkausgangspfad für eine unternehmenskritische Anwendung muss auch Anwendungsbereitstellungsdienste in Betracht ziehen, um einen sicheren, zuverlässigen und skalierbaren Eingangsdatenverkehr sicherzustellen.

Dieser Abschnitt baut auf globalen Routingempfehlungen auf, indem sie wichtige Funktionen für die Anwendungsbereitstellung untersuchen und relevante Dienste wie Azure Load Balancer Standard, Azure-App lication Gateway und Azure API Management berücksichtigen.

Überlegungen zum Entwurf

• DIE TLS-Verschlüsselung ist wichtig, um die Integrität des eingehenden Benutzerdatenverkehrs an eine unternehmenskritische Anwendung sicherzustellen, wobei tls Offloading nur an der Stelle des Eingangs eines Stempels zum Entschlüsseln eingehender Datenverkehr angewendet wird. Tls Offloading Erfordert den privaten Schlüssel des TLS-Zertifikats zum Entschlüsseln des Datenverkehrs.

• Eine Webanwendungsfirewall bietet Schutz vor allgemeinen Web-Exploits und Sicherheitsrisiken, z. B. SQL-Einfügung oder websiteübergreifendes Skripting, und ist unerlässlich, um die höchsten Zuverlässigkeitsansprüche 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-App lication Gateway oder Azure CDN (derzeit in der öffentlichen Vorschau) aktiviert werden.
    • Die auf den einzelnen Diensten angebotenen Funktionen unterscheiden sich geringfügig. Beispielsweise bietet der Azure Front Door WAF einen Grenzwert für die Geschwindigkeit, geofilterung und Bot-Schutz, die noch nicht im WaF des Anwendungsgateways angeboten werden. Sie alle unterstützen jedoch sowohl integrierte als auch benutzerdefinierte Regeln und können so festgelegt werden, dass sie im Erkennungsmodus oder im Präventionsmodus ausgeführt werden.
    • Die Roadmap für Azure WAF stellt sicher, dass ein einheitlicher WAF-Featuresatz für alle Dienstintegrationen bereitgestellt wird.

• Waf-Technologien von Drittanbietern wie NVAs und erweiterte Eingangscontroller in Kubernetes können auch als erforderliche Sicherheitsanfälligkeit betrachtet werden.

• Optimale WAF-Konfiguration erfordert in der Regel Feinabstimmungen, 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 trägt dazu bei, volumetrische Angriffe, die über Protokolle und Ports verteilt sind, sowie DNS-Vergiftungs- und TCP-Vergiftungsangriffe zu minimieren.

• Azure Front Door ist eine globale Azure-Ressource, sodass die Konfiguration global für alle Edgestandorte bereitgestellt wird.

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

• 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 betriebstechnischen Ansatz und trägt dazu bei, die Komplexität im Gesamtentwurf zu reduzieren, indem die Zertifikatverwaltung innerhalb eines einzigen Bereichs der Lösung ausgeführt wird.

• Azure Front Door dreht automatisch "Verwaltete" Zertifikate mindestens 60 Tage vor dem Ablauf des Zertifikats, um 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 zu Ausfallzeiten, wenn Azure Front Door zwischen "Verwaltet" und "Eigenes Zertifikat verwenden" gewechselt wird.

• Azure Front Door ist standardmäßig durch Azure DDoS Protection Basic geschützt, das standardmäßig in front door integriert ist. Dies bietet always-on Traffic Monitoring, Echtzeit-Entschärfung und schützt auch gegen allgemeine Layer 7 DNS-Abfragefluten oder Volumetric-Angriffe der Ebene 3/4.

  • Diese Schutzmaßnahmen tragen dazu bei, die Verfügbarkeit von Azure Front Door auch bei einem DDoS-Angriff zu Standard. Verteilte Denial of Service (DDoS)-Angriffe können eine zielorientierte Ressource nicht verfügbar machen, indem sie ihn mit unlegitim Datenverkehr überwältigen.

• Azure Front Door bietet auch WAF-Funktionen auf globaler Datenverkehrsebene, während das Anwendungsgateway-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 von einer SLA unterstützt und verfügt über mehrere Funktionseinschränkungen im Vergleich zur Standard-SKU.

Entwurfsempfehlungen

• Führen Sie das TLS-Offloading an so wenigen Stellen wie möglich durch, um die Sicherheit zu Standard und gleichzeitig den Zertifikatverwaltungslebenszyklus zu vereinfachen.

• Verwenden Sie verschlüsselte Verbindungen (z. B. HTTPS) von dem Punkt, an dem tls offloading in die eigentlichen Anwendungs-Back-Ends erfolgt. Anwendungsendpunkte sind für Endbenutzer nicht sichtbar, sodass von Azure verwaltete Aktionen Standard, zazurewebsites.net. B. oder cloudapp.net, mit 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ügbaren Endpunkte angewendet werden.

• Aktivieren Sie WAF-Funktionen an einem einzigen Dienststandort, entweder global mit Azure Front Door oder regional mit Azure-App lication Gateway, da dies die Optimierung der Konfiguration vereinfacht und die Leistung und Die 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 sie über 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 statische Inhaltsübermittlung

Eine besondere Behandlung statischer Inhalte wie Bilder, JavaScript, CSS und andere Dateien kann erhebliche Auswirkungen auf die gesamtbenutzererfahrung sowie auf die Gesamtkosten der Lösung haben. Das Zwischenspeichern statischer Inhalte am Edge kann die Ladezeiten des Clients 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 dienen sowohl statischen Ressourcen (Bilder, JavaScript, CSS, Lokalisierungsdateien usw.) als auch dynamischen Inhalten.
• Arbeitsauslastungen mit häufig aufgerufenen statischen Inhalten profitieren erheblich von der Zwischenspeicherung, da dadurch die Last für Back-End-Dienste reduziert und die Latenz des Inhaltszugriffs für Endbenutzer reduziert wird.
• Zwischenspeichern kann nativ in Azure mithilfe von Azure Front Door oder Azure Content Delivery Network (CDN) implementiert werden.
  • Azure Front Door bietet Azure-native Edgezwischenspeicherungsfunktionen und Routingfunktionen, um statische und dynamische Inhalte aufzuteilen.
    • Durch die Erstellung der entsprechenden Routingregeln in Azure Front Door /static/* können Datenverkehr transparent zu statischen Inhalten umgeleitet werden.
  • Komplexere Zwischenspeicherungsszenarien können mithilfe des Azure CDN-Diensts implementiert werden, um ein umfassendes Inhaltsübermittlungsnetzwerk für erhebliche statische Inhaltsvolumes einzurichten.
    • Der Azure CDN-Dienst wird wahrscheinlich kostengünstiger sein, bietet jedoch nicht die gleichen erweiterten Routing- und WAF-Funktionen (Web Application Firewall), die für andere Bereiche eines Anwendungsdesigns empfohlen werden. Es bietet jedoch weitere Flexibilität, um mit ähnlichen Diensten von Drittanbieterlösungen wie Akamai und Verizon zu integrieren.
  • Beim Vergleich der Azure Front Door- und Azure CDN-Dienste sollten die folgenden Entscheidungsfaktoren untersucht werden:
    • Kann mithilfe des Regelmoduls erforderliche Zwischenspeicherungsregeln durchgeführt werden.
    • Größe des gespeicherten Inhalts und der zugehörigen Kosten.
    • Preis pro Monat für die Ausführung des Regelmoduls (berechnet pro Anforderung auf Azure Front Door).
    • Anforderungen für ausgehenden Datenverkehr (Preis unterscheidet sich je nach Ziel).

Entwurfsempfehlungen

• Generierter, statischer Inhalt wie Kopien von Bilddateien, die sich nie oder nur selten ändern, kann auch von der Zwischenspeicherung profitieren. Zwischenspeichern 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 globale Routing- und Webanwendungsfirewall (WAF)-Zwecke empfiehlt es sich, die Verwendung von Azure Front Door-Cachefunktionen zu priorisieren, es sei denn, Es gibt Lücken.

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 wird die Methode, mit der die Anwendungsintegration erreicht wird, erhebliche Auswirkungen auf die Sicherheit, Leistung und Zuverlässigkeit der Lösung haben und sich stark auf Designentscheidungen innerhalb anderer Designbereiche auswirken.

Eine unternehmenskritische Anwendung kann in einer von drei übergeordneten Netzwerkkonfigurationen bereitgestellt werden, die bestimmt, 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 in einer Azure-Zielzone konfigurieren Sie Konfiguration 1. sollte innerhalb einer Online-Zielzone bereitgestellt werden, während sowohl 2) als auch 3) innerhalb einer Corp. Verbinden ed Landing Zone bereitgestellt werden sollten, um die Integration auf Netzwerkebene zu erleichtern.

In diesem Abschnitt werden diese Netzwerkintegrationsszenarien erläutert, die Schichtung in der geeigneten Verwendung von Azure Virtual Networks und umgebenden Azure-Netzwerkdiensten, um sicherzustellen, dass die Integrationsanforderungen optimal erfüllt sind.

Entwurfsaspekte

Keine virtuellen Netzwerke

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

  • Verbinden ivität zwischen allen als azure-Diensten betrachteten Diensten wird vollständig über öffentliche Endpunkte und das Microsoft Azure-Backbone bereitgestellt. Verbinden ivity between public endpoints hosted on Azure will only traverse the Microsoft backbone and will't go over the public internet.
  • Verbinden ivität für externe Systeme außerhalb von Azure wird vom öffentlichen Internet bereitgestellt.

• Dieser Designansatz verwendet "Identität als Sicherheitsperimeter", um die Zugriffssteuerung zwischen den verschiedenen Dienstkomponenten und abhängigen Lösungen 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, bezieht sie anfällig für zusätzliche Angriffsvektoren, die darauf ausgerichtet sind, nicht autorisierten Zugriff zu erlangen.

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

Isolierte virtuelle Netzwerke

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

• Eingehende Clientanforderungen erfordern weiterhin einen öffentlichen Endpunkt, der für das Internet verfügbar gemacht werden kann, aber alle nachfolgenden Kommunikationen können sich innerhalb des virtuellen Netzwerks befinden, indem private Endpunkte verwendet werden. Bei Verwendung von Azure Front Door Premium ist es möglich, direkt von Edgeknoten zu privaten Anwendungsendpunkten zu leiten.

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

  • Verbinden ivität für Azure-Plattformdienste können bei Unterstützung mit privaten Endpunkten eingerichtet werden. Wenn andere externe Abhängigkeiten in Azure vorhanden sind, z. B. eine andere downstream-Anwendung, wird die Konnektivität über öffentliche Endpunkte und das Microsoft Azure-Backbone bereitgestellt.
  • Verbinden ivität für externe Systeme außerhalb von Azure würde durch das öffentliche Internet bereitgestellt.

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

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

• Die Verwendung virtueller Anwendungsnetzwerke führt zu erheblichen Bereitstellungskomplexen in CI/CD-Pipelines, da sowohl der Zugriff auf datenebene als auch der Steuerungsebenenzugriff auf Ressourcen, die in privaten Netzwerken gehostet werden, erforderlich ist, um Anwendungsbereitstellungen zu erleichtern.

  • Der sichere private Netzwerkpfad muss eingerichtet werden, damit CI/CD-Tools erforderliche Aktionen ausführen können.
  • Private Build-Agents können in virtuellen Anwendungsnetzwerken bereitgestellt werden, um den Proxyzugriff auf ressourcen zu verwenden, die durch das virtuelle Netzwerk gesichert sind.

Verbundenen virtuellen Netzwerken

• Für Szenarien mit Anforderungen an die Integration externer Netzwerke können virtuelle Anwendungsnetzwerke mit anderen virtuellen Netzwerken in Azure, einem anderen Cloudanbieter oder lokalen Netzwerken mit einer Vielzahl von Konnektivitätsoptionen verbunden werden. Einige Anwendungsszenarien können beispielsweise die Integration auf Anwendungsebene in andere Branchenanwendungen in Betracht ziehen, die privat in einem lokalen Unternehmensnetzwerk gehostet werden.

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

• Überlappende IP-Adressräume in Azure-Regionen oder lokalen Netzwerken führen zu einem wichtigen Streit, wenn die Netzwerkintegration berücksichtigt wird.

  • Eine virtuelle Netzwerkressource kann aktualisiert werden, um zusätzlichen Adressraum in Betracht zu ziehen, wenn jedoch ein virtueller Netzwerkadressraum eines peered-Netzwerks eine Synchronisierung auf dem Peeringlink ändert, was das Peering vorübergehend deaktiviert.
  • Azure reserviert fünf IP-Adressen innerhalb jedes Subnetzes, die bei der Ermittlung der geeigneten Größen für virtuelle Anwendungsnetzwerke und umfasste 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ß wie unnötige Abfalladressen.

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

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

Hinweis

Beachten Sie bei der Bereitstellung in einer Azure-Zielzone, dass alle erforderlichen Verbindungen mit lokalen Netzwerken von der Implementierung der Zielzone bereitgestellt werden sollten. Das Design kann ExpressRoute und andere virtuelle Netzwerke in Azure entweder mit virtuellem WAN oder einem Hub-and-Spoke-Netzwerkdesign 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 Standard.

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 berücksichtigt werden, die private Verknüpfung unterstützen, vorausgesetzt, dass Datenexfiltrationsrisiken akzeptabel oder durch alternative Steuerelemente abgemildert 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.

• Wenn Sie eine Verbindung mit anderen Azure- oder lokalen Netzwerken herstellen, sollten virtuelle Anwendungsnetzwerke nicht als kurzlebig behandelt werden, da sie erhebliche Komplikationen verursacht, wenn virtuelle Netzwerkpeering- und Virtuelle Netzwerkgatewayressourcen betroffen sind. Alle relevanten Anwendungsressourcen innerhalb des virtuellen Netzwerks sollten weiterhin kurzlebig sein, wobei parallele Subnetze verwendet werden, um blaugrüne Bereitstellungen aktualisierter regionaler Bereitstellungsstempel zu erleichtern.

• 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 Adresszuweisung für privates Internet (RFC 1918) zu verwenden.
    • Für Umgebungen mit eingeschränkter Verfügbarkeit privater IP-Adressen (RFC 1918) sollten Sie IPv6 verwenden.
    • Wenn die Verwendung der öffentlichen IP-Adresse erforderlich ist, stellen Sie sicher, dass nur eigene Adressblöcke verwendet werden.
  • Richten Sie sich an Organisationsplänen für die IP-Adressierung in Azure, um sicherzustellen, dass der Ip-Adressraum des Anwendungsnetzwerks nicht mit anderen Netzwerken über lokale Standorte oder Azure-Regionen hinweg überlappt.
  • Erstellen Sie nicht unnötig große virtuelle Anwendungsnetzwerke, um sicherzustellen, dass der IP-Adressraum nicht verschwendet wird.

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

  • Berücksichtigen 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 berücksichtigen Sie Kubenet für Szenarien mit einem begrenzten Bereich verfügbarer IP-Adressen. Weitere Details finden Sie unter Microsegmentation und Kubernetes-Netzwerkrichtlinien .

• Für Szenarien, die eine lokale Netzwerkintegration erfordern, priorisieren Sie die Verwendung der Express-Route, um eine sichere und skalierbare Konnektivität sicherzustellen.

  • Stellen Sie sicher, dass die zuverlässigkeitsstufe, die auf die ExpressRoute oder vpn angewendet wird, den Anwendungsanforderungen vollständig entspricht.
  • Bei Bedarf sollten mehrere Netzwerkpfade berücksichtigt werden, um zusätzliche Redundanz bereitzustellen, z. B. verbundene ExpressRoute-Schaltkreise oder die Verwendung von VPN als Failoververbindungsmechanismus.

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

  Hinweis

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

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

Internet (ausgehend)

Der Internetausgang ist eine grundlegende Netzwerkanforderung für eine unternehmenskritische Anwendung zur Erleichterung der externen Kommunikation im Kontext von:

1. Direkte Anwendungsbenutzerinteraktion.
2. Anwendungsintegration in externe 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 der Internetausgang erreicht werden kann, während gleichzeitig sichergestellt wird, dass Sicherheit, Zuverlässigkeit und nachhaltige Leistung Standard beibehalten werden, wobei wichtige Ausgangsanforderungen für dienste hervorgehoben werden, die in einem unternehmenskritischen Kontext empfohlen werden.

Entwurfsaspekte

• Viele Azure-Dienste erfordern Zugriff auf öffentliche Endpunkte für verschiedene Verwaltungs- und Steuerungsebenenfunktionen, die wie beabsichtigt funktionieren.

• Azure bietet unterschiedliche Methoden für ausgehende Internetkonnektivität, z. B. Azure NAT-Gateway oder Azure Load Balancer, für virtuelle Computer oder Computeinstanzen in einem virtuellen Netzwerk.

• Wenn datenverkehr von innerhalb eines virtuellen Netzwerks in das Internet übergegangen wird, muss netzwerkadressübersetzung (NETWORK Address Translation, NAT) stattfinden. Dies ist ein Berechnungsvorgang, der innerhalb des Netzwerkstapels auftritt und sich daher auf die Systemleistung auswirken kann.

• Wenn NAT in einem kleinen Maßstab stattfindet, sollte die Leistungsauswirkung gering sein, wenn jedoch eine große Anzahl von Problemen mit ausgehenden Anforderungen auftreten kann. Diese Probleme treten in der Regel in Form von "Quell-NAT(oder SNAT)-Portausschöpfung" auf.

• In einer mehrinstanzenübergreifenden Umgebung, z. B. Azure-App Dienst, stehen für jede Instanz eine begrenzte Anzahl ausgehender Ports zur Verfügung. Wenn diese Ports auslaufen, können keine neuen ausgehenden Verbindungen initiiert werden. Dieses Problem kann verringert werden, indem die Anzahl privater/öffentlicher Edge-Traversen oder eine skalierbarere NAT-Lösung wie das Azure NAT-Gateway verwendet wird.

• Zusätzlich zu NAT-Einschränkungen kann der ausgehende Datenverkehr auch den erforderlichen Sicherheitskontrollen unterliegen.

  • Azure Firewall bietet geeignete Sicherheitsfunktionen zum Sichern des Netzwerkausgangs.

  • Azure Firewall (oder eine entsprechende NVA) kann verwendet werden, um Kubernetes-Ausgangsanforderungen zu sichern, indem sie eine präzise Kontrolle über ausgehende Datenverkehrsflüsse bereitstellen.

• Große Mengen an Internetausgang verursachen Gebühren für die Datenübertragung.

Azure NAT Gateway

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

  • Bis zu 16 IP-Adressen können einem einzelnen NAT-Gateway zugewiesen werden.
  • Ein standardmäßiges TCP-Leerlauftimeout von 4 Minuten. Wenn das Leerlauftimeout auf einen höheren Wert geändert wird, werden die Abläufe länger gehalten, wodurch der Druck auf das SNAT-Portinventar erhöht wird.

• Das NAT-Gateway kann keine sofort einsatzbereite Zonalisolation bereitstellen. Um Zonalredundanz zu erhalten, muss ein Subnetz, das Zonalressourcen enthält, an den entsprechenden natalen NAT-Gateways ausgerichtet werden.

Entwurfsempfehlungen

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

  • Wenn eine große Anzahl von internetgebundenen Verbindungen erforderlich ist, sollten Sie das Azure NAT-Gateway verwenden, um ausgehende Datenverkehrsflüsse abzustrahieren.

• Verwenden Sie Azure Firewall, in denen Anforderungen zum Steuern und Überprüfen des ausgehenden Internetdatenverkehrs vorhanden sind.

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

Hinweis

Berücksichtigen Sie bei der Bereitstellung in einer Azure-Zielzone die Verwendung der grundlegenden Azure Firewall-Ressource (oder gleichwertiger NVA). Wenn eine Abhängigkeit von einer zentralen Plattformressource für den Internetausgang übernommen wird, sollte die Zuverlässigkeitsebene dieser Ressource und des zugeordneten Netzwerkpfads eng mit den Anwendungsanforderungen übereinstimmen. Betriebsdaten aus der Ressource sollten auch der Anwendung zur Verfügung gestellt werden, um potenzielle operative Maßnahmen in Ausfallszenarien zu informieren.

Wenn es hohe Anforderungen an ausgehenden Datenverkehr gibt, sollten Sie eine dedizierte Azure Firewall-Ressource für eine unternehmenskritische Anwendung berücksichtigen, um Risiken zu minimieren, die mit der Verwendung einer zentral freigegebenen Ressource verbunden sind, wie z. B. laute Nachbarszenarien.

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

Interzone und interregionale Verbinden ivitä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 durch die Ü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 Zonenredundanz, die auf allen Komponentenebenen innerhalb einer region angewendet werden.

• Eine Verfügbarkeitszone (Availability Zone, AZ) ist ein physisch separater Rechenzentrumsstandort innerhalb einer Azure-Region, der eine physische und logische Fehlerisolation bis zur Ebene eines einzelnen Rechenzentrums bereitstellt.

  Eine Roundtriplatenz von weniger als 2 ms ist für die kommunikation zwischen den Zonen garantiert. Zonen haben eine geringe Latenzabweichung bei unterschiedlichen Entfernungen und Faserpfaden zwischen Zonen.

• Die Verfügbarkeitszone-Konnektivität hängt von regionalen Merkmalen ab, und daher muss der Datenverkehr, der über einen Edgestandort in eine Region eintritt, möglicherweise zwischen Zonen geleitet werden, um sein Ziel zu erreichen. Dadurch wird eine ~1 ms-2ms-Latenz bei interzonenübergreifendem Routing und "Geschwindigkeit der Lichtgeschwindigkeit" hinzugefügt, dies sollte jedoch nur für hypersensitive Workloads geeignet sein.

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

• Mit Anwendungsszenarien, die extrem chatty zwischen Anwendungskomponenten sind, können die Verbreitung von Anwendungsebenen über Zonen hinweg erhebliche Latenz und höhere Kosten bedeuten. Es ist möglich, dies innerhalb des Entwurfs zu verringern, indem sie einen Bereitstellungsstempel auf eine einzelne Zone beschränken und mehrere Stempel in den verschiedenen Zonen bereitstellen.

• Die Kommunikation zwischen verschiedenen Azure-Regionen verursacht eine größere Datenübertragungsgebühr pro GB Bandbreite.

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

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

• Für Dienste zur Dienstkommunikation kann private Verknüpfung für die direkte Kommunikation mit privaten Endpunkten verwendet werden.

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

  • Das Anheften von Datenverkehr über Express Route umgeht Die Kosten für die Datenübertragung im Zusammenhang mit virtuellem Netzwerk-Peering, sodass sie als Möglichkeit zur Optimierung der Kosten verwendet werden können.
  • Dieser Ansatz erfordert zusätzliche Netzwerkhüpfungen für die Anwendungsintegration in Azure, wodurch Latenz- und Zuverlässigkeitsrisiken entstehen. Erweitert die Rolle von Express Route und zugehörigen Gatewaykomponenten von Azure/lokal, um auch Azure/Azure-Konnektivität einzuschließen.

• Wenn zwischen Diensten submillisekunden Latenz 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 Verknüpfung, um die Kommunikation direkt zwischen Diensten in derselben Region oder regionenübergreifend herzustellen (Dienst in Region A, die mit dem Dienst in Region B kommunizieren.

• 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 über Regionen hinweg zu synchronisieren, anstatt Konsistenz auf Anwendungsebene mit direkten Netzwerkpfaden zu erzielen.
  • Vermeiden Sie Denkverkehr zwischen verschiedenen Regionen, es sei denn, es ist notwendig, auch in einem Ausfallszenario. Verwenden Sie globale Routingdienste und End-to-End-Integritätssonden, um einen vollständigen Stempel aus dem Verkehr zu ziehen, wenn eine einzelne kritische Komponentenebene fehlschlägt, anstatt Datenverkehr auf dieser fehlerhaften Komponentenebene an eine andere Region weiterzuleiten.

• Priorisieren Sie bei Szenarien mit vertraulichen Hyperlatenzanwendungen die Verwendung von Zonen mit regionalen Netzwerkgateways, um die Netzwerklatenz für Eingangspfade zu optimieren.

Netzwerkrichtlinien für Mikrosegmentierung und Kubernetes

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. Es wird in der Regel angewendet, um die Netzwerkangriffsoberfläche zu reduzieren, die Sicherheitseindämmung zu verbessern und die Sicherheit durch richtliniengesteuerte Netzwerksteuerelemente auf Anwendungsebene zu stärken.

Eine unternehmenskritische Anwendung kann die Netzwerksicherheit auf Anwendungsebene mithilfe von Netzwerksicherheitsgruppen (Network Security Groups, NSG) auf Subnetz- oder Netzwerkschnittstellenebene, Dienstzugriffssteuerungslisten (Access Control Lists, ACL) und Netzwerkrichtlinien bei Verwendung von Azure Kubernetes Service (AKS) erzwingen.

In diesem Abschnitt wird der optimale Einsatz dieser Funktionen erläutert, wobei wichtige Überlegungen und Empfehlungen zur Erreichung der Mikrosegmentierung auf Anwendungsebene bereitgestellt werden.

Entwurfsaspekte

• AKS kann in zwei verschiedenen Netzwerkmodellen bereitgestellt werden:

  • Kubenet-Netzwerk: AKS-Knoten sind in ein vorhandenes virtuelles Netzwerk integriert, aber Pods existieren in einem virtuellen Überlagerungsnetzwerk auf jedem Knoten. 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 und seine Knoten, Pods und Dienste, die 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 Verbindung von und zu Pods erfordern. Verschiedene Knotenpools können in verschiedenen Subnetzen bereitgestellt werden.

  Hinweis

  Azure CNI erfordert mehr IP-Adressraum im Vergleich zu Kubenet. Die richtige Planung 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 von jeder Quelle und können Datenverkehr an jedes beliebige Ziel senden. ein Pod kann mit jedem anderen Pod in einem bestimmten Kubernetes-Cluster kommunizieren; Kubernetes stellt keine Netzwerkebenenisolation 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 Bezeichnungsmarkierern entsprechen.

  • AKS unterstützt zwei Plug-Ins, die Netzwerkrichtlinie, Azure und Calico implementieren. 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 gehen nicht in Konflikt, da sie additiv sind.
  • Damit ein Netzwerkfluss zwischen zwei Pods zulässig ist, müssen sowohl die Ausgangsrichtlinie auf dem Quell pod als auch die Eingangsrichtlinie für den Ziel-Pod den Datenverkehr zulassen.
  • Das Netzwerkrichtlinienfeature kann nur zur Clusterinstanziierung aktiviert werden. Es ist nicht möglich, Netzwerkrichtlinien für einen vorhandenen AKS-Cluster zu aktivieren.
  • Die Bereitstellung von Netzwerkrichtlinien ist konsistent, unabhängig davon, ob Azure oder Calico verwendet wird.
  • 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 verschiedene Subnetze innerhalb desselben virtuellen Netzwerks verwenden. NSGs können auf Subnetzebene angewendet werden, um die Mikrosegmentierung zwischen Knotenpools zu implementieren.

Entwurfsempfehlungen

• Konfigurieren Sie eine NSG für alle als Subnetze betrachteten Subnetze, um eine IP-ACL zum Sichern von Eingangspfaden bereitzustellen und Anwendungskomponenten basierend auf einem Zero Trust-Modell zu isolieren.

  • Verwenden Sie Front Door Service Tags innerhalb von NSGs für alle Subnetze, die Anwendungs-Back-End-Back-End-Dateien enthalten, die in Azure Front Door definiert sind, da dieser Datenverkehr aus einem legitimen Azure Front Door-IP-Adressraum stammt. Dadurch wird sichergestellt, dass der Datenverkehr über Azure Front Door auf Dienstebene fließt, aber kopfzeilenbasierte Filterung erforderlich ist, um die Verwendung einer bestimmten Front Door-Instanz sicherzustellen und auch Sicherheitsrisiken für "IP-Spoofing" zu mindern.

  • 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. Diese Netzwerkauswahl wird zur Bereitstellungszeit ausgewählt.
    • Das Azure CNI-Netzwerk-Plug-In ist ein robusteres und skalierbareres 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 zur Bereitstellungszeit.
  • Priorisieren Sie die Verwendung von Calico , da sie einen umfassenderen Featuresatz mit breiterer Communityakzeptanz und -unterstützung bietet.

Nächster Schritt

Überprüfen Sie die Überlegungen zur Quantifizierung und Beobachtung der Anwendungsintegrität.

Integritätsmodellierung und Beobachtbarkeit