17 — DevOps im regulierten Umfeld
Teil G — Wie man es im regulierten Umfeld macht. Zurück zur Übersicht.
Lernziel
Nach diesem Kapitel kannst du erklären, warum Continuous Delivery und aufsichtsrechtliche Anforderungen kein Widerspruch sind, kennst die Rolle der Standardänderung als zentralen Hebel und weißt, wie sich Funktionstrennung und Vier-Augen-Prinzip technisch statt organisatorisch erzwingen lassen.
Keine Rechtsberatung. Dieses Kapitel ordnet technische Verfahren in einen regulatorischen Zusammenhang ein. Es ersetzt weder die Abstimmung mit der eigenen Compliance-Abteilung noch die Prüfung durch die Innenrevision. Regulatorische Anforderungen ändern sich; der hier beschriebene Stand ist zu verifizieren.
17.1 Der vermeintliche Widerspruch
Die verbreitete Annahme lautet: Automatisierte Auslieferung und Aufsichtsrecht schließen einander aus. Wer mehrmals täglich ausliefert, kann kein Vier-Augen-Prinzip einhalten, keine Funktionstrennung gewährleisten und keine Nachweise führen.
Das Gegenteil ist der Fall — und zwar nicht als Behauptung, sondern aus der Natur der Sache:
| Anforderung | Manueller Betrieb | Automatisierte Kette |
|---|---|---|
| Wer hat die Änderung veranlasst? | Ticket, sofern gepflegt | Git-Commit mit Signatur |
| Wer hat freigegeben? | Unterschrift oder Mailfreigabe | Pull-Request-Genehmigung, unveränderlich |
| Was läuft in Produktion? | Vermutung, Inventarliste | Image-Digest, kryptografisch eindeutig |
| Wurde getestet? | Testprotokoll, händisch | Pipeline-Protokoll, automatisch |
| Ist die Konfiguration wie vorgesehen? | letzte Prüfung vor acht Monaten | laufender Soll-Ist-Abgleich |
| Kann zurückgerollt werden? | Sicherung, Dauer unbekannt | gemessen, geübt, dokumentiert |
Der entscheidende Punkt: In einer automatisierten Kette fallen die Nachweise als Nebenprodukt an. Niemand muss sie erzeugen, niemand kann sie vergessen, und niemand kann sie nachträglich verändern.
Ein manueller Prozess mit sorgfältig geführten Formularen ist nachweislich schlechter dokumentiert als eine Pipeline, die nichts dokumentiert, aber alles protokolliert. Der Unterschied liegt in der Fälschungssicherheit und in der Vollständigkeit — ein Formular kann man vergessen, einen Commit nicht.
17.2 Der regulatorische Rahmen
DORA — die Verordnung
Die Verordnung (EU) 2022/2554, der Digital Operational Resilience Act, gilt seit dem <cite index=„17-1“>17. Januar 2025</cite> unmittelbar. Sie regelt für Finanzunternehmen — Banken, Versicherungen, Kapitalverwaltungsgesellschaften, Zahlungsdienstleister und weitere — den Umgang mit IKT-Risiken.
Fünf Themenbereiche:
- IKT-Risikomanagement
- Behandlung und Meldung IKT-bezogener Vorfälle
- Testen der digitalen operationalen Widerstandsfähigkeit
- Management des Risikos durch IKT-Drittdienstleister
- Informationsaustausch
Wichtig für die Einordnung: Um Doppelregulierung zu vermeiden, hat die BaFin die nationalen Rundschreiben <cite index=„20-1“>KAIT, VAIT und ZAIT mit Ablauf des 16. Januar 2025 aufgehoben</cite>. Für Versicherungsunternehmen im Anwendungsbereich ist damit DORA das maßgebliche Regelwerk, nicht mehr die VAIT.
Die BAIT werden <cite index=„20-1“>schrittweise aufgehoben</cite>; für Institute, die ein IKT-Risikomanagement nach DORA betreiben müssen, gelten sie bereits seit dem 17. Januar 2025 nicht mehr.
Praktisch bleiben viele Inhalte der aufgehobenen Rundschreiben relevant: Was dort gefordert wurde, findet sich überwiegend in DORA wieder, und etabliertes Vorgehen aus der VAIT-Zeit gilt weiterhin als gute Praxis. Wer in älteren Unterlagen auf VAIT-Verweise stößt, sollte sie aber gegen die entsprechenden DORA-Artikel abgleichen.
Weitere Rahmenwerke
| Rahmen | Betrifft | Bezug zu DevOps |
|---|---|---|
| DSGVO | personenbezogene Daten | Testdaten, Logs, Aufbewahrung |
| ISO 27001 | Informationssicherheit allgemein | Änderungsmanagement, Zugriffskontrolle |
| BSI IT-Grundschutz | öffentlicher Sektor, oft freiwillig | Härtung, Dokumentation |
| ITIL 4 | Betriebsprozesse | Änderungs- und Störungsmanagement |
| KRITIS / NIS-2 | kritische Infrastrukturen | Meldepflichten, Nachweise |
17.3 Funktionstrennung und Vier-Augen-Prinzip
Die Kernanforderung: Wer eine Änderung entwickelt, darf sie nicht allein in Produktion bringen.
Das klingt nach einem Ausschlusskriterium für Continuous Deployment — ist aber nur eines für unbeaufsichtigtes Continuous Deployment. Continuous Delivery aus Kapitel 6 erfüllt die Anforderung vollständig.
Technische Umsetzung
Entwickler Prüfer Automatik
│ │ │
Commit ─────────────┼──────────────────┼──► Git
│ │ │
│ Pull Request │
│ genehmigen ────────────┼──► Nachweis:
│ │ │ wer, wann, was
│ │ Pipeline
│ │ baut, testet
│ │ │
│ Freigabe im │
│ Konfig-Repo ───────────┼──► Vier Augen erneut
│ │ │
│ │ GitOps-Abgleich
│ │ rollt aus
▼ ▼ ▼
Kein Mensch hat Produktionszugriff. Niemand kann
allein eine Änderung produktiv setzen.
| Anforderung | Technische Entsprechung |
|---|---|
| Vier-Augen-Prinzip | Branch-Schutz mit erforderlicher Genehmigung |
| Entwickler ≠ Freigeber | Pull Request kann nicht selbst genehmigt werden |
| Funktionstrennung | Kein Personenkonto hat Produktionszugriff — nur die Automatik |
| Nachvollziehbarkeit | Git-Historie, signierte Commits, Pipeline-Protokolle |
| Unveränderlichkeit | geschützte Zweige, keine Historienänderung möglich |
Der stärkste Einzelhebel: Wenn kein Mensch mehr auf Produktion schreiben kann, ist die Funktionstrennung nicht mehr eine Regel, die eingehalten werden soll, sondern eine Eigenschaft des Systems.
Das ist qualitativ etwas anderes. Eine organisatorische Regel kann umgangen werden — im Notfall, unter Zeitdruck, mit den besten Absichten. Eine technische Eigenschaft kann es nicht. Und für die Prüfung ist der Unterschied erheblich: Statt Stichproben in Protokollen zu ziehen, lässt sich die Berechtigungsstruktur einmal belegen.
17.4 Die Standardänderung — der zentrale Hebel
Hier liegt der praktische Schlüssel zum gesamten Kapitel. ITIL kennt drei Änderungsarten:
| Art | Merkmal | Freigabe |
|---|---|---|
| Normal Change | Einzelfall, Risikobewertung nötig | Änderungsgremium |
| Standard Change | wiederkehrend, vorab genehmigt, geringes Risiko | vorab genehmigt |
| Emergency Change | dringend, nachträgliche Aufarbeitung | Notfallverfahren |
Der Engpass in der Wertstromanalyse aus Kapitel 16 — vierzehn Tage Wartezeit bis zur nächsten Gremiumssitzung — betrifft ausschließlich den Normal Change.
Eine Standardänderung ist einmal bewertet und dauerhaft genehmigt. Sie wird nicht erneut vorgelegt; sie wird protokolliert.
Was ein Antrag auf Standardänderung enthalten muss
- eine genaue Beschreibung des Änderungstyps und seiner Abgrenzung
- die Risikobewertung, warum das Risiko gering ist
- den vollständigen automatisierten Ablauf inklusive aller Prüfschritte
- das Rückrollverfahren mit gemessener Dauer
- die anfallenden Nachweise und ihre Aufbewahrung
- die Abbruchbedingungen — wann greift das Verfahren nicht?
Ein Formulierungsbeispiel, das sich bewährt hat:
„Änderungen an der Anwendung KFZ-Rechner, die über die definierte Pipeline ausgeliefert werden, gelten als Standardänderung, sofern: die Pipeline vollständig grün ist, ein Vier-Augen-Review im Pull Request dokumentiert ist, keine Datenbankmigration mit Datenverlustpotenzial enthalten ist, keine Schnittstelle zu Drittsystemen verändert wird und das Rückrollverfahren verfügbar ist. Trifft eine dieser Bedingungen nicht zu, gilt die Änderung als Normal Change.„
Der letzte Satz ist der wichtigste. Er macht aus der Standardänderung keine Generalermächtigung, sondern eine klar abgegrenzte Kategorie — und genau das ist es, was ein Prüfer sehen will.
Das ist der Punkt, an dem sich die Durchlaufzeit tatsächlich ändert. Alles Vorherige in dieser Unterlage — Tests, Pipeline, Rollback, Überwachung — dient letztlich der Begründung, warum das Risiko gering genug für diese Einstufung ist.
17.5 Nachweisführung
Was bei einer Prüfung tatsächlich gefragt wird, und woher die Antwort kommt:
| Frage | Quelle | Aufbewahrung |
|---|---|---|
| Welche Version läuft seit wann? | Git-Historie des Konfigurationsrepositories | dauerhaft |
| Wer hat entwickelt, wer freigegeben? | Commit und Pull-Request-Genehmigung | dauerhaft |
| Wurde getestet, mit welchem Ergebnis? | Pipeline-Protokoll, Testberichte | nach Vorgabe, oft mehrere Jahre |
| Welche Komponenten sind enthalten? | SBOM aus Kapitel 14 | je Release |
| Wurde auf Schwachstellen geprüft? | Scanner-Berichte | je Release |
| Wer hatte Zugriff auf Produktion? | Rechteverwaltung, Protokolle | laufend |
| Wie wurde eine Störung bearbeitet? | Postmortem aus Kapitel 13 | je Vorfall |
| Entspricht die Konfiguration der Vorgabe? | Ergebnis des Soll-Ist-Abgleichs | laufend |
Der Nachweis, der am meisten Eindruck macht, ist der nächtliche Soll-Ist-Abgleich aus Kapitel 9. Er belegt nicht, dass die Konfiguration bei der letzten Prüfung stimmte, sondern dass sie jeden Tag geprüft wird und Abweichungen gemeldet werden.
Das ist die Antwort auf die unangenehmste Prüfungsfrage überhaupt: „Woher wissen Sie, dass sich seit der letzten Prüfung nichts geändert hat?“
Zwei technische Anforderungen an Protokolle: Sie müssen unveränderlich sein — Anhängen erlaubt, Ändern nicht — und sie brauchen eine verlässliche Zeitquelle. Ein Protokoll auf einem System, auf dem die Betroffenen Schreibrechte haben, ist als Nachweis wertlos.
17.6 Notfalländerungen
Der Fall, in dem alle Verfahren unter Druck geraten: Produktion steht, die Korrektur ist bekannt, das Gremium tagt am Donnerstag.
Ein tragfähiges Notfallverfahren regelt vorher:
- Wer darf auslösen? Namentlich benannter Personenkreis, keine Improvisation.
- Was ist erlaubt? Der reguläre Weg mit verkürzter Freigabe — nicht das Umgehen aller Prüfungen.
- Wie wird protokolliert? Automatisch, mit Begründung im Commit.
- Was passiert danach? Nachträgliche Vorlage, Postmortem, Prüfung binnen einer festen Frist.
Die Häufigkeit von Notfalländerungen ist eine Kennzahl für sich.
Ein einstelliger Anteil ist normal. Liegt der Anteil bei einem Drittel, ist der reguläre Weg zu langsam — und das Notfallverfahren dient nicht mehr dem Notfall, sondern der Umgehung. Das fällt bei jeder ernsthaften Prüfung auf, und es ist deutlich unangenehmer zu erklären als eine hohe Auslieferungsfrequenz.
Der richtige Schluss aus vielen Notfalländerungen ist nicht, das Notfallverfahren zu verschärfen, sondern den regulären Weg zu beschleunigen.
17.7 Datenschutz in der Auslieferungskette
Zusammengefasst, was in den vorherigen Kapiteln verstreut steht:
| Stelle | Risiko | Maßnahme | Kapitel |
|---|---|---|---|
| Testdaten | Produktivdaten im Testsystem | synthetische Daten | 4 |
| Logs | personenbezogene Daten in der zentralen Sammlung | Verweise statt Inhalte | 12 |
| Fehlermeldungen | Eingabedaten im Stacktrace | Ausgabe begrenzen | 12 |
| Sicherungen | Aufbewahrungsfristen | Löschkonzept, auch für Sicherungen | 6 |
| Pipeline-Protokolle | Daten in Testausgaben | keine echten Daten in Tests | 7 |
| Container-Images | Konfiguration mit Daten eingebacken | Konfiguration von außen | 10 |
17.8 Lab
Aufgabe 1 — Antrag auf Standardänderung. Formuliere für den KFZ-Rechner einen vollständigen Antrag nach der Gliederung aus 17.4. Achte besonders auf die Abbruchbedingungen: Welche Änderungen sollen ausdrücklich nicht als Standardänderung gelten?
Aufgabe 2 — Prüfungssimulation. Lass dir von jemandem die acht Fragen aus 17.5 stellen und beantworte sie ausschließlich mit Belegen aus deinen Systemen. Wo du improvisieren musst, fehlt ein Nachweis.
Aufgabe 3 — Berechtigungen. Prüfe für ein Produktivsystem: Welche Personenkonten haben Schreibzugriff? Ist jedes davon begründet? Was wäre nötig, um die Liste auf null zu bringen?
Aufgabe 4 — Gegenprobe. Nimm eine tatsächliche Produktivänderung der letzten Wochen und versuche, den vollständigen Weg von der Anforderung bis zum laufenden Prozess lückenlos zu belegen. Notiere jede Lücke.
Aufgabe 4 ist die aufschlussreichste. In den meisten Umgebungen bricht die Kette an einer bestimmten Stelle — typischerweise zwischen „das Ticket wurde geschlossen„ und „diese Binärdatei läuft auf diesem Server“. Genau diese Lücke schließt der Image-Digest.
17.9 Anti-Pattern
| Anti-Pattern | Folge | Abhilfe |
|---|---|---|
| „Regulierung verbietet Automatisierung„ | Stillstand mit falscher Begründung | Anforderungen lesen, nicht vermuten |
| Freigabe als Formalie ohne Kenntnis | Vier-Augen-Prinzip nur auf dem Papier | Änderungsliste automatisch beilegen |
| Notfalländerung als Regelweg | fällt bei jeder Prüfung auf | regulären Weg beschleunigen |
| Nachweise nachträglich erzeugen | lückenhaft, angreifbar | als Nebenprodukt anfallen lassen |
| Personenkonten mit Produktionszugriff | Funktionstrennung nicht belegbar | ausschließlich über die Automatik |
| Compliance erst am Projektende | teure Umbauten | Anforderungen im Entwurf klären |
| Protokolle auf dem geprüften System | als Nachweis wertlos | getrennte, unveränderliche Ablage |
| Papierprozess parallel zur Automatik | doppelter Aufwand, widersprüchliche Stände | den Papierweg abschaffen, nicht ergänzen |
17.10 Reflexionsfrage
Welche einzelne aufsichtsrechtliche Anforderung nennt man in deinem Haus als Grund gegen häufigere Auslieferungen — und steht sie tatsächlich so in der Vorschrift, oder ist sie eine gewachsene Auslegung?
Die Antwort ist häufiger das Zweite als das Erste. Und das ist eine gute Nachricht, denn Auslegungen lassen sich ändern.
Weiter mit Kapitel 18 — Anti-Pattern im Überblick