Das Vier-Augen-Prinzip in Azure Repos setzen Sie um, indem Änderungen nur über Pull Requests in geschützte Ziel-Branches gelangen und dort erst nach Freigabe durch mindestens eine weitere Person abgeschlossen werden. Technisch trägt das nur dann, wenn direkte Pushes auf diese Branches beschränkt und Ausnahmen von Regeln eng gehalten sind.
Damit beantworten Sie die Kernfrage auf Repository-Ebene: Eine Person darf eine Änderung anstoßen, aber nicht allein bis in den geschützten Branch bringen. Alles Weitere baut auf dieser Trennung zwischen Vorschlag, Prüfung und Abschluss auf.
In diesem Beitrag geht es deshalb um drei Punkte:
- den verbindlichen Freigabepunkt im Ablauf
- die Azure-Repos-Einstellungen, die das Vier-Augen-Prinzip stützen
- die Grenze zwischen technischer Erzwingung und organisatorischer Kontrolle
Der Schwerpunkt liegt auf Azure DevOps Services mit Azure Repos. Bei Azure DevOps Server können Funktionen je nach Version abweichen; betrachten Sie Ihre Umgebung deshalb getrennt.
Was Funktionstrennung bei Softwareänderungen verlangt
Funktionstrennung ist zuerst eine organisatorische Anforderung. Gemeint ist: Dieselbe Person soll eine relevante Änderung nicht allein vorbereiten, freigeben und wirksam machen.
Für Git-Abläufe heißt das, Sie betrachten mehr als nur den Merge. Maßgeblich sind auch direkte Push-Rechte auf geschützte Branches, Ausnahmen von Regeln und die spätere Nachvollziehbarkeit der Entscheidung.
Azure Repos bildet davon nur den technischen Ausschnitt ab. Sie können den Weg über Pull Requests erzwingen und Freigaben dokumentieren. Ob beteiligte Personen organisatorisch wirklich unabhängig sind, erkennt das System nicht, etwa bei Vertretungen, Gruppenverschachtelungen oder gemeinsam genutzten Konten.
Die technische Basis sind Branch Policies. Nach Microsoft Learn in „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026, sind sie standardmäßig ausgeschaltet und müssen je Branch bewusst gesetzt werden.
Für Funktionstrennung sind vor allem diese Regeln relevant:
- Mindestzahl an Reviewern
- automatisch eingeschlossene Reviewer
- Status Checks
- Build Validation
- verknüpfte Work Items
- Kommentarauflösung
Ein Status Check ist ein maschinenlesbares Prüfergebnis, das ein Dienst an einen Pull Request meldet und das per Policy verlangt werden kann.
Nicht dazu gehört „Limit merge types“ als eigentliche Trennungskontrolle. Laut Microsoft Learn „Securely use repositories and pull requests“, gelesen am 01.11.2026, steuert diese Einstellung vor allem die Historie. Wenn Sie die technischen Ausnahmen rund um Freigaben und Schutzregeln prüfen, ist der nächste Blick auf Rechte für Push, Merge und Regelumgehung sinnvoll.
Minimum Reviewers, Selbstfreigabe und letzter Pusher
Für zentrale Branches wie main empfiehlt Microsoft in seiner Sicherheitsbaseline, die Berechtigungen Bypass policies when completing pull requests und Bypass policies when pushing auf eine kleine Admin-Gruppe zu beschränken und mindestens zwei Reviewer zu verlangen. Das steht in Microsoft Learn „Securely use repositories and pull requests“, gelesen am 01.11.2026. Für das Vier-Augen-Prinzip ist das ein sinnvoller Ausgangspunkt, weil damit sowohl Ausnahmen als auch normale Freigaben enger gefasst werden.
Die Mindestzahl allein reicht aber nicht. Wenn die antragstellende Person ihre eigene Änderung mitfreigeben darf, kann eine formale Zahl von Reviewern organisatorisch trotzdem zu schwach sein.
Deshalb ist in der Reviewer-Policy vor allem die Option Allow requestors to approve their own changes wichtig. Für strikte Funktionstrennung sollte diese Option nicht erlaubt sein. Quelle: Microsoft Learn „Branch policies“, gelesen am 01.11.2026.
Eine zweite Schutzschicht ist Prohibit the most recent pusher from approving their own changes. Diese Einstellung zielt auf den häufigen Fall, dass nach einem ersten Review noch einmal Commits in den Pull Request kommen. Dann soll nicht dieselbe Person die letzte Fassung selbst absegnen können. Auch diese Option ist in Microsoft Learn „Branch policies“, gelesen am 01.11.2026, dokumentiert.
Praktisch oft noch wichtiger ist die Iterationslogik. Mit Require at least one approval on the last iteration stellen Sie sicher, dass nach dem letzten Push noch eine Freigabe auf dem aktuellen Stand vorliegt. Historische Zustimmungen auf älteren Iterationen helfen für reale Funktionstrennung meist weniger.
Strenger sind die Varianten Reset all approval votes und Reset all code reviewer votes. Sie erzwingen nach Änderungen eine erneute Bewertung. Das kann die Kontrolle schärfen, erhöht aber den Review-Aufwand.
Für Azure DevOps Server grenzt Microsoft den Funktionsumfang ab: Ab Server 2022.1 und höher gibt es zusätzlich die Option, auf jeder Iteration eine Freigabe zu verlangen. Quelle jeweils: Microsoft Learn „Branch policies“, gelesen am 01.11.2026. Zwischen Services und Server sollten Sie daher nicht von identischem Verhalten ausgehen.
Ergänzend empfiehlt Microsoft für sensible Pfade automatisch eingeschlossene Reviewer. Das ersetzt keine unabhängigen Reviewer insgesamt, kann aber für bestimmte Verzeichnisse oder Komponenten die Trennung von Verantwortung stabiler machen. Mehr dazu finden Sie bei Pflicht-Reviewern in Azure Repos.
Die Kontrolle für Audits und interne Prüfungen dokumentieren
Für Prüfungen zählt vor allem, ob Ihre Konfiguration reproduzierbar und nachvollziehbar belegt ist. Sinnvoll ist deshalb ein kleiner Sollstand je kritischem Ziel-Branch: zuständige Repositorys, aktive Policies, erlaubte Ausnahmen, verantwortliche Gruppen und der Weg, wie Änderungen an diesen Einstellungen freigegeben werden.
Hilfreich sind dabei wenige, feste Nachweise:
- Export oder strukturierte Erfassung der aktiven Branch Policies je Ziel-Branch
- Zuordnung der Policy-Ausnahmen und Bypass-Berechtigungen zu benannten Admin-Gruppen
- Nachweis, welche Build-Validierung für Pull Requests gefordert ist
- Definition, welche Status Checks erforderlich sind und von welchem Dienst sie kommen
- kurzer Ablauf für Notfälle, inklusive nachgelagerter Prüfung und Dokumentation
Für die laufende Kontrolle ist wichtig, dass sich Policies laut Microsoft Learn „Branch policies overview“ und „Branch policies“, gelesen am 01.11.2026, per REST API oder mit az repos policy verwalten lassen. Das eignet sich, um Abweichungen gegen einen Sollstand regelmäßig festzustellen oder Änderungen gezielt freizugeben. Den technischen Weg dazu behandelt der Beitrag zu Pull Requests per REST API.
Prüfbar sollte außerdem sein, wie Sie offene Diskussionen behandeln. Wenn Kommentare vor dem Abschluss eines Pull Requests geklärt sein müssen, gehört diese Anforderung in den dokumentierten Kontrollpfad. Die praktische Wirkung der Einstellung zeigt der Beitrag zu offenen Threads vor dem Merge.
Falls Ihr Audit-Modell die genaue Commit-Reihenfolge auswertet, dokumentieren Sie zusätzlich die zugelassenen Merge-Strategien. Microsoft Learn „Securely use repositories and pull requests“, gelesen am 01.11.2026, beschreibt Limit merge types dabei als Governance der Historie, nicht als eigentlichen Freigabenachweis.
Grenzen der technischen Kontrolle in Azure Repos
Technik kann Freigaben erzwingen, aber nicht deren organisatorische Qualität bewerten. Azure Repos sieht Stimmen, Status und Policy-Ergebnisse. Nicht sichtbar ist, ob zwei beteiligte Personen im Alltag tatsächlich unabhängig handeln, ob Vertretungen problematisch sind oder ob gemeinsame Konten den Kontrollgedanken unterlaufen.
Auch ergänzende Automatisierung ändert diese Grenze nicht. Ein externer Prüfdienst kann Ergebnisse an Pull Requests melden; wie solche Signale in den Ablauf kommen, zeigt der Beitrag zu Statusmeldungen über Service Hooks. Für das Vier-Augen-Prinzip bleibt aber entscheidend: Ein maschinelles Ergebnis ist keine menschliche Freigabe.
Das gilt ebenso für KI-gestützte Reviews. Nach Microsoft Learn „Copilot code reviews“ und den Release Notes Sprint 279, jeweils gelesen am 01.11.2026, kann die Funktion in Azure DevOps Services automatisch über Branch Policies ausgelöst werden. Zugleich nennt Microsoft klare Grenzen:
- nur Public Preview, also ohne SLA und mit möglicher Änderung
- nur aktive Pull Requests ohne Merge-Konflikte
- nur innerhalb der dokumentierten Größen- und Parallelitätsgrenzen
Für die eigentliche Freigabelogik ist vor allem ein Punkt wichtig: Laut Microsoft Learn „Review pull requests“, gelesen am 01.11.2026, entsteht immer ein Comment review. Das erfüllt keine Required-Reviewer-Policy und ersetzt keinen verpflichtenden Reviewer.
Daneben gibt es Betriebs- und Rechtsfragen außerhalb der Branch Policy. Microsoft schreibt in „Copilot code reviews FAQ“, gelesen am 01.11.2026, dass die Datenresidenz dieser Review-Funktion nicht an die Datenresidenzgrenzen der Azure-DevOps-Organisation gebunden ist. Fragen zu Datenschutz, DORA, NIS2 oder Mitbestimmung sollten Sie daher mit Rechtsberatung oder Datenschutzbeauftragten prüfen.
Falls Sie Pull Requests zunächst bewusst unfertig halten, betrifft das eher den Umgang mit Draft-Pull-Requests als die technische Trennung von Freigabe und Umsetzung.
Häufige Fragen
Woran erkennen Sie, ob Ihr Vier-Augen-Prinzip nur formal oder auch belastbar umgesetzt ist?
Ein belastbarer Aufbau zeigt sich meist nicht an einer einzelnen Policy, sondern an der Kombination mehrerer Sperren. Entscheidend ist, ob Ihr geschützter Branch auch dann geschützt bleibt, wenn jemand unter Zeitdruck arbeitet, eine Ausnahme braucht oder eine Berechtigung zu weit gefasst ist.
Achten Sie deshalb auf diese Punkte im Zusammenspiel:
- direkte Schreibrechte auf Ziel-Branches
- kleine und benannte Gruppen für Bypass-Berechtigungen
- Review-Pflichten auf der letzten Änderung
- dokumentierte Status- und Build-Anforderungen
- nachvollziehbare Behandlung von Ausnahmen
Wenn Sie technische und organisatorische Annahmen auseinanderhalten wollen, hilft ein Blick auf Sicherheits- und Datenfragen: dort sollte jeweils klar erkennbar sein, was heute gilt, was nur vorgesehen ist und welcher Stand mit Datum beschrieben wird.
Welche Fragen sind vor einer Freigabe für produktive Repositories oft noch offen?
Vor dem Rollout lohnt sich eine kurze Vorabprüfung außerhalb des Repositorys. Dabei geht es nicht nur um Git-Einstellungen, sondern auch um Betriebsmodell, Verantwortlichkeiten und mögliche Nebenwirkungen auf interne Kontrollen.
Typische Fragen sind:
- Wer darf Schutzregeln ändern?
- Wer entscheidet in Notfällen?
- Wie werden Ausnahmen später geprüft?
- Welche Identitäten dürfen technisch wirksam werden?
- Müssen Datenschutz, DORA, NIS2 oder Mitbestimmung gesondert betrachtet werden?
Gerade die letzte Gruppe ist keine reine Konfigurationsfrage. Klären Sie solche Punkte mit Rechtsberatung oder Datenschutzbeauftragten.
Wie verfolgen Sie bei künftigen Agentenfunktionen den tatsächlichen Stand?
Sinnvoll ist ein nüchterner Prüfpfad statt einer Erwartung an Ankündigungen. Schauen Sie getrennt auf öffentlich sichtbare Änderungen, auf belegte Messwerte und auf den jeweils beschriebenen Anmelde- oder Betriebsrahmen.
Dafür eignen sich drei Fragen:
- Was wurde öffentlich geändert? Sie sehen das im Änderungsverlauf.
- Was ist tatsächlich gemessen? Dafür ist der Nachweisbereich gedacht; bis zu realen Läufen bleibt er leer.
- Was ist zum Zugang beschrieben? Das steht im Abo- und Anmelderahmen.
Im Schlussteil dieses Beitrags ist dazu bereits eingeordnet: Polier von ballmüller solutions ist Stand 01.11.2026 in Entwicklung und nicht verfügbar.
Nächster Schritt
Legen Sie für jeden geschützten Branch einen kurzen Prüfpunkt fest, bevor Sie Änderungen an Policies oder Berechtigungen freigeben. So bleibt die Frage klar, ob Ihr Vier-Augen-Prinzip im Alltag tatsächlich an den entscheidenden Stellen greift.
Prüfen Sie dabei insbesondere:
- wer Policies ändern darf
- wer Bypass-Rechte hat
- ob Freigaben auf der letzten relevanten Änderung beruhen
- ob Pflicht-Reviewer und Status Checks zum Schutzbedarf passen
- wie Ausnahmen dokumentiert und später nachvollzogen werden
Mit Blick auf mögliche Agentenfunktionen reicht derselbe Maßstab. Polier von ballmüller solutions ist Stand 01.11.2026 in Entwicklung und nicht verfügbar; vorgesehen für Azure DevOps Services, mit den bestehenden Branch Policies des Kunden, und der Agent selbst merged nie.