콘텐츠로 건너뛰기

Chiffrement au repos pour PME : conformité CNIL, ANSSI et checklist

Guide pratique pour IT et PME : maîtriser les 4 couches du chiffrement au repos, gérer clés (KMS/HSM/BYOK) et respecter CNIL/ANSSI grâce à une checklist...

Chiffrement au repos pour PME : conformité CNIL, ANSSI et checklist

Module de stockage sécurisé dans un serveur

Le chiffrement au repos consiste à rendre illisibles les données stockées sur un disque, une sauvegarde ou une base de données, sauf pour qui détient la clé de déchiffrement. Il empêche un vol de disque ou une copie de sauvegarde de livrer des données exploitables. Sa limite majeure : il ne protège rien une fois qu’un système est actif et qu’un compte légitime, ou piraté, accède aux données déchiffrées.

En bref:

  • Le chiffrement au repos protège uniquement contre le vol de support physique ou la copie de sauvegarde, mais pas contre l’accès en système actif ou par compte piraté.
  • Quatre couches de chiffrement existent : disque entier, système de fichiers, base de données, et chiffrement applicatif, chacune répondant à des menaces spécifiques.
  • La gestion efficace des clés nécessite un modèle adapté comme le HSM ou le BYOK, avec des processus stricts pour génération, rotation et révocation.
  • Le chiffrement seul ne garantit pas la conformité réglementaire, qui requiert aussi des pratiques solides de gestion des clés et une évaluation des risques.
  • La segmentation des données, la planification de tests de restauration et la séparation des rôles améliorent significativement la sécurité opérationnelle.
Yundera
Gardez la maîtrise de vos données
Yundera propose des serveurs privés gérés en France, sans compétences techniques requises, pour conserver vos données et les exporter à tout moment.
Découvrir Yundera

Table des matières

Qu’est-ce que le chiffrement au repos et comment le différencier des autres états de la donnée ?

Une donnée « au repos » est une donnée stockée sur un support physique ou virtuel : disque dur, SSD, snapshot de machine virtuelle, fichier de sauvegarde, base de données inactive. Le chiffrement au repos transforme ce contenu en un bloc illisible sans la clé correspondante, protégeant les données stockées contre la lecture directe.

Trois états distincts régissent la vie d’une donnée, et confondre les deux premiers explique la plupart des projets de sécurité mal calibrés :

  • Au repos : la donnée dort sur un support (disque, sauvegarde, archive) et n’est manipulée par aucun processus actif.
  • En transit : la donnée circule entre deux points, un poste et un serveur par exemple, protégée typiquement par TLS.
  • En cours d’utilisation : la donnée est chargée en mémoire par une application qui la traite, la calcule ou l’affiche, souvent en clair à ce moment précis.

Un exemple concret éclaire la nuance. Un ordinateur portable volé dans un train, disque chiffré, ne livre rien à qui le démonte : les fichiers restent un bloc opaque. Le même ordinateur allumé, session ouverte, offre en revanche un accès direct aux fichiers en clair, car le système d’exploitation a déjà déchiffré le disque pour fonctionner. Le chiffrement au repos a fait son travail dans le premier cas et n’a plus aucune prise dans le second.

C’est cette bascule permanente entre les états qui pousse la CNIL à recommander une approche adaptée à chaque état de la donnée plutôt qu’une protection unique censée tout couvrir. Un disque chiffré, une sauvegarde chiffrée et une connexion TLS répondent à trois menaces différentes, et aucune des trois ne remplace les deux autres.

Les quatre couches techniques du chiffrement au repos, du disque à l’applicatif

Le chiffrement au repos ne se joue pas à un seul niveau. Il se décline en quatre couches qui s’empilent, chacune protégeant un scénario de menace différent et avec un coût opérationnel croissant.

La couche disque entier chiffre tout le volume physique : BitLocker sous Windows, LUKS sous Linux, FileVault sur macOS. Elle protège contre le vol matériel et la perte de disque, mais devient transparente dès que le système démarre. Un attaquant qui obtient un accès à distance sur une machine allumée contourne entièrement cette protection.

La couche système de fichiers chiffre des répertoires ou des volumes logiques précis plutôt que le disque entier, ce qui permet de gérer des clés différentes par utilisateur ou par service sur une même machine. C’est le niveau qu’utilisent des systèmes multi-utilisateurs pour isoler les données de chaque compte.

La couche base de données, souvent nommée TDE (chiffrement transparent des données), chiffre les fichiers de la base sans que les requêtes SQL n’aient à s’en soucier. Elle couvre bien le vol de fichiers de base, mais un compte disposant de droits de lecture légitimes voit les données en clair, requête après requête.

La couche applicative, ou chiffrement au niveau du champ, chiffre une donnée précise, un numéro de carte, un champ médical, avant même qu’elle n’atteigne la base. C’est la seule couche qui reste efficace même face à un administrateur de base de données malveillant ou une fuite de sauvegarde complète, au prix d’une intégration plus lourde dans le code applicatif.

Couche Ce qu’elle protège Ce qu’elle ne protège pas Complexité de mise en œuvre
Disque entier Vol matériel, disque perdu Accès système actif Faible
Système de fichiers Isolation par utilisateur/service Compte compromis sur le même volume Moyenne
Base de données (TDE) Vol de fichiers de base Requêtes d’un compte légitime Moyenne
Applicatif (chiffrement de champ) Fuite de base, admin malveillant Erreurs de logique applicative Élevée

Le choix de l’algorithme suit une règle simple mais souvent ignorée : AES en mode XTS convient au chiffrement bloc (disque, volume), tandis que AES en mode GCM, une forme de chiffrement authentifié, s’impose pour le chiffrement applicatif et les objets. Utiliser XTS pour chiffrer un champ applicatif, ou GCM pour un volume entier, crée des contraintes de performance ou des failles d’intégrité que peu d’équipes anticipent avant de les subir en production.

Gestion des clés : modèles KMS, HSM, BYOK et HYOK, et bonnes pratiques opérationnelles

Un chiffrement, même robuste, ne vaut que ce que vaut la gestion de sa clé. Un algorithme solide protégeant une clé stockée dans un fichier texte à côté des données chiffrées n’offre aucune protection réelle.

Un KMS (service de gestion des clés) orchestre la création, la distribution et la rotation des clés de chiffrement à l’échelle d’une infrastructure. Un HSM (module matériel de sécurité) est le composant physique ou logique qui génère et protège la clé racine, celle dont dépendent toutes les autres. L’ANSSI recommande qu’une racine de confiance repose idéalement sur un HSM certifié plutôt que sur un simple fichier protégé par mot de passe.

Quatre modèles structurent le marché aujourd’hui, avec des implications très différentes en souveraineté et en coût :

  1. Provider-managed : le fournisseur cloud génère et détient les clés. Simple à activer, mais le fournisseur conserve techniquement la capacité de déchiffrer vos données.
  2. CMK (clé gérée par le client) : vous gardez le contrôle des clés via un coffre comme Azure Key Vault, tandis que le chiffrement s’exécute côté fournisseur.
  3. BYOK (apportez votre propre clé) : vous générez la clé en dehors du fournisseur, puis l’importez dans son environnement pour l’usage courant.
  4. HYOK / XKS (gardez votre propre clé) : la clé ne quitte jamais votre infrastructure, le fournisseur devant l’appeler à chaque opération de chiffrement ou déchiffrement.

Ces quatre modèles répondent à une question simple que pose justement la CNIL : qui, techniquement, peut demander un déchiffrement, et où cette demande transite-t-elle ? Le chiffrement côté client garde la réponse entièrement hors de portée du fournisseur cloud, contrairement aux modèles provider-managed.

Le cycle de vie d’une clé comporte six moments critiques : génération, stockage, distribution, rotation, révocation, destruction. Chacun doit faire l’objet d’une procédure écrite, testée, et rejouée périodiquement, pas seulement documentée sur un wiki qui prend la poussière.

Conseil de pro : Ne testez jamais la rotation de vos clés uniquement en environnement de production. Une rotation ratée peut rendre des volumes importants de données définitivement illisibles ; validez la procédure complète, rotation et restauration, sur un jeu de données de test avant chaque déploiement réel.

Séparer les rôles reste la pratique la plus négligée : la personne qui administre les serveurs ne devrait pas être celle qui détient les droits d’accès au KMS. Un service centralisé et journalisé permet de savoir précisément qui a demandé quelle opération de déchiffrement, et quand.

Ce que le chiffrement au repos ne protège pas

L’expression même de « données au repos » induit en erreur : dans la plupart des environnements de production, les données ne dorment jamais vraiment, elles sont constamment lues, écrites et recopiées par des processus actifs. Le chiffrement au repos n’est donc qu’une brique parmi d’autres dans une défense en profondeur.

Voici les scénarios où cette protection n’intervient tout simplement pas :

  • Un compte compromis avec des droits légitimes voit les données exactement comme leur propriétaire, chiffrement ou non.
  • Une injection SQL ou une faille applicative extrait des données déjà déchiffrées par l’application pour répondre à une requête normale.
  • Un rançongiciel actif sur un serveur chiffre à son tour des données déjà déchiffrées à la volée, rendant inutile la couche de protection sous-jacente.
  • Une erreur humaine ou un risque interne (export non autorisé, copie sur clé USB) contourne la protection dès que la personne dispose d’un accès normal.

Face aux rançongiciels en particulier, la vraie ligne de défense n’est pas le chiffrement du disque mais l’existence de sauvegardes immuables, isolées du réseau et testées en restauration. Un disque chiffré ne redonne aucune donnée si le fichier a été détruit ou corrompu par un attaquant déjà connecté.

C’est précisément dans ces cas que le chiffrement applicatif reprend son sens : chiffrer un champ sensible avant qu’il n’atteigne la base limite ce qu’une injection SQL ou un compte compromis peut réellement extraire, même si la protection ajoute de la complexité au code.

Conformité et recommandations : RGPD, CNIL et ANSSI

L’article 32 du RGPD cite explicitement le chiffrement comme exemple de mesure technique appropriée pour protéger des données à caractère personnel, sans jamais l’imposer comme obligation absolue et uniforme. Le texte demande une mesure proportionnée au risque, ce qui signifie que chiffrer une base de clients sensibles n’appelle pas le même effort qu’un simple fichier de contacts professionnels publics.

La CNIL et l’ANSSI complètent ce cadre légal par des recommandations opérationnelles concrètes :

  • La CNIL distingue quatre niveaux de chiffrement applicables dans un environnement cloud et recommande d’adapter le niveau retenu à la sensibilité réelle des données, pas à un standard générique.
  • L’ANSSI fixe les primitives cryptographiques à privilégier (AES, modes AEAD, tailles de clés minimales) et insiste sur une racine de confiance matérielle plutôt que logicielle.
  • NIS2 et DORA, applicables respectivement aux entités essentielles et au secteur financier, renforcent les exigences de traçabilité et de résilience des mesures de chiffrement.
  • PCI-DSS impose un chiffrement au repos strict pour toute donnée de carte bancaire stockée, avec des contrôles d’audit réguliers.
  • ISO 27001 intègre le chiffrement dans son référentiel de contrôles de sécurité de l’information, sans en faire une case à cocher isolée du reste du système de management.

Ces textes convergent sur un point souvent oublié : le chiffrement seul ne suffit jamais à démontrer la conformité. Une organisation doit aussi prouver qu’elle gère ses clés correctement et qu’elle a évalué le risque réel avant de choisir son niveau de protection, un exercice détaillé dans notre guide sur la conformité RGPD dans le cloud.

Mettre en œuvre le chiffrement au repos : décisions pratiques et compromis

Se lancer dans le chiffrement au repos sans méthode aboutit presque toujours à deux écueils : chiffrer trop, au détriment des performances, ou chiffrer trop peu, en laissant filer les données réellement sensibles.

  1. Cartographier et classifier vos données avant toute chose. Chiffrer sans distinction coûte en performance et complexifie inutilement la gestion des clés pour des données qui n’en valent pas l’effort.
  2. Choisir entre chiffrement côté client et côté fournisseur selon l’usage réel. Un usage grand public bénéficie souvent du confort du chiffrement côté fournisseur ; une donnée réglementée ou stratégique justifie le contrôle total qu’offre le chiffrement côté client.
  3. Faire correspondre l’algorithme à la couche visée. XTS pour un volume ou un disque, GCM pour un champ applicatif ou un objet stocké : l’inverser crée des angles morts de sécurité.
  4. Planifier les tests opérationnels dès la conception, pas après le déploiement : rotation de clé, restauration complète depuis une sauvegarde chiffrée, et simulation d’un incident de perte de clé.

La classification des données mérite qu’on s’y arrête. Une donnée publique sur un site marketing ne demande pas le même traitement qu’un dossier de ressources humaines ou qu’une base de santé. Justifier le périmètre chiffré par cette classification, plutôt que par un réflexe de sécurité générique, permet aussi de justifier plus facilement les coûts auprès d’une direction financière.

Conseil de pro : Documentez, pour chaque catégorie de données, la couche de chiffrement retenue et la raison de ce choix. Cette traçabilité, souvent négligée, devient précieuse lors d’un audit RGPD ou d’une certification ISO 27001, quand il faut justifier pourquoi telle donnée est protégée ainsi et pas autrement.

L’échec le plus fréquent ne vient pas d’un mauvais algorithme mais d’une procédure de récupération jamais testée en conditions réelles. Une rotation de clé qui échoue silencieusement peut rendre des volumes entiers de données définitivement inaccessibles, un risque au moins aussi grave qu’une fuite.

Checklist opérationnelle rapide pour TPE, PME et utilisateurs techniques

Avant de lancer un projet de chiffrement complet, une vérification de quelques heures suffit à repérer les failles les plus courantes.

  • Postes de travail : le disque de chaque ordinateur professionnel est-il chiffré (BitLocker, FileVault, LUKS) et cette configuration est-elle vérifiée à l’inventaire, pas seulement à l’installation initiale ?
  • Sauvegardes : les fichiers de sauvegarde sont-ils chiffrés avec une clé distincte de celle des données de production, et stockés sur un support isolé du réseau principal ? Pour en savoir plus, consultez notre guide pratique sur le backup dati nel gestionale ristorante.
  • Accès et droits : qui, précisément, peut demander une opération de déchiffrement, et cette liste a-t-elle été revue depuis moins de six mois ?
  • KMS ou coffre de clés : les clés sont-elles centralisées dans un service dédié, journalisé, plutôt que dispersées dans des fichiers de configuration ?
  • Question à poser à tout fournisseur cloud : propose-t-il un modèle de clé gérée par le client (CMK) ou reste-t-il sur un chiffrement provider-managed par défaut ?
  • Test de restauration : une restauration complète depuis une sauvegarde chiffrée a-t-elle été rejouée avec succès au cours des douze derniers mois ?

Un chiffre à retenir : selon l’ANSSI, la solidité d’un chiffrement dépend moins de la longueur de la clé que de la rigueur du contrôle sur qui peut demander son usage, un point que beaucoup de PME découvrent seulement après un incident.

Cette checklist ne remplace pas un audit complet, mais elle révèle en quelques heures les angles morts les plus fréquents. Notre checklist de conformité RGPD dans le cloud approfondit la partie réglementaire pour les équipes qui doivent documenter ces contrôles.

Perspective Yundera : un serveur privé géré simplifie-t-il la gestion des clés ?

La complexité du chiffrement au repos vient rarement de l’algorithme, mais de la dispersion des responsabilités : qui détient la clé, qui gère la rotation, qui peut exporter les données en cas de litige avec le fournisseur. Un serveur privé hébergé en France, avec export des données garanti à tout moment, réduit une partie de cette incertitude structurelle, puisque le titulaire des données reste identifiable et le chemin de sortie reste toujours ouvert.

Cela ne dispense pas pour autant des bonnes pratiques détaillées plus haut : classification des données, tests de restauration, séparation des rôles restent nécessaires quelle que soit l’infrastructure choisie. Un serveur géré simplifie l’exploitation quotidienne, il ne remplace pas la discipline opérationnelle. Pour une organisation qui manipule des volumes de données très spécifiques ou des contraintes réglementaires sectorielles lourdes, une architecture applicative sur mesure reste parfois le meilleur choix.

— Yundera

Yundera, une alternative aux clouds publics pour qui veut garder la main sur ses clés et ses données

Certaines solutions alternatives au cloud public permettent de savoir précisément où vivent ses données et de pouvoir les récupérer sans négociation. Contrairement à un fournisseur provider-managed où le chiffrement reste sous contrôle du prestataire, Yundera héberge votre serveur privé en France, garantit l’export de vos données à tout moment, et ne collecte ni ne revend jamais rien.

Yundera

La solution peut inclure des applications open source pour divers usages, accessibles via un domaine personnalisé sans compétence technique requise. Pour une entreprise ou un indépendant qui a lu ce guide et compris l’importance de maîtriser le périmètre chiffré et l’accès aux clés, certaines infrastructures éthiques permettent que cette maîtrise reste entre vos mains. Les TPE et PME qui cherchent à réduire leur dépendance à un fournisseur tiers tout en simplifiant leur gestion quotidienne trouveront dans notre page dédiée aux petites entreprises des cas d’usage concrets. Découvrez l’offre de serveur privé Yundera et évaluez, à partir de votre propre classification des données, si un hébergement souverain correspond à vos besoins.

Sources

Recommandations

분류 Français
로그인 의견을 남기기