Freigeben über

Testvorgehen für Azure-Zielzonen

  • Artikel

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 per Automatisierung mithilfe von ARM-Vorlagen (Azure Resource Manager), AzOps, Terraform, Bicep oder manuell über das Azure-Portal ausgeführt werden. In diesem Leitfaden erfahren Sie, wie Sie Änderungen und deren Auswirkungen auf die Plattformbereitstellung für Azure-Zielzonen testen können.

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.

Dieser Leitfaden eignet sich am besten für Organisationen mit belastungsfähigen Change Management-Prozessen, die Änderungen an der Verwaltungsgruppenhierarchie der Produktionsumgebung vornehmen. 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.

Entsprechend bezieht sich der Begriff Produktionsumgebung in diesem Leitfaden auf die Verwaltungsgruppenhierarchie Ihrer Organisation, die die Azure-Abonnements und -Ressourcen für Ihre Workloads enthält.

Plattformdefinition

Wichtig

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

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

Die Enterprise-Staffelung hilft Ihnen, die erforderlichen Komponenten der Azure-Plattform zu entwerfen und bereitzustellen, damit Sie die entsprechenden Zielzonen bedarfsgerecht 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 Definitionen von Richtliniensätzen Microsoft.Authorization/policySetDefinitions
Richtlinienzuweisungen Microsoft.Authorization/policyAssignments
Definition RBAC -Rollen 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 für die meisten Kunden kein Bereitstellungsansatz oder -weg, den diese normalerweise nutzen. Es ist für Bereitstellungen von Azure-Landungszonen nicht zwingend erforderlich.

Diagram of the management group hierarchy with the canary environment testing approach.

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-Umgebungsverwaltungsgruppe können mit den Anzeigenamen der Verwaltungsgruppe der Produktionsumgebung 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 anfügen.

Die Verwaltungsgruppenhierarchie der Canary-Umgebung 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 gesamte Verwaltungsgruppenhierarchie der Canary-Umgebung bereitstellen möchten?

Wenn Sie nicht die gesamte Verwaltungsgruppenhierarchie der Canary-Umgebung bereitstellen möchten, können Sie Plattformressourcen innerhalb der Produktionsumgebungshierarchie testen, indem Sie Sandboxabonnements verwenden (siehe Diagramm).

Diagram of the testing approach that uses sandboxes.

Abbildung 2: Unternehmensweise Verwaltungsgruppenhierarchie mit Hervorhebung von 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 Definitionen und Zuweisungen von Azure Policy im Bereich des Sandboxabonnements 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-Policies aus der Verwaltungsgruppenhierarchie testen.

Verwenden eines einzelnen Microsoft Entra-Mandanten

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

  • Folgt den Designempfehlungen auf Unternehmensebene für Microsoft Entra-Mandanten
  • Gemäß dem Leitfaden Bewährte Methoden für Cloud Adoption Framework von Azure: Standardisieren eines einzelnen Verzeichnisses und einer einzelnen Identität sind in den meisten Fällen einzelne Microsoft Entra-Mandanten die bewährte Methode.
    • 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 Benutzer*innen der entsprechenden Verwaltungsgruppenhierarchie innerhalb des gleichen Microsoft Entra-Mandanten zugewiesen sind.
  • Erhöhte oder duplizierte Microsoft Entra ID-Lizenzierungskosten aufgrund mehrerer Identitäten in verschiedenen Microsoft Entra-Mandanten
    • Dieser Punkt ist besonders für Kunden relevant, die Microsoft Entra ID P1- oder P2-Features verwenden.
  • RBAC-Änderungen werden sowohl in Canary-Umgebungen als auch in Produktionsumgebungen komplexer, da die Benutzer*innen und Gruppen in beiden Microsoft Entra-Mandanten mit höherer Wahrscheinlichkeit nicht identisch sind.
    • Darüber hinaus sind die Benutzer- und Gruppen-IDs für alle Microsoft Entra-Mandanten nicht identisch, da sie global eindeutig sind.
  • Reduziert die Komplexität und den Verwaltungsmehraufwand, der durch das Verwalten mehrerer Microsoft Entra-Mandanten verursacht wird.
    • Privilegierte Benutzer, die den Zugriff behalten und sich bei separaten Mandanten anmelden müssen, um Tests durchzuführen, nehmen ggf. versehentliche Änderungen an der Produktionsumgebung vor, anstatt Änderungen an der Canary-Umgebung vorzunehmen und umgekehrt.
  • 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 die Probleme und die Zeit, die erforderlich ist, um Änderungen an der Bereitstellung von Azure-Zielzonen zu implementieren.

Implementierungsleitfaden

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

Warnung

Wenn Sie heutzutage das Portal verwenden, um Ihre Azure-Zielzonenumgebung bereitzustellen und zu verwalten, ist es möglicherweise schwierig, den Canary-Ansatz effizient einzuführen und zu nutzen, da die Gefahr besteht, dass die Produktionsumgebung und die Canary-Umgebung häufig nicht synchron sind und somit keine replikatähnliche Produktionshierarchie und -umgebung zur Verfügung steht.

In einem derartigen Szenario empfiehlt es sich gegebenenfalls, zu einer Infrastructure-as-Code-Bereitstellung für Azure-Zielzonen zu wechseln. Behalten Sie andernfalls die potenziellen Risiken von Konfigurationsdrift zwischen Canary-Umgebung und Produktionsumgebung im Hinterkopf, und lassen Sie Vorsicht walten.

  1. Verwenden Sie separate Microsoft Entra-Dienstprinzipale (SPNs) oder verwaltete Dienstidentitäten (Managed Service Identities, MSIs), denen Berechtigungen für die relevante Produktionsumgebung oder die Verwaltungsgruppenhierarchie der Canary-Umgebung erteilt wurden.
    • Dieser Leitfaden folgt dem Prinzip der geringsten Rechte (principle of least privilege; PoLP).
  2. Verwenden Sie separate Ordner in einem Git-Repository bzw. Branches oder Repositorys, um die Infrastructure-as-Code für Azure-Zielzonenbereitstellungen der Produktionsumgebung und der Canary-Umgebung zu speichern.
    • Verwenden der relevanten Microsoft Entra-Dienstprinzipale (SPNs) oder verwalteten Dienstidentitäten (Managed Service Identities, MSIs) als Teil der CI/CD-Pipelines je nach bereitgestellter Hierarchie
  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 Überprüfungen zu reduzieren, ob die Canary-Umgebung schnell ausfällt.
  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. Sie verfügen über eine Reihe von Canary-Abonnements in einer separaten EA-Abteilung und einem separaten Konto, die bei Bedarf in die Hierarchie der Canary-Verwaltungsgruppen verschoben werden können.
    • Es kann vorteilhaft sein, in den Canary-Umgebungsabonnements stets eine Vielzahl von Ressourcen bereitzustellen.
    • Es kann hilfreich sein, Infrastructure-as-Code-Vorlagen wie ARM-Vorlagen, Bicep oder Terraform zu verwenden, die mehrere Ressourcen erstellen, die die Überprüfung von Änderungen in der Canary-Umgebung ermöglichen.
  6. 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.

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.

Dadurch wird sichergestellt, dass die Elemente, die Sie für die Canary-Umgebung bereitstellen, von Anfang an mit der Produktionsumgebung synchron sind. Dies lässt sich ganz einfach erreichen, indem ein Infrastructure-as-Code-Tool zusammen mit einem Git-Repository verwendet wird.

Nächste Schritte

Erfahren Sie, wie Sie Sandboxumgebungen für Zielzonen implementieren.

Implementieren von Sandboxumgebungen für Zielzonen