Seitdem die GDPR in Kraft getreten ist, gibt es viele Diskussionen über die Verwendung personenbezogener Daten für andere Zwecke als die eigentliche Anwendung, für die sich der Nutzer angemeldet hat. Dazu gehören auch Testzwecke, bei denen sich viele Unternehmen immer noch auf Produktionsdaten verlassen, um einige ihrer Systeme (regressiv) zu testen, weil sie glauben, dass dies die einzige akzeptable Möglichkeit ist, reale Szenarien zu testen. In letzter Zeit haben sich die Aufsichtsbehörden zunehmend mit diesem Thema befasst. In diesem Artikel werden einige Anforderungen an Testdaten und Empfehlungen für den Umgang mit ihnen erläutert.
Grundsätzlich bestimmen und beeinflussen die Anforderungen, welche Testdaten für angemessene Tests vor der Inbetriebnahme von Softwareänderungen zu verwenden sind. Einerseits wünschen sich Tester/innen Daten, die nahe an den vorhandenen Produktionsdaten liegen, damit sie leichter und realistischer Testszenarien ermitteln können, die den realen Szenarien ähneln. Andererseits wollen Regulierungsbehörden und IT-Sicherheitsexperten die Menge an Daten aus der Produktion, die für Tests verwendet werden, begrenzen, da Testumgebungen in der Regel nicht so sicher sind wie Produktionsumgebungen und diese Verwendung auch die Umsetzung des "Rechts auf Vergessenwerden" erheblich erschwert.
Aus diesem Grund werden die Definitionen der GDPR in den Artikeln 13, 17 und 32 durch eine Reihe von Vorschriften ergänzt, die insbesondere für Finanzunternehmen gelten. In Deutschland sind diese im Kreditwesengesetz (KWG) geregelt und werden durch branchenspezifische Anforderungen in den MaRisk, BAIT (oder VAIT, KAIT, etc.) und firmenspezifischen Richtlinien weiter detailliert.
Nehmen wir den Artickel 32 der GDPR als Beispiel. Er besagt, dass der für die Datenverarbeitung Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen ergreifen müssen, um ein dem Risiko angemessenes Sicherheitsniveau zu gewährleisten. Für Banken wird dies in MARisk AT 7.2 weiter ausgeführt, wo die Notwendigkeit, die Sicherheit, Integrität, Verfügbarkeit und Authentizität von Daten zu gewährleisten, definiert wird, und in BAIT 7.11, wo das Datenschutzniveau speziell für Prüfzwecke erwähnt wird. Diese Anforderungen decken jedoch nicht alle Details ab; jede Organisation muss (mit Hilfe ihrer Datenschutz- und IT-Sicherheitsbeauftragten) selbst bestimmen, was "angemessen" für sie bedeutet.
Wie können Sie die regulatorischen Anforderungen einhalten, insbesondere in einer Applikationsumgebung mit langer Geschichte?
Ausgangspunkt muss eine systematische Risikoanalyse der Ist-Situation sein. Welche Art von Testdaten wird in welchem System und in welcher Umgebung verwendet? Verwenden Sie die (hoffentlich vorhandene) Business-Impact-Analyse, um das Risiko für jede Anwendung in Bezug auf die Daten einzustufen. Notieren Sie sich genau, welche persönlichen Daten verwendet werden - woher sie kommen, ob sie lokal gespeichert oder manuell verändert werden und wer für die Daten-aktualisierung in der Testumgebungen verantwortlich ist. Wenden Sie sich dann den Testern selbst zu - wie sie Tests dokumentieren, wie sie bestimmen, welche Testdaten für ihre Tests benötigt werden, und wie integriert ihre Szenarien sind.
Anhand der Ergebnisse können Sie Ihr weiteres Vorgehen festlegen. Für Anwendungen mit hohem Risiko (solche, die identifizierende Personendaten speichern oder für die hohe Verfügbarkeitsanforderungen definiert wurden) müssen Sie sich mit Techniken zur Datenmaskierung oder der Verwendung synthetischer Testdaten zur Durchführung Ihrer Testfälle befassen. Es gibt zwar viele Tools für diese Aufgabe, aber die Auswahl des Tools sollte weniger wichtig sein als:
a. zu verstehen, wie das Testen normalerweise durchgeführt wird und
b. die Abbildung des Datenflusses zwischen verschiedenen Systemen, um sicherzustellen, dass die Datenintegrität zwischen den Anwendungen (und damit den Tests) bei der Maskierung der Daten gewährleistet bleibt.
Ein Praxisbeispiel
Eine deutsche Bank ging zunächst alle Anwendungen durch, die für dieses Institut als risikoreich und unternehmenskritisch (KRITIS) eingestuft wurden. Anhand von Interviews mit Testern und Betriebsmitarbeitern wurden die Abhängigkeiten dieser Anwendungen zu anderen Anwendungen während der Tests ermittelt und gemeinsame Datenquellen für personenbezogene Daten identifiziert. Auf der Grundlage dieses Wissens wurden Maskierungsalgorithmen entwickelt und parallel dazu ein geeignetes Tool ausgewählt, das sowohl funktionale Anforderungen (Datenmaskierung, Archivierung, Generierung synthetischer Daten) als auch technische Anforderungen (Cloud-Speicher, Vor-Ort-Datenmaskierung, Unterstützung verschiedener Anwendungsplattformen) erfüllte.
Es wurde ein Pilotprojekt durchgeführt, bei dem die Skripte für die Datenmaskierung ersetzt und die maskierten Daten mit typischen Testszenarien validiert wurden. Die Business-Tester mussten im Umgang mit den maskierten Daten geschult werden, da sie in vielen Fällen daran gewöhnt waren, "ihre" Clients zu Testzwecken in Testumgebungen zu finden. Außerdem wurde ein zentrales Team für die Verwaltung der Testdaten aufgebaut, das die Projektmanager und Tester bei der Ermittlung der für die Tests erforderlichen Daten und der Befüllung der Testumgebungen mit diesen maskierten Daten anleitet. Ein Fahrplan für weitere Verbesserungen und die Ausweitung der Nutzung maskierter Testdaten in der gesamten Bank besteht.
QUELLE: Dieser Artikel ist ein Ausschnitt von Software Survey (Release 1/2023): Survey of Tools for Software Engineering, Engineering, bereitgestellt von United Innovations.
Die Plattform The United Innovations (UI) ist eine Unterorganisation der GFFT e.V., einer gemeinnützigen Gesellschaft, die sich dem Forschungstransfer widmet. Ihr Hauptziel ist es, Innovationen in Deutschland, Europa und darüber hinaus voranzutreiben. Mit ihrem umfangreichen Netzwerk setzt sich die Plattform dafür ein, dieses Ziel zu erreichen.
United Innovation unterstützt den Innovationsprozess in verschiedenen Themenbereichen mit identischen Angeboten: die Technologiedatenbank TechL©, Surveys, Tech-Awards, zahlreichen Veranstaltungen sowie Unterstützung von Start-Ups, Proofs of Concepts und Launch-Projekten.