Chiffrement des données : obligations et gestion des clés

Le chiffrement des données doit répondre à un risque identifié : perte d’un support, interception d’un échange ou accès indésirable au stockage. Pour évaluer une solution, demandez quelles données elle protège, contre quel accès et qui peut les déchiffrer. La mention « données chiffrées » ne suffit pas à établir la sécurité d’un service.

Ce que le RGPD exige réellement

L’Art. 32(1)(a) mentionne le chiffrement parmi les mesures à mettre en œuvre selon les besoins, dans le cadre d’un niveau de sécurité adapté au risque. Ce n’est ni une obligation identique de chiffrer chaque donnée dans toute circonstance, ni une option que l’organisme pourrait ignorer sans examiner son utilité. L’analyse tient notamment compte de la nature des données, du contexte, de l’état des connaissances et des conséquences pour les personnes. Source : RGPD, Art. 32(1) et (2).

Les mesures de sécurité de l’article 32 doivent aussi préserver disponibilité et résilience. Une base parfaitement chiffrée mais devenue irrécupérable après la perte de sa clé peut donc soulever un problème de sécurité.

NIS2 prévoit des politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement. Le texte n’impose pas un algorithme unique à toutes les entités. Sa transposition et les règles sectorielles doivent être vérifiées dans le contexte de l’organisation. Source : directive (UE) 2022/2555, Art. 21(1) et (2)(h).

Choisir le niveau de protection pertinent

Le tableau suivant sert à cadrer l’analyse avec l’équipe technique. Les limites doivent être vérifiées dans l’architecture effective.

Cette cartographie évite de confondre un réglage de stockage avec une protection contre tous les usages possibles des données. Elle doit inclure les exports, les environnements de test et les copies conservées par les prestataires.

Hachage et chiffrement ne remplissent pas le même rôle

La CNIL distingue les fonctions de hachage, de signature et de chiffrement. Une empreinte seule ne garantit pas la confidentialité d’une donnée ; le stockage des mots de passe appelle des fonctions adaptées et un sel. Pour le chiffrement, le choix des paramètres et la qualité de l’implémentation comptent autant que le nom de l’algorithme. Source : CNIL, chiffrement, hachage et signature.

La politique des mots de passe traite séparément la vérification des secrets d’authentification. Chiffrer une base de mots de passe en clair ne remplace pas cette analyse.

Préparer la gestion des clés

Attribuez une responsabilité claire pour chaque usage cryptographique. Le dossier doit répondre aux questions suivantes : qui génère la clé, qui peut l’utiliser, qui peut la récupérer, comment limiter les accès et que faire en cas de compromission ? La CNIL recommande une procédure de gestion des clés et certificats, ainsi que la protection des secrets par des accès restrictifs. Source : CNIL, précautions cryptographiques.

Ne fixez pas une rotation annuelle par simple réflexe. Définissez la durée d’usage selon la fonction, les risques, les règles techniques applicables et les capacités de remplacement. Une rotation mal préparée peut rendre des archives illisibles sans supprimer les anciennes copies compromises.

Pour une sauvegarde, la preuve utile est une restauration autorisée qui vérifie la disponibilité des données et des moyens de déchiffrement. La conservation d’une clé sans accès possible au moment critique ne répond pas au besoin.

Contrôler les promesses du fournisseur cloud

Demandez une description des opérations de déchiffrement, des rôles d’administration et des voies de récupération. Le fait que le client fournisse une clé ne prouve pas à lui seul que le fournisseur ne peut jamais accéder au clair. La réponse dépend des droits et du fonctionnement du service.

La grille d’examen peut comprendre : données couvertes, copies exclues, gestion des clés, accès de support, procédure d’incident, restitution et fermeture du service. Ces éléments alimentent les obligations de sécurité dans le cloud. Le chiffrement ne remplace ni le contrat de sous-traitance ni l’analyse des transferts internationaux éventuellement concernés. Source : RGPD, Art. 28 et 32.

Chiffrement et violation de données

L’Art. 34(3)(a) prévoit une exception à l’information des personnes lorsque des mesures appropriées rendent les données incompréhensibles à toute personne non autorisée. Il faut vérifier leur application réelle. Cette disposition ne dispense pas automatiquement de l’analyse de notification de l’Art. 33 ni de la documentation de la violation. Source : RGPD, Art. 33 et 34.

Construire une fiche de décision par usage

Une décision exploitable décrit un parcours de données et une menace. « Chiffrer les données clients » reste trop vague pour attribuer les travaux. Préparez plutôt une fiche par usage : travail mobile, transmission à un partenaire, stockage applicatif ou conservation d’une copie. La fiche proposée peut comporter six champs :

1. Données et personnes concernées : documents, volume, sensibilité et conséquences d’un accès indu.
2. Situation redoutée : vol du matériel, copie du stockage, accès d’un administrateur ou interception d’un échange.
3. Protection attendue : ce qui doit rester inaccessible et dans quelles circonstances.
4. Limites connues : données disponibles après connexion, exports autorisés, copies ou destinataires exclus.
5. Dépendances : comptes, clés, personnes et services nécessaires à l’utilisation comme à la récupération.
6. Décision et suivi : responsable de mise en œuvre, preuve attendue, écart restant et événement déclenchant une révision.

Le métier décrit l’usage indispensable ; l’équipe technique examine les moyens ; le responsable du traitement apprécie le niveau de risque et les mesures. Une limite connue ne devient pas acceptable par sa seule inscription dans un tableau. Lorsque l’analyse révèle une protection insuffisante, consignez l’action à mener et les restrictions nécessaires pendant sa réalisation. Ce document sert à rendre la décision vérifiable, sans constituer un formulaire réglementaire imposé.

Organiser la réception avec le prestataire

Avant de conclure que le chiffrement est opérationnel, demandez quelles pièces peuvent établir sa portée : description de configuration, périmètre des sauvegardes, liste des rôles autorisés ou compte rendu d’une vérification convenue. Une capture montrant une option activée ne décrit pas nécessairement les exports ni les accès de maintenance. Rapprochez chaque pièce de l’usage qu’elle est censée couvrir.

La réception peut prévoir une démonstration autorisée sur des données fictives. L’objectif proposé est de suivre un fichier depuis son entrée dans le service jusqu’à sa restitution, en identifiant les copies produites et les intervenants capables de le lire. Définissez au préalable le résultat attendu et les limites de l’observation. Un parcours concluant sur cette configuration ne prouve pas la sécurité de tous les environnements du fournisseur.

Pour la récupération, faites préciser qui peut déclencher l’opération, quelle autorisation est requise et comment conserver une trace de l’intervention. Examinez aussi le départ de l’administrateur habituel et la fermeture du contrat. Le fournisseur doit-il encore être disponible pour rendre vos archives lisibles ? Les moyens nécessaires resteront-ils accessibles aux personnes habilitées après la fin du service ? Les réponses déterminent les travaux de sortie et leur ordre, avant toute suppression de compte ou de clé.

Exemple fictif : un poste chiffré, un export incertain

Dans ce scénario entièrement fictif, l’entreprise Aulne perd un ordinateur professionnel. Son inventaire indique que le disque était chiffré. Un salarié avait également préparé un export destiné à un partenaire ; son emplacement final et sa protection ne sont pas encore établis. La seule propriété du disque ne permet donc pas de conclure pour toutes les copies.

La fiche d’incident proposée distingue trois lignes : le poste perdu, l’export et les moyens de déchiffrement. Pour chacune, notez les faits établis, leur source et les vérifications restantes. Il faut notamment examiner l’état du poste au moment de la perte, l’accès possible aux secrets et la destination effective du fichier. Les réponses peuvent modifier l’appréciation du risque ; leur absence doit rester visible.

L’équipe poursuit ces investigations pendant que le responsable de traitement évalue les obligations des Art. 33 et 34. L’incertitude ne suspend pas leurs exigences de délai. Si une notification à l’autorité est requise et que les informations ne sont pas toutes disponibles, l’Art. 33(4) permet leur communication échelonnée sans retard indu supplémentaire. Cette démarche ne présume ni l’existence d’un accès malveillant ni l’efficacité de la protection. Source : RGPD, Art. 33 et 34.

La clôture devrait séparer la décision relative à cette violation et les améliorations à apporter aux exports. Réparer le circuit de transmission est utile pour l’avenir ; cela n’établit pas rétroactivement que le fichier était protégé au moment de sa disparition.

Ce qu’il faut retenir

• Reliez le chiffrement à un risque et à un périmètre précis.
• Vérifiez les accès au clair, les copies et la récupération des clés.
• Une empreinte ne remplace pas le chiffrement des données.
• Conservez une preuve de fonctionnement et de restauration.

FAQ

Le RGPD impose-t-il AES-256 partout ?

Non. L’Art. 32 impose une sécurité adaptée au risque, sans désigner cet algorithme comme solution universelle. La configuration et la gestion des clés doivent aussi être évaluées.

Des données chiffrées sortent-elles automatiquement du RGPD ?

Non. Le chiffrement est une mesure de protection ; il ne suffit pas à rendre les données anonymes pour l’organisme qui peut les rattacher aux personnes.

Peut-on perdre l’accès à une sauvegarde chiffrée ?

Oui, si les moyens de déchiffrement deviennent indisponibles. Le plan de restauration doit couvrir les clés et les dépendances nécessaires.

Recevez nos analyses pratiques sur la sécurité des données.

Thiébaut Devergranne, docteur en droit et fondateur de donneespersonnelles.fr, travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.