Verschluesselung von Produktionsdaten per SQL
- Dieses Thema hat 4 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 13 Jahre von
Anonym.
-
AuthorPosts
-
20. August 2010 um 13:59 Uhr #4092
AnonymInaktivHallo zusammen,
wieder mal möchte ich eure Ideen / Anregungen nutzen, um eine Fragestellung zu diskutieren. Hier die Aufgabe:Von Produktion sollen bestimmte Tabellen entladen werden (vermutlich per DSNTIAUL da SQL möglich).
Diese Daten sollen jetzt auf verschiedenen Testsystemen geladen werden. Alle Produktionsdaten sollen aber so unkenntlich gemacht werden, dass niemand damit etwas anfangen kann. Schlüsselfelder können glücklicherweise unverändert bleiben.
Idee:
3 DB2-Funktionen definieren:
F#RND1 ==> setzt CHAR-Felder
F#RND2 ==> setzt Numerische Daten in CHAR-Feldern um
F#RND3 ==> setzt Date-Felder um; BesonderheitMinderjährige müssen minderjährig bleiben und Volljährige müssen volljährig sein.
In die obigen Funktionen könnte zum Beispiel das Datum (alle DSNTIAUL-Jobs laufen an einem Tag; oder die Länge des zu verschlüsselnden Feldes einlaufen length(strip(FELD1)) ).
Wichtig ist außerdem das die Funktion nicht per Zufallsfunktionen aufbaut, da sonst gleiche redundante Daten unterschiedliche verschlüsselte Werte ergeben würden.Die obigen 3 Funktionen werden auf alle "sensiblen Columns" beim Auslesen per DSNTIAUL angewendet.
Die entstandenen sequentiellen Entladebestände SYSREC00 bis SYSREC99 enthalten nur noch verschlüsselte Daten.
Diese Daten werden von Produktion auf Test übertragen und dort geladen.
Mir ist klar, dass dies nicht "unknackbar" ist, aber mit ein wenig Geschick lassen sich diese Funktionen doch schon ganz sicher machen?
Was haltet ihr davon?
Sicher/ Unsicher?
Was kann man besser machen?
Hattet ihr vergleichbare Situation und welche Lösungen habt ihr verwendet?Gruß Klaus
Hier mal der Entwurf für Funktion F#RND1:
CREATE FUNCTION DBSI.F#RND1
    (INPUTVAR VARCHAR(4000)
    ,UMSETZVAR VARCHAR(4000)
    )
 RETURNS  VARCHAR(4000)
 CONTAINS SQL
 NO EXTERNAL ACTION
 RETURN
     TRANSLATE(
            INPUTVAR
    , SUBSTR (          STRIP(UMSETZVAR)!!
          ‚ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz‘
          , 1 , 52
          )
        , ‚ZYZWVUzSRzPOzyTwvZtzrqpznmZkjzhgfUdcbaAZZDEFGZIJKZMN‘
          )
;Macht aus Klaus Rottenbacher ==> elTus toAAeGSTRMeC
Macht aus Rottenbacher      ==> coGGeMYZXSeIUnterschiedlich da erstes Feld 18 Byte (nach Strip) und zweites Feld 12 Byte (nach Strip)
24. August 2010 um 20:19 Uhr #4246
AnonymInaktivHallo Klaus,
bei der geschilderten Situation handelt es sich ja mehr um eine "Umschlüsselung". Zur Verschlüsselung gibt es ja die ENCRYPT-Funktion, mit der die Daten aber ziemlich ‚aufgeblasen‘ werden – nicht wirklch nützlich für die Erzeugung von Testdaten.
Was ich nicht schlecht finde ist eine symmetrische XOR-Verschlüsselung, bei der die Original-Daten mit einem individuellen Schlüssel umgesetzt werden und wieder zurückgeschlüsselt werden könnten.
Problem: DB2 kennt weder die XOR-Operation noch die BIT-Funktion oder BIT-Konstante.
Aber: Mit einer DB2 Stored Procedure (External) in Java oder REXX geschrieben sollte die Um- oder Verschlüsselung machbar sein. Dabei kommt der SYSADM ins Spiel, der die Started Task für den WLM Application Space um die REXX- oder Java- (USS) Library erweitern muß.
Ich hab‘ auch schon eine Lösung gesehen, bei der inbesondere (Nach-) Namen und Orte in wiederkehrende Strings ausgetauscht werden. Die Kunden heißen dann alle Meier, Mayer, Müller, Schmidt, Schmitt etc pp. …
Wer es etwas bequemer mag: Von IBM gibts das Cloning Tool für solche Zwecke. Eine zusammenfassende Dokumentation findet Ihr im Anhang. (Nur in der Thread-Anzeige, nicht in der Übersicht!)
Grüße
Gernot25. August 2010 um 5:59 Uhr #4360
AnonymGastHallo,
UBS Hainer liefert ein Werkzeug zum Kopieren von DB2-Tabellen und DB2-Datenbanken. Es kann sogar im laufenden Betrieb aus Produktionsumgebungen selektieren und in bestehende Testumgebungen kopieren. Die Quelle muss also nicht unbedingt gestoppt werden. Auch sehr nützlich: Man kann ebenso eine ImageCopy als Quelle nutzen. Dazugehörige Objekte können bei der Kopie berücksichtigt werden. Datenreduktion und Anonymisierung und/oder Pseudonymisierung sind ebenso möglich. Schau doch mal hier: http://www.ubs-hainer.com
Viele Grüße
Jan
27. August 2010 um 6:52 Uhr #4442
AnonymInaktivErst mal vielen Dank für die Anregungen.
Gernot, wäre es auch möglich die Umschlüsselung in eine DB2-function zu packen? Dann stelle ich es mir einfacher vor per DSNTIAUL zu entladen und jeden Column, der umgeschlüsselt werden soll einfach der DB2-Function zu übergeben?
Zurückschlüsselung ist für uns allerdings nicht wichtig.
Wir möchten gerne einen möglichst hohe Vielfalt an Namen / Werten behalten.Nur noch Müllers/Mayer/Schmitts etc. ist für unsere anschließenden Tests zu wenig!
Oder ist auch die einfache Nutzung einer stored procedure im DSNTIAUL möglich?Gruß Klaus
6. September 2010 um 19:03 Uhr #4487
AnonymInaktivHallo Klaus,
da eine DB2 z/OS UDF nicht viel Spielraum läßt, müßte die etwas komplexere Logik in eine Stored Procedure ausgelagert werden.
Mit SQL PL in Stored Proc’s ohne Aufruf eines externen Programms ist das zu bewerkstelligen. Das Problem ist jetzt nur noch, dass die gewünschte Function die StoProc (2 Argumente: 1xInput, 1xOutput) aufrufen müßte – ich weiß bloß [noch] nicht wie.
Gruß
Gernot
-
AuthorPosts
You must be logged in to reply to this topic.