Datenbanksicherheit: Bedrohungen, Maßnahmen und Best Practices

Was ist Datenbanksicherheit?

Datenbanksicherheit umfasst alle Maßnahmen, die eine Datenbank und ihre Daten vor unbefugtem Zugriff, Veränderung, Löschung und Diebstahl schützen. Sie verbindet technische Maßnahmen (Authentifizierung, Verschlüsselung, Netzwerkisolation), betriebliche Gewohnheiten (Patches, Auditing, getestete Backups) und Regeln (wer welche Daten sehen darf und wie lange sie aufbewahrt werden).

Datenbanken sind ein bevorzugtes Ziel, weil sie das, was Angreifer suchen, an einem Ort bündeln: Kundendaten, Zugangsdaten und zahlungsbezogene Daten. Dieselben Maßnahmen schützen auch vor ehrlichen Fehlern, etwa einem Entwickler, der ein DELETE gegen die Produktion ausführt.

Typische Bedrohungen

Die wichtigsten Maßnahmen

Authentifizierung

Geben Sie jeder Person und jedem Dienst ein eigenes Konto, ohne gemeinsame Logins. Wo Ihre Plattform es unterstützt, sind kurzlebige, identitätsbasierte Zugangsdaten langlebigen Passwörtern vorzuziehen. Das ist dieselbe Disziplin wie beim Identity and Access Management im Rest Ihres Stacks.

Autorisierung und Least Privilege

Jedes Konto erhält nur die Rechte, die es braucht. Das Anwendungskonto sollte weder das Schema besitzen noch Verwaltungsbefehle ausführen, Administratoren nutzen eigene Konten. Eine rollenbasierte Rechteliste ist eine Form von Access Control List.

Verschlüsselung bei Übertragung und Speicherung

Verlangen Sie TLS für jede Verbindung und weisen Sie unverschlüsselte ab. Verschlüsseln Sie Speicher und Backups, damit eine gestohlene Platte oder ein Snapshot allein nutzlos ist. Besonders sensible Felder verschlüsseln Sie zusätzlich getrennt, wenn der Datenbankbetreiber sie nicht sehen soll.

Netzwerkisolation

Betreiben Sie die Datenbank in einem privaten Netz. Anwendungen erreichen sie über private Routen, Administratoren über VPN oder Bastion Host. Beschränken Sie, welche Quellen Firewall oder Security Group zulassen.

Auditing, Patching und Backups

Protokollieren Sie Rechteänderungen, Schemaänderungen und Massenexporte und lassen Sie sich bei Auffälligem alarmieren. Spielen Sie Patches für Datenbank und Betriebssystem regelmäßig ein. Erstellen Sie verschlüsselte Backups, lagern Sie eine Kopie in einem getrennten Account oder einer anderen Region und testen Sie die Wiederherstellung, denn ein nie wiederhergestelltes Backup ist nur eine Annahme.

SQL-Injection: der Klassiker

SQL-Injection entsteht, wenn Benutzereingaben in einen Abfragestring eingebaut werden. Das OWASP SQL Injection Prevention Cheat Sheet nennt Prepared Statements (parametrisierte Abfragen) als wichtigste Abwehr, dazu Allow-List-Validierung für Teile, die sich nicht binden lassen, etwa Tabellennamen oder Sortierung, und warnt, dass Escaping fehleranfällig ist. Außerdem sollten Anwendungskonten nie DBA- oder Admin-Rechte haben.

# Verwundbar: Eingabe wird in die Abfrage eingefügt
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)

# Sicher: Der Treiber sendet den Wert getrennt vom SQL
cursor.execute("SELECT * FROM users WHERE email = %s", (user_input,))

ORMs parametrisieren standardmäßig, aber ihre Raw-Query-Hintertüren sind ein häufiger Weg, wie Injection zurückkehrt. Die vollständige Liste steht im OWASP-Cheat-Sheet (englisch). Injection erreicht die Datenbank über Ihre API, API-Sicherheit ist also auch Datenbanksicherheit.

Umgang mit sensiblen Daten

• Passwörter: speichern Sie einen langsamen, gesalzenen Hash (bcrypt, scrypt oder Argon2), nie das Passwort oder eine umkehrbare Verschlüsselung.
• Personen- und Zahlungsdaten: auf Spalten- oder Anwendungsebene verschlüsseln oder tokenisieren, sodass der echte Wert in einem eigenen Tresor liegt.
• Test- und Dev-Daten: maskieren oder synthetisch erzeugen statt die Produktion zu kopieren.
• Mandantendaten: Row-Level-Security nutzen, wo die Engine sie bietet. In PostgreSQL zeigt eine Tabelle mit aktivierter Row Security und ohne Policy normalen Nutzern keine Zeilen, Tabelleneigentümer und Superuser umgehen sie aber, sofern Sie das nicht erzwingen.

Compliance in einem Absatz

Regelwerke wie DSGVO, HIPAA, PCI DSS und SOC 2 verlangen jeweils Zugriffskontrolle, Verschlüsselung, Protokollierung und Incident Response rund um die erfassten Daten. Nach Art. 33 DSGVO ist eine Verletzung des Schutzes personenbezogener Daten der Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden nach Bekanntwerden zu melden. Klären Sie mit Ihren Compliance-Beratern, welche Regeln für Sie gelten.

Häufige Fehler

• Die App als Admin verbinden, weil die Einrichtung dadurch einfacher wird.
• Produktionsdaten in Staging kopieren und unmaskiert lassen.
• Nie eine Wiederherstellung testen.
• Zugangsdaten in Code, CI-Logs oder Container-Images statt in einem Secrets Manager.
• Verschlüsselung für die ganze Antwort halten. Sie stoppt weder Injection noch ein gestohlenes Anwendungspasswort.

Datenbanksicherheit, Lasttests und Monitoring

LoadFocus sucht nicht nach Schwachstellen, aber Performance-Arbeit betrifft dieselben Systeme. Ein Lasttest zeigt, wie sich Ihre Datenbank bei steigender Nutzerzahl verhält, etwa wenn sich langsame Abfragen stauen oder der Connection Pool leerläuft (siehe how to optimize database connection pools, englisch). Wenn Sie ihn gegen eine Staging-Umgebung fahren, nutzen Sie maskierte oder synthetische Daten, wie in cloud testing security best practices (englisch) beschrieben. API-Monitoring prüft Ihre datenbankgestützten Endpunkte nach Zeitplan, sodass ein ausfallender oder langsamer Endpunkt einen Alarm auslöst, statt auf eine Kundenmeldung zu warten.

Häufige Fragen: Datenbanksicherheit

Wie verhindere ich SQL-Injection?

Nutzen Sie parametrisierte Abfragen oder Prepared Statements für jede Abfrage mit Benutzereingaben, validieren Sie nicht bindbare Bezeichner per Allow-List und verbinden Sie sich mit einem Konto, das nur die nötigen Rechte hat.

Soll ich in der Anwendung oder in der Datenbank verschlüsseln?

Verschlüsselung in der Datenbank ist einfacher zu betreiben, die Datenbank kann die Klartextdaten aber lesen. Verschlüsselung in der Anwendung hält Schlüssel von der Datenbank fern, erschwert aber Suche und Sortierung. Besonders sensible Felder rechtfertigen oft beides.

Was ist der Unterschied zwischen Verschlüsselung im Ruhezustand und bei der Übertragung?

Im Ruhezustand schützt gespeicherte Daten wie Platten und Backups. Bei der Übertragung schützt Daten im Netzwerk zwischen Anwendung und Datenbank. Sie brauchen beides.

Darf ich meine Datenbank ins Internet stellen?

Fast nie. Betreiben Sie sie in einem privaten Netz und lassen Sie nur Ihre Anwendungsserver und einen kontrollierten Admin-Zugang zu.

Was ist Row-Level-Security?

Eine Datenbankfunktion, die anhand von Ihnen definierter Policies filtert, welche Zeilen ein Nutzer lesen oder ändern darf. Sie dient bei mandantenfähigen Anwendungen als zweite Verteidigungslinie hinter den Prüfungen der Anwendung.

Wie bemerke ich einen Datenbank-Einbruch?

Audit-Logs plus Alarme bei Auffälligkeiten: Massenexporte, Abfragen zu ungewöhnlichen Zeiten, neue privilegierte Konten und Schemaänderungen außerhalb eines geplanten Änderungsfensters.