Cloud Computing: GxP-Konformität bei Versionsänderungen generischer Micro-Services

Auch in der pharmazeutischen Industrie geht der Trend in Richtung Cloud Computing. Finanzielle, aber auch organisatorische Vorteile sprechen für die Cloud. Gleichzeitig sollten aber auch potentielle Gefahren und regulatorische Einschränkungen beachtet werden. Neun Experten aus der Pharmaindustrie und von Überwachungsbehörden beantworten einen umfangreichen Fragenkatalog aus den folgenden GxP-relevanten Themenkreisen:

• Grundlagen der Cloud Computing Technologie
• Regulatorische Grundlagen und Erwartungen von Inspektoren
• Kunden-Lieferanten-Beziehung
• Anforderungen an den Cloud Service Provider (CSP)
• Anforderungen an die Lieferantenbewertung und Lieferantenaudits
• Qualifizierungs-/Validierungsanforderungen

Frage 19: Eine nicht (GXP-)qualifizierte PAAS könnte die Versionen einiger ihrer generischen Micro-Services ändern, die von der Anwendung verwendet werden, die als GXP SAAS bereitgestellt werden soll. Die Änderung der Versionen solcher generischen Micro-Services könnte sich der Kontrolle des SAAS-Anbieters entziehen. Was wäre erforderlich, um dieses Szenario GXP-konform zu machen? - Themenkreis Anforderungen an den Cloud Service Provider

Eine GxP-relevante IT-Infrastrukturplattform (= PaaS) nicht zu qualifizieren, widerspricht grundlegenden GxP Compliance Anforderungen: dadurch, dass eine validierungspflichtige Anwendung (= SaaS) diese Plattform nutzt, unterliegt die verwendete IT-Infrastruktur der Qualifizierungspflicht ( EU GMP Annex 11 [Principle]: The application should be validated; IT infrastructure should be qualified). Somit ist die (triviale) Antwort auf die Frage, wie das dargestellte Szenario GxP-konform zu machen ist schlicht, dass der genutzte Platform-as-Service qualifiziert werden muss.

Angesichts der Tatsache, dass auch die GxP-Welt nicht ideal ist, könnte man über Workarounds spekulieren, mit denen man einer solchen Non-Compliance begegnen kann. Sei es, dass man für eine Übergangszeit mit Interims Maßnahmen den Gefährdungsgrad zumindest verringert, oder allgemein durch ein entsprechendes Prozessdesign grundsätzlich weniger anfällig für derartige Schwächen wird. Nachfolgend eine sicherlich unvollständige Liste möglicher Gegenmaßnahmen:

• Das Beispiel der massiven Sicherheitslücke in der Java Bibliothek log4j hat gezeigt, wie wichtig es ist, dass man das Wissen und die Kontrolle über die verwendeten Softwarekomponenten hat. Folglich sollte im Rahmen der Validierung eine vollständige Übersicht über die in der Anwendung enthaltenen Bausteine oder Bibliotheken geführt werden. Damit ist eine zielgerichtete Reaktion möglich, sollten Schwachstellen oder Sicherheitslücken zu einer dieser Komponenten bekannt werden.
• Es ist grundsätzlich eine gute Idee, das Change Management des Cloud Service Providers zu kennen, ganz unabhängig davon, ob es sich um validierungspflichtige / qualifizierungspflichtige Dienste handelt oder nicht. Ein aktives Change-Management beinhaltet Information über geplante Updates oder (wichtige) Patches, die zeitnah den Kunden zur Verfügung gestellt werden. Der regulierte Betreiber muss seinerseits solche Informationen in einem kontrollierten Prozess auf ihre Relevanz hin bewerten und ggf. eigene Maßnahmen zur Absicherung der Änderung einplanen (bspw. Regressionstests). Voraussetzung ist natürlich, dass der regulierte Betreiber über das notwendige Knowhow und die Ressourcen verfügt, um seinen Teil des Change Managements beitragen zu können.
  Eine denkbare Verlagerung des Change Managements komplett auf die Seite des regulierten Betreibers wird i. d. R. an der fehlenden Kenntnis scheitern, welche Softwarekomponenten für den Plattform-Service zum Einsatz kommen.
• Sofern keinerlei Informationen über anstehende Plattformänderungen bekannt sind, sei es als reguläre, geplante Updates, oder auch im Rahmen des Patch Managements, bleibt dem regulierten Anwender als einzige Kontrollmaßnahme ein aktives Monitoring oder engmaschige Regressionstests:
  - Ein aktives Monitoring des Anwendungsverhaltens ermöglicht es, Anomalien, Einschränkungen oder Performance-Veränderungen zu erkennen. Vorausgesetzt, dass die Überwachung in einem engen zeitlichen Raster erfolgt und vor allem, dass entsprechend qualifizierte Mitarbeitende (IT oder Key User) die anfallenden Monitoring Daten einer Bewertung unterziehen, um ggf. geeignete Maßnahmen einzuleiten.
  Die Wirksamkeit eines derartigen Monitoring-Prozesses steht und fällt jedoch mit dem Vorhandensein aussagekräftiger Kennzahlen, die eine objektive Einschätzung des "Gesundheitsstatus" der GxP-relevanten Anwendung erlauben.
  - Regressionstests können Auskunft darüber geben, ob die vorhandene (und validierte) Systemfunktionalität immer noch unverändert gegeben ist. Im hier angenommenen Szenario sind die Randbedingungen für derartige Tests jedoch extrem ungünstig, da weder bekannt ist, wann Systemänderungen erfolgen, noch was ggf. geändert wurde. Das bedeutet, wirksame Regressionstests müssten in hoher Frequenz eingeplant und durchgeführt werden, um beeinträchtigte oder fehlende Systemfunktionen rechtzeitig entdecken zu können. Daher stehen Aufwand zu Nutzen bei diesem Workaround in einem sehr ungünstigen Verhältnis.

Weitere Fragen und Antworten des Expertenteams zum Thema "Cloud Computing"

Hier finden Sie weitere Fragen und Antworten zum Thema "Cloud Computing" die u.a. das Expertenteam beantwortet hat.

Die Experten

Frank Behnisch, CSL Behring GmbH, Marburg
Klaus Feuerhelm, ehem. Inspektor beim Regierungspräsidium Tübingen
Oliver Herrmann; Q-FINITY Quality Management, Dillingen
Eberhard Kwiatkowski, PharmAdvantageIT GmbH, Neuschoo
Stefan Münch, Körber Pharma Consulting, Karlsruhe
Yves Samson, Kereon AG, Basel
Dr. Wolfgang Schumacher, ehem. F. Hoffmann-La Roche AG, Basel
Dr. Arno Terhechte, Bezirksregierung Münster
Sieghard Wagner, Chemgineering Germany GmbH, Stuttgart