Teststrategie für Azure Landing Zone

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 möglicherweise die Bereitstellung von Azure Policy-Definitionen und -Zuweisungen sowie benutzerdefinierten Rollen und Zuweisungen für die rollenbasierte Zugriffssteuerung (RBAC) ihres Plattform-Landing-Zone-Accelerators testen usw. 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, mit dem sich Änderungen und ihre Auswirkungen auf die Bereitstellung eines Plattform-Landing-Zone-Accelerators testen lassen.

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 es mit der Anleitung in Richtliniengesteuerte Schutzmaßnahmen einführen kombiniert werden, die Techniken für die Einführung von Richtlinienänderungen bei der Bereitstellung einer Plattform-Zielzone beschreibt.

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 jeden Namen definieren, den Sie als geeignet für Ihre Canary-Azure Landungszone-Umgebung festlegen.

Ebenso wird in diesem Leitfaden der Begriff Produktionsumgebung/Hierarchie verwendet, um auf die Verwaltungsgruppenhierarchie der Plattform-Landingzone zu verweisen, die in Ihrer Organisation möglicherweise vorhanden ist und 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 Managementgruppenhierarchie der Azure-Landing-Zones in der Produktionsumgebung sowie der zugehörigen Governance-Vorgaben (RBAC und Azure Policy) eingeordnet und verwaltet.

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

Dieser Leitfaden richtet sich nur an Tests auf Plattformebene und Änderungen im Kontext einer Azure Zielzone.

Azure Anleitung zur Zielzone hilft 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. Für die Bereitstellung eines Beschleunigers für die Plattform-Landing-Zone ist dies nicht zwingend erforderlich.

Diagramm der Verwaltungsgruppenhierarchie mit dem Canary-Umgebungstestvorgehen

Abbildung 1: Canary-Verwaltungsgruppenhierarchie.

Wie das Diagramm zeigt, wird die gesamte Produktionsverwaltungsgruppenhierarchie der Azure Landing Zone unter Tenant Root Group dupliziert. Der Name Canary wird an die Anzeigenamen und IDs der Verwaltungsgruppe angefügt. Die Verwaltungsgruppen-IDs müssen innerhalb eines einzelnen Microsoft Entra Mandanten eindeutig sein. Der Mandant behandelt Verwaltungsgruppen-IDs als autoritative Bezeichner, sodass sie für den gesamten Mandanten eindeutig sein müssen. Sie können die Anzeigenamen der Managementgruppen mit der Hierarchie der Produktionsmanagementgruppe abstimmen. Fügen Sie den Anzeigenamen zudem eine Unterscheidungsbezeichnung hinzu, damit Benutzer beim Navigieren in der Verwaltungsgruppe die Canary-Hierarchie visuell von der Produktionsumgebung unterscheiden können.

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

  • Verwaltungsgruppen
    • Abonnementplatzierung
  • RBAC
    • Rollen (integriert und benutzerdefiniert)
    • Zuweisungen
  • Azure-Richtlinie
    • 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.

Diagramm des Testvorgehens, das Sandboxes verwendet.

Abbildung 2: Hierarchie der Azure-Verwaltungsgruppen für Landingzones mit Hervorhebung der 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

Nachfolgend finden Sie eine Anleitung zur Implementierung und Verwendung der Hierarchie der Canary-Verwaltungsgruppen für eine Azure-Landingzone neben der Verwaltungsgruppenhierarchie einer Azure-Landingzone für eine Produktionsumgebung.

Warnung

Wenn Sie das Portal nutzen, um Ihre Platform-Zielzonen Beschleunigungsumgebung bereitzustellen und zu verwalten, kann sich die effiziente Einführung und Nutzung des Canary-Ansatzes als schwierig erweisen: Es besteht ein hohes Risiko, dass Produktions- und Canary-Umgebung häufig auseinanderdriften und somit keine zur Produktionsumgebung analoge Hierarchie und Umgebung mehr bieten.

Erwägen Sie den Wechsel zu einem Bereitstellungsansatz für Infrastruktur als Code (IaC) für die Bereitstellung Ihres Plattform-Zielzonenbeschleunigers, 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", um Ihre Azure Zielzone zu aktualisieren.

  1. Verwenden Sie separate Microsoft Entra-Dienstprinzipale (SPNs) oder verwaltete Identitäten (MIs), denen Berechtigungen für die Managementgruppenhierarchie der Azure Landing Zone der entsprechenden Produktions- oder Canary-Umgebung zugewiesen wurden.
    • Dieser Leitfaden folgt dem Prinzip der geringsten Rechte (principle of least privilege; PoLP).
  2. Verwenden Sie separate Ordner innerhalb eines Git-Repositorys, Verzweigungen oder separate Repositorys, um die IaC für die Bereitstellung der Azure Zielzonen in der Produktions- und der Canary-Umgebung zu verwalten.
    • 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.
  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-Kundenvereinbarung), 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. Halten Sie eine Reihe von Beispiel-Workloadarchitekturen bereit, die Sie in den Canary-Abonnements in der Canary-Umgebung bereitstellen können, um Änderungen an Azure Policy und 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 Beispielarbeitslasten können mit den gleichen IaC-Vorlagen bereitgestellt werden, die zum Bereitstellen der Produktionsworkloads 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 Workload-Teams 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 sämtliche Azure-Abonnements, einschließlich aller Abonnements von Canary-Umgebungen, gemäß den Designempfehlungen für Azure Landing Zones 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 eine Azure-Landingzone in der Produktion bereitgestellt haben und nun eine Canary-Umgebung hinzufügen möchten, sollten Sie erwägen, Ihre aktuelle Bereitstellung der Hierarchie der Produktionsumgebung zu klonen und die Ressourcennamen so anzupassen, dass ihnen Ihr Canary-Benennungsschema als Präfix vorangestellt wird.

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 Azure Landing Zone-Entwurfsempfehlungen für Microsoft Entra-Mandanten.
    • In einem einzelnen Microsoft Entra-Mandanten können Sie die verschiedenen Microsoft Entra-Gruppen sowohl für Produktions- als auch für Canary-Azure-Landing-Zone-Umgebungen verwenden, wobei dieselben Benutzer ihrer jeweiligen relevanten 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.
  • Reduziert Reibungsverluste und die für die Implementierung von Änderungen an der Bereitstellung der Azure Landing Zone erforderliche Zeit.

Nächste Schritte

Sobald Sie über eine Canary-Umgebung verfügen, können Sie die Änderungen an Azure Policy und RBAC testen, bevor Sie sie in der Verwaltungsgruppenhierarchie Ihrer produktiven Azure Landing Zone 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 Sandbox-Umgebungen prüfen, die Ihren Workload-Teams für die Entwicklung und das Testen ihrer Workloads zur Verfügung stehen. Dies ist ein von der Canary-Umgebung getrenntes Konzept und wird verwendet, um Workload-Teams eine sichere Umgebung zur Entwicklung und zum Testen ihrer Workloads bereitzustellen, bevor diese in der Produktionsumgebung bereitgestellt werden.

Implementieren von Sandboxumgebungen für Zielzonen

  • Zuletzt aktualisiert um