Chiffrement des données personnelles : décider, déployer et prouver
Le chiffrement rend une information illisible sans la clé appropriée. Dans une organisation, cette définition simple cache trois décisions différentes : quels flux protéger, à quel endroit chiffrer et qui peut utiliser les clés. L’article 32 du RGPD cite le chiffrement parmi les mesures possibles de sécurité adaptées au risque. Il n’impose ni un algorithme unique ni le chiffrement de chaque donnée, au repos et en transit, dans toute circonstance. Une décision motivée doit tenir compte des personnes concernées, des accès, du scénario de compromission et de l’état des connaissances.
Ce guide aide le DPO, le RSSI et le responsable applicatif à traduire ce principe en architecture vérifiable. Il distingue le chiffrement du hachage et de la pseudonymisation, puis traite les clés, les sauvegardes, les prestataires et les violations. Les recommandations de l’ANSSI et de la CNIL éclairent le choix technique ; leur portée juridique dépend du contexte. Le RGS a un champ spécifique pour les autorités administratives et sert aussi de référence technique à d’autres acteurs.
1. Partir du risque et des parcours de données
Un inventaire utile suit les données depuis leur collecte jusqu’à leur suppression : navigateur, API, files de messages, stockage principal, exports, journaux, sauvegardes et supports de maintenance. Pour chaque étape, notez le type de données, la personne qui peut y accéder, la clé éventuelle et le tiers qui exploite le système. Une base chiffrée peut coexister avec un export CSV envoyé par courriel en clair ; le risque réel suit alors l’export. La cartographie du système d’information et le registre des traitements fournissent les deux vues complémentaires.
Exemple hypothétique : une clinique transmet un résultat au patient et au médecin. TLS protège le trajet entre les appareils et le serveur. Le chiffrement du disque protège certains scénarios de vol physique. Aucun des deux n’empêche un compte médical détourné de lire le dossier dans l’application. Il faut aussi contrôler les habilitations, les sessions et la journalisation. Le chiffrement répond à un scénario de menace déterminé ; il ne remplace pas les autres contrôles.
Dans l’analyse de risque, confrontez au moins la perte d’un ordinateur portable, l’exfiltration d’une sauvegarde, l’accès illégitime d’un administrateur, l’interception d’un flux et la compromission du compte applicatif. Pour chaque scénario, indiquez si le chiffrement réduit effectivement l’exposition. Si la clé est stockée sur le même support avec les mêmes droits que les données, le bénéfice peut être faible. Une AIPD peut être nécessaire pour un traitement susceptible d’engendrer un risque élevé ; elle documente aussi les limites résiduelles de la mesure.
2. Distinguer les mécanismes
Le chiffrement vise la confidentialité et permet de retrouver le contenu grâce à une clé. Le hachage cryptographique calcule une empreinte ; il ne se « déchiffre » pas. Pour un mot de passe, une fonction spécialisée et coûteuse à calculer, associée à un sel, est adaptée : la fiche CNIL sur le chiffrement, le hachage et la signature cite notamment Argon2, bcrypt, scrypt et PBKDF2. Une simple empreinte SHA-256 d’un mot de passe n’a pas le même rôle. La signature sert à vérifier l’origine et l’intégrité, sans garder nécessairement le contenu secret.
La pseudonymisation remplace un identifiant direct par une référence ; les données demeurent personnelles si une réidentification reste possible. L’anonymisation, lorsque ses conditions exigeantes sont réellement remplies, sort les données du champ des données personnelles. La tokenisation d’un numéro dans une application peut être utile, mais dépend de la protection du coffre qui fait la correspondance. Une ligne de registre « données chiffrées » ne suffit donc pas : précisez la technique, son champ et l’endroit où une identité ou un contenu peut réapparaître.
3. Protéger les flux sans oublier les extrémités
Le guide ANSSI relatif à TLS, publié en 2020, présente des paramètres de sécurité pour les échanges. Dans un service web, privilégiez une configuration moderne, des logiciels maintenus et des suites cryptographiques compatibles avec les clients réellement autorisés. TLS 1.3 peut simplifier les choix ; la prise en charge de TLS 1.2 doit être configurée de façon sûre lorsqu’elle reste nécessaire. Testez les certificats, la chaîne de confiance, leur renouvellement et la désactivation des protocoles dépassés. Une mention « HTTPS » dans un cahier des charges ne prouve pas que toutes les API et interfaces d’administration sont couvertes.
Le TLS s’arrête là où la connexion est terminée : répartiteur de charge, proxy, fournisseur de messagerie ou application. Dessinez ces points de terminaison et vérifiez le tronçon suivant. Un flux entre deux services internes peut traverser un réseau partagé ou un prestataire ; son caractère « interne » ne garantit pas sa confidentialité. Pour une messagerie médicale, distinguez le canal sécurisé, l’authentification des correspondants et un éventuel chiffrement de bout en bout. Ce dernier protège contre certains intermédiaires, mais peut compliquer la recherche, la reprise et le contrôle des pièces ; choisissez-le à partir du besoin.
Un certificat expiré ou un proxy qui accepte des paramètres faibles rend inopérante une politique conçue sur papier. Conservez des résultats de tests de configuration, les dates de renouvellement, le responsable de l’alerte et un essai de bascule. La revue des flux doit inclure les applications mobiles et les connecteurs anciens, qui échappent souvent au premier inventaire.
4. Choisir la couche de chiffrement au repos
Le chiffrement complet d’un disque ou d’un volume protège surtout contre la perte du matériel et certains accès au support hors fonctionnement. Sur un poste nomade, combinez-le avec le verrouillage de session et une gestion des clés de récupération. Dans un serveur en fonctionnement, une application autorisée voit normalement les données en clair. Chiffrer le volume ne limite donc pas automatiquement la lecture par un compte administrateur compromis.
Le chiffrement de base ou de colonne répond à d’autres scénarios : export non autorisé, copie d’un fichier, séparation entre opérateurs de stockage et application. Il faut préciser qui déchiffre et à quel moment. Si l’application détient la clé et donne accès à tous les dossiers à un compte unique, le contrôle d’accès applicatif reste le point décisif. Le chiffrement applicatif sélectif peut protéger certains champs contre le personnel d’exploitation, au prix d’une recherche et d’une maintenance plus complexes. Faites un essai avec les opérations métier, les migrations et la restauration avant d’arrêter la conception.
Les sauvegardes doivent être évaluées comme un système distinct. Elles peuvent contenir des bases, fichiers, secrets ou instantanés que le stockage principal protège autrement. Vérifiez leur chiffrement, leurs droits, la séparation éventuelle des clés et surtout la restauration effective. Une sauvegarde illisible après la perte du seul compte qui détenait la clé ne satisfait pas l’objectif de disponibilité de l’article 32. Le test doit inclure un opérateur qui n’a pas créé la sauvegarde et une procédure d’urgence documentée.
5. Gouverner les clés et les secrets
Une décision cryptographique comprend le cycle de vie de la clé : génération, distribution, stockage, usage, sauvegarde, révocation et destruction. Un KMS ou un HSM peut rendre ces opérations auditables et limiter l’exposition des clés, mais son nom commercial ne prouve pas la qualité du paramétrage. Séparez les droits d’administration du stockage, de l’application et des clés lorsque le risque le justifie. Contrôlez les comptes de service, les appels de déchiffrement et les droits temporaires. Le guide de la CNIL sur la sécurité des données demande aussi une procédure de gestion des clés et certificats.
La rotation n’est pas une formule « une fois par an pour toutes les clés ». Déterminez sa périodicité selon le type de clé, son exposition, la durée d’utilisation, les possibilités de réencryptage et les événements déclencheurs. Une suspicion de compromission peut imposer une réaction immédiate. Pour une clé de sauvegarde, la rotation doit laisser restaurables les générations encore conservées. Pour les clés TLS, le renouvellement du certificat et la protection de la clé privée suivent un autre calendrier. Consignez la version utilisée par chaque jeu de données et testez la révocation sur un environnement représentatif.
Exemple hypothétique : un prestataire perd un compte d’administration du KMS. L’équipe doit savoir quelles clés ce compte pouvait utiliser, quels journaux vérifier, quelles données étaient accessibles et comment remplacer les clés sans couper les soins ou le service. Une procédure qui dit seulement « révoquer la clé » est insuffisante si aucune copie saine ni plan de réencryptage n’existe. Faites cet exercice avant l’incident avec les métiers et le prestataire.
6. Algorithmes : éviter les slogans
La fiche CNIL cite AES avec un mode adapté et ChaCha20 avec Poly1305 comme exemples de chiffrement symétrique reconnu. Le choix concret dépend aussi de la bibliothèque, du mode, des aléas, de l’authentification du message et de la maintenance. Un AES correctement implémenté avec des clés protégées est plus utile qu’une taille affichée comme « maximale » avec un mode inapproprié. Évitez de créer un protocole cryptographique maison. Appuyez-vous sur les versions maintenues des bibliothèques et sur une revue spécialisée lorsque l’architecture est sensible.
L’annexe B1 du RGS traite des mécanismes cryptographiques dans son champ. Il serait trompeur d’en tirer une règle générale « AES-256 et RSA-3072 obligatoires pour tout responsable RGPD jusqu’en 2030 ». Les recommandations évoluent avec les usages et la durée de confidentialité recherchée. Si un texte ou un contrat sectoriel renvoie à un référentiel précis, vérifiez sa version et son champ plutôt que de recopier une table de tailles hors contexte.
Pour les mots de passe, la politique de mots de passe ANSSI et les recommandations CNIL doivent être lues avec le modèle d’attaque du service. Mesurez le coût du hachage sur l’infrastructure réelle, gérez les comptes compromis et prévoyez une migration progressive des anciennes empreintes. N’affichez pas un nombre d’itérations universel : il devient rapidement obsolète et varie selon l’algorithme.
7. Prestataires, données de santé et transferts
Un hébergeur qui annonce un stockage chiffré peut conserver lui-même les clés et l’accès au contenu en clair par son service. Demandez qui administre les clés, où se trouvent les données et les sauvegardes, quels sous-traitants interviennent, ainsi que les accès de support. Vérifiez les clauses de l’article 28 et les instructions de suppression ou de restitution. La localisation et les transferts internationaux forment une analyse distincte du chiffrement : une clé en Europe ne neutralise pas mécaniquement tous les accès depuis un pays tiers.
Pour les données de santé, lisez le champ de la certification HDS : elle dépend notamment de l’hébergement numérique pour le compte d’un tiers dans les conditions du Code de la santé publique. Le certificat indique les activités couvertes ; il ne signifie pas que chaque application du client est automatiquement conforme. Le référentiel HDS v2.0 publié en 2024 est le point de référence après la transition achevée le 16 mai 2026. Le chiffrement reste une mesure à vérifier dans l’architecture concrète.
8. Violation : ce que change réellement le chiffrement
L’article 34, paragraphe 3, point a, du RGPD peut dispenser de communiquer une violation aux personnes si les mesures appliquées aux données touchées les rendent incompréhensibles pour toute personne non autorisée. Il faut établir que les clés ne sont pas compromises, que la bonne version de sauvegarde était chiffrée et qu’aucun extrait en clair n’a été pris. Ce n’est pas une dispense automatique de documenter l’incident ni de notifier la CNIL au titre de l’article 33 lorsque le risque le justifie. La procédure de notification doit conserver les preuves de cette appréciation.
Exemple hypothétique : un ordinateur chiffré est volé alors qu’il était éteint, sans clé dans sa sacoche. L’équipe vérifie l’état réel du chiffrement, les comptes, les copies synchronisées et les journaux avant d’évaluer le risque. Si le même ordinateur était déverrouillé ou si un export en clair se trouvait sur une clé USB, la conclusion change. La qualification dépend des faits établis, pas de la présence d’une icône de cadenas dans l’inventaire.
9. Vérifier dans la durée
Pour chaque mesure, conservez un propriétaire, un test et une preuve datée : inventaire des flux, configuration TLS contrôlée, état du chiffrement des postes, droits d’usage des clés, restauration d’une sauvegarde et revue des prestataires. Reliez les écarts à une décision de risque et à une date de correction. L’audit RGPD et une analyse EBIOS Risk Manager peuvent aider à hiérarchiser les scénarios, sans transformer toute recommandation ANSSI en obligation juridique uniforme.
Le bon indicateur n’est pas seulement le pourcentage de disques chiffrés. Mesurez aussi les flux inconnus, les sauvegardes non testées, les comptes capables de déchiffrer un grand volume et les versions de clés impossibles à révoquer. Si l’un de ces points se dégrade, la décision initiale doit être revue. Un chiffrement défendable est celui dont le périmètre, l’effet et les limites peuvent être expliqués lors d’un incident réel.