TYPO3 auf Kubernetes unter IT-Grundschutz, Teil 10: Datenbank, Backup und Restore

01 — Im Cluster oder als verwalteter Dienst

Die erste Entscheidung fällt vor der ersten Zeile YAML. Eine verwaltete Datenbank des Cloud-Anbieters nimmt Patches, Replikation und Wiederherstellung auf einen Zeitpunkt ab. Dafür liegen die Daten außerhalb des Clusters, und der Anbieter wird Teil der Modellierung.

MariaDB als StatefulSet im Cluster hält alles in einer Hand. Eine eigene Instanz pro Mandant trennt die Daten sauber und macht Restores unabhängig voneinander. Der Preis: Updates, Sicherung und Hochverfügbarkeit liegen beim Betreiber. In der Praxis zeigt sich, dass die Instanz pro Mandant meist wichtiger ist als der Betriebsort. Eine gemeinsame Datenbank für viele Mandanten erschwert jede Isolation.

Beide Wege sind mit IT-Grundschutz vereinbar. Der Baustein APP.4.3 „Relationale Datenbanken“ gilt in beiden Fällen. Praktische Hinweise dazu enthält auch der BSI-Praxisleitfaden für Datenbanksysteme.

02 — Verbindungen und Rechte

Jede Verbindung zur Datenbank läuft verschlüsselt. MariaDB erzwingt das mit require_secure_transport=ON. Wer ohne TLS verbindet, wird abgewiesen, statt still im Klartext zu arbeiten. Mit einer eigenen CA pro Mandant, wie in Teil 5 beschrieben, prüft die Datenbank zusätzlich das Client-Zertifikat.

TYPO3 bekommt einen Benutzer, der nur seine eigene Datenbank sieht. Schema-Änderungen laufen beim Deployment mit einem getrennten Benutzer, dessen Zugangsdaten danach nicht im laufenden Pod liegen. Root-Zugang hat keine Anwendung.

Die Daten selbst liegen auf einem verschlüsselten Volume. Bei hohem Schutzbedarf verlangt APP.4.4.A20 eine verschlüsselte Datenhaltung bei Pods. Die Verschlüsselung des Speichersystems deckt den Fall eines abgezogenen Datenträgers ab. Gegen einen Angreifer mit Zugriff auf den laufenden Knoten hilft sie nicht. Das gehört in die Risikoanalyse.

03 — Sicherungen, die niemand verändern kann

Ein CronJob erstellt jede Nacht einen logischen Dump und lädt ihn in einen Objektspeicher. Zwei Eigenschaften des Buckets machen daraus eine Sicherung, die auch einen Angriff übersteht: Versionierung und Object Lock. Im Compliance-Modus kann ein gesperrtes Objekt während der Aufbewahrungsfrist niemand löschen oder überschreiben, auch nicht mit Administratorrechten. Den Governance-Modus kann dagegen umgehen, wer eine besondere Berechtigung hat. Für Sicherungen, die einen Angriff überstehen sollen, ist deshalb der Compliance-Modus die richtige Wahl.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "15 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      backoffLimit: 2
      template:
        spec:
          serviceAccountName: db-backup   # write-only identity for the bucket
          restartPolicy: Never
          containers:
            - name: dump
              image: registry.example.org/mariadb-backup@sha256:...
              command: ["/bin/backup.sh"] # mariadb-dump --single-transaction | gzip | upload
              securityContext:
                runAsNonRoot: true
                readOnlyRootFilesystem: true
                allowPrivilegeEscalation: false

Die Identität des Jobs darf in den Bucket schreiben, aber nicht lesen oder löschen. Auch der Knoten selbst hat keinen Lesezugriff. Wer den Cluster übernimmt, kommt so nicht an ältere Sicherungen und kann sie nicht zerstören. Snapshots des Volumes laufen als zweite, unabhängige Ebene daneben.

Zwei Kennzahlen gehören in das Datensicherungskonzept nach CON.3: das RPO, also wie viele Daten verloren gehen dürfen, und das RTO, also wie lange die Wiederherstellung dauern darf. Ein nächtlicher Dump bedeutet ein RPO von bis zu 24 Stunden. Reicht das bei hohem Schutzbedarf nicht, kommen Binärlogs hinzu. Mit ihnen lässt sich die Datenbank auf einen beliebigen Zeitpunkt zurückspielen, sofern sie laufend in denselben gesperrten Bucket kopiert werden. Die Sicherung im Cluster selbst behandelt APP.4.4.A5.

04 — Ein Backup, das niemand zurückgespielt hat, ist eine Hoffnung

Der wichtigste Teil des Konzepts ist der Restore. Er wird regelmäßig geübt, nach einem festen Runbook, und das Ergebnis wird protokolliert. Nur so ist belegt, dass Dump, Schlüssel und Zugangsdaten im Ernstfall zusammenpassen.

Ein bewährter Ablauf: eine leere Datenbank-Instanz in einem eigenen Namespace starten, den jüngsten Dump einspielen, TYPO3 dagegen starten und eine Stichprobe von Seiten prüfen. Die gemessene Dauer ist das tatsächliche RTO, nicht das geschätzte.

Typische Stolpersteine zeigen sich erst dabei. Die Zugangsdaten zum Bucket liegen nur im Cluster, der gerade ausgefallen ist. Der Dump enthält Cache-Tabellen, die TYPO3 ohnehin neu aufbaut, und bläht den Restore auf. Oder niemand weiß mehr, welche Version der Anwendung zum Dump gehört. Jeder dieser Punkte gehört ins Runbook, bevor er im Ernstfall auffällt.

Fazit

Die Datenbank bleibt der Teil des Clusters mit dem meisten Zustand. Verschlüsselte Verbindungen, eng geschnittene Rechte und unveränderliche Sicherungen decken Vertraulichkeit und Integrität ab. Die Verfügbarkeit steht und fällt mit dem geübten Restore.

Wie sich Sicherungen, Zugriffe und Auffälligkeiten nachweisen lassen, zeigt Teil 11: Nachweis und Betrieb. Zurück zu Teil 9: Autoscaling und Probes.