Clés de chiffrement détenues par le client ou gérées par le client : quelle différence et pourquoi est-ce important

Qui contrôle les clés qui déchiffrent vos données sensibles ? La réponse à cette question détermine si votre organisation garantit réellement la confidentialité de ses données ou si elle se contente d’une illusion de sécurité. Les fournisseurs cloud proposent un chiffrement par défaut, et beaucoup d’organisations pensent que leurs données restent protégées tant que les fichiers sont chiffrés. Pourtant, la robustesse du chiffrement importe bien moins que la maîtrise des clés, surtout lorsque les fournisseurs cloud conservent la capacité technique d’accéder à vos clés de chiffrement et de déchiffrer vos données à votre insu ou sans votre consentement.

Il existe trois modèles distincts de gestion des clés de chiffrement : les clés gérées par le fournisseur, les clés gérées par le client (BYOK) et les clés détenues par le client (HYOK). Chaque modèle offre un niveau de contrôle différent sur l’accès à vos données chiffrées. La différence entre la gestion et la détention des clés devient cruciale lorsque des agences gouvernementales émettent des assignations, que des cadres de conformité exigent une souveraineté des données démontrable ou que les organisations doivent prouver que même leur fournisseur cloud ne peut accéder à leurs informations sensibles.

Résumé Exécutif

À retenir : Les clés de chiffrement gérées par le client (BYOK) restent dans l’environnement du fournisseur cloud, qui peut donc y accéder en cas de demande légale, tandis que les clés détenues par le client (HYOK) restent sous contrôle exclusif du client et empêchent tout accès du fournisseur.

Pourquoi c’est important : Les organisations qui utilisent des clés de chiffrement gérées par le fournisseur ou BYOK s’exposent à des risques de confidentialité liés aux demandes d’accès gouvernementales dans le cadre du CLOUD Act, aux menaces internes du fournisseur et aux échecs de conformité dans les cadres exigeant une véritable souveraineté des données, comme le RGPD post-Schrems II et le CMMC Niveau 3.

5 Points Clés à Retenir

1. Les clés gérées par le client (BYOK) et les clés détenues par le client (HYOK) reposent sur des modèles de sécurité fondamentalement différents, malgré des noms similaires. BYOK stocke les clés générées par le client dans le service de gestion des clés du fournisseur, qui conserve un accès technique, tandis que HYOK garde les clés sous contrôle exclusif du client, dans des HSM sur site ou une infrastructure privée.

2. Le CLOUD Act permet aux autorités américaines d’exiger des fournisseurs cloud qu’ils déchiffrent les données clients, où qu’elles soient stockées dans le monde, souvent sans en informer le client. Ce cadre légal signifie que le chiffrement BYOK ne protège pas contre l’accès légal des gouvernements via votre fournisseur cloud, quel que soit l’emplacement physique des données.

3. Souveraineté et confidentialité des données sont deux notions distinctes qui nécessitent des contrôles techniques différents. Stocker les données dans une région géographique spécifique (souveraineté) n’empêche pas le fournisseur cloud d’y accéder s’il détient les clés de chiffrement, ce qui rend la détention des clés essentielle pour garantir la confidentialité.

4. Les cadres de conformité exigent de plus en plus des clés de chiffrement détenues par le client depuis l’invalidation des transferts de données US-UE par l’arrêt Schrems II. Le RGPD, NIS2, CMMC Niveau 3 et FedRAMP High imposent désormais des modèles de chiffrement où le fournisseur ne peut pas accéder aux données du client.

5. Les compromis opérationnels liés aux clés détenues par le client concernent la complexité et le coût, pas la sécurité ou les fonctionnalités. Les organisations peuvent conserver la même robustesse de chiffrement et les mêmes performances applicatives avec HYOK tout en gagnant en confidentialité, même si la gestion des clés nécessite une infrastructure et une expertise supplémentaires.

Les Trois Modèles de Gestion des Clés de Chiffrement

En quoi consistent les clés de chiffrement gérées par le fournisseur ?

Le chiffrement géré par le fournisseur est le modèle par défaut où les fournisseurs cloud génèrent, stockent et gèrent toutes les clés de chiffrement dans leur propre infrastructure.

Lorsque les organisations déposent des données sur un stockage cloud, le fournisseur les chiffre automatiquement à l’aide de clés qu’il contrôle. Cette approche ne nécessite aucune configuration côté client et fonctionne de façon transparente. Le fournisseur gère la rotation, la sauvegarde et tout le cycle de vie des clés. Les clients bénéficient d’un stockage chiffré sans avoir besoin d’expertise en chiffrement ni d’infrastructure dédiée à la gestion des clés.

Cependant, ce modèle crée des vulnérabilités majeures en matière de confidentialité. Le fournisseur détient à la fois les données chiffrées et les clés permettant de les déchiffrer, ce qui signifie qu’il peut accéder aux données clients à tout moment, de son propre chef ou sous contrainte légale. Les agences de sécurité peuvent assigner le fournisseur pour qu’il déchiffre et transmette les données clients. Les employés du fournisseur disposant des droits nécessaires peuvent consulter les informations chiffrées. En cas de faille de sécurité affectant les systèmes du fournisseur, données et clés sont exposées simultanément.

Quand les clés gérées par le fournisseur sont-elles acceptables ?

• Données non sensibles sans exigences réglementaires
• Environnements de développement et de test internes
• Informations publiques nécessitant uniquement une protection d’intégrité
• Organisations ayant une totale confiance dans la sécurité et la conformité légale de leur fournisseur cloud

Qu’est-ce que le Bring Your Own Key (BYOK) ?

Le chiffrement BYOK permet aux clients de générer des clés de chiffrement dans leur propre environnement et de les transférer vers le service de gestion des clés du fournisseur cloud.

Les clients créent les clés à l’aide de leurs propres outils cryptographiques, puis les transfèrent vers l’infrastructure KMS du fournisseur, comme AWS KMS, Azure Key Vault ou Google Cloud KMS. Le fournisseur stocke les clés du client séparément de celles qu’il génère lui-même et applique des contrôles d’accès supplémentaires. Les clients peuvent révoquer ou supprimer les clés de l’infrastructure KMS du fournisseur, rendant leurs données illisibles. Ce modèle offre un meilleur contrôle du cycle de vie des clés tout en déléguant au fournisseur la complexité opérationnelle du stockage et des opérations cryptographiques.

La limite majeure de ce modèle est que les clés BYOK résident dans l’environnement du fournisseur. Les systèmes du fournisseur réalisent toutes les opérations de chiffrement et de déchiffrement, ce qui implique que l’infrastructure du fournisseur doit avoir accès au matériel de clé. Même si les fournisseurs mettent en place des contrôles d’accès stricts et une journalisation des accès, ils conservent la capacité technique d’utiliser les clés du client. Les autorités peuvent contraindre le fournisseur à utiliser les clés BYOK pour déchiffrer les données clients. Les administrateurs du fournisseur disposant des droits nécessaires peuvent accéder au matériel de clé. Une faille de sécurité affectant l’infrastructure KMS du fournisseur pourrait exposer les clés du client.

Processus d’implémentation BYOK :

1. Le client génère les clés de chiffrement à l’aide d’outils cryptographiques locaux ou de HSM
2. Le client transfère les clés de façon sécurisée vers le KMS du fournisseur via des canaux chiffrés
3. Le fournisseur stocke les clés dans son infrastructure KMS avec des politiques d’accès spécifiques au client
4. Toutes les opérations de chiffrement/déchiffrement s’effectuent dans l’environnement du fournisseur à l’aide des clés du client
5. Le client peut faire tourner, révoquer ou supprimer les clés via l’interface de gestion du fournisseur

Limites du BYOK pour la protection de la confidentialité :

• Clés stockées dans l’infrastructure KMS du fournisseur
• Le fournisseur peut accéder aux clés pour la conformité légale, l’administration ou en cas de compromission
• Le CLOUD Act permet l’accès gouvernemental via le fournisseur sans notification au client
• Les employés du fournisseur ayant les droits nécessaires peuvent utiliser les clés pour déchiffrer les données

Qu’est-ce que le Hold Your Own Key (HYOK) ?

HYOK garde les clés de chiffrement sous contrôle exclusif du client, dans des modules matériels de sécurité (HSM) sur site ou une infrastructure cloud privée inaccessible au fournisseur.

Les clients génèrent et stockent les clés dans leurs propres HSM ou systèmes de gestion de clés. Lorsque des applications cloud doivent chiffrer ou déchiffrer des données, elles envoient des requêtes à l’infrastructure de gestion de clés du client, et non à celle du fournisseur. Les clés de chiffrement ne quittent jamais l’environnement du client, et le fournisseur n’a aucune capacité technique d’y accéder. Cette architecture permet de mettre en place des systèmes à connaissance nulle, où le fournisseur ne peut pas déchiffrer les données du client, même sous contrainte légale.

HYOK garantit une véritable protection de la confidentialité, car le fournisseur ne peut pas accéder aux informations du client. Les assignations judiciaires adressées au fournisseur ne permettent pas d’obtenir de données déchiffrées, car le fournisseur ne détient pas les clés. Les failles de sécurité du fournisseur n’exposent pas le matériel de clé. Les administrateurs du fournisseur ne peuvent pas accéder au contenu chiffré, quel que soit leur niveau de privilège. Seule l’organisation cliente contrôle l’utilisation des clés de chiffrement.

Méthodes d’implémentation HYOK :

• HSM sur site intégrés aux charges cloud
• Déploiement cloud privé où le client contrôle toute l’infrastructure
• Architectures hybrides avec serveurs de clés côté client et ressources de calcul côté fournisseur
• Systèmes isolés (air gap) pour des exigences de sécurité maximales

Bénéfices HYOK pour la confidentialité :

• Les clés ne quittent jamais le contrôle du client
• Le fournisseur n’a aucune capacité technique de déchiffrer les données
• Protection contre l’accès légal via le fournisseur
• Le client gère tout le cycle de vie des clés sans intervention du fournisseur

Pourquoi l’accès du fournisseur aux clés détruit la confidentialité des données

Comment le CLOUD Act permet-il l’accès gouvernemental sans que le client en soit informé ?

Le Clarifying Lawful Overseas Use of Data (CLOUD) Act autorise les autorités américaines à exiger des entreprises technologiques américaines qu’elles fournissent des données stockées partout dans le monde, quel que soit l’emplacement physique de ces données.

Adopté en 2018, le CLOUD Act a tranché un litige sur la capacité des mandats américains à contraindre des entreprises à produire des données stockées sur des serveurs étrangers. La loi impose aux fournisseurs cloud basés aux États-Unis de se conformer à toute procédure légale américaine valable pour les données qu’ils contrôlent, rendant l’emplacement géographique des données sans importance dès lors que le fournisseur détient les clés de chiffrement. Les autorités peuvent obtenir un mandat ou une assignation obligeant le fournisseur à déchiffrer et à transmettre les données du client, que celles-ci soient hébergées en Europe, en Asie ou ailleurs.

Les lettres de sécurité nationale incluent souvent des ordonnances de confidentialité interdisant au fournisseur d’informer le client de l’accès à ses données. Les clients utilisant le chiffrement géré par le fournisseur ou BYOK peuvent donc ignorer que les autorités ont déchiffré et consulté leurs informations sensibles. Le fournisseur détient la capacité technique d’utiliser les clés de chiffrement, les autorités la capacité légale de l’y contraindre, et les clients n’ont aucun moyen technique de s’y opposer.

Ce cadre implique que les mesures de souveraineté des données, comme le stockage dans une région géographique spécifique, n’offrent aucune protection de la confidentialité si le fournisseur contrôle les clés de chiffrement. Les données européennes stockées sur des serveurs européens restent accessibles aux autorités américaines si un fournisseur cloud américain détient les clés de chiffrement.

Conséquences du CLOUD Act selon les modèles de chiffrement :

• Clés gérées par le fournisseur : le fournisseur peut déchiffrer les données sur demande légale
• Clés BYOK dans le KMS du fournisseur : le fournisseur peut utiliser les clés du client pour déchiffrer les données sous contrainte légale
• Clés HYOK sous contrôle du client : le fournisseur ne peut pas déchiffrer les données, car il n’a pas accès aux clés

Qu’est-ce que le SHIELD Act et pourquoi n’est-il pas suffisant ?

Le Securing and Handling of Internet and Electronic Data (SHIELD) Act, proposé mais non adopté à ce jour, vise à empêcher les gouvernements étrangers d’accéder aux données américaines via les fournisseurs cloud.

Ce texte interdirait aux fournisseurs cloud de répondre à des demandes étrangères concernant les données de citoyens américains sans approbation d’un tribunal américain. Il cherche à instaurer des protections réciproques, similaires à celles que le CLOUD Act offre aux autorités américaines pour l’accès aux données stockées à l’étranger. Toutefois, même adopté, le SHIELD Act ne traiterait pas l’accès du gouvernement américain aux données clients, n’éliminerait pas la capacité technique du fournisseur à déchiffrer les informations et ne résoudrait pas la vulnérabilité fondamentale liée à la gestion des clés par le fournisseur.

Les organisations soucieuses de la confidentialité des données ne peuvent pas compter sur une législation qui pourrait ne jamais voir le jour et qui ne réglerait pas le problème central de l’accès aux clés par le fournisseur. Seuls des contrôles techniques via des clés détenues par le client assurent une protection fiable de la confidentialité, indépendamment de l’évolution des lois.

Pourquoi une législation proposée ne remplace pas les contrôles techniques :

• Les lois peuvent évoluer ou être abrogées
• L’application varie selon la juridiction et le contexte politique
• Les ordonnances de confidentialité empêchent les clients d’être informés des accès
• Des contrôles techniques comme HYOK suppriment la capacité du fournisseur à accéder aux données, quel que soit le cadre légal

Comment l’arrêt Schrems II a-t-il modifié les exigences de souveraineté des données ?

L’arrêt Schrems II de 2020 de la Cour de justice européenne a invalidé le Privacy Shield, qui autorisait les entreprises américaines à transférer des données personnelles européennes vers les États-Unis.

La Cour a estimé que les lois américaines de surveillance, notamment la section 702 du FISA et l’Executive Order 12333, n’offraient pas de garanties suffisantes pour les données des citoyens européens. Les fournisseurs cloud américains soumis au droit US ne peuvent garantir que les données européennes restent à l’abri des autorités américaines. La décision souligne que le droit américain permet aux agences de renseignement d’accéder aux données détenues par des sociétés américaines sans contrôle judiciaire adéquat ni recours pour les citoyens européens.

Cette décision a radicalement changé l’approche des organisations européennes vis-à-vis du chiffrement cloud. Stocker les données dans l’UE ne suffit plus à satisfaire le RGPD si un fournisseur américain contrôle les clés de chiffrement et peut être contraint de déchiffrer ces données en vertu du droit US. La décision impose des mesures techniques empêchant l’accès du fournisseur, poussant vers des clés détenues par le client ou des modèles de déploiement privés.

Conséquences de Schrems II sur la gestion des clés :

• Les organisations européennes ne peuvent plus se contenter d’accords contractuels de protection des données
• Des contrôles techniques empêchant l’accès du fournisseur sont désormais requis pour les transferts de données US-UE
• Les clés détenues par le client permettent d’être conforme au RGPD en supprimant la capacité du fournisseur à accéder aux données
• La directive NIS2 renforce les exigences pour les secteurs critiques

Quels cadres de conformité exigent la détention des clés par le client ?

Les exigences réglementaires imposent de plus en plus des modèles de chiffrement où le fournisseur ne peut pas accéder aux données du client, notamment pour les sous-traitants gouvernementaux, les infrastructures critiques et les entités traitant des données personnelles européennes.

Le CMMC Niveau 3, pour les sous-traitants de la défense manipulant des informations couvertes, exige des mécanismes cryptographiques empêchant toute divulgation non autorisée lors de la transmission et du stockage. L’accent mis sur la protection des CUI et l’alignement avec les exigences renforcées du NIST 800-172 imposent de fait des clés contrôlées par le client, excluant tout accès du fournisseur aux informations sensibles ou classifiées.

L’autorisation FedRAMP High et les charges DoD Impact Level 5 exigent des protections cryptographiques empêchant les fournisseurs cloud d’accéder aux données clients. Ces cadres partent du principe que les données traitées par les agences fédérales ou les systèmes de défense doivent être protégées contre toute partie extérieure à l’organisation cliente, y compris le fournisseur d’hébergement.

L’article 32 du RGPD impose des mesures techniques appropriées pour garantir la sécurité des données, et les recommandations post-Schrems II précisent que le chiffrement seul ne suffit pas si le fournisseur contrôle les clés et peut être contraint de déchiffrer les données en vertu d’une loi étrangère. Les organisations transférant des données personnelles européennes vers des pays sans lois adéquates doivent mettre en place des mesures complémentaires, les clés détenues par le client étant l’un des rares contrôles techniques satisfaisant à cette exigence.

Cadres de conformité privilégiant la détention des clés par le client :

• CMMC Niveau 3 pour la protection des CUI dans la supply chain défense
• FedRAMP High et DoD IL5 pour les données d’agences fédérales
• RGPD pour les transferts de données personnelles européennes vers des pays tiers post-Schrems II
• NIS2 pour les entités essentielles et importantes dans les secteurs critiques
• BDSG allemand et exigences françaises de souveraineté des données

Mise en œuvre technique : fonctionnement de chaque modèle

Comment les fournisseurs cloud mettent-ils en œuvre BYOK ?

Les fournisseurs cloud proposent BYOK via des services de gestion des clés acceptant les clés générées par le client tout en conservant la maîtrise opérationnelle de l’infrastructure de chiffrement.

Les clients génèrent les clés de chiffrement à l’aide d’outils locaux comme OpenSSL, les interfaces CLI du fournisseur cloud ou des HSM. Le client télécharge ensuite le matériel de clé vers le KMS du fournisseur via des appels API sécurisés utilisant TLS pour protéger les clés en transit. Le fournisseur stocke les clés du client dans son infrastructure KMS, souvent dans des HSM certifiés FIPS 140-2, avec des contrôles d’accès limitant les comptes et services pouvant utiliser chaque clé.

Lorsque les applications doivent chiffrer des données, elles appellent l’API KMS du fournisseur pour effectuer l’opération. Le KMS utilise la clé du client pour chiffrer les données et renvoie le texte chiffré. Le déchiffrement fonctionne de la même manière : l’application envoie le texte chiffré au KMS, qui utilise la clé du client pour le déchiffrer et renvoie le texte en clair. Toutes les opérations cryptographiques s’effectuent dans l’infrastructure du fournisseur à l’aide des clés du client, qui résident dans les systèmes du fournisseur.

Workflow BYOK :

1. Le client génère la clé à l’aide d’outils cryptographiques locaux
2. Le client télécharge la clé vers le KMS du fournisseur via un appel API chiffré
3. Le fournisseur stocke la clé dans son KMS avec des politiques d’accès spécifiques au client
4. Les applications demandent des opérations de chiffrement/déchiffrement au KMS du fournisseur
5. Le KMS du fournisseur effectue les opérations cryptographiques à l’aide de la clé du client
6. Le fournisseur retourne les résultats à l’application

Comment HYOK garantit-il le contrôle du client ?

Les implémentations HYOK conservent les clés de chiffrement dans l’infrastructure contrôlée par le client et réalisent les opérations cryptographiques hors de l’environnement du fournisseur.

Les clients déploient des HSM ou des systèmes de gestion de clés sur site qui ne synchronisent jamais les clés avec l’infrastructure du fournisseur. Lorsque des applications cloud doivent chiffrer ou déchiffrer des données, elles se connectent au système de gestion de clés du client via des connexions réseau sécurisées. L’infrastructure du client effectue l’opération cryptographique et renvoie le résultat, garantissant que les clés ne quittent jamais le contrôle du client. Certaines implémentations utilisent un déploiement cloud privé où le client contrôle l’ensemble de la pile d’infrastructure, rendant l’accès du fournisseur techniquement impossible.

Les architectures HYOK avancées mettent en œuvre un chiffrement au niveau applicatif, où les données sont chiffrées sur les terminaux avant d’être transmises au stockage cloud. Le fournisseur cloud ne reçoit que des données chiffrées et ne dispose d’aucun moyen de les déchiffrer. Cette approche permet de mettre en place des systèmes à connaissance nulle, où le fournisseur ne peut littéralement pas accéder aux données du client, quelle que soit la contrainte légale.

Workflow HYOK :

1. Le client déploie un HSM ou un système de gestion de clés dans son infrastructure
2. Le client génère et stocke toutes les clés de chiffrement localement
3. Les applications cloud se connectent au système de gestion de clés du client
4. Le système du client effectue les opérations de chiffrement/déchiffrement
5. Les clés ne quittent jamais le contrôle du client ni n’entrent dans l’environnement du fournisseur
6. Le fournisseur ne reçoit que des données chiffrées et ne peut pas les déchiffrer

Conséquences en matière de sécurité et de conformité

Quelles menaces la détention des clés par le client permet-elle d’écarter ?

Les clés de chiffrement détenues par le client éliminent des catégories entières de menaces qui persistent avec les modèles gérés par le fournisseur ou BYOK.

L’accès des autorités via la conformité du fournisseur disparaît dès lors que le fournisseur ne peut pas déchiffrer les données. Les assignations et mandats adressés au fournisseur ne permettent pas d’obtenir de données déchiffrées, car il ne détient pas les clés. Les agences de renseignement ne peuvent pas contraindre le fournisseur à activer une surveillance s’il n’a aucun accès technique aux informations du client. Cette protection s’applique quel que soit le gouvernement demandeur et le cadre légal invoqué.

Les menaces internes chez le fournisseur cloud ne peuvent pas accéder aux données du client si les clés restent hors de l’infrastructure du fournisseur. Les failles de sécurité affectant les systèmes administratifs, l’infrastructure KMS ou les sauvegardes du fournisseur n’exposent ni les clés ni les données. Les auditeurs tiers, prestataires de services managés et autres intervenants ayant accès aux systèmes du fournisseur ne peuvent pas déchiffrer les données du client.

Menaces écartées grâce à la détention des clés par le client :

• Accès gouvernemental via la conformité légale du fournisseur (scénarios CLOUD Act)
• Accès interne au fournisseur aux données chiffrées
• Failles de sécurité du fournisseur exposant à la fois données et clés
• Accès transfrontalier aux données contournant la souveraineté
• Accès tiers via les systèmes ou partenaires du fournisseur

Quels sont les compromis opérationnels ?

La détention des clés de chiffrement par le client introduit une complexité opérationnelle et un coût que les organisations doivent mettre en balance avec les bénéfices en matière de confidentialité et de conformité.

L’impact sur les performances varie selon l’approche retenue. Les solutions HYOK qui nécessitent des appels réseau vers les systèmes de gestion de clés du client ajoutent de la latence par rapport à un KMS natif du fournisseur. Les organisations doivent garantir une connectivité réseau fiable entre les charges cloud et l’infrastructure de gestion de clés sur site. Cependant, les modèles de déploiement privé où le client contrôle toute l’infrastructure éliminent la latence réseau tout en conservant la maîtrise des clés.

La disponibilité et la reprise après sinistre deviennent plus complexes lorsque le client gère les clés. Les organisations doivent mettre en place la redondance des HSM, des procédures de sauvegarde et des mécanismes de récupération sans s’appuyer sur les solutions du fournisseur. La gestion des clés requiert une expertise spécialisée, souvent absente en interne. Le coût du matériel HSM, des locaux sécurisés et du personnel qualifié dépasse le coût nul du chiffrement géré par le fournisseur.

Points d’attention opérationnels :

• Performance : latence potentielle pour les opérations de clés via le réseau vs. KMS natif du fournisseur
• Disponibilité : responsabilité du client pour la redondance et la reprise après sinistre de l’infrastructure de clés
• Complexité : nécessite une expertise en chiffrement et des procédures de gestion du cycle de vie des clés
• Coût : matériel HSM, locaux, personnel vs. chiffrement géré gratuitement par le fournisseur

Dans quels cas HYOK ou un déploiement privé est-il obligatoire ?

Certaines exigences de conformité, modèles de menace et niveaux de sensibilité des données rendent la détention des clés par le client indispensable.

Les organisations traitant des CUI pour des contrats de défense au CMMC Niveau 3 doivent empêcher l’accès du fournisseur pour satisfaire aux exigences de sécurité renforcées. Les agences fédérales traitant des données Impact Level 5 ou recherchant l’autorisation FedRAMP High ont besoin de protections cryptographiques empêchant le fournisseur de déchiffrer les informations. Les organisations européennes transférant des données personnelles à des fournisseurs américains après Schrems II doivent mettre en place des mesures techniques empêchant l’accès du gouvernement US via la conformité du fournisseur.

Les architectures Zero Trust, qui considèrent que tous les segments réseau et prestataires peuvent être compromis, imposent la détention des clés par le client. Les organisations confrontées à des menaces étatiques susceptibles de contraindre le fournisseur à collaborer ont besoin de modèles de chiffrement où le fournisseur ne peut techniquement pas aider. Les entités d’infrastructures critiques soumises à NIS2 doivent démontrer que les services essentiels restent protégés même en cas d’incident de sécurité ou de contrainte légale sur le fournisseur cloud.

Scénarios nécessitant la détention des clés par le client :

• Protection des CUI au CMMC Niveau 3 pour les sous-traitants défense
• Charges d’agences fédérales FedRAMP High et DoD IL5
• Transferts de données UE-US conformes au RGPD post-Schrems II
• Systèmes d’information gouvernementaux et défense classifiés
• Propriété intellectuelle et algorithmes de trading dans les services financiers
• Systèmes de santé protégeant la vie privée des patients contre tout acteur externe

Vos besoins en confidentialité priment sur toutes les autres variables et décisions liées aux clés de chiffrement

La distinction entre clés gérées par le client et clés détenues par le client détermine si les organisations garantissent réellement la confidentialité de leurs données ou se contentent d’une illusion de sécurité. Les modèles BYOK, qui stockent les clés générées par le client dans l’infrastructure du fournisseur, laissent toujours la possibilité au fournisseur d’accéder aux données en cas de contrainte légale ou de faille de sécurité. Le CLOUD Act et des cadres similaires rendent l’emplacement géographique des données sans importance dès lors que le fournisseur détient les clés de chiffrement et peut être contraint de déchiffrer les informations du client sans notification.

Les clés détenues par le client, via HYOK ou un déploiement privé, constituent le seul modèle protégeant contre l’accès légal via le fournisseur, les menaces internes et les échecs de conformité qui surviennent lorsque le fournisseur peut accéder aux données chiffrées. Les organisations soumises au CMMC Niveau 3, à FedRAMP High ou au RGPD post-Schrems II constatent que la détention des clés par le client est désormais une exigence de conformité obligatoire, et non plus un simple renforcement de la sécurité.

Les compromis opérationnels concernent la complexité et le coût, pas la sécurité ou les fonctionnalités. Les organisations peuvent conserver la même robustesse de chiffrement et les mêmes possibilités applicatives avec des clés détenues par le client, tout en bénéficiant de la protection de la confidentialité exigée par les cadres de conformité. Kiteworks propose cette capacité via des options de déploiement privé qui offrent aux clients un contrôle total sur les clés de chiffrement, éliminent l’accès du fournisseur aux données sensibles et permettent une véritable souveraineté des données conforme aux exigences réglementaires les plus strictes.

Comment Kiteworks garantit un chiffrement contrôlé par le client

Kiteworks met en œuvre la détention des clés de chiffrement par le client via des options de déploiement privé qui offrent aux organisations un contrôle total sur les clés et l’accès aux données.

L’architecture Réseau de données privé se déploie sur site, dans des environnements cloud privés ou sur des réseaux isolés, où le client contrôle toute la pile d’infrastructure. Le chiffrement AES-256 protège toutes les données au repos à l’aide de clés qui ne quittent jamais l’infrastructure du client. Les collaborateurs et le support Kiteworks n’ont aucun accès aux clés de chiffrement ni aux données du client, permettant une architecture à connaissance nulle réelle.

L’intégration de modules matériels de sécurité (HSM) assure une protection FIPS 140-2 Niveau 3 pour les clés de chiffrement, grâce à du matériel inviolable sous contrôle exclusif du client. Les organisations peuvent définir leurs propres procédures de gestion des clés, calendriers de rotation et contrôles d’accès, sans intervention de Kiteworks. La plateforme prend en charge à la fois les appliances HSM sur site et les services cloud HSM gérés par le client.

Le déploiement privé élimine les vulnérabilités de confidentialité inhérentes aux architectures cloud multi-locataires. Les assignations judiciaires ne peuvent pas contraindre Kiteworks à déchiffrer les données du client, car Kiteworks n’a pas la capacité technique de le faire. Le CLOUD Act devient sans objet dès lors que le prestataire ne détient jamais les clés de chiffrement du client. Les organisations bénéficient d’une véritable souveraineté des données conforme aux exigences post-Schrems II du RGPD.

La plateforme regroupe la messagerie électronique, le partage et le transfert de fichiers, ainsi que les formulaires web dans un environnement unifié avec des politiques de chiffrement et d’accès cohérentes. Cette approche élimine les failles de sécurité créées par l’utilisation de solutions ponctuelles distinctes et de modèles de gestion des clés différents selon les canaux de communication.

Pour en savoir plus sur la maximisation de la confidentialité des données grâce à la détention des clés de chiffrement par le client, réservez votre démo sans attendre !

Ressources complémentaires

• Article de blog
  Chiffrement à clé publique vs clé privée : explications détaillées
• Article de blog
  Bonnes pratiques essentielles pour le chiffrement des données
• eBook Top 10 des tendances du chiffrement des données : analyse approfondie de l’AES-256
• Article de blog
  Exploration de l’E2EE : exemples concrets de chiffrement de bout en bout
• Article de blog
  Guide ultime de l’AES 256 : renforcer la protection des données pour une sécurité infaillible