Verschlüsselung (relationaler) Datenbanken

vorhergehende Artikel in: Datenbanken Security Rants
26.08.2023

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.

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

Neueste Artikel

  • SQL Funktionen in SQLite als BeanShell-Scripts

    Ich habe bereits hin und wieder über Erweiterungen der sQLshell berichtet, die bestimmte spezifische, proprietäre Features des jeweiligen DBMS in der sQLshell verfügbar machen.

    Weiterlesen...
  • Spieleengine IX

    Es gibt seit Ewigkeiten mal wieder Neues von meiner eigenen Spieleengine!

    Weiterlesen...
  • Neue Version plantumlinterfaceproxy napkin look

    Es gibt eine neue Version des Projektes plantumlinterfaceproxy - Codename napkin look.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.