DSGVO Daten verschlüsseln

[Fuerchau]

Mit der IBM gehts auch:
https://www.ibm.com/support/knowledg...s/catcrypt.htm
https://www.ibm.com/support/knowledg...c3Scenario.htm

Bei HTTPS-Aufrufen sollte man die Performance nicht verachten.
Und was macht man bei Nichtverfügbarkeit des Services?

Da kann man schon besser Java-Methoden mit D*B-Javaserver verwenden.

Und was mache ich mit den unverschlüsselten 5250-Datenströmen, die ja nun über die Leitung gehen?

Alternativ gibt es auch entsprechende Encrypt/Decrypt-Funktionen in SQL.
Aber da liegt ja bekanntlich der Hase im Pfeffer.
Diese Funktionen kann ich per ODBC natürlich genauso verwenden.
Wo bleibt da also der Schutz, da die Daten auf dem Server entschlüsselt und ebenso im Klartext über die Leitung gehen?

Und wie sieht die Performance bei Zugriffen über verschlüsselte Schlüssel (Keys) aus?
Native per RLA habe ich ja nur Binärfolgen und bei SQL muss der OrderBy nach der Entschlüsselung laufen, was jedweder Optimierung entgegenläuft.

Schlussendlich muss also weniger die Datenbank als der Weg für die Sicherheit sorgen.
Eine verschlüsselte Datenbank hilft da überhaupt nicht, wenn die Daten dann unverschlüsselt abgerufen werden müssen.

[ILEMax]

Das erklär mal jemand, der einen Hut auf hat!

Hier heist es:
DSGVO fordert Verschlüsselung!
Wenn eure AS/400 so toll ist, warum kann sie das nicht?
Was das bewirken soll und wo sich das auswirken soll, sagen wir nicht!

Das die Software auf einem (gefühlten)Stand von 1982 ist spielt außerdem keine Rolle!

[Fuerchau]

Siehe den Hinweis:
"sowie weiteren Faktoren ab wie Stand der Technik, "

Stand der Technik heißt nicht nur die Datenbank. Wenn die Anwendung so alt ist, dass sie mit einer verschlüsselten Datenbank nicht zurechtkommen kann, muss auf anderem Wege die Sicherheit gewährleistet werden.

Wenn also der Weg (z.B. via VPN, SSL auch im Intranet) verschlüsselt ist, sollte das genügen.
Es geht ja darum, dem Verlust (was ja technisch nicht möglich ist), also der unerlaubten Kopie vorzubeugen bzw. unmöglich zu machen.

Dazu gehört eben die Verschlüsselung des 5250-Datenstromes sowie des ODBC- und sonstigen Zugriffswegen.
Wenn die Online-DB dann entsprechend gesichert ist, geht es noch um das Verschlüsseln der Daten bei einer Sicherung auf ein externes Medium.
Und da sollten dann so Programme wie BRMS entsprechende Optionen anbieten können.

[BenderD]

... ich versuch es mal:
- DSGVO bezieht sich auf Personen bezogene Daten, damit sind erst mal alle Schlüsselfelder und ähnliches draußen. Verschlüsselt werden müssen Feldinhalte und nur ein Subset der Felder.
- IBM bietet Systemsoftware zur Verschlüsselung von Daten als Lizenzprodukt an und ich gehe mal davon aus, dass diese - trotz NSA (und Inlandsgeheimdienst) Backdoor - zugelassen ist.
- es gibt sowohl aus RPG & Co. aufrufbare APIs, als auch SQL Funktionen zum ver- und entschlüsseln.
- zum entschlüsseln muss man den verwendeten Key und Algorithmus kennen (siehe exemplarisch: https://www.ibm.com/support/knowledg...s/qc3decdt.htm) - analog zum verschlüsseln.
- für neue Applikationen braucht dann das Programm entsprechende Funktionalität, um den key zu ermitteln, zu verschlüsseln vor dem speichern, bzw. zum entschlüsseln nach dem lesen.
- die Schlüssel müssen natürlich entsprechend gesichert gehandhabt werden (nicht trivial, kann man aber jetzt mal gedanklich ausblenden)
- zur Minimierung von Aufwand kann man Feldweise an die Datei ein Exitprogramm hängen, das die crypto Funktionen macht.
- dieses Programm muss an die Schlüssel Informationen dran kommen, das könnte durch auslesen aus einem entsprechend secured Bereich erfolgen, oder das Programm könnte aus dem verarbeitenden Job per call Schnittstelle entsprechend initialisiert werden.
- Greift jemand diese verschlüsselten Daten ab, sieht er nur die verhexelten Feldinhalte, auf der AS selber könnte das Exit Programm diese noch gegen eine Maske (lauter xxx) austauschen.
- verstärken kann man solche Mechanismen noch dadurch, dass der Benutzer ein Password mitgeben muss, damit die Programme überhaupt an den wiederum verschlüsselten Key drankommen.
- Noch eine Runde drauf kriegt man dadurch, dass noch eine zusätzliche Hardware Komponente mit eingebaut wird, ich nenne diese Dinger immer RSA Tamagochi.

D*B

PS: @Baldur: Verschlüsselung/Entschlüsselung geht zumindest seit V5R4 (ich meine eher älter) Das Exit Gedöns (also ohne durchgehende Änderung vorhandener Programme) seit V7R1. Stand der Technik ist also: geht und muss, wenn man keine Risiken gehen will.

[Fuerchau]

Nun auf frisch ans Werk.
Zumal alle alten Programme, die noch ohne Filehandler, ihre Datei also direkt lesen/schreiben, alle die nötigen Verschlüsselungen durchführen müssen.

Auch personenbezogene Daten können gerne mal als Schlüssel (zumindest für den Optimizer) herangezogen werden.

Kritisch sind noch die System, die noch nicht mal V5R4 haben und ob selbst bei V5R4 die Verschlüsselung ohne das Softwareprodukt, welches ich nicht mehr kenne und das es bestimmt nicht mehr gibt, funktioniert.

Und trotzdem:
Man darf nicht vergessen, dass bei einer systemseitigen Ver-/Entschlüsselung die Daten im Klartext beim Client verfügbar werden.

[prsbrc]

Nur zur Info für die Österreicher... es wurde alles heißer gekocht als dann gegessen :

https://derstandard.at/2000078602336...en-Datenschutz

The austrian way of life :-D

greets

[holgerscherer]

... damit wirst Du in Bezug auf DSGVO keinen Blumentopf gewinnen, nicht mal einen Trostpreis.

Nachdenken hat man ja auch nicht beim Schreiben der DSGVO im Hinterkopf gehabt ;-)

-h

[AG1965_2]

... damit sind erst mal alle Schlüsselfelder und ähnliches draußen ...

Vorsicht: Wenn es sich um Begriffe handelt, mit denen eine Person eindeutig identifiziert werden kann UND man diesen Begriff nach außen gegeben hat (wie eben z.B. eine Kunden- oder Kontonummer), ist das auch ein personenbezogenes Datum!
https://www.datenschutzbeauftragter-...che-beispiele/

[BenderD]

Vorsicht: Wenn es sich um Begriffe handelt, mit denen eine Person eindeutig identifiziert werden kann UND man diesen Begriff nach außen gegeben hat (wie eben z.B. eine Kunden- oder Kontonummer), ist das auch ein personenbezogenes Datum!
https://www.datenschutzbeauftragter-...che-beispiele/

... überzeugt, ergänzt: wenn man es richtig macht!!

D*B

[Fuerchau]

"UND man diesen Begriff nach außen gegeben hat"

Welche Veranlassung habe ich diese Daten weiterzugeben?
Für mich steht immer noch der Technologieansatz im Vordergrund:
Wenn der Zugriff von dritten nicht ausgeschlossen werden kann, ist eine Verschlüsselung der Daten sicher sinnvoll.
Allerdings fängt dies beim Terminal ja bereits an.
Wenn ich den Blick von Dritten auf das Terminal nicht verhindern kann, so sind die Daten zu verschlüsseln, m.a.W., auf dem Bildschirm eigentlich bereits unleserlich zu machen.
Der sicherste Weg ist also, alle Personendaten zu löschen und die Verarbeitung einzustellen.

Wer hat sich sowas nur ausgedacht....

[holgerscherer]

Wer hat sich sowas nur ausgedacht....

die gleichen Typen, die zulassen, dass alle Daten von den Einwohnermeldeämtern an den Rundfunk-Gebührenservice weiter gegeben werden...

-h

[Fuerchau]

Muss eigentlich nun die Telefonauskunft auch verschlüsselt werden?