> Tech > Interfaces natives et cryptage DB2

Interfaces natives et cryptage DB2

Tech - Par iTPro - Publié le 24 juin 2010
email

Les applications qui utilisent l’interface native (non SQL) peuvent aussi bénéficier des nouveautés de DB2. Il faudra bien sûr utiliser un peu de SQL, mais sans aller jusqu’à réécrire les applications pour utiliser SQL. Les utilisateurs natifs doivent bien comprendre que la table sous-jacente qui contiendra les données cryptées n’a

pas à être créée avec SQL. Il suffit que la colonne cryptée satisfasse aux exigences évoquées précédemment.
Les déclencheurs de base de données sont un excellent moyen pour offrir des services de cryptage sans changer toutes vos applications pour l’utilisation de SQL. Vous pouvez définir les triggers Before Insert et Update pour intercepter les requêtes d’écriture adressées à votre base de données, puis crypter les données d’éventuelles colonnes sensibles, avant de les confier au moteur DB2. Ce mode d’utilisation du déclencheur signifie que le seul programme qui devra utiliser SQL pour invoquer la fonction ENCRYPT_ RC2 sera le programme déclencheur. On peut utiliser indifféremment des déclencheurs SQL et externes.
L’exemple suivant utilise les déclencheurs SQL pour crypter des numéros de sécurité sociale insérés dans la table employee :
CREATE TRIGGER protect_ssnumber
BEFORE INSERT ON emp
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
DECLARE encrypt_key VARCHAR(127);
SET encrypt_key = get_passwordUDF( ‘EMP’);
SET n.socialSecurity = ENCRYPT_RC2( n.socialSecurity, encrypt_key);
END
Toute écriture native (ou SQL Insert) dans la table employee aura pour effet d’invoquer ce déclencheur Before Insert. Ensuite, le déclencheur SQL protect_id appelle d’abord la fonction définie par l’utilisateur get_password- UDF() pour obtenir le mot de passe de cryptage pour la table employee. Ce mot de passe est ensuite utilisé pour crypter le numéro de sécurité sociale dans l’image d’enregistrement avant que DB2 UDB l’utilise pour générer une nouvelle ligne dans la table employee.
Les vues SQL sont probablement la méthode la plus courante pour permettre aux programmes natifs de lire la version décryptée de données sensibles. Voici un exemple de vue que l’on pourrait utiliser de cette manière :
CREATE VIEW my_logins( System, login, passwd) AS
SELECT system,login,char( decrypt_char(passwd),6)
FROM regusers WHERE userid=USER

La vue SQL my_logins peut ensuite être ouverte comme un fichier logique par le programme natif, et la fonction decrypt column contenue dans la vue SQL permettra de renvoyer au programme natif la version non cryptée des données de la colonne. Le décryptage n’aura lieu que si le programme natif a défini la clé de cryptage appropriée – soit directement en exécutant l’instruction Set Encryption Password SQL, soit indirectement en appelant un autre programme. Comme les colonnes cryptées sont plus longues, les programmes natifs devront soit décrypter les données, soit être modifiés pour traiter la plus grande longueur de colonne quand les données cryptées seront renvoyées.

Téléchargez gratuitement cette ressource

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

HP Elite Slice G2 : optimisez la collaboration… et votre budget !

Téléchargez cette étude Forrester et découvrez comment booster la collaboration tout en dégageant un excellent R.O.I grâce au système de vidéoconférence HP Elite Slice G2 avec Microsoft Teams !

Tech - Par iTPro - Publié le 24 juin 2010