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

Beim Entwickeln eines Governancemodells für Ihre Organisation ist wichtig zu beachten, dass Azure Resource Manager nur eine Möglichkeit für die Verwaltung von Ressourcen ist. Azure DevOps und die Automatisierung per Continuous Integration und Continuous Delivery (CI/CD) können eine ungewollte sicherheitsrelevante Hintertür darstellen, wenn keine richtigen Schutzmaßnahmen getroffen werden. Diese Ressourcen sollten geschützt werden, indem das für Resource Manager genutzte RBAC-Modell (Role-Based Access Control, rollenbasierte Zugriffssteuerung) gespiegelt wird.

Das Konzept für End-to-End-Governance ist anbieterunabhängig. Für die hier beschriebene Implementierung wird Azure DevOps genutzt, aber es wird auch kurz auf die Alternativen eingegangen.

Mögliche Anwendungsfälle

Diese Referenzimplementierung und Demo ist „Open Source“ und soll als Lerntool für Organisationen dienen, die sich noch nicht mit DevOps auskennen und ein Governancemodell für die Bereitstellung in Azure erstellen müssen. Lesen Sie sich die Informationen zu diesem Szenario sorgfältig durch, um die bei diesem Modell getroffenen Entscheidungen, die für dieses Beispielrepository verwendet werden, zu verstehen.

Governancemodelle müssen jeweils an den Geschäftsregeln der Organisation ausgerichtet sein. Diese Regeln spiegeln sich in allen technischen Implementierungen von Zugriffssteuerungen wider. Bei diesem Beispielmodell wird ein fiktives Unternehmen und das folgende gängige Szenario (mit Geschäftsanforderungen) genutzt:

• Microsoft Entra-Gruppen, die an Geschäftsbereichen und Berechtigungsmodellen ausgerichtet sind
  Die Organisation verfügt über viele vertikale Geschäftsbereiche, z. B. „Obst“ (Fruits) und „Gemüse“ (Vegetables), die größtenteils unabhängig voneinander operieren. Jeder Geschäftsbereich verfügt über zwei Ebenen bzw. Berechtigungen, die einzelnen Microsoft Entra-Gruppen vom Typ *-admins oder *-devs zugeordnet sind. Beim Konfigurieren von Berechtigungen in der Cloud kann dies dann gezielt für bestimmte Entwickler erfolgen.

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

  • Produktion. Nur Administratoren verfügen über erhöhte Rechte.
  • Keine Produktion. Alle Entwickler verfügen über erhöhte Rechte (zur Förderung der Experimentierfreudigkeit und Innovationstätigkeit).

• Automatisierungsziele
  Bei jeder Anwendung sollte Azure DevOps nicht nur für Continuous Integration (CI), sondern auch für Continuous Deployment (CD) implementiert werden. Bereitstellungen können beispielsweise automatisch durch Änderungen am Git-Repository ausgelöst werden.

• Bisherige Cloud Journey
  Die Organisation hat zunächst ein isoliertes Projektmodell genutzt, um die Cloud Journey zu beschleunigen. Nun erkundet die Organisation aber Optionen zum Aufbrechen von Silos und Fördern der Zusammenarbeit, indem Projekte vom Typ „Kollaboration“ und „Supermarkt“ erstellt werden.

Dieses vereinfachte Diagramm zeigt, wie Branches in einem Git-Repository den Entwicklungs-, Staging- und Produktionsumgebungen zugeordnet sind:

Laden Sie eine SVG-Datei dieses Diagramms herunter.

Aufbau

In diesem Diagramm ist dargestellt, warum die Verknüpfung von Resource Manager und CI/CD mit Microsoft Entra ID der Schlüssel für ein umfassendes Governancemodell ist.

Laden Sie eine SVG-Datei dieser Architektur herunter.

Workflow

Die Zahlen stehen für die Reihenfolge, in der IT-Administratoren und Unternehmensarchitekten ihre Cloudressourcen betrachten und konfigurieren.

1. Microsoft Entra ID

   Wir integrieren Azure DevOps mit Microsoft Entra ID, um einen zentralen Bereich für die Identität zu erhalten. Dies bedeutet, dass ein*e Entwickler*in sowohl für Azure DevOps als auch für Resource Manager dasselbe Microsoft Entra-Konto verwendet. Benutzer werden nicht einzeln hinzugefügt. Stattdessen wird die Mitgliedschaft über Microsoft Entra-Gruppen zugewiesen, damit wir den Zugriff auf Ressourcen für Entwickler*innen in nur einem Schritt aufheben können, indem wir ihr Mitgliedschaften in Microsoft Entra-Gruppen entfernen. Wir erstellen Folgendes für jeden Bereich:

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

2. Produktionsumgebung

   Zur Vereinfachung der Bereitstellung wird bei dieser Referenzimplementierung eine Ressourcengruppe verwendet, 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

   Zur Vereinfachung der Bereitstellung wird bei dieser Referenzimplementierung eine Ressourcengruppe genutzt, um die Entwicklungsumgebung darzustellen. In der Praxis sollten Sie ein anderes Abonnement verwenden.

4. Rollenzuweisungen in Resource Manager

   Unsere Namen der Microsoft Entra-Gruppen weisen zwar implizit auf eine Rolle hin, aber Zugriffssteuerungen werden erst angewendet, nachdem eine Rollenzuweisung konfiguriert wurde. Hierdurch wird einem Microsoft Entra-Prinzipal eine Rolle für einen bestimmten Bereich zugewiesen. Entwickler verfügen beispielsweise über die Rolle „Mitwirkender“ für die Produktionsumgebung.

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

   * Zur Vereinfachung der Bereitstellung wird den Dienstprinzipalen bei dieser Referenzimplementierung die Rolle Owner zugewiesen. In der Produktion sollten Sie aber eine benutzerdefinierte Rolle erstellen, die einen Dienstprinzipal daran hindert, jegliche Verwaltungssperren zu entfernen, die Sie für Ihre Ressourcen festgelegt haben. Auf diese Weise werden Ressourcen vor versehentlichen Beschädigungen, z. B. Datenbanklöschungen, geschützt.

   Informationen zu den Gründen für die einzelnen Rollenzuweisungen finden Sie weiter unten in diesem Artikel unter Überlegungen.

5. Sicherheitsgruppenzuweisungen in Azure DevOps

   Sicherheitsgruppen funktionieren wie Rollen in Resource Manager. Nutzen Sie integrierte Rollen, und verwenden Sie standardmäßig die Rolle Mitwirkender für Entwickler. Administratoren werden der Sicherheitsgruppe Projektadministrator zugewiesen, damit sie erhöhte Rechte erhalten und Sicherheitsberechtigungen konfigurieren können.

   Beachten Sie, dass Azure DevOps und Resource Manager über unterschiedliche Berechtigungsmodelle verfügen:

   • Für Azure Resource Manager wird ein Modell mit additiven Berechtigungen genutzt.
   • Für Azure DevOps wird ein Modell mit den geringstmöglichen Berechtigungen genutzt.

   Aus diesem Grund muss sich die Mitgliedschaft in den Gruppen -admins und -devs gegenseitig ausschließen. Andernfalls würden die betroffenen Personen in Azure DevOps über geringere Zugriffsberechtigungen als erwartet verfügen.

   Gruppenname	Resource Manager-Rolle	Azure DevOps-Rolle
   fruits-all	–	–
   fruits-devs	Mitwirkender	Mitwirkender
   fruits-admins	Besitzer	Projektadministratoren
   veggies-all	–	–
   veggies-devs	Mitwirkender	Mitwirkender
   veggies-admins	Besitzer	Projektadministratoren
   infra-all	–	–
   infra-devs	Mitwirkender	Mitwirkender
   infra-admins	Besitzer	Projektadministratoren

   Für ein Szenario mit begrenzter Zusammenarbeit, z. B. eine Einladung des Obst-Teams an das Gemüse-Team zur Zusammenarbeit an einem einzigen Repository – würden die Teams beispielsweise die Gruppe veggies-all verwenden.

   Informationen zu den Gründen für die einzelnen Rollenzuweisungen finden Sie weiter unten in diesem Artikel unter Überlegungen.

6. Dienstverbindungen

   In Azure DevOps ist eine Dienstverbindung ein generischer Wrapper für Anmeldeinformationen. Wir erstellen eine Dienstverbindung, die die Client-ID und den geheimen Clientschlüssel des Dienstprinzipals enthält. Projektadministratoren können bei Bedarf den Zugriff auf diese geschützte Ressource konfigurieren, z. B. wenn vor der Bereitstellung eine Genehmigung durch einen Menschen erfolgen muss. Diese Referenzarchitektur verfügt über zwei Mindestschutzmaßnahmen für die Dienstverbindung:

   • Administratoren müssen Pipelineberechtigungen konfigurieren, um zu steuern, welche Pipelines auf die Anmeldeinformationen zugreifen können.
   • Darüber hinaus müssen Administratoren auch eine Überprüfung der Steuerung von Branches konfigurieren, damit nur Pipelines, die im Kontext des Branchs production ausgeführt werden, prod-connection nutzen können.

7. Git-Repositorys

   Da unsere Dienstverbindungen über Steuerungen für Branches mit Branches verknüpft sind, ist es von entscheidender Bedeutung, Berechtigungen für die Git-Repositorys zu konfigurieren und Branchrichtlinien anzuwenden. Zusätzlich zu der Anforderung, dass CI-Builds die Überprüfung bestehen müssen, müssen für Pull Requests mindestens zwei genehmigende Personen vorhanden sein.

Komponenten

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

Alternativen

Das Konzept für End-to-End-Governance ist anbieterunabhängig. In diesem Artikel geht es um Azure DevOps, aber Sie können auch Azure DevOps Server als lokales Ersatztool nutzen. Darüber hinaus steht Ihnen eine Reihe von Technologien für eine Open-Source-CI/CD-Entwicklungspipeline zur Verfügung, die über Optionen wie Jenkins und GitLab verfügt.

Sowohl Azure Repos als auch GitHub sind Plattformen, die für die Verwendung des Open-Source-Git-Systems für die Versionskontrolle erstellt wurden. Es gibt Unterschiede beim Funktionsumfang, aber beide Plattformen können in globale Governancemodelle für CI/CD integriert werden. GitLab ist eine weitere Git-basierte Plattform mit zuverlässigen CI/CD-Funktionen.

Bei diesem Szenario wird Terraform als IaC-Tool (Infrastructure-as-Code) verwendet. Alternativen sind Jenkins, Ansible und Chef.

Überlegungen

Für die Erzielung von End-to-End-Governance in Azure ist es wichtig, dass Sie das Sicherheits- und Berechtigungsprofil auf dem Weg vom Computer des Entwicklers bis in die Produktion verstehen. Im folgenden Diagramm ist ein grundlegender CI/CD-Workflow mit Azure DevOps dargestellt. Mit dem roten Sperrsymbol sind Sicherheitsberechtigungen gekennzeichnet, die vom Benutzer konfiguriert werden müssen. Wenn Sie Berechtigungen nicht oder falsch konfigurieren, sind Ihre Workloads nicht ausreichend geschützt.

Laden Sie eine SVG-Datei dieses Workflows herunter.

Zur Einrichtung eines erfolgreichen Schutzes für Ihre Workloads müssen Sie dafür eine Kombination aus Sicherheitsberechtigungskonfigurationen und Überprüfungen durch Menschen verwenden. Es ist auch wichtig, dass jedes RBAC-Modell sowohl für Pipelines als auch für den Code gilt. Häufig erfolgt die Ausführung mit Identitäten mit erhöhten Rechten, und bei entsprechenden vorhandenen Anweisungen werden Ihre Workloads zerstört. Zur Verhinderung sollten Sie Branchrichtlinien in Ihrem Repository konfigurieren, damit eine Überprüfung durch einen Menschen erfolgen muss, bevor Änderungen akzeptiert werden, die zur Auslösung von Automatisierungspipelines führen.

Berücksichtigen Sie beim Entwerfen eines Governancemodells die folgenden wichtigen Konzepte und Fragen. Beachten Sie die potenziellen Anwendungsfälle für diese Beispielorganisation.

1. Schützen Ihrer Umgebungen mit Branchrichtlinien

Da Bereitstellungen über Ihren Quellcode definiert und ausgelöst werden, sollte Ihre erste Abwehrmaßnahme darin bestehen, Ihr Repository für die Quellcodeverwaltung zu schützen. In der Praxis wird hierfür der Pull Request-Workflow in Kombination mit Branchrichtlinien genutzt, um die Überprüfungen und Anforderungen zu definieren, bevor Code akzeptiert werden kann.

Bei der Planung Ihres End-to-End-Governancemodells sind privilegierte Benutzer (veggies-admins) für die Konfiguration des Branchschutzes verantwortlich. Häufig verwendete Überprüfungen für den Branchschutz, mit denen Bereitstellungen geschützt werden können:

• Erzwingen, dass der CI-Build eine Überprüfung bestehen muss: Dies ist nützlich für die Sicherstellung der Qualität des Basiscodes, z. B. Linten von Code, Komponententests und sogar Sicherheitsüberprüfungen auf Viren bzw. für Anmeldeinformationen.

• Erzwingen von Peer Reviews: Lassen Sie von einem anderen Menschen überprüfen, ob der Code wie gewünscht funktioniert. Gehen Sie besonders sorgfältig vor, wenn Änderungen am Pipelinecode vorgenommen werden. Lassen Sie dies in Kombination mit CI-Builds durchführen, um dafür zu sorgen, dass die Peer Reviews weniger mühsam sind.

Was passiert, wenn ein Entwickler versucht, einen Pushvorgang direkt in die Produktion durchzuführen?

Beachten Sie, dass Git ein verteiltes System für die Quellcodeverwaltung ist. Ein Entwickler kann ggf. die Entscheidung treffen, einen Commit direkt in den lokalen Branch production durchzuführen. Aber wenn Git richtig konfiguriert ist, wird ein Pushvorgang dieser Art vom Git-Server automatisch abgelehnt. Zum 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 in diesem Beispiel anbieterunabhängig ist. Die Features für Pull Requests und den Branchschutz sind bei mehreren Anbietern im Bereich Quellcodeverwaltung erhältlich, z. B. Azure Repos, GitHub und GitLab.

Nachdem der Code für einen geschützten Branch akzeptiert wurde, wird die nächste Ebene von Zugriffssteuerungen vom Buildserver angewendet (z. B. Azure Pipelines).

2. Welchen Zugriff benötigen Sicherheitsprinzipale?

In Azure kann ein Sicherheitsprinzipal entweder ein Benutzerprinzipal oder ein monitorloser Prinzipal sein, z. B. ein Dienstprinzipal oder eine verwaltete Identität. In allen Umgebungen sollte für Sicherheitsprinzipale das Prinzip der geringsten Rechte befolgt werden. Während Sicherheitsprinzipale in Präproduktionsumgebungen über erweiterten Zugriff verfügen können, sollten die bestehenden Berechtigungen in Azure-Produktionsumgebungen minimiert werden. Dem JIT-Zugriff (Just-In-Time) und dem bedingten Microsoft Entra-Zugriff sollte Vorrang eingeräumt werden. Entwerfen Sie Ihre Azure RBAC-Rollenzuweisungen für Benutzerprinzipale so, dass sie auf diese Prinzipale mit den geringstmöglichen Berechtigungen ausgerichtet sind.

Es ist auch wichtig, Azure RBAC separat von Azure DevOps RBAC zu modellieren. Der Zweck der Pipeline besteht darin, den direkten Zugriff auf Azure zu minimieren. Mit Ausnahme von Sonderfällen wie Innovationstätigkeit, Schulung und Problemlösung sollten die meisten Interaktionen mit Azure über zielgerichtete und geschlossene Pipelines erfolgen.

Erwägen Sie für Azure Pipelines-Dienstprinzipale die Verwendung einer benutzerdefinierten Rolle, die verhindert, dass Ressourcensperren entfernt und andere destruktive Aktionen durchgeführt werden, die nicht in diesen Bereich fallen.

3. Erstellen einer benutzerdefinierten Rolle für den Dienstprinzipal, der für den Zugriff auf die Produktion verwendet wird

Ein häufiger Fehler besteht darin, CI/CD-Build-Agents Rollen und Berechtigungen vom Typ „Besitzer“ zu gewähren. Berechtigungen vom Typ „Mitwirkender“ sind nicht ausreichend, wenn über Ihre Pipeline auch Identitätsrollenzuweisungen oder andere privilegierte Vorgänge wie die Key Vault-Richtlinienverwaltung durchgeführt werden müssen.

Ein CI/CD-Build-Agent löscht aber Ihre gesamte Produktionsumgebung, wenn dafür eine entsprechende Anweisung vorhanden ist. Zur Vermeidung von nicht mehr rückgängig zu machenden Änderungen erstellen wir eine benutzerdefinierte Rolle, mit der Folgendes durchgeführt wird:

• Entfernen von Key Vault-Zugriffsrichtlinien
• Entfernen von Verwaltungssperren, mit denen standardmäßig das Löschen von Ressourcen verhindert werden soll (eine häufige Anforderung in regulierten Branchen)

Zu diesem Zweck 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}"
  ]
}

Falls für Sie hierdurch zu viele Berechtigungen entfernt werden, sollten Sie sich die vollständige Liste in der offiziellen Dokumentation zu den Vorgängen des Azure-Ressourcenanbieters ansehen und Ihre Rollendefinition wie gewünscht anpassen.

Bereitstellen dieses Szenarios

Dieses Szenario geht über Resource Manager hinaus. Aus diesem Grund verwenden wir Terraform. Hiermit können wir auch Prinzipale in Microsoft Entra ID erstellen und das Bootstrapping für Azure DevOps durchführen, indem wir nur ein Infrastructure-as-Code-Tool verwenden.

Informationen zum Quellcode und eine ausführliche Anleitung finden Sie im GitHub-Repository Demo zur Governance in Azure: von DevOps zu ARM.

Preise

Die Kosten für Azure DevOps richten sich nach der Anzahl von Benutzern in Ihrer Organisation, die Zugriff benötigen, und anderen Faktoren wie der Anzahl von erforderlichen gleichzeitigen Builds/Releases sowie der Anzahl von Benutzern. Azure Repos und Azure Pipelines sind Features des Azure DevOps-Diensts. Weitere Informationen finden Sie in der Azure DevOps-Preisübersicht.

In Microsoft Entra ID wird die Art von Gruppenzugriffsverwaltung, die für dieses Szenario benötigt wird, unter den Editionen Premium P1 und Premium P2 bereitgestellt. Die Preise für diese Tarife werden pro Benutzer berechnet. Weitere Informationen finden Sie unter „Preise“ in Microsoft Entra.

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 Coderepository für dieses Szenario unter Demo zur Governance in Azure: von DevOps zu ARM.
• Sehen Sie sich die Cloudgovernance-Leitfäden des Cloud Adoption Framework an.
• Was ist die rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC)?
• Cloud Adoption Framework: Ressourcenzugriffsverwaltung in Azure
• Azure Resource Manager-Rollen
  • Besitzer (integriert)
  • Mitwirkender (integriert)
  • Leser (integriert)
  • Benutzerdefinierte Rolle
• Azure DevOps-Sicherheitsgruppen
  • Projektadministratoren
  • Mitwirkender
  • Leser

Zugehörige Ressourcen

• Entwerfen einer CI/CD-Pipeline mithilfe von Azure DevOps
• Computerforensik: Rückverfolgbarkeit in Azure
• Azure Arc-Hybridverwaltung und -bereitstellung für Kubernetes-Cluster
• Durchsuchen der Azure-Architektur: CI/CD