Einblicke
Wo persönliche Daten liegen
Am Anfang stand ein unangenehmer Moment im Alltag: Eine fehlgeschlagene Anmeldung untersuchen und dabei persönliche Informationen sehen, die man dafür gar nicht braucht.
Wenn die Fehlersuche persönliche Daten sichtbar macht
Wer eine Identitätsplattform betreibt, kennt diese Meldung: „Ein Nutzer kann sich nicht anmelden.“ Zur Fehlersuche öffnen Sie die Kundenumgebung und suchen das Konto.
Sie brauchen nur bestimmte Angaben: Ist das Konto gesperrt? Wann und an welcher Stelle ist der letzte Versuch gescheitert? Welcher Anmeldeweg wurde genutzt? Ist der Passkey noch gültig registriert?
Dafür müssen Sie nicht wissen, wer die Person ist. Trotzdem sehen Sie beim Öffnen des Kontos Namen, E-Mail-Adresse, Telefonnummer und verknüpfte Konten auf demselben Bildschirm. Sie suchten einen technischen Zustand. Sie bekamen persönliche Informationen dazu.
„Bitte nicht hinsehen“ schützt nicht,
solange die Daten auf dem Bildschirm stehen.
Dabei hat niemand einen Fehler gemacht. Der Kunde hat die Untersuchung angefordert, Sie haben das Verfahren eingehalten und die Aufgabe erledigt. Gesehen haben Sie die Daten trotzdem. Der Aufbau des Systems hat sie Ihnen gezeigt.
Mit Richtlinien und Schulungen allein hängt der Schutz vom Gedächtnis und der Aufmerksamkeit der zuständigen Person ab. Auf Dauer kann daraus ein Vorfall werden. Die Trennung personenbezogener Daten in eine eigene Datenbank begann mit dem Versuch, dieses Problem im Aufbau des Systems zu lösen.
Zwei Datenbanken von Anfang an
Direkt identifizierende Daten liegen in einer physisch getrennten Datenbank. Die Trennung wurde nicht nachträglich aufgesetzt, sondern beginnt bereits in der Datenzugriffsschicht.
Mit dieser Trennung lässt sich das Ausgangsproblem lösen. Sperrstatus, fehlgeschlagene Anmeldungen und Geräteinformationen liegen links. Der für eine Untersuchung nötige Zugriff kann freigegeben werden, ohne die rechte Seite zu öffnen. Niemand muss daran denken, wegzusehen.
Dieselbe Struktur beantwortet nebenbei Audit-Fragen. Wo Namen und E-Mail-Adressen liegen und welche Daten eine Löschung umfasst, lässt sich klar zeigen. Die Lösung des Betriebsproblems macht auch die Architektur leichter erklärbar.
Auch außerhalb der PII DB gibt es personenbezogene Daten
Das muss ausdrücklich gesagt werden: Diese Trennung ist keine rechtliche Grenze zwischen personenbezogenen und nicht personenbezogenen Daten.
In der Core DB liegen IP-Adressen, Geräteinformationen, Sitzungsverläufe, Authentifizierungsereignisse, Metadaten zu Anmeldemitteln und stabile interne Nutzer-IDs. Auch das können personenbezogene Daten sein. Allein identifizieren sie möglicherweise niemanden, zusammen mit anderen Informationen aber schon.
Authrim trennt direkt identifizierende Daten von Identitätsdaten für den Betrieb. Eine Untersuchung soll mit der zweiten Gruppe auskommen, ohne auf die erste zuzugreifen. Auch die zweite Gruppe muss geschützt werden.
Die Aussage „Personenbezogene Daten gibt es nur in der PII DB“ wäre falsch. Treffend ist: Namen, E-Mail-Adressen und andere direkt identifizierende Daten sind in der PII DB isoliert. Rechte zur Fehlersuche können vergeben werden, ohne diesen Speicher zugänglich zu machen.
Mit dem Löschen ist es nicht getan
Ein Konto auf Wunsch zu löschen ist einfach. Schwieriger sind die beiden Anforderungen, die danach kommen können.
Die erste ist der Nachweis der Löschung: wann, durch wen und warum. Die zweite ist das Verhindern einer erneuten Registrierung für einen bestimmten Zeitraum, wie es Geschäftsregeln häufig vorsehen.
Beides verlangt, eine Person wiederzuerkennen, deren Daten gelöscht wurden. Direkt identifizierende Angaben dafür aufzubewahren, widerspricht jedoch dem Zweck der Löschung.
Das Prinzip lautet: Nur den für die Wiedererkennung erforderlichen Prüfwert aufbewahren und nach Ablauf der Frist löschen. Dazu werden Zeitpunkt, verantwortliche Person und Grund der Löschung erfasst.
Wovon „nicht rekonstruierbar“ abhängt
Ein technisches Detail ist wichtig: E-Mail-Adressen haben wenig Entropie. Bei einem einfachen Hash kann ein Wörterbuchangriff die Adresse ermitteln. „Nicht rekonstruierbar“ gilt daher nicht ohne Bedingungen.
Authrim verwendet einen HMAC-SHA256-Blindindex mit einem geheimen Schlüssel. Eine Schlüsselgeneration wird mitgespeichert, damit Schlüssel gewechselt werden können. Ohne den Schlüssel lassen sich mögliche Adressen nicht durch Berechnen ihrer Prüfwerte abgleichen.
Die Trennung des Schlüssels ist Voraussetzung für diesen Schutz. Liegt er neben den Prüfwerten, geht diese Eigenschaft verloren. Diese Bedingung gehört auch in jede öffentliche Beschreibung.
Nur die Daten öffnen, die die Untersuchung braucht
Zurück zur fehlgeschlagenen Anmeldung: Gesucht wird die Stelle, an der die Authentifizierung abbrach. Ein Name oder eine Telefonnummer muss dafür normalerweise nicht geöffnet werden.
Authrim trennt direkt identifizierende Informationen, damit Rechte zur Fehlersuche ohne Zugriff auf diesen Speicher vergeben werden können. Werden tatsächlich personenbezogene Daten benötigt, übernimmt jemand mit den passenden zusätzlichen Berechtigungen.
Verschlüsselung und Zugriffskontrolle schützen die Daten, Audit-Logs zeichnen ihre Nutzung auf. Darüber hinaus sollte die zuständige Person gewöhnliche Untersuchungen abschließen können, ohne unnötige persönliche Informationen zu öffnen. Getrennter Speicher macht das zum Ausgangspunkt des täglichen Betriebs.
Umsetzung: Speichertrennung und Zugriffsgrenze sind implementiert.
Validierung: Durch automatisierte Tests im Repository abgedeckt.
Betriebsreife: Die Absicherung läuft weiter. Authrim ist noch vor Version 1.0.
Diese Architektur erleichtert Löschprozesse. Sie allein garantiert keine rechtliche Konformität; dafür sind auch die Verfahren und Verträge der Organisation entscheidend.