Datenbanken im BSI-Bauplan: Was der neue Praxisleitfaden für relationale, NoSQL- und containerisierte Systeme operativ verändert

Am 6. Mai 2026 hat das BSI seinen Praxisleitfaden zur sicheren Nutzung von relationalen, NoSQL-, Cloud- und containerisierten Datenbanksystemen veröffentlicht. Adressaten sind Verantwortliche aus Informationssicherheit, IT-Betrieb und IT-Architektur. Der Leitfaden ist kein Pflichtdokument im NIS-2-Sinn, wird aber sehr wahrscheinlich ab Sommer 2026 die De-facto-Mess-Skala, an der Auditor:innen, Cyber-Versicherer und NIS-2-Aufsichtsstellen die Datenbank-Schicht in DACH-Stacks bewerten.

Vier inhaltliche Achsen: (1) Authentifizierung und Berechtigung mit sauberer Schema-Granularität und Mandanten-Trennung; (2) Verschlüsselung in Ruhe (LUKS/dm-crypt, KMS) und in Transit (TLS auch für Bridge-Netze); (3) Container-Lebenszyklus mit getrennten Daten- und Anwendungs-Containern und Update-Pfad-Trennung; (4) Backup/Restore plus Datenabfluss-Detektion auf der DB-Schicht. Empfehlung: 2–3 Stunden Erstlektüre diese Woche, Mapping-Tabelle binnen zwei Wochen, TLS auf allen DB-Pfaden binnen vier Wochen, dokumentierte Restore-Übung binnen drei Monaten.

Was im Leitfaden steht

Der Praxisleitfaden ist nach Aussage des BSI kein Produkt-Audit und keine MariaDB-/PostgreSQL-/MongoDB-Spezifika-Sammlung. Er ist ein Architektur- und Betriebs-Rahmen: Welche Sicherheits-Entscheidungen treffe ich beim Aufsetzen einer Datenbank-Schicht, welche bei der Anbindung an eine Anwendung, welche im Lebenszyklus (Backup, Restore, Migration, End-of-Life), welche im Betrieb eines Containers, der eine Datenbank trägt?

Der inhaltliche Schwerpunkt liegt auf vier Achsen:

Erstens — Authentifizierung und Berechtigung. Der Leitfaden adressiert die in DACH-KMU-Stacks notorisch dünne Rollen-Granularität: ein einziger Application-User mit Schreibrechten auf das gesamte Schema, eine identische Rolle für Test- und Prod-Datenbank, kein Read-Only-Pfad für Reporting. Das BSI empfiehlt saubere Trennung nach Funktion und Mandant sowie konsequente Nutzung von Schema-Privilegien statt Tabellen-Privilegien.

Zweitens — Verschlüsselung im Ruhezustand und in Transit. Der Leitfaden zieht die Linie deutlich: TLS für jede Datenbank-Verbindung, auch innerhalb einer Container-Composition. „Vertraue nicht dem Bridge-Netz“ ist die Ein-Satz-Zusammenfassung — eine Position, die in Reviews regelmäßig auf das überraschte ‚aber das ist ein internes Netz‘ trifft. Für die Verschlüsselung im Ruhezustand setzt der Leitfaden auf Storage-Layer-Encryption (LUKS, dm-crypt, Cloud-Provider-Keys mit eigenem KMS), nicht auf In-Database-TDE als Pflicht — eine pragmatische Entscheidung für DACH-KMU.

Drittens — Container-Lebenszyklus. Hier wird der Leitfaden für moderne Stacks am interessantesten. Eine Datenbank in einem Container ist kein „normaler“ Container: Backup-Volumes, Persistenz-Mounts, Update-Pfade und Restart-Verhalten unterscheiden sich von zustandslosen Anwendungs-Containern. Der Leitfaden empfiehlt eine klare Trennung zwischen Daten- und Anwendungs-Containern, dedizierte Volumes mit Verschlüsselung, und eine Update-Strategie, die das Image-Update vom Schema-Update trennt.

Viertens — Backup, Restore und Datenabfluss-Detektion. Der Leitfaden zieht eine Linie, die sich mit dem Bitwarden-Pattern (UID 280) deckt: Ein Backup, das nicht regelmäßig restauriert wird, ist kein Backup, sondern eine Annahme. Daneben adressiert er die im NIS-2-Kontext zunehmend wichtige Frage der Datenabfluss-Detektion — Logging und Anomalie-Erkennung auf der Datenbank-Schicht selbst, nicht erst auf der Netzwerk-Ebene davor.

Bewusst weggelassen sind konkrete Tool-Empfehlungen. Es gibt keinen „BSI-empfohlenen Backup-Operator“, kein „BSI-zertifiziertes TDE-Modul“. Das ist die richtige Entscheidung, weil das Tooling-Feld zu schnell wandert. Es bedeutet aber, dass der Leitfaden in den DACH-Mittelstand-Stacks nur dann ankommt, wenn Beratung oder interne Architektur-Verantwortliche die Übersetzung in konkrete Konfigurationen leisten.

Wie der Leitfaden in NIS-2 und ISO 27001 einrastet

Strukturell ist der Praxisleitfaden Teil einer breiteren BSI-Initiative der letzten Wochen: Ende April der C5:2026-Standard für Cloud-Dienste mit erstmaligen Anforderungen an Post-Quantum-Kryptografie und Confidential Computing, Anfang Mai der „Cyberdome“-Aufbau für nationale Schutz-Infrastruktur, jetzt der Datenbank-Leitfaden als operative Handreichung. Die Linie ist konsistent: Das BSI rüstet die Mess- und Bewertungs-Infrastruktur für die NIS-2-Aufsicht auf, die ab Sommer 2026 spürbar wird — das Registrierungsfenster ist seit 6. März 2026 geschlossen.

Für ISO-27001-Häuser passt der Leitfaden problemlos in die Annex-A-Controls 8.10 (Information deletion), 8.11 (Data masking), 8.24 (Use of cryptography) und 8.13 (Information backup). Ein vorhandenes ISMS kann den Leitfaden als Detail-Spezifikation für die Datenbank-Schicht in die bestehende Risiko-Matrix einhängen, ohne ein eigenes Projekt aufzusetzen.

Wer kein formales ISMS hat, sondern einen DevSecOps-Pragma-Stack betreibt, hat mit dem Leitfaden ein neues Werkzeug in der Auseinandersetzung mit dem Cyber-Versicherer: Der Versicherer wird ab Sommer 2026 fragen, „nach welchem Standard härten Sie Ihre Datenbank-Schicht?“ — der Praxisleitfaden ist eine Antwort, die nichts kostet und den BSI-Stempel hat.

Was wir konkret empfehlen

Diese Woche: Lesen Sie den Leitfaden einmal komplett durch. Er ist kompakt; ein DevOps- oder DBA-verantwortlicher Mensch braucht zwei bis drei Stunden, um die Achsen zu erfassen. Ohne diese Lektüre bleibt jeder Folgeschritt Interpretation.

Innerhalb von zwei Wochen: Bauen Sie eine Mapping-Tabelle. Auf der einen Seite die BSI-Empfehlungen aus den vier Achsen, auf der anderen Seite Ihr Ist-Zustand. Wo erfüllen Sie die Empfehlung, wo nicht, wo bewusst nicht (z.B. LUKS auf Bare-Metal nicht aktiviert, dafür Cloud-Provider-Encryption). Die Mapping-Tabelle ist das Dokument, das Sie im nächsten Audit-Gespräch vorlegen.

Innerhalb von vier Wochen: TLS auf allen Datenbank-Pfaden. Wenn Sie heute noch Bridge-Network-Verkehr ohne TLS haben (Sylius-App-Container ↔ MariaDB-Container, TYPO3-Pod ↔ PostgreSQL-Pod), ist das die schnellste, sichtbarste und audittächtigste Verbesserung. Self-signed-Zertifikate aus der eigenen CA reichen für interne Pfade; cert-manager im K8s-Cluster automatisiert die Rotation.

Innerhalb von drei Monaten: Restore-Übung. Nicht „Backup-Test“, sondern echtes Restore in eine isolierte Umgebung, mit Zeit-Messung, Daten-Konsistenz-Prüfung und einem dokumentierten Protokoll. Der Leitfaden macht die Übung nicht zur Pflicht, aber er macht das Fehlen einer dokumentierten Restore-Übung zur typischen Auditfrage.

Was wir bewusst nicht empfehlen

Wir empfehlen nicht, eine Datenbank-Migration anzustoßen, nur weil der Leitfaden NoSQL und relationale Systeme parallel adressiert. Wer auf MariaDB/PostgreSQL produktiv und stabil läuft, sollte das nicht zugunsten eines Document-Stores oder umgekehrt umstellen, nur weil das BSI-Dokument beide kennt. Die Wahl der Datenbank-Klasse ist eine Architektur-Entscheidung, kein Compliance-Reflex.

Wir empfehlen ebenso wenig, sich auf In-Database-TDE als Allheilmittel zu verlassen. Der Leitfaden setzt pragmatisch auf Storage-Layer-Encryption als Default; In-Database-TDE ist die teurere Variante mit eigenen Schwächen (Schlüsselverwaltung, Performance, Reibung mit Backup-Tools). Wer die Wahl hat, fährt für die meisten DACH-KMU-Stacks mit dm-crypt oder einer KMS-gemanagten Cloud-Encryption günstiger und robuster.

Wer am stärksten betroffen ist

TYPO3- und Sylius-Hosting-Häuser mit Mehrmandanten-Setups, die mehrere Kund:innen-Datenbanken in derselben MariaDB- oder PostgreSQL-Instanz halten — typisch in Hosting-Verträgen mit dünner Marge und gemeinsamer Infrastruktur. Der Leitfaden macht die saubere Schema-/Mandanten-Trennung zur Erwartung; wer das heute über einen einzigen Application-User mit Schreibrechten auf alles fährt, hat eine ehrliche Aufgabe.

KMU mit Self-hosted Datenbank-Containern in Docker Compose, oft als Begleit-Container zu einer Sylius- oder Symfony-Anwendung. Hier sind die Mängel typisch in der Volume-Verschlüsselung, in der Update-Strategie (Image-Update zieht Schema-Update mit, ohne dass es jemand merkt) und in der Backup-Disziplin.

Mandanten mit NIS-2-Betroffenheit, die ihre Registrierung nicht abgeschlossen haben, im laufenden Audit-Vorbereitungs-Prozess. Hier ist der Praxisleitfaden ein willkommener Anker, weil er der Aufsichtsstelle eine konkrete Mess-Skala für die Datenbankschicht bietet, ohne dass der Mandant ein eigenes Mess-System bauen muss.

Fazit

Der Praxisleitfaden ist keine Sensation und löst kein akutes Sicherheitsproblem aus. Er ist ein Bauplan — und er ist die Art von Bauplan, an dem sich in den nächsten Monaten die Audit-Gespräche, Versicherer-Fragen und NIS-2-Klärungen ausrichten werden. Wer ihn ignoriert, wird ihn beim nächsten externen Termin trotzdem auf dem Tisch haben — nur dann ohne eigene Mapping-Tabelle.

Die Frage lautet nicht, ob der Leitfaden für Ihre Datenbank-Schicht relevant ist. Sie lautet, ob Sie heute die zwei Stunden für die erste Lektüre und die zwei Wochen für die Mapping-Tabelle haben — oder ob Sie diese Arbeit unter Audit-Druck im Herbst nachholen.

Persönlicher Hintergrund und technische Details zur TLS-Pflicht in Container-Compositions und zur Restore-Übung in TYPO3-/Sylius-Stacks: ole-hartwig.eu.