In regulierten Branchen ist ein Deployment niemals nur eine technische Aktion — es ist ein auditierbares Ereignis. Banken, Versicherer, Behörden und alle Unternehmen, die dem Sarbanes-Oxley Act, dem Digital Operational Resilience Act (DORA) der EU, der ISO/IEC 27001 oder den Bankaufsichtlichen Anforderungen an die IT (BAIT) der BaFin unterliegen, teilen dieselbe grundlegende Erwartung: Keine einzelne Person darf Code oder Konfiguration unangekündigt und ungeprüft in ein produktionsnahes System überführen können. Genau das ist der Kerngedanke hinter dem Vier-Augen-Prinzip — und einer der am häufigsten genannten Kontrollmechanismen in IT-Audits von Automatisierungsplattformen. Teil 6 der 3C Release Manager for Automic Enablement Series zeigt, wie diese Kontrolle direkt im Deployment-Workflow umgesetzt — und technisch erzwungen — wird.
Vorherige Teile dieser Reihe
Dieser Artikel setzt die 3C Release Manager for Automic Enablement Series fort. Falls Sie die vorherigen Teile verpasst haben, können Sie hier nachlesen:
- Teil 1 – Snapshot-Funktion: Erfassung des vollständigen Zustands eines Automic-Clients als zeitgestempelte Baseline.
- Teil 2 – Diff-Funktion: Vergleich von Snapshots zur Erkennung von Objektänderungen und zur Sicherstellung von Release-Transparenz.
- Teil 3 – Umgebungen anlegen: Definition der technischen Verbindungen zu Automic-Clients, die Snapshots, Diffs und Deployments erst ermöglichen.
- Teil 4 – Kontrollierte Deployments: Transport von Objekten zwischen Clients mit automatischen Backups und definiertem Rollback-Pfad.
- Teil 5 – Add Related: Erfassung verschachtelter Workflow-Abhängigkeiten bis auf Skriptebene in einem einzigen Schritt.
Sind kontrollierte, abhängigkeitsvollständige Transporte erst einmal etabliert, verschiebt sich die nächste Frage von Können wir sicher deployen? hin zu Können wir nachweisen, dass die Änderung autorisiert war? Genau hier setzt diese Kontrolle an.
Warum das Vier-Augen-Prinzip in regulierten Automic-Umgebungen entscheidend ist
Automic Automation steht typischerweise im Zentrum geschäftskritischer Workloads — Zahlungsverarbeitung, regulatorisches Reporting, Supply-Chain-Orchestrierung und Batch-Fenster, auf die sich der Rest des Unternehmens verlässt. Eine Änderung an einem Workflow in dieser Umgebung ist keine isolierte technische Anpassung. Es ist eine Änderung an einem System, dessen Ausfall unmittelbare geschäftliche und — in regulierten Branchen — regulatorische Konsequenzen hat.
Auditoren wissen das, und ihre Fragen sind unangenehm konkret. Wer hat diese Änderung genehmigt? Wann? War der Genehmigende eine andere Person als diejenige, die sie vorbereitet hat? Wo ist der Nachweis? Wenn sich diese Fragen nur mit Screenshots, in E-Mails eingefügten Ticket-Links oder einem „wir vertrauen unserem Team" beantworten lassen, ist die Kontrolle keine echte Kontrolle — sondern ein Ehrensystem. Genau deshalb existiert die Funktionstrennung: Sie soll diese Mehrdeutigkeit beseitigen, indem sie eine unabhängige Autorisierung zur Voraussetzung für die Ausführung macht — und nicht zu einer reinen Verfahrensempfehlung.
In einer klassischen Automic-Umgebung erfordert die Durchsetzung dieser Kontrolle typischerweise einen Flickenteppich aus externen Ticketing-Workflows, manuellen Freigaben in einem Change-Advisory-Board-Tool und operativer Disziplin, die vollständig davon abhängt, dass Menschen daran denken, den Prozess einzuhalten. Der 3C Release Manager for Automic verlagert diese Durchsetzung in das Deployment selbst.
Wie das Vier-Augen-Prinzip im 3C Release Manager durchgesetzt wird
Der Mechanismus ist direkt in die Umgebungskonfiguration eingebaut. Für jede Zielumgebung — typischerweise diejenigen, die Pre-Production- und Production-Clients abbilden — lässt sich die Anzahl der erforderlichen Freigaben in den zusätzlichen Einstellungen festlegen. Wird dieser Wert auf zwei gesetzt, ist die Kontrolle für diese Umgebung aktiv: Jeder Transport, der auf diesen Client zielt, erfordert vor der Ausführung die Freigabe von zwei unterschiedlichen Benutzern.
Die Durchsetzung erfolgt technisch, nicht prozessual. Sobald ein Deployment vorbereitet ist und den Status Preparation Ready erreicht, wird der Run-Button erst dann verfügbar, wenn die erforderliche Anzahl an Freigaben vorliegt. Der Benutzer, der das Paket erstellt und vorbereitet hat, kann zwar seine eigene Freigabe erteilen — diese einzelne Freigabe reicht zur Ausführung jedoch nicht aus. Eine zweite Bestätigung durch einen anderen Benutzer ist zwingend erforderlich. Bis diese zweite Freigabe registriert ist, kann die Ausführung nicht starten — es gibt kein Override, keinen Workaround, kein „dieses eine Mal".
Die kurze Demo unten zeigt den vollständigen Ablauf von Anfang bis Ende: ein von Benutzer A vorbereiteter Transport, der bewusst gesperrte Run-Button und die zweite Freigabe durch Benutzer B, die die Ausführung freischaltet.
Was das tatsächlich für Compliance und Audit bedeutet
Die direkte Einbettung einer unabhängigen Freigabe in das Deployment-Tooling verändert vier Dinge, die für Auditoren, Risk Officer und Release Manager entscheidend sind:
- Funktionstrennung wird nachprüfbar. Die Freigabe ist an die Benutzeridentität gebunden, die sie erteilt hat — nicht an ein Freitextfeld oder eine weitergeleitete E-Mail. Audit-Logs können für jeden Transport exakt nachweisen, welche zwei Benutzer ihn freigegeben haben und wann — und dass es sich tatsächlich um zwei unterschiedliche Personen handelte.
- Die Kontrolle lässt sich unter Druck nicht umgehen. Quartalsende-Druck, dringende Hotfixes und „der andere Genehmiger ist im Urlaub" — das sind genau die Momente, in denen manuelle Prozesse stillschweigend aufweichen. Eine technisch erzwungene Schwelle weicht nicht auf. Entweder die Änderung hat zwei Freigaben — oder sie wird nicht ausgeführt.
- Audit-Nachweise entstehen nebenbei — nicht als eigenes Projekt. Wenn ein Auditor Belege dafür verlangt, dass die Funktionstrennung im letzten Quartal auf Produktionsänderungen angewendet wurde, lautet die Antwort: eine Abfrage gegen die Deployment-Historie — und keine hektische Rekonstruktion aus E-Mail-Archiven, wer was freigegeben hat.
- Release-Governance wird teamübergreifend konsistent. Verschiedene Teams haben oft unterschiedliche Reifegrade in ihren Prozessen. Wird das Vier-Augen-Prinzip auf Umgebungsebene erzwungen, gilt der Standard einheitlich für jede Änderung, die auf diese Umgebung zielt — unabhängig davon, welches Team sie vorbereitet hat.
Wo das Vier-Augen-Prinzip in das übergeordnete Release-Framework passt
Diese Kontrolle ist kein eigenständiges Feature — sie ist eine Ebene in einem Release-Governance-Modell, das der 3C Release Manager durchgängig zusammensetzt. Snapshots liefern die Baseline. Diffs machen Änderungen transparent. Kontrollierte Transporte ergänzen Backups und Rollback. Die rekursive Sammlung verwandter Objekte sorgt für Vollständigkeit. Die Freigabe-Erzwingung fügt die Autorisierung hinzu.
Zusammen beantworten diese Ebenen genau die Fragen, die Auditoren tatsächlich stellen: Wie war der Zustand vorher? Was hat sich geändert? Wer hat die Änderung autorisiert? Ließe sich diese bei Bedarf rückgängig machen? Jede Ebene ist für sich genommen nützlich; ihr Wert potenziert sich, wenn sie gemeinsam als ein einheitlicher, in sich stimmiger Release-Prozess eingesetzt werden.
Für Organisationen, die den ICT-Change-Management-Anforderungen der DORA unterliegen (siehe auch die Hinweise der Deutschen Bundesbank zum Übergang von BAIT zu DORA), den Funktionstrennungs-Anforderungen der BAIT oder einem der vergleichbaren Rahmenwerke für kritische Systeme, ist das der Unterschied zwischen einem behaupteten und einem nachgewiesenen kontrollierten Release-Prozess.
Wichtigste Erkenntnisse
- Die unabhängige Doppelfreigabe gehört zu den am häufigsten geprüften Kontrollen in regulierten IT-Umgebungen und ist eine grundlegende Erwartung unter Rahmenwerken wie SOX, DORA, ISO 27001 und BAIT.
- Der 3C Release Manager for Automic setzt diese technisch durch, indem er pro Umgebung eine konfigurierbare Anzahl an Freigaben durch unterschiedliche Benutzer verlangt, bevor ein Transport ausgeführt werden kann.
- Die Freigabe-Erzwingung ist direkt in den Deployment-Workflow integriert und wird nicht über externes Ticketing aufgesetzt — der Run-Button bleibt gesperrt, bis die erforderliche Schwelle erreicht ist.
- Das Ergebnis ist eine nachprüfbare Funktionstrennung, Audit-Nachweise entstehen als Nebenprodukt des Prozesses, und die Governance bleibt teamübergreifend und über alle Änderungen hinweg konsistent.
- In Kombination mit Snapshots, Diffs, kontrollierten Transporten und rekursiver Objektsammlung vervollständigt diese Kontrolle ein Release-Framework, das sich sauber auf reale Audit-Anforderungen abbilden lässt.
Compliance-konformes Release Management bedeutet nicht, mehr Schritte hinzuzufügen. Es bedeutet sicherzustellen, dass die entscheidenden Schritte von der Plattform erzwungen, automatisch dokumentiert und im Nachgang einfach nachweisbar sind. Der 3C Release Manager for Automic ist genau auf dieses Prinzip ausgelegt.
Möchten Sie sehen, wie sich der 3C Release Manager auf die Audit- und Compliance-Anforderungen Ihrer Organisation abbilden lässt? Vereinbaren Sie ein kostenloses Beratungsgespräch, um Ihre Release-Governance-Landschaft zu besprechen — oder entdecken Sie den vollständigen Automic-Kurspfad an der Tricise University, um Release-Governance-Kompetenz in Ihrem Team aufzubauen.
