Anpassen der Architektur der Azure-Zielzonen an die Anforderungen

Im Rahmen der Azure-Zielzone-Anleitung stehen mehrere Referenzimplementierungsoptionen zur Verfügung:

• Azure-Zielzone mit Azure Virtual WAN
• Azure-Zielzone mit herkömmlichem Hub und Spoke
• Azure-Zielzonen-Foundation
• Azure-Zielzone für kleine Unternehmen

Diese Optionen können helfen, Ihrem Unternehmen einen schnellen Einstieg zu ermöglichen, indem sie Konfigurationen verwenden, die die konzeptionelle Architektur der Azure-Zielzone und die bewährten Methoden in den Entwurfsbereichen bereitstellen.

Die Referenzimplementierungen basieren auf den bewährten Methoden und Erkenntnissen von Microsoft Teams aus Einsätzen mit Kunden und Partnern. Dieses Wissen ist die „80“ der 80/20-Regel. Die verschiedenen Implementierungen beziehen Stellung zu technischen Entscheidungen, die Teil des Architekturentwurfsprozesses sind.

Da nicht alle Anwendungsfälle gleich sind, können nicht alle Organisationen einen Implementierungsansatz genau so verwenden, wie er gedacht war. Sie müssen die Überlegungen verstehen, wenn eine Anforderung für das Anpassen identifiziert wird.

Was ist ein „Zielzonenarchetyp“ in Azure-Zielzonen?

Ein Archetyp für eine Zielzone beschreibt, was erfüllt sein muss, damit eine Zielzone (Azure-Abonnement) die erwartete Umgebung und die Complianceanforderungen in einem bestimmten Umfang erfüllen kann. Beispiele:

• Azure Policy-Zuweisungen.
• RBAC-Zuweisungen (rollenbasierte Zugriffssteuerung).
• Zentral verwaltete Ressourcen, wie z. B. Netzwerke.

Aufgrund der Art und Weise, wie die Richtlinienvererbung in Azure funktioniert, betrachten Sie jede Verwaltungsgruppe in der Ressourcenhierarchie als Beitrag zur endgültigen Ausgabe des Zielzonenarchetyps. Überlegen Sie, was auf den oberen Ebenen in der Ressourcenhierarchie angewendet wird, wenn Sie die unteren Ebenen entwerfen.

Es gibt eine enge Beziehung zwischen Verwaltungsgruppen und Zielzonenarchetypen, aber eine Verwaltungsgruppe allein ist noch kein Zielzonenarchetyp. Stattdessen ist sie Teil des Frameworks, das Sie verwenden, um jeden der Zielzonenarchetypen in Ihrer Umgebung zu implementieren.

Sie können diese Beziehung in der konzeptionellen Architektur der Azure-Zielzone sehen. Richtlinienzuweisungen werden in der Zwischenstammverwaltungsgruppe erstellt, z. B. Contoso, für Einstellungen, die für alle Workloads gelten müssen. Weitere Richtlinienzuweisungen werden auf niedrigeren Ebenen der Hierarchie für spezifischere Anforderungen erstellt.

Die Platzierung des Abonnements innerhalb der Verwaltungsgruppenhierarchie bestimmt die daraus resultierende Festlegung von Azure-Richtlinien und Zugriffssteuerungen (IAM), die auf diese bestimmte Zielzone (Azure-Abonnement) vererbt, angewendet und durchgesetzt werden.

Um sicherzustellen, dass eine Zielzone über die erforderlichen, zentral verwalteten Ressourcen verfügt, sind möglicherweise zusätzliche Prozesse und Tools erforderlich. Beispiele hierfür sind:

• Diagnoseeinstellungen zum Senden von Aktivitätsprotokolldaten an einen Log Analytics-Arbeitsbereich.
• Fortlaufende Exporteinstellungen für Microsoft Defender für Cloud.
• Virtuelles Netzwerk mit verwalteten IP-Adressräumen für Anwendungsworkloads.
• Verknüpfen von virtuellen Netzwerken mit verteiltem Denial of Service (DDoS)-Netzwerkschutz.

Hinweis

In den Azure-Referenzzonenreferenzimplementierungen werden Azure-Richtlinien mit DeployIfNotExists und ModifyEffekten verwendet, um die Bereitstellung einiger der vorherigen Ressourcen zu erreichen. Sie folgen dem Designprinzip der richtliniengesteuerten Governance.

Weitere Informationen finden Sie unter Einführen richtliniengesteuerter Schutzmaßnahmen.

Integrierte Archetypen für die konzeptionelle Architektur der Azure-Zielzone

Die konzeptionelle Architektur umfasst Beispiel-Zielzonen-Archetypen für Anwendungslasten wie Corp und Online. Diese Archetypen gelten möglicherweise für Ihre Organisation und erfüllen Ihre Anforderungen. Möglicherweise möchten Sie Änderungen an diesen Archetypen vornehmen oder neue erstellen. Ihre Entscheidung hängt von den Anforderungen und Anforderungen Ihrer Organisation ab.

Tipp

Überprüfen Sie hier die Archetypen der Zielzonen im Beschleuniger für die Azure-Zielzone: Verwaltungsgruppen im Beschleuniger für die Azure-Zielzone.

Möglicherweise möchten Sie auch an anderer Stelle in der Ressourcenhierarchie Änderungen vornehmen. Wenn Sie die Hierarchie für die Implementierung von Azure-Zielzonen für Ihr Unternehmen planen, befolgen Sie die Richtlinien in den Entwurfsbereichen.

Die folgenden Beispiele für die Zielzone aus der konzeptionellen Architektur helfen Ihnen, ihren Zweck und die beabsichtigte Verwendung zu verstehen:

Zielzonenarchetyp (Verwaltungsgruppe)	Zweck oder Verwendung
Corp	Die dedizierte Verwaltungsgruppe für Unternehmenszielzonen. Diese Gruppe ist für Workloads gedacht, die Konnektivität oder Hybridkonnektivität zum Unternehmensnetzwerk über den Hub im Konnektivitätsabonnement erfordern.
Online	Die dedizierte Verwaltungsgruppe für Onlinezielzonen. Diese Gruppe ist für Workloads gedacht, die möglicherweise eine direkte eingehende/ausgehende Internetverbindung erfordern, oder für Workloads, die möglicherweise kein virtuelles Netzwerk erfordern.
Sandbox	Die dedizierte Verwaltungsgruppe für Abonnements, die in Organisationen nur für Tests und Exploration verwendet werden. Diese Abonnements werden sicher von den Unternehmens- und Onlinezielzonen getrennt. Sandboxes verfügen auch über weniger restriktive Richtlinien, die das Testen, Erkunden und Konfigurieren von Azure-Diensten ermöglichen.

Szenarien, in denen die Anpassung erforderlich sein kann

Wie bereits erwähnt, stellen wir in Konzeptionelle Architektur der Azure-Zielzone gängige Zielzonenarchetypen vor. Das sind corp und online. Diese Archetypen sind nicht behoben und sind nicht die einzigen zulässigen Zielzonen-Archetypen für Anwendungslasten. Möglicherweise müssen Sie Zielzonen-Archetypen an Ihre Bedürfnisse und Anforderungen anpassen.

Bevor Sie Zielzonen-Archetypen anpassen, ist es wichtig, die Konzepte zu verstehen und auch den Bereich der Hierarchie zu visualisieren, den wir Ihnen vorschlagen. Das folgende Diagramm zeigt die Standardhierarchie der konzeptionellen Architektur der Azure-Zielzone.

Zwei Bereiche der Hierarchie werden hervorgehoben. Eine befindet sich unterhalb der Zielzonen, und der andere befindet sich unter der Plattform.

Anpassen der Archetypen von Anwendungszielzonen

Beachten Sie den Bereich, der unter der Verwaltungsgruppe Zielzonen in Blau hervorgehoben ist. Es ist der am häufigsten verwendete und sicherste Ort in der Hierarchie, um mehr Archetypen hinzuzufügen, um neue oder mehr Anforderungen zu erfüllen, die nicht mehr Richtlinienzuweisungen zu einem vorhandenen Archetyp mithilfe der vorhandenen Hierarchie hinzugefügt werden können.

Sie können beispielsweise eine neue Anforderung haben, eine Reihe von Anwendungslasten zu hosten, die die Complianceanforderungen der Zahlungskartenindustrie (PCI) erfüllen müssen. Diese neue Anforderung muss jedoch nicht auf alle Workloads in Ihrem gesamten Besitz angewendet werden.

Es gibt eine einfache und sichere Möglichkeit, diese neue Anforderung zu erfüllen. Erstellen Sie eine neue Verwaltungsgruppe namens PCI unterhalb der Verwaltungsgruppe Landing Zones in der Hierarchie. Sie können der neuen PCI-Verwaltungsgruppe weitere Richtlinien wie die Microsoft Defender für Cloud initiative für behördliche Compliancerichtlinien für PCI v3.2.1:2018 zuweisen. Diese Aktion bildet einen neuen Archetyp.

Jetzt können Sie neue oder vorhandene Azure-Abonnements in die neue PCI-Verwaltungsgruppe verschieben, um die erforderlichen Richtlinien zu erben und den neuen Archetyp zu bilden.

Ein weiteres Beispiel ist Microsoft Cloud for Sovereignty, das Verwaltungsgruppen für vertrauliche Datenverarbeitung hinzufügt und für den Einsatz in regulierten Branchen ausgerichtet ist. Microsoft Cloud for Sovereignty bietet Tools, Anleitungen und Schutzmaßnahmen für die Öffentliche Cloud-Einführung mit entsprechenden Souveränitätskontrollen.

Tipp

Sie müssen wissen, was sie berücksichtigen und was passiert, wenn Sie Azure-Abonnements zwischen Verwaltungsgruppen in Bezug auf RBAC und Azure Policy verschieben. Weitere Informationen finden Sie unter Übertragen vorhandener Azure-Umgebungen auf die konzeptionelle Architektur der Azure-Zielzone.

Angepasste Archetypen von Zielzonen für Plattformen

Möglicherweise möchten Sie auch den Bereich anpassen, der in Orange unter der Plattformverwaltungsgruppe hervorgehoben ist. Die Zonen in diesem Bereich werden als Plattformzielzonen bezeichnet.

Beispielsweise verfügen Sie möglicherweise über ein dediziertes SOC-Team, das einen eigenen Archetyp benötigt, um seine Workloads zu hosten. Diese Workloads müssen Azure Policy und RBAC-Zuordnungsanforderungen erfüllen, die sich von denen der Verwaltungsverwaltungsgruppe unterscheiden.

Erstellen Sie eine neue Sicherheitsverwaltungsgruppe unterhalb der Plattformverwaltungsgruppe in der Hierarchie. Sie können ihm die erforderlichen Azure Policy und RBAC-Zuordnungen zuweisen.

Jetzt können Sie neue oder vorhandene Azure-Abonnements in die neue Sicherheits-Verwaltungsgruppe verschieben, um die erforderlichen Richtlinien zu erben und den neuen Archetyp zu bilden.

Beispiel für eine angepasste Azure-Zielzonenhierarchie

Das folgende Diagramm zeigt eine maßgeschneiderte Azure-Zielzonenhierarchie. Es verwendet Beispiele aus dem vorherigen Diagramm.

Zu berücksichtigende Punkte

Berücksichtigen Sie die folgenden Punkte, wenn Sie überlegen, wie Sie Ihre Implementierung von Azure-Zielzonen-Archetypen in der Hierarchie anpassen:

• Das Anpassen der Hierarchie ist nicht obligatorisch. Die standardmäßigen Archetypen und Hierarchien, die wir bereitstellen, sind für die meisten Szenarien geeignet.

• Erstellen Sie Ihre Organisationshierarchie, Teams oder Abteilungen nicht in Archetypen neu.

• Versuchen Sie immer, auf den bestehenden Archetypen und der Hierarchie aufzubauen, um neue Anforderungen zu erfüllen.

• Erstellen Sie neue Archetypen nur, wenn sie wirklich benötigt werden.

  Beispielsweise ist eine neue Complianceanforderung (z. B. PCI) nur für eine Teilmenge von Anwendungen erforderlich und muss nicht für alle Workloads gelten.

• Erstellen Sie neue Archetypen nur in den hervorgehobenen Bereichen in den obigen Diagrammen.

• Vermeiden Sie es, über eine Hierarchietiefe von vier Ebenen hinauszugehen, um Komplexität und unnötige Ausschlüsse zu vermeiden. Erweitern Sie Archetypen horizontal statt vertikal in der Hierarchie.

• Erstellen Sie keine Archetypen für Umgebungen, wie z. B. Entwicklung, Test, Produktion.

  Weitere Informationen finden Sie unter Wie gehen wir in der konzeptionellen Architektur der Azure-Zielzonen für Workloads mit „Dev/Test/Produktion“ um?

• Wenn Sie aus einer Brownfield-Umgebung kommen oder einen Ansatz zum Hosten von Abonnements in der Landing Zones Management Group mit Richtlinien im Erzwingungsmodus „nur überwachen“ suchen, überprüfen Sie das Szenario: Übergang einer Umgebung durch Duplizieren einer Zielzonenverwaltungsgruppe