Azure Virtual Machines-Baselinearchitektur in einer Azure-Zielzone

Die Architektur in diesem Artikel erweitert die Baselinearchitektur virtueller Maschinen (VM), um Änderungen und Erwartungen zu berücksichtigen, wenn Sie sie in einer Azure-Zielzone bereitstellen.

Im Beispiel in diesem Artikel möchte eine Organisation, dass eine VM-basierte Workload Verbundressourcen verwendet, 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 einführt, um konsistente Governance und Kosteneffizienz für mehrere Workloads zu erzwingen.

Als Workloadbesitzer können Sie die Verwaltung freigegebener Ressourcen an zentrale Teams auslagern und sich so auf die Workloadentwicklung konzentrieren. In diesem Artikel wird die Perspektive des Workloadteams erläutert. Es werden Empfehlungen für das Plattformteam angegeben.

Artikel-Layout

Aufbau	Entwurfsentscheidung	Ansatz für ein Azure Well-Architected Framework
▪ Architekturdiagramm ▪ Workloadressourcen ▪ Verbundressourcen	▪ Abonnementeinrichtung ▪ Netzwerkanforderungen ▪ Änderungen des Netzwerkentwurfs von der Baseline aus ▪ Überwachung ▪ Patch-Compliance ▪ Organisations-Governance ▪ Change Management	▪ Zuverlässigkeit ▪ Sicherheit ▪ Kostenoptimierung

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Komponenten

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

Eigene Ressourcen des Workloadteams

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

• Azure Virtual Machines ist die Anwendungsplattform. Die Computeressourcen werden über Verfügbarkeitszonen verteilt.

• Azure Load Balancer wird verwendet, um den Datenverkehr von den Front-End-VMs zu den Back-End-VMs privat zu laden. Mit dem Lastenausgleichsmodul wird Datenverkehr an alle VMs über Zonen hinweg verteilt.

• Azure Application Gateway wird als Reverseproxy verwendet, um die Benutzeranforderungen an die Front-End-VMs weiterzuleiten. Die ausgewählte SKU wird auch verwendet, um die Azure Web Application Firewall zu hosten und so die Front-End-VMs vor potenziell schädlichem Datenverkehr zu schützen.

• Azure Key Vault wird verwendet, um Anwendungsgeheimnisse und -zertifikate zu speichern.

• Azure Monitor, Protokollanalyse und Application Insights werden verwendet, um Daten zu Einblicken zu sammeln, zu speichern und zu visualisieren.

• Azure Policy wird verwendet, um Richtlinien anzuwenden, die für die Workload spezifisch sind.

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

• Virtuelle Spoke-Subnetze und die Netzwerksicherheitsgruppen (NSGs), die in diesen Subnetzen platziert werden, um die Segmentierung zu verwalten und den Datenverkehrsflow zu steuern.

• Private Endpunkte zum Sichern der Konnektivität mit Platform as a Service-Lösungen (PaaS) und den privaten DNS-Zonen, die für diese Endpunkte erforderlich sind.

• Azure Managed Disks speichert Protokolldateien auf Back-End-Servern und die Daten werden selbst beim Neustart von VMs beibehalten. 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 diese zentralen Ressourcen und verwaltet sie. Bei dieser Architektur wird davon ausgegangen, dass diese Ressourcen vorab bereitgestellt werden und Abhängigkeiten berücksichtigt werden.

• Die Azure-Firewall im Hubnetzwerk wird verwendet, um den ausgehenden Datenverkehr zu prüfen und einzuschränken. Diese Komponente ersetzt den Standard-Lastenausgleich in der Baselinearchitektur, der keine Einschränkungen für ausgehenden Datenverkehr im Internet bietet.

• Azure Bastion im Hubnetzwerk bietet sicheren operativen Zugriff auf Workload-VMs. In der Baselinearchitektur besitzt das Workloadteam diese Komponente.

• Das virtuelle Spoke-Netzwerk ist der Ort, an dem die Workload bereitgestellt wird.

• Benutzerdefinierte Routen (UDRs) werden verwendet, um das Tunneln für das Hubnetzwerk zu erzwingen.

• Richtlinienbasierte Azure-Governanceeinschränkungen und DeployIfNotExists (DINE-)Richtlinien sind Bestandteil des Workload-Abonnements.

Abonnementeinrichtung

In einem Zielzonenkontext muss Ihr Workloadteam das Plattformteam über seine spezifischen Anforderungen informieren.

Ihr Workloadteam muss detaillierte Informationen zu dem benötigten Netzwerkbereich 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 geeignete Verwaltungsgruppe basierend auf der Wichtigkeit für das Unternehmen und den technischen Anforderungen der Workload zu, z. B. wenn eine Workload im Internet verfügbar gemacht wird. Die Organisation bestimmt die Konfiguration dieser Verwaltungsgruppen, und das Plattformteam implementiert sie.

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

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

• Öffentliche Anwendungen, wie in internetorientierten Anwendungen, die sich häufig unter der Unternehmens- oder Online-Verwaltungsgruppe befinden.

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 ersten Einrichten des Abonnements. 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 weitreichendere Auswirkungen auf alle Workloadteams.

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 -Fulfillments

Das Workloadteam und die Plattformteams teilen zwei Standard-Verantwortlichkeiten: 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 Spoke-Netzwerke: In dieser Architektur ist nur ein dedizierter Spoke erforderlich. Die bereitgestellten Ressourcen müssen sich nicht über mehrere Netzwerke erstrecken und in einem einzigen virtuellen Netzwerk zusammengefasst werden.

• Die Größe des Spoke-Netzwerks: Berücksichtigen Sie die betrieblichen Anforderungen und das erwartete Wachstum der Workload. Wenn Sie beispielsweise Updateimplementierungen mit Blau-Grün- oder Canary-Releases planen, sollte die maximale Größe den Platz berücksichtigen, den Ihre parallelen Bereitstellungen erfordern.

  Zukünftige Änderungen erfordern möglicherweise mehr IP-Speicherplatz, was möglicherweise nicht mit der aktuellen Zuordnung übereinstimmt. Die Integration dieser Bereiche kann zu einer zusätzlichen Komplexität führen. Agieren Sie proaktiv und fordern Sie im Voraus genügend Netzwerkressourcen an, um sicherzustellen, dass der zugewiesene Platz für zukünftige Erweiterungen geeignet ist.

• 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 Spoke- 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 Workloadmerkmale und Designauswahl: Teilen Sie Ihrem Plattformteam Ihre Designauswahl, Komponenten und Merkmale mit. Wenn Sie beispielsweise erwarten, dass Ihre Workload eine hohe Anzahl gleichzeitiger Verbindungen mit dem Internet (übermäßige Kommunikation) generiert, sollte das Plattformteam sicherstellen, dass genügend Ports verfügbar sind, um die Auslastung zu verhindern. Sie können der zentralen Firewall IP-Adressen hinzufügen, um den Datenverkehr zu unterstützen oder ein NAT-Gateway (Network Address Translation) einzurichten und so den Datenverkehr über einen alternativen Pfad weiterzuleiten.

  Wenn Sie hingegen erwarten, dass Ihre Workload einen minimalen Netzwerkdatenverkehr (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 beispielsweise Zugriff auf eine Datenbank, die ein anderes Team besitzt, oder Ihre Workload verfügt möglicherweise über lokalen Datenverkehr. 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 Spoke-Netzwerk 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 gepatcht zu bleiben, sollte eine Firewall diese Updates nicht blockieren. Wenn es Monitor-Agents gibt, die auf bestimmte Endpunkte zugreifen, sollte eine Firewall diesen Datenverkehr ebenfalls nicht blockieren, da dies die Überwachungsdaten 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 unberechtigten 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.

  Informieren Sie das Plattformteam außerdem über die IP-Bereiche, die die VMs enthalten. Diese Informationen sind für die Konfiguration der NSGs rund um Azure Bastion im Hubnetzwerk erforderlich.

• Die öffentlichen IP-Adressen: Informieren Sie das Plattformteam über das eingehende Datenverkehrsprofil, einschließlich aller erwarteten öffentlichen IP-Adressen. In dieser Architektur zielt nur Datenverkehr aus dem Internet auf die öffentliche IP-Adresse auf Application Gateway ab. Das Plattformteam sollte das Workloadteam informieren, wenn diese IPs einem Azure DDoS Protection-Plan unterliegen oder angeben, ob dies in der Verantwortung des Workloadteams liegt.

  In dieser Architektur gibt es eine weitere öffentliche IP für den operativen 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.

VM-Entwurfsmöglichkeiten

Die VM-SKU und die Datenträgerauswahl entsprechen der Baselinearchitektur.

Eine Organisation kann dem Workloadteam Compliance-Anforderungen auferlegen, die die Verwendung bestimmter VM-Images vorschreiben. Aufgrund solcher Anforderungen kann das Plattformteam eine Reihe standardisierter Images verwalten, die häufig als goldene Images bezeichnet 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 Betriebssystem-Image für VMs auswählen, wenden Sie sich an Ihr Plattformteam bezüglich Image-Quellen, Aktualisierungshäufigkeit und Nutzungserwartungen. Stellen Sie außerdem sicher, dass Images die erforderlichen geschäftlichen Anforderungen erfüllen können, die die Workload erfüllt.

Netzwerk

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 verwendet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

• Virtuelles Hub-Netzwerk: Ein regionaler Hub enthält zentrale Dienste, die mit Workloadressourcen in derselben Region kommunizieren. Weitere Informationen finden Sie unter Plattform-Teamressourcen. Es wird empfohlen, den Hub im Konnektivitätsabonnement zu platzieren.

• Virtuelles Spoke-Netzwerk: In dieser Architektur ist das einzelne virtuelle Netzwerk aus der Baselinearchitektur das Spoke-Netzwerk. Es ist mit dem Hubnetzwerk verbunden, das die zentralisierten Dienste enthält. Das Plattformteam besitzt und verwaltet dieses Spoke-Netzwerk. Dieses Netzwerk enthält die Workloadressourcen. Das Workloadteam besitzt die Ressourcen in diesem Netzwerk, einschließlich seiner Subnetze.

Stellen Sie sicher, dass Sie die Workloadanforderungen dem Plattformteam mitteilen und diese regelmäßig überprüfen.

Subnetze des virtuellen Netzwerks

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

Wenn Sie Ihre Workload in einer Azure-Zielzone bereitstellen, müssen Sie weiterhin Netzwerkkontrollen 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 gesamten Organisationsausgaben optimieren, indem zentrale Dienste verwendet werden, anstatt redundante Sicherheitskontrollen für jede Workload 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 Datenverkehrsflow bleibt derselbe wie die Baselinearchitektur.

Der Workloadbesitzer ist für alle Ressourcen verantwortlich, die mit dem öffentlichen Internetzugriff auf Ihren Workload zusammenhängen. In dieser Architektur werden beispielsweise Application Gateway und seine öffentliche IP im Spoke-Netzwerk und nicht im Hubnetzwerk platziert. Einige Organisationen platzieren möglicherweise Ressourcen mit eingehendem Datenverkehr in einem Konnektivitätsabonnement, indem sie eine zentralisierte demilitarisierte Implementierung (DMZ) verwenden. Die Integration in diese spezifische Topologie ist nicht Gegenstand dieses Artikels.

Ausgehender Datenverkehr

In der Baselinearchitektur legt die Skalierung des virtuellen Workloadcomputers 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 virtuelle Spoke-Netzwerk verlässt, wird über eine ausgehende Firewall durch das Peer-Hub-Netzwerk geleitet. An alle möglichen Subnetze im Spoke-Netzwerk wird eine Route angehängt, die den gesamten Datenverkehr für IPs, die nicht im lokalen virtuellen Netzwerk gefunden werden (0.0.0.0.0/0), an die Azure Firewall des Hubs leitet.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Die Workload-Kommunikation mit dem privaten Endpunkt für den Key Vault-Zugriff bleibt dieselbe wie die Baselinearchitektur. Dieser Pfad wird aus dem vorherigen Diagramm aus Platzgründen ausgelassen.

Das Workloadteam muss alle erforderlichen ausgehenden Datenverkehrsflows für die Infrastruktur und den Workloadbetrieb identifizieren, dokumentieren und kommunizieren. Das Plattformteam lässt den erforderlichen Datenverkehr zu und der gesamte nicht kommunizierte ausgehende Datenverkehr wird wahrscheinlich abgelehnt.

Bei der Kontrolle des ausgehenden Datenverkehrs geht es um mehr als nur darum, sicherzustellen, dass der erwartete Datenverkehr zugelassen wird. Außerdem soll sichergestellt werden, dass nur der erwartete Datenverkehr zulässig ist. Nicht kommunizierter ausgehender Datenverkehr wird wahrscheinlich standardmäßig abgelehnt, aber es liegt im besten Sicherheitsinteresse der Workload, sicherzustellen, dass der Datenverkehr ordnungsgemäß weitergeleitet wird.

Teilen Sie dem Plattformteam alle besonderen Anforderungen an den ausgehenden Datenverkehr mit. Wenn Ihre Workload beispielsweise zahlreiche gleichzeitige Verbindungen zu externen Netzwerkendpunkten herstellt, informieren Sie das Plattformteam. Anschließend kann das Plattformteam entweder eine geeignete Azure NAT Gateway-Implementierung bereitstellen oder zur Schadensbegrenzung weitere öffentliche IP-Adressen zur regionalen Firewall hinzufügen.

In Ihrer Organisation gelten möglicherweise Anforderungen, die von der Verwendung von Architekturmustern abschrecken, die öffentliche IP-Adressen im Besitz der Workload für ausgehenden Datenverkehr verwenden. In diesem Fall können Sie Azure Policy verwenden, um öffentliche IP-Adressen auf VM-Netzwerkschnittstellenkarten (NICs) und alle anderen öffentlichen IP-Adressen außer Ihren bekannten Eingangspunkten zu verweigern.

Private DNS-Zonen

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

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

Konnektivitätstests

Für VM-basierte Architekturen gibt es mehrere Testtools, die dabei helfen können, Netzwerk-Sichtverbindungs-, Routing- und DNS-Probleme zu ermitteln. Sie können herkömmliche Tools zur Problembehandlung verwenden, z. B. netstat, nslookup oder tcping. Darüber hinaus können Sie das Dynamic Host Configuration Protocol (DHCP) und die DNS-Einstellungen des Netzwerkadapters überprüfen. Wenn NICs vorhanden sind, stehen Ihnen weitere Funktionen zur Problembehandlung zur Verfügung, mit denen Sie Konnektivitätsprüfungen mithilfe von Azure Network Watcher durchführen können.

Operator-Zugriff

Wie bei der Baselinearchitektur wird der operative Zugriff über Azure Bastion in dieser Architektur unterstützt.

Die Baselinearchitektur stellt Azure Bastion jedoch als Teil der Workload bereit. Für eine typische Organisation, die Azure-Zielzonen einführt, wird Azure Bastion als zentrale Ressourcen für jede Region bereitgestellt. Das Plattformteam besitzt und verwaltet Azure Bastion, und alle Workloads in der Organisation nutzen es gemeinsam. Um diesen Anwendungsfall in dieser Architektur zu veranschaulichen, befindet sich Azure Bastion im Hubnetzwerk im Konnektivitätsabonnement.

Operator-Identität

Diese Architektur verwendet dieselbe Authentifizierungserweiterung wie die Baselinearchitektur.

Beginnen Sie immer mit dem Prinzip der geringsten Rechte und des granularen Zugriffs auf eine Aufgabe anstelle eines langfristigen Zugriffs. Nutzen Sie im Kontext der Zielzone die Just-in-Time-Unterstützung (JIT), die das Plattformteam verwaltet.

Patch-Compliance und Betriebssystem-Upgrades

Die Baselinearchitektur beschreibt einen autonomen Ansatz für Patching und Upgrades. Wenn die Workload in Zielzonen integriert ist, kann sich dieser Ansatz ändern. Das Plattformteam kann die Patching-Vorgänge vorgeben, damit alle Workloads den organisatorischen Anforderungen entsprechen.

Stellen Sie sicher, dass der Patchvorgang alle Komponenten enthält, die Sie der Architektur hinzufügen. Wenn Sie sich beispielsweise dafür entscheiden, Build-Agent-VMs hinzuzufügen, um die Bereitstellung, Skalierung und Verwaltung von Anwendungen zu automatisieren, müssen diese VMs den Plattformanforderungen entsprechen.

Überwachung

Die Azure-Zielzonenplattform stellt freigegebene Ressourcen für Einblicke im Rahmen des Verwaltungsabonnements bereit. Es wird jedoch empfohlen, Ihre eigenen Überwachungsressourcen bereitzustellen, um die Verantwortlichkeiten der Workload zu vereinfachen. Dieser Ansatz ist mit der Baselinearchitektur konsistent.

Das Workloadteam stellt die Überwachungsressourcen bereit, darunter:

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

• der Protokollanalyse-Arbeitsbereich als einheitliche Senke für alle Protokolle und Metriken, die von Azure-Ressourcen im Besitz von Workloads und dem Anwendungscode gesammelt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ähnlich wie bei der Baseline sind alle Ressourcen so konfiguriert, dass sie Azure-Diagnoseprotokolle an den Protokollanalyse-Arbeitsbereich senden, den das Workloadteam im Rahmen der Infrastructure-as-Code-Bereitstellung (IaC) der Ressourcen bereitstellt. Möglicherweise müssen Sie auch Protokolle an einen zentralen Protokollanalyse-Arbeitsbereich senden. In Azure-Zielzonen befindet sich dieser Arbeitsbereich im Verwaltungsabonnement.

Das Plattformteam verfügt möglicherweise auch über DINE-Richtlinien, mit denen es Diagnostics konfigurieren kann, um Protokolle an seine zentralisierten Verwaltungsabonnements zu senden. Es ist wichtig, sicherzustellen, dass Ihre Implementierung die zusätzlichen Protokollflows nicht einschränkt.

Daten aus mehreren Senken korrelieren

Die Protokolle und Metriken der Workload sowie ihre Infrastrukturkomponenten werden imProtokollanalyse-Arbeitsbereich der Workload gespeichert. Protokolle und Metriken, die zentralisierte Dienste wie Azure Firewall, Microsoft Entra ID und Azure Bastion generieren, werden jedoch in einem zentralen Protokollanalyse-Arbeitsbereich gespeichert. Das Korrelieren von Daten aus mehreren Senken kann eine komplexe Aufgabe sein.

Bei der Reaktion auf Vorfälle werden häufig korrelierte Daten verwendet. Wenn beim Korrelieren von Daten aus mehreren Senken ein Problem auftritt, stellen Sie sicher, dass das Triage-Runbook für diese Architektur dieses Problem behebt und organisatorische Kontaktpunkte enthält, falls das Problem über die Workloadressourcen hinausgeht. Workload-Administratoren benötigen möglicherweise Unterstützung von Plattformadministratoren, um Protokolleinträge aus Unternehmensnetzwerk-, Sicherheits- oder anderen Plattformdiensten zu korrelieren.

Azure Policy

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

Um diese Diskrepanz zu vermeiden, integrieren und testen Sie die von der Plattform initiierten Änderungen in Ihre IaC-Vorlagen präventiv. Wenn das Plattformteam Azure-Richtlinien verwendet, die im Widerspruch zu den Anforderungen der Anwendung stehen, können Sie mit dem Plattformteam eine Lösung vereinbaren.

Änderungen im Laufe der Zeit verwalten

Von der Plattform bereitgestellte Dienste und Vorgänge gelten in dieser Architektur als externe Abhängigkeiten. Das Plattformteam nimmt weiterhin Änderungen vor, bindet Benutzer ein und wendet Kostenkontrollen an. Das Plattformteam, das die Organisation betreut, priorisiert möglicherweise einzelne Workloads nicht. Änderungen an diesen Abhängigkeiten, beispielsweise Golden Image-Änderungen, Firewall-Änderungen, automatisierte Patches oder Regeländerungen, können sich auf mehrere Workloads auswirken.

Daher müssen Workload- und Plattformteams effizient und zeitnah kommunizieren, um alle externen Abhängigkeiten zu verwalten. Es ist wichtig, Änderungen zu testen, damit sie sich nicht negativ auf die Arbeitslast auswirken.

Plattformänderungen, die sich auf die Arbeitslast auswirken

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

• Azure-Richtlinien: Änderungen an Azure-Richtlinien können sich auf Workload-Ressourcen und deren Abhängigkeiten auswirken. Beispielsweise kann es zu direkten Richtlinienänderungen oder einer Verschiebung der Zielzone in eine neue Verwaltungsgruppenhierarchie kommen. Diese Änderungen bleiben möglicherweise unbemerkt, bis es eine neue Bereitstellung gibt. Daher ist es wichtig, sie gründlich zu testen.

• Firewallregeln: Änderungen an Firewallregeln können sich auf das virtuelle Netzwerk der Workload oder auf Regeln auswirken, die allgemein für den gesamten Datenverkehr gelten. Diese Änderungen können zu blockiertem Datenverkehr und sogar zu automatischen Prozessfehlern führen, z. B. einer fehlgeschlagenen Anwendung von Betriebssystem-Patches. 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 an Funktionen auf gemeinsam genutzten Ressourcen können sich auf die Workload auswirken.

• Routing im Hubnetzwerk: Änderungen in der transitiven Art des Routings im Hub können sich möglicherweise auf die Workload-Funktionalität auswirken, wenn eine Workload vom Routing zu anderen virtuellen Netzwerken 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 Jumpbox-Zugriffsmusters über wirksamen Routine-, Ad-hoc- und Notfallzugriff verfügen.

• Besitzeränderungen: Teilen Sie dem Workloadteam alle Änderungen in Bezug auf Besitzer und Kontaktpunkte mit, da diese sich auf die Verwaltung und Supportanfragen der Workload auswirken können.

Workloadänderungen mit Auswirkungen auf die Plattform

Bei den folgenden Beispielen handelt es sich um Workload-Änderungen in dieser Architektur, die Sie dem Plattformteam mitteilen sollten. Es ist wichtig, dass das Plattformteam die Zuverlässigkeits-, Sicherheits-, Betriebs- und Leistungsziele des Plattformdienstes anhand der neuen Änderungen des Workloadteams validiert, bevor diese in Kraft treten.

• Netzwerkausgang: Überwachen Sie jeden signifikanten Anstieg des Netzwerkausgangs, um zu verhindern, dass die Arbeitslast zu einem Noisy-Neighbor-Effekt auf Netzwerkgeräten wird. Dieses Problem kann sich möglicherweise auf die Leistungs- oder Zuverlässigkeitsziele anderer Workloads auswirken.

• Öffentlicher Zugriff: Änderungen am öffentlichen Zugriff auf Workloadkomponenten erfordern möglicherweise weitere Tests. Das Plattformteam kann die Arbeitsauslastung in eine andere Verwaltungsgruppe verschieben.

• Bewertung der geschäftlichen Bedeutung: Wenn es Änderungen an den Service-Level-Agreements (SLAs) des Workloads gibt, benötigen Sie möglicherweise einen neuen Ansatz für die Zusammenarbeit zwischen der Plattform und den Workloadteams.

• Wechsel des Besitzers: Teilen Sie dem Plattformteam Änderungen in den Eigentumsverhältnissen und Kontaktpunkten mit.

Änderungen der Arbeitslast-Geschäftsanforderungen

Um Service-Level-Ziele (SLOs) der Workload einzuhalten, muss das Plattformteam möglicherweise in Änderungen der Workload-Architektur einbezogen werden. Diese Änderungen erfordern möglicherweise ein Änderungsmanagement durch das Plattformteam oder eine Validierung, dass die bestehende Governance die geänderten Anforderungen unterstützt.

Kommunizieren Sie beispielsweise Änderungen an einem zuvor nicht zugelassenen Ausgangsflow, damit das Plattformteam diesen Flow in der Firewall, im Virtual Network Manager oder in anderen Komponenten hinzufügen kann, um den erforderlichen Datenverkehr zu unterstützen. Wenn umgekehrt ein zuvor zugelassener Ausgangsflow nicht mehr benötigt wird, sollte das Plattformteam diesen Flow blockieren, um die Sicherheit der Workload aufrechtzuerhalten. Kommunizieren Sie auch Änderungen beim Routing an andere virtuelle Netzwerke oder standortübergreifende Endpunkte oder Änderungen an den Architekturkomponenten. Jede Ressource unterliegt Richtlinien und möglicherweise der Kontrolle durch die Ausgangs-Firewall.

Zuverlässigkeit

Diese Architektur entspricht den Zuverlässigkeitsgarantien in der Baselinearchitektur.

Zuverlässigkeitsziele

Das maximal mögliche zusammengesetzte SLO ist aufgrund von Komponenten wie der Ausgangsnetzwerksteuerung niedriger als das grundlegende zusammengesetzte SLO. Diese Komponenten, die in Zielzonenumgebungen üblich sind, sind für diese Architektur nicht einzigartig. Das SLO wird ebenfalls reduziert, wenn das Workloadteam diese Azure-Dienste direkt steuert.

Trotz eines niedrigeren maximal möglichen SLO liegt der wichtigste Aspekt der Zuverlässigkeit in der Aufteilung der Arbeitslastkomponenten auf funktionale Teams. Bei dieser Methode profitiert das Workloadteam von einem spezialisierten Team, das sich auf den Betrieb kritischer Infrastruktur konzentriert, die von diesem Workload und anderen Workloads genutzt wird.

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

Kritische Abhängigkeiten

Zeigen Sie alle Funktionen an, die die Workload in der Plattform- und Anwendungszielzone als Abhängigkeiten ausführt. Pläne zur Reaktion auf Vorfälle erfordern, dass das Workloadteam den Punkt und die Methode der Kontaktinformationen für diese Abhängigkeiten kennt. Beziehen Sie diese Abhängigkeiten auch in die Fehlermodusanalyse (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, unterliegt Änderungen, die nicht im Zusammenhang mit der Workload stehen.

• Ausschöpfung des Netzwerkports: Nutzungsspitzen durch alle Workloads, die das Netzwerkgerät gemeinsam nutzen, können zu einer Netzwerksättigung oder Portauslastung auf der Ausgangs-Firewall führen.

• DINE-Richtlinien: DINE-Richtlinien für private DNS-Azure DNS-Zonen (oder andere plattformbezogene Abhängigkeiten) erfolgen auf bestmögliche Weise, ohne SLA bei der Ausführung. Eine Verzögerung in der DNS-Konfiguration kann zu Verzögerungen bei der Bereitschaft einer Anwendung zur Verarbeitung des Datenverkehrs führen.

• Verwaltungsgruppenrichtlinien: Konsistente Richtlinien zwischen Umgebungen sind der Schlüssel zur Zuverlässigkeit. Stellen Sie sicher, dass Vorproduktionsumgebungen den Produktionsumgebungen ähneln, um genaue Tests zu ermöglichen und umgebungsspezifische Abweichungen zu verhindern, die eine Bereitstellung oder Skalierung blockieren können. Weitere Informationen finden Sie unter Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

Viele dieser Überlegungen könnten ohne Azure-Zielzonen bestehen, aber die Workload- und Plattformteams müssen diese Probleme gemeinsam angehen, um sicherzustellen, dass die Anforderungen erfüllt werden.

Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermodusanalyse.

Sicherheit

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

Netzwerksteuerungen

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

Eingehender Datenverkehr

Sie können Ihre Workload von anderen Workload-Spokes innerhalb Ihrer Organisation über NSGs in Ihren Subnetzen oder die nichttransitive Art oder Kontrollen im regionalen Hub isolieren. Erstellen Sie umfassende NSGs, die nur die eingehenden Netzwerkanforderungen Ihrer Anwendung und ihrer Infrastruktur zulassen. Wir empfehlen, dass Sie sich aus Sicherheitsgründen nicht ausschließlich auf die nichttransitive Art des Hubnetzwerks verlassen.

Das Plattformteam implementiert wahrscheinlich Azure-Richtlinien, um sicherzustellen, dass die Webanwendungsfirewall auf den Modus „Ablehnen“ festgelegt ist, um die Anzahl der öffentlichen IPs einzuschränken, die für Ihr Abonnement verfügbar sind, und andere Prüfungen. Zusätzlich zu diesen Richtlinien sollte das Workloadteam die Verantwortung für die Bereitstellung workloadorientierter Richtlinien besitzen, die den eingehenden Sicherheitsstatus verstärken.

Die folgende Tabelle enthält Beispiele für Eingangssteuerelemente in dieser Architektur.

Quelle	Zweck	Workload-Steuerung	Plattformsteuerung
Internet	Datenverkehrsflows von Benutzern	Leitet alle Anfragen durch eine NSG, eine Web Application Firewall und Routing-Regeln, bevor der öffentliche Datenverkehr in den privaten Datenverkehr übergeht, der in die Front-End-VMs gelangt	Keine
Azure Bastion	Operatorzugriff auf virtuelle Computer	NSG auf VM-Subnetzen, das den gesamten Datenverkehr zu RAS-Ports blockiert, es sei denn, er stammt aus dem angegebenen Azure Bastion-Subnetz der Plattform	Keine
Andere Spokes	Keine	Blockiert über NSG-Regeln	Nichttransitives Routing oder Azure Firewall-Regeln im Fall eines durch Azure Virtual WAN gesicherten Hubs

Ausgehender Datenverkehr

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

Beachten Sie, dass das Plattformteam, obwohl Sie der Besitzer Ihres Subnetzes innerhalb des virtuellen Netzwerks sind, wahrscheinlich Firewall-Regeln erstellt hat, um Ihre erfassten Anforderungen im Rahmen Ihres Abonnementverkaufsprozesses speziell darzustellen. Stellen Sie sicher, dass Änderungen an Subnetzen und Ressourcenplatzierung im Laufe der Lebensdauer Ihrer Architektur weiterhin mit Ihrer ursprünglichen Anfrage kompatibel sind. Oder Sie können mit Ihrem Netzwerkteam zusammenarbeiten, um die Kontinuität der Ausgangskontrolle mit geringstem Zugriff sicherzustellen.

Die folgende Tabelle enthält Beispiele für Eingänge in dieser Architektur.

Endpunkt	Zweck	Workload-Steuerung (NSG)	Plattformsteuerung (Hub)
ntp.ubuntu.com	Das Network Time Protocol (NTP) für linux-VMs	UDP/123 zum Internet im Front-End-VM-Subnetz (Die Ausgangsfirewall beschränkt diese breite Öffnung)	Firewall-Netzwerkregelberechtigung für dasselbe wie die Workloadsteuerung
Windows Update-Endpunkte	Windows Update-Funktionalität von Microsoft-Servern	TCP/443 und TCP/80 zum Internet im Back-End-VM-Subnetz (die Ausgangsfirewall beschränkt diese breite Öffnung)	Firewall-Zulassungsregel mit FQDN-Tag von WindowsUpdate
Agent-Endpunkte überwachen	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 Firewallanwendungsregel-Zulassungen für alle spezifischen FQDNs unter TCP/443
nginx.org	Zur Installation von Nginx (eine Beispielanwendungskomponente) direkt über den Anbieter	TCP/443 zum Internet im Front-End-VM-Subnetz (Die Ausgangsfirewall beschränkt diese breite Öffnung)	Erforderliche Firewallanwendungsregel-Zulassung für nginx.org auf TCP/443
Schlüsseltresor	Zum Import von TLS-Zertifikaten (Transport Layer Security) in Application Gateway und VMs	- TCP/443 zu einem privaten Endpunktsubnetz von beiden VM-Subnetzen zu einem privaten Endpunktsubnetz - TCP/443 zu einem privaten Endpunktsubnetz aus einem Anwendungsgateway-Subnetz - TCP/443 von VMs, die mit einer erforderlichen Bezeichnung für Anwendungssicherheitsgruppen (ASG) und dem Application Gateway-Subnetz markiert sind	Keine

DDoS Protection

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 nutzen, 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.

Verwaltung von Geheimnissen

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

Als Workloadteam behalten Sie Ihre Geheimnisse weiterhin in Ihrer 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

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

Diese Architektur profitiert erheblich von den Ressourcen der Azure-Zielzonenplattform. Selbst wenn Sie diese Ressourcen über ein Chargeback-Modell nutzen, sind die zusätzliche Sicherheit und die standortübergreifende Konnektivität kostengünstiger als die Selbstverwaltung dieser Ressourcen.

Das Plattformteam verwaltet die folgenden Ressourcen in dieser Architektur. Diese Ressourcen sind häufig verbrauchsabhängig (Rückbuchung) oder für das Workloadteam möglicherweise kostenlos.

• Azure Firewall
• SIEM-Lösung (Security Information and Event Management)
• Azure Bastion-Hosts
• Standortübergreifende Konnektivität, z. B. ExpressRoute

Nutzen Sie andere zentralisierte Angebote Ihres Plattformteams, um diese Vorteile auf Ihre Workload auszuweiten, ohne deren SLO, Recovery Time Objective (RTO) oder Recovery Point Objective (RPO) zu beeinträchtigen.

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

Bereitstellen dieses Szenarios

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

Nächster Schritt

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

Abonnementverkauf