Compliance-as-Code für OT-Infrastrukturen im GxP-Umfeld
Wer eine Produktionsanlage für Medikamente betreibt, muss jederzeit belegen können, dass ihre Technik dem entspricht, was regulatorisch gefordert und in der Spezifikation festgehalten ist. Dieser Beweis entsteht heute noch hauptsächlich von Hand. Das Projekt zeigt, wie dies automatisiert werden kann.
Das V-Modell der Qualifizierung:
Jeder Spezifikationsstufe auf der linken Seite steht rechts eine Prüfstufe gegenüber, die genau
gegen sie testet.
Ausgangslage
Anlagen der Pharma- und Life-Sciences-Industrie unterliegen strengen Vorschriften. Behörden in Europa und den USA verlangen den dokumentierten Nachweis, dass die eingesetzte Technik geeignet ist und wie spezifiziert arbeitet. Für die darunterliegende IT/OT-Infrastruktur – Server, Netzwerk, Firewall – heisst das: Jede Einstellung muss festgelegt, geprüft und belegt sein.
Dieser Nachweis entsteht heute überwiegend in Handarbeit. Fachpersonen arbeiten Prüfpunkt für Prüfpunkt ab, halten Bildschirmfotos fest und übertragen Ergebnisse in Protokolle. Das kostet Zeit, in der die Anlage nicht produziert, und es bindet genau jene Fachleute, die anderswo gebraucht werden.
Schwerer wiegt ein zweites Problem. Ein solches Protokoll beschreibt einen einzigen Tag. Ändert jemand am Tag darauf eine Einstellung von Hand, bleibt das unbemerkt, bis die nächste Prüfung ansteht. Der Nachweis altert also, sobald er unterschrieben ist.
In der Summe entsteht ein Innovationsstau. Änderungen werden aufgeschoben, gebündelt oder ganz unterlassen – nicht, weil sie technisch schwierig wären, sondern weil ihr Nachweis teuer ist. Anlagen veralten dadurch, ohne dass es jemand beabsichtigt.
Zielsetzung
Das Projekt untersucht, ob sich der Nachweis maschinell und automatisiert führen lässt. Gesucht war kein einzelnes Werkzeug, sondern ein Zusammenspiel: Der Soll-Zustand der Anlage wird als versionierter Programmcode beschrieben, eine davon getrennte Prüflogik erhebt den tatsächlichen Zustand, und aus dem Vergleich entsteht automatisch ein Dokument, das als regulatorischer Nachweis taugt.
Vier Fragen leiteten die Arbeit. Welche Eigenschaften muss ein maschinell erzeugter Bericht haben, damit ihn eine Qualitätssicherung akzeptiert? Wie muss die Automatisierung aufgebaut sein, damit sie Abweichungen dauerhaft erkennt und nicht nur einmalig? Nach welchen Kriterien lassen sich die verfügbaren Werkzeuge für eine solche Umgebung vergleichen? Und wie schliesst sich die Lücke zwischen technischer Automatisierung und regulatorischer Dokumentation?
Eine Kennung über die ganze Kette
Jede Anforderung trägt eine Kennung. Dieselbe Kennung steht in der Spezifikation, in der Prüflogik, im gespeicherten Ergebnis und im erzeugten Nachweis. Damit lässt sich die Kette von hinten aufrollen: Vom Prüfergebnis führt die Kennung zurück bis zu der Anforderung, die es belegt – und umgekehrt.
Prüfen, ohne zu verändern
Die Automatisierung läuft in Stufen. Änderungen werden zuerst geprüft, dann freigegeben, dann ausgerollt und getestet. Nachts läuft nur die Prüfung: Sie meldet Abweichungen, korrigiert sie aber nicht.
Ergebnisse
Der Prototyp läuft gegen eine eigens aufgebaute Laborumgebung aus Servern, Netzwerkkomponenten und einer Firewall. Ein vollständiger Durchlauf prüft rund 750 Einzelpunkte gegen zwölf Zielsysteme und erzeugt daraus ohne weiteres Zutun ein Nachweisdokument.
- Der Nachweis entsteht durchgehend digital – vom Prüfwerkzeug bis in das fertige Dokument gibt es keinen Schritt über ein Bildschirmfoto.
- Jedes Prüfergebnis trägt die Kennung der Anforderung, die es belegt. Kein Ergebnis steht ohne Bezug im Bericht.
- Das Dokument nennt Zeitpunkt, Version und die Personen, die den geprüften Stand verfasst und freigegeben haben.
- Die nächtliche Prüfung findet Abweichungen, die im laufenden Betrieb auftreten können.
Die wichtigste Erkenntnis betrifft die Prüfungen selbst. Gefährlich ist nicht der Test, der fehlschlägt – der meldet sich. Gefährlich ist der Test, der besteht, ohne etwas gemessen zu haben. Mehrere Prüfungen dieser Art traten im Projekt zutage und führten zu einer einfachen Regel: Jede Prüfung muss zuerst belegen, dass sie überhaupt Daten erhalten hat.
Ein Eingriff von Hand – und was daraus folgt
Wozu das Ganze gut ist, zeigt sich am besten an einer Änderung, die niemand angemeldet hat. Der folgende Fall wurde zur Veranschaulichung absichtlich herbeigeführt.
Der Eingriff. Auf dem Verzeichnisserver wird die geforderte Mindestlänge für Passwörter von zwölf auf acht Zeichen herabgesetzt. Wenige Klicks, wenige Sekunden – und kein Eintrag, der davon berichtet. Genau so entstehen Abweichungen im Alltag einer Anlage.
Der Befund. In der folgenden Nacht läuft die Prüfung planmässig und ohne Zutun. Sie schlägt fehl und nennt beides: den geforderten Wert und den tatsächlich vorgefundenen.
Der entscheidende Ausschnitt aus dem Prüfbericht. Die erste Zeile nennt die Anforderung, gegen die verstossen wurde – dieselbe Kennung, die auch in der Spezifikation steht.
Technische Schlüsselbegriffe
- Regulatorischer RahmenEU-GMP Annex 11 und Annex 15, 21 CFR Part 11, GAMP 5
- QualifizierungComputerised System Validation, IQ und OQ, Traceability
- Infrastructure as CodeOpenTofu, Ansible
- Compliance-PrüfungCinc Auditor, Policy- und Compliance-as-Code
- AutomatisierungGitLab CE, CI/CD-Pipeline
- NachweisarchivOpenSearch, maschinell erzeugter Prüfbericht
- ZielumgebungOperational Technology, Hyper-V, Netzwerk- und Firewall-Konfiguration
- BetriebseigenschaftenIdempotenz, Drift-Erkennung, Vier-Augen-Prinzip
Kund:in
ControlTech Engineering AG
cte.ch
Team
Cédric Zumsteg
cedric.zumsteg@students.fhnw.ch
Fabian Jehle
fabian.jehle@students.fhnw.ch
Betreuer
Sebastian Graf
sebastian.graf@fhnw.ch