Azure DevOps: Einrichtung und Leitprinzipien¶
Viele Workload-Teams bauen und deployen mit Azure DevOps. Die Plattform kann für deinen Spoke ein Repository und eine Service Connection anlegen (Was du bekommst), aber die Azure-DevOps-Organisation und ihre Projekte gehören deiner Organisation. Diese Seite sammelt empfohlene Einstellungen (Guardrails) und eine sinnvolle Projektstruktur.
Empfehlungen, keine Plattform-Features
Das MCP-Produkt konfiguriert deine Azure-DevOps-Organisation nicht. Verstehe die Listen unten als Baseline, die dein Security Officer und deine DevOps-Administratoren anpassen. Wo deine Organisation eigene Regeln hat, gelten diese.
Organisation, Projekt, Team¶
| Ebene | Was es ist | Empfehlung |
|---|---|---|
| Organisation | Oberster Container, verbunden mit Microsoft Entra ID und der Abrechnung | Wenige. Meist eine pro Unternehmen. |
| Projekt | Repositories, pipelines, Boards, Test Plans, mit eigenen Berechtigungen | Ein Projekt pro Produkt oder Anwendungsbereich. |
| Team | Eine Gruppe innerhalb eines Projekts mit eigenem Board und Backlog | Eines pro DevOps-Team. |
Ein Projekt oder mehrere?
| Ansatz | Geeignet für |
|---|---|
| Einzelnes Projekt | Kleine und mittlere Organisationen, einfache Berechtigungen, einfache Navigation zwischen den Komponenten eines Produkts |
| Mehrere Projekte | Große Organisationen mit unabhängigen Teams. Bessere Isolation und unterschiedliche Security-, Build- und Release-Anforderungen pro Projekt |
Wähle, was du willst, aber bleib konsequent. Repositories und pipelines später zwischen Projekten zu verschieben, ist Arbeit.
Organisationsebene¶
| Guardrail | Warum |
|---|---|
| Ein nicht-persönliches Konto besitzt die Organisation, und der Zugriff darauf erfolgt nur per Eskalation | Menschen verlassen das Unternehmen; ein persönlicher Owner ist ein Single Point of Failure |
| Zugriff nur mit Entra-ID-Identitäten, über Gruppen | Eintritte und Austritte folgen deinem Identity-Prozess |
| Eingebaute Gruppen bleiben leer, außer ihren Standardmitgliedern. Das nicht-persönliche Konto ist in Project Collection Administrators. | Keine Berechtigungen durch vergessene Mitgliedschaften |
| Privilegierte Rollen (zum Beispiel Project Collection Administrators) nur über PIM | Just-in-time-Zugriff mit Audit-Trail. Siehe Zugriff, Gruppen und PIM. |
| Alternative Authentifizierungsdaten deaktivieren | Kleinere Angriffsfläche |
| Zugriff von Drittanwendungen über OAuth deaktivieren | Kontrolle über Integrationen |
| SSH-Authentifizierung erlauben | Eine sichere Alternative für Git |
| Audit-Log-Events aktivieren | Audit-Trail und Untersuchung von Incidents |
| Öffentliche Projekte deaktivieren | Keine versehentliche Offenlegung |
| Zusätzlichen Schutz für öffentliche Package Registries aktivieren | Schützt vor kompromittierten oder schädlichen Packages |
| IP Conditional Access Validation bei nicht-interaktiven Flows aktivieren | Deckt auch Service Connections ab |
| Externen Gastzugriff deaktivieren | Die Zusammenarbeit bleibt intern |
| Team- und Projektadministratoren dürfen keine Benutzer einladen | Zentrales Onboarding |
Pipelines¶
| Guardrail | Warum |
|---|---|
| Niemand löscht Builds, Releases, Projekte oder Repositories | Eine vollständige, prüfbare Historie. Nutze stattdessen Retention Policies. |
| Genehmigung auf der Produktionsstage ist Pflicht. Führe Release-pipelines nur von bestimmten Produktions-Branches aus. | Kontrollierte, prüfbare Produktions-Deployments |
| Definiere pipelines in YAML. Schalte klassische Build- und Release-pipelines ab. | Änderungen werden geprüft und sind in der Versionsverwaltung nachvollziehbar |
| Aktiviere Enforce settable at queue time für Variablen, begrenze die Variablen, die beim Queuen gesetzt werden können, und erlaube nicht, im Editor gesetzte Variablen zu überschreiben | Reproduzierbare Läufe und weniger Injection-Möglichkeiten |
| Erlaube Benutzern nicht, sicherheitskritische pipelines gegen beliebige Branches oder Tags auszuführen | Nur geprüfter Code erreicht die Produktion |
| Deaktiviere die Vererbung an der pipeline und begrenze in jedem Fall den Job Authorization Scope | Least Privilege |
| Vermeide remote geladene Ressourcen. Wenn du eine brauchst, fixiere die Version und prüfe einen Hash. | Sicherheit der Supply Chain |
| Logge keine Secrets. Halte keine Secrets in pipeline-Variablen: Nutze Azure Key Vault. Wenn das nicht geht, nutze Secret-Variablen, begrenze, wer sie lesen darf, und speichere keine strukturierten Daten (zum Beispiel JSON) als Secret. | Secrets bleiben aus Logs und pipeline-Definitionen heraus |
| Secrets auditieren und rotieren | Begrenzt die Zeit, in der ein geleaktes Secret nützlich ist |
| Nutze Service Connections, statt Zugangsdaten durchzureichen, beschränke sie auf die Ressourcen und Resource Groups, die sie brauchen, und nutze keine Azure-Classic-Service-Connections | Least Privilege, zentrale Verwaltung |
| Nutze PATs sparsam und rotiere sie. Erwäge stattdessen Service Principals (oder Workload Identity Federation). | PATs sind mächtig und personengebunden |
| Baue keine pull requests aus GitHub-Forks. Wenn doch, gib ihnen keine Secrets und löse sie manuell aus. | Nicht vertrauenswürdiger Code darf nicht mit deinen Zugangsdaten laufen |
| Halte pipeline-Abhängigkeiten mit einem Tool wie Renovate aktuell | Weniger bekannte Schwachstellen |
Die Service Connection, die die Plattform für deinen Spoke anlegt, kann statt eines Secrets föderierte Credentials verwenden, siehe So änderst du und So nutzt du.
Repositories und Branches¶
| Guardrail | Warum |
|---|---|
| Konfiguriere Branch Policies auf dem Main-Branch und erlaube kein Umgehen | Die Regeln gelten für alle |
| Verlange eine Mindestanzahl an Reviewern (zwei sind üblich) und mindestens eine Genehmigung für die letzte Iteration | Unabhängige Prüfung dessen, was gemergt wird |
| Wer zuletzt gepusht hat, kann die eigene Änderung nicht genehmigen | Vier-Augen-Prinzip |
| Verknüpfe jeden pull request mit einem Work Item | Nachvollziehbarkeit |
| Löse alle Kommentare, bevor du einen pull request abschließt | Feedback geht nicht verloren |
| Verlange einen erfolgreichen Build für den pull request | Fehler vor dem Merge finden |
| Speichere Produktions-Secrets in einem separaten Key Vault, mit Zugriff nach dem Need-to-know-Prinzip | Trennung von Produktion und Nicht-Produktion |
| Vermische Testumgebungen und Produktion nicht, auch nicht ihre Zugangsdaten | Verhindert Unfälle und Datenlecks |
| Forking deaktivieren | Kontrolle über Code und Secrets |
Agents¶
| Guardrail | Warum |
|---|---|
| Vergib Berechtigungen auf Agent Pools an möglichst wenige Konten | Kleinere Angriffsfläche |
| Nutze die restriktivste Firewall, mit der die Agents noch nutzbar bleiben | Begrenzt, was ein kompromittierter Build erreichen kann |
| Aktualisiere die Pools regelmäßig, damit die Build-Flotte keine verwundbare Software betreibt | Siehe Build Agents |
| Nutze einen separaten Pool für Builds, die in die Produktion ausliefern oder deployen | Trennung |
| Trenne sensible Pools von den übrigen und nutze Zugangsdaten nur in pipelines, die auf bestimmte Pools festgelegt sind | Zugangsdaten gelangen nicht in nicht vertrauenswürdige Jobs |
Das Projekt der Plattform für Workload-Teams öffnen (optional)¶
Manche Plattform-Teams betreiben ein eigenes Azure-DevOps-Projekt mit Wiki, Board und Repositories (zum Beispiel für die Definitionen der Firewallregeln). Wenn du Workload-Teams dort eingeschränkten Zugriff gibst, beschleunigt das die Arbeit:
| Was | Zugriff | Warum |
|---|---|---|
| Wiki mit Plattform-Dokumentation | Lesen, für jedes onboardete Team | Teams finden die Konzepte und Anleitungen selbst |
| Board | Lesen | Teams können ihre eigenen Anfragen verfolgen, wenn Tickets mit dem Board synchronisiert werden |
| Repository mit Firewallregeln | Lesen | Teams sehen, welche Regeln für sie gelten und ob die Firewall ihren Traffic blockiert |
| Pull requests auf dieses Repository | Pro Team, nach Absprache | Ein pull request lässt sich leichter validieren als eine schriftliche Anfrage. Das Plattform-Team genehmigt und deployt weiterhin, und ein Ticket ist weiterhin nötig. |
Vergib den Zugriff über eine Reader-Gruppe in Microsoft Entra ID, der du die Gruppen jedes onboardeten Teams hinzufügst, und nicht an einzelne Personen. Lass die übrigen Repositories geschlossen. Das Konfigurations-Repository der Plattform zu öffnen, ist eine Entscheidung des Plattform-Teams: Lies zuerst Betriebsmodelle und Firewallregeln.