Chiffrement au repos et en cours d’utilisation

Lors de l’évaluation de la sécurité d’un fournisseur, une équipe TPRM a posé des questions sur le chiffrement. Le fournisseur a confirmé le chiffrement AES-256 au repos de toutes les données clients : chiffrement au niveau de la base de données, chiffrement des volumes de stockage, chiffrement des sauvegardes, le tout confirmé dans son rapport SOC 2 Type II. L’équipe en a pris note et est passée à la suite. Ce que l’évaluation n’a pas examiné, c’est que le chiffrement au niveau de la base de données était un chiffrement transparent : le moteur de base de données déchiffrait automatiquement les données à la lecture, et la couche applicative, tous les microservices, le pipeline d’analyse et tout utilisateur disposant d’identifiants de base de données recevaient des données en clair. Le chiffrement protégeait le support de stockage contre une extraction physique. Il n’offrait aucune protection contre un accès non autorisé à la couche applicative, contre un identifiant de base de données compromis, contre une vulnérabilité applicative exposant les résultats des requêtes, ni contre la menace interne d’un utilisateur privilégié interrogeant directement la base de données. Le chiffrement était réel. C’était une protection réelle contre une menace qui n’était pas la plus probable.

Les lacunes de couverture du chiffrement se concentrent autour de cinq scénarios d’exposition précis :

• Chiffrement transparent de la base de données avec un large accès aux requêtes : chiffrement au niveau de la base de données qui déchiffre automatiquement pour tout utilisateur ou toute application authentifiés, sans aucune protection contre un accès autorisé mais excessif
• Données en clair dans la mémoire et les journaux applicatifs : données sensibles déchiffrées pour le traitement applicatif et présentes en mémoire, dans les journaux applicatifs, les messages d’erreur et les sorties de débogage
• Données non chiffrées en transit entre services : communications internes de service à service transmettant des données déchiffrées sans protection TLS, exposant les données à une interception au niveau du réseau
• Données en clair dans les caches et le stockage temporaire : données déchiffrées stockées dans Redis, Memcached ou d’autres couches de cache sans nouveau chiffrement, accessibles à tout processus ayant accès au cache
• Lacunes dans la gestion des clés de chiffrement : clés gérées dans le même environnement que les données qu’elles protègent, ce qui supprime la séparation entre clé et texte chiffré qui donne son sens au chiffrement

Pourquoi c’est important

La confirmation du chiffrement au repos est l’un des contrôles de sécurité les plus souvent cités dans les réponses des fournisseurs aux questionnaires : il est visible, auditable et documenté dans les rapports SOC 2. Pour les praticiens TPRM, le risque est que cette confirmation crée, quant à la protection des données, une assurance qui surestime nettement ce qui est réellement protégé. Les menaces que traite le chiffrement au repos (vol de supports de stockage, intrusion physique) ne sont pas celles qui provoquent la plupart des violations de données chez les fournisseurs. Les menaces qui provoquent les violations (identifiants compromis, vulnérabilités applicatives, accès internes) agissent toutes sur des données déchiffrées que le chiffrement au repos ne protège pas.

La dépendance au contrôle d’accès est la dimension essentielle. Le chiffrement au repos ne protège qu’à la mesure des contrôles d’accès aux clés et aux systèmes qui effectuent le déchiffrement. Si tout utilisateur ayant accès à la base de données reçoit des données déchiffrées, le chiffrement n’offre aucune protection contre un accès excessif à la base de données. Si l’application déchiffre les données pour les traiter et qu’une vulnérabilité applicative expose les résultats de la base de données, le chiffrement n’a offert aucune protection contre cette vulnérabilité. Le chiffrement protège la couche de stockage. Les contrôles d’accès, la sécurité applicative et la gestion des clés protègent les couches où les violations se produisent réellement.

Pour les praticiens TPRM, cela crée une obligation d’évaluation précise : demander non seulement si les données sont chiffrées, mais aussi contre quelle menace le chiffrement protège, ce que la couche de chiffrement au repos ne protège pas et quels contrôles compensatoires traitent l’exposition pendant l’utilisation. Un fournisseur capable d’exposer le modèle de menace de sa mise en œuvre du chiffrement, ce que le chiffrement protège et ce qui exige d’autres contrôles, a abordé le chiffrement comme une décision d’architecture de sécurité plutôt que comme une case de conformité à cocher.

Là où la plupart des équipes se trompent

L’échec le plus répandu consiste à traiter la confirmation du chiffrement comme une confirmation de la protection des données. AES-256 au repos est une norme de chiffrement robuste. Elle protège les données au repos contre des menaces précises. Elle n’offre aucune protection contre une menace qui passe par un déchiffrement autorisé, ce qui est la manière dont se produisent pratiquement toutes les violations de données en production. Confirmer que les données sont chiffrées au repos et en conclure que la protection des données est assurée revient à confondre le mécanisme et la couverture.

Le deuxième échec consiste à ne pas poser de questions précises sur la gestion des clés. Le chiffrement ne vaut que par la protection des clés de chiffrement. Un chiffrement de base de données utilisant des clés stockées sur le même serveur de base de données, un chiffrement du stockage cloud utilisant des clés gérées par le même compte cloud et un chiffrement des sauvegardes utilisant des clés stockées avec les sauvegardes offrent tous une protection nettement plus faible qu’un chiffrement doté d’une gestion des clés correctement séparée. L’algorithme de chiffrement est AES-256. La gestion des clés détermine si cet algorithme a un sens en pratique.

• Traiter la confirmation du chiffrement au repos comme une confirmation de la protection des données : le chiffrement au repos protège la couche de stockage, et non la couche applicative et d’accès où se produisent les violations
• Aucune évaluation de la gestion des clés : la robustesse du chiffrement dépend de la protection des clés, et non du choix de l’algorithme
• Ne pas poser de questions sur le chiffrement en transit entre les services internes : communications internes de service à service qui contournent le TLS
• Ne pas poser de questions sur les données en clair dans les journaux et les caches : données sensibles dans les journaux applicatifs, les messages d’erreur et les couches de cache
• Aucune question sur le modèle de menace : le fournisseur comprend-il ce que couvre son chiffrement et ce qui exige d’autres contrôles

À quoi ressemblent les bonnes pratiques

Les programmes de chiffrement matures des fournisseurs mettent en œuvre le chiffrement comme une stratégie de protection en couches : chiffrement du stockage pour la couche physique, TLS pour toutes les communications en transit, chiffrement applicatif pour les champs sensibles qui doivent rester chiffrés même au sein de la couche applicative, et gestion des clés séparée des données qu’elle protège. La posture de chiffrement est comprise en fonction des menaces qu’elle traite, et des contrôles compensatoires couvrent explicitement la couche d’utilisation, où le chiffrement au repos n’offre aucune protection.

• Chiffrement au repos avec gestion des clés séparée : clés gérées par HSM ou KMS cloud avec séparation entre l’accès aux clés et l’accès aux données
• TLS 1.2 ou supérieur pour toutes les communications en transit, y compris les communications internes de service à service, et pas seulement les API exposées vers l’extérieur
• Chiffrement applicatif pour les champs les plus sensibles : chiffrement au niveau des champs qui maintient les champs sensibles chiffrés même lorsque la base de données déchiffre l’enregistrement qui les contient
• Données sensibles exclues des journaux : journalisation applicative configurée pour masquer ou omettre les valeurs des champs sensibles
• Chiffrement des caches pour les données sensibles : chiffrement de la couche de cache empêchant la persistance de données sensibles en clair dans les caches
• Modèle de menace du chiffrement formulé : le fournisseur peut décrire les menaces que traite son chiffrement et les contrôles compensatoires qui couvrent la couche d’utilisation

Outils

Couvrir le chiffrement à toutes les couches exige des outils qui étendent la protection au-delà de la couche de stockage, aux contextes applicatifs et de transit.

Gestion des clés : AWS KMS, Azure Key Vault, HashiCorp Vault, Thales

Les services de gestion des clés assurent la gestion du cycle de vie des clés cryptographiques, qui détermine si le chiffrement protège réellement. AWS KMS et Azure Key Vault offrent une gestion des clés cloud native qui sépare l’accès aux clés de l’accès aux données : une politique IAM distincte détermine qui peut utiliser la clé de chiffrement et qui peut lire les données chiffrées. HashiCorp Vault assure la gestion des secrets et des clés au niveau applicatif pour les environnements multicloud. Pour les praticiens TPRM, demander quel service de gestion des clés le fournisseur utilise et comment l’accès aux clés est séparé de l’accès aux données est la question de gouvernance du chiffrement la plus importante après la confirmation de l’algorithme.

Chiffrement au niveau des champs : Crypteron, AWS DynamoDB Encryption Client, MongoDB CSFLE

Le chiffrement au niveau des champs, ou au niveau des champs côté client, maintient certains champs sensibles chiffrés dans la couche applicative : la base de données stocke et renvoie un texte chiffré même pour un utilisateur applicatif authentifié, et l’application doit détenir séparément la clé de déchiffrement pour accéder à la valeur du champ. Cela étend la protection du chiffrement à la couche applicative pour les champs les plus sensibles. MongoDB Client-Side Field Level Encryption (CSFLE) offre cette capacité pour les déploiements MongoDB. Pour les praticiens TPRM, demander si le fournisseur utilise le chiffrement au niveau des champs pour les données sensibles des catégories les plus critiques permet de savoir si la couverture du chiffrement va au-delà de la couche de stockage.

Informatique confidentielle : Intel SGX, AMD SEV, AWS Nitro Enclaves

Les plateformes d’informatique confidentielle offrent des environnements d’exécution de confiance matériels qui protègent les données pendant leur utilisation : elles maintiennent les données chiffrées même en mémoire pendant le traitement, les protégeant d’un accès privilégié au OS et d’une compromission de l’hyperviseur. AWS Nitro Enclaves et Azure Confidential Computing offrent une informatique confidentielle cloud native. Ce sont des capacités émergentes encore peu répandues en entreprise, mais les fournisseurs qui traitent les données sensibles des catégories les plus critiques (génomique, trading financier, données gouvernementales classifiées) commencent à les déployer. Pour les praticiens TPRM, connaître l’informatique confidentielle comme orientation de la protection des données en cours d’utilisation permet des échanges éclairés sur l’état actuel et la feuille de route.

Enjeux de gouvernance

Le défi de gouvernance du chiffrement est la confusion entre algorithme et architecture qu’illustre l’évaluateur. AES-256 est un algorithme robuste. Qu’il soit appliqué de manière à offrir une protection réelle dépend entièrement de la gestion des clés, des contrôles d’accès au déchiffrement et de ce qu’il advient des données une fois déchiffrées. Un programme de chiffrement qui spécifie l’algorithme sans traiter la gestion des clés, les contrôles d’accès et l’exposition pendant l’utilisation a documenté un choix de chiffrement sans documenter une architecture de sécurité.

Pour les programmes TPRM, le changement de gouvernance concret consiste à passer de la confirmation de l’algorithme à la confirmation du modèle de menace : demander aux fournisseurs de décrire les menaces que traite leur chiffrement et les contrôles compensatoires qui traitent les menaces non couvertes par le chiffrement au repos. Un fournisseur capable de formuler cette réponse a pensé le chiffrement comme une architecture de sécurité. Un fournisseur qui ne peut que confirmer AES-256 a pensé le chiffrement comme une exigence de conformité.

• Poser des questions précises sur la gestion des clés : pas seulement l’algorithme, mais la façon dont les clés sont gérées, stockées et soumises au contrôle d’accès
• Poser des questions sur le chiffrement en transit entre les services internes : couverture TLS étendue au maillage de services et aux communications internes
• Poser des questions sur les données sensibles dans les journaux : la journalisation applicative masque-t-elle les valeurs des champs sensibles
• Demander aux fournisseurs de décrire ce que couvre leur chiffrement : quelle menace il traite et quels contrôles compensatoires couvrent la couche d’utilisation
• Inclure l’architecture de chiffrement dans les évaluations des fournisseurs : pas seulement la confirmation de l’algorithme, mais aussi la gestion des clés, la couverture en transit et le chiffrement au niveau des champs pour les données les plus sensibles

Si vous êtes une petite équipe

Ajoutez à votre évaluation du chiffrement deux questions qui vont au-delà de la confirmation de l’algorithme. Premièrement : comment vos clés de chiffrement sont-elles gérées, et qui a accès aux clés par rapport à qui a accès aux données chiffrées, ces accès sont-ils séparés ? Deuxièmement : qu’est-ce qui protège les données clients sensibles pendant le traitement applicatif, une fois que le chiffrement du stockage les a déchiffrées, et plus précisément, qu’est-ce qui empêche un administrateur de base de données disposant d’identifiants valides d’accéder à toutes les données clients en clair ? La première question révèle la maturité de la gestion des clés. La seconde impose une discussion sur le modèle de menace qui révèle si le fournisseur comprend ce que le chiffrement au repos protège et ne protège pas.

• Ajouter la séparation de la gestion des clés à votre évaluation du chiffrement : qui accède aux clés et qui accède aux données
• Demander ce qui protège les données pendant le traitement applicatif après le déchiffrement
• Poser des questions sur la couverture TLS des communications internes entre services, et pas seulement des API externes
• Demander si des données sensibles apparaissent dans les journaux applicatifs

Ce qu’il faut exiger

Demandez directement :

« Comment vos clés de chiffrement sont-elles gérées : plus précisément, sont-elles stockées dans un service de gestion des clés distinct, avec des contrôles d’accès séparés des données qu’elles chiffrent, ou sont-elles gérées dans le même environnement que les données ? »

« Qu’est-ce qui protège les données clients pendant le traitement applicatif, une fois qu’elles ont été déchiffrées par votre chiffrement du stockage ? Plus précisément, qu’est-ce qui empêche un utilisateur disposant d’identifiants valides pour la base de données d’interroger toutes les données clients en clair ? »

« Le TLS est-il appliqué à toutes les communications internes de service à service de votre architecture applicative, et des données clients sensibles apparaissent-elles en clair dans les journaux applicatifs ou les messages d’erreur ? »

Preuves attendues

• Description de l’architecture de gestion des clés : service KMS, séparation entre l’accès aux clés et l’accès aux données
• Description de la protection pendant l’utilisation : contrôles d’accès, chiffrement au niveau des champs ou informatique confidentielle pour les données les plus sensibles
• Confirmation de la couverture TLS des communications internes entre services
• Confirmation du masquage dans les journaux des champs de données sensibles

Un fournisseur qui répond à la question sur la gestion des clés par « nous utilisons AES-256 » a de nouveau décrit l’algorithme. Demandez précisément où les clés sont stockées et qui peut y accéder. Une clé de chiffrement stockée sur le même serveur que les données chiffrées offre la même protection que l’absence de chiffrement si ce serveur est compromis. L’algorithme est la serrure. La gestion des clés détermine si la clé est accrochée à côté de la porte.

Comment le prouver

Les exigences de chiffrement sont traitées dans PCI-DSS (cryptographie robuste pour les données des titulaires de carte), dans la spécification de chiffrement « addressable » de HIPAA, dans la pseudonymisation et le chiffrement en tant que mesures techniques appropriées du GDPR, et dans NIST SP 800-111. Démontrer la diligence requise exige des preuves que l’architecture de chiffrement a été évaluée, et pas seulement une confirmation de l’algorithme.

• Registres d’évaluation des fournisseurs documentant les questions sur la gestion des clés, la protection pendant l’utilisation et la couverture TLS
• Documentation de l’architecture de gestion des clés pour les relations fournisseurs les plus à risque
• Documentation du modèle de menace du chiffrement : ce que couvre le chiffrement et ce que traitent les contrôles compensatoires
• Confirmation de la couverture TLS des communications entre services

À retenir

AES-256 est un algorithme robuste. Il protège les données sur le support de stockage contre une extraction physique. Il déchiffre automatiquement lorsque la base de données traite une requête. Après le déchiffrement, les données circulent en clair dans l’application, en clair dans le maillage de services, en clair dans le cache et en clair sur l’écran de toute personne disposant d’identifiants valides. Le chiffrement au repos protège contre la menace que personne ne met à exécution : le vol de disque. Les contrôles d’accès, la sécurité applicative et la gestion des clés protègent contre les menaces qui provoquent les violations réelles. Confirmer l’algorithme revient à confirmer la serrure du coffre. Demander qui détient les clés, qui peut ouvrir le coffre et à quoi ressemblent les données une fois sorties du coffre, c’est poser des questions sur la sécurité. Posez les trois questions.