NIS2 und GxP auf Kubernetes: Container-Plattform fuer regulierte Pharma-Workloads

TL;DR

• GxP-Validierung (IQ/OQ/PQ) laesst sich auf Kubernetes-Cluster abbilden, wenn Infrastruktur als Code vorliegt und jede Aenderung versioniert ist
• NIS2 verlangt technische Massnahmen fuer Risikomanagement, Incident Response und Supply-Chain-Sicherheit -- Kubernetes bringt die Bausteine dafuer mit (RBAC, NetworkPolicy, Audit Logging)
• GitOps mit Argo CD oder Flux ist der Schluessel fuer lueckenlose Audit-Trails und reproduzierbare Deployments
• Image Signing und Vulnerability Scanning gehoeren in die CI/CD-Pipeline, nicht erst in die Produktion
• Der Einstieg funktioniert am besten ueber einen PoC mit einer nicht-kritischen GxP-Anwendung

Warum Pharma-Unternehmen Kubernetes brauchen

Die Pharmabranche ist eine der am staerksten regulierten Industrien ueberhaupt. GxP-Richtlinien (GMP, GCP, GLP) definieren, wie Software und Infrastruktur validiert werden muessen. Dazu kommt seit Oktober 2024 die NIS2-Richtlinie, die Cybersicherheitsanforderungen fuer kritische Einrichtungen drastisch verschaerft.

Traditionelle VM-basierte Infrastrukturen machen Validierung teuer. Jede Umgebung ist ein Unikat, Konfigurationsdrift ist schwer nachzuweisen, und Aenderungen erfordern manuelle Dokumentation. Kubernetes dreht dieses Modell um: Die gesamte Infrastruktur liegt als Code vor, jede Aenderung wird in Git versioniert, und Umgebungen sind per Definition reproduzierbar.

Das bedeutet konkret: Wenn ein Auditor fragt, welche Konfiguration am 15. Januar um 14:32 Uhr aktiv war, koennen Sie auf einen Git-Commit verweisen. Kein Durchsuchen von Change-Management-Tickets, kein Abgleich von Screenshots.

GxP-Validierung auf Kubernetes: IQ, OQ, PQ als Code

Die klassische Qualifizierung teilt sich in drei Phasen auf: Installationsqualifizierung (IQ), operationale Qualifizierung (OQ) und Performancequalifizierung (PQ). Auf Kubernetes laesst sich jede Phase automatisieren.

IQ -- Ist die Plattform korrekt installiert? Das prueft ein Satz von Tests, die nach jedem Cluster-Setup laufen. Ein einfaches Beispiel mit einem Shell-Script:

#!/bin/bash
# iq-check.sh -- Installationsqualifizierung fuer Kubernetes-Cluster

set -euo pipefail

echo "=== IQ Check: Kubernetes Cluster ==="

# Pruefe Kubernetes-Version
KUBE_VERSION=$(kubectl version --short 2>/dev/null | grep Server | awk '{print $3}')
echo "[IQ-001] Kubernetes Version: $KUBE_VERSION"

# Pruefe Control Plane Health
kubectl get componentstatuses 2>/dev/null || kubectl get --raw='/readyz?verbose'

# Pruefe erforderliche Namespaces
for ns in gxp-prod gxp-staging monitoring; do
  if kubectl get namespace "$ns" &>/dev/null; then
    echo "[IQ-002] Namespace $ns: OK"
  else
    echo "[IQ-002] Namespace $ns: FEHLT" && exit 1
  fi
done

# Pruefe CNI-Plugin und CoreDNS
kubectl get pods -n kube-system -l k8s-app=kube-dns --no-headers | grep -q Running \
  && echo "[IQ-003] CoreDNS: Running" \
  || echo "[IQ-003] CoreDNS: PROBLEM"

# Pruefe Storage Classes
kubectl get storageclass gxp-encrypted-storage &>/dev/null \
  && echo "[IQ-004] GxP StorageClass: vorhanden" \
  || echo "[IQ-004] GxP StorageClass: FEHLT"

echo "=== IQ Check abgeschlossen ==="

OQ und PQ laufen als automatisierte Test-Suites, z.B. mit Sonobuoy fuer Conformance Tests oder mit eigenen Integration-Tests, die pruefen, ob RBAC-Regeln greifen, NetworkPolicies den Traffic korrekt einschraenken und Persistent Volumes wie erwartet funktionieren.

NIS2-Anforderungen technisch umsetzen

NIS2 verlangt von kritischen Einrichtungen konkrete Massnahmen in mehreren Bereichen. Hier ist eine Zuordnung zu Kubernetes-Konzepten:

Der wichtigste Punkt: NIS2 fordert nicht spezifisch Kubernetes. Es fordert nachweisbare technische Massnahmen. Kubernetes macht den Nachweis einfacher, weil alles deklarativ und versioniert ist.

Netzwerksegmentierung fuer GxP-Workloads

Ein Kernprinzip bei GxP ist die Trennung von validierten und nicht-validierten Umgebungen. Auf Kubernetes setzen Sie das mit Namespaces und NetworkPolicies um.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: gxp-workload-isolation
  namespace: gxp-prod
spec:
  podSelector:
    matchLabels:
      gxp-validated: "true"
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              environment: gxp-prod
        - namespaceSelector:
            matchLabels:
              purpose: monitoring
      ports:
        - protocol: TCP
          port: 8443
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              environment: gxp-prod
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: logging
      ports:
        - protocol: TCP
          port: 3100

Diese Policy stellt sicher, dass GxP-Pods nur von anderen GxP-Pods und dem Monitoring-System erreicht werden koennen. Ausgehend duerfen sie nur auf die GxP-Datenbank und das Logging-System zugreifen. Alles andere wird geblockt.

Wichtig: Setzen Sie eine Default-Deny-Policy pro Namespace ein, bevor Sie spezifische Regeln hinzufuegen. Ohne Default-Deny erlaubt Kubernetes allen Traffic.

GitOps als Audit-Trail-Maschine

Fuer GxP muessen alle Aenderungen an der Infrastruktur dokumentiert und nachvollziehbar sein. Traditionell geschieht das ueber Change-Management-Systeme und manuelle Eintraege. Mit GitOps wird der Git-History selbst zum Audit-Trail.

So sieht ein typischer Workflow aus:

1. Entwickler erstellt einen Pull Request mit der Aenderung (z.B. neues Image-Tag, geaenderte Resource Limits)
2. Automatisierte Checks laufen: Linting, Policy-Check mit Kyverno, Vulnerability Scan
3. Ein zweiter Engineer reviewed und approved den PR
4. Merge in den Main-Branch loest die Synchronisation aus
5. Argo CD oder Flux erkennt die Aenderung und rollt sie auf dem Cluster aus
6. Der GitOps-Operator meldet den Sync-Status zurueck

Jeder dieser Schritte ist in Git und im GitOps-Tool protokolliert. Ein Auditor kann den kompletten Lebenszyklus einer Aenderung nachvollziehen: Wer hat sie angefragt, wer hat sie genehmigt, wann wurde sie ausgerollt, was war der vorherige Zustand.

Image Supply Chain absichern

NIS2 legt besonderen Wert auf Supply-Chain-Sicherheit. Fuer Kubernetes bedeutet das: Jedes Container-Image, das auf dem Cluster laeuft, muss geprueft und signiert sein.

# Container-Image mit Cosign signieren
cosign sign --key cosign.key registry.example.com/gxp-app:v2.1.0

# Signatur in der CI/CD-Pipeline verifizieren
cosign verify --key cosign.pub registry.example.com/gxp-app:v2.1.0

# Vulnerability Scan mit Trivy
trivy image --severity HIGH,CRITICAL \
  --exit-code 1 \
  registry.example.com/gxp-app:v2.1.0

In Kombination mit einem Admission Controller wie Kyverno oder OPA Gatekeeper koennen Sie erzwingen, dass nur signierte und gescannte Images im GxP-Namespace deployed werden duerfen. Unsignierte Images werden automatisch abgelehnt.

Monitoring und Incident Response

GxP und NIS2 verlangen beide, dass Sicherheitsvorfaelle erkannt und dokumentiert werden. Dafuer brauchen Sie drei Schichten:

Schicht 1: Metriken und Alerting. Prometheus sammelt Cluster- und Anwendungsmetriken. Alertmanager benachrichtigt bei Anomalien. Grafana visualisiert den Zustand. Details dazu finden Sie in unserem Artikel zu Kubernetes Monitoring.

Schicht 2: Logging. Alle Kubernetes-Audit-Logs, Anwendungslogs und System-Events fliessen in ein zentrales System (Loki, ELK). Die Retention muss GxP-konform sein, typischerweise mindestens fuenf Jahre fuer produktionsrelevante Daten.

Schicht 3: Runtime Security. Falco ueberwacht Systemcalls und erkennt ungewoehnliches Verhalten in Echtzeit: Shell-Zugriff auf einen Pod, unerwartete Netzwerkverbindungen, Dateisystemveraenderungen in einem Read-Only-Container. Mehr dazu im Beitrag zu Kubernetes Runtime Security.

Vergleich: VM-basierte vs. Kubernetes-basierte GxP-Infrastruktur

DSGVO-Aspekte bei GxP-Daten

Pharma-Workloads verarbeiten haeufig personenbezogene Daten, etwa aus klinischen Studien. Kubernetes unterstuetzt die DSGVO-Konformitaet durch mehrere Mechanismen:

Datenlokalitaet: Durch Node-Affinity und Topology-Constraints koennen Sie sicherstellen, dass Pods mit sensiblen Daten nur auf Nodes in bestimmten Rechenzentren laufen. Storage Classes definieren, wo Persistent Volumes physisch liegen.

Zugriffskontrolle: RBAC trennt Verantwortlichkeiten sauber. Ein Entwickler kann Logs lesen, aber keine Secrets im GxP-Namespace einsehen. Ein Operator kann Deployments neustarten, aber keine RBAC-Regeln aendern. Mehr zur Absicherung von Kubernetes Namespaces.

Verschluesselung: etcd-Encryption-at-Rest schuetzt Secrets und ConfigMaps. Service Meshes wie Istio oder Linkerd erzwingen mTLS zwischen allen Pods. Einen Vergleich finden Sie unter Istio vs Linkerd.

Praxistipps fuer den Einstieg

Starten Sie nicht mit Ihrer kritischsten GxP-Anwendung. Waehlen Sie eine interne Anwendung, die bereits containerisiert ist oder sich leicht containerisieren laesst, zum Beispiel ein internes Reporting-Tool oder eine Testdaten-Pipeline.

Investieren Sie frueh in Policy-as-Code. Kyverno-Policies, die erzwingen, dass jedes Deployment im GxP-Namespace bestimmte Labels, Resource Limits und Security Contexts hat, sparen spaeter enorm viel Aufwand bei der Validierung.

Automatisieren Sie die Qualifizierung von Anfang an. IQ-, OQ- und PQ-Tests als CI/CD-Jobs bedeuten, dass jede Cluster-Aenderung automatisch requalifiziert wird. Das ist der groesste Hebel gegenueber manueller Validierung.

Dokumentieren Sie Architektur-Entscheidungen als ADRs (Architecture Decision Records) im selben Git-Repository wie Ihre Infrastruktur. So hat ein Auditor nicht nur das Was, sondern auch das Warum.

Einen ausfuehrlichen Leitfaden fuer den produktionsreifen Cluster-Aufbau finden Sie unter Kubernetes Production Setup.

Fazit

Kubernetes ist keine Silver Bullet fuer GxP und NIS2 -- aber es liefert die technische Basis, um Compliance nachweisbar, reproduzierbar und effizient umzusetzen. Der Schluessel liegt in der Kombination aus GitOps, Policy-as-Code, automatisierter Validierung und durchgaengigem Monitoring.

Der Einstieg muss nicht gross sein. Ein einzelner PoC mit einer nicht-kritischen Anwendung, einer sauberen GitOps-Pipeline und automatisierten Qualifizierungstests reicht, um den Mehrwert konkret zu zeigen.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung einer GxP-konformen Container-Plattform brauchen, melden Sie sich gerne unter /kontakt.