Am 6. Mai 2026 hat das Bundesamt für Sicherheit in der Informationstechnik einen Praxisleitfaden zur sicheren Nutzung von relationalen, NoSQL-, Cloud- und containerisierten Datenbanksystemen veröffentlicht. Der Leitfaden tritt nicht als verbindliche Norm auf, sondern als Orientierungsrahmen für Informationssicherheit, IT-Betrieb und IT-Architektur — und er wird genau in dieser Funktion zur Mess-Skala für Audits, Versicherer und NIS-2-Bewertungen.
Was hat sich geändert? Das BSI legt eine kompakte Handreichung für Datenbank-Schichten vor — architekturnah, nicht produkt-spezifisch. Wer sollte weiterlesen? Betreiber von TYPO3-, Sylius- oder Symfony-Stacks mit Datenbank-Containern, Mehrmandanten-Hosting-Häuser und alle, die im nächsten halben Jahr einen NIS-2- oder ISO-27001-Audit-Termin auf dem Plan haben. Was steht heute an? Erstlektüre, Mapping-Tabelle, TLS auf allen DB-Pfaden — in dieser Reihenfolge.
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.
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.
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.
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.
Ich empfehle 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.
Ich empfehle 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.
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.
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.
Ja — aber nicht aus regulatorischer Pflicht. Drei Stellen, an denen der Leitfaden auch ohne NIS-2-Betroffenheit greift: (1) Cyber-Versicherer fragen ab Sommer 2026 nach einem Standard für die Datenbank-Schicht; „BSI-Praxisleitfaden“ ist eine kosten-neutrale Antwort. (2) Auftraggeber im b2b-Geschäft (gerade KRITIS-pflichtige Kund:innen) werden den Leitfaden bei Lieferanten-Audits zitieren. (3) ISO-27001-Annex-A-Mappings werden den Leitfaden als Detail-Spezifikation aufnehmen, sodass auch ohne formale NIS-2-Betroffenheit eine ISMS-Prüfung Bezug nehmen wird.
Für interne Container-zu-Container-Pfade ja. Eine eigene interne CA, deren Root-Zertifikat in alle beteiligten Container vertraut wird, ist mit cert-manager oder einem schlanken step-ca-Setup in einem Vormittag aufgebaut und löst die zwei eigentlichen Probleme: Verschlüsselung des Bridge-Traffics und gegenseitige Authentifizierung (mTLS). Public-CA-Zertifikate (Let’s Encrypt, ZeroSSL) sind für interne Pfade fehl am Platz — sie erfordern erreichbare Domains und verkomplizieren die Rotation. Der BSI-Leitfaden verlangt TLS, nicht Public-CA-TLS.
Bei Managed-Datenbank-Services (AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL) liegt die Infrastruktur-Verantwortung beim Anbieter — also Patching der DB-Engine, Volume-Verschlüsselung at-rest, Backup-Mechanik. Bei Ihnen bleiben weiterhin: die Berechtigungs-Granularität, die TLS-Erzwingung (auch RDS verbindet ohne TLS, wenn der Client das nicht verlangt), die Rotation der Anwendungs-Credentials, die Restore-Übung (Cloud-Backup ≠ getesteter Restore-Pfad) und die Daten-Klassifizierung. Eine BSI-konforme Mapping-Tabelle für Cloud-DBs hat etwa zwei Drittel der Achsen „grün durch Provider“ — die restlichen sind operative Pflicht.
Vier Komponenten: (1) Isoliertes Ziel-Setup (eigene VM oder eigener Compose-Stack), das Production-ähnlich ist, aber nicht in Production schreibt. (2) Restore des jüngsten Backups (Zeitmessung: vom „Befehl ab“ bis zum „DB bereit“). (3) Konsistenz-Prüfungen — z.B. CHECKSUM TABLE in MariaDB/MySQL, pg_dump --schema-only-Vergleich in PostgreSQL, eine sample-basierte Integritäts-Prüfung auf geschäftskritischen Tabellen. (4) Protokoll: ein Markdown-File im Repo mit Zeit, Stand, Verantwortlichem, Auffälligkeiten. Sechs Monate später muß dieser Eintrag eine Auditfrage beantworten können, ohne dass jemand die Übung noch im Kopf hat.
Der Leitfaden setzt pragmatisch auf Storage-Layer-Encryption (LUKS, dm-crypt auf Bare-Metal; KMS-gemanagte Volume-Encryption in der Cloud) als Default. In-Database-TDE (z.B. InnoDB Transparent Data Encryption oder pg_crypto-basierte Spaltenverschlüsselung) ist nicht ausgeschlossen, aber als zusätzliche Schicht für besonders sensible Daten gedacht, nicht als primäre Defense. Praktisch: Storage-Layer-Encryption ist robust, performant und mit Backups verträglich; In-Database-TDE bringt Schlüsselverwaltungs-Reibung, Performance-Kosten und Komplikationen mit Backup-Tools. Für 90 Prozent der DACH-KMU ist Storage-Layer-Encryption die korrekte Wahl.
Mapping-Tabelle: zwei bis vier Stunden für DBA und/oder DevOps-Verantwortlichen. TLS auf allen DB-Pfaden: ein bis zwei Personentage für eine cert-manager- oder step-ca-Aufsetzung plus die Konfigurationsänderungen in den Application-Containern. Schema-/Mandanten-Trennung in einer historisch gewachsenen Datenbank: 3–10 Personentage, abhängig vom Migrations-Aufwand. Restore-Übung erstmalig: ein Personentag plus Folge-Routine. Backup-Verschlüsselung und Datenabfluss-Detektion: 1–3 Personentage je nach Tool-Stack. Für einen mittleren Sylius- oder TYPO3-Hosting-Mandanten ist die komplette Umsetzung damit ein Aufwand von 2–3 Personenwochen — verteilt über 8–12 Wochen.