Das BSI stellt über ein öffentliches GitHub-Repository Sicherheitskonfigurationen für mehrere Datenbanksysteme bereit. Die Vorlagen sollen Admin- und DevOps-Teams helfen, zentrale Schutzmaßnahmen wie TLS-Verschlüsselung, Protokollierung, Berechtigungen und Backups konsistent umzusetzen – und typische Fehlkonfigurationen zu vermeiden.
Was veröffentlicht das BSI – und wofür ist es gedacht?
Im Kern geht es um eine Sammlung „sicherer“ bzw. gehärteter Konfigurationen für Datenbankmanagementsysteme, die als Ausgangspunkt für den produktiven Betrieb dienen sollen. Das Repository richtet sich laut Beschreibung an IT-Administration, Datenbankadministration und Entwicklerinnen bzw. Entwickler, die Datenbanken sicher betreiben wollen.
Wichtig: Die Dateien sind ausdrücklich als Orientierung gedacht. Sie ersetzen weder ein Sicherheitskonzept noch eine Risikoabwägung für die eigene Umgebung – und müssen vor dem Einsatz geprüft und angepasst werden.
Welche Datenbanken werden abgedeckt – und wie ist das Repository aufgebaut?
Stand der öffentlich einsehbaren README werden aktuell Konfigurationen für folgende Systeme genannt: MariaDB, MongoDB, MySQL und Weaviate. Zusätzlich kündigt das Repository an, künftig PostgreSQL und Redis ergänzen zu wollen.
Technisch ist die Sammlung so organisiert, dass pro Datenbanksystem und Version getrennte Ordner existieren. Für Deployments nennt das BSI zwei Schienen:
- Linux mit Docker Compose (containerisierte, automatisierte Setups)
- Windows ohne Docker (klassische lokale Installationen, z. B. für Entwicklungsumgebungen)
Zu den Inhalten gehören neben Konfigurationsdateien auch Initialisierungsskripte sowie Hinweise zur Härtung („hardening“).
Welche Sicherheitsaspekte adressieren die Vorlagen?
Das Repository formuliert Sicherheitsziele, die in der Praxis häufig an Konfigurationsdetails hängen – und genau dort passieren auch viele Fehler. Genannt werden unter anderem:
- Verschlüsselte Netzwerkkommunikation (TLS/SSL) und Zugangsbeschränkungen auf vertrauenswürdige Netze/Hosts
- Logging/Protokollierung, insbesondere für fehlgeschlagene oder auffällige Zugriffe
- Sichere Storage- und Dateirechte für Daten- und Log-Verzeichnisse
- Backups (regelmäßig, automatisiert, idealerweise verschlüsselt) plus Restore-Tests
- Sichere Authentifizierung & Rechtevergabe (Rollen, Prinzip der minimalen Rechte)
- Updates & Wartung als laufende Betriebsaufgabe (Patch-Management, Log-Monitoring)
Damit deckt das BSI nicht nur „ein“ Feature ab, sondern die typischen Bausteine, die bei Datenbanken zusammenwirken müssen, damit ein Setup belastbar wird.
Warum Datenbanken ein Angriffsvektor bleiben
Datenbanken sind selten „nur ein Backend“. Sie speichern Geschäftsgeheimnisse, personenbezogene Daten, Zugangs- und Protokolldaten – und sind damit ein attraktives Ziel. Gleichzeitig sind sie in moderne Architekturen eingebettet: Container-Plattformen, CI/CD, Cloud-Netzwerke, Microservices, temporäre Testumgebungen. Das erhöht die Komplexität – und damit die Wahrscheinlichkeit, dass an irgendeiner Stelle zu offen konfiguriert wird (Netzwerkbindung, Standardports, zu breite Rollen, unzureichende Protokollierung, fehlende Transportverschlüsselung).
Hinzu kommt: Datenbanksysteme sind wie andere Kernkomponenten regelmäßig von Sicherheitslücken betroffen, die zeitnahes Patchen erfordern. Beispiele dafür finden sich immer wieder in Warnmeldungen und Fachmedien, etwa zu MariaDB oder MongoDB.
Gerade bei neueren Datenbankklassen wie Vektor-Datenbanken (z. B. Weaviate) steigt der Druck zusätzlich: Sie landen häufig in KI/LLM-Nähe und damit in Umgebungen, die schnell wachsen, experimentell sind und oft über APIs angebunden werden. Weaviate selbst beschreibt sich als „vector database“ für semantische Suche und ähnliche Anwendungsfälle – also typischerweise mit datenintensiven Workloads.