Azure DevOps-Berechtigungen auf Unternehmensebene aus dem Schützengraben

Oder wie Sie die rollenbasierte Zugriffskontrolle (RBAC) in Azure DevOps in Unternehmensumgebungen implementieren und trotzdem wartbar halten. 4 Antipatterns und ein Ansatz, wie Sie dies selbst implementieren können!

Einführung und Schlüsselwerte

Die Zuweisung von Berechtigungen an Benutzer und Benutzergruppen in Azure DevOps ist in kleinen Unternehmen, vielleicht bis zu 25-50 Mitarbeitern, einfach und unkompliziert. Bei einem großen Unternehmen muss man sich jedoch genau überlegen, wie man dies angehen will. Bei einem mittelgroßen Kunden (etwa 250 Benutzer) musste ich die Berechtigungsstruktur in Azure DevOps neu gestalten. Die wichtigste Anforderung war, die Zugriffskontrolle über den Microsoft Identity Manager (MIM) verwalten zu können. microsoft identity manager ). Microsoft MIM wird eingesetzt, um eine rollenbasierte Zugriffskontrolle (RBAC - role-based access control) zu implementieren. Wikipedia-Seite zur rollenbasierten Zugriffskontrolle). Die Idee hinter dieser Implementierung ist, dass Teamleiter anstelle eines Supportteams den Zugriff auf Systeme genehmigen können (Selbstbedienung). Dieser Zugriff wurde von den Systemadministratoren durch die Einrichtung von MIM-Rollen und Microsoft Entra ID oder Active Directory (AD)-Gruppen vordefiniert. Durch die Verwendung von MIM-Rollen, die mit Entra-Gruppen verknüpft sind, ist es nicht mehr notwendig, einzelnen Benutzern Berechtigungen zuzuweisen, da sie lediglich einer Gruppe hinzugefügt werden müssen.

In diesem Artikel geht es nicht um die Einrichtung von RBAC selbst, sondern darum, wie Sie RBAC in Azure DevOps erleichtern.

Wichtiger Hinweis: Ich gehe davon aus, dass Sie über ausreichende Kenntnisse und Erfahrungen verfügen, um Entscheidungen über Änderungen der Berechtigungen in Azure DevOps zu treffen. Eine nützliche Referenz zum Verständnis von Berechtigungen ist diese: Dokumentationsseite zu permissions-access?view=azure-devops

Annäherung

Lassen Sie uns nun mit dem Ansatz fortfahren;

Ich habe die folgenden Schlüsselwerte als Grundlage für die Implementierung festgelegt:

• Wartbarkeit - Häufige Änderungen sollten so mühelos wie möglich sein
• Sichtbarkeit - Man sollte leicht erkennen können, welche spezifischen Berechtigungen eine Person hat
• Integration - Die Einrichtung sollte mit MIM integriert werden
• Transparenz - Die Mitarbeiter haben Zugang zu allen Ressourcen innerhalb von Azure DevOps, es sei denn, es gibt einen triftigen Grund, den Zugang zu beschränken. Dies gilt vor allem für Ingenieure (dies widerspricht dem Prinzip des geringstmöglichen Umfangs an Privilegien, aber ich ziehe Transparenz dem geringstmöglichen Umfang an Privilegien vor, wenn möglich).

Die Schlüsselwerte werden unter Verwendung der folgenden Richtlinien implementiert:

• Verwenden Sie keine "Verweigern"-Berechtigungen
• Berechtigungen werden immer über Entra/AD- oder Azure DevOps-Gruppen vergeben, niemals über einen einzelnen Benutzer. Dies gilt auch für die Mitgliedschaft in Gruppen auf Team Project-Ebene
• Die Mitgliedschaft in jeder "Administratoren"-Gruppe (Projektadministratoren, Endpunktadministratoren, Build-Administratoren, Release-Administratoren usw.) ist auf das Team beschränkt, das Azure DevOps verwaltet. Das Problem ist, dass diese Gruppen die Berechtigung zum Ändern von Berechtigungen erteilen
• Sorgen Sie für Ordnung und Sauberkeit. Wenn ein Team aufhört zu existieren, besprechen Sie mit dem Team, was es übernehmen kann: - Entfernt (Backlogs, Bereiche, Iterationen, Pipelines, Repos) - Archiviert (Backlogs) - Übertragen auf ein anderes Team
• Wenn das Unternehmen separate Konten für die Systemadministration verwendet, sollten die Benutzer nicht in der Lage sein, über diese Konten auf Azure DevOps zuzugreifen. Dafür sind sie nicht gedacht. Außerdem würde dies zu zusätzlichen Lizenzkosten führen. Die einzige Ausnahme sollte/kann das Team sein, das Azure DevOps verwaltet, so dass sie die Belange trennen können
• Einheitliche Namen für Azure DevOps- und Entra/AD-Gruppen im gesamten System
• Standardmäßige Azure DevOps-Gruppen verfügen über vorgefertigte Berechtigungen, die in keiner Weise geändert werden sollten. Wenn benutzerdefinierte Berechtigungen erforderlich sind, erstellen Sie eine weitere Gruppe

Implementierung

Die Implementierung von Sicherheitsstrukturen kann mühsam sein und sich in langwierige Prozesse einfügen. Daher halte ich es für gut, dies so agil wie möglich anzugehen und den Fortschritt nicht mehr als nötig zu verlangsamen.

Der Aufbau der Gruppenstruktur in AD und MIM nimmt viel Zeit in Anspruch, also dachte ich mir, ich würde (1) erstellen Sie die Berechtigungsgruppen (die tatsächlich eine zukünftige Rolle in MIM widerspiegeln) in Azure DevOps auf der Ebene Sammlung/Organisation. Dann (2) Benutzer in diese Gruppen aufnehmen und sobald die AD/MIM-Gruppen fertig sind, kann ich die (3) ersetzen Sie die einzelnen Benutzer durch die Gruppen.

Es hilft auch, zuerst (1) die neue Berechtigungsgruppe erstellen, dann (2) die Berechtigungen an diese Gruppe zu vergeben und dann (3) die Gruppe mit anderen Gruppen oder Einzelpersonen füllen (dies ist ein Zwischenschritt, bevor die eigentlichen MIM-Rollen verfügbar sind). Danach, (4) können die alten Berechtigungen entfernt werden.

Bevor wir zu den eigentlichen Schritten und Beispielen übergehen, sollten wir uns einige Antimuster ansehen.

Antipattern 1 - Direkt an Einzelpersonen vergebene Berechtigungen

Wenn einer Person in einer großen Umgebung sehr spezifische Berechtigungen zugewiesen werden, ist es sehr schwer, diese nachzuvollziehen. Es gibt keinen zentralen Ort, an dem man diese Berechtigungen einsehen kann. Ein Beispiel ist die Schubkraft Berechtigung in einem Git Repo. Diese Berechtigung wird häufig angefordert und implementiert, indem einer Person die Berechtigung für ein bestimmtes Repository erteilt wird. Diese Berechtigung kann nur zurückverfolgt werden, indem Sie in die Repository-Einstellungen gehen, zu einem bestimmten Repository navigieren und dann die Sicherheitseinstellungen überprüfen. Keine leichte Aufgabe in einer Umgebung, in der ein Projekt 100+ Repos enthält...

Erstellen Sie stattdessen eine Gruppe auf Team-Projekt- oder Organisationsebene, weisen Sie dieser Gruppe Berechtigungen zu und machen Sie andere Gruppen/Personen zu Mitgliedern dieser Gruppe.

Schritt 1: Erstellen Sie eine Gruppe auf Organisationsebene und fügen Sie Mitglieder hinzu;

Schritt 2: Erstellen Sie eine Gruppe auf Projektebene und machen Sie eine Gruppe auf Organisationsebene zu einem Mitglied dieser Gruppe;

Schritt 3: Weisen Sie der Gruppe auf Projektebene Berechtigungen zu (die Gruppe wird nicht standardmäßig angezeigt; suchen Sie sie mit Hilfe des Suchfeldes);

Antimuster 2 - Einsatz von Teams in Fällen, in denen Gruppen verwendet werden können

Wenn Sie ein Team erstellen, werden in der Regel ein Bereich sowie Boards, teamspezifische Einstellungen und Dashboards erstellt. Wenn Sie ein Team erstellen, um eine Gruppe von Personen zu beherbergen, die nur (eine) bestimmte Berechtigung(en) teilen, dann ist das ein ziemlicher Aufwand. Verwenden Sie eine Gruppe statt eines Teams. Ein Team ist nur erforderlich, wenn eine Gruppe von Personen mit Azure Boards zusammenarbeitet. Wenn keine Azure Boards erforderlich sind, erstellen Sie stattdessen eine Gruppe.

Antipattern 3 - Ändern der Berechtigungen von Standardgruppen

Jede Azure DevOps-Organisation verfügt über Standardgruppen (siehe Referenz am Ende dieses Beitrags), und jedes erstellte Teamprojekt verfügt ebenfalls über Standardgruppen. Wenn Sie die Berechtigungen dieser Gruppen ändern, stiftet das Verwirrung bei Ihren Mitarbeitern. Die Leute erwarten, dass sich Standardgruppen standardmäßig so verhalten. Wenn Sie ein anderes Verhalten benötigen, erstellen Sie eine neue Gruppe speziell für dieses Verhalten. Sehen Sie sich die Lösung für das erste Antipattern "Einzelpersonen direkt zugewiesene Berechtigungen" an, mit der auch dieses Antipattern gelöst wird.

Antipattern 4 - Missbrauch von Administratorgruppen auf Projektebene

Um eine Azure-Pipeline zu erstellen, die einen bestimmten Agent-Pool verwendet, benötigen Sie die Berechtigung, diesen Agent-Pool zu nutzen, da die Pipeline sonst nicht verwendet werden kann. Um die Berechtigungen zu erteilen, sollten Sie die Personen nicht in die Gruppe der Build- oder Release-Administratoren aufnehmen! Warum nicht? Weil diese Personen die Berechtigung erhalten, Berechtigungen zu ändern, was Ihr RBAC-Modell durcheinander bringen könnte.

Erstellen Sie stattdessen eine separate Gruppe, in der die Benutzer Rolle in diesem speziellen Agent-Pool oder in mehreren Agent-Pools zugewiesen ist. Dies ist nur auf Team Project-Ebene möglich, nicht auf Organisationsebene (die Rolle Benutzer ist dort nicht verfügbar).

Schritt 1: Erstellen Sie eine Gruppe auf Projektebene und fügen Sie die Gruppe Team Project Contributors zu dieser Berechtigungsgruppe hinzu.

Schritt 2: Geben Sie der benutzerdefinierten Berechtigungsgruppe für alle Agent Pools die Rolle Benutzer

Strategie zur Umsetzung

Bevor Sie mit der Umsetzung beginnen, sollten Sie sich Gedanken über die Strategie machen. Die Strategie hängt ganz von der Situation ab, in der sich das Unternehmen befindet. In meinem Fall war ich in der Lage, sie in kleinen Phasen umzusetzen, so dass ich den Kurs/die Richtung ändern konnte, wenn die von mir gewählten Lösungen nicht wie erwartet funktionierten. Außerdem konnte ich den Prozess in zwei Schritten durchführen:

1. Benutzer in Azure DevOps-Gruppen (auf Organisationsebene) aufnehmen
2. Ersetzen Sie diese Benutzer durch die neuen Entra/AD/MIM-Gruppen, sobald diese bereit sind.

Bei der Ausarbeitung Ihrer eigenen Strategie hat es mir geholfen, diese Punkte zu beachten:

• Informieren Sie die Benutzer über Änderungen, die Sie vornehmen. So können sie sich melden, wenn sich Änderungen der Berechtigungen auf ihre Arbeit auswirken.
• Kurze Verbesserungszyklen gegenüber langen Projekten mit Big-Bang-Implementierungen
• Bleiben Sie regelmäßig in Kontakt mit dem für MIM und Entra/AD zuständigen Team und erkundigen Sie sich nach dessen Anforderungen
• Nehmen Sie Änderungen so vor, dass sie leicht wieder rückgängig gemacht werden können.

Konventionen zur Namensgebung

Es ist hilfreich, wenn die Gruppen in Azure DevOps einer Namenskonvention entsprechen. Das macht sie leicht zu erkennen. Natürlich steht es jedem frei, seine eigenen Konventionen festzulegen, aber dies sind die Konventionen, die ich verwendet habe:

Bestimmen und erstellen Sie Gruppen auf Organisationsebene

Gruppen auf Organisationsebene sind in der Regel die Gruppen, die die Rollen widerspiegeln würden. Rollen können sein (Blei) Ingenieur, Produktinhaber, Scrum Master, admin oder alles, was Sie brauchen. Bei meinem Kunden habe ich diese Regeln nach und nach entsprechend meinen Bedürfnissen aufgebaut. Ich habe die gesamte Azure DevOps-Umgebung nach benutzerdefinierten Berechtigungen durchsucht und versucht zu überprüfen, ob sie noch notwendig sind und zu welcher Rolle sie gehören. Auf dieser Grundlage habe ich die Rollen auf Organisationsebene erstellt und die ursprünglichen benutzerdefinierten Berechtigungen bereinigt.

Bestimmen und erstellen Sie Gruppen auf Projektebene

Prüfen Sie zunächst immer, ob die Berechtigung/Gruppe auf Organisationsebene generisch gemacht werden kann. Wenn es wirklich notwendig ist, Berechtigungen auf Projektebene einzurichten, dann erstellen Sie dort Gruppen. Einige Situationen, in denen dies nützlich sein kann:

• Strategische Repositories, die nur für einige leitende Ingenieure zugänglich sind
• Ein Projekt, mehrere Teams, die ihre eigenen gemeinsamen Abfragen haben
• Kundenspezifische Projekte, bei denen der Kunde Zugang zu seinem Auftragsbestand hat

Nutzung der Azure DevOps Gruppenregeln

Vor einiger Zeit hat Microsoft Gruppenregeln in Azure DevOps (nur Dienste!). Mit Gruppenregeln können Sie Team Project Access und Lizenzen automatisch Entra-Gruppen zuweisen. Diese Funktion ist insbesondere (aber nicht nur) für die Verwaltung von Lizenzen(Zugriffsebenen) mit Hilfe von Entra Gruppen hilfreich. Ich habe sie zwar nicht bei meinem Kunden eingesetzt, aber wir verwenden sie in unserem eigenen Unternehmen. Unsere Techniker erhalten mit Hilfe von Gruppenregeln standardmäßig die Zugriffsstufe Visual Studio Subscriber. Wir haben eine Gruppenregel, die diese Zugriffsstufe zuweist und unseren Ingenieuren Zugriff auf alle Projekte außer einigen wenigen Team-Projekten gibt.

Verwaltung von Team- und Team-Admin-Mitgliedschaften

Teams und Teamadministratoren sind ein schwieriges Thema bei RBAC, denn eine MIM-Rolle zu haben bedeutet nicht unbedingt, Mitglied eines bestimmten Teams zu sein. Wenn jemand Teamadministrator ist, kann diese Person tatsächlich Teammitglieder hinzufügen und entfernen. Damit wird das RBAC-Prinzip durchbrochen, bei dem alles über Rollen und nicht über Berechtigungen gesteuert wird.

Die Teamadministratoren sind also eine "Gruppe", die Sie vermeiden sollten.

Was die Teammitglieder betrifft, so sind damit einige sehr nützliche Funktionen verbunden. Wenn Personen einem Team angehören, werden sie automatisch über wichtige Ereignisse in ihrem Azure DevOps Team benachrichtigt, sie haben ihr eigenes Backlog, das sofort sichtbar ist, wenn sie Azure Boards aufrufen, und es gibt noch weitere Vorteile. Es gibt hier keinen idealen Ansatz. Man könnte alle in der Organisation verfügbaren Teams auf Organisationsebene definieren und diese Gruppen zu Mitgliedern der Gruppe Engineers machen, so dass die Mitarbeiter nicht Mitglied von zwei Rollen sein müssen (der Rolle Engineers und ihrer Teamrolle). Dies würde zu einer Struktur führen, wie sie im folgenden Diagramm dargestellt ist:

Im Diagramm folgen die Pfeile den Mitgliedschaften. Die Gruppe Contoso Engineers hat also drei Mitglieder:

• Team Jedis
• Team Starlords
• Team Wächter

Die folgenden Gruppen enthalten dann entweder Benutzer oder Entra/MIM-Gruppen:

• Team Jedis
• Team Starlords
• Team Wächter

Beachten Sie, dass die Standardgruppe auf Teamprojektebene Contributors die Gruppe Contoso Engineers als Mitglied in jedem Projekt hat, damit alle Ingenieure auf alle Teamprojekte (oder zumindest auf die meisten davon) zugreifen und zu ihnen beitragen können.

Referenz

Diese Referenz beschreibt einige Standardgruppen, die auf verschiedenen Ebenen in Azure DevOps verfügbar sind. Eine vollständige Referenz finden Sie unter: Dokumentationsseite zu permissions-access?view=azure-devops

Standardgruppen auf Organisationsebene

Azure DevOps Server (On Prem):

• Verwalter der Projektsammlung
• Projekt Sammlung Build Administratoren
• Projektabholung Build Service Konten
• Projekt Sammlung Proxy Service Konten
• Projekt Inkasso Service Konten
• Projekt Sammlung Test Service Konten
• Projekt Sammlung Gültige Benutzer
• Sicherheitsdienst Gruppe
• Team Foundation lizenzierte Benutzer (nur verfügbar, wenn in der Vergangenheit die Workgroup Edition von TFS verwendet wurde)

Azure DevOps Services (Cloud):

• Verwalter der Projektsammlung
• Projekt Sammlung Build Administratoren
• Projektabholung Build Service Konten
• Projekt Sammlung Proxy Service Konten
• Projekt Inkasso Service Konten
• Projekt Sammlung Test Service Konten
• Projekt Sammlung Gültige Benutzer
• Projektgebundene Benutzer
• Sicherheitsdienst Gruppe

Standardgruppen auf Team Projekt Ebene

• Administratoren bauen
• Mitwirkende
• Administratoren der Einsatzgruppen
• Endpunkt-Administratoren
• Endpunkt Schöpfer
• Projekt-Administratoren
• Projekt Gültige Benutzer
• Leser
• Administratoren freigeben