Chiffrer est facile. La clé, c’est le travail

La mauvaise question

« Chiffrez-vous les données ? » est une question à laquelle on répond toujours oui, et qui n’apprend donc rien. Le chiffrement des disques est standard, le trafic sur internet est chiffré, et tout grand service cloud chiffre ce que vous y déposez sans qu’on le demande.

La question qui apprend quelque chose est : où se trouve la clé qui défait ce chiffrement, et qui peut y accéder. Car des données chiffrées dont la clé est posée à côté du coffre ne sont pas protégées. Elles sont seulement plus compliquées à lire.

Cette différence est exactement là où atterrit un audit. Non pas sur l’existence d’une serrure, mais sur celui qui détient la clé.

Les trois endroits où une clé peut se trouver

En pratique, on rencontre trois modèles, et la différence entre eux n’est pas technique mais de gouvernance.

• Le fournisseur gère la clé. C’est le standard des services cloud. Cela fonctionne, c’est bien protégé et vous n’avez pas à vous en occuper. Le revers : vous ne pouvez pas démontrer que le fournisseur lui-même n’y accède pas, car c’est une propriété de son système et non de votre politique.
• Vous fournissez la clé au fournisseur. Azure et AWS le permettent : vous créez la clé vous-même et la confiez pour usage. Vous gardez la maîtrise du cycle de vie et pouvez la révoquer. La clé reste néanmoins dans leur environnement.
• La clé est dans votre propre matériel. Un module de sécurité matériel conserve les clés de sorte qu’elles ne quittent jamais l’appareil. Les opérations se font à l’intérieur ; ce qui en sort est le résultat, pas la clé. Thales est l’un des fournisseurs de ce type d’équipement, et c’est le modèle vers lequel renvoient les régulateurs quand l’exigence est qu’une clé se trouve de façon démontrable hors du fournisseur.

Le troisième modèle coûte plus cher et demande plus de travail que les deux premiers. Nous le proposons quand il y a une raison, pas parce qu’il impressionne.

Ce qu’un audit demande vraiment

Lors d’un audit, d’une revue DORA ou d’un échange NIS2, l’algorithme n’est presque jamais le sujet. Quatre choses le sont, et toutes les quatre sont administratives.

• Où se trouve la clé. Pas « dans le cloud », mais dans quel système, sous le contrôle de qui et dans quel pays.
• Qui peut y accéder. Nominativement, pas seulement par rôle, avec une liste qui correspond à qui travaille là aujourd’hui.
• Quand elle a été renouvelée. Une clé en place depuis huit ans est un constat, même s’il ne lui est jamais rien arrivé.
• Ce qui se passe si elle disparaît. Si personne ne sait répondre, la sauvegarde de ces données est théorique.

Ces quatre questions se répondent sans matériel coûteux. Elles ne se répondent pas sans traçabilité, et c’est là que cela achoppe en pratique.

La clé et la sauvegarde

Il y a une erreur que nous rencontrons plus souvent que toutes les autres réunies : la sauvegarde est chiffrée avec une clé qui n’existe que dans l’environnement que vous cherchez à restaurer.

Cela tient jusqu’au jour où vous perdez cet environnement. Vous avez alors des copies que personne ne peut ouvrir, et vous l’apprenez au pire moment. Les sauvegardes immuables ne règlent pas cela : elles protègent contre la modification et la suppression, pas contre la perte de la clé.

Nous ne testons donc pas seulement si une sauvegarde revient, mais si elle revient dans un environnement reconstruit à partir de rien. C’est un autre type de test, et il produit plus souvent des surprises.

Ce que nous faisons là-dedans

Nous ne construisons pas de chiffrement et n’écrivons pas de logiciel de gestion de clés. Ce que nous faisons :

• Cartographier où sont les clés. Lors d’une reprise, c’est presque toujours la première surprise : il y en a plus que personne ne pensait, et certaines se trouvent à un endroit que personne n’avait prévu.
• Limiter et consigner les accès. Par personne, avec vérification à plusieurs facteurs et une trace lisible après coup.
• Planifier le renouvellement. Une clé, comme un certificat, a une date de fin. Nous la surveillons et la signalons largement à l’avance.
• Tester la reprise sans l’environnement existant. Le test qui compte est celui où l’on fait comme s’il ne restait rien.

La façon dont cela s’inscrit dans la sécurité plus large figure sous cybersécurité ; la façon dont nous convenons et démontrons les durées de reprise sous sauvegarde et continuité.

Quand le matériel a du sens

Le stockage matériel des clés a du sens si au moins l’une de ces trois conditions est vraie.

• Il existe une exigence, réglementaire ou d’un client, que les clés se trouvent de façon démontrable hors de l’environnement de votre fournisseur cloud.
• Vous traitez des données de carte ou autre chose pour laquelle une norme l’exige explicitement.
• Vous devez pouvoir montrer que personne — vous compris — ne peut lire une clé, seulement l’utiliser.

Si aucune des trois ne s’applique, la gestion des clés chez votre fournisseur cloud avec une bonne traçabilité est le choix raisonnable, et nous le disons. Acheter quelque chose pour lequel vous n’avez aucune exigence, c’est de l’argent qui ne va pas vers la faille suivante.