Nun ist die DGSVO/GDPR einige Monate in Kraft – und der große Knall ist erstmal ausgeblieben. Zwar gibt es immer noch viele Seiten, die innerhalb der EU nicht erreichbar sind, aber außer den Cookie-Hinweisen hat sich für den Nutzer nicht viel geändert, zumindest dem äußeren Eindruck nach. Im ersten Post zu GDPR bin ich auf den allgemeinen Umfang des Gesetztes eingegangen und möchte in diesem Beitrag mehr auf die Technik eingehen: Denn da hat sich bei vielen Anbietern tatsächlich einiges getan:
Beim Verarbeiten von personenbezogenen Daten kristallisieren sich im Moment mehrere (durchaus wünschenswerte) Entwicklungen heraus:
- Wenige Daten verteilt sammeln: sensible Daten werden an einer Stelle vorgehalten, um die Löschung/Anonymisierung zu vereinfachen.
- Mit weiteren Parteien Auftragsdatenvereinbarungen (AAV) eingehen, um sich die Verantwortung und Pflichten klar an den Partner zu kommunizieren.
- Verschlüsselte Übertragung per HTTPS: Wer glaubt, ohne Verschlüsselung am Markt agieren zu können, für den kann es bei der Fülle von Anforderungen und verschärften Strafandrohungen schnell teuer werden. Denn die haben es in sich: Es sind saftige Bußgelder fällig, die sogar die Existenz eines Unternehmens gefährden können. Mit Lösungen wie Let’s Encrypt kann man sogar kostenlos und schnell die Verschlüsselung der eigenen Dienste sicherstellen.
- Verschlüsselung der Daten mit Public-/Private-Key-Verfahren: Diese Form von „Privacy by Design“ ist besonders interessant. Denn laut DSGVO gelten verschlüsselte Daten nicht als verloren, wenn der Schlüssel nicht mit verlorengeht. Diesen Fakt kann man sich dann auch in Verbindung mit Artikel 17 – dem Recht zu Vergessen – zunutze machen:
Sensible Daten werden dabei mit dem Public Key des Nutzers verschlüsselt und können dann problemlos in der Datenbank abgelegt werden:
Das Schöne an der Variante ist, dass die Backup-Prozesse so bleiben können wie bisher. Setzt ein Nutzer sein Recht auf Löschen um, wird sein Private Key entfernt und man kommt nicht mehr an die Daten heran. Dabei muss man beim Anwendungsdesign darauf achten, dass bestimmte Datenfelder eben jetzt auch leer sein können, wenn der Nutzer entfernt wurde.
Technisch kann man das als allgemeine Schnittstelle zur Verfügung stellen:
Eingebettet würde man diese Schnittstelle im Identity- und Access-Management unterbringen:
- Eine Anwendung möchte sensible Daten zu einem Nutzer sicher ablegen. Diese Daten werden an die API gesendet
- Das IAM liest die Schlüsselinformationen aus
- und verschlüsselt die Daten damit.
- Der chiffrierte Datensatz wird der Anwendung übergeben, damit diese den Speichervorgang abschließen kann.
Dieses Pattern, auch als „Crypto Erase“ bekannt, lässt sich mittlerweile bei vielen Anwendungen entdecken, z.B. bei Axon oder in Verbindung mit einer Blockchain. Immer mehr Anwendungen und Frameworks werden dieses Pattern nutzen, da es auch bei verteilten Anwendungen funktioniert und z.B. auch mit JPA Entity Listener gut umsetzbar ist.
Generell zeigt sich damit, dass sich trotz hochverteilten Anwendungen auch der Datenschutz umsetzen lässt und der Komfort dabei nicht auf der Strecke bleiben muss.
