Verschlüsselte Klientenakte: was Krypto-Shredding technisch bedeutet
„Verschlüsselt" steht im Marketing vieler Softwareprodukte, oft ohne dass klar wird, was genau damit gemeint ist. Es gibt einen wichtigen Unterschied: Verschlüsselung der Verbindung zum Server (Transportverschlüsselung) ist heute Standard und schützt vor Mitlesen unterwegs. Feldverschlüsselung der gespeicherten Daten selbst ist etwas anderes und schützt auch dann, wenn jemand direkten Zugriff auf die Datenbank bekommt.
Wogegen Feldverschlüsselung schützt
- Datenbank-Dumps, die versehentlich oder böswillig aus dem System kopiert werden
- Backup-Leaks, etwa wenn eine Sicherungskopie an falscher Stelle landet
- Physischen Zugriff auf den Datenträger, etwa bei Diebstahl der Hardware
Wogegen sie nicht schützt: Code, der mit demselben Schlüssel auf derselben Instanz läuft. Das ist ein Grund, warum eine dedizierte Instanz je Einrichtung, ohne fremde Zusatzsoftware, ein eigenständiges Sicherheitsmerkmal ist, nicht nur ein Betriebsdetail.
Was Krypto-Shredding ist
Klassisches Löschen entfernt einen Datensatz aus der Tabelle. Krypto-Shredding geht einen anderen Weg: Jede Akte hat ihren eigenen Schlüssel. Wird die Akte vernichtet, wird nicht in erster Linie der Inhalt gelöscht, sondern der Schlüssel selbst unwiederbringlich entfernt. Ohne Schlüssel ist der verschlüsselte Inhalt danach technisch wertlos, auch wenn die Ciphertext-Reste noch physisch irgendwo liegen sollten, etwa in einem älteren Backup.
Warum das bei Aufbewahrungsfristen relevant ist
Nach Ablauf der Aufbewahrungsfrist muss eine Akte tatsächlich unlesbar werden, nicht nur „als gelöscht markiert" sein. Krypto-Shredding macht diesen Zustand technisch belastbar nachweisbar: der Schlüssel existiert nachweislich nicht mehr.
Was zu fragen bleibt
- Sind wirklich die sensiblen Felder verschlüsselt, oder nur ein Teil davon?
- Hat jede Akte einen eigenen Schlüssel, oder wird ein gemeinsamer Schlüssel für alle Akten verwendet?
- Was passiert konkret mit Backups, wenn eine Akte vernichtet wird?
Wie JuBase das löst
In JuBase liegen sensible Felder nicht im Klartext. Jede Akte hat einen eigenen Schlüssel; die Vernichtung einer Akte vernichtet diesen Schlüssel unwiederbringlich. Betrieben wird das auf einer eigenen Instanz je Einrichtung, keine gemeinsame Datenbank mit anderen Trägern.