Testvorgehen für Azure-Zielzonen

Hinweis

Dieser Artikel gilt nur für Microsoft Azure und nicht für andere Microsoft Cloud-Angebote wie Microsoft 365 oder Microsoft Dynamics 365.

Einige Organisationen möchten ihre Plattformbereitstellung für Azure-Zielzonen möglicherweise für Azure Policy-Definitionen und -Zuweisungen, die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) sowie benutzerdefinierte Rollen und Zuweisungen usw. testen. Die Tests können mithilfe von Azure Resource Manager-Vorlagen (ARM-Vorlagen), Terraform, Bicep oder manuell über das Azure-Portal abgeschlossen werden. Dieser Leitfaden bietet einen Ansatz, der zum Testen von Änderungen und deren Auswirkungen auf eine Plattformbereitstellung mit Azure-Landezonen verwendet werden kann.

Dieser Artikel kann auch mit dem Leitfaden Plattformautomatisierung und DevOps-relevanter Entwurfsbereich verwendet werden, da er sich auf die Teams und Aufgaben der PlaformOps und zentralen Funktionen bezieht. Darüber hinaus kann sie mit dem Leitfaden in Einführen richtliniengesteuerter Schutzmaßnahmen kombiniert werden, der Techniken zur Einführung von Richtlinienänderungen in einer Azure-Zielzonenbereitstellung enthält.

Diese Anleitung eignet sich am besten für Organisationen mit robusten Änderungsmanagementprozessen, die Änderungen an der Produktionsverwaltungsgruppenhierarchie regeln. Die Canary-Verwaltungsgruppenhierarchie kann individuell zur Erstellung und zum Testen von Bereitstellungen verwendet werden, bevor Sie sie in der Produktionsumgebung bereitstellen.

Hinweis

Der Begriff Canary wird verwendet, um Verwechslungen mit Entwicklungs- oder Testumgebungen zu vermeiden. Dieser Name wird nur zu Beispielzwecken verwendet. Sie können einen beliebigen Namen definieren, der für Ihre Canary-Umgebung mit Azure-Zielzonen geeignet ist.

Ebenso wird der Begriff "Produktionsumgebung/Hierarchie " in diesem Leitfaden verwendet, um auf die Verwaltungsgruppenhierarchie der Azure-Zielzonen zu verweisen, die Ihre Organisation möglicherweise eingerichtet hat, die die Azure-Abonnements und -Ressourcen für Ihre Workloads enthält.

Plattformdefinition

Wichtig

Dieser Leitfaden richtet sich nicht an Entwicklungsumgebungen oder Testumgebungen, die von Anwendungs- oder Dienstbesitzern verwendet werden und als Zielzonen, Workloads, Anwendungen oder Dienste bezeichnet werden. Diese werden innerhalb der Verwaltungsgruppenhierarchie von Azure-Zielzonen der Produktionsumgebung und der zugehörigen Governance (RBAC und Azure Policy) positioniert und verarbeitet.

Anleitungen zu Entwicklung, Tests, Benutzerakzeptanztests (UAT) und Produktionsumgebungen für Anwendungsworkloads und Teams finden Sie unter Verwalten von Anwendungsentwicklungsumgebungen in Azure-Zielzonen.

Dieser Leitfaden gilt nur für Tests und Änderungen auf Plattformebene im Zusammenhang mit Azure-Zielzonen.

Azure-Zielzonen helfen Ihnen, die erforderlichen Azure-Plattformkomponenten zu entwerfen und bereitzustellen, damit Sie Landezonen im großen Maßstab erstellen und operationalisieren können.

Für diesen Artikel und dieses Testvorgehen gelten die folgenden Plattformressourcen:

Produkt oder Dienst	Ressourcenanbieter und Typ
Verwaltungsgruppen	Microsoft.Management/managementGroups
Zuordnung von Verwaltungsgruppenabonnements	Microsoft.Management/managementGroups/subscriptions
Richtliniendefinitionen	Microsoft.Authorization/policyDefinitions
Definitionen von Richtlinieninitiative oder Richtliniensätzen	Microsoft.Authorization/policySetDefinitions
Richtlinienzuweisungen	Microsoft.Authorization/policyAssignments
RBAC-Rollendefinitionen	Microsoft.Authorization/roleDefinitions
Zuweisungen von RBAC-Rollen	Microsoft.Authorization/roleAssignments
Abonnements	Microsoft.Subscription/aliases

Beispielszenarien und Ergebnisse

Ein Beispiel für dieses Szenario ist eine Organisation, die die Auswirkungen und Ergebnisse einer neuen Azure Policy testen möchte, um Ressourcen und Einstellungen in allen Zielzonen zu steuern, und zwar gemäß dem Prinzip des richtliniengesteuerten Governanceentwurfs. Die Organisation möchte diese Änderung nicht direkt in die Produktionsumgebung übernehmen, da sie Bedenken hat, welche Auswirkungen dies haben könnte.

Die Verwendung der Canary-Umgebung zum Testen dieser Plattformänderung ermöglicht es der Organisation, die Auswirkungen und das Ergebnis der geänderten Azure Policy zu überprüfen. Durch diesen Prozess wird sichergestellt, dass die Anforderungen der Organisation erfüllt werden, bevor die Azure Policy in die Produktionsumgebung implementiert wird.

Ein ähnliches Szenario kann eine Änderung der Azure RBAC-Rollenzuweisungen und Microsoft Entra-Gruppenmitgliedschaften sein. Möglicherweise sind bestimmte Tests erforderlich, bevor die Änderungen in der Produktionsumgebung vorgenommen werden.

Wichtig

Dies ist keine gängige Bereitstellungsstrategie oder Muster für die meisten Kunden. Es ist für Bereitstellungen von Azure-Landungszonen nicht zwingend erforderlich.

Abbildung 1: Canary-Verwaltungsgruppenhierarchie.

Wie das Diagramm zeigt, wird die gesamte Verwaltungsgruppenhierarchie der Produktionsumgebung für Azure-Zielzonen unter Tenant Root Group dupliziert. Der Name Canary wird an die Anzeigenamen und IDs der Verwaltungsgruppe angefügt. Die IDs müssen innerhalb eines einzelnen Microsoft Entra-Mandanten eindeutig sein.

Hinweis

Die Anzeigenamen der Canary-Verwaltungsgruppe können mit den Anzeigenamen der Produktionsverwaltungsgruppe identisch sein. Dies kann für Benutzer zu Verwirrungen führen. Aus diesem Grund wird empfohlen, den Namen „canary“ an die Anzeigenamen und deren IDs anzufügen.

Die Canary-Verwaltungsgruppenhierarchie wird dann verwendet, um das Testen der folgenden Ressourcentypen zu vereinfachen:

• Verwaltungsgruppen
  • Abonnementplatzierung
• RBAC
  • Rollen (integriert und benutzerdefiniert)
  • Zuweisungen
• Azure Policy
  • Definitionen (integriert und benutzerdefiniert)
  • Initiativen, auch als Satzdefinitionen bezeichnet
  • Zuweisungen

Was passiert, wenn Sie nicht die Canary-Verwaltungsgruppenhierarchie bereitstellen möchten?

Wenn Sie die Canary-Verwaltungsgruppenhierarchie nicht bereitstellen möchten, können Sie Plattformressourcen innerhalb der Produktionsumgebungshierarchie testen, indem Sie Sandkastenabonnements verwenden, wie im Diagramm dargestellt.

Abbildung 2: Verwaltungsgruppenhierarchie für Azure-Zielzonen mit hervorgehobenen Sandboxes

Um Azure Policy und RBAC in diesem Szenario zu testen, benötigen Sie ein einzelnes Azure-Abonnement mit der RBAC -Rolle „Besitzer“, die der Identität zugewiesen ist, für die Sie die Tests durchführen möchten, z. B. Benutzerkonto, Dienstprinzipal oder verwaltete Dienstidentität. Mit dieser Konfiguration können Sie nur Azure-Richtliniendefinitionen und -zuordnungen im Bereich des Sandkastenabonnements erstellen, zuweisen und korrigieren.

Dieser Sandboxansatz kann auch für RBAC -Tests innerhalb des Abonnements verwendet werden, z. B. wenn Sie eine neue benutzerdefinierte RBAC -Rolle entwickeln, um Berechtigungen für einen bestimmten Anwendungsfall zu erteilen. Diese Tests können alle im Sandboxabonnement durchgeführt und getestet werden, bevor Sie Rollen weiter oben in der Hierarchie erstellen und zuweisen.

Ein Vorteil dieses Ansatzes ist, dass die Sandboxabonnements für den Zeitraum verwendet werden können, für den sie erforderlich sind, und dann aus der Umgebung gelöscht werden können.

Mit diesem Ansatz können Sie jedoch die Vererbung von RBAC- und Azure-Richtlinien aus der Verwaltungsgruppenhierarchie testen.

Implementierungsleitfaden

Im Folgenden finden Sie einen Leitfaden zur Implementierung und Verwendung der Canary-Verwaltungsgruppenhierarchie für Azure-Zielzonen zusammen mit einer Verwaltungsgruppenhierarchie in einer Produktionsumgebung für Azure-Zielzonen.

Warnung

Wenn Sie das Portal verwenden, um Ihre Azure-Zielzonenumgebung heute bereitzustellen und zu verwalten, kann es schwierig sein, den Canary-Ansatz effizient zu übernehmen und zu verwenden, da sowohl die Produktions- als auch die Canary-Umgebung häufig nicht synchron sind und daher keine replikatähnliche Hierarchie und Produktionsumgebung bereitgestellt werden.

Erwägen Sie, zu einem Bereitstellungsansatz für Azure-Zielzonen zu wechseln, der Infrastructure as Code (IaC) nutzt, wie oben aufgeführt, wenn Sie sich in diesem Szenario befinden. Behalten Sie andernfalls die potenziellen Risiken von Konfigurationsdrift zwischen Canary-Umgebung und Produktionsumgebung im Hinterkopf, und lassen Sie Vorsicht walten. Weitere Informationen finden Sie unter Verwenden von IaC zum Aktualisieren von Azure-Landezonen.

1. Verwenden Sie separate Microsoft Entra-Dienstprinzipale (SPNs) oder verwaltete Identitäten (MIs), denen Berechtigungen für die relevante Verwaltungsgruppenhierarchie von Azure-Zielzonen in der Produktions- oder der Canary-Umgebung erteilt wurden.
   • Dieser Leitfaden folgt dem Prinzip der geringsten Rechte (principle of least privilege; PoLP).
2. Verwenden Sie separate Ordner in Git-Repositorys, Branches oder Repositorys, um die Infrastructure-as-Code (IaC) für Azure-Zielzonenbereitstellungen der Produktionsumgebung und der Canary-Umgebung zu speichern.
   • Verwenden Sie je nach bereitgestellter Hierarchie die relevanten Microsoft Entra-Dienstprinzipale (SPNs) oder verwalteten Identitäten (MIs) als Teil der CI/CD-Pipelines.
3. Implementieren Sie Git-Branch- oder Sicherheitsrichtlinien für die Canary-Umgebung, wie Sie sie für die Produktionsumgebung eingerichtet haben.
   • Ziehen Sie in Betracht, die Anzahl der genehmigenden Personen sowie die Fail-Fast-Überprüfungen für die Canary-Umgebung zu reduzieren.
4. Verwenden Sie dieselben Azure Pipelines oder GitHub-Aktionen, die Umgebungsvariablen verwenden, um die bereitgestellte Hierarchie zu ändern. Eine weitere Möglichkeit besteht im Klonen der Pipelines und Ändern der hart codierten Einstellungen, um zu definieren, welche Hierarchie bereitgestellt wird.
   • Wenn Sie Azure Pipelines DevOps-Vorlagen oder GitHub-Aktionsworkflowvorlagen verwenden, können Sie das Prinzip "Nicht wiederholen" (DRY) einhalten.
5. Verfügen Sie über eine Reihe von Canary-Abonnements unter einem separaten Abrechnungskonto, etwa einem EA-Konto (Enterprise Agreement) oder einem MCA-Rechnungsabschnitt (Microsoft Customer Agreement), die bei Bedarf innerhalb der Hierarchie der Canary-Verwaltungsgruppen verschoben werden können.
   • Es kann von Vorteil sein, dass eine Reihe von Ressourcen immer in den Canary-Umgebungsabonnements bereitgestellt wird, um Tests und Validierung von Änderungen an der Canaryumgebung zu beschleunigen.
6. Sie verfügen über eine Reihe von Beispielarchitekturen für Anwendungsworkloads, die Sie in den Canary-Abonnements in der Canary-Umgebung bereitstellen können, um die Änderungen der Azure-Richtlinien und von RBAC zu testen. Auf diese Weise können Sie die Änderungen überprüfen, bevor Sie die Änderungen für die Produktion bereitstellen und höherstufen.
   • Diese Beispielworkloads können mit den gleichen IaC-Vorlagen bereitgestellt werden, die zum Bereitstellen der Produktionsanwendungsworkloads verwendet werden. Dadurch können Sie sicherstellen, dass die Canary-Testumgebung mit der Produktionsumgebung synchronisiert ist und dass die von Ihnen getesteten Änderungen gültig und in der Produktionsumgebung anwendbar sind.
   • Sie sollten die Beispielworkloads kontinuierlich überprüfen und aktualisieren, um sicherzustellen, dass sie relevant und auf dem neuesten Stand mit den neuesten Architektur- und Entwurfsmustern in Ihrer Organisation sind.
   • Wenn Sie Referenzarchitekturen für Ihre Anwendungsteams bereitstellen, sollten Sie diese auch in der Canary-Umgebung bereitstellen. Auf diese Weise können Sie die Änderungen anhand der Referenzarchitekturen überprüfen und sicherstellen, dass sie auf die Produktionsumgebung anwendbar sind.
7. Senden Sie alle Azure-Aktivitätsprotokolle für alle Azure-Abonnements, einschließlich aller Canary-Umgebungsabonnements, gemäß den Entwurfsempfehlungen für Azure-Zielzonen an den Azure Log Analytics-Arbeitsbereich der Produktionsumgebung.
   • Auf diese Weise können Ihre Sicherheits- und Betriebsteams die Canaryumgebung auf Änderungen oder Probleme überwachen, die sich aus den Tests der Azure-Richtlinie und der RBAC-Änderungen an der Produktionsumgebung ergeben können.

Tipp

Wenn Sie bereits Azure-Zielzonen in der Produktionsumgebung bereitgestellt haben und jetzt eine Canary-Umgebung hinzufügen möchten, klonen Sie ggf. Ihre aktuelle Bereitstellung der Produktionsumgebungshierarchie, und versehen Sie die Namen der Ressourcen mit einem Präfix, das Ihrem Canary-Benennungsschema entspricht.

Damit stellen Sie sicher, dass die Elemente, die Sie für die Canary-Umgebung bereitstellen, von Anfang an mit der Produktionsumgebung synchron sind. Dies ist einfach zu erreichen, wenn Sie ein IaC-Tool zusammen mit einem Git-Repository verwenden.

Verwenden eines einzelnen Microsoft Entra-Mandanten

Folgende Aspekte sind beim Verwenden eines einzelnen Microsoft Entra-Mandanten zu berücksichtigen:

• Die Verwendung eines einzelnen Mandanten entspricht den Entwurfsempfehlungen für Azure-Zielzonen Microsoft Entra-Mandanten.
  • In einem einzelnen Microsoft Entra-Mandanten können Sie die verschiedenen Microsoft Entra-Gruppen sowohl für Produktionsumgebungen als auch für Canary-Umgebungen für Azure-Zielzonen verwenden, bei denen die gleichen Benutzenden der entsprechenden Verwaltungsgruppenhierarchie zugewiesen sind.
• Erhöhte oder duplizierte Microsoft Entra ID-Lizenzierungskosten aufgrund mehrerer Identitäten in verschiedenen Microsoft Entra-Mandanten Dies ist besonders für Kunden relevant, die Microsoft Entra ID P1- oder P2-Features verwenden.
• RBAC-Änderungen werden sowohl in Canary- als auch in Produktionsumgebungen komplexer, da die Benutzenden und Gruppen in beiden Microsoft Entra-Mandanten mit höherer Wahrscheinlichkeit nicht identisch sind.
  • Denken Sie daran, dass die Benutzer- und Gruppen-IDs in Microsoft Entra-Mandanten nicht identisch sind, da sie global eindeutig sind.
• Reduziert die Komplexität und den Verwaltungsmehraufwand, der durch das Verwalten mehrerer Microsoft Entra-Mandanten verursacht wird.
  • Privilegierte Benutzende, die weiterhin Zugriff benötigen und sich bei separaten Mandanten anmelden müssen, um Tests durchzuführen, könnten z. B. versehentlich Änderungen an der Produktionsumgebung anstelle der Canary-Umgebung vornehmen.
• Verringert die Wahrscheinlichkeit von Konfigurationsdrifts und Bereitstellungsfehlern.
• Es ist keine zusätzliche Sicherheit erforderlich, und es müssen keine Notfall- oder Notfallzugriffsprozesse erstellt werden.
• Der Aufwand und die Zeit für das Implementieren von Änderungen an der Bereitstellung von Azure-Zielzonen wird reduziert.

Nächste Schritte

Wenn Sie eine Canary-Umgebung eingerichtet haben, können Sie mit dem Testen der Azure Policy- und RBAC-Änderungen beginnen, bevor Sie sie in Ihrer Verwaltungsgruppenhierarchie für Azure-Zielzonen in der Produktion bereitstellen.

Nachdem Sie die Änderungen an Azure-Richtlinien in der Canary-Umgebung getestet haben, können Sie sie in die Produktionsumgebung höherstufen. Dazu nutzen Sie denselben Ansatz wie im Leitfaden Einführen richtliniengesteuerter Schutzmaßnahmen. Dazu wird das Feature „Erzwingungsmodus“ für Richtlinienzuweisungen verwendet. Mithilfe des in diesem Leitfaden dokumentierten Ansatzes können Sie eine zusätzliche Testphase durchlaufen, bevor Sie die Azure-Richtlinie in der Produktionsumgebung in der gewünschten Wirkung erzwingen, wodurch Sie Vertrauen in die von Ihnen vorgenommenen Azure-Richtlinienänderungen aufbauen können.

Sie können auch Sandkastenumgebungen für Ihre Anwendungsteams überprüfen, um sie für die Entwicklung und das Testen ihrer Workloads zu verwenden. Dies ist ein separates Konzept zur Canary-Umgebung und wird verwendet, um eine sichere Umgebung für Anwendungsteams bereitzustellen, damit sie ihre Workloads entwickeln und testen können, bevor diese in die Produktion bereitgestellt werden.

Implementieren von Sandboxumgebungen für Zielzonen