[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Oct 2015
    Beiträge
    109

    Question SQL encryption

    Hallo zusammen,

    ich verschlüssel zwei Felder einer Datei mit
    set encryption password = password;


    Im Anschluss schreibe ich sie mit encrypt weg.
    Damit ich sie immer enspannt lesen kann, ohne ständig zu casten und zu decrypten,
    habe ich dafür eine View erstellt.
    Soweit funktioniert es.

    Jetzt habe ich ein Programm zum Setzen des Passworts erstellt.
    Mit actgrp(*caller) kann ich jetzt innerhalb dieses Programmes den Befehl zum
    PW setzen absetzen und im Hauptprogramm die VIEW lesen.

    Das Ganze hätte ich gern auch für strsql bzw andere SQL Editoren,
    also schrieb ich ne Procedure die das RPG-Programm zum setzen des Passworts
    aufruft, damit der User das Passwort nicht selbst kennen muss.
    Leider funktioniert es so aber nicht. Das Passwort wird gesetzt,
    die "SQL-Session" registriert dies aber nicht und ich erhalte:
    SQL Errorcode: -20143
    Eine Verschlüsselungs- oder Entschlüsselungsfunktion ist fehlgeschlagen, da für das Verschlüsselungskennwort kein Wert festgelegt war.
    Fehlerbeseitigung: Mit der Anweisung SET ENCRYPTION PASSWORD das Kennwort für die Verschlüsselungs- und Entschlüsselungsfunktionen festlegen.
    Das Kennwort kann auch als Argument für die Verschlüsselungs- und Entschlüsselungsfunktionen angegeben werden.
    In den RPG Programmen selbst habe ich auf *caller geachtet und auf der IBM Seite
    stand, dass sql procedures immer *caller sind.

    Kann mir jemand weiterhelfen?

    edit:
    einfacher beschrieben:

    call PWDSP(current user) --> ruft RPG-Programm welches set encryption password = password;
    ausführt.
    select decrypt_char(meinfeld) from test ---> erkennt nicht, dass das pw gesetzt wurde

    Meine SQL procedure:
    create or replace procedure PWDSP
    (in meininput char(10))
    language rpgle
    not deterministic
    external name PWDSP

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    17.978
    Hast du mal den SQLCODE nach dem Set ausgewertet?
    Laut Doku ist eine Kennwortkonstante in statischem SQL nicht erlaubt. Hierfür ist auf jeden Fall eine Hostvariable erforderlich.
    In dynamischem SQL wiederum geht's.
    Probier das mal aus und gib mal den SQLCODE/SQLSTATE z.B. per DSPLY aus.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Oct 2015
    Beiträge
    109
    Danke für die Idee,

    Du hast Recht, konstant setzen kannst du das nicht.
    Dann lässt sich das Programm nicht einmal wandeln.
    Das mach ich aber auch nicht. ich ermittle innerhalb der Programms anhand der Daten des Benutzers
    ein Passwort.
    Ich hab zur Sicherheit noch mal nachgesehen, aber sqlcode und state sind 0 -> alles super.
    Innerhalb der Programme klappt das ja auch, ein zweites Programm schreibt Sätze in die Datei.
    Bloß interaktiv "zählt" das gesetzte passwort nicht und ich muss den Befehl vor Aufruf meiner View
    manuell setzen.

    Da hab ich auch noch ein weiteres Problem - meine View hat dann ein Problem, falls verschiedene PWs
    innerhalb der gleichen table verwendet wurden. Das ist auch unschön, kann ich aber logisch lösen.

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    17.978
    Da hilft dann nur eine SQL-Function (UDF), die du in der View aufrufst.
    Zusätzllich definierst du eine nicht-globale Sitzungs-Variable für das Kennwort, hier sind alternativ natürlich auch andere Varianten denkbar.
    Die UDF liest das Kennwort, setzt dies per Set Encryption, decrypted den Wert und macht u.U. auch wieder ein Set Encryption zurück. Damit kannst du dann auch die verschiedenen Passwort-Varianten erreichen.
    Sitzungsvariablen halt deshalb, dass nicht irgend jemand anders dann ganz zufällig per ODBC die View ausliest.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Oct 2015
    Beiträge
    109
    Das klingt vielversprechend,
    aber selbst für eine SQL UDF funktioniert es bei mir leider nicht:
    create or replace function mylib.uftest(pw char(8))
    returns char(1)
    language sql
    modifies sql data
    begin
    declare isok char(1);
    set encryption password = pw;
    set isok = 'A';
    return isok;
    end

    select a.*, mylib.uftest('testab') from myview a
    Die Fehlermeldung bleibt identisch:
    Ursache . . . . : Funktion DECRYPT_CHAR kann nicht ausgeführt werden;
    Ursachencode 1. Ursachencodes und ihre Bedeutung:
    1 -- Der Wert für ENCRYPTION PASSWORD ist nicht festgelegt.

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    17.978
    Da hast du mich missverstanden.
    Ggf. gilt das Kennwort nur ab Aufrufebene. M.a.W, wenn die Aufrufebene verlassen wird, ist auch das Kennwort weg. Ggf. kannst du das mal verifizieren in dem dein RPG den Set encryption durchführt und QCMD aufruft. Dann mit STRSQL die View ansehen. Wenn STRSQL und QCMD und somit auch dein RPG dann verlassen wird könnte die View dann wieder verschlüsselt sein.
    Somit könntest du vielleicht auch eine Tablefunction schreiben, die das Kennwort setzt und einen Cursor mit dem Decrypt zurückgibt.
    Leider finde ich in der Doku nichts über die Gültigkeitsdauer des Set Encryption.

    Ansonsten:
    - du definierst eine SQL-Variable (create variable)
    - Per Funktion/Aufruf o.ä. führst du "Set Variable = Password" aus
    - die UDF hat einen Parameter, z.b. Varchar(256) und Return Varchar(256) führt den Set Encryption und den Decrypt aus: set encryption = Variable; return decrypt(Parameter);

    Wenn die Variable nicht Global ist gilt sie nur für den Job.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •