Basisarchitektur virtueller Azure-Computer in einer Azure-Zielzone

Die Architektur in diesem Artikel erweitert die Vm-Basisarchitektur (VM), die, um Änderungen und Erwartungen zu beheben, wenn Sie sie in einer Azure-Zielzone 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.

Artikellayout

Architektur	Entwurfsentscheidung	Azure Well-Architected Framework-Ansatz
▪ Architekturdiagramm ▪ Workloadressourcen ▪ Partnerressourcen	▪ Abonnementsetup ▪ Netzwerkanforderungen ▪ Netzwerkentwurfsänderungen aus dem Basisplan ▪ Monitoring ▪ Patchcompliance- ▪ Organisationsgovernance ▪ Change Management	▪ Zuverlässigkeit ▪ Security ▪ Kostenoptimierung

Architektur

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 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 größtenteils unverändert von der Basisarchitektur.

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

• Azure Load Balancer wird verwendet, um den Datenverkehr privat von den Front-End-VMs auf die Back-End-VMs zu laden. Der Lastenausgleich verteilt Datenverkehr an VMs über Zonen hinweg.

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

• Azure Key Vault- wird zum Speichern von Anwendungsschlüsseln und Zertifikaten verwendet.

• Azure Monitor-, Log Analytics- und Application Insights- werden verwendet, um Observability-Daten 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.

• Speichen-Subnetze für virtuelle Netzwerke und die Netzwerksicherheitsgruppen (NSGs), die auf diesen Subnetzen platziert werden, um die Segmentierung zu verwalten und den Datenverkehrsfluss zu steuern.

• privaten Endpunkte, um die Konnektivität mit PaaS-Lösungen (Platform as a Service) und die privaten DNS-Zonen zu sichern, die für diese Endpunkte erforderlich.

• von Azure Managed Disks Protokolldateien auf den Back-End-Servern speichert und die Daten auch dann aufbewahrt werden, 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 verwendet wird, um den Ausgehenden Datenverkehr zu prüfen und einzuschränken. Diese Komponente ersetzt den Standardmäßigen Lastenausgleich in der Basisarchitektur, der keine Einschränkungen für ausgehenden Datenverkehr im Internet bietet.

• Azure Bastion im Hubnetzwerk bietet sicheren betriebsbereiten Zugriff auf Arbeitsauslastungs-VMs. In der Basisarchitektur besitzt das Workloadteam diese Komponente.

• Das virtuelle Netzwerk mit Speichen ist der Ort, an dem die Workload bereitgestellt wird.

• benutzerdefinierte Routen (USER-defined routes, UDRs) werden verwendet, um das Tunneln in das Hubnetzwerk zu erzwingen.

• Richtlinienbasierte Azure-Governanceeinschränkungen und DeployIfNotExists (DINE)-Richtlinien sind Teil des Workloadabonnements.

Abonnementeinrichtung

In einem Zielzonenkontext muss Ihr Workloadteam das Plattformteam über seine 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 eine entsprechende Verwaltungsgruppe basierend auf der Geschäftskritischenität und technischen Anforderungen der Workload zuweist, z. B. wenn eine Arbeitsauslastung für das Internet verfügbar 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 Unternehmensverwaltungsgruppe von Azure-Landzonen befinden.

• öffentliche Anwendungen, wie in internetorientierten 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 wirken sich auf alle Workloadteams aus.

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 z. B. Blau-/Grün- oder Canaryupdates implementieren möchten, sollte die maximale Größe den Platz berücksichtigen, den Ihre parallelen Bereitstellungen erfordern.

  Zukünftige Änderungen erfordern möglicherweise mehr IP-Speicherplatz, was mit der aktuellen Zuordnung falsch ausgerichtet werden kann. 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 Ports verfügbar sind, um die Erschöpfung 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, um den Datenverkehr über einen alternativen Pfad weiterzuleiten.

  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 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 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 es Monitor-Agents gibt, die auf bestimmte Endpunkte zugreifen, diesen Datenverkehr nicht blockieren, da die Überwachung von Daten für Ihre Workload unterbrochen werden 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 Datenverkehrsprofil, einschließlich aller erwarteten öffentlichen IP-Adressen. In dieser Architektur zielt nur der datenverkehrsbezogene Internet auf die öffentliche IP auf dem Anwendungsgateway ab. Das Plattformteam sollte das Workload-Team informieren, wenn diese IPs unter einem Azure DDoS Protection-Plan stehen oder wenn dies die Verantwortung des Workloadteams ist.

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

Auswahlmöglichkeiten für vm-Design

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.

Vernetzung

In der Basisarchitekturwird 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.

• virtuellen Hubnetzwerk: 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 wird mit dem Hubnetzwerk peered, das die zentralen Dienste enthält. Das Plattformteam besitzt und verwaltet dieses Speichennetzwerk. 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 an das Plattformteam übermitteln und diese regelmäßig überprüfen.

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 Azure-Zielzone bereitstellen, müssen Sie dennoch Netzwerksteuerelemente 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 Basisarchitekturidentisch.

Der Workloadbesitzer ist für alle Ressourcen verantwortlich, die sich auf das öffentliche Internet beziehen, in Ihren Workload eingehen. 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 Konnektivitätsabonnement platzieren, indem eine zentralisierte entilitarisierte (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 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 Speichennetzwerk verlässt, wird über eine Ausgangsfirewall über das Peered Hub-Netzwerk geleitet. Eine Route ist an alle möglichen Subnetze im Speichennetzwerk angefügt, die den gesamten Datenverkehr für IPs leitet, die nicht im lokalen virtuellen Netzwerk (0.0.0.0/0) an die Azure-Firewall des Hubs gefunden werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

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

Das Workloadteam muss alle erforderlichen ausgehenden Datenverkehrsflüsse für die Infrastruktur- und Workloadvorgänge identifizieren, dokumentieren und kommunizieren. Das Plattformteam ermöglicht den erforderlichen Datenverkehr, und der gesamte unübertragbare Datenverkehr wird wahrscheinlich verweigert.

Die Steuerung des Ausgangsverkehrs ist mehr als nur sicherzustellen, dass der erwartete Datenverkehr zulässig ist. Es geht auch darum, sicherzustellen, dass nur erwarteten Datenverkehr zulässig ist. Der unübertragbare Datenverkehr wird wahrscheinlich standardmäßig verweigert, aber es liegt im besten Sicherheitsinteresse der Workload, um sicherzustellen, dass der Datenverkehr ordnungsgemäß weitergeleitet wird.

Kommunizieren Sie alle eindeutigen Datenverkehrsanforderungen an das Plattformteam. Wenn Ihre Workload beispielsweise zahlreiche gleichzeitige Verbindungen mit externen Netzwerkendpunkten herstellt, informieren Sie das Plattformteam. Anschließend kann das Plattformteam entweder eine entsprechende Azure NAT-Gatewayimplementierung bereitstellen oder weitere öffentliche IPs in der regionalen Firewall zur Entschärfung hinzufügen.

Ihre Organisation verfügt möglicherweise über Anforderungen, die die Verwendung von Architekturmustern verhindern, die arbeitslasteigene öffentliche IPs für den Ausgang verwenden. In diesem Fall können Sie azure Policy verwenden, um öffentliche IPs auf NETZWERKkarten (VM Network Interface Cards, NICs) und alle anderen öffentlichen IPs zu verweigern, die nicht ihre bekannten Eingangspunkte sind.

Private 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. Private DNS-Zonen werden in der Regel in großem Umfang mit DINE-Richtlinien verwaltet, wodurch Azure Firewall als zuverlässiger DNS-Proxy funktioniert und vollqualifizierte Domänennamen (Fully Qualified Domain Name, FQDN) Netzwerkregeln unterstützt.

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 Basisarchitekturwird der betriebsbereite Zugriff über Azure Bastion in dieser Architektur unterstützt.

Die Basisarchitektur stellt Azure Bastion jedoch als Teil der Workload bereit. Für eine typische Organisation, die Azure-Landezonen verwendet, stellen sie Azure Bastion als zentrale Ressourcen für jede Region bereit. 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.

Beginnen Sie immer mit dem Prinzip der geringsten Rechte und dem differenzierten Zugriff auf eine Aufgabe anstelle eines langjährigen Zugriffs. Nutzen Sie im Kontext der Zielzone 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 kann die Patchvorgänge diktieren, sodass alle Workloads den Organisatorischen 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-Zielzonenplattform bietet gemeinsam genutzte Observability-Ressourcen als Teil des Verwaltungsabonnements. Es wird jedoch empfohlen, Ihre eigenen Überwachungsressourcen bereitzustellen, um die Verantwortlichkeiten der Arbeitsauslastung zu erleichtern. Dieser Ansatz ist mit der Basisarchitekturkonsistent.

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

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

• Der Log Analytics-Arbeitsbereich als einheitliche Spüle für alle Protokolle und Metriken, die aus Ressourcen im Besitz der Workload und dem Anwendungscode gesammelt werden.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Ähnlich wie der Basisplan werden alle Ressourcen so konfiguriert, dass Azure Diagnostics-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-Zielzonen 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.

Korrelieren von Daten aus mehreren Senken

Die Protokolle und Metriken der Workload und ihre Infrastrukturkomponenten werden im Log Analytics-Arbeitsbereich der Workload 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 Korrelieren von Daten aus mehreren Senken kann eine komplexe Aufgabe sein.

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

Azure-Richtlinie

Das Plattformteam wendet wahrscheinlich Richtlinien an, die sich auf die Workloadbereitstellung auswirken. Sie wenden häufig DINE-Richtlinien an, um automatisierte Bereitstellungen in einem Anwendungslandzonenabonnement 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.

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, unabhängig davon, ob sie goldene Bildänderungen, Firewalländerungen, automatisierte Patching- oder Regeländerungen sind, 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-Richtlinien: Änderungen an Azure-Richtlinien können sich auf Arbeitsauslastungsressourcen und deren Abhängigkeiten auswirken. Beispielsweise kann es direkte Richtlinienänderungen oder die Bewegung der Zielzone in eine neue Verwaltungsgruppenhierarchie 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 azure Virtual Network Manager-angewendete 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.

• Netzwerkausgang: Überwachen Sie jede signifikante Zunahme des Netzwerkausgangs, um zu verhindern, dass die Arbeitsauslastung zu einem lauten 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 Änderungen an den Vereinbarungen auf Servicelevel (Service Level Agreements, SLAs) der Workload vorliegen, benötigen Sie möglicherweise einen neuen Ansatz für die Zusammenarbeit zwischen plattform- und Workloadteams.

• Ä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 unterliegt möglicherweise der Firewallsteuerung.

Betrachtungen

Diese Überlegungen implementieren die Säulen des Azure Well-Architected-Frameworks, das eine Reihe von leitden Tenets ist, die verwendet werden können, um die Qualität einer Workload 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 die geplante zusammengesetzte SLO- aufgrund von Komponenten wie Der Ausgang-Netzwerksteuerung. 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 Workloadteam von einem spezialisierten Team, das sich auf den Betrieb kritischer Infrastruktur konzentriert, die diese Workload und andere Workloads verwenden.

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 Workloadteam den Punkt und die Methode der Kontaktinformationen für diese Abhängigkeiten kennt. 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:

• Firewall-: Die zentrale Ausgangsfirewall, die von mehreren Workloads gemeinsam genutzt wird, unterliegt Änderungen, die nicht im Zusammenhang mit der Workload 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 private Azure DNS-Zonen (oder andere plattformbezogene Abhängigkeiten) sind besten Aufwand, ohne SLA bei der Ausführung. 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 Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

Viele dieser Überlegungen können ohne Azure-Zielzonen vorhanden sein, aber die Workload- und Plattformteams müssen diese Probleme zusammenarbeiten, um sicherzustellen, dass die Anforderungen erfüllt sind.

Weitere Informationen finden Sie unter Empfehlungen für die Durchführung der Fehlermodusanalyse.

Sicherheit

Die Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für sicherheitsrelevante.

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 Sicherheitsentwurfsprüfung in der Well-Architected Framework-.

Netzwerksteuerelemente

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

Eingehender Datenverkehr

Sie können Ihre Arbeitsauslastung von anderen Workload-Speichen innerhalb Ihrer Organisation über NSGs in Ihren Subnetzen oder die nichttransitive Natur oder Steuerelemente im regionalen Hub isolieren. 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 die Anwendungsfirewall auf Deny Modefestgelegt 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	Benutzerdatenverkehrflüsse	Trichtert alle Anforderungen über eine NSG-, Webanwendungsfirewall und Routingregeln, bevor der öffentliche Datenverkehr zu privatem Datenverkehr wechselt, der die Front-End-VMs eingibt	Nichts
Azure Bastion	Operatorzugriff auf virtuelle Computer	NSG auf VM-Subnetzen, die den gesamten Datenverkehr zu Remotezugriffsports blockieren, es sei denn, sie stammt aus dem von der Plattform festgelegten Azure Bastion-Subnetz.	Nichts
Andere Speichen	Nichts	Blockiert über NSG-Regeln	Nichttransitives Routing oder Azure Firewall-Regeln im Falle eines durch 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 Arbeitsauslastungsoperator haben Sie die Verantwortung, unerwünschten Ausgehenden Datenverkehr so nah an der Quelle wie praktikabel 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 den Ausgang in dieser Architektur.

Endpunkt	Zweck	Workload(NSG)-Steuerelement	Plattformsteuerelement (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 im Back-End-VM-Subnetz (die Ausgangsfirewall beschränkt diese breite Öffnung)	Firewall-Zertifikatregel 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 Zertifikate für Firewallanwendungsregel für alle spezifischen 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 (Transport Layer Security) in Application Gateway und VMs	- TCP/443- zu einem privaten Endpunktsubnetz von beiden VM-Subnetzen zu einem privaten Endpunkt-Subnetz - TCP/443- zu einem privaten Endpunktsubnetz aus einem Anwendungsgateway-Subnetz - TCP/443- von virtuellen Computern, die mit einer erforderlichen Asg-Bezeichnung (Application Security Group) und einem Anwendungsgateway-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äts-.

Geheime Verwaltung

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

Als Arbeitsauslastungsteam 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 von Anwendungsgeheimnissen.

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 Prüfliste für die Überprüfung der Kostenoptimierung.

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

Diese Architektur profitiert erheblich von Den Ressourcen der Azure-Zielzone-Plattform. 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.

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