View Full Version : DSGVO Daten verschlüsseln
Wir wollen, wegen der DSGVO, unsere Datenbank auf der iSeries verschlüsseln.
Google hilft mir nicht.
Unsere URALT RPG Pgmme sollen die verschlüsselten Daten 'vollautomatisch' entschlüsseln. Aber wenn ein böser Bube mit ODBC/JDBC ect. auf die Daten zugreift soll er nur Kauderwelsch bekommen.
Das das SO mit Schnipp nicht geht, ist klar.
Aber ich finde im Netz nicht mal, ob ich die DB2/400 vom OS/400 verschlüsseln kann!
Alle links und Kommentare sind Willkommen.
Der ILEMax
PS:Die Anfrage ist einigermaßen ernst, es ist KEINE Satire
https://www-356.ibm.com/partnerworld/wps/servlet/download/DownloadServlet?id=4E$V_2UMH5yiPCA$cnt&attachmentName=protecting_ibm_i_data_with_encrypti on.pdf&token=MTUyMzQ1MTI0NjU0Mw==&locale=en_ALL_ZZ
... da gibt es SQL Functions ENCRYPTxxx, DECRYPTxxx und das Lizenzprodukt für die Verschlüsselung wird gebraucht - gibt es aber außerhalb TrumpLand nur mit NSA Backdoor
D*B
Danke Euch beiden,
hört sich aber so an, als müssten wir den RLA zugriff komplett rausprogrammieren.
Oder nach dem Setll read den Satz an SQL Programme (Funktionen geht nicht, URalt RPG) übergeben.
und vor dem Update/Write auch ...
Das 'mal eben' bei rd 900 Pgmmen, ...
Toll!
Wer zu spät modernisiert den bestraft das Leben ...
Danke
Der ILEMax
... ohne nicht unerheblichen Aufwand geht da wohl nix. Mit den Funktionen (oder den ebenfalls verfügbaren APIs) ist es ja nicht getan, da müssen auch noch alle Daten migriert werden. Das sollte man zuerst mal längs der konkreten Anforderungen evaluieren, was da am besten wäre. Die Änderungen an den RPG Schinken könnte man eventuell über OA Handler minimieren, mit entsprechendem Aufwand für die Handler und anpacken muss man alle betroffenen Programme in jedem Fall.
D*B
KingofKning
11-04-18, 14:36
Tja, wenn Du den bösen Buben schon mal spezifizieren kannst, kannst Du ihn auch aussperren. Es gibt ja Produkte die jeden ODBC-Zugriff limitieren können.
Vielleicht hilfrt ein wenig nachdenken den günstigsten Weg zu finden bevor man sich zuviel Arbeit macht.
GG 4434
Tja, wenn Du den bösen Buben schon mal spezifizieren kannst, kannst Du ihn auch aussperren. Es gibt ja Produkte die jeden ODBC-Zugriff limitieren können.
Vielleicht hilfrt ein wenig nachdenken den günstigsten Weg zu finden bevor man sich zuviel Arbeit macht.
GG 4434
... damit wirst Du in Bezug auf DSGVO keinen Blumentopf gewinnen, nicht mal einen Trostpreis.
D*B
... falls ihr wenigstens einigermaßen aktuell seid (V7Rx), könnte FIELDPROC noch was hergeben, müsste aber vorab juristisch und technisch evaluiert werden.
D*B
Danke, schau ich mir an ...
@alle
Seid Ihr alle so 'Modern' das Euch das nicht betrifft?
Oder ignoriert Ihr diese Anforderung aus der DSGVO?
Oder sogar die ganze DSGVO?
der ILEMax
https://www.security-insider.de/9-dsgvo-mythen-enttarnt-a-673986/
Siehe vor allem auf Punkt 9
Wichtig ist hier insbesonders die Aussage:
"Ob eine Verschlüsselung zum Einsatz kommen soll oder nicht, hängt somit von dem zu ermittelnden Schutzbedarf der Daten, dem Risiko für die Betroffenen sowie weiteren Faktoren ab wie Stand der Technik, Implementierungskosten und Art, Umfang, Umstände und Zwecke der Verarbeitung. Verschlüsselung ist also kein Automatismus, sondern eine wichtige Maßnahmen bei entsprechendem Bedarf an Schutz für die Vertraulichkeit der Daten."
Wenn die Datenbank also keine Verschlüsselung hergibt, ist es auch nicht erforderlich. Man muss da halt andere Schutzmaßnahmen treffen.
Mit SQL kann man ab V7R2 oder R3 eine Anonymisierung / Maskierung von Daten vornehmen.
D.h., dass insbesonders bei SQL-/ODBC-Zugriffen sicherheitsrelevante Informationen verfälscht werden.
Zusätzlich konnte man ja vorher schon mit Berechtigungen und Views den Zugriff auf Daten beschränken.
Birgitta hatte dazu in der letzten Midrange einen Beitrag geschrieben (da wurde das Geburtsjahr einer Person z.B. durch 9999 ersetzt).
Wichtig dabei scheint wohl, dass erstmalig auch ein *ALLOBJ-User dann nicht mehr an alles drankommt.
Ob und wie dies auf RLA wirkt, kann ich nicht sagen, da SQL eigentlich erst hinter RLA beginnt.
Allerdings ist der RLA-Zugriff per ODBC (ja, das geht) oder Java-/Toolkit von außen eher selten.
Die Gefahr allerdings ist dabei, dass ich falsche Informationen lese und wenn es in der laufenden Verarbeitung passiert damit dann rechne und ggf. in andere Dateien fortschreibe.
Es ist also organisatorisch nicht ganz so einfach, wie uns die IBM das glauben macht.