TL;DR

• Patientendaten sind nach DSGVO Art. 9 besonders schuetzenswerte Daten -- Verstoesse kosten bis zu 20 Mio. EUR oder 4% des Jahresumsatzes
• Encryption at Rest und in Transit ist Pflicht, nicht Kuer: etcd-Verschluesselung, TLS zwischen Services und verschluesselte Persistent Volumes
• Namespace-Isolation und RBAC trennen Patientendaten von anderen Workloads und stellen sicher, dass nur autorisierte Services zugreifen koennen
• DiGA-Zulassung erfordert nachweisbare Datensicherheit, Interoperabilitaet via HL7 FHIR und einen lueckenlosen Audit Trail
• Managed Kubernetes mit ISO 27001 und C5-Testat uebernimmt einen grossen Teil der Compliance-Dokumentation, die Sie sonst selbst erstellen muessten

Kubernetes im Gesundheitswesen: DSGVO-konforme Patientendaten

Kliniken, medizinische Versorgungszentren und Health-Tech-Startups stehen vor dem gleichen Problem: Sie muessen moderne Software schnell ausliefern und gleichzeitig die strengsten Datenschutzanforderungen einhalten, die das deutsche Recht kennt. Patientendaten nach Art. 9 DSGVO gehoeren zu den besonders schuetzenswerten Datenkategorien. Ein Verstoss hat nicht nur finanzielle Konsequenzen, sondern gefaehrdet das Vertrauen von Patienten und Zuweisern.

Kubernetes liefert die technischen Bausteine fuer eine sichere und compliance-faehige Plattform. Aber ohne die richtige Konfiguration ist ein Kubernetes-Cluster genauso unsicher wie jede andere Infrastruktur.

Regulatorischer Rahmen: Was fuer Gesundheitsdaten gilt

Im Gesundheitswesen greifen mehrere Regelwerke gleichzeitig. Die Herausforderung: Sie muessen alle erfuellen, auch ohne eigene Compliance-Abteilung.

Besonders relevant fuer Health-Tech-Unternehmen: Die DiGA-Verordnung verlangt, dass Gesundheitsdaten ausschliesslich in Deutschland oder der EU verarbeitet werden. Das betrifft direkt die Cloud-Region-Wahl und das Cluster-Setup.

Verschluesselung: Dreifacher Schutz fuer Patientendaten

Fuer Gesundheitsdaten reicht eine einzelne Verschluesselungsschicht nicht. Sie brauchen Schutz auf drei Ebenen: in der Datenbank (at Rest), auf dem Transportweg (in Transit) und im Kubernetes-Cluster selbst (etcd).

1. etcd-Verschluesselung fuer Secrets und ConfigMaps

Kubernetes speichert alle Cluster-Daten in etcd -- einschliesslich Secrets, die Datenbankpasswoerter oder API-Keys enthalten. Standardmaessig sind diese Daten nur Base64-kodiert, nicht verschluesselt.

# EncryptionConfiguration fuer den API-Server
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      # AES-GCM Verschluesselung (empfohlen)
      - aesgcm:
          keys:
            - name: key-2026-02
              secret: c2VjcmV0LWtleS1mb3ItaGVhbHRoY2FyZS1kYXRh
      # Fallback: Lesen alter, unverschluesselter Daten
      - identity: {}

Bei Managed Kubernetes (AKS, EKS, GKE) ist die etcd-Verschluesselung in der Regel standardmaessig aktiviert. Pruefen Sie das trotzdem -- fuer ein Audit muessen Sie es nachweisen koennen.

2. TLS zwischen allen Services

Patientendaten duerfen nicht unverschluesselt zwischen Microservices uebertragen werden. Ein Service Mesh wie Istio oder Linkerd erzwingt mTLS (mutual TLS) zwischen allen Pods, ohne dass die Anwendungen selbst angepasst werden muessen.

3. Verschluesselte Persistent Volumes

Datenbanken mit Patientendaten muessen auf verschluesselten Volumes liegen. Alle grossen Cloud-Anbieter unterstuetzen Encryption at Rest fuer ihre Storage Classes.

Zugriffskontrolle: Wer darf was sehen?

RBAC (Role-Based Access Control) in Kubernetes steuert, welche Personen und Services auf welche Ressourcen zugreifen duerfen. Fuer Patientendaten muessen Sie das Prinzip der minimalen Berechtigung (Least Privilege) konsequent umsetzen.

# Rolle: Nur Lesen von Pods und Logs im Healthcare-Namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: healthcare-reader
  namespace: patient-data
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: []  # Kein Zugriff auf Secrets
---
# Rolle: Deployment-Berechtigung fuer das Entwicklerteam
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: healthcare-deployer
  namespace: patient-data
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update", "patch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: []  # Auch Deployer brauchen keinen Secret-Zugriff
---
# RoleBinding: Entwicklerteam bekommt Deployer-Rechte
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-deployer
  namespace: patient-data
subjects:
  - kind: Group
    name: healthcare-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: healthcare-deployer
  apiGroup: rbac.authorization.k8s.io

Wichtig: Secrets im Namespace patient-data sind explizit ausgenommen. Datenbankpasswoerter und Verschluesselungskeys sollten ueber einen externen Secret Store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) verwaltet werden -- nicht ueber kubectl-Zugriff.

DiGA-Anforderungen: Was das BfArM erwartet

Digitale Gesundheitsanwendungen (DiGA), die auf Rezept verordnet werden, muessen das DiGAV-Pruefverfahren beim BfArM bestehen. Die technischen Anforderungen betreffen direkt die Infrastruktur.

DiGA-Checkliste fuer Kubernetes-Betreiber

HL7 FHIR Integration

Die DiGAV fordert Interoperabilitaet nach HL7 FHIR. In der Kubernetes-Architektur laesst sich das als eigenstaendiger FHIR-Gateway-Service umsetzen, der zwischen der eigenen Anwendung und externen Systemen (Praxis-Informationssysteme, Krankenhaus-KIS) vermittelt.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fhir-gateway
  namespace: patient-data
  labels:
    app: fhir-gateway
    compliance: diga
spec:
  replicas: 2
  selector:
    matchLabels:
      app: fhir-gateway
  template:
    metadata:
      labels:
        app: fhir-gateway
        data-access: patient-data
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
      containers:
        - name: fhir-gateway
          image: registry.internal/fhir-gateway:4.2.1@sha256:a1b2c3d4e5f6
          ports:
            - containerPort: 8080
              name: fhir-api
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "500m"
              memory: "1Gi"
          env:
            - name: FHIR_VERSION
              value: "R4"
            - name: AUDIT_LOG_ENABLED
              value: "true"
            - name: TLS_ENABLED
              value: "true"
          readinessProbe:
            httpGet:
              path: /fhir/metadata
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 15
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 30
          volumeMounts:
            - name: tls-certs
              mountPath: /etc/tls
              readOnly: true
      volumes:
        - name: tls-certs
          secret:
            secretName: fhir-gateway-tls

Das Image wird per SHA-Digest referenziert, nicht per Tag. Das stellt sicher, dass bei einem Audit nachvollziehbar ist, welche exakte Software-Version laeuft. Fuer DiGA-Anwendungen ist diese Nachvollziehbarkeit Pflicht.

Audit-Logging: Der lueckenlose Nachweis

Fuer Gesundheitsdaten muessen Sie jederzeit nachweisen koennen, wer wann auf welche Daten zugegriffen hat. Kubernetes bietet dafuer API-Server Audit Logs, die jede Anfrage an den Cluster protokollieren.

Ein GitOps-Workflow mit ArgoCD oder Flux liefert den Deployment-Audit-Trail quasi als Nebenprodukt: Jede Aenderung an der Infrastruktur ist ein Git-Commit mit Zeitstempel, Autor und Diff.

Haeufige Compliance-Luecken im Gesundheitswesen

1. Unverschluesselte Secrets in etcd

Base64 ist keine Verschluesselung. Pruefen Sie, ob die EncryptionConfiguration aktiv ist. Bei Managed Kubernetes ist das oft standardmaessig der Fall, bei Self-Managed Clustern nicht.

2. Fehlende Network Policies

Ohne Network Policies kann jeder Pod im Cluster auf die Patientendatenbank zugreifen. Eine Default-Deny-Policy pro Namespace ist das Minimum. Vertiefte Informationen dazu finden Sie in unserem DSGVO-Compliance-Guide.

3. Keine Datenlokation geprueft

Managed-Kubernetes-Services verteilen Workloads automatisch ueber Availability Zones. Stellen Sie sicher, dass alle Zones in der EU liegen. Fuer DiGA-Anwendungen empfiehlt sich eine explizite Beschraenkung auf deutsche Cloud-Regionen.

4. Logging ohne Retention Policy

Audit-Logs, die nach 30 Tagen automatisch geloescht werden, nuetzen bei einer Pruefung nichts. Definieren Sie Retention Policies, die den regulatorischen Mindestfristen entsprechen.

5. RBAC zu grosszuegig

cluster-admin-Rechte fuer Entwickler sind in Healthcare-Umgebungen nicht akzeptabel. Jede Rolle sollte nur die minimal notwendigen Berechtigungen haben. Regelmaessige RBAC-Reviews (mindestens quartalsweise) decken Privilege Creep auf.

Vergleich: Deployment-Optionen fuer Healthcare

Fuer die meisten Health-Tech-Unternehmen und MVZ ist Managed Kubernetes die pragmatische Wahl. Die grossen Cloud-Anbieter investieren erheblich in Compliance-Zertifizierungen, die Sie als Kunde mitnutzen koennen.

Naechste Schritte

1. Bestandsaufnahme: Welche Patientendaten verarbeiten Sie, und wo liegen sie aktuell?
2. Verschluesselung pruefen: Sind etcd, Volumes und die Service-Kommunikation verschluesselt?
3. RBAC-Review: Wer hat aktuell Zugriff auf Healthcare-Namespaces, und braucht er diesen Zugriff?
4. Monitoring einrichten: Ein Monitoring-Stack mit Prometheus und Grafana ist die Basis fuer Audit-Faehigkeit
5. 24/7-Betrieb planen: Gesundheitsdaten brauchen Rund-um-die-Uhr-Ueberwachung

Wenn Sie tiefer in die KRITIS-Thematik einsteigen wollen (relevant fuer Krankenhaeuser ab 30.000 vollstationaeren Faellen), empfehlen wir unseren KRITIS-Leitfaden. Fuer die allgemeine DSGVO-Compliance in Kubernetes-Umgebungen bietet die 7-Punkte-Checkliste einen strukturierten Einstieg.