Ein Team sagt: „Die Datenbank ist im Ruhezustand verschlüsselt, also sind wir sicher." Was ist als Architekt die Lücke?
Kurzantwort
Verschlüsselung im Ruhezustand wehrt genau eine Bedrohung ab — den physischen oder Datenträgerdiebstahl — und hilft nichts gegen eine kompromittierte Anwendung, gestohlene Zugangsdaten oder abgehörten Datenverkehr, da die Datenbank für jede autorisierte Abfrage transparent entschlüsselt. Ein solides Design verlangt zusätzlich TLS im Transit, starke Authentifizierung und Autorisierung sowie ein ordentliches Schlüsselmanagement mit Funktionstrennung. Eine zweite Ruhezustand-Verschlüsselung erhöht nur die Kosten, ohne das Bedrohungsmodell zu ändern, und nur die Backups zu verschlüsseln lässt die Produktivdaten und ihre Zugriffswege offen.
Wenn ein Team „im Ruhezustand verschlüsselt" mit „sicher" gleichsetzt, verwechselt es eine einzelne Maßnahme mit einer vollständigen Sicherheitslage. Die Aufgabe des Architekten ist es, die Maßnahme den Bedrohungen zuzuordnen, die sie tatsächlich mindert, und offenzulegen, was sie offen lässt.
Was Verschlüsselung im Ruhezustand tatsächlich leistet
Verschlüsselung im Ruhezustand — auf Datenträger-, Dateisystemebene oder als Transparent Data Encryption (TDE) — schützt Daten auf gestohlenen oder ausgemusterten Medien. Trägt jemand eine Festplatte oder ein Backup-Band davon, sind die Bytes unlesbar. Das ist ein realer, aber enger Nutzen.
Die entscheidende Erkenntnis: Die Datenbank entschlüsselt Daten für jede autorisierte Verbindung transparent. Eine SQL-Abfrage der Anwendung sieht Klartext. Gegen die Bedrohungen, die echte Sicherheitsvorfälle dominieren, hilft Verschlüsselung im Ruhezustand daher nichts.
Die verbleibenden Lücken
- Kompromittierung auf Anwendungsebene. Eine SQL-Injection, eine verwundbare API oder ein kompromittiertes Dienstkonto fragt die Datenbank ab und erhält Klartext. Die Verschlüsselung greift nie.
- Gestohlene Zugangsdaten. Per Phishing erbeutete oder geleakte Datenbank-Zugangsdaten lassen einen Angreifer authentifizieren und alles im Klartext lesen.
- Daten im Transit. Ohne TLS kann der Verkehr zwischen Anwendung und Datenbank auf der Leitung abgehört oder manipuliert werden.
- Schlüsselverwaltung. Werden Schlüssel schlecht gespeichert oder zusammen mit den Daten abgelegt, ist die Verschlüsselung reine Kulisse.
Warum die falschen Antworten falsch sind
„Nichts — Verschlüsselung im Ruhezustand reicht aus" ist die Falle für schwächere Kandidaten: Sie akzeptieren eine einzelne Maßnahme als vollständige Antwort. „Eine zweite Verschlüsselungsschicht im Ruhezustand hinzufügen" verdoppelt Kosten und Komplexität, während sie genau dieselbe Bedrohung abwehrt — Bewegung ohne Fortschritt. „Nur die Backups verschlüsseln" ist noch enger und lässt die Produktivdaten und jeden Zugriffsweg ungeschützt.
Worauf der Interviewer achtet
Er will Bedrohungsmodell-Denken sehen: Welche Bedrohung adressiert jede Maßnahme, und wo liegen die Restrisiken? Ein guter Architekt antwortet mit Defense in Depth — TLS im Transit, Zugriffskontrolle nach dem Least-Privilege-Prinzip, parametrisierte Abfragen gegen Injection und Schlüssel, die in einem KMS/HSM getrennt von den Daten verwaltet werden — statt ein einziges Häkchen als Ziellinie zu behandeln.
Wahrscheinliche Anschlussfragen
- Wenn die Anwendung kompromittiert ist, hilft die Verschlüsselung im Ruhezustand überhaupt? Warum oder warum nicht?
- Wo würdest du die Schlüssel dieser Datenbank speichern und rotieren, und wer sollte Zugriff haben?
- Wie würdest du dieselben Daten im Transit zwischen Anwendung und Datenbank schützen?