FIELDPROC , Cryptage de colonne sous DB2.
La version 7 de DB2 propose une nouvelle fonctionnalité permettant de crypter le contenu d'une colonne par le nouveau mot-clé FIELDPROC ajouté aux ordres SQL CREATE TABLE et ALTER TABLE
Create table fieldtable (cle integer , zone char(200) FIELDPROC fieldproc1) |
sous System i navigator :

ACS

La zone cryptée ne peut pas être :
- une zone de type ROWID
- une zone numérique avec l'attribut AS IDENTITY
- une zone de type TIMESTAMP avec AS ROW CHANGE TIMESTAMP
- un DATALINK
- une zone avec comme valeur par défaut CURRENT DATE/TIME/TIMESTAMP, USER
Programmation :
- la procédure doit être de type PGM/ILE (pas de GAPIII, de java, de programme de service)
- l'algorithme doit être réversible
(si la chaîne 'ABCDEF' est transformée en '123456', '123456' doit produire 'ABCDEF')
- on peut définir des paramètres à envoyer à la procédure, ils sont transmis à chaque appel
- la procédure est appelée lors de la création, pour :
- valider le type de zone (elle peut refuser de travailler avec des zones numériques, par ex.)
- indiquer le type de zone à stocker :
- l'utilisateur saisi du caractère, on stocke du binaire
- lors de la lecture le binaire est transformé à nouveau en caractère
- la procédure est appelée ensuite lors des affectations afin de crypter la donnée, lors des lectures afin de la décrypter
(Ordres SQL ou Entrées/sorties natives)
- Elle peut décrypter la donnée suivant des conditions, et c'est là que c'est intéressant.(l'utilisateur appartient à la DRH ou pas, par ex.)
- Paramètres :
- une zone fonction indiquant le contexte
8 = appel lors de la création
0 = appel pour crypter
4 = appel pour décrypter
- une structure décrivant les paramètres
- une structure décrivant la valeur en clair
- valeur à utiliser pour le cryptage si fonction=0
- valeur à produire si fonction=4
- la valeur en clair
- une structure décrivant la valeur cryptée
- valeur à produire si fonction=0
- valeur à utiliser si fonction=4
- la valeur cryptée
- SQLCODE (doit commencer par 38, si erreur, 00000 dans le cas contraire)
- message complémentaire si SQLCODE <> '00000'
Exemple avec un pgm qui inverse les bits (fonction RPG %BITNOT) sur une zone CHAR
et ne décrypte que si c'est QSECOFR qui lit.
(pour les structures, voir le code complet fourni en exemple)
/free select; when fonction = 8; // création // le type retourné est le même, donc copie de la définition encoded_attr= decoded_attr; when fonction = 0; // INSERT => encodage lg = decoded_attr.sqlfpLength; transforme(decoded_Data : encoded_Data : lg); when fonction = 4 ; // SELECT => decodage lg = encoded_attr.sqlfpLength; if profil = 'QSECOFR'; transforme(encoded_Data : decoded_Data : lg); else; %subst(decoded_Data:1:lg) = %subst(encoded_Data:1:lg); endif; other ; SQLSTATE = '38001'; message = 'demande inconnue'; ENDSL; *inlr = *on; /end-free * procédure de codage, inverse tous les bits,x'00 devient x'FF', etc ... * (algorithme trop simple pour utiliser en production) Ptransforme B D PI D data1 32767 D data2 32767 D lg 5I 0 D i S 5I 0 /free for i = 1 to lg; // la doc déconseille de crypter les espaces if %subst(data1 : i : 1) = ' '; %subst(data2:i:1) = %subst(data1:i:1); else; %subst(data2:i:1) = %bitnot(%subst(data1:i:1)); endif; ENDFOR; /end-free ptransforme E |
puis
Insert into fieldtable values (1 , 'coucou')
Insert into fieldtable values (2 , 'autre test') |
SELECT * FROM FIELDTABLE, sous QSECOFR

Sous un autre profil
(ici, avec System i navigator)
Quelques remarques
- La documentation vous déconseille de crypter le caractère espace
en effet quand vous comparez à la zone, une constante plus courte, le système complète l'information la plus petite par des espaces.
si les espaces de la zone sont cryptés, du coup la donnée sera considérée comme différente de la constante alors qu'en réalité ce n'est pas le cas.
- les tris peuvent être perturbés sur une zone cryptée :
ex SELECT *FROM FIELDTABLE ORDER BY ZONE
-> sous QSECOFR
(la zone est décryptée)
-> sous un autre profil
(la zone reste cryptée)
- lors d'un CPYF la procédure sera appelée (même sur DSPPFM), ainsi que lors d'un CREATE TABLE AS (SELECT ...)
- une option de QAQQINI destinée à l'optimiseur, indique si la zone doit être décryptée systématiquement :
FIELDPROC_ENCODED_COMPARISON :
- *ALLOW_EQUAL (dft)
on crypte les constantes comparées plutôt que de décrypter la valeur du fichier, pour les comparaisons, GROUP BY et DISTINCT.
la fonction doit être déterministe (retourner toujours le même résultat pour la même valeur) et les valeur retournées peuvent ne pas être triées
- ALLOW_RANGE
on crypte les constantes comparées plutôt que de décrypter la valeur du fichier, comme ALLOW_EQUAL, mais aussi pour MIN, MAX et ORDER BY
la fonction doit être déterministe et les valeur retournées doivent être triées (significatives pour un tri)
- *ALL
la procédure est appelée le moins souvent possible (on crypte les constantes comme ALLOW_RANGE)
pour toutes les opérations y compris LIKE
- *NONE
la procédure de cryptage est appelée systématiquement et on travaille avec les valeurs en clair.
CQE travaille toujours de cette manière, quelque soit la valeur dans QAQQINI.