Comprendre et apppliquer le cryptage DB2 UDB

par Kent Milligan Mis en ligne le 01/O3/2006 - Publié en Juillet 2005

Les stratégies de confidentialité des données et les usurpations d’identité ont accentué la prise de conscience de la sécurité tant dans nos services de technologies de l’information que dans nos foyers. Cette sensibilisation oblige les programmeurs et administrateurs iSeries à élaborer de nouvelles méthodes de protection pour le contenu sensibles des bases de données DB2 UDB for iSeries. La V5R3 propose de nouveaux moyens de protection des données, grâce aux fonctions de cryptage et de décryptage DB2.
Mais avant de nous intéresser aux nouvelles méthodes de protection des données, ne négligeons surtout pas la première ligne de protection des données DB2: la sécurité au niveau objet. Les services de sécurité au niveau objet i5/OS jouent un rôle de premier plan dans la protection des données DB2, indépendamment de l’interface d’accès. Dès lors que l’utilisateur final demande davantage d’interfaces d’accès, les sites iSeries ne peuvent plus se contenter de la sécurité basée sur menus, pour contrôler l’accès aux données sensibles. La sécurité au niveau objet empêche tout utilisateur non autorisé d’accéder aux données sensibles (comme les rémunérations) pour les supprimer ou les modifier.Le cryptage des données est une méthode de sécurité qui érige une autre ligne de protection autour des colonnes DB2 contenant des données sensibles. Ce niveau de sécurité supplémentaire s’impose parce que la sécurité au niveau objet ne saurait empêcher des utilisateurs autorisés comme les servant du help desk, de visualiser des données sensibles, ni empêcher un pirate de lire ces mêmes données, au moyen de références (ID et mot de passe) volées à un utilisateur autorisé. Si des données sensibles comme un numéro de carte de crédit sont stockées sous forme cryptée, tous les utilisateurs recevront toujours, par défaut, une chaîne binaire de données cryptées. Pour lire en clair le numéro de la carte de crédit, l’utilisateur devra remplir deux conditions : être autorisé à accéder à l’objet DB2 et connaître le mot de passe de cryptage et la fonction de décryptage.
A l’aide d’un exemple, voyons comment on pourrait utiliser la nouvelle fonction de cryptage et de décryptage DB2 dans ce scénario, pour fournir un degré de sécurité supplémentaire.

SET ENCRYPTION PASSWORD
INSERT IN INTO customer
VALUES('JOSHUA', ENCRYPT('1111222233334444'))

SET ENCRYPTION PASSWORD
SELECT name, DECRYPT_CHAR(card_nbr)
FROM customer

Ici, l’instruction Set Encryption Password fournit à DB2 la clé qui servira pour crypter les données et pour les décrypter. L’instruction suivante montre comment la fonction de cryptage DB2 sert à coder le numéro de carte de crédit sensible avant de l’écrire dans la table DB2. La dernière instruction montre les étapes nécessaires pour visualiser la valeur originale du numéro de carte de crédit '1111222233334444'. En premier lieu, la clé de cryptage doit être mise à la même valeur que celle qui a servi à crypter le numéro. Ensuite, il faut utiliser l’une des fonctions de décryptage pour convertir la valeur cryptée binaire en valeur caractère initiale.
Dans cet exemple, on remarquera tout particulièrement l’absence de mots-clés SQL ou DDS ordonnant à DB2 UDB de crypter et de décrypter automatiquement les données. Des changements d’application sont donc nécessaires. La raison en est que le cryptage et le décryptage automatiques ne fournissent pas un degré de sécurité supplémentaire. Si DB2 décrypte le numéro de carte de crédit pour tous les utilisateurs qui lisent la table Customer, alors le numéro de carte de crédit sera aussi visible aux yeux des utilisateurs que s’il n’y avait pas de cryptage. On ne peut tirer parti du cryptage qu’en changeant les applications et les interfaces de manière à décrypter sélectivement les données pour un sous-groupe d’utilisateurs autorisés. DB2 apporte une valeur ajoutée en la matière : ces nouvelles fonctions facilitent le cryptage et le décryptage. Les applications se contentent d’invoquer une fonction SQL simple au lieu de coder des appels adressés à des API et des services de cryptographie complexes.