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.
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.
Téléchargez cette ressource
Livre blanc Sécurité et Stockage des documents
Découvrez dans ce livre blanc Kyocera les outils logiciels qui permettent une approche holistique et efficace de la collecte, du stockage, de la gestion et de la sécurisation des documents en entreprise.
