View Full Version : DSGVO Daten verschlüsseln
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
... wie bisher auch: wir haben den sichersten Rechner der Welt, vertrauen auf unseren Menüschutz, in unseren Daten kennen wir uns selber kaum aus, unsere Programme sind so alt, dass sie keiner mehr versteht und außerdem stellen wir sowieso bald auf SAP um...
D*B
RobertMack
13-04-18, 09:30
Aber ich finde im Netz nicht mal, ob ich die DB2/400 vom OS/400 verschlüsseln kann!
Muss es denn gleich die ganze Datenbank sein? Man kann auch einzelne Felder verschlüsseln...
Szenario:
1) Installation eines Verschlüsselungs-API irgendwo in Eurem Netzwerk
2) Auswahl der relevanten Felder in Euren Dateien (z.B. Bankverbindungen, persönliche Daten)
3) Identifizierung der betroffenen Programme
4) Vorgehensweise: an den Stellen an denen Ihr z.B. ein Datum von PF nach DSPF und zurück dreht, erfolgt ein Aufruf (https aus RPGLE!) der die gewünschten Felder ver- oder entschlüsselt)
5) Clou: der verschlüsselte String entspricht in seiner Länge immer dem Original!
https://www.voltage.com/
Mit der IBM gehts auch:
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/catcrypt.htm
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qc3Scenario.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.
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!
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.
... 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/knowledgecenter/ssw_i5_54/apis/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.
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.
Nur zur Info für die Österreicher... es wurde alles heißer gekocht als dann gegessen :
https://derstandard.at/2000078602336/DSGVO-Oesterreich-verwaessert-europaeischen-Datenschutz
The austrian way of life :-D
greets
holgerscherer
30-04-18, 14:53
... 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
... 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-info.de/personenbezogene-daten-definition-und-praktische-beispiele/