Autor und Sprecher

Thorsten Siefert

Technik und Gestaltung

Thorsten Siefert

Es gilt das gesprochene Wort

Diesen Satz kann ich aus Entwicklersicht gut nachvollziehen. Trotzdem lohnt sich eine zweite Frage:

Was genau muss an den Daten real sein?

Denn „realistisch testen“ bedeutet nicht automatisch, dass dafür ein vollständiger Produktivbestand benötigt wird.

Bei vielen Tests reicht es vollkommen aus, wenn Testdaten dieselbe Struktur, dieselben Wertebereiche, Beziehungen und fachlich relevanten Sonderfälle abbilden wie die produktiven Daten.

Bei Migrationen gibt es allerdings einen Punkt, an dem genau das nicht mehr genügt.

Wie weit reichen synthetische Testdaten?

Synthetische Daten können erstaunlich weit tragen.

Solange der Test prüfen soll, ob eine Anwendung oder Migration mit einer bestimmten Datenstruktur und bekannten fachlichen Konstellationen umgehen kann, müssen die einzelnen Datensätze nicht real sein.

Damit lassen sich zum Beispiel prüfen:

• Feld- und Datentypen
• Mappingregeln zwischen Quell- und Zielsystem
• Pflichtfelder und Validierungen
• Beziehungen zwischen Datensätzen
• Transformationsregeln
• bekannte Sonderfälle
• Fehlerbehandlung
• Schnittstellen
• große Datenmengen und Performance

Auch komplexe Datenbestände können dafür künstlich erzeugt werden.

Entscheidend ist, dass nicht nur „irgendwelche Fake-Daten“ erzeugt werden. Gute synthetische Testdaten müssen die Eigenschaften des realen Datenbestands abbilden, die für den jeweiligen Test relevant sind.

Ein Beispiel:

Wenn ein Altsystem zehn unterschiedliche Varianten einer Kundenbeziehung kennt, hilft ein synthetischer Datenbestand mit ausschließlich idealtypischen Datensätzen wenig. Sind diese zehn Varianten aber bekannt, können sie gezielt nachgebildet werden.

Bis hierhin besteht normalerweise kein technischer Grund, personenbezogene Originaldaten einzusetzen.

Wo synthetische Daten an ihre Grenze kommen

Anders wird es, wenn nicht mehr nur geprüft werden soll, ob das Migrationsverfahren grundsätzlich funktioniert, sondern ob es mit dem konkreten vorhandenen Datenbestand funktioniert.

Produktive Datenbestände haben Geschichte.

Über Jahre entstehen Konstellationen, die niemand bewusst entworfen hat:

• historische Feldbelegungen
• inkonsistente Werte
• Sonderfälle aus früheren Systemversionen
• Daten, die heutigen Validierungsregeln nicht mehr entsprechen
• unerwartete Beziehungen
• Altbestände aus früheren Migrationen

Was man nicht kennt, kann man auch nicht gezielt synthetisch erzeugen.

Spätestens wenn genau diese tatsächliche Datenrealität Gegenstand der Prüfung wird, kann die Nutzung des Originalbestands erforderlich sein.

Migrationen brauchen unterschiedliche Teststufen

Deshalb halte ich es für sinnvoll, nicht pauschal zwischen „Testdaten“ und „Produktivdaten“ zu unterscheiden.

Die Teststrategie kann stufenweise aufgebaut werden.

Frühe Entwicklungs- und Mappingtests können vollständig mit synthetischen Daten arbeiten.

Danach können synthetische Daten um gezielt konstruierte Grenz- und Sonderfälle ergänzt werden.

Auch Mengentests benötigen nicht zwingend Originaldaten. Wenn geprüft werden soll, ob zehn Millionen Datensätze innerhalb eines bestimmten Zeitfensters verarbeitet werden können, lässt sich die erforderliche Datenmenge häufig künstlich erzeugen.

Erst danach stellt sich die Frage:

Muss jetzt der konkrete Produktivbestand bewiesen werden, oder weiterhin nur die technische Funktionsfähigkeit?

Das ist für mich der entscheidende Übergang.

Cut-over-Tests können eine andere Datenrealität benötigen

Ein klassischer Fall ist der Cut-over-Test.

Vor einer produktiven Umstellung soll möglichst realitätsnah geprüft werden:

• ob der tatsächliche Bestand migriert werden kann,
• wie lange die Migration dauert,
• ob Kontrollsummen und Bestände übereinstimmen,
• ob unerwartete Datenkonstellationen auftreten,
• ob der technische Ablauf des Umstellungswochenendes funktioniert,
• und ob ein Rollback oder Wiederanlauf beherrscht wird.

Hier kann der konkrete Originaldatenbestand notwendig werden.

Noch deutlicher wird es, wenn die Migration gegenüber Revision, Wirtschaftsprüfern oder anderen prüfenden Stellen nachweisbar sein muss.

Dann geht es nicht mehr nur um die Frage:

„Kann unsere Software solche Daten migrieren?“

Sondern möglicherweise um:

„Können wir nachweisen, dass genau dieser Bestand vollständig und korrekt migriert wurde?“

Dafür reichen synthetische Daten naturgemäß nicht immer aus.

Privacy by Design heißt nicht: niemals Originaldaten

Genau deshalb halte ich die einfache Regel „Produktivdaten gehören grundsätzlich nicht in Testumgebungen“ für zu pauschal.

Privacy by Design bedeutet vielmehr:

Für jeden Test wird bewusst entschieden, welche Datenrealität tatsächlich benötigt wird.

Wenn synthetische Daten ausreichen, sollten keine personenbezogenen Originaldaten kopiert werden.

Wenn Originaldaten erforderlich sind, muss diese Entscheidung nachvollziehbar begründet werden.

Und dann ändern sich die Anforderungen an die Testumgebung.

Originaldaten machen aus „Test“ keinen rechtsfreien Raum

Sobald reale personenbezogene Daten verwendet werden, ist „das ist doch nur Test“ keine ausreichende Sicherheitsstrategie.

Dann sollte unter anderem geklärt sein:

• welcher konkrete Testzweck die Nutzung rechtfertigt,
• welcher Datenumfang erforderlich ist,
• wer Zugriff benötigt,
• wie lange die Daten benötigt werden,
• wie Testsystem, Exporte und Schnittstellen geschützt werden,
• und wie die Daten anschließend wieder entfernt werden.

Datenminimierung bedeutet dabei auch, nicht reflexartig den kompletten Bestand bereitzustellen, wenn nur ein Teil davon benötigt wird.

Besonders wichtig: Dienstleister bei Migrationen

Migrationen werden häufig nicht ausschließlich intern durchgeführt.

Softwarehersteller, Implementierungspartner, Cloud-Anbieter, Datenbankspezialisten oder externe Migrationsteams erhalten unter Umständen Zugriff auf produktive Daten.

Spätestens dann reicht eine rein technische Betrachtung nicht mehr.

Vor der Bereitstellung sollte geklärt sein, in welcher Rolle der jeweilige Dienstleister handelt und welche vertragliche Grundlage dafür erforderlich ist.

Handelt ein Dienstleister als Auftragsverarbeiter, gehören insbesondere die Anforderungen an die Auftragsverarbeitung in die Vertragsstruktur. Bei anderen Rollen kann die rechtliche Einordnung anders aussehen. Ein Vertrag zur Auftragsverarbeitung ist deshalb nicht automatisch für jeden beteiligten Dienstleister die richtige Lösung.

Unabhängig von der konkreten Rollenverteilung sollten jedenfalls Fragen geregelt sein wie:

• zulässiger Zweck der Verarbeitung
• Umfang des Zugriffs
• Vertraulichkeitsverpflichtungen
• technische und organisatorische Schutzmaßnahmen
• Einsatz weiterer Unterauftragnehmer
• Speicher- und Verarbeitungsorte
• Umgang mit Sicherheitsvorfällen
• Rückgabe beziehungsweise Löschung der Daten
• Nachweis- und Kontrollmöglichkeiten

Gerade bei Migrationsprojekten darf diese Vertragsstruktur nicht erst diskutiert werden, nachdem der erste Datenbankdump bereits beim Dienstleister liegt.

Eine Migration muss auditierbar bleiben

Wenn Originaldaten eingesetzt werden, reicht es außerdem nicht, die Umgebung lediglich „abzusichern“.

Die Entscheidung und der Umgang mit den Daten sollten nachvollziehbar und prüfbar sein.

Dazu sollte beispielsweise dokumentiert werden:

• welcher Datenbestand für welchen Test verwendet wurde,
• wann der Bestand erzeugt wurde,
• wer ihn freigegeben hat,
• wer darauf zugreifen durfte,
• welche Verarbeitungsschritte durchgeführt wurden,
• welche Kontrollwerte vor und nach der Migration vorlagen,
• welche Abweichungen festgestellt wurden,
• und wann die Testbestände wieder gelöscht wurden.

Bei prüfungsrelevanten Migrationen kommen technische Nachweise hinzu.

Kontrollsummen, Datensatzanzahlen, Abstimmprotokolle oder definierte Reconciliation-Verfahren können beispielsweise zeigen, dass Ausgangs- und Zielbestand nachvollziehbar miteinander abgeglichen wurden.

Auditierbarkeit ist damit selbst eine Anforderung an das Migrationsdesign.

Zugriff ist nicht gleich Berechtigung für alles

Ein weiterer Klassiker: Das Migrationsteam benötigt Zugriff auf die Datenbank.

Daraus folgt nicht automatisch, dass jede beteiligte Person während der gesamten Projektlaufzeit Zugriff auf sämtliche Daten benötigt.

Berechtigungen können zeitlich, organisatorisch und technisch begrenzt werden.

Gerade bei Dienstleistern sollte nachvollziehbar sein:

Wer konnte wann auf welchen Bestand zugreifen – und warum?

Die Testumgebung sollte damit nicht zur dauerhaft weniger geschützten Kopie der Produktion werden.

Und nach der Migration?

Dieser Punkt wird erstaunlich leicht vergessen.

Für Cut-over-Tests oder prüfungsrelevante Nachweise werden Datenbestände bereitgestellt. Das Projekt geht produktiv. Die Migration ist abgeschlossen.

Und Monate später existiert der damalige Datenbestand immer noch:

• auf einem Testserver,
• in einem Datenbankdump,
• in einem Backup,
• auf dem System eines Dienstleisters,
• oder in einem Projektverzeichnis.

Deshalb sollte bereits vor der Bereitstellung festgelegt werden, wann, von wem und wie diese Daten wieder gelöscht werden. Ebenso muss dies dokumentiert werden.

Bestehen Aufbewahrungs- oder Nachweispflichten, kann eine weitere Speicherung erforderlich sein. Dann sollte aber klar definiert sein, welche Daten für welchen Nachweis tatsächlich aufbewahrt werden müssen und wer darauf zugreifen darf.

Entfallen Zweck und gegebenenfalls bestehende Aufbewahrungserfordernisse, muss auch der Testbestand verschwinden.

Und das sollte im Idealfall nicht nur passieren, sondern nachweisbar passieren. Insbesondere dann, wenn Dienstleister Kopien erhalten haben.

Die eigentliche Frage lautet deshalb nicht „echt oder künstlich?“

Synthetische Daten sind kein Selbstzweck.

Originaldaten sind aber auch kein Qualitätsmerkmal für einen besonders realistischen Test.

Die richtige Datenrealität hängt vom Testziel ab.

Für Struktur, Logik, bekannte Sonderfälle und vielfach auch Performance können synthetische Daten sehr weit reichen.

Wenn dagegen der konkrete historische Bestand, seine Vollständigkeit oder seine nachweisbare Überführung geprüft werden muss, können Originaldaten erforderlich sein.

Privacy by Design beginnt deshalb nicht mit einem Verbot.

Es beginnt mit drei Fragen:

1. Welche Realität muss dieser Test tatsächlich abbilden?

2. Welche Daten benötigen wir dafür wirklich?

3. Und wie stellen wir sicher, dass diese Daten nach dem Test nicht einfach bleiben?

Genau dort wird Privacy by Design zur Engineering- und Governance-Aufgabe“