Avis d'Experts IBM : Crypto or Not Crypto, That Is The Question!

En 2017, les données personnelles sont souvent à l'honneur pour deux raisons très différentes: des fuites de données sont régulièrement rapportées dans les journaux, et elles se font désormais à une échelle industrielle, à coup de 100, voire 500 millions d'utilisateurs.

En parallèle, un règlement européen, le RGPD, sera opposable en mai 2018. Il offre de nouveaux droits et de nouvelles garanties aux personnes en matière de gestion de leurs données personnelles. Et il ne reste que quelques mois aux entreprises pour se mettre en conformité, sous peine de lourdes amendes.

Le chiffrement est une des premières mesures à mettre en place pour protéger les données personnelles.

En cas de fuite, elles ne pourront pas être exploitées par l'attaquant, tant qu'il ne possède pas la clé de déchiffrement.

Mais le chiffrement de l'information peut avoir des impacts techniques, organisationnels et financiers non négligeables. A moins d'utiliser une plateforme technique capable de tout chiffrer tout le temps sans pénaliser de manière inacceptable les performances (si, si, ça existe), il faut donc commencer par identifier quoi chiffrer, puis gérer ce parc dans le temps.

Chiffrer, c'est rendre une information illisible pour quelqu'un qui n'a pas la clé qui permettra de déchiffrer l'information pour la lire à nouveau.

La bonne gestion des clés est donc très importante pour protéger les informations chiffrées. Une personne malveillante peut aussi essayer de décrypter l'information, c'est-à-dire la lire sans avoir la clé. Les méthodes de chiffrement implémentées doivent donc être robustes et empêcher les attaquants de « casser » la protection mise en place.

La généralisation du chiffrement amène aussi à utiliser des « clés maîtres », des clés qui vont servir à protéger toutes les autres clés, un peu comme la clé de la boîte à clés dans laquelle vous rangez toutes les clés de votre maison. Est-il besoin de rappeler que la protection de ces « clés maîtres » est critique?

En complément (et pas en remplacement.), il existe de nombreuses options pour protéger les données :

-anonymisation des informations qu'on n'a pas besoin de pouvoir identifier (mais attention au croisement de ces informations qui permettrait de ré-identifier dans certains cas les données anonymisées);

- rédaction des portions de document sensibles (comme dans les dossiers du FBI que vous voyez dans les séries américaines, avec des portions de phrase masquées par un bandeau noir);

- tokenisation des informations qu'on veut pouvoir continuer à exploiter mais sans les exposer (l'émetteur remplace l'information par un token banalisé, mais conserve une table de correspondance qui lui permettra d'effectuer l'opération inverse si on lui renvoie cette information; il est donc le seul à savoir de qui on parle). Voire suppression pure et simple des données qu'on n'a pas besoin de conserver explicitement. Ce qui constitue, vous en conviendrez, un excellent moyen d'éviter les fuites, et de se simplifier la vie.

L'ère du stockage massif des informations, sans raison particulière et sans durée de vie, ne devrait donc pas résister au durcissement de la réglementation. Et c'est plutôt une bonne nouvelle pour le respect de notre vie privée.

Enfin, les solutions logicielles DAM (Data Access Monitoring) complètent la chaîne de protection pour protéger en particulier les informations stockées dans les bases qu'on ne peut (ou ne veut) pas anonymiser.  Elles auditent les transactions, peuvent les modifier si nécessaire, voire interdire les requêtes jugées dangereuses.

Le chiffrement s'impose donc comme un élément important de la politique de sécurité et de protection des données en entreprise. Toute la complexité consiste à bien comprendre les différents moyens de protéger l'information, et à les combiner à bon escient.

Pour paraphraser à nouveau Shakespeare, « il ne suffit pas de chiffrer, il faut chiffrer juste*».

*Dans la version officielle : "Il ne suffit pas de parler, il faut parler juste". Le songe d'une nuit d'été

Thierry Matusiak, Architecte Logiciel - IBM.