Comprendre et apppliquer le cryptage DB2 UDB

Après avoir expliqué la nouvelle aide au cryptage, voyons les étapes nécessaires à cette opération. Tout d’abord, il faut installer sur le serveur un produit gratuit supplémentaire. Les fonctions colonne de cryptage et de décryptage de DB2 UDB utilisent en fait les algorithmes de cryptage intégrés dans le produit IBM Cryptographic Access Provider 128-bit pour iSeries (5722-AC3). Les IBM Cryptographic Coprocessor and Accelerator ne sont pas nécessaires et ne procurent aucun avantage aux algorithmes de cryptage de DB2 UDB.
La dernière étape de la préparation consiste à identifier les colonnes qui ont besoin d’être cryptées. Le cryptage des données entraîne le changement du type de données et de la longueur des définitions de colonnes existantes. Le type de données doit être changé parce qu’une valeur cryptée est une chaîne binaire qui ne peut être stockée que dans une colonne définie avec l’un des types de données SQL suivants :

• BINARY
• VARBINARY
• CHAR FOR
• VARCHAR
• BLOB

Si la table DB2 UDB cible est définie avec DDS, la colonne cible doit être définie comme un champ caractère de longueur fixe ou variable avec une valeur CCSID de 65535.
Il faut augmenter la longueur d’une colonne existante à cause de quelques octets d’overhead nécessaires pour la valeur cryptée. Il faudra aussi accroître la longueur si un indice de mot de passe est stocké avec la valeur cryptée. (Je reviendrai sur les indices de mots de passe dans un moment.)
La longueur réelle d’une valeur de chaîne cryptée est la longueur de la chaîne plus n octets. N est défini de la manière suivante :

• Si un indice n’est pas spécifié, n est 8 octets (ou 6 octets si la chaîne d’entrée est un LOB, BINARY ou VARBINARY ou si la chaîne d’entrée et le mot de passe sont des valeurs CCSID différentes) plus le nombre d’octets jusqu’à la limite de 8 octets suivante.
• Si un indice est spécifié, n est 8 octets (16 octets si la chaîne d’entrée est un LOB, BINARY ou VARBINARY ou si la chaîne d’entrée et le mot de passe ont des valeurs CCSID différentes) plus le nombre d’octets jusqu’à la limite de 8 octets suivante plus 32 octets pour la longueur de l’indice.

Différentes valeurs CCSID peuvent résulter du fait que la chaîne mot de passe se voit attribuer le CCSID utilisé par le job, et que la valeur cryptée se voit attribuer le CCSID du type de données résultat.
Les quelques exemples suivants permettent de mieux comprendre l’aspect longueur :
Un numéro de carte de crédit de 16 chiffres qui sera stocké dans une colonne VARBINARY avec un indice, demandera une longueur de colonne de 32 octets : 16 octets pour les données non cryptées + 16 octets supplémentaires + 0 octet supplémentaire (nous sommes déjà à une limite de 8 octets).
Un numéro de sécurité sociale américain de 9 chiffres qui sera stocké dans une colonne VARCHAR FOR BIT DATA avec un indice demandera une longueur de colonne de 56 octets : 9 octets pour les données non cryptées + 8 octets supplémentaires + 7 octets supplémentaires (pour atteindre la limite de 8 octets suivante) + 32 octets pour l’indice.
Outre la réduction du nombre de changements de définitions des colonnes, l’overhead de performance est une autre raison pour ne crypter qu’un petit sous-ensemble de colonnes. Ainsi, si vous renforcez la sécurité de l’immeuble de bureaux en ajoutant un lecteur de badges à la porte d’entrée, il vous faudra un peu plus de temps pour aller à votre bureau chaque matin. De la même manière, en ajoutant le cryptage et le décryptage à votre application, vous ralentirez l’accès à la base de données. La figure 1 montre le résultat d’un test de comparaison simple effectué en laboratoire avec une table à seule colonne.