3 Le chiffrement des données fait partie de ces termes présents dans chaque référentiel de conformité, chaque liste de contrôle d’audit de sécurité et chaque présentation commerciale de fournisseur. Pourtant, il est souvent mal compris au niveau qui compte vraiment pour les organisations réglementées. La plupart des équipes savent que le chiffrement est obligatoire. Bien moins savent précisément ce qu’il fait, où il doit être appliqué, contre quoi il ne protège pas, et comment les choix de chiffrement au niveau de la couche de stockage influent sur la conformité au RGPD, à HIPAA, à FIPS, à NIS2 et à DORA. Ce guide s’adresse aux responsables de la conformité, aux responsables IT du secteur public et aux architectes de stockage qui doivent aller au-delà de la définition de surface et comprendre le chiffrement dans le contexte du stockage de données d’entreprise, là où se prennent les décisions concrètes et où l’exposition en matière de conformité se crée ou se referme. Ce que fait réellement le chiffrement des données Fondamentalement, le chiffrement des données consiste à transformer des données lisibles (le texte en clair) en un format illisible (le texte chiffré) à l’aide d’un algorithme mathématique et d’une clé de chiffrement. Seule une personne disposant de la bonne clé de déchiffrement peut inverser le processus et lire les données d’origine. L’objectif est simple : si des données chiffrées sont consultées par une personne non autorisée (à la suite d’une violation, d’une menace interne, d’une autorisation mal configurée ou de la saisie d’un support de stockage), elles restent illisibles sans la clé. Le chiffrement n’empêche pas l’accès non autorisé. Il rend cet accès inutile. Cette distinction compte pour la conformité. Les réglementations n’exigent pas qu’aucune violation ne se produise jamais. Elles exigent que, lorsque des données sont consultées sans autorisation, le préjudice soit limité. Le chiffrement est le principal contrôle technique qui répond à cette exigence. L’article 32 du RGPD, par exemple, cite explicitement le chiffrement comme mesure technique appropriée pour protéger les données personnelles. Dans le cadre de HIPAA, le chiffrement des informations de santé protégées, au repos et en transit, est une spécification de mise en œuvre dite « addressable » que, dans la pratique, la plupart des entités concernées appliquent comme une obligation. Comprendre ce que fait le chiffrement, et ce qu’il ne fait pas, est le point de départ pour bâtir une architecture de stockage qui satisfait réellement aux obligations de conformité, au lieu de seulement en donner l’apparence. Chiffrement au repos ou chiffrement en transit Le chiffrement des données s’applique au stockage d’entreprise dans deux contextes principaux, que les référentiels de conformité traitent différemment. Le chiffrement au repos protège les données stockées sur des supports physiques : disques durs, SSD, bandes ou tout stockage persistant. Si un disque est retiré d’un datacenter, volé ou mis au rebut sans effacement sécurisé, le chiffrement au repos garantit que ses données restent illisibles. Il protège aussi contre l’accès non autorisé à l’infrastructure de stockage brute, sous la couche applicative ou la couche API. Le chiffrement en transit protège les données lorsqu’elles circulent entre des systèmes : entre un client et une plateforme de stockage, entre datacenters, entre une infrastructure on-premise et des environnements cloud. Sans chiffrement en transit, les données qui circulent sur les réseaux peuvent être interceptées et lues. TLS (Transport Layer Security) est le mécanisme standard de chiffrement en transit dans les environnements de stockage modernes, généralement imposé via HTTPS pour toutes les communications de l’API S3. La plupart des référentiels de conformité exigent les deux. Un stockage S3 conforme pour les environnements réglementés (en anglais) impose le chiffrement au niveau de l’objet au repos et exige que toutes les données en transit passent par des connexions chiffrées. Traiter l’un ou l’autre comme facultatif crée une faille de conformité que les auditeurs trouveront. La norme de chiffrement qui compte vraiment : AES-256 Lorsque la documentation d’un stockage d’entreprise parle de chiffrement, il s’agit presque toujours d’AES (Advanced Encryption Standard), et plus précisément d’AES-256, qui utilise une clé de 256 bits. AES-256 est la norme mondiale de chiffrement des données sensibles au repos. Elle est approuvée par le NIST, exigée par FIPS 140-2 et FIPS 140-3 pour les charges de travail fédérales américaines, et acceptée par tous les grands référentiels de conformité, dont le RGPD, HIPAA, PCI-DSS et NIS2. Une clé de 256 bits signifie qu’il existe 2²⁵⁶ clés possibles, un nombre si grand que les attaques par force brute sont irréalisables avec toute technologie prévisible. Avantage pratique pour les environnements de stockage d’entreprise : les processeurs modernes intègrent une accélération matérielle des opérations AES, ce qui signifie que le chiffrement AES-256 peut être appliqué à l’ensemble d’un stockage de plusieurs pétaoctets sans surcoût de performances significatif. Inutile d’activer le chiffrement uniquement pour les catégories de données sensibles : il peut et doit être imposé par défaut à tous les objets. Cela élimine le risque opérationnel de voir des données non chiffrées dans l’environnement parce que quelqu’un a oublié d’activer le paramètre. Les modes de chiffrement du stockage compatible S3 Pour les organisations qui utilisent un stockage objet compatible S3 (désormais la majorité des environnements de données d’entreprise), le chiffrement est proposé via trois modes standard de chiffrement côté serveur. Comprendre leurs différences est essentiel pour les décisions d’architecture de conformité. SSE-S3 (chiffrement côté serveur avec des clés gérées par la plateforme) est le mode de base. La plateforme de stockage chiffre automatiquement chaque objet en AES-256. Les clés sont générées et gérées en interne. Pour de nombreuses charges de travail, ce mode offre un chiffrement robuste avec une complexité opérationnelle minimale. Sa limite : la plateforme de stockage détient à la fois les données et les clés, ce qui peut ne pas satisfaire les exigences de conformité imposant de séparer la gestion des clés du stockage des données. SSE-KMS (chiffrement côté serveur avec un système externe de gestion des clés) introduit une gouvernance externe des clés. Les clés de chiffrement sont gérées par un KMS distinct, on-premise ou hébergé dans le cloud. Cela impose une frontière de sécurité essentielle : le système de stockage détient les données chiffrées, mais les clés qui les déchiffrent résident dans un système séparé, contrôlé de façon indépendante. Cette séparation s’aligne directement sur les principes d’architecture zero trust et répond à l’exigence de conformité selon laquelle les organisations doivent garder le contrôle de leurs propres clés de chiffrement. Elle permet aussi le crypto-shredding : rendre des données définitivement illisibles en supprimant la clé de chiffrement plutôt que les données elles-mêmes, ce qui est précieux pour les obligations de droit à l’effacement du RGPD. SSE-C (chiffrement côté serveur avec des clés fournies par le client) donne au client un contrôle total : il fournit la clé de chiffrement à chaque requête API. La plateforme de stockage effectue le chiffrement, mais ne conserve jamais la clé. Ce modèle offre un contrôle maximal des clés au prix d’une complexité opérationnelle nettement plus élevée, et il est généralement réservé à des cas d’usage précis exigeant une sécurité très élevée. Pour la plupart des entreprises réglementées, SSE-KMS associé à un module matériel de sécurité (HSM) externe représente le bon équilibre : un chiffrement robuste, un contrôle indépendant des clés et une chaîne de gestion des clés auditable que les équipes de conformité peuvent présenter aux régulateurs. Pourquoi la gestion des clés fait gagner ou perdre la conformité Le chiffrement en lui-même est un problème bien résolu. AES-256 est robuste sur le plan cryptographique. Sa mise en œuvre est standardisée. Son surcoût de performances est maîtrisable. Ce qui distingue les organisations dotées d’une posture de chiffrement réellement solide de celles qui se contentent de cocher une case, c’est la gestion des clés. Les clés de chiffrement doivent être protégées avec au moins autant de rigueur que les données qu’elles protègent. Si les clés sont stockées avec les données qu’elles chiffrent, un attaquant qui accède à l’environnement de stockage accède à tout. Si les clés ne sont jamais renouvelées, une seule compromission passée peut exposer toutes les données chiffrées avec cette clé. Si l’accès aux clés n’est pas audité, impossible de démontrer aux régulateurs que les contrôles de chiffrement ont fonctionné comme prévu. Pour les responsables de la conformité, les questions de gestion des clés les plus importantes sont les suivantes : qui détient les clés ? L’organisation peut-elle démontrer que l’accès aux clés est journalisé et auditable ? Les clés sont-elles renouvelées selon un calendrier défini ? Existe-t-il une procédure de révocation des clés et de crypto-shredding lorsque des données doivent être supprimées ? L’organisation peut-elle démontrer, lors d’un audit, la séparation entre les clés et l’infrastructure de stockage ? La conformité FIPS 140-2 et FIPS 140-3 (en anglais), exigée pour les charges de travail fédérales américaines et les programmes de défense, s’applique spécifiquement aux modules cryptographiques qui effectuent les opérations de chiffrement et de gestion des clés, et non aux systèmes de stockage dans leur ensemble. Comprendre cette distinction compte lors des achats : une plateforme de stockage n’est pas certifiée FIPS dans sa globalité. Ses composants cryptographiques doivent être validés, et la configuration déployée doit correspondre à l’environnement validé. C’est là que les évaluateurs techniques et les équipes de conformité doivent travailler en étroite collaboration. Chiffrement et immuabilité : deux contrôles qui doivent fonctionner ensemble Une idée fausse courante en architecture de conformité veut que le chiffrement suffise à protéger les données réglementées. Ce n’est pas le cas, et la faille apparaît dans les scénarios de ransomware. Les attaques par ransomware ciblent de plus en plus l’infrastructure de sauvegarde et de stockage, car les attaquants savent qu’il est plus rentable de détruire la capacité de restauration d’une organisation que de voler ses données. Lorsqu’un attaquant obtient un accès administrateur à un environnement de stockage, il peut supprimer ou écraser les données qui ne sont pas protégées par l’immuabilité, même si elles sont chiffrées. Le chiffrement empêche l’attaquant de lire les données. Il ne fait rien pour l’empêcher de les détruire. C’est pourquoi l’immuabilité S3 Object Lock (en anglais) et le chiffrement doivent être appliqués ensemble, comme des contrôles complémentaires. L’immuabilité imposée au niveau de l’objet garantit que les données ne peuvent être ni supprimées ni écrasées pendant une période de conservation définie, quels que soient les identifiants dont dispose l’attaquant. Le chiffrement garantit que les données consultées sans autorisation restent illisibles. Ensemble, ils couvrent les deux principaux vecteurs de menace contre lesquels les référentiels de conformité sont conçus : l’accès non autorisé et la destruction non autorisée. Un stockage S3 conforme pour les secteurs réglementés (en anglais) considère ces deux contrôles comme indissociables. Le verrouillage de conformité au niveau de l’objet empêche la suppression. Le chiffrement AES-256 empêche la lecture non autorisée. Leur combinaison crée de fait une isolation logique (air gap) : des données illisibles pour les personnes non autorisées et indestructibles, même par des personnes disposant d’identifiants administrateur. Les obligations de chiffrement dans les principaux référentiels de conformité Pour les responsables de la conformité qui gèrent des obligations relevant de plusieurs régimes réglementaires, il est utile de comprendre comment l’accent mis sur le chiffrement varie d’un référentiel à l’autre. Le RGPD exige des mesures techniques appropriées pour protéger les données personnelles et cite explicitement le chiffrement en exemple. Plus précisément, il exige que les organisations soient en mesure de démontrer que ces mesures ont été appliquées : les pistes d’audit de la configuration du chiffrement, les journaux d’accès aux clés et les preuves de l’application du chiffrement comptent donc autant que le chiffrement lui-même. Les exigences du RGPD en matière de stockage des données (en anglais) vont au-delà du chiffrement et couvrent la conservation, la suppression et la capacité à respecter les droits des personnes concernées à grande échelle. HIPAA exige des entités concernées qu’elles chiffrent les informations de santé protégées au repos et en transit, au titre d’une spécification « addressable » : les organisations doivent soit l’appliquer, soit documenter une alternative justifiée. Dans la pratique, justifier l’absence de chiffrement est bien plus lourd que de simplement mettre en œuvre AES-256, et la plupart des auditeurs le considèrent comme obligatoire de fait. FIPS 140 encadre les modules cryptographiques utilisés pour le chiffrement dans les environnements fédéraux et de défense américains. Il porte sur la mise en œuvre du chiffrement, et pas seulement sur sa présence : les algorithmes utilisés, les longueurs de clé et la configuration opérationnelle doivent tous être conformes aux normes validées. La conformité FIPS (en anglais) concerne particulièrement les responsables IT du secteur public qui achètent du stockage pour des charges de travail d’agences fédérales. NIS2 et DORA exigent tous deux que les organisations mettent en œuvre des mesures techniques appropriées pour protéger les données et maintenir leur résilience opérationnelle. Le chiffrement y est une attente de base, NIS2 insistant particulièrement sur le chiffrement des données en transit à travers les frontières réseau, ce qui concerne les environnements de cloud hybride où les données circulent entre l’infrastructure on-premise et le cloud. À quoi ressemble la conformité du chiffrement dans la pratique Pour un responsable de la conformité qui examine la posture de chiffrement d’une organisation en vue d’un audit du stockage, la preuve qui compte n’est pas que le chiffrement soit théoriquement activé. C’est qu’il soit imposé par défaut, appliqué de façon cohérente, auditable de façon indépendante et intégré, avec l’immuabilité et les contrôles d’accès, dans une architecture de sécurité cohérente. Cela signifie un chiffrement AES-256 appliqué à tous les objets dès l’ingestion, et non de façon sélective. Des clés de chiffrement gérées en externe, indépendamment de la plateforme de stockage. TLS imposé pour toutes les données en transit. Des journaux d’accès aux clés pouvant être fournis aux auditeurs. Des contrôles IAM zero trust (en anglais) qui appliquent le principe du moindre privilège à l’accès à la configuration du chiffrement. Et une immuabilité imposée au niveau de l’objet, pour que les données chiffrées ne puissent pas être détruites, même en cas de compromission d’identifiants administrateur. Les plateformes de stockage qui imposent tout cela par défaut, au lieu d’en faire une option de configuration, réduisent considérablement le risque de non-conformité, car elles éliminent l’erreur humaine de configuration. La conformité ne devrait pas dépendre du fait que quelqu’un pense à activer le chiffrement sur un nouveau bucket. Pour aller plus loin Le chiffrement AES pour la sécurité des données d’entreprise Un stockage S3 conforme pour les données réglementées (en anglais) Guide de conformité FIPS pour un stockage sécurisé (en anglais) Exigences du RGPD en matière de stockage des données pour les équipes IT et stockage (en anglais) S3 Object Lock : immuabilité et WORM (en anglais) Qu’est-ce que le stockage immuable ? Définition, avantages et fonctionnement (en anglais) Bonnes pratiques de sécurité zero trust : ne jamais faire confiance, toujours vérifier (en anglais) Qu’est-ce que NIS2 ? La directive européenne sur la cybersécurité expliquée (en anglais) Le règlement sur la résilience opérationnelle numérique (DORA) expliqué (en anglais) Qu’est-ce que le NIST Cybersecurity Framework ? (en anglais) Découvrez comment Scality impose par défaut le chiffrement AES-256 sur le stockage cloud on-premise et hybride, avec une gestion externe des clés, l’immuabilité S3 Object Lock et des contrôles de conformité prêts pour l’audit. Demander une démo personnalisée →
