Chiffrement des données : obligations RGPD et bonnes pratiques
Le chiffrement est une mesure de sécurité recommandée par le RGPD et exigée par NIS2. Obligations légales, types de chiffrement et mise en oeuvre pratique.
Le chiffrement des données constitue l’une des mesures techniques les plus fréquemment invoquées par les textes européens en matière de protection de l’information. Le RGPD le mentionné explicitement à son article 32, la directive NIS2 en fait une exigence structurante, et la CNIL le recommandé systématiquement dans ses guides pratiques. Pourtant, la mise en oeuvre du chiffrement reste un sujet mal maîtrisé par de nombreuses organisations, qui peinent a distinguer ce qui relève de l’obligation juridique stricte, de la recommandation forte, ou de la simple bonne pratique. Cet article propose une analyse complète du cadre juridique applicable, des standards techniques a déployer et des modalités pratiques de mise en oeuvre.
Le cadre juridique du chiffrement
Le RGPD et l’article 32
L’article 32 du RGPD impose aux responsables de traitement et aux sous-traitants de mettre en oeuvre les mesures techniques et organisationnelles appropriées afin de garantir un niveau de sécurité adapté au risque. Le texte mentionné explicitement, au paragraphe 1, point a), “la pseudonymisation et le chiffrement des données à caractère personnel” parmi les mesures susceptibles d’être déployées.
Il convient de noter que le RGPD ne posé pas une obligation absolue de chiffrement. Le texte utilise la formule “selon les cas”, ce qui signifie que le chiffrement doit être mis en oeuvre lorsqu’il est adapté au niveau de risque identifie. En pratique, cette formulation laisse une marge d’appréciation au responsable de traitement, mais cette marge se réduit considérablement à mesure que la sensibilité des données augmente.
Pour les données de santé, les données biométriques, les données relatives aux infractions pénales ou les données révélant l’origine raciale ou ethnique, le chiffrement n’est plus une option mais une quasi-obligation. L’absence de chiffrement pour ces catégories de données serait très difficilement justifiable devant une autorité de contrôle. Pour approfondir l’ensemble des exigences de l’article 32, consultez notre guide sur la sécurité des données au titre du RGPD.
La directive NIS2 et les exigences de cryptographie
La directive (UE) 2022/2555, dite NIS2, va plus loin que le RGPD en matière de chiffrement. Son article 21, paragraphe 2, point h), impose aux entités essentielles et importantes de mettre en oeuvre des “politiques et des procédures relatives à l’utilisation de la cryptographie et, le cas échéant, du chiffrement”. Cette formulation est significative : il ne s’agit plus seulement de chiffrer les données lorsque c’est nécessaire, mais de disposer d’une politique formalisée en matière de cryptographie.
Concrètement, les organisations soumises à NIS2 doivent documenter leur stratégie de chiffrement, définir les cas d’usage, les algorithmes retenus, les procédures de gestion des clés et les responsabilités associées. L’absence d’une telle politique constitue en soi un manquement, indépendamment de la question de savoir si le chiffrement est effectivement déployé sur tel ou tel système.
La position de la CNIL
La CNIL a pris position a de nombreuses reprises sur le chiffrement. Dans ses recommandations relatives à la sécurité des données personnelles, elle considère le chiffrement comme une mesure de base pour plusieurs scénarios : le stockage de données sensibles, la transmission de données sur des réseaux publics, le stockage de données sur des équipements mobiles ou des supports amovibles.
La jurisprudence de la CNIL confirmé cette approche. Plusieurs sanctions ont été prononcées en raison de l’absence de chiffrement la ou il s’imposait. À titre d’exemple, la transmission de données de santé par courrier électronique sans chiffrement a été sanctionnée, de même que le stockage de mots de passe en clair dans des bases de données. Le message est clair : lorsque le risque est élevé, l’absence de chiffrement est constitutive d’un manquement à l’obligation de sécurité.
Les types de chiffrement a déployer
Le chiffrement ne se résumé pas à un concept unique. Il se décline en plusieurs modalités, chacune répondant à un besoin spécifique de sécurité.
Le chiffrement au repos (at rest)
Le chiffrement au repos protégé les données stockées sur des supports physiques : disques durs, bases de données, sauvegardes, supports amovibles. L’objectif est de prévenir l’accès aux données en cas de vol, de perte ou d’accès physique non autorisé au support.
Le standard de référence est l’AES-256 (Advanced Encryption Standard avec une clé de 256 bits). Cet algorithme est considéré comme robuste par l’ensemble des autorités de référence, y compris l’ANSSI. Il est disponible nativement dans la plupart des systèmes d’exploitation (BitLocker sous Windows, FileVault sous macOS, LUKS sous Linux) et dans les solutions de bases de données du marché.
Pour les bases de données, deux approches coexistent : le chiffrement transparent (TDE - Transparent Data Encryption), qui chiffre l’ensemble de la base au niveau du stockage, et le chiffrement au niveau colonne, qui permet de chiffrer sélectivement les champs contenant des données sensibles. La seconde approche offre une granularité supérieure mais induit une complexité de gestion plus élevée.
Le chiffrement en transit (in transit)
Le chiffrement en transit protégé les données pendant leur transmission sur un réseau. Il s’agit de prévenir l’interception des données par un tiers (attaque de type “man-in-thé-middle”).
Le standard actuel est TLS 1.3, qui a succede a TLS 1.2. Les versions antérieures (TLS 1.0, TLS 1.1, SSL) sont considérées comme obsolètes et ne doivent plus être utilisées. La CNIL et l’ANSSI recommandent formellement de désactiver ces protocoles anciens.
Le chiffrement en transit s’applique à l’ensemble des flux : communications web (HTTPS), messagerie électronique (SMTPS, IMAPS), transferts de fichiers (SFTP, FTPS), connexions à des bases de données distantes, communications entre microservices au sein d’une architecture applicative.
Le chiffrement de bout en bout (end-to-end)
Le chiffrement de bout en bout constitue le niveau de protection le plus élevé. Dans ce modèle, les données sont chiffrées sur le terminal de l’expéditeur et ne sont déchiffrées que sur le terminal du destinataire. Aucun intermédiaire, y compris le fournisseur du service de communication, ne dispose des clés permettant d’accéder au contenu en clair.
Ce type de chiffrement est particulièrement pertinent pour les communications contenant des données sensibles : échanges entre un avocat et son client, transmissions de données médicales entre professionnels de santé, communications internes portant sur des informations stratégiques.
La gestion des clés : le maillon critique
Le chiffrement n’a de valeur que si les clés cryptographiques sont correctement gérées. Une clé compromise rend l’ensemble du dispositif de chiffrement inopérant. La gestion des clés constitue donc le maillon le plus critique de toute stratégie de chiffrement.
Les principes fondamentaux
Plusieurs principes doivent guider la gestion des clés. La séparation des clés et des données chiffrées est essentielle : stocker la clé de chiffrement au même endroit que les données chiffrées revient a fermer une porte a clé en laissant la clé sur la serrure. Les clés doivent être stockées dans des coffres-forts dédiés (HSM - Hardware Security Modules, ou solutions de gestion de clés logicielles telles qu’AWS KMS, Azure Key Vault ou HashiCorp Vault).
La rotation régulière des clés est également indispensable. Les clés de chiffrement doivent être renouvelées périodiquement, selon une fréquence adaptée au niveau de risque. Une rotation annuelle constitue un minimum raisonnable pour la plupart des cas d’usage.
Enfin, la révocation et la destruction des clés doivent être prévues et documentées. Lorsqu’une clé est compromise ou arrivé en fin de vie, un processus de révocation doit être immédiatement déclenche.
La hiérarchie des clés
Les bonnes pratiques recommandent de mettre en place une hiérarchie de clés comprenant au minimum trois niveaux : une clé maîtresse (Master Key), protégée dans un HSM, qui sert a chiffrer les clés de chiffrement de données (DEK - Data Encryption Keys), elles-mêmes utilisées pour chiffrer les données. Cette architecture, dite “envelope encryption”, permet de limiter l’exposition de la clé maîtresse et de faciliter la rotation des clés de données.
Quand le chiffrement est-il obligatoire ?
La réponse à cette question dépend du contexte juridique et factuel. On peut néanmoins identifier plusieurs situations dans lesquelles le chiffrement est, de facto, obligatoire.
Données sensibles au sens du RGPD : pour les catégories particulières de données (article 9) et les données relatives aux condamnations pénales (article 10), le chiffrement au repos et en transit est quasi-systématiquement exigé par les autorités de contrôle.
Transferts internationaux de données : à la suite de l’arrêt Schrems II, le chiffrement constitue l’une des mesures supplémentaires recommandées par le CEPD pour les transferts vers des pays tiers ne bénéficiant pas d’une décision d’adéquation. Le chiffrement avec gestion des clés sous le contrôle exclusif de l’exportateur est spécifiquement mentionné.
Entites soumises à NIS2 : les entités essentielles et importantes doivent, au minimum, disposer d’une politique de chiffrement documentée et la mettre en oeuvre de manière effective.
Données de santé : le référentiel de sécurité applicable aux systèmes d’information de santé impose le chiffrement à plusieurs niveaux.
Équipements mobiles et télétravail : les terminaux susceptibles d’être perdus ou volés (ordinateurs portables, smartphones, clés USB) doivent impérativement être chiffres.
Le chiffrement dans le cloud
Le recours croissant aux services cloud posé des questions spécifiques en matière de chiffrement. La plupart des fournisseurs cloud proposent un chiffrement natif des données au repos et en transit. Cependant, dans le modèle standard, c’est le fournisseur cloud qui détient les clés de chiffrement, ce qui signifie qu’il dispose techniquement de la capacité d’accéder aux données en clair.
Pour les données les plus sensibles, plusieurs options permettent de renforcer le contrôle sur les clés. La solution “Bring Your Own Key” (BYOK) permet au client de fournir sa propre clé au fournisseur cloud, qui l’utilise pour le chiffrement. La solution “Hold Your Own Key” (HYOK) va plus loin en maintenant la clé sous le contrôle exclusif du client, en dehors de l’infrastructure du fournisseur. Enfin, le chiffrement cote client (client-side encryption) consiste à chiffrer les données avant de les transmettre au fournisseur, de sorte que ce dernier ne manipule jamais que des données chiffrées.
Le choix entre ces options dépend de l’analyse de risque et des exigences réglementaires applicables. Pour les données soumises au secret professionnel ou les données de santé, la solution HYOK ou le chiffrement cote client sont généralement recommandés.
Guide de mise en oeuvre pratique
La mise en oeuvre d’une stratégie de chiffrement conforme aux exigences légales suppose une démarche structurée en plusieurs étapes.
Étape 1 - Cartographie : identifier l’ensemble des données traitées, leur localisation (bases de données, fichiers, sauvegardes, flux de transmission) et leur niveau de sensibilité. Le déploiement d’une solution de prévention des fuites de données (DLP) en amont de cette étape peut faciliter l’identification des flux de données sensibles.
Étape 2 - Analyse de risque : pour chaque catégorie de données, évaluer les risques associés à une compromission (atteinte à la vie privée, préjudice financier, atteinte à la réputation) et déterminer le niveau de chiffrement requis.
Étape 3 - Choix des solutions : sélectionner les algorithmes (AES-256 pour le chiffrement symétrique, RSA-2048 ou courbes elliptiques pour le chiffrement asymétrique), les protocoles (TLS 1.3) et les solutions de gestion de clés.
Étape 4 - Déploiement : mettre en oeuvre le chiffrement de manière progressive, en commencant par les données les plus sensibles et les flux les plus exposés.
Étape 5 - Documentation : rédiger la politique de chiffrement exigée par NIS2, incluant les algorithmes utilisés, les procédures de gestion des clés, les responsabilités et les procédures de révocation.
Étape 6 - Audit et maintien : vérifier régulièrement la conformité du dispositif de chiffrement, tester la robustesse des configurations et mettre à jour les algorithmes en fonction de l’évolution des menaces.
Conclusion
Le chiffrement des données n’est plus une option technique réservée aux experts en cybersécurité. Il constitue désormais une exigence juridique structurante, portée à la fois par le RGPD et par la directive NIS2. Les organisations qui n’ont pas encore formalisé leur stratégie de chiffrement s’exposent à des risques juridiques significatifs, tant en termes de sanctions administratives que de responsabilité civile en cas de violation de données. La mise en conformité suppose une approche méthodique, articulant analyse de risque, choix techniques adaptés et gouvernance des clés cryptographiques. C’est à ce prix que le chiffrement remplit pleinement son rôle de protection des données personnelles et des informations sensibles.