Azure Virtual Machines Basisarchitektur in einer Azure Landing Zone

Azure Bastion

Azure Firewall

Azure Log Analytics

Azure Virtual Machines

Azure Virtual Network

Die Architektur in diesem Artikel erweitert die Baseline-Architektur virtual machine (VM), um Änderungen und Erwartungen zu berücksichtigen, wenn Sie sie in einer Azure Landing Zone bereitstellen.

Im Beispiel in diesem Artikel möchte eine Organisation eine VM-basierte Workload verwenden, um Verbundressourcen zu verwenden, die ein Plattformteam zentral verwaltet. Zu diesen Ressourcen gehören Netzwerkressourcen für standortübergreifende Konnektivität, Identitätszugriffsverwaltung und Richtlinien. In diesem Beispiel wird davon ausgegangen, dass die Organisation Azure Zielzonen verwendet, um eine konsistente Governance und Kosteneffizienz für mehrere Workloads zu erzwingen.

Als Workloadbesitzer können Sie die Verwaltung gemeinsam genutzter Ressourcen in zentrale Teams entladen, sodass Sie sich auf die Arbeitsauslastungsentwicklung konzentrieren können. In diesem Artikel wird die Perspektive des Workloadteams erläutert. Empfehlungen für das Plattformteam werden angegeben.

Wichtig

Was sind Azure Landezonen? Azure Landungszonen stellen zwei Perspektiven des Cloudbedarfs einer Organisation dar. Eine Application Landing Zone ist ein Azure-Abonnement, in dem eine Workload ausgeführt wird. Sie ist mit den gemeinsamen Ressourcen der Organisation verbunden. Über diese Verbindung verfügt sie über Zugriff auf die grundlegende Infrastruktur, die die Workload ausführt, z. B. Netzwerk, Identitätszugriffsverwaltung, Richtlinien und Überwachung. Eine Plattform-Landing-Zone ist eine Sammlung verschiedener Abonnements, die jeweils einer bestimmten Funktion dienen. Beispielsweise bietet ein Konnektivitätsabonnement eine zentralisierte DNS-Auflösung (Domain Name System), eine standortübergreifende Konnektivität und virtuelle Netzwerkgeräte (Virtual Appliances, NVAs), die für Anwendungsteams zur Verfügung stehen.

Es wird empfohlen, das Konzept der Azure Zielzonen zu verstehen, um Sie bei der Vorbereitung auf die Implementierung dieser Architektur zu unterstützen.

Artikellayout

Architektur	Entwurfsentscheidung	Azure Well-Architected Framework-Ansatz
▪ Architekturdiagramm ▪ Workload-Ressourcen ▪ Verbundressourcen	▪ Abonnementeinrichtung ▪ Netzwerkanforderungen ▪ Netzwerkentwurfsänderungen aus dem Basisplan ▪ Überwachung ▪ Patch-Konformität ▪ Organisations-Governance ▪ Change Management	▪ Zuverlässigkeit ▪ Sicherheit ▪ Kostenoptimierung

Tipp

Diese implementierung reference veranschaulicht die in diesem Artikel beschriebenen bewährten Methoden.

Die Repositoryartefakte bieten eine anpassbare Grundlage für Ihre Umgebung. Die Implementierung richtet ein Hubnetzwerk mit gemeinsam genutzten Ressourcen wie Azure Firewall zu Demonstrationszwecken ein. Sie können dieses Setup auf separate Anwendungslandzonenabonnements für unterschiedliche Workload- und Plattformfunktionen anwenden.

Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Alle Azure Zielzonenarchitekturen haben eine Trennung des Eigentums zwischen dem Plattformteam und dem Workload-Team. Anwendungsarchitekten und DevOps-Teams müssen ein starkes Verständnis für diese Verantwortung haben, um zu verstehen, was unter ihrem direkten Einfluss oder ihrer Kontrolle liegt und was nicht.

Arbeitsauslastung teameigene Ressourcen

Die folgenden Ressourcen bleiben gegenüber der Baselinearchitektur weitgehend unverändert.

• Azure Virtual Machines ist eine Infrastruktur als Dienst (IaaS), die skalierbare Computeressourcen bereitstellt. In dieser Architektur hosten VMs die Front-End- und Back-End-Ebenen und werden über Verfügbarkeitszonen für Resilienz verteilt.

• Azure Load Balancer ist ein Layer-4-Lastenausgleichsdienst für TCP-Datenverkehr (Transmission Control Protocol) und UDP-Datenverkehr (User Datagram Protocol). In dieser Architektur verteilt ein interner Load-Balancer den Datenverkehr von Front-End-VMs zu Back-End-VMs über Zonen hinweg.

• Azure Application Gateway ist ein Layer-7-Reverseproxy und ein Lastverteiler für Webdatenverkehr. In dieser Architektur beendet sie Transport Layer Security (TLS), prüft Anforderungen und dient als Reverseproxy, um den Benutzerdatenverkehr an Front-End-VMs weiterzuleiten. Die ausgewählte SKU hostt auch Azure Web Application Firewall, um die Front-End-VMs vor potenziell schädlichem Datenverkehr zu schützen.

• Azure Key Vault ist ein Dienst zum Verwalten von geheimen Schlüsseln, Schlüsseln und Zertifikaten. In dieser Architektur enthält sie die TLS-Zertifikate, die das Anwendungsgateway und VMs nutzen.

• Azure Monitor, Log Analytics und Application Insights sind Tools zum Sammeln, Speichern und Visualisieren von Observability-Daten. In dieser Architektur sammeln sie Gast- und Plattformmetriken und Protokolle, erfassen und korrelieren sie in einem dedizierten Arbeitsbereich und ermöglichen Telemetrie und Visualisierung auf Anwendungsebene für die Problembehandlung, Leistungsoptimierung und Governance.

• Azure Policy ist ein Dienst, der organisatorische Standards erzwingt und die Compliance im großen Maßstab bewertet. In dieser Architektur erfolgt die Anwendung workloadspezifischer Governance-Steuerelemente getrennt von plattformweiten Richtlinien.

Das Workload-Team verwaltet und erfüllt die folgenden Ressourcen und Verantwortlichkeiten.

• Satelliten-Teilnetzwerke und die Netzwerk-Sicherheitsgruppen (NSGs) bieten segmentierten IP-Adressraum und Grenzen für die Filterung von Datenverkehr. In dieser Architektur implementieren sie stufenbasierte Isolation und Steuern von Ost-West- und Eingangs- und Ausgangsflüssen für Workloadkomponenten.

• Private-Endpunkte bieten privaten IP-basierten Zugriff auf Plattformdienste über das Azure Backbone. In dieser Architektur sichern sie die Konnektivität mit Plattform as a Service (PaaS)-Lösungen und den privaten DNS-Zonen , die für diese Endpunkte erforderlich sind.

• Azure Managed Disks bieten dauerhaften, leistungsstarken Speicher für VMs. In dieser Architektur speichern sie Protokolldateien auf den Back-End-Servern, und die Daten werden auch dann beibehalten, wenn VMs neu gestartet werden. Die Front-End-Server verfügen über angefügte Datenträger, mit denen Sie Ihre zustandslose Anwendung bereitstellen können.

Ressourcen im Besitz des Plattformteams

Das Plattformteam besitzt und verwaltet diese zentralen Ressourcen. Bei dieser Architektur wird davon ausgegangen, dass diese Ressourcen vorab bereitgestellt werden und abhängigkeiten berücksichtigt werden.

• Azure Firewall im Hubnetzwerk ist ein zustandsbehafteter Netzwerksicherheitsdienst zum Filtern und Protokollieren von Datenverkehr. In dieser Architektur wird der Ausgangsverkehr aus dem Hub zentral überprüft und über erzwungenes Tunneling eingeschränkt. Diese Komponente ersetzt die öffentliche Azure Load Balancer in der Basisarchitektur, die keine Einschränkungen für ausgehenden Datenverkehr im Internet bietet.

• Azure Bastion im Hubnetzwerk ist ein architektonischer Ansatz, der Remotedesktop Protocol (RDP) und Secure Shell (SSH)-Konnektivität mit VMs über TLS bereitstellt, ohne öffentliche IP-Adressen verfügbar zu machen. In dieser Architektur stellt sie gemeinsam genutzten, geprüften Betriebszugriff auf Workload-VMs bereit. In der Basisarchitektur besitzt das Workloadteam diese Komponente.

• Das virtuelle Speichennetzwerk ist ein isolierter Adressraum, der mit einem Hub für gemeinsame Dienste verknüpft ist. In dieser Architektur hostet diese Architektur die Compute-, Ingress- und verwandten Ressourcen der Workload unter der Verantwortung des Teams.

• Benutzerdefinierte Routen (UDRs) sind benutzerdefinierte Routingregeln, mit denen Sie Routingtabellen anpassen können, um den Datenverkehr über bestimmte nächste Hops zu leiten. In dieser Architektur erzwingen sie den gesamten internetgebundenen Datenverkehr über die Firewall des Hubs.

• Azure Policy-basierte Governance-Einschränkungen und DeployIfNotExists (DINE)-Richtlinien stellen automatisch die erforderlichen Ressourcen für die Konformität bereit oder konfigurieren sie. In dieser Architektur stellen sie sicher, dass im Workloadabonnement vorgeschriebene plattformorientierte Konfigurationen vorhanden sind, z. B. private DNS oder Diagnose.

Wichtig

Azure Zielzonen stellen einige der vorherigen Ressourcen als Teil der Abonnements für die Plattform-Zielzone bereit, und Ihr Workload-Abonnement stellt weitere Ressourcen bereit. Viele der Ressourcen sind Teil des Konnektivitätsabonnements, das zusätzliche Ressourcen wie Azure ExpressRoute, Azure VPN Gateway und Azure DNS enthält. Diese zusätzlichen Ressourcen bieten Zugang über mehrere Standorte hinweg und Namensauflösung. Die Verwaltung dieser Ressourcen liegt außerhalb des Umfangs dieses Artikels.

Abonnementeinrichtung

In einem Anwendungslandungszonenkontext muss Ihr Workloadteam das Plattformteam über ihre spezifischen Anforderungen informieren.

Ihr Workload-Team muss detaillierte Informationen zum benötigten Netzwerkraum enthalten, damit das Plattformteam die erforderlichen Ressourcen zuordnen kann. Ihr Team bestimmt die Anforderungen, und das Plattformteam bestimmt die IP-Adressen, die innerhalb des virtuellen Netzwerks zugewiesen werden sollen, und die Verwaltungsgruppe, der das Abonnement zugewiesen ist.

Das Plattformteam weist eine entsprechende Verwaltungsgruppe basierend auf der geschäftlichen Kritikalität und den technischen Anforderungen der Workload zu, z. B. wenn eine Workload dem Internet ausgesetzt ist. Die Organisation bestimmt die Konfiguration dieser Verwaltungsgruppen, und das Plattformteam implementiert sie.

Beispielsweise werden die Verwaltungsgruppen in den Anwendungsszenarien für die Basisarchitektur berücksichtigt:

• Private-Anwendungen, z. B. interne Branchenanwendungen oder kommerzielle Off-the-Shelf-Lösungen (COTS), die sich häufig unter der Unternehmensleitungsgruppe Azure Landezonen befinden.

• Öffentliche Anwendungen, wie bei internetgerichteten Anwendungen, die häufig unter der Unternehmens- oder Online-Verwaltungsgruppe liegen.

Das Plattformteam ist auch für das Einrichten eines Abonnements oder einer Gruppe von Abonnements für die Workloadbereitstellung verantwortlich.

In den folgenden Abschnitten finden Sie Anleitungen zum anfänglichen Abonnementsetup. Das Plattformteam nimmt jedoch in der Regel Änderungen an den zentralen Diensten vor, um verpasste oder geänderte Anforderungen zu erfüllen. Plattformänderungen haben einen breiteren Einfluss auf alle Workload-Teams.

Daher muss das Plattformteam sicherstellen, dass alle VM-Workloads für alle Änderungen vorbereitet sind, und sie müssen den Lebenszyklus der VM-basierten Lösung und des Testzyklus kennen. Weitere Informationen finden Sie unter Verwalten von Änderungen im Laufe der Zeit.

Workloadanforderungen und Erfüllungen

Das Workload-Team und die Plattformteams teilen zwei Hauptaufgaben: Verwaltungsgruppenzuweisung und Netzwerkeinrichtung. Berücksichtigen Sie für diese Architektur die folgenden Netzwerkanforderungen, die Sie dem Plattformteam mitteilen sollten. Verwenden Sie diese Punkte als Beispiele, um die Diskussion und Aushandlung zwischen den beiden Teams zu verstehen, wenn Sie eine ähnliche Architektur implementieren.

• Die Anzahl der virtuellen Speichennetzwerke: In dieser Architektur ist nur ein dedizierter Speichen erforderlich. Die bereitgestellten Ressourcen müssen sich nicht über mehrere Netzwerke erstrecken und in einem einzigen virtuellen Netzwerk zusammengefasst werden.

• Die Größe des Speichennetzes: Berücksichtigen Sie die betrieblichen Anforderungen und das erwartete Wachstum der Arbeitsauslastung. Wenn Sie zum Beispiel Blau/Grün- oder Canary-Updates implementieren möchten, sollte die maximale Größe den benötigten Platz für Ihre parallelen Bereitstellungen berücksichtigen.

  Zukünftige Änderungen erfordern möglicherweise mehr IP-Adressenbereich, was möglicherweise nicht mit der aktuellen Zuweisung übereinstimmt. Die Integration dieser Räume kann zu einer zusätzlichen Komplexität führen. Seien Sie proaktiv und fordern Sie vorab genügend Netzwerkressourcen an, um sicherzustellen, dass der zugewiesene Speicherplatz zukünftige Erweiterungen aufnehmen kann.

• Die Bereitstellungsregion: Es ist wichtig, die Regionen anzugeben, in denen die Workload bereitgestellt wird. Das Plattformteam kann diese Informationen verwenden, um sicherzustellen, dass die virtuellen Speichen- und Hub-Netzwerke in derselben Region bereitgestellt werden. Netzwerke in unterschiedlichen Regionen können zu Latenzproblemen führen, da der Datenverkehr regionale Grenzen überschreitet und auch zusätzliche Bandbreitenkosten verursachen kann.

• Die Arbeitsauslastungsmerkmale und Designoptionen: Kommunizieren Sie Ihre Designentscheidungen, Komponenten und Merkmale an Ihr Plattformteam. Wenn Sie beispielsweise erwarten, dass Ihre Workload eine hohe Anzahl gleichzeitiger Verbindungen mit dem Internet (Chatty) generiert, sollte das Plattformteam sicherstellen, dass genügend SNAT-Ports (Source Network Address Translation) verfügbar sind, um die Erschöpfung zu verhindern. Sie können der zentralen Firewall öffentliche IP-Adressen hinzufügen, um den SNAT-Portpool zu erweitern oder eine Azure NAT Gateway anzufügen, um die SNAT-Kapazität weiter zu skalieren.

  Wenn Sie hingegen erwarten, dass Ihre Arbeitsauslastung minimale Netzwerkdatenverkehre (Hintergrundgeräusche) generiert, sollte das Plattformteam Ressourcen effizient in der gesamten Organisation verwenden.

  Das Plattformteam muss alle Abhängigkeiten klar verstehen. Ihre Workload benötigt z. B. Zugriff auf eine Datenbank, die ein anderes Team besitzt, oder Ihre Workload hat möglicherweise Verkehr über verschiedene Standorte hinweg. Verfügt Ihre Workload über Abhängigkeiten außerhalb von Azure? Solche Informationen sind für das Plattformteam wichtig.

• Die Firewallkonfiguration: Das Plattformteam muss den Datenverkehr kennen, der das Speichennetzwerk verlässt und in das Hubnetzwerk getunnelt wird. Die Firewall im Hub kann diesen Datenverkehr nicht blockieren.

  Wenn Ihre Workload beispielsweise auf Windows Updates zugreifen muss, um patched zu bleiben, sollte eine Firewall diese Updates nicht blockieren. Ebenso sollte eine Firewall diesen Datenverkehr nicht blockieren, wenn Monitor-Agents auf bestimmte Endpunkte zugreifen, da dies die Überwachung von Daten für Ihre Workload stören kann. Die Anwendung erfordert möglicherweise Zugriff auf Endpunkte von Drittanbietern. Verwenden Sie unabhängig davon eine zentralisierte Firewall, um zwischen erwartetem und unwarrantem Datenverkehr zu unterscheiden.

• Operatorzugriff: Wenn Microsoft Entra ID Sicherheitsgruppen vorhanden sind, die operatoren für den Zugriff auf die virtuellen Computer über Azure Bastion verwenden, informieren Sie das Plattformteam. Azure Bastion ist in der Regel eine zentrale Ressource. Es ist wichtig, sicherzustellen, dass die Sicherheitsgruppen und die VMs das sichere Protokoll unterstützen.

  Darüber hinaus informieren Sie das Plattformteam über die IP-Bereiche, die die VMs enthalten. Diese Informationen sind für die Konfiguration der NSGs um Azure Bastion im Hubnetzwerk erforderlich.

• Die öffentlichen IP-Adressen: Informieren Sie das Plattformteam über das eingehende Verkehrsprofil, einschließlich aller erwarteten öffentlichen IP-Adressen. In dieser Architektur wird nur vom Internet stammender Datenverkehr auf die öffentliche IP des Anwendungsgateways zielgerichtet. Das Plattformteam sollte das Workload-Team informieren, wenn diese IPs unter einem Azure DDoS-Schutzplan liegen oder wenn dies die Verantwortung des Workloadteams ist.

  In dieser Architektur gibt es eine weitere öffentliche IP für den betriebsfähigen Zugriff über Azure Bastion. Das Plattformteam besitzt diese öffentliche IP und ist in einem Dienst registriert, z. B. DDoS Protection, der vom Plattformteam ebenfalls verwaltet wird.

Wichtig

Wir empfehlen einen Abonnement-Verkaufsworkstream für das Plattformteam, das eine Reihe von Fragen umfasst, die zum Erfassen von Informationen aus dem Workloadteam konzipiert sind. Diese Fragen können von einer Organisation zu einer anderen variieren, aber die Absicht besteht darin, die Anforderungen für die Implementierung von Abonnements zu erfassen. Weitere Informationen finden Sie unter Abonnementverkauf.

VM-Design-Optionen

Die VM-SKU- und Datenträgerauswahl bleiben mit der Basisarchitekturidentisch.

Eine Organisation stellt möglicherweise Complianceanforderungen für das Workloadteam fest, das die Verwendung bestimmter VM-Images vorschreibt. Aufgrund dieser Anforderungen kann das Plattformteam eine Reihe standardisierter Bilder verwalten, die häufig als goldene Bilderbezeichnet werden, die für die gesamte Organisation erstellt werden.

Das Plattformteam kann ein verwaltetes Angebot wie Azure Compute Gallery oder ein privates Repository verwenden, um genehmigte Betriebssystemimages oder Workloadartefakte zu speichern. Wenn Sie ein Betriebssystemimage für VMs auswählen, wenden Sie sich an Ihr Plattformteam zu Bildquellen, Aktualisierungshäufigkeit und Nutzungserwartungen. Stellen Sie außerdem sicher, dass Bilder die erforderlichen geschäftlichen Anforderungen erfüllen können, die die Workload erfüllt.

Wichtig

Für das Plattformteam: Wenn Sie Compute Gallery verwenden, erfordert die Workload eine Netzwerksichtbarkeit für den privaten Katalog. Arbeiten Sie mit dem Workloadteam zusammen, um eine sichere Verbindung herzustellen.

Vernetzung

In der Baselinearchitektur wird die Workload in einem einzigen virtuellen Netzwerk bereitgestellt. Das Workloadteam verwaltet das virtuelle Netzwerk.

In dieser Architektur bestimmt das Plattformteam die Netzwerktopologie. Die Hub-Spoke-Topologie wird in dieser Architektur angenommen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

• Hub-Virtualnetzwerk: ein regionaler Hub enthält zentrale Dienste, die mit Workloadressourcen in derselben Region kommunizieren. Weitere Informationen finden Sie unter Plattform-Teamressourcen. Wir empfehlen, den Hub im Konnektivitätsabonnementzu platzieren.

• Speichen-virtuelles Netzwerk: In dieser Architektur ist das einzelne virtuelle Netzwerk aus der Basisarchitektur das Speichennetzwerk. Es ist an das Hub-Netzwerk angeschlossen, das die zentralen Dienste enthält. Das Plattformteam besitzt und verwaltet dieses Speichennetzwerk. Dieses Netzwerk enthält die Belastungsressourcen. Das Workloadteam besitzt die Ressourcen in diesem Netzwerk, einschließlich seiner Subnetze.

Stellen Sie sicher, dass Sie die Workloadanforderungen an das Plattformteam übermitteln und diese regelmäßig überprüfen.

Wichtig

Für das Plattformteam: Es sei denn, es wird ausdrücklich von der Workload benötigt, peeren Sie das Spoke-Netzwerk nicht direkt mit einem anderen Spoke-virtuellen Netzwerk. Diese Übung schützt die Segmentierungsziele der Workload. Ihr Team sollte alle transitiven virtuellen Netzwerkverbindungen erleichtern.

Virtuelle Netzwerk-Subnetze

Im virtuellen Speichennetzwerk erstellt und weist das Workloadteam die Subnetze zu. Das Platzieren von Steuerelementen zum Einschränken des Datenverkehrs in und aus den Subnetzen trägt dazu bei, Segmentierung bereitzustellen. Diese Architektur verwendet dieselbe Subnetztopologie wie die Basisarchitektur, die dedizierte Subnetze für Anwendungsgateway, Front-End-VMs, das Lastenausgleichsmodul, Back-End-VMs und private Endpunkte enthält.

Wenn Sie Ihre Workload in einer Anwendungslandezone bereitstellen, müssen Sie dennoch Netzwerksteuerungen implementieren. Organisationen können Einschränkungen für den Schutz vor Datenexfiltration und die Sichtbarkeit des zentralen Sicherheitsbetriebszentrums (SOC) und des IT-Netzwerkteams festlegen.

Mit diesem Ansatz kann das Plattformteam die gesamte Organisationsausgaben optimieren, indem zentrale Dienste verwendet werden, anstatt redundante Sicherheitskontrollen für jede Arbeitsauslastung in der gesamten Organisation bereitzustellen. In dieser Architektur ist Azure Firewall ein Beispiel für einen zentralen Dienst. Es ist nicht kosteneffizient oder praktisch für jedes Workloadteam, seine eigene Firewallinstanz zu verwalten. Wir empfehlen einen zentralen Ansatz für die Firewallverwaltung.

Eingehender Datenverkehr

Der eingehende Datenverkehrsfluss bleibt mit der Basisarchitektur identisch.

Der Workload-Besitzer ist für sämtliche Ressourcen verantwortlich, die mit dem Eingang von öffentlichem Internetverkehr in den Workload verbunden sind. In dieser Architektur werden beispielsweise Das Anwendungsgateway und seine öffentliche IP-Adresse im Speichennetzwerk und nicht im Hubnetzwerk platziert. Einige Organisationen können Ressourcen mit eingehendem Datenverkehr in einem Verbindungsabonnement platzieren, indem eine zentralisierte entmilitarisierte Zone (DMZ)-Implementierung verwendet wird. Die Integration mit dieser spezifischen Topologie liegt außerhalb des Gültigkeitsbereichs für diesen Artikel.

Ausgehender Datenverkehr

In der Basisarchitektur legt die Skalierung des virtuellen Computers den Zugriff auf das öffentliche Internet über Azure Load Balancer fest, aber dieser Datenverkehr ist nicht eingeschränkt.

Dieses Design unterscheidet sich in dieser Architektur. Der gesamte Datenverkehr, der das Speichen-Virtual-Netzwerk verlässt, wird über eine Egress-Firewall durch das Peered Hub-Netzwerk geleitet. ** Eine Route ist mit allen möglichen Subnetzen im Spoke-Netzwerk verbunden, die den gesamten Datenverkehr von IPs, die nicht im lokalen virtuellen Netzwerk (0.0.0.0/0) vorhanden sind, zur Azure-Firewall des Hubs leitet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Arbeitslastkommunikation mit dem privaten Endpunkt für den Zugriff auf Key Vault bleibt identisch mit der Baseline-Architektur. Dieser Pfad wird aus dem vorherigen Diagramm aus Platzgründen weggelassen.

Das Workload-Team muss alle erforderlichen ausgehenden Datenverkehrsflüsse für die Infrastruktur und den Workload-Betrieb identifizieren, dokumentieren und kommunizieren. Das Plattformteam lässt den erforderlichen Datenverkehr zu, und der gesamte nicht kommunizierte ausgehende Datenverkehr wird wahrscheinlich blockiert.

Die Steuerung des Ausgangsverkehrs ist mehr als nur sicherzustellen, dass der erwartete Datenverkehr zulässig ist. Es geht auch darum, sicherzustellen, dass nur erwarteter Datenverkehr erlaubt wird. Nicht kommunizierter ausgehender Datenverkehr wird wahrscheinlich standardmäßig verweigert, aber es liegt im besten Sicherheitsinteresse der Workload, sicherzustellen, dass der Datenverkehr ordnungsgemäß weitergeleitet wird.

Tipp

Ermutigen Sie das Plattformteam, IP-Gruppen in Azure Firewall zu verwenden. Diese Vorgehensweise stellt sicher, dass die Anforderungen für den ausgehenden Datenverkehr Ihrer Workload genau durch eine enge Eingrenzung nur auf die Quellsubnetze dargestellt werden. Eine Regel, mit der Workload-VMs api.example.org erreichen können, bedeutet beispielsweise nicht unbedingt, dass die Unterstützung von Ressourcen innerhalb desselben virtuellen Netzwerks auf denselben Endpunkt zugreifen kann. Diese Ebene der granularen Kontrolle kann den Sicherheitsstatus Ihres Netzwerks verbessern.

Kommunizieren Sie alle spezifischen Anforderungen an den ausgehenden Datenverkehr an das Plattformteam. Die Firewall wendet die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) auf ausgehende Datenströme an, ersetzt die Quell-IP der Arbeitslast durch eine ihrer öffentlichen IP-Adressen und die Anzahl der angefügten IP-Adressen begrenzt das SNAT-Port-Kontingent. Wenn Ihre Workload zahlreiche gleichzeitige ausgehende Verbindungen herstellt, informieren Sie das Plattformteam, damit sie die SNAT-Portausschöpfung verringern können, indem sie eine Azure NAT Gateway anfügen oder weitere öffentliche IPs in der regionalen Firewall hinzufügen. Teilen Sie außerdem den öffentlichen IP-Satz der Firewall mit nachgeschalteten Partnern, sodass Zulassungslisten den gesamten Bereich möglicher Quell-IPs abdecken.

Ihre Organisation hat möglicherweise Anforderungen, die die Verwendung von Architekturmustern einschränken, die öffentliche IPs, die der Arbeitslast gehören, für den Datenabfluss nutzen. In diesem Fall können Sie Azure Policy verwenden, um öffentliche IPs auf VM-Netzwerkschnittstellenkarten (NICs) und anderen öffentlichen IPs zu verweigern, die nicht ihre bekannten Eingangspunkte sind.

Privates DNS Zonen

Architekturen, die private Endpunkte verwenden, benötigen private DNS-Zonen, um mit dem DNS-Anbieter zu arbeiten. Das Workloadteam muss über ein klares Verständnis der Anforderungen und verwaltung privater DNS-Zonen im Abonnement verfügen, das das Plattformteam bereitstellt. Privates DNS Zonen werden in der Regel in großem Umfang mit DINE-Richtlinien verwaltet, wodurch Azure Firewall als zuverlässiger DNS-Proxy funktionieren und vollqualifizierte Domänennamen(FQDN)-Netzwerkregeln unterstützen können.

In dieser Architektur stellt das Plattformteam die zuverlässige private DNS-Auflösung für Private Link-Endpunkte sicher. Arbeiten Sie mit Ihrem Plattformteam zusammen, um ihre Erwartungen zu verstehen.

Konnektivitätstests

Für VM-basierte Architekturen gibt es mehrere Testtools, mit denen Sie Netzwerkleitungs-, Routing- und DNS-Probleme ermitteln können. Sie können herkömmliche Tools zur Problembehandlung wie netstat, nslookupoder tcpingverwenden. Darüber hinaus können Sie die DHCP-Einstellungen (Dynamic Host Configuration Protocol) und DNS-Einstellungen des Netzwerkadapters untersuchen. Wenn NICs vorhanden sind, verfügen Sie über weitere Problembehandlungsfunktionen, mit denen Sie Konnektivitätsprüfungen mithilfe von Azure Network Watcher durchführen können.

Operatorzugriff

Wie die baseline-Architektur wird der betriebsbereite Zugriff über Azure Bastion in dieser Architektur unterstützt.

Die Basisarchitektur stellt jedoch Azure Bastion als Teil der Workload bereit. Für eine typische Organisation, die Azure Landing Zones einsetzt, wird Azure Bastion als zentrale Ressource für jede Region bereitgestellt. Das Plattformteam besitzt und verwaltet Azure Bastion, und alle Workloads in der Organisation teilen sie. Um diesen Anwendungsfall in dieser Architektur zu veranschaulichen, befindet sich Azure Bastion im Hubnetzwerk im Konnektivitätsabonnement.

Operatoridentität

Diese Architektur verwendet dieselbe Authentifizierungserweiterung wie die Basisarchitektur.

Anmerkung

Wenn sich Administratoren bei einem virtuellen Computer anmelden, müssen sie ihre Unternehmensidentitäten innerhalb ihres Microsoft Entra ID Mandanten verwenden und keine Serviceprinzipale über Funktionen hinweg freigeben.

Beginnen Sie immer mit dem Prinzip der minimalen Rechte und dem differenzierten Zugriff auf eine Aufgabe, anstelle eines dauerhaften Zugriffs. Nutzen Sie die Just-in-Time-Unterstützung (JIT), die das Plattformteam verwaltet.

Patchcompliance- und Betriebssystemupgrades

Die Basisarchitektur beschreibt einen autonomen Ansatz für Patching und Upgrades. Wenn die Workload in Landezonen integriert ist, kann sich dieser Ansatz ändern. Das Plattformteam könnte die Patchvorgänge vorgeben, sodass alle Workloads den organisatorischen Anforderungen entsprechen.

Stellen Sie sicher, dass der Patchvorgang alle Komponenten enthält, die Sie der Architektur hinzufügen. Wenn Sie beispielsweise Build-Agent-VMs hinzufügen, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu automatisieren, müssen diese virtuellen Computer die Plattformanforderungen erfüllen.

Überwachung

Die Azure Landingzone-Plattform bietet gemeinsam genutzte Überwachungsressourcen im Rahmen des Verwaltungsabonnements. Es wird jedoch empfohlen, Ihre eigenen Überwachungsressourcen einzurichten, um die Verantwortung für die Arbeitslast wahrzunehmen. Dieser Ansatz ist mit der Basisarchitekturkonsistent.

Das Arbeitsauslastungsteam stellt die Überwachungsressourcen bereit, die Folgendes umfassen:

• Application Insights als APM-Dienst (Application Performance Monitoring) für das Workloadteam.

• Der Log Analytics-Arbeitsbereich als einheitliche Ablage für alle Protokolle und Metriken, die aus von Arbeitslasten in Azure verwalteten Ressourcen und der Anwendungscode gesammelt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ähnlich wie der Basisplan werden alle Ressourcen so konfiguriert, dass Azure-Diagnose Protokolle an den Log Analytics Arbeitsbereich gesendet werden, den das Workloadteam als Teil der Infrastruktur als Codebereitstellung (IaC) der Ressourcen bereitgestellt. Möglicherweise müssen Sie auch Protokolle an einen zentralen Log Analytics Arbeitsbereich senden. In Azure Landing Zones befindet sich dieser Arbeitsbereich im Verwaltungsabonnement.

Das Plattformteam verfügt möglicherweise auch über DINE-Richtlinien, die sie zum Konfigurieren der Diagnose verwenden können, um Protokolle an ihre zentralisierten Verwaltungsabonnements zu senden. Es ist wichtig, sicherzustellen, dass Ihre Implementierung die zusätzlichen Protokollflüsse nicht einschränkt.

Daten aus mehreren Senken korrelieren

Die Protokolle und Metriken der Arbeitslast sowie ihre Infrastruktur-Komponenten werden im Log-Analytics-Arbeitsbereich der Arbeitslast gespeichert. Protokolle und Metriken, die zentrale Dienste wie Azure Firewall, Microsoft Entra ID und Azure Bastion, generieren, werden jedoch in einem zentralen Log Analytics Arbeitsbereich gespeichert. Das Zusammenführen und Abgleichen von Daten von mehreren Datenquellen kann eine komplexe Aufgabe sein.

Korrelierte Daten werden häufig während der Reaktion auf Vorfälle verwendet. Wenn es ein Problem mit der Korrelation von Daten aus mehreren Senken gibt, stellen Sie sicher, dass das Triage-Runbook für diese Architektur das Problem anspricht und Ansprechpartner enthält, falls das Problem über die Ressourcen der Arbeitslast hinausgeht. Workloadadministratoren benötigen möglicherweise Unterstützung von Plattformadministratoren, um Protokolleinträge aus Unternehmensnetzwerken, Sicherheitsdiensten oder anderen Plattformdiensten zu korrelieren.

Wichtig

Für das Plattformteam: Wo möglich, gewähren Sie Azure Role-based Access Control (Azure RBAC), um Protokollsenken für relevante Plattformressourcen abzufragen und zu lesen. Aktivieren Sie Firewallprotokolle für Netzwerk- und Anwendungsregelauswertungen und DNS-Proxy, da die Anwendungsteams diese Informationen während der Problembehandlungsaufgaben verwenden können.

Azure Policy

Das Plattformteam wendet wahrscheinlich Richtlinien an, die sich auf die Workloadbereitstellung auswirken. Sie wenden häufig DINE-Richtlinien an, um automatisierte Bereitstellungen in einem Landing Zone-Abonnement für Anwendungen zu verarbeiten. DINE-Richtlinien können Arbeitsauslastungsressourcen ändern oder Ihrer Bereitstellung Ressourcen hinzufügen, was zu einer Diskrepanz zwischen den Ressourcen führen kann, die deklarativ über die Workloadvorlage bereitgestellt werden, und den Ressourcen, die die Verarbeitungsanforderungen tatsächlich verwenden. Eine typische Lösung besteht darin, diese Änderungen mit imperativen Ansätzen zu beheben, die nicht ideal sind.

Um diese Diskrepanz zu vermeiden, sollten Sie die plattforminitiierten Änderungen in Ihre IaC-Vorlagen vorab integrieren und testen. Wenn das Plattformteam Azure Richtlinien verwendet, die mit den Anforderungen der Anwendung in Konflikt geraten, können Sie eine Lösung mit dem Plattformteam aushandeln.

Wichtig

Azure-Zielzonen verwenden verschiedene DINE-Richtlinien, zum Beispiel eine Richtlinie, die private Endpunkte in großem Umfang verwaltet. Diese Richtlinie überwacht die Bereitstellung privater Endpunkte und aktualisiert Azure DNS im Hubnetzwerk, das Teil eines plattformverwalteten Abonnements ist. Das Workloadteam verfügt nicht über die Berechtigung zum Ändern der Richtlinie im Hub, und das Plattformteam überwacht nicht die Bereitstellungen der Workloadteams, um DNS automatisch zu aktualisieren. DINE-Richtlinien werden verwendet, um diese Verbindung bereitzustellen.

Andere Richtlinien können sich auf diese Architektur auswirken, einschließlich Richtlinien, die:

• Fordern Sie eine Windows VM an, um einer Active Directory Domäne beizutreten. Diese Richtlinie stellt sicher, dass die JoinADDomainExtension VM-Erweiterung installiert und konfiguriert ist. Weitere Informationen finden Sie unter Enforce Windows VMs, um einer Active Directory Domäne beizutreten.
• Die IP-Weiterleitung auf Netzwerkschnittstellen verbieten.

Verwalten von Änderungen im Laufe der Zeit

Von der Plattform bereitgestellte Dienste und Vorgänge werden als externe Abhängigkeiten in dieser Architektur betrachtet. Das Plattformteam wendet weiterhin Änderungen an, integriert Benutzer und wendet Kostenkontrollen an. Das Plattformteam, das die Organisation bedient, priorisiert möglicherweise nicht einzelne Workloads. Änderungen an diesen Abhängigkeiten, seien es Änderungen an goldenen Images, Firewalländerungen, automatisierte Patchvorgänge oder Regeländerungen, können sich auf mehrere Workloads auswirken.

Daher müssen Arbeitsauslastungs- und Plattformteams effizient und zeitnah kommunizieren, um alle externen Abhängigkeiten zu verwalten. Es ist wichtig, Änderungen zu testen, damit sie keine negativen Auswirkungen auf Workloads haben.

Plattformänderungen, die sich auf die Workload auswirken

In dieser Architektur verwaltet das Plattformteam die folgenden Ressourcen. Änderungen an diesen Ressourcen können sich möglicherweise auf die Zuverlässigkeit, Sicherheit, Vorgänge und Leistungsziele der Workload auswirken. Es ist wichtig, diese Änderungen zu bewerten, bevor das Plattformteam sie in Kraft setzt, um zu bestimmen, wie sie sich auf die Arbeitsauslastung auswirken.

• Azure policies: Änderungen an Azure Richtlinien können sich auf Arbeitsauslastungsressourcen und deren Abhängigkeiten auswirken. Beispielsweise kann es direkte Richtlinienänderungen oder die Verschiebung der Landing Zone in eine neue Managementgruppen-Hierarchie geben. Diese Änderungen können unbemerkt bleiben, bis eine neue Bereitstellung vorhanden ist, daher ist es wichtig, sie gründlich zu testen.

• Firewallregeln: Änderungen an Firewallregeln können sich auf das virtuelle Netzwerk oder die Regeln der Workload auswirken, die allgemein für den gesamten Datenverkehr gelten. Diese Änderungen können zu blockierten Datenverkehr und sogar automatischen Prozessfehlern führen, z. B. fehlgeschlagene Anwendung von Betriebssystempatches. Diese potenziellen Probleme gelten sowohl für die ausgehende Azure-Firewall als auch für die vom Azure Virtual Network Manager angewendeten NSG-Regeln.

• Freigegebene Ressourcen: Änderungen an der SKU oder features für freigegebene Ressourcen können sich auf die Arbeitsauslastung auswirken.

• Routing im Hubnetzwerk: Änderungen der transitiven Art des Routings im Hub können sich potenziell auf die Arbeitsauslastungsfunktionalität auswirken, wenn eine Workload vom Routing an andere virtuelle Netzwerke abhängt.

• Azure Bastion host: Änderungen an der Azure Bastion Hostverfügbarkeit oder -konfiguration können sich auf Workloadvorgänge auswirken. Stellen Sie sicher, dass Änderungen des Sprungfeldzugriffsmusters über effektive Routine-, Ad-hoc- und Notfallzugriffe verfügen.

• Änderungen des Besitzes: Kommunizieren Sie alle Änderungen des Besitzes und der Kontaktpunkte an das Workloadteam, da sie sich auf die Verwaltungs- und Supportanfragen der Workload auswirken können.

Workloadänderungen, die sich auf die Plattform auswirken

Die folgenden Beispiele sind Workloadänderungen in dieser Architektur, die Sie mit dem Plattformteam kommunizieren sollten. Es ist wichtig, dass das Plattformteam die Zuverlässigkeit, Sicherheit, Vorgänge und Leistungsziele des Plattformdiensts anhand der änderungen des neuen Workloadteams überprüft, bevor sie wirksam werden.

• Netzwerkausfluss: Überwachen Sie jede signifikante Zunahme des Netzwerkausflusses, um zu verhindern, dass die Arbeitslast zu einem störenden Nachbarn auf Netzwerkgeräten wird. Dieses Problem kann sich möglicherweise auf die Leistungs- oder Zuverlässigkeitsziele anderer Workloads auswirken.

• öffentlichen Zugriff: Änderungen des öffentlichen Zugriffs auf Arbeitsauslastungskomponenten erfordern möglicherweise weitere Tests. Das Plattformteam kann die Arbeitsauslastung in eine andere Verwaltungsgruppe verschieben.

• Bewertung der unternehmenskritischen Leistung: Wenn es Änderungen an den Service-Level-Vereinbarungen (SLAs) des Workloads gibt, benötigen Sie möglicherweise einen neuen Ansatz für die Zusammenarbeit zwischen Plattform- und Workload-Teams.

• Änderungen des Besitzes: Kommunizieren Sie Änderungen des Eigentums und Kontaktpunkte an das Plattformteam.

Änderungen der Geschäftsanforderungen für Arbeitsauslastungen

Um die Ziele auf Serviceebene (SLOs) der Workload aufrechtzuerhalten, muss das Plattformteam möglicherweise an Änderungen der Workloadarchitektur beteiligt sein. Diese Änderungen erfordern möglicherweise die Änderungsverwaltung aus dem Plattformteam oder die Überprüfung, dass vorhandene Governance die geänderten Anforderungen unterstützt.

Kommunizieren Sie z. B. Änderungen an einem zuvor nicht zulässigen Ausgangsfluss, damit das Plattformteam diesen Fluss in der Firewall, Virtual Network Manager oder anderen Komponenten hinzufügen kann, um den erforderlichen Datenverkehr zu unterstützen. Wenn ein zuvor zulässiger Ausgang nicht mehr benötigt wird, sollte das Plattformteam diesen Fluss blockieren, um die Sicherheit der Workload aufrechtzuerhalten. Kommunizieren Sie außerdem Änderungen beim Routing an andere virtuelle Netzwerke oder standortübergreifende Endpunkte oder Änderungen an den Architekturkomponenten. Jede Ressource unterliegt Richtlinien und möglicherweise der Egress-Firewall-Kontrolle.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected Frameworks, bei dem es sich um eine Reihe von Leitsätzen handelt, die verwendet werden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Diese Architektur entspricht den Zuverlässigkeitsgarantien in der Basisarchitektur.

Zuverlässigkeitsziele

Der maximal mögliche zusammengesetzte SLO ist niedriger als der Basis zusammengesetzte SLO aufgrund von Komponenten wie der Ausgangsnetzwerksteuerung. Diese Komponenten, die in Landungszonenumgebungen üblich sind, sind für diese Architektur nicht einzigartig. Der SLO wird ähnlich reduziert, wenn das Workloadteam diese Azure Dienste direkt steuert.

Trotz eines geringeren maximalen SLO-Werts ist der wichtigste Zuverlässigkeitsaspekt die Aufteilung von Arbeitsauslastungskomponenten in funktionalen Teams. Mit dieser Methode profitiert das Workload-Team von einem spezialisierten Team, das sich auf den Betrieb kritischer Infrastrukturen konzentriert, die sowohl diese als auch andere Workloads nutzen.

Weitere Informationen finden Sie unter Empfehlungen zum Definieren von Zuverlässigkeitszielen.

Kritische Abhängigkeiten

Zeigen Sie alle Funktionen an, die von der Workload in der Plattform und der Anwendungslandungszone als Abhängigkeiten ausgeführt werden. Vorfallreaktionspläne erfordern, dass das Workload-Team über die Methode und Art der Kontaktaufnahme für diese Abhängigkeiten Bescheid weiß. Schließen Sie diese Abhängigkeiten auch in die Fehlermodusanalyse (Failure Mode Analysis, FMA) der Workload ein.

Berücksichtigen Sie für diese Architektur die folgenden Abhängigkeiten:

• Ausgangsfirewall: Die zentrale Ausgangsfirewall, die von mehreren Workloads gemeinsam genutzt wird, erfährt Änderungen, die nicht mit der Workload in Zusammenhang stehen.

• Netzwerkportausschöpfung: Spitzen bei der Nutzung von allen Workloads, die das Netzwerkgerät gemeinsam nutzen, können zu einer Netzwerksättigung oder Portausschöpfung in der Ausgangsfirewall führen.

• DINE-Richtlinien: DINE-Richtlinien für Azure DNS private DNS-Zonen (oder andere plattformbasierte Abhängigkeiten) sind Best-Effort, ohne Ausführungs-SLA. Eine Verzögerung bei der DNS-Konfiguration kann zu Verzögerungen bei der Bereitschaft einer Anwendung zur Verarbeitung von Datenverkehr führen.

• Gruppenrichtlinien für die Verwaltung: Konsistente Richtlinien zwischen Umgebungen sind der Schlüssel zur Zuverlässigkeit. Stellen Sie sicher, dass Vorproduktionsumgebungen mit Produktionsumgebungen vergleichbar sind, um genaue Tests bereitzustellen und umgebungsspezifische Abweichungen zu verhindern, die eine Bereitstellung oder Skalierung blockieren können. Weitere Informationen finden Sie unter Verwaltung von Anwendungsentwicklungsumgebungen in Azure-Landing-Zonen.

Viele dieser Überlegungen könnten ohne Azure Landing Zones existieren, aber die Workload- und Plattformteams müssen zusammenarbeiten, um diese Probleme zu lösen und sicherzustellen, dass die Anforderungen erfüllt werden.

Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermodus- und Wirkungsanalyse.

Sicherheit

Die Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Die Sicherheitsüberlegungen für diese Architektur werden von der Basisarchitektur übernommen. Die Empfehlungen in den folgenden Abschnitten basieren auf der Prüfliste für die Sicherheitsentwurfsüberprüfung im Well-Architected Framework.

Netzwerksteuerungen

Konfigurieren Sie Netzwerksteuerelemente ordnungsgemäß, um sicherzustellen, dass Ihre Workload sicher ist.

Eingehender Datenverkehr

Sie können Ihre Workload von anderen Workload-Komponenten innerhalb Ihrer Organisation über NSGs in Ihren Subnetzen oder aufgrund der nichttransitiven Eigenschaften oder Kontrollfunktionen im regionalen Hub abschotten. Erstellen Sie umfassende NSGs, die nur die eingehenden Netzwerkanforderungen Ihrer Anwendung und ihrer Infrastruktur zulassen. Es wird empfohlen, dass Sie sich nicht ausschließlich auf die nichttransitive Art des Hubnetzwerks für die Sicherheit verlassen.

Das Plattformteam implementiert wahrscheinlich Azure-Richtlinien, um sicherzustellen, dass Application Gateway die Web Application Firewall auf Deny-Modus eingestellt hat, um die Anzahl der öffentlichen IPs, die für Ihr Abonnement verfügbar sind, zu begrenzen, und andere Prüfungen durchzuführen. Zusätzlich zu diesen Richtlinien sollte das Workload-Team die Verantwortung für die Bereitstellung workload-zentrierter Richtlinien tragen, die die eingehende Sicherheitslage verstärken.

Die folgende Tabelle enthält Beispiele für Einlasskontrollen innerhalb dieser Architektur.

Quelle	Zweck	Workload-Steuerung	Plattformsteuerung
Internet	Benutzerverkehrsflüsse	Leitet alle Anforderungen über eine NSG, eine Web Application Firewall sowie Routingregeln, bevor der öffentliche Datenverkehr zu dem privaten Datenverkehr wird, der in die Front-End-VMs eintritt.	Nichts
Azure Bastion	Operatorzugriff auf virtuelle Computer	NSG auf VM-Subnetzen, die allen Datenverkehr zu Remotezugriffsports blockieren, außer wenn er aus dem von der Plattform festgelegten Azure Bastion Subnetz stammt.	Nichts
Andere Speichen	Nichts	Blockiert über NSG-Regeln	Nichttransitives Routing oder Azure Firewall Regeln im Falle eines Azure Virtual WAN gesicherten Hubs

Ausgehender Datenverkehr

Wenden Sie NSG-Regeln an, die die erforderlichen Anforderungen an die ausgehende Konnektivität Ihrer Lösung ausdrücken und alles andere verweigern. Verlassen Sie sich nicht nur auf die Hubnetzwerksteuerelemente. Als Workload-Operator haben Sie die Verantwortung, unerwünschten ausgehenden Netzwerkverkehr so nah an der Quelle wie möglich zu stoppen.

Beachten Sie, dass während Sie ihr Subnetz innerhalb des virtuellen Netzwerks besitzen, das Plattformteam wahrscheinlich Firewallregeln erstellt hat, um ihre erfassten Anforderungen im Rahmen Ihres Abonnementverkaufsprozesses speziell darzustellen. Stellen Sie sicher, dass Änderungen an Subnetzen und Ressourcenplatzierungen während der Lebensdauer Ihrer Architektur weiterhin mit Ihrer ursprünglichen Anforderung kompatibel sind. Sie können auch mit Ihrem Netzwerkteam zusammenarbeiten, um die Kontinuität der Zugriffssteuerung für den geringsten Zugriff sicherzustellen.

Die folgende Tabelle zeigt Beispiele für Egress in dieser Architektur.

Endpunkt	Zweck	Workload-Steuerung (NSG)	Plattformsteuerung (Hub)
ntp.ubuntu.com	Das Network Time Protocol (NTP) für linux-VMs	UDP/123 für das Internet im Front-End-VM-Subnetz (die Ausgangsfirewall schränkt diese breite Öffnung ein)	Firewall-Netzwerkregelberechtigung für dasselbe wie die Workloadsteuerung
Windows Update Endpunkte	Windows Update-Funktionen von den Microsoft-Servern	TCP/443 und TCP/80 zum Internet im Subnetz der Back-End-VMs (die Ausgangsfirewall beschränkt diese breite Öffnung)	Firewall-Erlaubnisregel mit FQDN-Tag von WindowsUpdate
Überwachen von Agentendpunkten	Erforderlicher Datenverkehr für die Monitor-Erweiterung auf virtuellen Computern	TCP/443- zum Internet in beiden VM-Subnetzen (die Ausgangsfirewall beschränkt diese breite Öffnung)	Erforderliche Anwendungsregelerlaubnisse für die Firewall für alle spezifischen vollqualifizierten Domänennamen (FQDNs) auf TCP/443
nginx.org	So installieren Sie Nginx (eine Beispielanwendungskomponente) direkt vom Anbieter	TCP/443- zum Internet im Front-End-VM-Subnetz (die Ausgangsfirewall beschränkt diese breite Öffnung)	Erforderliche Firewallanwendungsregelzuteilung für nginx.org auf TCP/443-
Key Vault	So importieren Sie TLS-Zertifikate in Anwendungsgateway und VMs	- TCP/443 zu einem privaten Endpunktsubnetz von beiden VM-Subnetzen zu einem privaten Endpunktsubnetz - TCP/443 zu einem privaten Endpunktsubnetz aus einem Application Gateway-Subnetz - TCP/443 von virtuellen Computern, die mit einer erforderlichen ASG-Bezeichnung (Application Security Group) und einem Application Gateway-Subnetz gekennzeichnet sind	Nichts

DDoS-Schutz

Bestimmen Sie, wer für die Anwendung des DDoS-Schutzplans verantwortlich ist, der alle öffentlichen IPs Ihrer Lösung abdeckt. Das Plattformteam kann IP-Schutzpläne verwenden oder sogar Azure Policy verwenden, um Virtuelle Netzwerkschutzpläne zu erzwingen. Diese Architektur sollte über eine Abdeckung verfügen, da sie eine öffentliche IP für den Ausgang aus dem Internet umfasst.

Weitere Informationen finden Sie unter Empfehlungen für Netzwerk und Konnektivität.

Geheime Verwaltung

Für die geheime Verwaltung folgt diese Architektur der Basisarchitektur.

Als Workload-Team behalten Sie Ihre Geheimnisse in der Key Vault-Instanz bei. Stellen Sie nach Bedarf weitere Instanzen bereit, um Ihre Anwendungs- und Infrastrukturvorgänge zu unterstützen.

Weitere Informationen finden Sie unter Empfehlungen zum Schutz geheimer Anwendungsschlüssel.

Kostenoptimierung

Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Für die Workloadressourcen gelten auch die Kostenoptimierungsstrategien in der Basisarchitektur für diese Architektur.

Diese Architektur profitiert erheblich von Azure Plattformressourcen für die Zielzone. Selbst wenn Sie diese Ressourcen über ein Chargebackmodell verwenden, sind die zusätzlichen Sicherheits- und standortübergreifenden Verbindungen kostengünstiger als die selbstverwaltende Verwaltung dieser Ressourcen.

Das Plattformteam verwaltet die folgenden Ressourcen in dieser Architektur. Diese Ressourcen sind häufig verbrauchsbasiert (Chargeback) oder potenziell kostenlos für das Workloadteam.

• Azure Firewall
• Sicherheitsinformationen und Ereignisverwaltung (SIEM)
• Azure Bastion-Hosts
• Standortübergreifende Konnektivität, z. B. ExpressRoute

Nutzen Sie andere zentralisierte Angebote Ihres Plattformteams, um diese Vorteile auf Ihre Workload zu erweitern, ohne dessen SLO-, Wiederherstellungszeitziel (RTO) oder Wiederherstellungspunktziel (RPO) zu beeinträchtigen.

Weitere Informationen finden Sie unter Empfehlungen zum Sammeln und Überprüfen von Kostendaten.

Implementieren dieses Szenarios

Eine Bereitstellung für diese Referenzarchitektur ist auf GitHub verfügbar.

Implementation: VM-Basisarchitektur in einer Azure Zielzone

Nächster Schritt

Überprüfen Sie die Zusammenarbeit und die technischen Details, die zwischen einem Workloadteam und Plattformteams gemeinsam genutzt werden.

Abonnementverkauf

Die Architektur in diesem Artikel erweitert die Baseline-Architektur virtual machine (VM), um Änderungen und Erwartungen zu berücksichtigen, wenn Sie sie in einer Azure Landing Zone bereitstellen.

Im Beispiel in diesem Artikel möchte eine Organisation eine VM-basierte Workload verwenden, um Verbundressourcen zu verwenden, die ein Plattformteam zentral verwaltet. Zu diesen Ressourcen gehören Netzwerkressourcen für standortübergreifende Konnektivität, Identitätszugriffsverwaltung und Richtlinien. In diesem Beispiel wird davon ausgegangen, dass die Organisation Azure Zielzonen verwendet, um eine konsistente Governance und Kosteneffizienz für mehrere Workloads zu erzwingen.

Als Workloadbesitzer können Sie die Verwaltung gemeinsam genutzter Ressourcen in zentrale Teams entladen, sodass Sie sich auf die Arbeitsauslastungsentwicklung konzentrieren können. In diesem Artikel wird die Perspektive des Workloadteams erläutert. Empfehlungen für das Plattformteam werden angegeben.

Wichtig

Was sind Azure Landezonen? Azure Landungszonen stellen zwei Perspektiven des Cloudbedarfs einer Organisation dar. Eine Application Landing Zone ist ein Azure-Abonnement, in dem eine Workload ausgeführt wird. Sie ist mit den gemeinsamen Ressourcen der Organisation verbunden. Über diese Verbindung verfügt sie über Zugriff auf die grundlegende Infrastruktur, die die Workload ausführt, z. B. Netzwerk, Identitätszugriffsverwaltung, Richtlinien und Überwachung. Eine Plattform-Landing-Zone ist eine Sammlung verschiedener Abonnements, die jeweils einer bestimmten Funktion dienen. Beispielsweise bietet ein Konnektivitätsabonnement eine zentralisierte DNS-Auflösung (Domain Name System), eine standortübergreifende Konnektivität und virtuelle Netzwerkgeräte (Virtual Appliances, NVAs), die für Anwendungsteams zur Verfügung stehen.

Es wird empfohlen, das Konzept der Azure Zielzonen zu verstehen, um Sie bei der Vorbereitung auf die Implementierung dieser Architektur zu unterstützen.

Artikellayout

Architektur	Entwurfsentscheidung	Azure Well-Architected Framework-Ansatz
▪ Architekturdiagramm ▪ Workload-Ressourcen ▪ Verbundressourcen	▪ Abonnementeinrichtung ▪ Netzwerkanforderungen ▪ Netzwerkentwurfsänderungen aus dem Basisplan ▪ Überwachung ▪ Patch-Konformität ▪ Organisations-Governance ▪ Change Management	▪ Zuverlässigkeit ▪ Sicherheit ▪ Kostenoptimierung

Tipp

Diese implementierung reference veranschaulicht die in diesem Artikel beschriebenen bewährten Methoden.

Die Repositoryartefakte bieten eine anpassbare Grundlage für Ihre Umgebung. Die Implementierung richtet ein Hubnetzwerk mit gemeinsam genutzten Ressourcen wie Azure Firewall zu Demonstrationszwecken ein. Sie können dieses Setup auf separate Anwendungslandzonenabonnements für unterschiedliche Workload- und Plattformfunktionen anwenden.

Architektur

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

Alle Azure Zielzonenarchitekturen haben eine Trennung des Eigentums zwischen dem Plattformteam und dem Workload-Team. Anwendungsarchitekten und DevOps-Teams müssen ein starkes Verständnis für diese Verantwortung haben, um zu verstehen, was unter ihrem direkten Einfluss oder ihrer Kontrolle liegt und was nicht.

Arbeitsauslastung teameigene Ressourcen

Die folgenden Ressourcen bleiben gegenüber der Baselinearchitektur weitgehend unverändert.

• Azure Virtual Machines ist eine Infrastruktur als Dienst (IaaS), die skalierbare Computeressourcen bereitstellt. In dieser Architektur hosten VMs die Front-End- und Back-End-Ebenen und werden über Verfügbarkeitszonen für Resilienz verteilt.

• Azure Load Balancer ist ein Layer-4-Lastenausgleichsdienst für TCP-Datenverkehr (Transmission Control Protocol) und UDP-Datenverkehr (User Datagram Protocol). In dieser Architektur verteilt ein interner Load-Balancer den Datenverkehr von Front-End-VMs zu Back-End-VMs über Zonen hinweg.

• Azure Application Gateway ist ein Layer-7-Reverseproxy und ein Lastverteiler für Webdatenverkehr. In dieser Architektur beendet sie Transport Layer Security (TLS), prüft Anforderungen und dient als Reverseproxy, um den Benutzerdatenverkehr an Front-End-VMs weiterzuleiten. Die ausgewählte SKU hostt auch Azure Web Application Firewall, um die Front-End-VMs vor potenziell schädlichem Datenverkehr zu schützen.

• Azure Key Vault ist ein Dienst zum Verwalten von geheimen Schlüsseln, Schlüsseln und Zertifikaten. In dieser Architektur enthält sie die TLS-Zertifikate, die das Anwendungsgateway und VMs nutzen.

• Azure Monitor, Log Analytics und Application Insights sind Tools zum Sammeln, Speichern und Visualisieren von Observability-Daten. In dieser Architektur sammeln sie Gast- und Plattformmetriken und Protokolle, erfassen und korrelieren sie in einem dedizierten Arbeitsbereich und ermöglichen Telemetrie und Visualisierung auf Anwendungsebene für die Problembehandlung, Leistungsoptimierung und Governance.

• Azure Policy ist ein Dienst, der organisatorische Standards erzwingt und die Compliance im großen Maßstab bewertet. In dieser Architektur erfolgt die Anwendung workloadspezifischer Governance-Steuerelemente getrennt von plattformweiten Richtlinien.

Das Workload-Team verwaltet und erfüllt die folgenden Ressourcen und Verantwortlichkeiten.

• Satelliten-Teilnetzwerke und die Netzwerk-Sicherheitsgruppen (NSGs) bieten segmentierten IP-Adressraum und Grenzen für die Filterung von Datenverkehr. In dieser Architektur implementieren sie stufenbasierte Isolation und Steuern von Ost-West- und Eingangs- und Ausgangsflüssen für Workloadkomponenten.

• Private-Endpunkte bieten privaten IP-basierten Zugriff auf Plattformdienste über das Azure Backbone. In dieser Architektur sichern sie die Konnektivität mit Plattform as a Service (PaaS)-Lösungen und den privaten DNS-Zonen , die für diese Endpunkte erforderlich sind.

• Azure Managed Disks bieten dauerhaften, leistungsstarken Speicher für VMs. In dieser Architektur speichern sie Protokolldateien auf den Back-End-Servern, und die Daten werden auch dann beibehalten, wenn VMs neu gestartet werden. Die Front-End-Server verfügen über angefügte Datenträger, mit denen Sie Ihre zustandslose Anwendung bereitstellen können.

Ressourcen im Besitz des Plattformteams

Das Plattformteam besitzt und verwaltet diese zentralen Ressourcen. Bei dieser Architektur wird davon ausgegangen, dass diese Ressourcen vorab bereitgestellt werden und abhängigkeiten berücksichtigt werden.

• Azure Firewall im Hubnetzwerk ist ein zustandsbehafteter Netzwerksicherheitsdienst zum Filtern und Protokollieren von Datenverkehr. In dieser Architektur wird der Ausgangsverkehr aus dem Hub zentral überprüft und über erzwungenes Tunneling eingeschränkt. Diese Komponente ersetzt die öffentliche Azure Load Balancer in der Basisarchitektur, die keine Einschränkungen für ausgehenden Datenverkehr im Internet bietet.

• Azure Bastion im Hubnetzwerk ist ein architektonischer Ansatz, der Remotedesktop Protocol (RDP) und Secure Shell (SSH)-Konnektivität mit VMs über TLS bereitstellt, ohne öffentliche IP-Adressen verfügbar zu machen. In dieser Architektur stellt sie gemeinsam genutzten, geprüften Betriebszugriff auf Workload-VMs bereit. In der Basisarchitektur besitzt das Workloadteam diese Komponente.

• Das virtuelle Speichennetzwerk ist ein isolierter Adressraum, der mit einem Hub für gemeinsame Dienste verknüpft ist. In dieser Architektur hostet diese Architektur die Compute-, Ingress- und verwandten Ressourcen der Workload unter der Verantwortung des Teams.

• Benutzerdefinierte Routen (UDRs) sind benutzerdefinierte Routingregeln, mit denen Sie Routingtabellen anpassen können, um den Datenverkehr über bestimmte nächste Hops zu leiten. In dieser Architektur erzwingen sie den gesamten internetgebundenen Datenverkehr über die Firewall des Hubs.

• Azure Policy-basierte Governance-Einschränkungen und DeployIfNotExists (DINE)-Richtlinien stellen automatisch die erforderlichen Ressourcen für die Konformität bereit oder konfigurieren sie. In dieser Architektur stellen sie sicher, dass im Workloadabonnement vorgeschriebene plattformorientierte Konfigurationen vorhanden sind, z. B. private DNS oder Diagnose.

Wichtig

Azure Zielzonen stellen einige der vorherigen Ressourcen als Teil der Abonnements für die Plattform-Zielzone bereit, und Ihr Workload-Abonnement stellt weitere Ressourcen bereit. Viele der Ressourcen sind Teil des Konnektivitätsabonnements, das zusätzliche Ressourcen wie Azure ExpressRoute, Azure VPN Gateway und Azure DNS enthält. Diese zusätzlichen Ressourcen bieten Zugang über mehrere Standorte hinweg und Namensauflösung. Die Verwaltung dieser Ressourcen liegt außerhalb des Umfangs dieses Artikels.

Abonnementeinrichtung

In einem Anwendungslandungszonenkontext muss Ihr Workloadteam das Plattformteam über ihre spezifischen Anforderungen informieren.

Ihr Workload-Team muss detaillierte Informationen zum benötigten Netzwerkraum enthalten, damit das Plattformteam die erforderlichen Ressourcen zuordnen kann. Ihr Team bestimmt die Anforderungen, und das Plattformteam bestimmt die IP-Adressen, die innerhalb des virtuellen Netzwerks zugewiesen werden sollen, und die Verwaltungsgruppe, der das Abonnement zugewiesen ist.

Das Plattformteam weist eine entsprechende Verwaltungsgruppe basierend auf der geschäftlichen Kritikalität und den technischen Anforderungen der Workload zu, z. B. wenn eine Workload dem Internet ausgesetzt ist. Die Organisation bestimmt die Konfiguration dieser Verwaltungsgruppen, und das Plattformteam implementiert sie.

Beispielsweise werden die Verwaltungsgruppen in den Anwendungsszenarien für die Basisarchitektur berücksichtigt:

• Private-Anwendungen, z. B. interne Branchenanwendungen oder kommerzielle Off-the-Shelf-Lösungen (COTS), die sich häufig unter der Unternehmensleitungsgruppe Azure Landezonen befinden.

• Öffentliche Anwendungen, wie bei internetgerichteten Anwendungen, die häufig unter der Unternehmens- oder Online-Verwaltungsgruppe liegen.

Das Plattformteam ist auch für das Einrichten eines Abonnements oder einer Gruppe von Abonnements für die Workloadbereitstellung verantwortlich.

In den folgenden Abschnitten finden Sie Anleitungen zum anfänglichen Abonnementsetup. Das Plattformteam nimmt jedoch in der Regel Änderungen an den zentralen Diensten vor, um verpasste oder geänderte Anforderungen zu erfüllen. Plattformänderungen haben einen breiteren Einfluss auf alle Workload-Teams.

Daher muss das Plattformteam sicherstellen, dass alle VM-Workloads für alle Änderungen vorbereitet sind, und sie müssen den Lebenszyklus der VM-basierten Lösung und des Testzyklus kennen. Weitere Informationen finden Sie unter Verwalten von Änderungen im Laufe der Zeit.

Workloadanforderungen und Erfüllungen

Das Workload-Team und die Plattformteams teilen zwei Hauptaufgaben: Verwaltungsgruppenzuweisung und Netzwerkeinrichtung. Berücksichtigen Sie für diese Architektur die folgenden Netzwerkanforderungen, die Sie dem Plattformteam mitteilen sollten. Verwenden Sie diese Punkte als Beispiele, um die Diskussion und Aushandlung zwischen den beiden Teams zu verstehen, wenn Sie eine ähnliche Architektur implementieren.

• Die Anzahl der virtuellen Speichennetzwerke: In dieser Architektur ist nur ein dedizierter Speichen erforderlich. Die bereitgestellten Ressourcen müssen sich nicht über mehrere Netzwerke erstrecken und in einem einzigen virtuellen Netzwerk zusammengefasst werden.

• Die Größe des Speichennetzes: Berücksichtigen Sie die betrieblichen Anforderungen und das erwartete Wachstum der Arbeitsauslastung. Wenn Sie zum Beispiel Blau/Grün- oder Canary-Updates implementieren möchten, sollte die maximale Größe den benötigten Platz für Ihre parallelen Bereitstellungen berücksichtigen.

  Zukünftige Änderungen erfordern möglicherweise mehr IP-Adressenbereich, was möglicherweise nicht mit der aktuellen Zuweisung übereinstimmt. Die Integration dieser Räume kann zu einer zusätzlichen Komplexität führen. Seien Sie proaktiv und fordern Sie vorab genügend Netzwerkressourcen an, um sicherzustellen, dass der zugewiesene Speicherplatz zukünftige Erweiterungen aufnehmen kann.

• Die Bereitstellungsregion: Es ist wichtig, die Regionen anzugeben, in denen die Workload bereitgestellt wird. Das Plattformteam kann diese Informationen verwenden, um sicherzustellen, dass die virtuellen Speichen- und Hub-Netzwerke in derselben Region bereitgestellt werden. Netzwerke in unterschiedlichen Regionen können zu Latenzproblemen führen, da der Datenverkehr regionale Grenzen überschreitet und auch zusätzliche Bandbreitenkosten verursachen kann.

• Die Arbeitsauslastungsmerkmale und Designoptionen: Kommunizieren Sie Ihre Designentscheidungen, Komponenten und Merkmale an Ihr Plattformteam. Wenn Sie beispielsweise erwarten, dass Ihre Workload eine hohe Anzahl gleichzeitiger Verbindungen mit dem Internet (Chatty) generiert, sollte das Plattformteam sicherstellen, dass genügend SNAT-Ports (Source Network Address Translation) verfügbar sind, um die Erschöpfung zu verhindern. Sie können der zentralen Firewall öffentliche IP-Adressen hinzufügen, um den SNAT-Portpool zu erweitern oder eine Azure NAT Gateway anzufügen, um die SNAT-Kapazität weiter zu skalieren.

  Wenn Sie hingegen erwarten, dass Ihre Arbeitsauslastung minimale Netzwerkdatenverkehre (Hintergrundgeräusche) generiert, sollte das Plattformteam Ressourcen effizient in der gesamten Organisation verwenden.

  Das Plattformteam muss alle Abhängigkeiten klar verstehen. Ihre Workload benötigt z. B. Zugriff auf eine Datenbank, die ein anderes Team besitzt, oder Ihre Workload hat möglicherweise Verkehr über verschiedene Standorte hinweg. Verfügt Ihre Workload über Abhängigkeiten außerhalb von Azure? Solche Informationen sind für das Plattformteam wichtig.

• Die Firewallkonfiguration: Das Plattformteam muss den Datenverkehr kennen, der das Speichennetzwerk verlässt und in das Hubnetzwerk getunnelt wird. Die Firewall im Hub kann diesen Datenverkehr nicht blockieren.

  Wenn Ihre Workload beispielsweise auf Windows Updates zugreifen muss, um patched zu bleiben, sollte eine Firewall diese Updates nicht blockieren. Ebenso sollte eine Firewall diesen Datenverkehr nicht blockieren, wenn Monitor-Agents auf bestimmte Endpunkte zugreifen, da dies die Überwachung von Daten für Ihre Workload stören kann. Die Anwendung erfordert möglicherweise Zugriff auf Endpunkte von Drittanbietern. Verwenden Sie unabhängig davon eine zentralisierte Firewall, um zwischen erwartetem und unwarrantem Datenverkehr zu unterscheiden.

• Operatorzugriff: Wenn Microsoft Entra ID Sicherheitsgruppen vorhanden sind, die operatoren für den Zugriff auf die virtuellen Computer über Azure Bastion verwenden, informieren Sie das Plattformteam. Azure Bastion ist in der Regel eine zentrale Ressource. Es ist wichtig, sicherzustellen, dass die Sicherheitsgruppen und die VMs das sichere Protokoll unterstützen.

  Darüber hinaus informieren Sie das Plattformteam über die IP-Bereiche, die die VMs enthalten. Diese Informationen sind für die Konfiguration der NSGs um Azure Bastion im Hubnetzwerk erforderlich.

• Die öffentlichen IP-Adressen: Informieren Sie das Plattformteam über das eingehende Verkehrsprofil, einschließlich aller erwarteten öffentlichen IP-Adressen. In dieser Architektur wird nur vom Internet stammender Datenverkehr auf die öffentliche IP des Anwendungsgateways zielgerichtet. Das Plattformteam sollte das Workload-Team informieren, wenn diese IPs unter einem Azure DDoS-Schutzplan liegen oder wenn dies die Verantwortung des Workloadteams ist.

  In dieser Architektur gibt es eine weitere öffentliche IP für den betriebsfähigen Zugriff über Azure Bastion. Das Plattformteam besitzt diese öffentliche IP und ist in einem Dienst registriert, z. B. DDoS Protection, der vom Plattformteam ebenfalls verwaltet wird.

Wichtig

Wir empfehlen einen Abonnement-Verkaufsworkstream für das Plattformteam, das eine Reihe von Fragen umfasst, die zum Erfassen von Informationen aus dem Workloadteam konzipiert sind. Diese Fragen können von einer Organisation zu einer anderen variieren, aber die Absicht besteht darin, die Anforderungen für die Implementierung von Abonnements zu erfassen. Weitere Informationen finden Sie unter Abonnementverkauf.

VM-Design-Optionen

Die VM-SKU- und Datenträgerauswahl bleiben mit der Basisarchitekturidentisch.

Eine Organisation stellt möglicherweise Complianceanforderungen für das Workloadteam fest, das die Verwendung bestimmter VM-Images vorschreibt. Aufgrund dieser Anforderungen kann das Plattformteam eine Reihe standardisierter Bilder verwalten, die häufig als goldene Bilderbezeichnet werden, die für die gesamte Organisation erstellt werden.

Das Plattformteam kann ein verwaltetes Angebot wie Azure Compute Gallery oder ein privates Repository verwenden, um genehmigte Betriebssystemimages oder Workloadartefakte zu speichern. Wenn Sie ein Betriebssystemimage für VMs auswählen, wenden Sie sich an Ihr Plattformteam zu Bildquellen, Aktualisierungshäufigkeit und Nutzungserwartungen. Stellen Sie außerdem sicher, dass Bilder die erforderlichen geschäftlichen Anforderungen erfüllen können, die die Workload erfüllt.

Wichtig

Für das Plattformteam: Wenn Sie Compute Gallery verwenden, erfordert die Workload eine Netzwerksichtbarkeit für den privaten Katalog. Arbeiten Sie mit dem Workloadteam zusammen, um eine sichere Verbindung herzustellen.

Vernetzung

In der Baselinearchitektur wird die Workload in einem einzigen virtuellen Netzwerk bereitgestellt. Das Workloadteam verwaltet das virtuelle Netzwerk.

In dieser Architektur bestimmt das Plattformteam die Netzwerktopologie. Die Hub-Spoke-Topologie wird in dieser Architektur angenommen.

Laden Sie eine Visio-Datei dieser Architektur herunter.

• Hub-Virtualnetzwerk: ein regionaler Hub enthält zentrale Dienste, die mit Workloadressourcen in derselben Region kommunizieren. Weitere Informationen finden Sie unter Plattform-Teamressourcen. Wir empfehlen, den Hub im Konnektivitätsabonnementzu platzieren.

• Speichen-virtuelles Netzwerk: In dieser Architektur ist das einzelne virtuelle Netzwerk aus der Basisarchitektur das Speichennetzwerk. Es ist an das Hub-Netzwerk angeschlossen, das die zentralen Dienste enthält. Das Plattformteam besitzt und verwaltet dieses Speichennetzwerk. Dieses Netzwerk enthält die Belastungsressourcen. Das Workloadteam besitzt die Ressourcen in diesem Netzwerk, einschließlich seiner Subnetze.

Stellen Sie sicher, dass Sie die Workloadanforderungen an das Plattformteam übermitteln und diese regelmäßig überprüfen.

Wichtig

Für das Plattformteam: Es sei denn, es wird ausdrücklich von der Workload benötigt, peeren Sie das Spoke-Netzwerk nicht direkt mit einem anderen Spoke-virtuellen Netzwerk. Diese Übung schützt die Segmentierungsziele der Workload. Ihr Team sollte alle transitiven virtuellen Netzwerkverbindungen erleichtern.

Virtuelle Netzwerk-Subnetze

Im virtuellen Speichennetzwerk erstellt und weist das Workloadteam die Subnetze zu. Das Platzieren von Steuerelementen zum Einschränken des Datenverkehrs in und aus den Subnetzen trägt dazu bei, Segmentierung bereitzustellen. Diese Architektur verwendet dieselbe Subnetztopologie wie die Basisarchitektur, die dedizierte Subnetze für Anwendungsgateway, Front-End-VMs, das Lastenausgleichsmodul, Back-End-VMs und private Endpunkte enthält.

Wenn Sie Ihre Workload in einer Anwendungslandezone bereitstellen, müssen Sie dennoch Netzwerksteuerungen implementieren. Organisationen können Einschränkungen für den Schutz vor Datenexfiltration und die Sichtbarkeit des zentralen Sicherheitsbetriebszentrums (SOC) und des IT-Netzwerkteams festlegen.

Mit diesem Ansatz kann das Plattformteam die gesamte Organisationsausgaben optimieren, indem zentrale Dienste verwendet werden, anstatt redundante Sicherheitskontrollen für jede Arbeitsauslastung in der gesamten Organisation bereitzustellen. In dieser Architektur ist Azure Firewall ein Beispiel für einen zentralen Dienst. Es ist nicht kosteneffizient oder praktisch für jedes Workloadteam, seine eigene Firewallinstanz zu verwalten. Wir empfehlen einen zentralen Ansatz für die Firewallverwaltung.

Eingehender Datenverkehr

Der eingehende Datenverkehrsfluss bleibt mit der Basisarchitektur identisch.

Der Workload-Besitzer ist für sämtliche Ressourcen verantwortlich, die mit dem Eingang von öffentlichem Internetverkehr in den Workload verbunden sind. In dieser Architektur werden beispielsweise Das Anwendungsgateway und seine öffentliche IP-Adresse im Speichennetzwerk und nicht im Hubnetzwerk platziert. Einige Organisationen können Ressourcen mit eingehendem Datenverkehr in einem Verbindungsabonnement platzieren, indem eine zentralisierte entmilitarisierte Zone (DMZ)-Implementierung verwendet wird. Die Integration mit dieser spezifischen Topologie liegt außerhalb des Gültigkeitsbereichs für diesen Artikel.

Ausgehender Datenverkehr

In der Basisarchitektur legt die Skalierung des virtuellen Computers den Zugriff auf das öffentliche Internet über Azure Load Balancer fest, aber dieser Datenverkehr ist nicht eingeschränkt.

Dieses Design unterscheidet sich in dieser Architektur. Der gesamte Datenverkehr, der das Speichen-Virtual-Netzwerk verlässt, wird über eine Egress-Firewall durch das Peered Hub-Netzwerk geleitet. ** Eine Route ist mit allen möglichen Subnetzen im Spoke-Netzwerk verbunden, die den gesamten Datenverkehr von IPs, die nicht im lokalen virtuellen Netzwerk (0.0.0.0/0) vorhanden sind, zur Azure-Firewall des Hubs leitet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Arbeitslastkommunikation mit dem privaten Endpunkt für den Zugriff auf Key Vault bleibt identisch mit der Baseline-Architektur. Dieser Pfad wird aus dem vorherigen Diagramm aus Platzgründen weggelassen.

Das Workload-Team muss alle erforderlichen ausgehenden Datenverkehrsflüsse für die Infrastruktur und den Workload-Betrieb identifizieren, dokumentieren und kommunizieren. Das Plattformteam lässt den erforderlichen Datenverkehr zu, und der gesamte nicht kommunizierte ausgehende Datenverkehr wird wahrscheinlich blockiert.

Die Steuerung des Ausgangsverkehrs ist mehr als nur sicherzustellen, dass der erwartete Datenverkehr zulässig ist. Es geht auch darum, sicherzustellen, dass nur erwarteter Datenverkehr erlaubt wird. Nicht kommunizierter ausgehender Datenverkehr wird wahrscheinlich standardmäßig verweigert, aber es liegt im besten Sicherheitsinteresse der Workload, sicherzustellen, dass der Datenverkehr ordnungsgemäß weitergeleitet wird.

Tipp

Ermutigen Sie das Plattformteam, IP-Gruppen in Azure Firewall zu verwenden. Diese Vorgehensweise stellt sicher, dass die Anforderungen für den ausgehenden Datenverkehr Ihrer Workload genau durch eine enge Eingrenzung nur auf die Quellsubnetze dargestellt werden. Eine Regel, mit der Workload-VMs api.example.org erreichen können, bedeutet beispielsweise nicht unbedingt, dass die Unterstützung von Ressourcen innerhalb desselben virtuellen Netzwerks auf denselben Endpunkt zugreifen kann. Diese Ebene der granularen Kontrolle kann den Sicherheitsstatus Ihres Netzwerks verbessern.

Kommunizieren Sie alle spezifischen Anforderungen an den ausgehenden Datenverkehr an das Plattformteam. Die Firewall wendet die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) auf ausgehende Datenströme an, ersetzt die Quell-IP der Arbeitslast durch eine ihrer öffentlichen IP-Adressen und die Anzahl der angefügten IP-Adressen begrenzt das SNAT-Port-Kontingent. Wenn Ihre Workload zahlreiche gleichzeitige ausgehende Verbindungen herstellt, informieren Sie das Plattformteam, damit sie die SNAT-Portausschöpfung verringern können, indem sie eine Azure NAT Gateway anfügen oder weitere öffentliche IPs in der regionalen Firewall hinzufügen. Teilen Sie außerdem den öffentlichen IP-Satz der Firewall mit nachgeschalteten Partnern, sodass Zulassungslisten den gesamten Bereich möglicher Quell-IPs abdecken.

Ihre Organisation hat möglicherweise Anforderungen, die die Verwendung von Architekturmustern einschränken, die öffentliche IPs, die der Arbeitslast gehören, für den Datenabfluss nutzen. In diesem Fall können Sie Azure Policy verwenden, um öffentliche IPs auf VM-Netzwerkschnittstellenkarten (NICs) und anderen öffentlichen IPs zu verweigern, die nicht ihre bekannten Eingangspunkte sind.

Privates DNS Zonen

Architekturen, die private Endpunkte verwenden, benötigen private DNS-Zonen, um mit dem DNS-Anbieter zu arbeiten. Das Workloadteam muss über ein klares Verständnis der Anforderungen und verwaltung privater DNS-Zonen im Abonnement verfügen, das das Plattformteam bereitstellt. Privates DNS Zonen werden in der Regel in großem Umfang mit DINE-Richtlinien verwaltet, wodurch Azure Firewall als zuverlässiger DNS-Proxy funktionieren und vollqualifizierte Domänennamen(FQDN)-Netzwerkregeln unterstützen können.

In dieser Architektur stellt das Plattformteam die zuverlässige private DNS-Auflösung für Private Link-Endpunkte sicher. Arbeiten Sie mit Ihrem Plattformteam zusammen, um ihre Erwartungen zu verstehen.

Konnektivitätstests

Für VM-basierte Architekturen gibt es mehrere Testtools, mit denen Sie Netzwerkleitungs-, Routing- und DNS-Probleme ermitteln können. Sie können herkömmliche Tools zur Problembehandlung wie netstat, nslookupoder tcpingverwenden. Darüber hinaus können Sie die DHCP-Einstellungen (Dynamic Host Configuration Protocol) und DNS-Einstellungen des Netzwerkadapters untersuchen. Wenn NICs vorhanden sind, verfügen Sie über weitere Problembehandlungsfunktionen, mit denen Sie Konnektivitätsprüfungen mithilfe von Azure Network Watcher durchführen können.

Operatorzugriff

Wie die baseline-Architektur wird der betriebsbereite Zugriff über Azure Bastion in dieser Architektur unterstützt.

Die Basisarchitektur stellt jedoch Azure Bastion als Teil der Workload bereit. Für eine typische Organisation, die Azure Landing Zones einsetzt, wird Azure Bastion als zentrale Ressource für jede Region bereitgestellt. Das Plattformteam besitzt und verwaltet Azure Bastion, und alle Workloads in der Organisation teilen sie. Um diesen Anwendungsfall in dieser Architektur zu veranschaulichen, befindet sich Azure Bastion im Hubnetzwerk im Konnektivitätsabonnement.

Operatoridentität

Diese Architektur verwendet dieselbe Authentifizierungserweiterung wie die Basisarchitektur.

Anmerkung

Wenn sich Administratoren bei einem virtuellen Computer anmelden, müssen sie ihre Unternehmensidentitäten innerhalb ihres Microsoft Entra ID Mandanten verwenden und keine Serviceprinzipale über Funktionen hinweg freigeben.

Beginnen Sie immer mit dem Prinzip der minimalen Rechte und dem differenzierten Zugriff auf eine Aufgabe, anstelle eines dauerhaften Zugriffs. Nutzen Sie die Just-in-Time-Unterstützung (JIT), die das Plattformteam verwaltet.

Patchcompliance- und Betriebssystemupgrades

Die Basisarchitektur beschreibt einen autonomen Ansatz für Patching und Upgrades. Wenn die Workload in Landezonen integriert ist, kann sich dieser Ansatz ändern. Das Plattformteam könnte die Patchvorgänge vorgeben, sodass alle Workloads den organisatorischen Anforderungen entsprechen.

Stellen Sie sicher, dass der Patchvorgang alle Komponenten enthält, die Sie der Architektur hinzufügen. Wenn Sie beispielsweise Build-Agent-VMs hinzufügen, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu automatisieren, müssen diese virtuellen Computer die Plattformanforderungen erfüllen.

Überwachung

Die Azure Landingzone-Plattform bietet gemeinsam genutzte Überwachungsressourcen im Rahmen des Verwaltungsabonnements. Es wird jedoch empfohlen, Ihre eigenen Überwachungsressourcen einzurichten, um die Verantwortung für die Arbeitslast wahrzunehmen. Dieser Ansatz ist mit der Basisarchitekturkonsistent.

Das Arbeitsauslastungsteam stellt die Überwachungsressourcen bereit, die Folgendes umfassen:

• Application Insights als APM-Dienst (Application Performance Monitoring) für das Workloadteam.

• Der Log Analytics-Arbeitsbereich als einheitliche Ablage für alle Protokolle und Metriken, die aus von Arbeitslasten in Azure verwalteten Ressourcen und der Anwendungscode gesammelt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ähnlich wie der Basisplan werden alle Ressourcen so konfiguriert, dass Azure-Diagnose Protokolle an den Log Analytics Arbeitsbereich gesendet werden, den das Workloadteam als Teil der Infrastruktur als Codebereitstellung (IaC) der Ressourcen bereitgestellt. Möglicherweise müssen Sie auch Protokolle an einen zentralen Log Analytics Arbeitsbereich senden. In Azure Landing Zones befindet sich dieser Arbeitsbereich im Verwaltungsabonnement.

Das Plattformteam verfügt möglicherweise auch über DINE-Richtlinien, die sie zum Konfigurieren der Diagnose verwenden können, um Protokolle an ihre zentralisierten Verwaltungsabonnements zu senden. Es ist wichtig, sicherzustellen, dass Ihre Implementierung die zusätzlichen Protokollflüsse nicht einschränkt.

Daten aus mehreren Senken korrelieren

Die Protokolle und Metriken der Arbeitslast sowie ihre Infrastruktur-Komponenten werden im Log-Analytics-Arbeitsbereich der Arbeitslast gespeichert. Protokolle und Metriken, die zentrale Dienste wie Azure Firewall, Microsoft Entra ID und Azure Bastion, generieren, werden jedoch in einem zentralen Log Analytics Arbeitsbereich gespeichert. Das Zusammenführen und Abgleichen von Daten von mehreren Datenquellen kann eine komplexe Aufgabe sein.

Korrelierte Daten werden häufig während der Reaktion auf Vorfälle verwendet. Wenn es ein Problem mit der Korrelation von Daten aus mehreren Senken gibt, stellen Sie sicher, dass das Triage-Runbook für diese Architektur das Problem anspricht und Ansprechpartner enthält, falls das Problem über die Ressourcen der Arbeitslast hinausgeht. Workloadadministratoren benötigen möglicherweise Unterstützung von Plattformadministratoren, um Protokolleinträge aus Unternehmensnetzwerken, Sicherheitsdiensten oder anderen Plattformdiensten zu korrelieren.

Wichtig

Für das Plattformteam: Wo möglich, gewähren Sie Azure Role-based Access Control (Azure RBAC), um Protokollsenken für relevante Plattformressourcen abzufragen und zu lesen. Aktivieren Sie Firewallprotokolle für Netzwerk- und Anwendungsregelauswertungen und DNS-Proxy, da die Anwendungsteams diese Informationen während der Problembehandlungsaufgaben verwenden können.

Azure Policy

Das Plattformteam wendet wahrscheinlich Richtlinien an, die sich auf die Workloadbereitstellung auswirken. Sie wenden häufig DINE-Richtlinien an, um automatisierte Bereitstellungen in einem Landing Zone-Abonnement für Anwendungen zu verarbeiten. DINE-Richtlinien können Arbeitsauslastungsressourcen ändern oder Ihrer Bereitstellung Ressourcen hinzufügen, was zu einer Diskrepanz zwischen den Ressourcen führen kann, die deklarativ über die Workloadvorlage bereitgestellt werden, und den Ressourcen, die die Verarbeitungsanforderungen tatsächlich verwenden. Eine typische Lösung besteht darin, diese Änderungen mit imperativen Ansätzen zu beheben, die nicht ideal sind.

Um diese Diskrepanz zu vermeiden, sollten Sie die plattforminitiierten Änderungen in Ihre IaC-Vorlagen vorab integrieren und testen. Wenn das Plattformteam Azure Richtlinien verwendet, die mit den Anforderungen der Anwendung in Konflikt geraten, können Sie eine Lösung mit dem Plattformteam aushandeln.

Wichtig

Azure-Zielzonen verwenden verschiedene DINE-Richtlinien, zum Beispiel eine Richtlinie, die private Endpunkte in großem Umfang verwaltet. Diese Richtlinie überwacht die Bereitstellung privater Endpunkte und aktualisiert Azure DNS im Hubnetzwerk, das Teil eines plattformverwalteten Abonnements ist. Das Workloadteam verfügt nicht über die Berechtigung zum Ändern der Richtlinie im Hub, und das Plattformteam überwacht nicht die Bereitstellungen der Workloadteams, um DNS automatisch zu aktualisieren. DINE-Richtlinien werden verwendet, um diese Verbindung bereitzustellen.

Andere Richtlinien können sich auf diese Architektur auswirken, einschließlich Richtlinien, die:

• Fordern Sie eine Windows VM an, um einer Active Directory Domäne beizutreten. Diese Richtlinie stellt sicher, dass die JoinADDomainExtension VM-Erweiterung installiert und konfiguriert ist. Weitere Informationen finden Sie unter Enforce Windows VMs, um einer Active Directory Domäne beizutreten.
• Die IP-Weiterleitung auf Netzwerkschnittstellen verbieten.

Verwalten von Änderungen im Laufe der Zeit

Von der Plattform bereitgestellte Dienste und Vorgänge werden als externe Abhängigkeiten in dieser Architektur betrachtet. Das Plattformteam wendet weiterhin Änderungen an, integriert Benutzer und wendet Kostenkontrollen an. Das Plattformteam, das die Organisation bedient, priorisiert möglicherweise nicht einzelne Workloads. Änderungen an diesen Abhängigkeiten, seien es Änderungen an goldenen Images, Firewalländerungen, automatisierte Patchvorgänge oder Regeländerungen, können sich auf mehrere Workloads auswirken.

Daher müssen Arbeitsauslastungs- und Plattformteams effizient und zeitnah kommunizieren, um alle externen Abhängigkeiten zu verwalten. Es ist wichtig, Änderungen zu testen, damit sie keine negativen Auswirkungen auf Workloads haben.

Plattformänderungen, die sich auf die Workload auswirken

In dieser Architektur verwaltet das Plattformteam die folgenden Ressourcen. Änderungen an diesen Ressourcen können sich möglicherweise auf die Zuverlässigkeit, Sicherheit, Vorgänge und Leistungsziele der Workload auswirken. Es ist wichtig, diese Änderungen zu bewerten, bevor das Plattformteam sie in Kraft setzt, um zu bestimmen, wie sie sich auf die Arbeitsauslastung auswirken.

• Azure policies: Änderungen an Azure Richtlinien können sich auf Arbeitsauslastungsressourcen und deren Abhängigkeiten auswirken. Beispielsweise kann es direkte Richtlinienänderungen oder die Verschiebung der Landing Zone in eine neue Managementgruppen-Hierarchie geben. Diese Änderungen können unbemerkt bleiben, bis eine neue Bereitstellung vorhanden ist, daher ist es wichtig, sie gründlich zu testen.

• Firewallregeln: Änderungen an Firewallregeln können sich auf das virtuelle Netzwerk oder die Regeln der Workload auswirken, die allgemein für den gesamten Datenverkehr gelten. Diese Änderungen können zu blockierten Datenverkehr und sogar automatischen Prozessfehlern führen, z. B. fehlgeschlagene Anwendung von Betriebssystempatches. Diese potenziellen Probleme gelten sowohl für die ausgehende Azure-Firewall als auch für die vom Azure Virtual Network Manager angewendeten NSG-Regeln.

• Freigegebene Ressourcen: Änderungen an der SKU oder features für freigegebene Ressourcen können sich auf die Arbeitsauslastung auswirken.

• Routing im Hubnetzwerk: Änderungen der transitiven Art des Routings im Hub können sich potenziell auf die Arbeitsauslastungsfunktionalität auswirken, wenn eine Workload vom Routing an andere virtuelle Netzwerke abhängt.

• Azure Bastion host: Änderungen an der Azure Bastion Hostverfügbarkeit oder -konfiguration können sich auf Workloadvorgänge auswirken. Stellen Sie sicher, dass Änderungen des Sprungfeldzugriffsmusters über effektive Routine-, Ad-hoc- und Notfallzugriffe verfügen.

• Änderungen des Besitzes: Kommunizieren Sie alle Änderungen des Besitzes und der Kontaktpunkte an das Workloadteam, da sie sich auf die Verwaltungs- und Supportanfragen der Workload auswirken können.

Workloadänderungen, die sich auf die Plattform auswirken

Die folgenden Beispiele sind Workloadänderungen in dieser Architektur, die Sie mit dem Plattformteam kommunizieren sollten. Es ist wichtig, dass das Plattformteam die Zuverlässigkeit, Sicherheit, Vorgänge und Leistungsziele des Plattformdiensts anhand der änderungen des neuen Workloadteams überprüft, bevor sie wirksam werden.

• Netzwerkausfluss: Überwachen Sie jede signifikante Zunahme des Netzwerkausflusses, um zu verhindern, dass die Arbeitslast zu einem störenden Nachbarn auf Netzwerkgeräten wird. Dieses Problem kann sich möglicherweise auf die Leistungs- oder Zuverlässigkeitsziele anderer Workloads auswirken.

• öffentlichen Zugriff: Änderungen des öffentlichen Zugriffs auf Arbeitsauslastungskomponenten erfordern möglicherweise weitere Tests. Das Plattformteam kann die Arbeitsauslastung in eine andere Verwaltungsgruppe verschieben.

• Bewertung der unternehmenskritischen Leistung: Wenn es Änderungen an den Service-Level-Vereinbarungen (SLAs) des Workloads gibt, benötigen Sie möglicherweise einen neuen Ansatz für die Zusammenarbeit zwischen Plattform- und Workload-Teams.

• Änderungen des Besitzes: Kommunizieren Sie Änderungen des Eigentums und Kontaktpunkte an das Plattformteam.

Änderungen der Geschäftsanforderungen für Arbeitsauslastungen

Um die Ziele auf Serviceebene (SLOs) der Workload aufrechtzuerhalten, muss das Plattformteam möglicherweise an Änderungen der Workloadarchitektur beteiligt sein. Diese Änderungen erfordern möglicherweise die Änderungsverwaltung aus dem Plattformteam oder die Überprüfung, dass vorhandene Governance die geänderten Anforderungen unterstützt.

Kommunizieren Sie z. B. Änderungen an einem zuvor nicht zulässigen Ausgangsfluss, damit das Plattformteam diesen Fluss in der Firewall, Virtual Network Manager oder anderen Komponenten hinzufügen kann, um den erforderlichen Datenverkehr zu unterstützen. Wenn ein zuvor zulässiger Ausgang nicht mehr benötigt wird, sollte das Plattformteam diesen Fluss blockieren, um die Sicherheit der Workload aufrechtzuerhalten. Kommunizieren Sie außerdem Änderungen beim Routing an andere virtuelle Netzwerke oder standortübergreifende Endpunkte oder Änderungen an den Architekturkomponenten. Jede Ressource unterliegt Richtlinien und möglicherweise der Egress-Firewall-Kontrolle.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected Frameworks, bei dem es sich um eine Reihe von Leitsätzen handelt, die verwendet werden können, um die Qualität einer Arbeitsauslastung zu verbessern. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie an Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Diese Architektur entspricht den Zuverlässigkeitsgarantien in der Basisarchitektur.

Zuverlässigkeitsziele

Der maximal mögliche zusammengesetzte SLO ist niedriger als der Basis zusammengesetzte SLO aufgrund von Komponenten wie der Ausgangsnetzwerksteuerung. Diese Komponenten, die in Landungszonenumgebungen üblich sind, sind für diese Architektur nicht einzigartig. Der SLO wird ähnlich reduziert, wenn das Workloadteam diese Azure Dienste direkt steuert.

Trotz eines geringeren maximalen SLO-Werts ist der wichtigste Zuverlässigkeitsaspekt die Aufteilung von Arbeitsauslastungskomponenten in funktionalen Teams. Mit dieser Methode profitiert das Workload-Team von einem spezialisierten Team, das sich auf den Betrieb kritischer Infrastrukturen konzentriert, die sowohl diese als auch andere Workloads nutzen.

Weitere Informationen finden Sie unter Empfehlungen zum Definieren von Zuverlässigkeitszielen.

Kritische Abhängigkeiten

Zeigen Sie alle Funktionen an, die von der Workload in der Plattform und der Anwendungslandungszone als Abhängigkeiten ausgeführt werden. Vorfallreaktionspläne erfordern, dass das Workload-Team über die Methode und Art der Kontaktaufnahme für diese Abhängigkeiten Bescheid weiß. Schließen Sie diese Abhängigkeiten auch in die Fehlermodusanalyse (Failure Mode Analysis, FMA) der Workload ein.

Berücksichtigen Sie für diese Architektur die folgenden Abhängigkeiten:

• Ausgangsfirewall: Die zentrale Ausgangsfirewall, die von mehreren Workloads gemeinsam genutzt wird, erfährt Änderungen, die nicht mit der Workload in Zusammenhang stehen.

• Netzwerkportausschöpfung: Spitzen bei der Nutzung von allen Workloads, die das Netzwerkgerät gemeinsam nutzen, können zu einer Netzwerksättigung oder Portausschöpfung in der Ausgangsfirewall führen.

• DINE-Richtlinien: DINE-Richtlinien für Azure DNS private DNS-Zonen (oder andere plattformbasierte Abhängigkeiten) sind Best-Effort, ohne Ausführungs-SLA. Eine Verzögerung bei der DNS-Konfiguration kann zu Verzögerungen bei der Bereitschaft einer Anwendung zur Verarbeitung von Datenverkehr führen.

• Gruppenrichtlinien für die Verwaltung: Konsistente Richtlinien zwischen Umgebungen sind der Schlüssel zur Zuverlässigkeit. Stellen Sie sicher, dass Vorproduktionsumgebungen mit Produktionsumgebungen vergleichbar sind, um genaue Tests bereitzustellen und umgebungsspezifische Abweichungen zu verhindern, die eine Bereitstellung oder Skalierung blockieren können. Weitere Informationen finden Sie unter Verwaltung von Anwendungsentwicklungsumgebungen in Azure-Landing-Zonen.

Viele dieser Überlegungen könnten ohne Azure Landing Zones existieren, aber die Workload- und Plattformteams müssen zusammenarbeiten, um diese Probleme zu lösen und sicherzustellen, dass die Anforderungen erfüllt werden.

Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermodus- und Wirkungsanalyse.

Sicherheit

Die Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Die Sicherheitsüberlegungen für diese Architektur werden von der Basisarchitektur übernommen. Die Empfehlungen in den folgenden Abschnitten basieren auf der Prüfliste für die Sicherheitsentwurfsüberprüfung im Well-Architected Framework.

Netzwerksteuerungen

Konfigurieren Sie Netzwerksteuerelemente ordnungsgemäß, um sicherzustellen, dass Ihre Workload sicher ist.

Eingehender Datenverkehr

Sie können Ihre Workload von anderen Workload-Komponenten innerhalb Ihrer Organisation über NSGs in Ihren Subnetzen oder aufgrund der nichttransitiven Eigenschaften oder Kontrollfunktionen im regionalen Hub abschotten. Erstellen Sie umfassende NSGs, die nur die eingehenden Netzwerkanforderungen Ihrer Anwendung und ihrer Infrastruktur zulassen. Es wird empfohlen, dass Sie sich nicht ausschließlich auf die nichttransitive Art des Hubnetzwerks für die Sicherheit verlassen.

Das Plattformteam implementiert wahrscheinlich Azure-Richtlinien, um sicherzustellen, dass Application Gateway die Web Application Firewall auf Deny-Modus eingestellt hat, um die Anzahl der öffentlichen IPs, die für Ihr Abonnement verfügbar sind, zu begrenzen, und andere Prüfungen durchzuführen. Zusätzlich zu diesen Richtlinien sollte das Workload-Team die Verantwortung für die Bereitstellung workload-zentrierter Richtlinien tragen, die die eingehende Sicherheitslage verstärken.

Die folgende Tabelle enthält Beispiele für Einlasskontrollen innerhalb dieser Architektur.

Quelle	Zweck	Workload-Steuerung	Plattformsteuerung
Internet	Benutzerverkehrsflüsse	Leitet alle Anforderungen über eine NSG, eine Web Application Firewall sowie Routingregeln, bevor der öffentliche Datenverkehr zu dem privaten Datenverkehr wird, der in die Front-End-VMs eintritt.	Nichts
Azure Bastion	Operatorzugriff auf virtuelle Computer	NSG auf VM-Subnetzen, die allen Datenverkehr zu Remotezugriffsports blockieren, außer wenn er aus dem von der Plattform festgelegten Azure Bastion Subnetz stammt.	Nichts
Andere Speichen	Nichts	Blockiert über NSG-Regeln	Nichttransitives Routing oder Azure Firewall Regeln im Falle eines Azure Virtual WAN gesicherten Hubs

Ausgehender Datenverkehr

Wenden Sie NSG-Regeln an, die die erforderlichen Anforderungen an die ausgehende Konnektivität Ihrer Lösung ausdrücken und alles andere verweigern. Verlassen Sie sich nicht nur auf die Hubnetzwerksteuerelemente. Als Workload-Operator haben Sie die Verantwortung, unerwünschten ausgehenden Netzwerkverkehr so nah an der Quelle wie möglich zu stoppen.

Beachten Sie, dass während Sie ihr Subnetz innerhalb des virtuellen Netzwerks besitzen, das Plattformteam wahrscheinlich Firewallregeln erstellt hat, um ihre erfassten Anforderungen im Rahmen Ihres Abonnementverkaufsprozesses speziell darzustellen. Stellen Sie sicher, dass Änderungen an Subnetzen und Ressourcenplatzierungen während der Lebensdauer Ihrer Architektur weiterhin mit Ihrer ursprünglichen Anforderung kompatibel sind. Sie können auch mit Ihrem Netzwerkteam zusammenarbeiten, um die Kontinuität der Zugriffssteuerung für den geringsten Zugriff sicherzustellen.

Die folgende Tabelle zeigt Beispiele für Egress in dieser Architektur.

Endpunkt	Zweck	Workload-Steuerung (NSG)	Plattformsteuerung (Hub)
ntp.ubuntu.com	Das Network Time Protocol (NTP) für linux-VMs	UDP/123 für das Internet im Front-End-VM-Subnetz (die Ausgangsfirewall schränkt diese breite Öffnung ein)	Firewall-Netzwerkregelberechtigung für dasselbe wie die Workloadsteuerung
Windows Update Endpunkte	Windows Update-Funktionen von den Microsoft-Servern	TCP/443 und TCP/80 zum Internet im Subnetz der Back-End-VMs (die Ausgangsfirewall beschränkt diese breite Öffnung)	Firewall-Erlaubnisregel mit FQDN-Tag von WindowsUpdate
Überwachen von Agentendpunkten	Erforderlicher Datenverkehr für die Monitor-Erweiterung auf virtuellen Computern	TCP/443- zum Internet in beiden VM-Subnetzen (die Ausgangsfirewall beschränkt diese breite Öffnung)	Erforderliche Anwendungsregelerlaubnisse für die Firewall für alle spezifischen vollqualifizierten Domänennamen (FQDNs) auf TCP/443
nginx.org	So installieren Sie Nginx (eine Beispielanwendungskomponente) direkt vom Anbieter	TCP/443- zum Internet im Front-End-VM-Subnetz (die Ausgangsfirewall beschränkt diese breite Öffnung)	Erforderliche Firewallanwendungsregelzuteilung für nginx.org auf TCP/443-
Key Vault	So importieren Sie TLS-Zertifikate in Anwendungsgateway und VMs	- TCP/443 zu einem privaten Endpunktsubnetz von beiden VM-Subnetzen zu einem privaten Endpunktsubnetz - TCP/443 zu einem privaten Endpunktsubnetz aus einem Application Gateway-Subnetz - TCP/443 von virtuellen Computern, die mit einer erforderlichen ASG-Bezeichnung (Application Security Group) und einem Application Gateway-Subnetz gekennzeichnet sind	Nichts

DDoS-Schutz

Bestimmen Sie, wer für die Anwendung des DDoS-Schutzplans verantwortlich ist, der alle öffentlichen IPs Ihrer Lösung abdeckt. Das Plattformteam kann IP-Schutzpläne verwenden oder sogar Azure Policy verwenden, um Virtuelle Netzwerkschutzpläne zu erzwingen. Diese Architektur sollte über eine Abdeckung verfügen, da sie eine öffentliche IP für den Ausgang aus dem Internet umfasst.

Weitere Informationen finden Sie unter Empfehlungen für Netzwerk und Konnektivität.

Geheime Verwaltung

Für die geheime Verwaltung folgt diese Architektur der Basisarchitektur.

Als Workload-Team behalten Sie Ihre Geheimnisse in der Key Vault-Instanz bei. Stellen Sie nach Bedarf weitere Instanzen bereit, um Ihre Anwendungs- und Infrastrukturvorgänge zu unterstützen.

Weitere Informationen finden Sie unter Empfehlungen zum Schutz geheimer Anwendungsschlüssel.

Kostenoptimierung

Bei der Kostenoptimierung geht es um Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Für die Workloadressourcen gelten auch die Kostenoptimierungsstrategien in der Basisarchitektur für diese Architektur.

Diese Architektur profitiert erheblich von Azure Plattformressourcen für die Zielzone. Selbst wenn Sie diese Ressourcen über ein Chargebackmodell verwenden, sind die zusätzlichen Sicherheits- und standortübergreifenden Verbindungen kostengünstiger als die selbstverwaltende Verwaltung dieser Ressourcen.

Das Plattformteam verwaltet die folgenden Ressourcen in dieser Architektur. Diese Ressourcen sind häufig verbrauchsbasiert (Chargeback) oder potenziell kostenlos für das Workloadteam.

• Azure Firewall
• Sicherheitsinformationen und Ereignisverwaltung (SIEM)
• Azure Bastion-Hosts
• Standortübergreifende Konnektivität, z. B. ExpressRoute

Nutzen Sie andere zentralisierte Angebote Ihres Plattformteams, um diese Vorteile auf Ihre Workload zu erweitern, ohne dessen SLO-, Wiederherstellungszeitziel (RTO) oder Wiederherstellungspunktziel (RPO) zu beeinträchtigen.

Weitere Informationen finden Sie unter Empfehlungen zum Sammeln und Überprüfen von Kostendaten.

Implementieren dieses Szenarios

Eine Bereitstellung für diese Referenzarchitektur ist auf GitHub verfügbar.

Implementation: VM-Basisarchitektur in einer Azure Zielzone

Nächster Schritt

Überprüfen Sie die Zusammenarbeit und die technischen Details, die zwischen einem Workloadteam und Plattformteams gemeinsam genutzt werden.

Abonnementverkauf