Gérer les clés. Limiter les accès.

Une nouvelle clé ne signifie pas que l'ancienne peut être supprimée immédiatement. Nous déterminons quelles données, signatures ou sauvegardes dépendent encore de versions antérieures. Les applications ont besoin d'une association claire à la version de clé. La création, l'activation, la révocation, l'archivage et la suppression font l'objet d'états et de validations distincts. Les erreurs telles que des sessions épuisées, des authentifications expirées ou des connexions interrompues sont traitées de manière visible. Les nouvelles tentatives ne doivent pas produire de doublons de clés indésirables ni d'opérations métier dupliquées.

Lors du test, nous vérifions non seulement les appels réussis, mais aussi les rôles rejetés et les opérations non autorisées. Les moyens d'accès et les secrets ne doivent pas se retrouver dans le code source, les journaux ou des sauvegardes générales. Votre équipe reçoit la configuration, des scénarios d'exemple et une procédure de diagnostic. Les bibliothèques utilisées, les environnements d'exécution et les inventaires de clés existants sont importants pour démarrer.

PKCS #11 décrit l'accès aux jetons cryptographiques et à leurs fonctions. KMIP couvre la gestion des objets cryptographiques entre le client et le système de gestion des clés. Un service cloud peut quant à lui proposer sa propre API REST. Cela n'implique aucune interchangeabilité automatique. OTOKO® documente où une opération est exécutée, quel matériel de clé une interface transmet réellement et quels attributs sont conservés. Une simple liste de protocoles devient ainsi une voie d'intégration compréhensible.

Dans un chiffrement hiérarchique, des clés de données peuvent protéger les données elles-mêmes, tandis qu'une clé de niveau supérieur protège ces clés de données. Cela évite qu'un HSM doive traiter chaque grand bloc de données. Ce qui compte, c'est l'endroit où une clé de données est nécessaire en clair et la durée pendant laquelle elle y reste disponible. Nous clarifions le comportement du cache, la rotation et les accès dans l'application. L'affirmation « la clé reste dans le HSM » n'est valable que pour le rôle de clé considéré et ses attributs.

Plusieurs services utilisent jusqu'ici leurs propres fichiers de clés. OTOKO® commence par associer à chaque clé son propriétaire, sa finalité et ses dépendances de données. Nous testons ensuite l'intégration prise en charge d'un service représentatif et définissons les autorisations par application. La bascule s'effectue progressivement, avec une lecture contrôlée des données existantes et l'écriture des nouvelles données. Les anciennes clés ne sont retirées qu'une fois la conservation, les sauvegardes et la restauration prises en compte. Le résultat est un inventaire de clés documenté, avec des procédures d'utilisation et de changement testées.