Felder anonymisieren (DSGVO)

[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.

[BenderD]

... es gibt aber auch Archivierungsfristen und Jahressicherungen...

D*B

[Fuerchau]

ja, wenn ich aber die letzten 10 Jahr (oder mehr) sowieso in der Datenbank habe, reicht ja auch meine zyklische 7-Tagesicherung.
Neutralisiere ich also Daten, sind sie nach spätestens 7 Tagen weg.