Faut-il chiffrer les données de son DPI ? – Volet 2

Une fois que l’on a compris que le chiffrement d’une donnée sur la couche matérielle pouvait être réalisé par (au moins) quatre couches différentes, il faut intégrer trois notions, ou lois, immuables :

• L1 : Le chiffrement par la couche de niveau « n » est une contre-mesure de sécurité pour les attaques sur les couches inférieures, et surtout pas une réponse à une attaque sur les couches égales ou supérieures ;
• L2 : plus le chiffrement est réalisé par une couche « haute », plus il protège de types d’attaques (conséquence de L1), mais, a contrario, plus les contraintes au quotidien sont nombreuses, à la fois côté DSI et côté métier ;
• L3 : conséquence de L2, mécaniquement, le chiffrement (qui est une augmentation du critère de Confidentialité) dégrade les critères d’Intégrité et de Disponibilité.

Pour ce qui est de L1, l’activation du chiffrement sur la couche 1 (firmware) protège du vol physique de disque. Par exemple, un cadre de l’entreprise se fait dérober son PC dans un train ; si le voleur ne possède pas le mot de passe, il va devoir démonter physiquement le PC pour en récupérer le disque, mais ce dernier, chiffré, sera illisible. Si, en revanche, le chiffrement a été positionné sur la couche 2 (OS) et si le voleur dispose du mot de passe de session, à la différence de l’exemple précédent où le vol physique du disque ne permettait pas de lire les données, l’ouverture de session rendra leur lecture possible. C’est à la fois tout l’intérêt des systèmes en couches (la couche de niveau « n » rend transparent son fonctionnement pour les couches supérieures) et leur limite. Autrement dit, si le seul risque dont on veut se prémunir est l’exfiltration de données après un vol physique d’équipement (par exemple, une intrusion dans un datacenter), alors le chiffrement par la couche 1 (firmware) est une bonne réponse. Mais si l’on veut se prémunir aussi d’attaques sur les couches supérieures, le chiffrement de la couche 1 ne constitue en rien une protection adéquate.

On en vient immanquablement à la question du chiffrement des données pour les rendre inintelligibles aux informaticiens de la DSI eux-mêmes – souvent le mantra : « Il faut chiffrer les données du DPI » trouve là son origine fantasmagorique. Si l’on part du principe que la DSI possède les accès sur la couche 1 (qui d’autre ?), sur la couche 2 (OS : sinon il est difficile de travailler) et sur la couche 3 (DB), alors il faut chiffrer les données par la couche applicative. Pour des applications en C/S déployées en dur sur les PC des utilisateurs, cette opération relève de l’exploit : il faut déployer des clés de chiffrement sur chaque PC, mettre sous séquestre le serveur de clé (voire l’externaliser), auditer régulièrement les PC des admin histoire de vérifier si par hasard une clé ne se serait pas créée en douce, auditer les flux internes sur le LAN. Ou alors déployer l’application en mode Citrix, TSE ou Systancia – ce qui revient à échanger le Covid-19 contre une triple peste purulente. Pour les applications en 3/3, il va falloir sécuriser le serveur d’applications en le rendant totalement inaccessible aux admin (qui pour autant sont admin de domaine) : que l’auteur d’une telle performance m’appelle, je veux bien qu’il m’explique comment il a procédé. Il en profitera aussi pour m’expliquer comment les informaticiens vont pouvoir reproduire des dysfonctionnements du logiciel sur des cas réels sans avoir un accès applicatif à l’environnement de production – et pour celui qui voudrait sortir : « On fait des copies hebdomadaires de la prod sur un environnement anonymisé », j’ai les lèvres gercées à cause du sel marin, ça me fait mal de rire trop fort, merci d’être sympa.

Évidemment, le plus simple est que les informaticiens n’aient pas d’accès DB, ce qui permet donc justement de chiffrer au niveau de cette couche. Mais alors là, vous vous posez d’autres questions : comment – et surtout qui – va administrer la DB (migrations, maintenance, etc.) ? Comme l’externalisation n’est pas une réponse (ce n’est qu’un déplacement du problème), il va vous falloir trouver de bonnes âmes chez les utilisateurs qui auront le temps de s’occuper d’administrer les DB, et accessoirement les compétences, sachant qu’un admin Oracle de bon niveau, c’est au bas mot dix ans de pratique. Autre solution : à chaque fois qu’une action d’administration sur la DB est nécessaire, qu’un « power-user »vienne taper le mot de passe sur la console pour que les admin de la DSI puissent travailler. Le tout bien entendu 24/7/365 en multisite. Bon, en gros, ça va tenir 72 heures, peut-être une semaine. Au final, les utilisateurs donneront le mot de passe DB aux admin de la DSI, et vous vous retrouverez à la case départ.

À titre personnel, je n’ai vu le chiffrement de données mis en œuvre – il s’agissait d’un chiffrement sur la couche DB – qu’une seule fois : sur la base de données du logiciel de médecine du travail, qui intègre nativement cette fonction. Et au final, parce qu’il est impossible de faire autrement, au moins deux informaticiens disposaient de codes d’accès nominatifs, malgré l’extrême réticence du responsable du service. Je constate que les autres établissements de santé à avoir mis en place ce système en interne sont étonnamment discrets sur les questions centrales : quels sont les risques retenus, quelle couche réalise le chiffrement, quels accès pour les admin de la DSI ? À ceux qui pensent que c’est de l’ordre du réalisable, je rappelle que même la NSA n’a pas empêché les fuites de données WikiLeaks.

À suivre…