Wie wir bei Youthpass 600.000 Zertifikate gelöscht haben

Seit 2007 entwickeln und betreiben wir im Auftrag von JUGEND für Europa für die EU-Kommission das Youthpass-System, eine Website, über die europaweit Zertifikate für Teilnehmer an Jugendprojekten erstellt werden können. Mit großem Erfolg: Bis heute sind fast 1,5 Millionen Youthpass-Zertifikate ausgegeben worden. Die Daten dieser Zertifikate werden in einer Datenbank gespeichert, um Zertifikate zum Beispiel bei Bedarf korrigieren und neu generieren zu können. Auch die generierten PDF-Dateien werden zum Zwecke der Prüfbarkeit gespeichert.

Was dem System bisher fehlte, war ein Verfahren, über das die Daten wieder aus der Datenbank gelöscht werden. Schließlich gibt es ein Recht auf Vergessenwerden und dem widerspricht es, wenn Daten von Projektteilnehmern ohne zeitliche Begrenzung gespeichert bleiben. Vor diesem Hintergrund trat unser Kunde mit der Bitte an uns heran, zukünftig Daten aus Projekten, die vor über 6 Jahren beendet wurden, automatisch aus dem System zu löschen. Das betraf direkt zu Beginn schon fast 600.000 Zertifikate, bei denen diese Frist bereits erreicht war. Schnell wurde klar, dass die Löschung an sich einfach ist, aber eine Reihe von umfangreichen Vorarbeiten erforderte.

Eine grundlegende Entscheidung: "Papierkorb" oder "Radiergummi"?

Die Anforderung unseres Kunden war, dass personenbezogene Daten aus der Datenbank gelöscht werden sollten. Dies umfasste z. B. die Namen, Geburtsdaten und Identifikationsnummern der Projektteilnehmer, aber auch die Informationen zu Dialogpartnern und Referenzgebern. Andere Daten sollten hingegen im System bleiben. Gemeinsam haben wir überlegt, wie wir hierbei am besten vorgehen können. Wir haben zwei grundsätzlich unterschiedliche Möglichkeiten gesehen, die wir "Radiergummi" und "Papierkorb" getauft haben.

Der "Radiergummi"-Ansatz bestand darin, in der Datenbank gezielt die Daten "auszuradieren", die personenbezogen waren, und alle anderen Daten unverändert zu erhalten. Vorteile, die wir in diesem Ansatz gesehen haben, waren:

• Es bleiben automatisch alle Daten im System erhalten, die nicht personenbezogen sind
• Es entsteht dementsprechend kein Entwicklungsaufwand, um nicht-personenbezogene Daten zu erhalten, die für andere Zwecke benötigt wurden (z. B. Statistiken, Verifizierung, Forschung)

Dem gegenüber standen auch einige Nachteile:

• Einige der personenbezogenen Daten sind in Pflichtfeldern gespeichert, z. B. der Name des Zertifikatsempfängers. Pflichtfelder können aber technisch nicht einfach auf "leer" gesetzt werden
• Benutzer des Youthpass-Systems finden in alten Projekten teilgelöschte Teilnehmerdaten vor und könnten ggf. auch Zertifikate für anonymisierte Personen generieren. Da das natürlich nicht sinnvoll ist und eventuell sogar zu Fehlern führen würde, muss die Anwendung entsprechend angepasst werden und den Zugriff auf die alten Daten sperren
• Alle Datensätze bleiben weiter dauerhaft im Produktivsystem, mit entsprechenden Anforderungen an die Performanz der Datenbank und mit dem Nachteil, dass alle Datenbankbereiche, die seit 2007 genutzt wurden, dauerhaft in Betrieb bleiben müssen.

Der "Papierkorb"-Ansatz sah vor, Datensätze, deren personenbezogene Daten entfernt werden sollen, komplett aus dem System zu löschen. Daten, die für andere Zwecke gebraucht werden, müssten vor der Löschung anonymisiert in dafür spezialisierte "Data stores" übertragen werden. Hierfür haben wir folgende Vorteile gesehen:

• Die Anwendung muss nicht mit teilgelöschten Daten umgehen; Projekte, die gelöscht wurden, sind einfach nicht mehr vorhanden
• Die Menge der im Produktivsystem vorhandenen Daten wächst langsamer
• Die Datenbankstruktur und der Programmcode für die Umsetzung früherer Versionen der Youthpass-Zertifikate (für alte Generationen der Förderprogramme) können gelöscht werden, sobald alle Projekte aus dieser Förderperiode gelöscht sind
• Die Daten, die für andere Zwecke aufgehoben werden, können in dafür optimierter Form gespeichert werden.

Folgende Nachteile hatten wir auf dem Schirm:

• Entwicklungsaufwand für die spezialisierten Data stores
• Die Struktur der aufgehobenen Daten könnte sich im Zeitverlauf ändern und wäre dann komplizierter zu analysieren (eine Nebenwirkung der größeren Freiheit bei der Weiterentwicklung der Datenstrukturen)

Nach Abwägung dieser Argumente haben wir uns gemeinsam mit JUGEND für Europa für den "Papierkorb"-Ansatz entschieden. Damit konnte die eigentliche Arbeit am Projekt beginnen.

Welche Daten sollen aufgehoben werden?

Da wir nun alle alten Datensätze komplett löschen wollten, musste vorher sicher gestellt sein, dass wir Daten, die wir weiter benötigen, vorher anderweitig sichern. Folgende Zwecke haben wir identifiziert:

• Statistiken: Das Youthpass-System bietet berechtigten Benutzern die Möglichkeit, statistische Daten über die generierten Zertifikate einzusehen. Und jeder Besucher der Website kann direkt auf der Startseite die Gesamtzahl der generierten Zertifikate sehen. Diese Informationen wurden bisher mehr oder weniger direkt aus der Produktivdatenbank ermittelt. Nach der Löschung wäre die ausgewiesene Gesamtzahl der Zertifikate damit um 600.000 gesunken.
• Verifizierung von Zertifikaten: Jedes Zertifikat trägt einen Identifikationscode, der online über die Website überprüft werden kann. Nach der Löschung der Daten wären die betroffenen Zertifikate nicht mehr als gültig erkannt worden.
• Forschungsdaten: Für zukünftige Forschung sollten insbesondere die auf den Zertifikaten vorhandenen Beschreibungen von Lernerfahrungen und erworbenen Kompetenzen möglichst erhalten bleiben, ebenso auch die anderen Angaben auf den Zertifikaten, die keiner Löschpflicht unterliegen.

Vollständige Statistiken trotz Löschung

Aus Performancegründen gab es in Youthpass bereits spezialisierte Datenbanktabellen mit den Statistikdaten. Diese Statistikdaten wurden allerdings bisher jede Nacht aus den Produktivdaten neu aggregiert – ein Vorgehen, das nach der Löschung von Produktivdaten natürlich nicht mehr möglich gewesen wäre, ohne die Daten der gelöschten Projekte auch in den Statistiken zu verlieren. Wir haben daher entschieden, die Statistikdaten direkt beim Generieren eines Zertifikats in die entsprechenden Datenbanktabellen zu schreiben. Beim Aktualisieren eines Zertifikats werden diese Statistikdaten ebenfalls aktualisiert, und ab der Löschung des Projekts bleiben sie eingefroren erhalten.

Was im Laufe des Projekts klar wurde: Nicht für alle Statistikabfragen wurden ausschließlich die spezialisierten Datenbanktabellen genutzt, sondern manche Abfragen nutzten auch Produktivdaten. Das betrifft sowohl das Statistik-Tool für die Youthpass-Benutzer, aber auch Ad-Hoc-Statistiken, die wir ab und zu im Auftrag unseres Kunden zusammengestellt haben. Wir mussten also analysieren, welche Daten wir für die unterschiedlichen Statistiken aufheben mussten. Anschließend haben wir die Statistiktabellen um diese Datenfelder erweitert.

Eine kleine Zusatzherausforderung war hier noch der Übergang von der alten in die neue Welt: Um vollständige Statistikdaten zu haben, haben wir zunächst das Skript für die nächtliche Aggregation der Daten so erweitert, dass die neuen Datenfelder mit befüllt wurden (auch wenn dieses Skript ja nicht mehr lange leben sollte). Anschließend konnten wir das Statistik-Tool so umstellen, dass die Abfragen ausschließlich über die Statistiktabellen liefen und keine Produktivdaten mehr nutzten. Im letzten Schritt haben wir dann die neue Lösung aktiviert, die die Statistikdaten direkt beim Generieren der Zertifikate schreibt, und das nächtliche Aggregationsskript in Rente geschickt.

Wie verifiziert man Namen, die man gelöscht hat?

Wie oben bereits erwähnt, bietet Youthpass eine Verifizierungsseite, über die jedes Zertifikat anhand seiner ID oder eines aufgedruckten QR-Codes auf Gültigkeit überprüft werden kann. Diese Überprüfung erfolgte, indem die ID in der Produktivdatenbank nachgeschlagen wurde. Daher hätte sie nach einer Datenlöschung für die gelöschten Zertifikate nicht mehr funktioniert. Mindestens die Zertifikats-ID musste also dauerhaft aufgehoben werden.

Die Verifizierungsfunktion prüft aber nicht nur, ob die ID gültig ist oder nicht, sondern sie zeigt auch an, in welcher Art von Projekt das Zertifikat ausgegeben wurde, welcher Zeitraum darauf angegeben ist und welchen Titel das Projekt hatte. Und, last but not least: Für welchen Teilnehmer das Zertifikat erstellt wurde. Diese Information ist wichtig, weil in einigen europäischen Ländern die Youthpass-Zertifikate für die Bewerbungen an Hochschulen genutzt werden können und entsprechend sicher sein müssen.

Grundsätzlich wählten wir für die Verifizierungsfunktion den gleichen Ansatz wie für die Statistiken: Die Daten, die wir für die Verifizierung benötigen, speichern wir in einer speziellen Datenbanktabelle.

Doch der Name der Teilnehmer stellte uns vor die besondere Herausforderung: Wie können wir Namen verifizieren, die wir gelöscht haben?

Wir entschieden uns dafür, die Namen unumkehrbar verschlüsselt in der Verifizierungsdatenbank zu speichern. Der gleiche Ansatz wird typischerweise bei Passwörtern verwendet: Websites, auf denen man sich einloggen kann, speichern aus Sicherheitsgründen nicht das Passwort selbst in der Datenbank, sondern einen daraus abgeleiteten Hash. Die Website kann die Korrektheit des Passworts prüfen, indem sie den Hash des beim Login eingegebenen Passworts mit dem in der Datenbank gespeicherten Hash des vom Benutzer gewählten Passworts vergleicht.

Mit diesem Ansatz können wir nicht mehr zu einer gegebenen Zertifikats-ID den Namen anzeigen (denn die Verschlüsselung ist ja nicht umkehrbar), aber wir können für einen vom Nutzer der Verifizierungsfunktion angegeben Namen prüfen, ob dieser tatsächlich auf dem Zertifikat stand. So weit so gut, doch eine zusätzliche Herausforderung kam noch auf uns zu: Was tun wir, wenn der Name nicht exakt so eingegeben wird, wie er in der Datenbank steht? Können wir das retten?

• Youthpass-Benutzer müssen im Formular Vorname und Nachname des Teilnehmers eingeben (heute würden wir vermutlich nur noch ein Namensfeld nutzen, aber das ist ein anderes Thema). Auf dem Zertifikat steht aber nicht, was der Vor- und was der Nachname ist – und auf ungarischen Zertifikaten wird die Reihenfolge sogar umgekehrt. Wir speichern daher sowohl den Hash für "Vorname Nachname" als auch den für "Nachname Vorname"
• Auf einigen Zertifikatsversionen wird der Name in VERSALIEN ausgegeben. In der Datenbank steht er aber in gemischter Schreibweise. Wir wollten, dass sowohl "MAX" als auch "Max" (und auch "max") als korrekt anerkannt werden. Zugleich wollten wir auch sichergehen, dass Akzente nicht zu Problemen führen (z. B. weil sie sich auf der Tastatur des Nutzers der Verifizierungsfunktion nicht eingeben lassen). Um diese Probleme zu lösen, speichern wir eine normalisierte Version des Namens (Kleinbuchstaben ohne Sonderzeichen) in der Verifizierungsdatenbank. Dafür nutzen wir die NFC-Normalisierung bzw., um ganz genau zu sein, "Any-Latin; Latin-ASCII; Lower".

Damit die Benutzer der Verifizierungsfunktion zukünftig möglichst wenig Aufwand haben, haben wir noch eine Vereinfachung vorgenommen: Der QR-Code, der auf den neueren Zertifikaten erscheint, enthält jetzt auch den Namen des Teilnehmers. Wenn man den QR-Code nutzt, um ein Zertifikat zu verifizieren, wird also bei neuen Zertifikaten nicht nur die ID, sondern auch der Name an den Youthpass-Server gesendet. Dieser kann dann den Namen mit dem gespeicherten Hash vergleichen und direkt anzeigen, dass dieser Name echt ist. Natürlich geht das nicht für Zertifikate, die bereits vor der Umstellung gedruckt wurden (der QR-Code kann sich ja nicht im Nachhinein ändern), weshalb die oben genannten Normalisierungen trotzdem wichtig sind.

Zugleich haben wir eine weitere Neuerung eingeführt: Wenn sich relevante Daten eines Zertifikats später einmal ändern, wird nun eine neue ID für dieses Zertifikat vergeben. Unter der alten ID können nach wie vor die alten Daten verifiziert werden, unter der neuen ID dann die neuen Daten.

Anonymisiertes Datenarchiv für Forschungszwecke

Für die Begleitforschung zu Youthpass und die Weiterentwicklung des Systems war es unserem Kunden wichtig, möglichst viele Daten aus den Youthpass-Zertifikaten anonymisiert zu speichern.

Wir haben verschiedene Lösungsmöglichkeiten evaluiert und uns schließlich dazu entschieden, die Daten in einem weit verbreiteten Format semistrukturiert zu speichern: JSON. Da derzeit noch keine konkreten Anforderungen für die Forschung bekannt sind, haben wir uns für die einfachstmögliche Form der Speicherung entschieden: In einer Datenbanktabelle. Es ist bei Bedarf aber auch jederzeit möglich (und vermutlich sinnvoll), die Daten in ein spezielles Datenanalysesystem zu übertragen.

Grundsätzlich ähnelt auch die Befüllung des Datenarchivs von der Einbindung her dem bereits beschriebenen Ansatz: Bei der Generierung von Zertifikaten werden die Forschungsdaten ins Archiv übertragen beziehungsweise aktualisiert.

Für den Aufbau des Datenarchivs haben wir als erstes für alle Datenklassen, aus denen sich ein Youthpass-Zertifikat zusammensetzt, Normalisierer konfiguriert, die diese Daten in JSON konvertieren. Teilweise sind das Normalisierer, die direkt aus dem Symfony-Framework kommen, teilweise mussten wir projektspezifische Normalisierer ergänzen. Auf diese Weise entsteht dann mit Hilfe der Symfony Serializer Component für jedes generierte Zertifikat ein JSON-Dokument mit allen seinen Daten in auswertbarer Form.

Eine Frage, über die wir uns länger den Kopf zerbrochen haben: Wie können wir sicherstellen, dass wir bei zukünftigen Veränderungen des Datenmodells nicht vergessen können, die Archivierungsregeln anzupassen? Wenn zum Beispiel ein neues Feld hinzugefügt ist, muss ja individuell beurteilt werden, ob dieses Feld ins Archiv eingeschlossen werden darf oder nicht. Ohne einen "Stolperstein" oder Alarm werden solche Dinge leicht vergessen, und so könnte dann entweder ein Feld im Archiv landen, das eine Identifikation von Personen ermöglicht, oder eines fehlen, das für die Forschung interessant gewesen wäre. Unsere Lösung besteht in funktionalen Tests über das Test-Framework Behat: In den Testspezifikationen wird in natürlicher Sprache konfiguriert, welche Daten im Archiv landen sollen und welche ausgespart werden. Die Tests gleichen das mit der Gesamtheit der vorhandenen Felder ab und schlagen fehl, sobald ein Feld existiert, für das keine Entscheidung getroffen ist.

Konkret sieht das dann so aus (Beispiel gekürzt):

Scenario: Normalizing certificate data contained in a multi-activity project (new data model)
    Given an organisation has been created and filled with data
    And a multi-activity project has been created and filled with data
    And an activity of type "Youth Exchange" has been added to the project and filled with data
    And a certificate comprising all activities has been created within the project
    When the certificate data is normalized
    Then the normalized data should contain the following fields:
        | fieldname                     | available |
        | publicCertificateId           | never     |
        | firstName                     | never     |
        | lastName                      | never     |
        | dateOfBirth                   | never     |
        | birthPlace                    | never     |
        | _birthCountry                 | never     |
        | email                         | never     |
        | certificateType               | always    |
        | languages                     | always    |
        | tasks                         | always    |
        | teamMemberRole                | always    |
        | trainingActivities            | always    |
        | lengthOfInvolvement           | always    |
        | activities                    | always    |
        | competences                   | always    |
        | learningOutcomes              | always    |
    And no other fields exist than given in this list

Damit waren wir fast am Ziel – doch eine Aufgabe blieb noch: Wie man in der obigen Definition sieht, werden die Felder tasks und competences ins Archiv aufgenommen, also Beschreibungen der Aufgaben und der Kompetenzentwicklung des Zertifikatsempfängers. In diesen Beschreibungen kann der Name des Zertifikatsempfängers vorkommen, wodurch die Zertifikate nicht mehr vollständig anonymisiert wären. Um dies zu verhindern, ersetzen wir in allen solchen Beschreibungsfeldern den Vor- und Nachnamen sowie die E-Mail-Adresse des Zertifikatsempfängers durch Platzhalter. Auch das sah auf den ersten Blick einfacher aus, als es tatsächlich war: Da Youthpass-Zertifikate mehrsprachig ausgestellt werden können und die Schreibweise des Namens von Sprache zu Sprache variieren kann (z. B. im Falle von griechischen Namen), müssen die Ersetzungen für alle Sprachversionen des Namens vorgenommen werden.

Und noch eine sprachliche Herausforderung begegnete uns: In vielen Sprachen werden die Namen dekliniert, aus Sebastian wird z. B. Sebastians (Aufgabe). Im Deutschen ist das noch relativ einfach, denn es gibt nur das Genitiv-s, das hinten angehängt wird. In anderen europäischen Sprachen gibt es Endungen mit mehreren Buchstaben, oder es fällt ein Buchstabe am Ende des Namens weg, bevor die Endung angehängt wird. Wir haben daher nach einigen Experimenten entschieden, den letzten Buchstaben des Namens zu entfernen und bis zu 4 Buchstaben für die Endung anzuhängen. Um im Fall von kurzen Namen wie Ly nicht jedes Wort, das mit L beginnt, zu ersetzen, wenden wir die Kürzung erst ab Namenslängen von 4 Buchstaben an.

Als wir mit dem "Research Archive" am Ziel waren, hatten wir eine schöne Erkenntnis: Ursprünglich ging es in dem Projekt ja darum, Daten der gelöschten Zertifikate zu Forschungszwecken zu retten. Da wir diese anonymisierten Datensätze jetzt aber schon direkt beim Generieren der Zertifikate erzeugen, können sie sofort für Recherchezwecke eingesehen und für die Weiterentwicklung herangezogen werden, was mit den vollständigen Zertifikaten aufgrund des Personenbezugs nicht möglich war.

Keine Löschung ohne Vorwarnung

Nun war also alles zur Löschung bereit – aber die Nutzer wussten noch nichts davon. Natürlich sollten nicht einfach hunderttausende Datensätze gelöscht werden, ohne die betroffenen Projektverantwortlichen vorher zu informieren. Eventuell wollte ja der ein oder andere auch ein altes Zertifikat noch einmal neu aushändigen.

Zu diesem Zweck zeigen wir jetzt zum einen bei den betroffenen Projekten das Datum der geplanten Löschung als kleinen Warnhinweis in der Projektübersicht an. Zum anderen sollten alle Projektverantwortlichen der zu löschenden Projekte mehrfach per Mail über die geplante Löschung informiert werden: Einmal drei Monate vor der geplanten Löschung, ein zweites Mal einen Monat vorher und ein letztes Mal eine Woche vor der Löschung.

Da wir für jede Vorwarnrunde ca. 50.000 Mails verschicken mussten, haben wir viel Liebe in die Formulierung des Mail-Subjects und des Vorschautexts der Mail gesteckt, um den Empfängern die Information möglichst prägnant zu vermitteln. Für das visuelle Design der Mails konnten wir die Templates einer anderen Benachrichtigungsfunktion, die wir vor einigen Jahren entwickelt haben, verallgemeinern und wiederverwenden.

Auch hier gab es eine noch eine späte Überraschung: Das System ist so aufgebaut, dass es die Mails für jedes Projekt einzeln verschickt. Bei einer Datenanalyse fiel aber auf, dass einige Youthpass-Benutzer weit über 100 Projekte hatten, die bereits zur Löschung anstanden. Es kam nicht in Frage, diesen Nutzern in jeder Vorwarnrunde 100 Mails zu senden. Unser Kunde hat daher die Mails allgemein formuliert, also ohne Bezug auf ein konkretes Projekt, und wir haben einen Mechanismus ergänzt, der E-Mail-Adressen, die vor kurzem bereits eine Benachrichtigung für ein Projekt erhalten haben, beim Versand weiterer Nachrichten der gleichen "Vorwarnstufe" überspringt.

Um das System möglichst robust zu gestalten, gibt es keine festen Zeitpunkte für den Versand der Mails oder die Löschung der Projekte. Nur der erste Mailversand orientiert sich am Enddatum des Projektes, jeder weitere am Datum des vorangegangenen Mailversandes für dieses Projekt. Und die eigentliche Datenlöschung ist an den Zeitpunkt der letzten Warnmail gekoppelt: Frühestens eine Woche, nachdem diese Mail in einem Projekt tatsächlich erfolgreich verschickt wurde, kann das Projekt gelöscht werden. Auf diese Weise ist sichergestellt, dass auch Systemstörungen nicht dazu führen können, dass Projekte ohne ausreichend Vorwarnung gelöscht werden. Das definierte Warnschema (erste, zweite, dritte Warnung mit entsprechenden Abständen) wird immer eingehalten und es kann höchstens zu Verschiebungen nach hinten kommen, was in diesem Fall als das geringste Übel erschien.

Im Zuge der Vorabinformation hat unser Kunde das Verfahren auch auf der Website beschrieben: https://www.youthpass.eu/en/help/deletion/

Zu guter Letzt: Marie Kondo-ing Youthpass!

Nach all dieser Vorarbeit war die eigentliche Löschung der Projekte schnell implementiert: Da wir bereits vor einigen Jahren durch die Einführung sogenannter Fremdschlüsselbeziehungen in der Datenbank definiert hatten, welche der unterschiedlichen Datensätze wie miteinander zusammenhängen, mussten nun nur noch die Projekte, die tatsächlich zur Löschung reif waren (also die vor mindestens einer Woche die dritte Warnmail erhalten hatten), aus der Datenbank gelöscht werden. Die zugehörigen Teilnehmer- und Generierungsinformationen wurden über die Fremdschlüssel automatisch mit entfernt. Außerdem musste das System noch die zugehörigen PDF-Dateien, die in einem Dateiablagesystem verwaltet werden, löschen. Das war eine Neuerung: In den Anfangsjahren von Youthpass war es eine ausdrückliche Anforderung, dass alle jemals generierten PDFs aus Gründen der Nachvollziehbarkeit und des Schutzes vor Missbrauchs dauerhaft aufbewahrt werden sollten. Das musste nun (aus heutiger Sicht erfreulicherweise) geändert werden, sodass nur noch PDFs aufgehoben werden, die noch benötigt werden.

Und schließlich war es soweit: Die Löschung konnte erfolgreich umgesetzt werden und auf dem Weg dahin hat Youthpass noch einige strukturelle Verbesserungen erfahren. Nicht nur wir sind zufrieden, auch unsere Kunden. Via GitHub schrieb uns Kundin Eda:

Yuhu! Great! Thanks for Marie Kondo-ing Youthpass :D