Angeregt durch eine Diskussion neulich habe ich ein wenig genauer über die Verschlüsselung von Datenbanken nachgedacht.

Der Anstoß kam aus der Tatsachem dass bereits seit vielen Jahrzehnten Datenbanken nicht mehr nur als Client-Server-Modell genutzt werden, sondern auch Anwendungen, die auf lokalen PCs laufen solche Datenabanken zur Speicherung umfangreicher Datenbestände nutzen.

Wie jede andere Datei auch ist eine Datei, die die Daten einer Datenbank beherbergt prinzipiell lesbar und sie kann kopiert werden. Damit geht ein Problem einher: Die Daten in dieser Datenbank können gestohlen werden.

Das traditionelle Modell einer Client-Server-Architektur hat dieses Problem nur eingeschränkt: Der Rechner mit dem Datenbankserver ist lokal von denjenigen getrennt, an dem normale Nutzer mit dem Client mit den im Server gespeicherten Daten arbeiten. Dadurch sind die Daten in der Datenbank auch ohne Verschlüsselung geschützt - wenn alle Anwender hinreichend sichere Passwörter benutzen.

Dieser Schutz über das Datenbankpasswort greift jedoch nicht mehr, wenn die Datenbank, bzw. deren Daten nicht mehr auf einem räumlich getrennten, besonders gesicherten Server gelagert werden.

Tatsächlich ist es so, dass das Passwort für den Datenbankzugang in vielen Fällen komplett irrelevant wird: Es ist lediglich wichtig, wie das Administratorkonto abgesichert ist. Als Administrator kann ich nämlich viele der heutigen Datenbanksysteme auf einfache Art und Weise von jeglichem Paswortschutz entkleiden - habe ich Administratorrechte, kann ich sämtliche Daten in einer Datenbank sehen!

Zwei Beispiele sollen das illustrieren: Hier habe ich Links herausgesucht, die erklären, wie ein solcher Angriff für MySQL und PostgreSQL funktionieren könnte.

Wie bereits angedeutet wäre bereits viel gewonnen, in Anwendungen, die auf die klassische Trennung zwischen Client und Server verzichten einfach die Datenbank zu verschlüsseln. Dazu kommen mehrere Methoden in Betracht. Ich zähle hier mal nur drei davon auf:

1. Transparente Verschlüsselung auf Anwendungsebene. Dazu müsste der Zugriff auf die Daten über eine transparente Zwischenschicht laufen, die Daten vopr dem Schreiben in die Datenbank verschlüsselt und nach dem Lesen aus der Datenbank entsprechend entschlüsselt. Ein solcher Mechanismus wäre - zum Beispiel durch einen entsprechenden JDBC-Treiber relativ problemlos zu schaffen. Allerdings hätte dieser Ansatz seine Tücken: Man müsste zu seiner Nutzung drastische Änderungen am Datenmodell vornehmen: Numerische Werte etwa oder Zeitstempel könnten nicht mehr als entsprechende Typen im Datenmodell abgebildet werden, sondern müssten als VARCHAR in der Datenbank gespeichert werden. Außerdem könnten praktisch keine der Features einer Datenbank mehr benutzt werden: spezielle Operatoren in WHERE Klauseln wie etwa BETWEEN würden nicht mehr funktionieren. Des weiteren müssten eventuell auch bereits bestehende VARCHAR Spalten geändert werden, weil der verschlüsselte Text eventuell länger wäre als der Klartext. Diese Methode könnte man nur dann einsetzen, wenn nur wenige bestimmte Spalten sensible Daten enthielten und man ein Datenmodell vor sich hat, das historisch gewachsen und daher nur unter unvertretbar hohem Aufwand änderbar ist.

2. Verschlüsseln des Datenträgers, auf dem sich die Daten befinden. Dazu muss nicht unbedingt eine gesamte Partition oder Festplatte verschlüsselt werden. Unter Linux existiert eine Möglichkeit, einzelne Dateien / Verzeichnisse zu verschlüsseln. Man könnte also zum Beispiel das Verzeichnis, das die Dateien des Datenbankservers enthält, auf diese Weise verschlüsseln. Das Problem hierbei wäre jedoch, dass das Entschlüsseln der Partition und der Start und Stop des Datenbankservers unabhängig voneinander verlaufen: Wenn die Partition entschlüsselt ist, kann ich immer noch die oben angeführten Angriffe durchführen. Eine Besserung würde nur eintreten, wenn der Stop des Datenbankservers automatisch die Daten verschlüsseln würde.

3. Verschlüsselung der Datenbank mit Bordmitteln. Dies ist die Variante, die bevorzugt werden sollte: damit ist das bei 2. erwähnte Synchronisationsproblem behoben: Die Daten existieren nur dann im Klartext, wenn die Datenbank läuft. Wird durch einen Administrator der Passwortschutz für Datenbankanwender entfernt, hat der Angreifer nichts gewonnen, denn die Verschlüsselung ist weiterhin intakt.