Felder anonymisieren (DSGVO)

[nico1964]

Hallo,
ich weiß reichlich spät aber gestern sind meine Bosse draufgekommen, dass die DSGVO auch uns trifft.

Ich habe jetzt die undankbare Aufgabe, die betroffenen Felder nicht zu verschlüsseln, sondern zu anonymisieren. Mein erster Gedanke dabei war einfach mit SQL CREATE MASK zu arbeiten.
Das wurde aber von meinen Vorgesetzten (AS400 Verweigerer) abgelehnt.

Jetzt steh ich vor dem Problem 147 Felder aufgeteilt auf 10 Dateien zu anonymisieren ohne das unsere Anwendung gleich in die Luft fliegt.

Eckdaten:
Power 7 Release 7.3
Anwendung Green Screen in COBOL mit native READ/WRITE/UPDATE/DELETE
Datenbank DDS-beschriebene Dateien

Schade, dass CREATE MASK nicht akzeptiert wird. Damit hätte ich sowohl die Anwendung als auch SQL- und QUERY-Abfragen und Zugriffe von außen abgehandelt.

Für Anregungen und Tipps wäre ich euch wirklich dankbar.

P.S.: Fremdsoftware kommt wie immer bei uns nicht in Frage gibt's nur für die Mircosoft Umgebungen

[Fuerchau]

Was verstehst du unter "Felder anonymisieren"?
Für die ERP-Anwendung kann man dies komplett ausschließen, da sie dann tatsächlich auf die Schnautze fällt.
Auch maskierte Daten sind kritisch, da man ja selten verfolgen kann, ob ein Programm, dass die maskierten Daten liest nicht ggf. auf einer anderen Datei wieder ausgibt oder verarbeitet.
Immerhin passiert die Maskierung ja zwischen Dateizugriff und Programmcode!

Was also bleibt ist der Zugriff außerhalb der Anwendung (SQL, Query, ODBC).
Hier bietet sich nur das Sicherheitskonzept der AS/400:
- Datenlib und Dateien gehören einem APP-User und sind für Public *exclude.
- Programme laufen mit Berechtigung des App-Owners.
- Bereitstellung von Views für alle anderen Funktionen mit der entsprechenden Maskierung/Auslassung

[nico1964]

Unter anonymisieren meinen meine Vorgesetzten, dass zum Beispiele im Feld Name statt nico1964 irgendein Zufallsstring in der Länder des Feldes Name steht.

Das mit dem auf die Schnauze fallen ist nicht so heiß bei uns, da die Partnern, wo die Daten maskiert werden, nur mehr im Anzeigemodus aufgerufen werden können und das auch nur über Umwege.

Der Ansatz wie Du das lösen würdest, würde ein komplettes Umschreiben der Anwendung erfordern.
Dafür ist weder Zeit noch die nötige Manpower vorhanden. Am liebsten würde ich ja die betroffenen Daten einmal verschlüsseln von wegen anonymisieren. Das ist alles nur weil unser anderen Mickey Mouse Anwendungen weniger beherrschen als die Power 7. Zeigt sich bei allen systemübergreifenden Projekten(z.B. Drucken über Follow Me Printing mit Übergabe des richtigen Users auf der i-Series schon längst gelöst, bei den anderen Anwendungen denken Sie noch nach. Muss aber in genau 1 Monat funktionieren.)

[Fuerchau]

Zum Thema Verschlüsselung hilft dir das in der Anwendung ja auch nicht, da diese ja wiederum zwischen der Datenbank und dem Programm liegt.
Die 5250-Clients lesen die Daten nun mal ja wieder unverschlüsselt.

Ansonsten gibt es nur SQL-Funktionen für Crypt/Encrypt. Da du aber COBOL mit native Zugriffen hast, entfällt das auch wieder.

Ein Umschreiben der Anwendung ist ja auch nur zum Teil richtig.
I.d.R. greifst du auch per COBOL auf eine PF/LF zu.
Der Zugriff auf die PF lässt sich ebenso auf eine LF umbiegen ohne das Programm ändern zu müssen.

Also können die Nur-Anzeigeprogramme per Liblist durchaus auf LF's zugreifen, die dann die Inhalte ausblenden und statt dessen kalkulierte Werte anzeigen.
Ggf. muss man bestimmte Daten halt per Trigger doppeln für die Anzeige.

[nico1964]

Zum Thema Verschlüsselung hilft dir das in der Anwendung ja auch nicht, da diese ja wiederum zwischen der Datenbank und dem Programm liegt.
Die 5250-Clients lesen die Daten nun mal ja wieder unverschlüsselt.

Also das ist das geringste Problem und habe ich auch schon ausprobiert. Bei Partnern, wo ein gewisses Kennzeichen gesetzt ist, werden die von mir zuvor mit CREATE MASK markierten Daten auch als Maske ausgegeben. Da wird auch nix mehr zurück geschrieben.

[Fuerchau]

"Schade, dass CREATE MASK nicht akzeptiert wird..."
Dann leiste Überzeugungsarbeit, dass ohne Neuentwicklung dies die einzige Chance ist.

[BenderD]

Also das ist das geringste Problem und habe ich auch schon ausprobiert. Bei Partnern, wo ein gewisses Kennzeichen gesetzt ist, werden die von mir zuvor mit CREATE MASK markierten Daten auch als Maske ausgegeben. Da wird auch nix mehr zurück geschrieben.

... nochmal nachgefasst: was ist hier mit "Partnern" gemeint? Handelt es sich hierbei um replizierte Datenbestände?

D*B

[nico1964]

... nochmal nachgefasst: was ist hier mit "Partnern" gemeint? Handelt es sich hierbei um replizierte Datenbestände?D*B

Hallo,mal noch genauer definiert. Sollte ein Kunde seine Löschung beantragen, so wurde bei uns im Unternehmen entschieden keine physiche Löschung sondern eine Anonymisierung durchzuführen. Der Grund ist das es sich bei uns um eine historisch gewachsenen Anwendung handelt (seit gefühlt 1989) und keiner mehr die gesamte Anwendung überblickt. Ich selbst bin seit 11 Jahren im Unternehmen und so ziemlich single source.Also die Aufgabenstellung lautet wie folgt. Im Partnerstamm (Kunden und Lieferanten) wird ein Kennzeichen gesetzt und an Hand dieses Kennzeichen sollen alle personenbezogenen Daten verteilt über n-Dateien verschlüsselt werden. Welche Daten das bei uns sind und welche Dateien davon betroffen sind, habe ich in der kurzen Zeit seit das Projekt bei mir am Tisch gelandet ist, schon verifiziert. Jetzt habe ich natürlich nach einer einfachen Methode gesucht, wo ich sowohl die Datenbank(DDS) als auch die Anwendung (COBOL) möglichst nicht anrühren muss.Es ist auch von oben her keine Rückentschlüsselung gewünscht. Da war halt mein erster Ansatz CREATE MASK.Den Ansatz habe ich mittlerweile verworfen, der funktioniert zwar bei der Hauptdatei wo das Kennzeichen gesetzt ist, aber nicht mehr bei den anderen.Jetzt habe ich seit gestern, auch auf Grund eurer wie immer fundierten Antworten, ein wenig recherchiert und mit SQL herumprobiert.Mein jetziger Ansatz ist folgender:select part_nr, suchname, substr(encrypt_RC2(ustid, 'xxxxxxxxxxx'), 1, 14), ustid from lea/leap1 where loschkz <> ' ' Wobei das Password für die Verschlüsselung ist natürlich unkenntlich gemacht. Der Substring ist notwendig, damit ich mit den bestehenden Feldlängen in der Datei weiter arbeiten kann.Ach ja das encrypt habe ich meinem Vorgesetzten(null AS400 Ahnung) verkaufen können

[BenderD]

... das ist eine wenig anders geartete Lage, als bislang von mir verstanden:
- mask und encrypt scheiden beide(!!!) tatsächlich aus, da ja die Kunden bezogenen Daten auch danach leicht rekonstruierbar sind, was dem berechtigten Anspruch des Kunden zuwider läuft.
- was du brauchst ist ein update auf die Felder etwa nach der Art:
update lea/leap1 set feldxyz = substr(encrypt...(feldxyz ...))
der neue Inhalt lässt sich nicht rückübertragen, da ja nur der halbe String gespeichert wird.
- es bleibt allerdings noch das Problem, was mit bisherigen Sicherungsbeständen passieren soll.

D*B

[nico1964]

... das ist eine wenig anders geartete Lage, als bislang von mir verstanden:
- mask und encrypt scheiden beide(!!!) tatsächlich aus, da ja die Kunden bezogenen Daten auch danach leicht rekonstruierbar sind, was dem berechtigten Anspruch des Kunden zuwider läuft.
- was du brauchst ist ein update auf die Felder etwa nach der Art:
update lea/leap1 set feldxyz = substr(encrypt...(feldxyz ...))
der neue Inhalt lässt sich nicht rückübertragen, da ja nur der halbe String gespeichert wird.
- es bleibt allerdings noch das Problem, was mit bisherigen Sicherungsbeständen passieren soll.

D*B

Hallo,
danke nochmals für Deine Antworten, die Lösung mit dem Substr(encrypt wird es auch werden.
Tja und was die bisherigen Sicherungsbestände betrifft, da bin ich Gott sei Dank nicht zuständig, aber ich weiß, dass die Kollegen schon darüber nachdenken.

[Fuerchau]

Das Problem wird sich i.d.R. nach einiger Zeit von selber lösen da man ja für die Sicherung die Medien eigentlich zyklisch verwendet.

[holgerscherer]

Im Partnerstamm (Kunden und Lieferanten) wird ein Kennzeichen gesetzt und an Hand dieses Kennzeichen sollen alle personenbezogenen Daten verteilt über n-Dateien verschlüsselt werden.

Also ("einfach") ein Pflegeprogramm schreiben oder anpassen, das beim Ereignis "Inaktiv setzen" loslegt:
- entsprechende Felder in allen Dateien (sofern bekannt) anonymisieren. Da reicht es, jedes Feld mit einem X auszufüllen
- Auditjournale im Hinterkopf halten, aber:
- das Finanzamt wird wie gewohnt 10jährige Speicherfrist fordern
- Backups: kann man nach 10 Jahren weg werfen
- Verschlüsseln ist unfug bei Daten, die noch gebraucht werden. Weg Verschlüsselte Daten bis zum Bildschirm und zurück wurde schon diskutiert
- nach der gesetzlichen Aufbewahrungsfrist nicht anonymisieren, sondern löschen. Was ein Prüfer nicht findet, kann er auch nicht benutzen

Und wie immer gilt: das ganze Thema wird bei 250 Grad gekocht und bei 30 Grad gelöffelt. Die Anforderung der DSGVO bezüglich Daten von natürlichen Personen und die Anforderung des Finanzamts laufen manchmal etwas diametral. Machen kann man da nix ausser versuchen und hoffen.
Und für die Zukunft: keine Daten von natürlichen Personen speichern, z.B. Ansprechpartner Verkauf beim Lieferanten und so weiter. Dann muss man sich da auch nicht drum kümmern, diese zu löschen, wenn der Verkäufer beim Lieferanten kündigt...

-h