Les différents facteurs du processus de cryptage

1.    Quels champs faut-il crypter ? La réponse est moins évidente qu’il n’y paraît. Certes, tous les champs de cartes de crédit ne sont pas concernés, mais il peut être difficile de savoir où ils se trouvent. Ils pourraient, par exemple, être imbriqués dans un champ d’une autre nature. Il existe des utilitaires tiers qui analysent une base de données à la recherche de chaînes « suspectes », du genre numéros de carte de crédit ou de carte d’identité. Ces utilitaires peuvent être adaptés pour trouver d’autres chaînes, selon les besoins ou la volonté du programmeur.

2.    Les données sensibles ne se trouvent pas seulement dans un environnement de production. Les mêmes peuvent être présentes dans d’autres contextes, comme le développement, le test, ou d’autres partitions logiques entières. Des utilitaires peuvent empêcher ce genre de situation en copiant les données de production et en les dépersonnalisant pour le test de développement applicatif.

3.    Le texte chiffré est constitué de caractères. Si vous envisagez de le stocker dans les champs de texte en clair original, et si le champ de texte en clair est numérique, il faut d’abord le convertir en alphanumérique.

4.    Le texte chiffré résultant sera-t-il trop grand pour être stocké physiquement dans le champ source ? Avec beaucoup de chiffrements par blocs, la taille des blocs d’entrée peut être différente de la taille des blocs de sortie, et il est possible que le texte chiffré soit plus grand que le texte en clair original, surtout si ce dernier est court. Par exemple, avec un champ de carte de crédit, la longueur des données renvoyées sera d’au moins 16 ou 24 caractères, puisque la plupart des cartes de crédit comportent entre 12 et 16 caractères, et ces données seront binaires contrairement au système base-10 utilisé dans le numéro de carte.

5.    Faut-il écrire directement l’algorithme de cryptage dans l’application principale, ou instaurer des déclencheurs au niveau des champs de la base de données ou bien encore coder et encapsuler les algorithmes dans un programme de service ?

6.    Comment les données doivent-elles être cryptées ? Plus précisément, devriez-vous coder des API ou mettre en oeuvre des déclencheurs de base de données ? Les API seraient appelées à partir de l’application ; les déclencheurs seraient placés « en dessous » de l’application. Si vous ne contrôlez pas entièrement le contenu des fichiers, optez plutôt pour un déclencheur parce qu’il sera toujours activé et les données seront cryptées, que ce soit à partir de l’application ou non.

7.    Les données cryptées doivent-elles être stockées dans un fichier externe ? C’est une méthode très répandue qui permet de gérer les clés de manière plus souple. Dans ce scénario, quand les données sont initialement « traduites » (cryptées), la valeur du champ source originale est remplacée par une valeur équivalente séquentielle ou aléatoire : un procédé appelé « jetonisation ». La valeur du jeton sera la clé d’index vers le fichier externe. Ce fichier externe pourrait aussi contenir une date/tampon horodateur de la dernière utilisation du champ, un ID utilisateur, un nom de programme, etc. Toute information pertinente sur l’application qui peut être capturée sera utile pendant un audit de sécurité et aussi pour le débogage. Comme le jeton a les mêmes attributs de données que les données originales (par exemple, aux yeux de l’application, un jeton de carte de crédit ressemble à un numéro de carte de crédit), la jetonisation peut diminuer les changements apportés à l’ancien code d’application.

8.    Gestion du changement : est-ce qu’un journal sera attaché au fichier pour suivre les changements ?

9.    Quel volume de cryptage/décryptage aura lieu pendant la journée ? Ces algorithmes de cryptage sollicitent beaucoup la CPU (bien que AES, Advanced Encryption Standard traite ce problème) et quand on traite énormément de champs ou de fichiers consécutifs, les performances risquent de se dégrader. Sur les systèmes IBM i, un coprocesseur cryptographique a pour mission de délester la CPU des tâches de cryptage, ce qui augmente nettement le nombre d’opérations de cryptage dans un temps donné. Quand il code à un niveau bas en utilisant des API, comme l’API de données de cryptage QC3ENCDT, le programmeur peut choisir l’endroit où le cryptage aura lieu. Il peut alors décider qui effectuera l’algorithme de cryptage : la CPU système ou un coprocesseur de cryptage. L’API fournit aussi une valeur d’après laquelle le système déterminera, à l’exécution, la ressource la mieux à même d’effectuer l’algorithme.

10.    Comment le cryptage des données sera-t-il mis en œuvre ? Une stratégie de repli doit être en place au moment du lancement réel pour éviter un arrêt intempestif de la production. Et cette décision doit pouvoir être prise à la volée sans être obligé d’arrêter l’application. Pour cela, une méthode consiste à garder dans le fichier les données cryptées et les données en clair pendant une période d’essai. Une zone de contrôle des enregistrements ou des données utilisateur (c’est-à-dire un objet défini dont le contenu peut être changé immédiatement) est vérifiée à chaque appel de décryptage. Si la valeur est vraie (true), effectuez le décryptage et renvoyez la valeur. Si la valeur est fausse (false), renvoyez simplement les données en clair.

11.    Combien de temps prendra le cryptage initial de la base de données existante ? Très longtemps s’il s’agit de millions de champs ou d’enregistrements. Procédez d’abord à un test avec un sous-ensemble de la base de données pour prévoir le temps d’immobilisation nécessaire à cette tâche. Éventuellement, divisez ce travail pour réduire ce bloc de temps. Par exemple, vous pouvez fragmenter un fichier puis rassembler ces fragments une fois le cryptage effectué. Autre technique : traiter un fichier énorme par le numéro d’enregistrement relatif. Par cette méthode, le fichier reste une seule unité dont vous traitez différentes sections simultanément.

12.    S’il y a des fichiers de transactions historiques contenant des données sensibles, il faut aussi les crypter.