Encryption at Rest schützt nicht vor Zugriff: Warum Datenbankverschlüsselung weitergehen muss

Was verschlüsselte Volumes, Datenbankzugänge, Backups und Spaltenverschlüsselung jeweils leisten — und wo ihre Grenzen liegen.

Eine Datenbank liegt auf einer verschlüsselten Festplatte. Das klingt sicher. Dann meldet sich jemand mit gültigen Zugangsdaten an und führt SELECT aus. Die Daten erscheinen lesbar. Genau an diesem Punkt endet der Schutz von Encryption at Rest.

Eine Datenbank liegt auf einem verschlüsselten Volume. Das klingt zunächst nach einem soliden Schutz. Dann meldet sich jemand mit gültigen Zugangsdaten an und führt einen SELECT aus. Die Daten erscheinen lesbar.

Das ist kein Widerspruch und auch kein Fehler der Verschlüsselung. Es zeigt nur, wovor sie schützen soll — und wovor nicht.

Encryption at Rest schützt Daten im Ruhezustand: auf Festplatten, SSDs, Cloud-Volumes, Snapshots oder Datenträgern, die nicht aktiv von der Datenbank verwendet werden. Wird ein Datenträger gestohlen oder ein Snapshot kopiert, soll der Inhalt ohne den passenden Schlüssel nicht direkt lesbar sein.

Sobald die Datenbank aber läuft und eine Anwendung oder ein Benutzer korrekt verbunden ist, müssen die Daten für die Verarbeitung entschlüsselt werden. Wer über ausreichende Rechte verfügt, kann sie dann auch lesen. Genau an dieser Grenze beginnt die Frage, ob besonders sensible Werte zusätzlich auf Datenebene geschützt werden müssen.

Schutz ist keine Sicherheitsgarantie

„Schutz“ bedeutet in diesem Beitrag nicht: Danach kann niemals mehr etwas passieren. Jede Maßnahme reduziert bestimmte Risiken und erschwert bestimmte Zugriffe. Ein verschlüsseltes Volume ist besser als ein unverschlüsseltes Volume. Verschlüsselte sensible Spalten sind besser als lesbare Werte. Mehrere aufeinander abgestimmte Ebenen sind besser als eine einzelne Maßnahme.

Absolute Sicherheit gibt es nicht. Das Ziel ist, Angriffe zu erschweren, Folgen zu begrenzen und Daten auch bei einzelnen Fehlern nicht sofort vollständig offenzulegen.

Die Schutzebenen sind nicht dasselbe

In der Praxis werden verschiedene Sicherheitsmaßnahmen häufig unter dem Sammelbegriff „Verschlüsselung“ zusammengefasst. Sie lösen aber unterschiedliche Probleme:

• TLS schützt Daten während der Übertragung.
• Datenbankrechte begrenzen, wer welche Abfragen und Änderungen durchführen darf.
• Encryption at Rest schützt gespeicherte Daten auf Datenträgern und Volumes.
• Spalten- oder Anwendungsverschlüsselung schützt besonders sensible Werte auch innerhalb der Datenbank.
• Verschlüsselte Backups schützen Sicherungen, wenn sie kopiert oder außerhalb des eigentlichen Systems abgelegt werden.

Keine dieser Ebenen ersetzt die anderen. Sie greifen an unterschiedlichen Stellen der Kette.

Was Encryption at Rest tatsächlich leistet

Wenn ein Cloud-Volume oder eine Festplatte verschlüsselt ist, kann ein Angreifer den Datenträger nicht einfach ausbauen und die Datenbankdateien im Klartext lesen. Das ist besonders relevant für:

• gestohlene oder ausgemusterte Datenträger,
• kopierte Snapshots,
• falsch entsorgte Hardware,
• Offline-Kopien von Datenbankdateien,
• bestimmte Zugriffe auf Speicherebene beim Hosting-Anbieter.

Das ist ein wichtiger Schutz. Er bezieht sich aber auf den Speicherzustand — nicht auf eine bereits laufende und korrekt erreichbare Datenbank.

Wo der Schutz endet

Wenn ein Angreifer die Anwendung kompromittiert oder Zugangsdaten eines Datenbankbenutzers erhält, kann er möglicherweise direkt Abfragen ausführen. Die Datenbank liefert dann genau das, wofür sie gebaut wurde: lesbare Ergebnisse.

Encryption at Rest verhindert in diesem Fall nicht automatisch, dass ein berechtigter Datenbankzugriff sensible Inhalte ausliest. Deshalb bleiben Least Privilege, getrennte Benutzer und eine saubere Rechtevergabe entscheidend. Genau darum ging es in Teil 4 dieser Serie: Root ist kein Anwendungsuser.

Schutzebene	schützt vor	schützt nicht vor
TLS / Transportverschlüsselung	Mithören auf dem Transportweg	kompromittierter Anwendung oder gültigem Datenbankzugang
Encryption at Rest	gestohlenen Datenträgern, Snapshots und Offline-Volumes	SELECT-Zugriff auf eine laufende Datenbank
Datenbankrechte	unnötigen oder zu weitreichenden Benutzerrechten	einem kompromittierten Benutzer mit den erlaubten Rechten
Spalten-/Anwendungsverschlüsselung	lesbaren sensiblen Werten in Dumps und bei direktem DB-Zugriff	kompromittierter Anwendung oder zugänglichen Schlüsseln
Backup-Verschlüsselung	gestohlenen oder kopierten Sicherungen	Restore mit gültigen Schlüsseln und Zugangsdaten
Schlüsselverwaltung	unkontrolliertem Zugriff auf Schlüssel	einer Anwendung, die den Schlüssel zur Laufzeit verwenden darf

Mehr Schutzschichten machen ein System nicht unangreifbar, reduzieren aber die Auswirkungen einzelner Fehler.

Das oft unterschätzte Backup-Problem

Ein Datenbank-Backup ist nicht automatisch sicher, nur weil die produktive Datenbank auf einem verschlüsselten Volume liegt. Ein Dump kann die Daten in einer neuen Datei wieder im Klartext enthalten. Diese Datei wird dann vielleicht auf einen Backup-Speicher, einen anderen Server oder einen lokalen Rechner kopiert.

Wer Zugriff auf das Backup erhält, kann unter Umständen die komplette Datenbank wiederherstellen und anschließend in Ruhe auswerten — ohne die ursprüngliche Anwendung und ohne deren Zugriffskontrollen.

Auch Backups brauchen deshalb eigenen Schutz:

• Verschlüsselung während der Übertragung und am Ziel,
• getrennte und möglichst restriktive Zugriffsrechte,
• eine angemessene Aufbewahrungsstrategie,
• Schutz der Schlüssel außerhalb des Backup-Speichers,
• regelmäßige Tests, ob sich die Sicherung tatsächlich wiederherstellen lässt.

Ein verschlüsseltes Backup ersetzt kein funktionierendes Backup. Unwiederherstellbare oder frei lesbare Sicherungen helfen im Ernstfall gleichermaßen wenig.

Spaltenverschlüsselung für sensible Daten

Wenn einzelne Werte besonders schützenswert sind, kann die Anwendung sie vor dem Speichern verschlüsseln. In der Datenbank liegt dann nicht mehr der eigentliche Wert, sondern ein Chiffrat. Ohne den passenden Schlüssel ist ein direkter Datenbankzugriff deutlich weniger wertvoll.

Das kann zum Beispiel für besonders sensible personenbezogene Daten, medizinische Angaben, Zugangsinformationen oder andere vertrauliche Inhalte sinnvoll sein. Die Entscheidung sollte aber immer vom konkreten Schutzbedarf abhängen.

Spaltenverschlüsselung bringt eigene Herausforderungen mit:

• Verschlüsselte Werte lassen sich nicht ohne Weiteres durchsuchen oder sortieren.
• Schlüssel müssen sicher verwaltet und gegebenenfalls rotiert werden.
• Ein verlorener Schlüssel kann Daten dauerhaft unbrauchbar machen.
• Verschlüsselung und Entschlüsselung können zusätzliche Last erzeugen.
• Die Anwendung braucht zur Laufzeit Zugriff auf den Schlüssel — und muss deshalb besonders sorgfältig geschützt werden.

Wichtig ist außerdem: Spaltenverschlüsselung macht Backup-Schutz nicht überflüssig. Sie reduziert zwar die Lesbarkeit der betroffenen Werte in einem gestohlenen Dump. Trotzdem können andere Spalten, Metadaten, Schlüssel oder Konfigurationsdateien sensibel sein. Gute Sicherheit bleibt mehrschichtig.

Schlüssel gehören nicht einfach neben die Datenbank

Die Verschlüsselung selbst ist nur so stark wie der Umgang mit dem Schlüssel. Liegt der Schlüssel in derselben Datenbank, im selben ungeschützten Backup oder direkt im öffentlich erreichbaren Quellcode, wird aus zusätzlicher Sicherheit schnell nur eine weitere Datei, die ein Angreifer finden muss.

Schlüssel sollten getrennt von den Daten verwaltet werden. Zugriffe müssen begrenzt, nachvollziehbar und für den jeweiligen Anwendungsfall ausreichend sein. Rotation, Wiederherstellung und der Umgang mit verlorenen Schlüsseln gehören zur technischen Planung — nicht erst zur Notfallübung.

Praktische Checkliste

Vor der Entscheidung für eine Verschlüsselung sollten diese Fragen beantwortet werden:

1. Welche Daten sind tatsächlich sensibel?
2. Wer darf diese Daten in der Anwendung sehen?
3. Welche Rechte hat der technische Datenbankbenutzer wirklich?
4. Was passiert, wenn jemand einen Datenbank-Dump erhält?
5. Sind Backups verschlüsselt und getrennt zugriffsgeschützt?
6. Wo liegen die Schlüssel und wer kann sie verwenden?
7. Wie werden Schlüssel rotiert und wiederhergestellt?
8. Wurde die Wiederherstellung eines verschlüsselten Backups getestet?
9. Welche Funktionen gehen durch Verschlüsselung verloren, z.B. Suche oder Sortierung?
10. Welche Schutzmaßnahme greift, wenn die Anwendung selbst kompromittiert ist?

Fazit: Schutz in Schichten denken

Encryption at Rest ist wichtig. Sie schützt Daten auf Datenträgern, Volumes und bestimmten Offline-Kopien. Sie schützt aber nicht automatisch vor einem gültigen Datenbankzugriff und macht ein unverschlüsseltes Backup nicht nachträglich sicher.

Für sensible Daten muss der Schutz deshalb näher an die Daten selbst rücken: durch ein sauberes Rechtekonzept, geeignete Spalten- oder Anwendungsverschlüsselung, getrennte Schlüsselverwaltung und geschützte Backups.

Keine einzelne Maßnahme macht ein System unangreifbar. Jede gut gewählte Schutzschicht macht es aber schwieriger, Daten vollständig zu stehlen oder nach einem einzelnen Fehler direkt lesbar zu machen. Genau darin liegt ihr Wert.

Weiterlesen in der SQL-Serie

• Teil 1: SQL Performance und Datenintegrität — https://eproi.eu/sql-performance-und-datenintegritaet/
• Teil 2: SQL-Transaktionen — https://eproi.eu/transaktionen-das-meistunterschaetzte-werkzeug-in-der-datenbankentwicklung/
• Teil 3: Datenbanksicherheit — https://eproi.eu/datenbanksicherheit-framework-lucken/
• Teil 4: Root ist kein Anwendungsuser — https://eproi.eu/root-ist-kein-anwendungsuser-datenbankrechte-richtig-trennen/

Weitere passende Praxislektüre

WordPress-Hacking: Befallene Installation richtig bereinigen — https://eproi.eu/ein-echter-wordpress-rettungsfall-aus-der-praxis/