End-to-End-Governance in Azure bei Verwendung von CI/CD

Beim Entwickeln eines Governancemodells für Ihre Organisation ist es wichtig zu beachten, dass Azure Resource Manager nur eine Möglichkeit zum Verwalten von Ressourcen ist. Azure DevOps und die Automatisierung von kontinuierlicher Integration und kontinuierlicher Bereitstellung (CI/CD) können eine unbeabsichtigte Sicherheitshintertür darstellen, wenn sie nicht ordnungsgemäß gesichert werden. Diese Ressourcen sollten durch Spiegelung des rollenbasierten Zugriffssteuerungsmodells (RBAC) geschützt werden, das für den Ressourcen-Manager verwendet wird.

Das Konzept der End-to-End-Governance ist anbieterunabhängig. Die hier beschriebene Implementierung verwendet Azure DevOps, aber Alternativen werden ebenfalls kurz erwähnt.

Mögliche Anwendungsfälle

Diese Referenzimplementierung und Demo ist Open Source und soll als Lehrtool für Organisationen verwendet werden, die neu bei DevOps sind und ein Governancemodell für die Bereitstellung in Azure erstellen müssen. Lesen Sie dieses Szenario sorgfältig, um die Entscheidungen hinter dem in diesem Beispiel-Repository verwendeten Modell zu verstehen.

Jedes Governancemodell muss an die Geschäftsregeln der Organisation gebunden sein, die in jeder technischen Implementierung von Zugriffskontrollen widerzuspiegeln sind. In diesem Beispielmodell wird ein fiktives Unternehmen mit dem folgenden gängigen Szenario (mit geschäftlichen Anforderungen) verwendet:

• Microsoft Entra-Gruppen, die mit Geschäftsdomänen und Berechtigungsmodellen übereinstimmen
  Die Organisation verfügt über viele vertikale Geschäftsdomänen wie "Obst" und "Gemüse", die weitgehend unabhängig arbeiten. In jeder Geschäftsdomäne gibt es zwei Ebenen oder Berechtigungen, die unterschiedlichen *-admins oder *-devs Microsoft Entra-Gruppen zugeordnet sind. Auf diese Weise können Entwickler beim Konfigurieren von Berechtigungen in der Cloud gezielt sein.

• Bereitstellungsumgebungen
  Jedes Team verfügt über zwei Umgebungen:

  • Produktion. Nur Administratoren haben erhöhte Berechtigungen.
  • Nichtproduktion. Alle Entwickler haben erhöhte Berechtigungen (um Experimenten und Innovationen zu fördern).

• Automatisierungsziele
  Jede Anwendung sollte Azure DevOps nicht nur für die kontinuierliche Integration (CI), sondern auch für die kontinuierliche Bereitstellung (CD) implementieren. Beispielsweise können Bereitstellungen automatisch durch Änderungen am Git-Repository ausgelöst werden.

• Die bisherige Cloud-Reise
  Die Organisation begann mit einem isolierten Projektmodell, um den Weg zur Cloud zu beschleunigen. Aber jetzt erforschen sie Optionen, silos zu brechen und die Zusammenarbeit zu fördern, indem sie die Projekte "Zusammenarbeit" und "Supermarkt" erstellen.

Dieses vereinfachte Diagramm zeigt, wie Verzweigungen in einem Git-Repository Entwicklungs-, Staging- und Produktionsumgebungen zugeordnet werden:

Laden Sie ein SVG dieses Diagramms herunter.

Architektur

Dieses Diagramm zeigt, wie die Verknüpfung von Ressourcen-Manager und CI/CD zu Microsoft Entra ID der Schlüssel für ein End-to-End-Governance-Modell ist.

Laden Sie ein SVG dieser Architektur herunter.

Arbeitsablauf

Die Nummerierung spiegelt die Reihenfolge wider, in der IT-Administratoren und Unternehmensarchitekten ihre Cloudressourcen berücksichtigen und konfigurieren.

1. Microsoft Entra-ID

   Wir integrieren Azure DevOps mit Microsoft Entra ID , um eine einzige Ebene für Identität zu haben. Dies bedeutet, dass ein Entwickler dasselbe Microsoft Entra-Konto für Azure DevOps und Ressourcen-Manager verwendet. Benutzer werden nicht einzeln hinzugefügt. Stattdessen wird die Mitgliedschaft von Microsoft Entra-Gruppen zugewiesen, damit wir den Zugriff eines Entwicklers auf Ressourcen in einem einzigen Schritt entfernen können, indem seine Microsoft Entra-Gruppenmitgliedschaften entfernt werden. Für jede Domäne erstellen wir Folgendes:

   • Microsoft Entra-Gruppen. Zwei Gruppen pro Domäne (weiter unten in Schritt 4 und 5 in diesem Artikel beschrieben).
   • Dienstprinzipale. Ein expliziter Dienstprinzipal pro Umgebung.

2. Produktionsumgebung

   Um die Bereitstellung zu vereinfachen, verwendet diese Referenzimplementierung eine Ressourcengruppe, um die Produktionsumgebung darzustellen. In der Praxis sollten Sie ein anderes Abonnement verwenden.

   Der privilegierte Zugriff auf diese Umgebung ist nur auf Administratoren beschränkt.

3. Entwicklungsumgebung

   Um die Bereitstellung zu vereinfachen, verwendet diese Referenzimplementierung eine Ressourcengruppe, um die Entwicklungsumgebung darzustellen. In der Praxis sollten Sie ein anderes Abonnement verwenden.

4. Rollenzuweisungen im Ressourcen-Manager

   Obwohl unsere Microsoft Entra-Gruppennamen eine Rolle bedeuten, werden Zugriffssteuerungen erst angewendet, wenn eine Rollenzuweisung konfiguriert ist. Dadurch wird einem Microsoft Entra-Prinzipal eine Rolle für einen bestimmten Bereich zugewiesen. Entwickler haben beispielsweise die Rolle "Mitwirkender" in der Produktionsumgebung.

   Microsoft Entra-Prinzipal	Entwicklungsumgebung (Ressourcen-Manager)	Produktionsumgebung (Ressourcen-Manager)
   veggies-devs-group	Owner	Leser
   veggies-admins-group	Besitzer	Besitzer
   veggies-ci-dev-sp	Benutzerdefinierte Rolle *	–
   veggies-ci-prod-sp	–	Benutzerdefinierte Rolle *

   * Um die Bereitstellung zu vereinfachen, weist diese Referenzimplementierung die Owner Rolle den Dienstprinzipalen zu. In der Produktion sollten Sie jedoch eine benutzerdefinierte Rolle erstellen, die verhindert, dass ein Dienstprinzipal Verwaltungssperren entfernt, die Sie auf Ihren Ressourcen platziert haben. Dies trägt zum Schutz von Ressourcen vor versehentlichem Schaden bei, z. B. beim Löschen von Datenbanken.

   Wenn Sie die Gründe für die einzelnen Rollenzuweisungen verstehen möchten, lesen Sie den Abschnitt "Überlegungen " weiter unten in diesem Artikel.

5. Sicherheitsgruppenzuweisungen in Azure DevOps

   Sicherheitsgruppen funktionieren wie Rollen im Ressourcen-Manager. Nutzen Sie integrierte Rollen, und setzen Sie für Entwickler standardmäßig auf Mitwirkender. Administratoren werden der Sicherheitsgruppe "Projektadministrator " für erhöhte Berechtigungen zugewiesen, sodass sie Sicherheitsberechtigungen konfigurieren können.

   Beachten Sie, dass Azure DevOps und Resource Manager unterschiedliche Berechtigungsmodelle haben:

   • Azure Resource Manager verwendet ein additives Berechtigungsmodell .
   • Azure DevOps verwendet ein Geringstes Berechtigungsmodell .

   Aus diesem Grund muss sich die Mitgliedschaft in den Gruppen -admins und -devs gegenseitig ausschließen. Andernfalls hätten die betroffenen Personen weniger Zugriff als erwartet in Azure DevOps.

   Gruppenname	Rolle "Ressourcen-Manager"	Azure DevOps-Rolle
   fruits-all	–	–
   fruits-devs	Beitragender	Beitragender
   fruits-admins	Besitzer	Projektadministratoren
   veggies-all	–	–
   veggies-devs	Beitragender	Beitragender
   veggies-admins	Besitzer	Projektadministratoren
   infra-all	–	–
   infra-devs	Beitragender	Beitragender
   infra-admins	Besitzer	Projektadministratoren

   In einem Szenario mit eingeschränkter Zusammenarbeit, z. B. das Obstteam, das das Veggies-Team zur Zusammenarbeit an einem einzigen Repository einlädt, würden sie die veggies-all Gruppe verwenden.

   Wenn Sie die Gründe für die einzelnen Rollenzuweisungen verstehen möchten, lesen Sie den Abschnitt "Überlegungen " weiter unten in diesem Artikel.

6. Dienstverbindungen

   In Azure DevOps ist eine Dienstverbindung ein generischer Wrapper um eine Anmeldeinformation. Wir erstellen eine Dienstverknüpfung, die die Client-ID und das Client-Secret des Service Principals enthält. Projektadministratoren können den Zugriff auf diese geschützte Ressource bei Bedarf konfigurieren, z. B. wenn vor der Bereitstellung eine menschliche Genehmigung erforderlich ist. Diese Referenzarchitektur verfügt über zwei Mindestschutzmechanismen für die Dienstverbindung:

   • Administratoren müssen Pipelineberechtigungen konfigurieren, um zu steuern, welche Pipelines auf die Anmeldeinformationen zugreifen können.
   • Administratoren müssen auch eine Branchenkontrollprüfung konfigurieren, damit nur Pipelines, die im Kontext des production Branches ausgeführt werden, die prod-connection verwenden können.

7. Git-Repositorys

   Da unsere Dienstverbindungen über Branch-Control-Steuerelemente verbunden sind, ist es wichtig, Berechtigungen für die Git-Repositories zu konfigurieren und Verzweigungsrichtlinien anzuwenden. Neben der Anforderung, dass CI-Builds übergeben werden müssen, benötigen wir auch Pullanforderungen, um mindestens zwei Genehmiger zu haben.

Komponenten

• Azure DevOps
• Microsoft Entra-ID
• Azure Resource Manager
• Azure Repos
• Azure-Pipelines

Alternatives

Das Konzept der End-to-End-Governance ist anbieterunabhängig. Während sich dieser Artikel auf Azure DevOps konzentriert, könnte Azure DevOps Server als lokaler Ersatz verwendet werden. Alternativ können Sie auch eine Reihe von Technologien für eine Open-Source-CI/CD-Entwicklungspipeline mit Optionen wie Jenkins und GitLab verwenden.

Sowohl Azure Repos als auch GitHub sind Plattformen, die für die Verwendung des Open-Source-Git-Versionssteuerungssystems erstellt wurden. Während ihre Featuresätze etwas anders sind, können beide in globale Governancemodelle für CI/CD integriert werden. GitLab ist eine weitere gitbasierte Plattform, die robuste CI/CD-Funktionen bereitstellt.

Dieses Szenario verwendet Terraform als Tool für Infrastruktur als Code (IaC). Zu den Alternativen gehören Jenkins, Ansible und Chef.

Überlegungen

Um End-to-End-Governance in Azure zu erreichen, ist es wichtig, das Sicherheits- und Berechtigungsprofil des Pfads vom Computer des Entwicklers zur Produktion zu verstehen. Das folgende Diagramm veranschaulicht einen geplanten CI/CD-Workflow mit Azure DevOps. Das rote Sperrsymbol gibt Sicherheitsberechtigungen an, die vom Benutzer konfiguriert werden müssen. Wenn Sie keine Berechtigungen konfigurieren oder falsch konfigurieren, bleiben Ihre Workloads anfällig.

Laden Sie ein SVG dieses Workflows herunter.

Um Ihre Workloads erfolgreich zu sichern, müssen Sie eine Kombination aus Sicherheitsberechtigungskonfigurationen und menschlichen Prüfungen in Ihrem Workflow verwenden. Es ist wichtig, dass jedes RBAC-Modell auch auf Pipelines und Code erweitert werden muss. Diese werden häufig mit privilegierten Identitäten betrieben und zerstören Ihre Workloads, wenn sie dazu angewiesen werden. Um dies zu verhindern, sollten Sie Verzweigungsrichtlinien für Ihr Repository so konfigurieren, dass sie eine menschliche Genehmigung erfordern, bevor Sie Änderungen akzeptieren, die Automatisierungspipelines auslösen.

Die folgenden Konzepte und Fragen sind beim Entwerfen eines Governancemodells wichtig. Beachten Sie die potenziellen Anwendungsfälle dieser Beispielorganisation.

1. Schützen Ihrer Umgebungen mit Zweigstellenrichtlinien

Da Ihr Quellcode Bereitstellungen definiert und auslöst, besteht Ihre erste Verteidigungslinie darin, Ihr Quellcodeverwaltungs-Repository (Source Code Management, SCM) zu sichern. In der Praxis wird dies durch den Einsatz des Pull-Request-Workflows in Kombination mit Branch-Richtlinien erreicht, die Überprüfungen und Anforderungen festlegen, bevor Code akzeptiert werden kann.

Bei der Planung Ihres End-to-End-Governance-Modells sind privilegierte Benutzer (veggies-admins) für die Konfiguration des Branch-Schutzes verantwortlich. Zu den allgemeinen Branch-Schutzmaßnahmen, die zum Sichern Ihrer Deployments verwendet werden, gehören:

• Das CI-Build muss erfolgreich abgeschlossen werden. Nützlich für die Erstellung der grundlegenden Codequalität, z. B. Code linting, Komponententests und sogar Sicherheitsprüfungen wie Viren- und Anmeldeinformationsscans.

• Codeüberprüfung durch Kollegen erforderlich Lassen Sie den Code von einer weiteren Person überprüfen, um sicherzustellen, dass er wie beabsichtigt funktioniert. Achten Sie besonders darauf, wenn Änderungen am Pipelinecode vorgenommen werden. Kombinieren Sie mit CI-Builds, um Peer-Rezensionen weniger mühsam zu machen.

Was passiert, wenn ein Entwickler versucht, direkt in die Produktionsumgebung zu deployen?

Denken Sie daran, dass Git ein verteiltes SCM-System ist. Ein Entwickler kann sich direkt auf seine lokale production Verzweigung verpflichten. Wenn Git jedoch ordnungsgemäß konfiguriert ist, wird ein solcher Push automatisch vom Git-Server abgelehnt. Beispiel:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Beachten Sie, dass der Workflow im Beispiel anbieterunabhängig ist. Die Pullanforderungs- und Verzweigungsschutzfeatures sind von mehreren SCM-Anbietern verfügbar, einschließlich Azure Repos, GitHub und GitLab.

Sobald der Code in eine geschützte Verzweigung akzeptiert wurde, wird die nächste Ebene der Zugriffssteuerungen vom Buildserver (z. B. Azure-Pipelines) angewendet.

2. Welchen Zugriff benötigen Sicherheitsprinzipale?

In Azure kann ein Sicherheitsprinzipal entweder ein Benutzerprinzipal oder ein kopfloser Prinzipal sein, z. B. ein Dienstprinzipal oder eine verwaltete Identität. In allen Umgebungen sollten Sicherheitsprinzipale dem Prinzip der geringsten Berechtigungen entsprechen. Während Sicherheitsprinzipale möglicherweise erweiterten Zugriff in Vorproduktionsumgebungen haben, sollten Produktions-Azure-Umgebungen die dauerhaften Berechtigungen minimieren und Just-in-Time (JIT)-Zugriff sowie Microsoft Entra Conditional Access bevorzugen. Gestalten Sie Ihre Azure RBAC-Rollenzuweisungen für Benutzerprinzipale so, dass sie mit diesen am wenigsten privilegierten Prinzipalen übereinstimmen.

Es ist auch wichtig, Azure RBAC anders als Azure DevOps RBAC zu modellieren. Der Zweck der Pipeline besteht darin, den direkten Zugriff auf Azure zu minimieren. Abgesehen von speziellen Fällen, wie Innovation, Lernen und Problemlösungen, sollten die meisten Interaktionen mit Azure über zweckbestimmte und abgesicherte Pipelines durchgeführt werden.

Für Azure Pipeline-Dienstprinzipalen sollten Sie eine benutzerdefinierte Rolle verwenden, die verhindert, dass Ressourcensperren entfernt und andere destruktive Aktionen ausgeführt werden, die außerhalb seines Zwecks liegen.

3. Erstellen einer benutzerdefinierten Rolle für den Dienstprinzipal für den Zugriff auf die Produktion

Es ist ein häufiger Fehler, CI/CD-Build-Agents Besitzerrollen und Berechtigungen zu erteilen. Berechtigungen für Mitwirkende reichen nicht aus, wenn Ihre Pipeline auch Zuweisungen von Identitätsrollen oder andere privilegierte Operationen wie die Verwaltung von Richtlinien im Key Vault ausführen muss.

Ein CI/CD Build Agent löscht jedoch die gesamte Produktionsumgebung, wenn dies erforderlich ist. Um unwiderrufliche destruktive Änderungen zu vermeiden, erstellen wir eine benutzerdefinierte Rolle, die:

• Entfernt Zugriffsrichtlinien für key Vault
• Entfernt Verwaltungssperren , die beabsichtigt verhindern sollten, dass Ressourcen gelöscht werden (eine häufige Anforderung in regulierten Branchen)

Dazu erstellen wir eine benutzerdefinierte Rolle und entfernen die Microsoft.Authorization/*/Delete Aktionen.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Wenn dies zu viele Berechtigungen für Ihre Zwecke entfernt, lesen Sie die vollständige Liste in der offiziellen Dokumentation für Azure-Ressourcenanbietervorgänge , und passen Sie Ihre Rollendefinition nach Bedarf an.

Bereitstellen dieses Szenarios

Dieses Szenario erstreckt sich über den Ressourcen-Manager hinaus. Deshalb verwenden wir Terraform, mit dem wir auch Hauptobjekte in Microsoft Entra ID erstellen und Azure DevOps mithilfe eines einzigen Infrastruktur-als-Code-Tools konfigurieren können.

Für Quellcode und detaillierte Anweisungen besuchen Sie die GitHub-Repositorygovernance auf Azure Demo – von DevOps zu ARM.

Pricing

Die Kosten für Azure DevOps hängen von der Anzahl der Benutzer in Ihrer Organisation ab, die Zugriff erfordern, sowie von anderen Faktoren wie der Anzahl der erforderlichen Builds/Versionen und der Anzahl der Benutzer. Azure Repos und Azure Pipelines sind Features des Azure DevOps-Diensts. Weitere Informationen finden Sie unter Azure DevOps-Preis.

In Microsoft Entra ID wird der Typ der für dieses Szenario erforderlichen Gruppenzugriffsverwaltung in den Editionen Premium P1 und Premium P2 bereitgestellt. Die Preise für diese Stufen werden pro Benutzer berechnet. Weitere Informationen finden Sie unter Microsoft Entra-Preise.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• Julie Ng | Senior Service Engineer

Nächste Schritte

• Besuchen Sie das Code-Repository für dieses Szenario bei Governance auf Azure Demo – von DevOps zu ARM.
• Überprüfen Sie die Cloud-Governance-Leitfäden des Cloud Adoption Framework.
• Was ist die rollenbasierte Azure-Zugriffssteuerung (Azure RBAC)?
• Cloud Adoption Framework: Ressourcenzugriffsverwaltung in Azure
• Azure Resource Manager-Rollen
  • Besitzer (integriert)
  • Mitwirkender (integriert)
  • Reader (integriert)
  • Benutzerdefinierte Rolle
• Azure DevOps-Sicherheitsgruppen
  • Projektadministratoren
  • Contributor
  • Reader