View Full Version : Felder anonymisieren (DSGVO)
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
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
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.)
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.
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.
[
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.
... wie sieht denn die genaue Anforderung aus? Ich erkenne da nur, was es nicht sein soll und dass es nix kosten soll.
D*B
"Schade, dass CREATE MASK nicht akzeptiert wird..."
Dann leiste Überzeugungsarbeit, dass ohne Neuentwicklung dies die einzige Chance ist.
... wie sieht denn die genaue Anforderung aus? Ich erkenne da nur, was es nicht sein soll und dass es nix kosten soll.
D*B
Also ich darf weder ein CREATE MASK verwenden noch ein ENCRYPT
Ich soll einfach eine Feld z.B. NAME CHAR (50) mit dem Inhalt z.B. "Nicoladoni" durch einen xbeliebigen String ersetzen
Dann bleibt ja nur noch:
update file set Name = 'Xbeliebig' where Name = 'Nicoladoni'
Ich weiß nicht was die Anforderung "Bitte dusche mich, mache mich aber nicht nass" bringen soll.
Also ich darf weder ein CREATE MASK verwenden noch ein ENCRYPT
Ich soll einfach eine Feld z.B. NAME CHAR (50) mit dem Inhalt z.B. "Nicoladoni" durch einen xbeliebigen String ersetzen
... lass dir das schriftlich geben und dann frisch ans Werk, ein paar SQL Scripte und die Sache ist Husch, Pfusch erledigt. Sicherung würde ich vorher keine machen, da steht ja dann wieder Fug statt Unfug drin.
D*B
PS. Ich habe irgendwie das Gefühl, dass mir Dein Chef bekannt vorkommt...