Vier-Augen-Prinzip beim Deployment: Freigaben technisch erzwingen

Ziel

Fehler und Missbrauch, die eine einzelne Person – oder ein einzelner Agent mit ihren Rechten – einschleusen könnte, vor der Produktion abfangen, ohne den Ablauf auf Vertrauen und Erinnerung zu stützen.

Voraussetzungen

Ein Versionsverwaltungs- und CI-System, das Regeln pro Zweig und pro Umgebung kennt: GitHub bietet geschützte Zweige und Umgebungen mit «Required reviewers», GitLab Freigaben für Deployments («Deployment approvals»). Mindestens zwei Personen mit Reviewrecht. Ein Deployment, das ausschliesslich aus der CI und nur vom Hauptzweig erfolgt.

Schritte

1. Den Hauptzweig schützen: direkte Pushes verbieten, mindestens eine Freigabe verlangen, Freigaben bei neuen Commits verfallen lassen (GitHub: «Dismiss stale pull request approvals when new commits are pushed»), die Statusprüfungen der CI als Pflicht eintragen.
2. Die eigene Freigabe ausschliessen: Wer den Änderungsvorschlag erstellt, gibt ihn nicht selbst frei. Für sensible Pfade (Deploy-Skripte, Infrastruktur, Rechte) über eine Datei mit Code-Besitzern eine zweite, benannte Gruppe verlangen.
3. Die Produktion als eigene Umgebung mit Freigabepflicht anlegen, sodass der Deploy-Job wartet, bis eine berechtigte Person ihn freigibt – getrennt vom Code-Review, weil Zeitpunkt und Kontext der Auslieferung eine eigene Entscheidung sind.
4. Umgehungen schliessen: Administratoren unterliegen denselben Regeln («Do not allow bypassing the above settings»); Deploy-Zugangsdaten liegen nur in der CI, nicht auf Arbeitsrechnern.
5. Einen Notweg definieren, der das Prinzip verschiebt statt bricht: Ein Notfall-Deployment braucht eine zweite Person am Telefon, wird als solches markiert und spätestens am nächsten Arbeitstag nachträglich reviewt.
6. Regelmässig prüfen: Wer hat Reviewrecht, welche Regeln wurden laut Audit-Log umgangen, welche Freigaben erfolgten so schnell, dass niemand gelesen haben kann.

Erwartetes Ergebnis

Jede Änderung in Produktion lässt sich auf zwei Personen zurückführen: Autorin und Freigebenden. Eine kompromittierte Arbeitsstation oder ein fehlgeleiteter Agent kann allein keinen Stand ausliefern.

Grenzen und Prüfbasis

Das Prinzip prüft, dass jemand hingesehen hat, nicht wie gründlich; Abnick-Reviews entwerten es, und dagegen helfen nur Reviewkultur und Stichproben, keine Werkzeuge. Zwei Personen, die zusammenarbeiten, können es aushebeln; dagegen helfen Protokolle und Rollentrennung. Die genannten Einstellungen folgen der zitierten GitHub- und GitLab-Dokumentation; über die Wirkung auf Fehlerraten wird nichts behauptet.