Fragen und Antworten zum Thema Cloud Computing im GMP-Umfeld - Teil 3
Die Hinwendung zum Cloud Computing ist ein aktueller Trend in der gesamten Wirtschaft. Auch die pharmazeutische Industrie wendet sich verstärkt in diese Richtung. GxP-Anwendungen sind davon nicht unberührt.
Insbesondere finanzielle und organisatorischen Vorteile sprechen für die "Cloud". Allerdings sollte man auch potentielle Gefahren und regulatorische Einschränkungen kennen und beachten. In den nachfolgenden Ausgaben des GMP-Journals werden von 9 Experten aus der Industrie und von Überwachungsbehörden Fragen aus den folgenden GxP-relevanten Themenkreisen beantwortet:
- Grundlagen der Cloud Computing Technologie
- Regulatorische Grundlagen und Erwartungen von Inspektoren
- Kunden-Lieferanten-Beziehungen
- Anforderungen an den Cloud Service Provider (CSP)
- Anforderungen an die Lieferantenbewertung und Lieferantenaudits
- Qualifizierungs-/Validierungsanforderungen
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
14. Regulatorische Grundlagen und Erwartungen von Inspektoren
Was sollte die Bewertung der "Cloud-Lieferanten" aus Behördensicht umfassen?
Wesentliche Hinweise für die Bewertung eines CSP aus Behördensicht liefert das Votum der EFG 11: V1100202 Anforderungen an die Aufbewahrung elektronischer Daten
Entsprechend dem Votum V1100202 müssen die Vorgaben zur Qualifizierung der IT-Infrastruktur (IAAS, PAAS), der Validierung der Applikation (SAAS) und die Sicherstellung der Verfügbarkeit, Lesbarkeit und Integrität von einem (internen oder externen) Dienstleister erfüllt werden. Entscheidend ist der Hinweis, dass eine Gefährdung für Patientinnen/Patienten und/oder die Qualität des Arzneimittels ausgeschlossen wird. Ein Assessment sollte entsprechend dem Votum insbesondere folgende Punkte umfassen:
- Service Level Agreement
- Qualifizierung und Validierung verifiziert wurden
- Im Rahmen eines kontinuierlichen Assessments des CSP im Sinne von Quality Attributs überprüft werden können.
- Die Löschung der Daten nach Beendigung des Geschäftsverhältnisses sichergestellt ist.
- Die Verlagerung der Daten oder der Anwendung zurück oder zu einem anderen CSP möglich ist.
Seminarempfehlung
Tuesday, 26 November 2024 9 .00 - 18.00 h
Computerised System Validation: Introduction to Risk Management - Live Online Training
15. Qualifizierungs-/Validierungsanforderungen
Was ist bei der Validierung von SaaS zu beachten; wer ist verantwortlich?
SaaS steht für "Software as a Service" und ist eines von mehreren Servicemodellen, bei denen ein Cloud Service Provider (CSP) seine Dienste anbietet. Bei SaaS stellt der CSP die gesamte Anwendung einschließlich Infrastruktur und Plattform bereit.
Das regulierte Unternehmen bezahlt eine Lizenzgebühr, muss aber selbst nicht in Server-Hardware und Software-Entwicklung investieren - bezahlt werden Bereitstellung und laufender Betrieb. Im Gegenzug übernimmt der CSP die IT-Administration und weitere Dienstleistungen wie Wartung und Aktualisierung der Software.
Um es klar zu sagen: Verantwortung lässt sich nicht delegieren! Das regulierte Unternehmen bleibt für die ordnungsgemäße Nutzung und Umsetzung der Anwendung durch den CSP verantwortlich. Dieser Verantwortung wird das regulierte Unternehmen gerecht, indem der CSP qualifiziert und die per SaaS bereitgestellte(n) Anwendung(en) validiert werden.
Wie bei jeder Software-Anwendung sollten zunächst die Anforderungen in Form eines Lastenhefts (URS) festgelegt werden. Auf dieser Basis, ergänzt um weitere Kriterien, z.B. kommerzielle Aspekte, können verschiedene CSPs mit ihren Anwendungen evaluiert werden. Kommt ein CSP in die engere Wahl, so ist - abhängig vom Risiko der Anwendung und der verarbeiteten Daten - eine Qualifizierung durchzuführen; diese kann vom Ausfüllen eines Fragebogens bis zu einem mehrtägigen Vor- Ort-Audit reichen.
Die Transparenz des CSPs und die Art und Weise der Zusammenarbeit haben einen entsprechend hohen Einfluss auf die Validierung. Generell kann diese als "Black Box" betrachtet und mit denselben Methoden wie herkömmliche Software validiert werden, aber es gilt, folgenden Aspekte besondere Aufmerksamkeit zu widmen:
- Dokumentation, die der CSP/Hersteller bereitstellt
- Dieser Aspekt gewinnt an Bedeutung, weil nicht nur die Anwendung, sondern auch Infrastruktur, Betriebssystem etc. durch den CSP installiert und betrieben werden.
- Vorleistungen und Qualität der Anwendung
- Diese lässt sich durch Einsicht in die Unterlagen des CSPs/ Herstellers und durch eigene Prüfmaßnahmen verifizieren.
- Datenschutz Die DSGVO ist zu beachten. Hier ist zu hinterfragen, wie und wo die eigenen Daten gespeichert und verarbeitet werden und wie Daten verschiedener Unternehmen voneinander sicher getrennt werden.
- Update-Strategie Bei SaaS ist nicht nur die Qualität der Anwendung zum Zeitpunkt der Prüfung relevant, sondern insbesondere die Prozesse und Methoden zur Weiterentwicklung, Fehlerbeseitigung und generell Aktualisierung sind zu prüfen: Häufig hat das regulierte Unternehmen - je nach Anwendung und Dienstleistungsvertrag - keinen direkten Einfluss auf Umfang und Zeitpunkt von Aktualisierungen.
- Exit-Strategie Ein weiterer wichtiger Punkt, der bereits früh bedacht werden sollte, ist die Exit-Strategie: SaaS ist bequem, kann aber leicht zu einer unerwünschten Abhängigkeit ("Vendor- Lock-in") führen, da der CSP in der Regel nicht nur die Anwendung betreibt, sondern auch die Daten speichert und verwaltet.
Generell folgt die Validierung von SaaS den bekannten Prinzipien der klassischen Computersystem-validierung. Durch SaaS kommen jedoch neue Risiken hinzu und die Schwerpunkte verschieben sich, weil die Aktivitäten des CSPs / Herstellers eine größere Rolle spielen.
16. Qualifizierungs-/Validierungsanforderungen
Welche Konsequenzen haben die verschiedenen Servicemodelle (IaaS / PaaS / SaaS / XaaS) für das Lieferantenmanagement und die Qualifizierung / Validierung?
Wie in der Antwort zu "Was bedeutet IaaS / PaaS / SaaS / XaaS?" dargestellt (siehe Frage 1; GMP-Journal 3/22), unterscheiden sich die unterschiedlichen Servicemodelle bzgl. Qualifizierung und Validierung vor allem darin, wo die Verantwortung des Lieferanten (Cloud Service Provider, CSP) aufhört und die des Anwenders (reguliertes Unternehmen) beginnt. Spezialfälle wie HPCaaS oder AIaaS (siehe "Was bedeutet IaaS / PaaS / SaaS / XaaS?") werden hier der Einfachheit halber wie SaaS behandelt, d. h. wir betrachten IaaS, PaaS und SaaS.
Wichtig zu wissen: Die Verantwortung des regulierten Unternehmens für Patientensicherheit, Produktqualität und - insbesondere im Kontext Cloud wichtig - Datenintegrität, kann nicht an einen CSP oder sonstigen Dienstleister delegiert werden! Dennoch sind Cloud-Modelle bestens geeignet, das Leverage- Prinzip anzuwenden: "Baue auf den (Vor-)Leistungen des Dienstleisters auf!". Die vom regulierten Unternehmen durchzuführenden Maßnahmen für die Qualifizierung und Validierung einer Anwendung orientieren sich folglich neben den wichtigen Faktoren GxP-Einfluss, Risiko, Erfahrung, Komplexität etc. auch am Servicemodell:
- IaaS: Der CSP stellt die Infrastruktur zur Verfügung. Da Konfiguration und Betrieb aller weiteren Ebenen beim regulierten Unternehmen verbleiben, sind keine besonderen Maßnahmen erforderlich. Zur Risikominimierung ist es empfehlenswert, sich die Verfügbarkeit vom CSP vertraglich zusichern zu lassen und einen "Plan B" für einen Betrieb zu haben, falls die Cloud nicht erreichbar ist (dies gilt selbstverständlich auch für die Infrastruktur auf Seiten des regulierten Unternehmens).
- PaaS: Der CSP stellt die Infrastruktur zur Verfügung und installiert das Betriebssystem. Da Betriebssysteme ebenso wie Infrastruktur in GAMP Software Kategorie 1 fallen und - zumindest bei den weit verbreitet eingesetzten Betriebssystemen - keine besonderen Risiken zu erwarten sind, gelten die Aussagen für IaaS hier analog. Als zusätzliche Maßnahme sollte die Konfiguration des Betriebssystems überprüft und dokumentiert werden. Zudem sollte bekannt und nach Möglichkeit vertraglich geregelt sein, wie und wie oft der CSP das Betriebssystem aktualisiert und wann und in welcher Form das regulierte Unternehmen darüber informiert wird.
- SaaS: Der CSP stellt die Infrastruktur, das Betriebssystem und die Anwendung bereit. Bei diesem Modell muss der CSP die Anwendung entsprechend der Anforderungen des regulierten Unternehmens spezifizieren und testen, ebenso verbleibt ein Teil der Kontrolle über die Konfiguration beim CSP. Dies setzt ein hohes Maß an Vertrauen voraus, das häufig nur durch eine dem Risiko der Anwendung angemessene Prüfung des CSP gerechtfertigt ist; diese Prüfung erfordert in der Regel eine Auditierung. Das Risiko und der Umfang der Prüfung kann reduziert werden, wenn der CSP entsprechende Unterlagen (Zertifikate, White Paper etc.) bereitstellt. Im Rahmen der Prüfung identifizierte Risiken sollten mit geeigneten Maßnahmen, z.B. vertraglichen Vereinbarungen, reduziert werden. Der Update-Strategie des CSP kommt bei SaaS eine noch größere Bedeutung als bei PaaS zu, da Änderungen potenziell weitreichender und riskanter sind. Insofern ist bei SaaS noch wichtiger, diese Update-Strategie zu kennen und rechtzeitig über geplante Änderungen informiert zu sein.
Unabhängig, ob IaaS, PaaS oder SaaS: Die Rollen und Verantwortlichkeiten sowohl des CSP als auch des regulierten Unternehmens sollte definiert und klar beschrieben und die Vorgehensweise in Bezug auf Änderungen durch den CSP sollte vertraglich geregelt sein.
17. Qualifizierungs-/Validierungsanforderungen
Kann eine automatisierte Deploymentkette eine IQ ersetzen? Wenn ja, was muss die Deploymentkette and Informationen zur Verfügung stellen?
Aus Annex 11 ergibt sich die Anforderung, Infrastruktur zu qualifizieren. Die Art und Weise, wie Infrastruktur zur Verfügung gestellt wird (z.B. als IaaS) hat auch Einfluss auf die Art und Weise, wie Infrastruktur qualifiziert wird und wie nachgewiesen wird - Stichwort "documented evidence" -, dass sie den Anforderungen und Spezifikationen entspricht.
Die "klassische papierbasierte Infrastruktur- Qualifizierung" basierte auf definierter Hardware und spezifizierten Strukturen, die verifiziert wurden. Virtualisierung, Automatisierung und Monitoringtools haben Infrastruktur- Deployment zu einem dynamischen Prozess fortentwickelt und die statische Qualifizierung wandelt sich in eine kontinuierliche Prozesskontrolle, die wiederum ebenfalls automatisiert über Monitoringtools erfolgt.
Die Komponenten der Infrastrukturqualifizierung wie Anforderung / Spezifikation, Design, Konfiguration, Deployment und Verifizierung bleiben als Grundlage erhalten. Der Prozess der Qualifizierung und des begleitenden Monitorings verschmelzen und nutzen ggf. auch gleiche Tools (DevOps).
Eine automatisierte Deploymentkette verknüpft mit einem geeigneten Monitoring wären geeignet als Nachweis der Infrastrukturqualifizierung. Die Geeignetheit der Tools ist nachzuweisen.
Ebenso muss sichergestellt sein, dass Fehler erkannt, berichtet und behoben werden.
Obwohl Infrastruktur im Zusammenhang mit Cloud Services unbestritten eine kritische Komponente darstellt, sind die Informationen zur Qualifizierung derselben, die der CSP bereitstellt und der RU fordert rudimentär und entsprechen nur in wenigen Fällen einer Qualifizierung einer On-Premise Lösung.
Auch die Beauftragung eines globalen CSP reicht allein nicht als Nachweis für eine qualifizierte Infrastruktur aus.
18. Qualifizierungs-/Validierungsanforderungen
Welchen Wert hat eine "Validierung", die von einem CSP für die bereitgestellten Services in Eigenregie durchgeführt wurde?
Bei SaaS Applikationen, die vom Cloud Service Provider für den GMP Bereich angeboten werden, ist normalerweise eine vollständige Validierung des Basis-Systems vorgesehen. Dabei führt der CSP alle notwendigen Teilschritte der Validierung (von URS bis UAT) selbst durch und dokumentiert diese entsprechend den gängigen Regularien. Auf diese Validierungsunterlagen kann der pharmazeutische Unternehmer für das Standardsystem zurückgreifen, muss jedoch alle Schritte der Systemanpassung (Customizing) außerhalb des Standards selbst durchführen. Der User Akzeptanz Test (UAT) ist in jedem Fall vom pharmazeutischen Unternehmen selbst durchzuführen und kann nicht an den CSP übertragen werden. Dabei können natürlich Unterlagen des Systemtests, die beim CSP vorliegen, herangezogen werden.
Von dieser Vorgehensweise ausgenommen sind selbstverständlich speziell entwickelte MES Applikationen (Manufacturing Execution System), bei denen der vom Provider bereitgestellte Standard nur einen kleinen Teil des Systems ausmacht.
Einige Provider demonstrieren schon auf ihren Homepages eine klare Übersicht, wer welche Validierungsdokumente zur Verfügung stellt. Es ist trotzdem sinnvoll, schon im SLA eindeutig festzulegen, welche Unterlagen im Fall von Behördeninspektionen vom CSP beigestellt werden und welche Kosten dabei entstehen. Es ist durchaus an der Tagesordnung, dass CSPs schon für die Bereitstellung von Personal während einer Behördeninspektion die üblichen Tagessätze in Rechnung stellen, obwohl gar keine Fragen an den CSP gerichtet wurden.
Seminarempfehlung
27-29 November 2024
Computerised System Validation: The GAMP 5 Approach - Live Online Training
19. Anforderungen an den Cloud Service Provider (CSP)
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 Microservices könnte sich der Kontrolle des SAAS-Anbieters entziehen. Was wäre erforderlich, um dieses Szenario GXP-konform zu machen?
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 Qualifizierungspflicht1. 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 Monitoringdaten einer Bewertung unterziehen, um ggf. geeignete Maßnahmen einzuleiten.
Die Wirksamkeit eines derartigen Monitoringprozesses 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.
Über den Autor:
Dr. Andreas Mangel
... kam 1995 als Fachbereichsleiter zu CONCEPT HEIDELBERG, wo er für die Themenbereiche Sterilproduktion und Computervalidierung verantwortlich ist.
Fußnoten:
1 EU GMP Annex 11 [Principle]: The application should be validated; IT infrastructure should be qualified.
