DSGVO - Eine Lektion in der Modernisierung
Von Björn Gullberg
25. Juli 2017
3 min lesen
In meinem Beruf treffe ich viele Kunden, die gerade oder mitten in ihrer digitalen Transformation sind und von denen viele versuchen, das Rätsel um die kontinuierliche Lieferung / Bereitstellung zu lösen. In den letzten 5 Jahren konzentrierte sich die Diskussion um Softwareentwicklung auf Geschwindigkeit und Qualität. Die meisten Leute sagen, dass Automatisierung der Schlüssel ist, und ich auch - Automatisierung lässt Aufgaben schneller, zuverlässiger und wiederholbarer ausgeführt werden.
Eine der vielen Automatisierungen, mit denen Unternehmen zu kämpfen haben, ist die Testautomatisierung. Der Grund dafür sind Testdaten. Gemeinsame Testumgebungen bedeuten das Teilen und Überschreiben von Testdaten. Sobald eine Testausführung ausgeführt wurde, sind die Daten "verschmutzt" und können ohne "Aktualisierung" nicht für nachfolgende Tests wiederverwendet werden.
In weniger als einem Jahr müssen wir uns auch mit den neuen regulatorischen Anforderungen an Testdaten befassen. Es gibt Millionen von Artikeln über die Auswirkungen der DSGVO, aber ich werde mich an die Anforderungen halten, die unter Testgesichtspunkten erforderlich sind.
Sensitiv gegen unempfindlich
Namen, Adressen, Kreditkartennummern, Kontonummern, Telefonnummern, Kontonamen usw. sind offensichtlich vertraulich. Die eigentliche Herausforderung besteht jedoch darin, die Einschränkungen unempfindlicher Daten zu finden, die dazu führen können, dass Daten vertraulich werden. Im Folgenden habe ich beispielsweise den Autor, das Konto und das Bild anonymisiert, aber die meisten von Ihnen können diesen Datensatz aufgrund des „bekannten Verhaltens“ erneut identifizieren.
Mit anderen Worten, eine Kombination aus bekanntem Verhalten und freiem Text mit verschiedenen individuell unempfindlichen Daten kann so selten werden, dass sie nicht mehr unempfindlich ist. Das heißt, unempfindliche Daten können empfindlich werden, wenn die Tiefe eines typischen Datensatzes zu gering ist.
Sie müssen sich folgende Fragen stellen:
- Welche Daten sind sensibel?
- Gibt es Verhalten, spezifischen Inhalt oder gibt es unempfindliche Daten, die beim Kombinieren sensibel werden?
Manchmal kann sogar der Inhalt von Freitext sensibel sein.
Es gibt zwei verschiedene Möglichkeiten, um sensible Daten nicht identifizierbar zu machen. Anonymisierung und Pseudonymisierung. Beide Maskendaten basieren auf einem Verschlüsselungsalgorithmus (Schlüssel), aber mit Anonymisierung werfen Sie den Schlüssel weg, sodass er nicht umkehrbar ist.
Sobald alle diese Dateninstallationen abgeschlossen sind, müssen wir sie über alle Datenbanken, Dateien und anderen Datenspeicher hinweg synchronisieren, die von den internen oder externen Anwendungen verwaltet werden, mit denen wir interagieren. Die Herausforderung, dies für alle internen Anwendungen zu tun, ist schwer genug, aber was ist mit Drittanbietern? Nehmen wir im Twitter-Beispiel an, ich teste eine neue Funktion, bei der Kommentare zu einem Tweet auch als Kommentar zu einem verbundenen Facebook-Konto angezeigt werden. Irgendwie müssen wir unsere anonymisierten Testdaten synchronisieren, um auch das Testen dieser Funktion zu erfüllen.
SSS - Synthetisieren, simulieren und stimulieren
Mit anonymisierten (oder pseudonymisierten) Daten ist es für uns Menschen schwieriger, die Testfälle anhand der Daten zu identifizieren, weshalb manuelle Tests schwieriger werden. Bei Continuous Delivery-Initiativen hingegen arbeitet die Datenanonymisierung in Ihrem besten Interesse.
Damit die Testautomatisierung funktioniert, benötigen wir in allen Systemen, auf die während der Ausführung eines Testfalls zugegriffen wird, ordnungsgemäße, synchronisierte und unberührte Testdaten.
Wir benötigen Testdaten für 3 Hauptzwecke:
- Um unsere Testskripte zu füttern - manuell oder automatisiert
- Um unser SUT zu füttern - damit die Validierung von Testfällen mit (1) synchronisiert wird
- Um Simulationen / virtuelle Assets (Stubs / Mocks) mit synchronisierten Testdaten in Datenspeichern zu versorgen, in denen wir keine Kontrolle haben
Wenn wir einen Schritt weiter gehen und von automatisierten Tests abweichen möchten und dies kontinuierlich tun möchten, müssen wir dies auch wiederholt tun, vorzugsweise über ein Automatisierungsskript.
Proaktiv vs. reaktiv
Wenn wir über die DSGVO hinausblicken, müssen Unternehmen meines Erachtens die Schnittstellen- und Datenmodelle genauer untersuchen. Sie informieren uns über gültige und ungültige Strukturen und Daten durch den „Vertrag“ oder die Spezifikation. Wir müssen diese Verträge und Spezifikationen proaktiv testen, anstatt sie reaktiv anhand von Daten zu testen. Wir müssen in Bezug auf die Fehlervermeidung denken, bei der die Qualitätssicherung kein Ereignis oder eine bestimmte Phase ist, sondern ein fortlaufender Prozess.