Stockage des clés et contrôle d’accès

les pratiques suivantes : utiliser les API de gestion des clés intégrées et créer votre propre système de gestion des clés ; utiliser une carte de cryptage matérielle qui fournit la gestion des clés ; installer une appliance de gestion des clés (un équipement séparé qui stocke et sert les clés en toute sécurité), ou le produit d’un fournisseur dans lequel la gestion des clés est déjà intégrée. La principale caractéristique d’un système de gestion des clés s’énonce ainsi : les clés sont séparées des données qu’elles cryptent et elles sont stockées en lieu sûr.

Contrôle d’accès. Pour que le cryptage des données apporte un plus en matière de sécurité, il faut de bons contrôles d’accès aux éléments suivants : le dispositif de stockage des clés lui-même (s’il s’agit d’une implémentation logicielle, cela signifie que la sécurité au niveau objet a été mise en oeuvre), le mécanisme qui extrait la clé et les routines de cryptage (plus particulièrement celles de décryptage). (Pour plus d’informations sur la sécurité au niveau objet, voir l’article « Protection des données DB2 : le facultatif et l’essentiel »). Si le premier venu a accès à la clé, à quoi sert le cryptage ? En outre, si vous avez un système de gestion des clés de type logiciel, il est probable que tout détenteur de *ALLOBJ pourra extraire la clé de cryptage. En effet, les utilisateurs munis de l’autorité spéciale *ALLOBJ peuvent accéder à tout objet présent sur le système. (C’est pourquoi il est bon de pratiquer le hachurage chaque fois qu’on n’a pas besoin des données de clés en texte clair.) Le mieux que vous puissiez faire pour contrarier l’extraction par des utilisateurs *ALLOBJ est de dresser un ou plusieurs obstacles sur le chemin afin qu’il soit plus difficile d’extraire la clé de cryptage et d’accéder aux routines de décryptage.

L’un de ces obstacles consiste à vérifier le processus pour voir s’il utilise *ALLOBJ et, si oui, rejeter la demande d’extraction ou de décryptage. Un autre consiste à vérifier le programme appelant la routine de décryptage et à ne décrypter que si le programme appelant figure dans une liste agréée. Mais sachez que si votre entreprise est amenée à restreindre l’accès aux clés de la part des utilisateurs *ALLOBJ, vous devrez probablement mettre en oeuvre un certain type de système de gestion des clés par matériel, comme une application ou une carte de cryptage matérielle. Sauvegarde des clés. La sauvegarde des clés de cryptage doit faire l’objet d’une planification rigoureuse. Tout d’abord, les clés ne doivent pas se trouver sur le même média que les données. Mais vous devez appliquer un schéma permettant d’associer quelle clé a été utilisée à quelle date, sous peine de ne pouvoir extraire vos données s’il fallait les récupérer après un stockage de longue durée ou effectuer une reprise après sinistre.

Changements de clés. J’ai gardé pour la fin cet aspect de la gestion des clés, pour de bonnes raisons : c’est l’un des moins stabilisés en matière de bonnes pratiques, et selon votre implémentation, l’un des plus difficiles à instaurer en tant qu’administrateur. Je parle bien sûr de l’opération qui consiste à changer la clé de cryptage qui a servi à crypter les données dans des fichiers actifs (par opposition à des fichiers de sauvegarde). Déplacer les données cryptées sur un autre fichier ou ajouter un autre champ dans vos fichiers présente un avantage : vous pouvez ajouter un champ qui suit la clé de cryptage utilisée. (A noter que ce n’est pas la clé de cryptage elle-même. C’est plutôt un nom de clé ou un numéro de version ou quelqu’autre information ayant servi à identifier la clé utilisée pour crypter les données.)