Vous êtes dans : Accueil > Tribunes libres >

Faut-il chiffrer les données de son DPI ? Volet 3 (fin)

Cédric Cartau, MARDI 29 SEPTEMBRE 2020

Dans le premier volet, nous avons examiné la question du chiffrement des données du DPI en reposant les fondamentaux : la différence entre le moyen et le besoin, et surtout la notion de chiffrement et de couche technique. Dans le deuxième volet, nous avons abordé les conséquences de la première loi selon laquelle le chiffrement ne protège que des attaques sur les couches inférieures, et surtout les conséquences de cette loi concernant le chiffrement des données contre les accès des informaticiens.

Le chiffrement génère des questions sur qui va chiffrer et qui, au final, va avoir accès à la donnée (voir le volet précédent), mais il a aussi des conséquences très lourdes sur d’autres aspects de l’exploitation, sur lesquelles curieusement personne ne s’étend : le PCA-PRA et la sauvegarde/restauration.

Si vous chiffrez les données avec la couche Firmware, toutes les couches supérieures « voient » la donnée en clair, y compris votre logiciel de sauvegarde, qui va donc la copier sur un espace bis. Si vous ne chiffrez pas cet espace bis, autant dire que tout votre dispositif ne sert pas à grand-chose. Il va donc falloir aussi chiffrer vos bandes ou votre baie de sauvegarde. Et, tant qu’on y est, il va falloir aussi sauvegarder les clés de chiffrement de vos environnements de production et de sauvegarde, les placer dans un lieu sécurisé par un mot de passe, vous demander où vous allez stocker ce mot de passe, etc. La seule question de la gestion de ces mots de passe occupe pas moins de 27 pages dans le premier opus du Guide Cyber résilience [1], publié avec le concours de l’Apssis. Bref, que du bonheur.

Si vous chiffrez vos données avec la couche DB, votre logiciel de sauvegarde ne voit et ne sauvegarde que des données chiffrées. Vous êtes alors affranchi de la question du chiffrement des supports de sauvegarde, mais si vous perdez les clés des espaces de stockages primaires vos données sont irrémédiablement perdues dans la mesure où vous n’allez restaurer que des données chiffrées dont vous ne possédez pas la clé. En d’autres termes, plus le chiffrement est réalisé sur les couches hautes, plus les problèmes d’exploitation augmentent.

C’est exactement la même chose concernant le PCA-PRA. Selon la couche qui gère les aspects de chiffrement, et selon la couche qui assure la redondance des données (il peut s’agir de cluster DB actif/actif ou actif/passif, de cluster d’OS, de stockage en mode Grid, etc.), les scenarii ne sont absolument pas les mêmes et, rien que sur cette question de PCA-PRA, il peut être nécessaire de réaliser une analyse de risques spécifiques, afin de bien identifier les scenarii à risque qui pourraient mener à des pertes de données.

Globalement, la loi L2 implique que la question des impacts sur l’exploitation et la question de la sauvegarde des clés de chiffrement constituent le nœud du problème, à savoir jusqu’où aller pour chiffrer, avec quelle couche chiffrer, contre quels types de risques on peut se prémunir avec les moyens dont on dispose, etc. Pour faire simple, plus on chiffre « haut » et plus on est enquiquiné.

La loi L3 est quant à elle plus « high level » : elle dit juste que dans le triptyque DIC (Disponibilité, Intégrité, Confidentialité), toute surpondération d’un des trois pans entraîne mécaniquement une dégradation des deux autres. La donnée la plus confidentielle du monde (surpondération du C) est celle que l’on a détruite (dégradation du I et du D). Inversement, la donnée la plus disponible du monde (surpondération du D) est celle que l’on a mise dans Google en libre accès (dégradation du C). Il est donc simple de comprendre que le chiffrement des données (augmentation du C) va mécaniquement engendrer plus de risques sur le D (des difficultés pour les informaticiens d’assurer l’exploitation) et du I (un risque de perte de données si l’on perd les clés de chiffrement).

La loi L3 a donc pour principale conséquence que, de la question initiale qui était « Faut-il chiffrer les données du DPI ? », nous sommes passés à « Quel est le besoin qui conduit à chiffrer les données du DPI et quelles solutions techniques mettre en face de ce besoin ? » et maintenant à « Si on chiffre les données métiers, quelle augmentation du risque de perte irrémédiable de données DPI due au chiffrement la MOA est-elle prête à accepter ? ».

Bouclons la boucle et revenons au propos de départ sur la différence entre le besoin et le moyen. Si le besoin est de protéger les données contre un monte-en-l’air qui cambriolerait la salle informatique, il n’appartient pas au demandeur (MOA) de décider que la contre-mesure est le chiffrement. Elle peut parfaitement reposer sur la protection physique des locaux (alarme, détection d’intrusion, équipes de sécurité avec rondes périodiques, badges d’accès nominatifs, etc.), et le choix relève de la seule responsabilité de la MOE. Le RGPD est d’ailleurs très intelligent sur ce mode de raisonnement : il appartient au responsable de traitement d’évaluer les risques en toute bonne foi, et de choisir en toute bonne foi les mesures de réduction qui ramène ce risque à un niveau jugé en toute bonne foi acceptable : le RGPD ne fait l’apologie d’aucune technique, d’aucun produit, et c’est heureux.

Si le besoin consiste à protéger les accès aux données pour des populations d’admin de la DSI (et la DSI n’a pas à juger de la pertinence de ce besoin), la DSI se doit de répondre qu’il est possible de le satisfaire, moyennant un coût très élevé et des risques considérables de perte de données, et qu’il appartient à la MOA de définir un budget et un niveau acceptable de risque de perte de données. À titre personnel, je ne saurais trop conseiller à une DSI qui doit traiter cette demande de réaliser une analyse de risques poussée, afin de bien identifier ce qui est possible et ce qui ne l’est pas, les scenarii d’exploitation qui vont se trouver complexifiés ou ralentis, les risques encourus selon tel ou tel scénario catastrophe, etc. Et surtout de bien coucher l’ensemble sur le papier, d’en garder la copie horodatée ainsi que l’accusé de réception du mail d’envoi. Et de préférence non chiffrés.

[1] https://www.apssis.com/actualite-ssi/435/guide-cyber-resilience-opus-1-les-mots-de-passe.htm 

#dpi#dsi#RGPD#pra#perte de données#apssis#logiciel#