Was stehlen Hacker tatsächlich aus der Datenbank?
Medizinische Daten sind nicht „nur eine weitere Tabelle in der Datenbank“. Zwei Muster, die die Auswirkungen eines Lecks begrenzen
Innerhalb weniger Wochen erlebte der polnische Gesundheitssektor drei schwerwiegende Vorfälle. Zuerst auf einer der führenden Plattformen zur Führung elektronischer Gesundheitsdokumentationen, von der laut UODO Daten von ca. 19 Millionen Polen (Datenbank ca. 2,5 TB) durchgesickert sind. Im Leck könnten unter anderem Name, Adresse, PESEL, Kontaktdaten, Gesundheitsdaten sowie Informationen über Medikamente und Rezepte enthalten sein. Bis Mitte September gingen bei der UODO über 2.000 Meldungen von Einrichtungen ein, die das System nutzen.
Dann ein weiterer Angriff auf ein ähnliches System – potenziell bis zu 5 Millionen Personen. Und am 24. September ein Angriff auf ein medizinisches Zentrum: Die Angreifer erhielten Zugang zu Teilen der Infrastruktur und zu Teilen der Patientendaten, laut Unternehmen etwa 3% der gesamten Datenbank. Die Vorfälle wurden natürlich an CBZC, CERT Polska und UODO gemeldet, und es wurde ein individueller Kontakt mit den Betroffenen angekündigt.
Wir kennen die technischen Details dieser Angriffe nicht und bewerten sie nicht. Eine Lektion ist jedoch universell: Gehen Sie davon aus, dass irgendwann jemand Zugriff auf Ihre Datenbank erhalten könnte. Die architektonische Frage lautet also nicht nur „wie verhindere ich den Zugang des Angreifers“, sondern auch „was sieht er, wenn er bereits eingedrungen ist“. Nachfolgend zwei Muster, die wir in medizinischen Projekten anwenden: Blind Index und Trennung medizinischer Daten von anderen.
Blind Index: Suche nach dem Patienten, ohne ihn offen zu speichern
Klassisches Problem: Wir möchten die Patienten-ID verschlüsseln oder pseudonymisieren, müssen aber dennoch schnell auf die Frage „zeige alle Ergebnisse dieses Patienten“ antworten. Verschlüsselung mit zufälligem IV (z.B. AES-GCM) verhindert die Suche mit der Anweisung WHERE, da derselbe Wert jedes Mal einen anderen Chiffretext ergibt.
Die Lösung ist der Blind Index – ein deterministischer Hash, der mit einem geheimen Schlüssel berechnet wird:blindIndex(value: string): string {
return createHmac('sha256', this.blindIndexKey)
.update(value.trim().toLowerCase())
.digest('hex');
}
In medizinischen Tabellen speichern wir keine offene userId, sondern eine Spalte patientHash mit Index. Der Ablauf im Repository sieht so aus:
Worauf man aus technischer Sicht achten sollte
- HMAC, nicht reines SHA-256. Der PESEL- oder ID-Raum ist klein – ein einfacher Hash kann in Minuten mit einem Wörterbuch zurückgerechnet werden. Ohne HMAC-Schlüssel ist der Hash nutzlos.
- Getrennter Schlüssel für den Blind Index und ein anderer für die Verschlüsselung. Schlüssel in KMS / Tresor, niemals in derselben Datenbank.
- Normalisierung des Eingangs vor dem Hashing (Groß-/Kleinschreibung, Leerzeichen), andernfalls beginnt die Suche, „Datensätze zu verlieren“.
- Einschränkungen: nur Gleichheit (ohne LIKE und Bereiche), sichtbare Häufigkeiten, und Schlüsselrotation bedeutet Neuberechnung der Indizes – dies muss von Anfang an geplant werden.
- Ergebnis: Ein Dump der medizinischen Tabelle ist eine Sammlung von Untersuchungsergebnissen und Hashes, die ohne Schlüssel aus einer anderen Schicht keiner bestimmten Person zugeordnet werden können.
Trennung medizinischer Daten von anderen
Das zweite Muster ist das Prinzip, dass medizinische Daten nicht in einem „Sack“ mit dem Rest des Systems leben. Wir trennen drei Schichten:
Datenbanken
- Domänendaten sind vom Zugriff auf medizinische Daten getrennt – das ist eine separate Datenbank.
- Das Log wird außerhalb der Transaktion der Operation gespeichert. Wenn die Operation zurückgesetzt wird, bleibt die Spur des Zugriffsversuchs dennoch bestehen – und genau diese Spuren sind bei der Analyse eines Vorfalls erforderlich.
- Separate Anmeldeinformationen und separates SSL für jede Datenbank. Die Übernahme eines Domain-Anwendungskontos ermöglicht keinen Lesezugriff oder das „Löschen“ des Audit-Logs (gute Praxis: Das Anwendungskonto hat nur INSERT-Rechte auf das Log).
Dateispeicherung
Verzeichnis / öffentlicher Raum– nur Inhalte, die ohnehin über URL bereitgestellt werden (z.B. Grafiken, Marketingmaterialien).Verzeichnis / privater Raum– ausschließlich Chiffretext, ohne öffentliche URL. Der Zugriff ist nur über eine vorbereitete Methode möglich, die Berechtigungen überprüft, die Datei entschlüsselt und den Zugriff im Log speichert.
Zusammenfassung
Keines dieser Muster wird den Angreifer am Eingang aufhalten – dafür gibt es Updates, Netzwerksegmentierung, MFA und Monitoring. Auch die Schulung Ihrer Mitarbeiter und Sicherheitstrainings sind äußerst wichtig. Viele Angriffe gelingen nicht durch den Einsatz ausgeklügelter Hacker-Tools, sondern durch einfache Tricks, Phishing oder die Verwendung von Passwörtern aus anderen Diensten.
Die Anwendung technischer Schutzmaßnahmen ändert jedoch, was der Angreifer mitnimmt: Anstelle einer fertigen Akte „PESEL + Diagnose“ erhält er Hashes ohne Schlüssel, Chiffretexte ohne URL und ein Log, das er nicht löschen konnte. Bei medizinischen Daten ist das der Unterschied zwischen einem Vorfall und einer Katastrophe für Millionen von Patienten.
