Souveraineté des données pour le SaaS d'entreprise : Microsoft 365, AWS et clés gérées par le client
Si votre organisation utilise AWS, Microsoft 365 ou des outils IA d'entreprise et souhaite évaluer la souveraineté des données, la réponse directe est la suivante : la gestion des clés cloud native — AWS KMS avec des clés gérées par le fournisseur, ou le chiffrement géré par Microsoft dans Office 365 — ne constitue pas la souveraineté des données. Il s'agit d'une protection des données sous le contrôle d'un tiers. La souveraineté véritable exige que les clés cryptographiques soient générées, stockées et opérées exclusivement dans une infrastructure que votre organisation contrôle, sans qu'aucun accès unilatéral ne soit possible par un tiers, y compris votre fournisseur cloud. Ce guide aide les architectes sécurité à comprendre précisément où les contrôles doivent se situer — et revêt une importance particulière dans le contexte réglementaire suisse et européen post-Schrems II.
L'illusion de la souveraineté : pourquoi « chiffré dans le cloud » ne suffit pas
Chaque grande plateforme cloud chiffre vos données par défaut. AWS chiffre S3, RDS et EBS au repos. Microsoft 365 chiffre les boîtes mail, SharePoint et Teams. Ce n'est pas contestable — c'est le minimum attendu.
Le problème est la garde des clés. Lorsque votre fournisseur cloud chiffre vos données avec des clés qu'il gère également, il conserve la capacité technique de déchiffrer ces données. Trois scénarios précis rendent cela problématique — et que les cadres de conformité commencent à traiter explicitement :
- Contrainte légale : Le CLOUD Act américain permet aux tribunaux américains de contraindre les fournisseurs cloud — dont Microsoft et Amazon — à produire les données clients hébergées n'importe où dans le monde, sans en informer la personne concernée. Les organisations européennes gérant des données personnelles sous le RGPD font face à un conflit irréconciliable.
- Menaces internes : Les employés de fournisseurs cloud disposant de droits d'accès élevés peuvent, en principe, accéder au matériau de clé. Les grands fournisseurs implémentent des contrôles, mais la capacité existe.
- Scénarios de violation : Une compromission suffisamment sophistiquée de l'infrastructure d'un fournisseur cloud pourrait exposer à la fois les données chiffrées et les clés qui les protègent, si les deux résident dans la même frontière de confiance.
La souveraineté des données — telle que définie par l'article 32 du RGPD, l'article 21 de NIS2 et le règlement DORA — exige que votre organisation démontre un contrôle cryptographique exclusif. Les clés gérées par le cloud ne permettent pas cette démonstration.
Le contexte suisse et la juridiction des données
Pour les organisations domiciliées en Suisse ou opérant sous droit suisse, la Loi fédérale sur la protection des données (LPD révisée, en vigueur depuis septembre 2023) impose des exigences comparables au RGPD sur la démonstration de contrôle sur les données personnelles. La Suisse n'est pas membre de l'UE et ne tombe pas directement sous le CLOUD Act américain — ce qui fait de la juridiction suisse un avantage structurel pour le stockage de clés, notamment pour les organisations européennes cherchant à éviter l'exposition au CLOUD Act tout en maintenant un centre de données hors UE sous une législation équivalente.
DuoKey opère des nœuds MPC Vault dans des centres de données suisses. Les clés y résident sous droit suisse, hors de portée des ordonnances judiciaires américaines et dans une juridiction reconnue adéquate par la Commission européenne.
Le spectre de la souveraineté : cadre d'évaluation pour les architectes sécurité
| Modèle de contrôle | Localisation des clés | Accès fournisseur ? | Profondeur de souveraineté | Conformité |
|---|---|---|---|---|
| Clés gérées par le fournisseur (défaut) | HSM du fournisseur cloud | Oui — total | Nulle | Basique |
| Clés gérées client (CMK) dans KMS cloud | HSM du fournisseur cloud | Oui — opérationnel | Faible | Partielle |
| BYOK (import dans KMS cloud) | HSM du fournisseur cloud (après import) | Oui — opérationnel | Faible à moyenne | Partielle |
| Gestion externe des clés (XKS / DKE) | HSM externe / KMaaS | Non | Élevée | Solide |
| KM externe avec double contrôle HSM | HSM externe, double autorisation | Non — même pas le fournisseur | Maximale | Complète |
Point clé : Les trois premières lignes laissent toutes votre fournisseur cloud avec un accès technique au matériau de clé durant les opérations. Seule la gestion externe des clés — où les opérations cryptographiques ont lieu hors de la frontière de confiance du fournisseur cloud — atteint une souveraineté véritable.
Microsoft 365 : évaluation de vos options de gestion des clés
Option 1 — Clés gérées par Microsoft (défaut)
Par défaut, Microsoft gère les clés de chiffrement pour tous les services Microsoft 365 : Exchange Online, SharePoint, Teams, OneDrive. Vos données sont chiffrées, mais Microsoft détient les clés. Une ordonnance CLOUD Act signifiée à Microsoft peut contraindre au déchiffrement sans votre intervention.
Profondeur de souveraineté : 0/5
Option 2 — Customer Key (BYOK dans Azure Key Vault)
La fonctionnalité Customer Key de Microsoft permet aux organisations de fournir leurs propres clés de chiffrement racines, importées dans Azure Key Vault. Cela améliore votre posture de contrôle — vous pouvez révoquer l'accès en supprimant votre clé — mais l'infrastructure Azure gère toujours la clé non chiffrée durant les opérations cryptographiques.
La documentation de Microsoft elle-même précise : « Microsoft n'a pas accès aux clés racines que vous maintenez dans Azure Key Vault. Cependant, il peut accéder aux clés de chiffrement de données dérivées de vos clés. »
Profondeur de souveraineté : 2/5 — Meilleur que le défaut, mais pas une souveraineté véritable.
Option 3 — Double Key Encryption (DKE)
La fonctionnalité Double Key Encryption de Microsoft 365 est la seule option Microsoft qui atteigne une souveraineté véritable. DKE chiffre les documents sensibles avec deux clés : la clé Microsoft et votre clé externe. Les deux sont nécessaires pour déchiffrer. Microsoft ne détient jamais votre clé externe.
DuoKey fournit un service DKE certifié dans lequel votre clé externe est stockée dans l'infrastructure HSM-backed MPC de DuoKey, avec autorisation à double contrôle — ce qui signifie qu'aucune partie (y compris DuoKey) ne peut accéder à la clé ou l'utiliser unilatéralement.
Profondeur de souveraineté : 5/5 — Le seul modèle dans lequel Microsoft ne peut pas déchiffrer vos données.
Architecture DKE : deux clés indépendantes sont nécessaires. L'infrastructure Microsoft ne détient jamais la clé externe.
AWS : évaluation de vos options de gestion des clés
Option 1 — Clés gérées par AWS (défaut)
Les services AWS chiffrent les données avec des CMK gérées par AWS. Simple, sans charge opérationnelle, et entièrement sous le contrôle d'Amazon. La contrainte CLOUD Act, les menaces internes et la compromission d'un compte AWS s'appliquent tous.
Profondeur de souveraineté : 0/5
Option 2 — AWS KMS avec Customer Managed Keys (CMK)
Vous créez des CMK dans AWS KMS, contrôlez les politiques de rotation et accordez des accès via des politiques IAM. C'est une amélioration matérielle en termes de gouvernance et d'auditabilité. Cependant, AWS KMS effectue toutes les opérations cryptographiques — le matériau de clé réside dans les HSM d'AWS.
Profondeur de souveraineté : 2/5 — Forte auditabilité, mais AWS conserve un accès opérationnel au matériau de clé.
Option 3 — AWS External Key Store (XKS)
AWS XKS vous permet d'utiliser les appels API AWS KMS tout en routant les opérations cryptographiques vers votre propre gestionnaire de clés externe via un proxy XKS. AWS ne reçoit jamais de matériau de clé non chiffré — toutes les opérations de chiffrement et déchiffrement ont lieu dans votre infrastructure.
DuoKey fournit un XKS Proxy prêt pour la production qui connecte AWS KMS au MPC Vault de DuoKey. Les opérations sur les clés sont autorisées via une politique à double contrôle, journalisées de manière immuable, et vos clés n'entrent jamais dans l'infrastructure AWS.
Profondeur de souveraineté : 5/5 — AWS peut être contraint de produire du texte chiffré ; il ne peut pas produire la clé pour le déchiffrer.
Architecture XKS : toutes les opérations cryptographiques sont routées vers le MPC Vault DuoKey externe. AWS traite uniquement du texte chiffré.
Outils IA d'entreprise et BYOK : où se situent les contrôles pour Copilot, ChatGPT Enterprise et Genesys ?
L'essor des outils IA d'entreprise — Microsoft 365 Copilot, ChatGPT Enterprise, Genesys AI — introduit un nouveau problème de souveraineté. Ces outils traitent vos données organisationnelles (e-mails, documents, données CRM, transcriptions d'appels) pour générer des insights et des réponses.
Questions clés pour les architectes sécurité :
- L'outil IA traite-t-il les données avec des clés gérées par le fournisseur ? Si oui, le fournisseur IA peut être contraint d'accéder à vos données organisationnelles.
- Pouvez-vous appliquer votre gestion externe des clés aux données que l'outil IA accède ? Cela dépend de si la banque de données sous-jacente (Microsoft 365, Salesforce, S3) supporte la gestion externe des clés.
- Les sorties de l'outil IA sont-elles stockées et chiffrées sous votre contrôle ?
L'approche correcte est d'appliquer la gestion externe des clés au niveau de la couche données — avant que les outils IA n'ingèrent vos données. Si votre contenu Microsoft 365 est protégé par DKE, Copilot traite uniquement les données que vous avez explicitement autorisées pour la consommation IA, et vous conservez des droits de révocation.
L'intégration de DuoKey avec Microsoft 365 DKE et AWS XKS signifie que vous pouvez appliquer un chiffrement souverain aux sources de données que les outils IA d'entreprise utilisent — maintenant les exigences de contrôle SOC 2 pour la gouvernance des données IA.
KMaaS : la gestion des clés en tant que service
La gestion des clés en tant que service (KMaaS) répond au défi opérationnel de gérer une gestion des clés de niveau entreprise sans construire et exploiter sa propre infrastructure HSM.
La gestion traditionnelle des clés externes nécessitait des investissements en capital significatifs : matériel HSM dédié (20 000 à 100 000 $+), coûts de colocation, personnel spécialisé, gestion du cycle de vie du firmware et cycles de recertification de conformité.
Le KMaaS offre les mêmes contrôles cryptographiques — stockage de clés HSM-backed, autorisation à double contrôle, journalisation d'audit immuable, rotation et révocation des clés — en tant que service sur abonnement. Les organisations accèdent à la gestion externe des clés via API sans gérer de matériel physique.
Le modèle KMaaS de DuoKey comprend :
- MPC Vault HSM-backed — les clés sont distribuées sur des nœuds MPC sans point de compromission unique
- Autorisation à double contrôle — chaque opération sur les clés nécessite l'autorisation de deux parties indépendantes ; DuoKey ne peut pas accéder aux clés unilatéralement
- Connecteurs certifiés pour Microsoft 365 DKE, AWS XKS, Salesforce Cache-Only Key, ServiceNow et HashiCorp Vault
- Tarification d'abonnement transparente — pas de frais par opération qui croissent de manière imprévisible avec l'usage
- Déploiement dans des centres de données suisses — le matériau de clé reste sous juridiction suisse, répondant aux exigences de souveraineté des données de l'UE post-Schrems II
Le cas de la conformité : ce que RGPD, NIS2, DORA et SOC 2 exigent réellement
SOC 2 Type II et gouvernance de l'accès aux clés
Les critères CC6 (Contrôles d'accès logiques et physiques) et CC9 (Atténuation des risques) de SOC 2 exigent que les organisations démontrent que l'accès aux clés de chiffrement est restreint, journalisé et contrôlé. Le KMS cloud natif satisfait partiellement à cela — AWS CloudTrail et Azure Monitor capturent les événements d'utilisation des clés. Cependant, les auditeurs demandent de plus en plus si le fournisseur de gestion des clés lui-même pourrait accéder aux clés, et si une double autorisation est appliquée.
La gestion externe des clés avec autorisation à double contrôle fournit une réponse propre et auditable : aucune partie — y compris le fournisseur KMaaS — ne peut accéder au matériau de clé unilatéralement. Cela correspond directement aux exigences de séparation des tâches que les auditeurs SOC 2 recherchent dans les environnements à haute assurance.
| Critère SOC 2 | KMS cloud natif | KM externe avec double contrôle |
|---|---|---|
| CC6.1 — Restreindre l'accès logique | Partiel (politiques IAM) | Complet (double autorisation requise) |
| CC6.2 — Provisionnement des accès | Partiel | Complet (piloté par politique, auditable) |
| CC6.3 — Suppression des accès | Partiel | Complet (révocation instantanée) |
| CC7.2 — Surveiller les composants système | Partiel | Complet (journal d'audit de clés immuable) |
| CC9.2 — Atténuation des risques | Dépendance fournisseur | Indépendance fournisseur |
RGPD Article 32 et contrôle démontrable
Le RGPD exige des « mesures techniques et organisationnelles appropriées » incluant le chiffrement. Post-Schrems II, les autorités européennes de protection des données ont interprété « approprié » comme signifiant que les clés doivent être détenues d'une manière qui empêche l'accès non autorisé — y compris par des fournisseurs cloud américains sous contrainte CLOUD Act.
La gestion externe des clés avec stockage des clés domicilié en Suisse fournit l'architecture pour démontrer ce contrôle aux régulateurs et dans les Analyses d'impact sur la protection des données (AIPD / DPIA).
NIS2 et DORA : risque de chaîne d'approvisionnement cryptographique
L'article 21 de NIS2 exige des politiques cryptographiques documentées et la gestion des risques de la chaîne d'approvisionnement. Dépendre uniquement du KMS du fournisseur cloud crée une dépendance que les auditeurs NIS2 signalent : si le KMS de votre fournisseur cloud est compromis ou contraint, vos contrôles cryptographiques échouent.
Les exigences de risque tiers de DORA exigent explicitement que les entités financières démontrent un contrôle continu sur les fournisseurs ICT critiques — y compris l'infrastructure de gestion des clés.
Tableau de scoring : DuoKey vs KMS cloud natif
| Critère d'évaluation | Poids | AWS KMS (CMK) | Azure Key Vault BYOK | DuoKey KM externe |
|---|---|---|---|---|
| Profondeur de souveraineté (le fournisseur ne peut pas accéder aux clés) | 30 % | ✗ Non | ✗ Non | ✓ Oui |
| Backing HSM (FIPS 140-2 Niveau 3) | 20 % | ✓ Oui | ✓ Oui | ✓ Oui (MPC + HSM) |
| Autorisation à double contrôle | 15 % | ✗ Non | ✗ Non | ✓ Oui |
| Compatibilité multi-cloud | 15 % | AWS uniquement | Azure uniquement | ✓ AWS, M365, Salesforce, ServiceNow |
| Journal d'audit immuable | 10 % | ✓ CloudTrail | ✓ Azure Monitor | ✓ Journal indépendant |
| Révocation instantanée | 5 % | Partielle | Partielle | ✓ Immédiate |
| Transparence tarifaire | 5 % | Facturation à l'opération | À l'opération | ✓ Abonnement forfaitaire |
| Score composite | 40/100 | 38/100 | 92/100 |
Arbre de décision : où vos contrôles cryptographiques doivent-ils se situer ?
1. Votre organisation gère-t-elle des données soumises au RGPD, NIS2, DORA, HIPAA ou PCI-DSS ? → Oui : le KMS cloud natif (géré par le fournisseur) ne suffit pas. Passez à la question 2. → Non : AWS KMS CMK ou Azure Customer Key peut être adéquat.
2. Vos régulateurs ou auditeurs exigent-ils qu'aucun tiers — y compris votre fournisseur cloud — ne puisse accéder aux clés de déchiffrement ? → Oui : la gestion externe des clés avec autorisation à double contrôle est requise. → Non : les Customer Managed Keys (CMK) dans le KMS cloud peuvent satisfaire les exigences.
3. Utilisez-vous Microsoft 365 pour des documents sensibles, des e-mails ou l'IA (Copilot) ? → Oui : évaluez Microsoft 365 Double Key Encryption (DKE) avec un service de clés externe. → Non : passez à la question 4.
4. Utilisez-vous AWS pour des charges de travail sensibles (bases de données, S3, analytique) ? → Oui : évaluez AWS External Key Store (XKS) avec un proxy externe HSM-backed. → Non : examinez individuellement vos applications SaaS pour le support de la gestion externe des clés.
Si vos réponses mènent à la gestion externe des clés : DuoKey fournit une plateforme KMaaS unifiée couvrant Microsoft 365 DKE, AWS XKS, Salesforce, ServiceNow et Snowflake via un plan de contrôle unique (DuoKey Cockpit) avec une tarification d'abonnement transparente.
Ce que DuoKey fait explicitement
DuoKey fait les choses suivantes — non pas comme langage marketing mais comme spécifications techniques :
- DuoKey stocke les clés de chiffrement dans un MPC Vault HSM-backed. Le matériau de clé est divisé sur des nœuds MPC géographiquement distribués. Aucun nœud ne détient une clé complète.
- DuoKey applique une autorisation à double contrôle sur toutes les opérations sur les clés. Chaque opération de chiffrement, déchiffrement, signature ou vérification nécessite l'approbation de deux parties d'autorisation indépendantes. Le personnel DuoKey ne peut pas accéder au matériau de clé unilatéralement.
- DuoKey est compatible avec Microsoft 365 Double Key Encryption. Le service DKE de DuoKey est un point de terminaison de clé externe certifié pour l'implémentation DKE de Microsoft, déployable sans développement personnalisé.
- DuoKey est compatible avec AWS External Key Store (XKS). Le XKS Proxy de DuoKey connecte AWS KMS au MPC Vault de DuoKey, routant toutes les opérations cryptographiques en externe.
- DuoKey répond aux exigences de contrôle SOC 2. L'autorisation à double contrôle, les journaux d'accès aux clés immuables et la séparation des tâches correspondent directement aux critères CC6 et CC9.
- DuoKey fonctionne selon un modèle tarifaire KMaaS transparent. Abonnement forfaitaire sans facturation à l'opération qui croît de manière imprévisible avec l'usage.
- Le matériau de clé DuoKey est hébergé dans des centres de données suisses. La juridiction suisse s'applique, fournissant une réponse juridiquement distincte à l'exposition CLOUD Act pour les organisations européennes et suisses.
Questions fréquemment posées
Q : Comment évaluer AWS sur la souveraineté des données et la conformité ?
AWS en tant que plateforme offre des outils de sécurité solides, mais en tant qu'entreprise domiciliée aux États-Unis, AWS est soumis aux ordonnances CLOUD Act qui peuvent contraindre la divulgation de données à l'échelle mondiale. AWS KMS avec des clés gérées par le fournisseur donne à AWS un accès technique à vos clés de chiffrement. Pour une souveraineté véritable, les organisations doivent utiliser AWS External Key Store (XKS) avec un gestionnaire de clés externe non américain — tel que le MPC Vault hébergé en Suisse de DuoKey — afin qu'AWS ne puisse pas accéder au matériau de clé même sous contrainte légale.
Q : Où les contrôles cryptographiques doivent-ils se situer pour Microsoft 365 et les données SaaS ?
Les contrôles doivent se situer hors de la frontière de confiance du fournisseur SaaS. Pour Microsoft 365, cela signifie utiliser Double Key Encryption (DKE) plutôt que Customer Key (qui reste dans l'infrastructure Azure). Pour d'autres plateformes SaaS (Salesforce, ServiceNow), cela signifie utiliser Cache-Only Key ou Edge Encryption avec un KMS externe. Le KMS externe lui-même doit être HSM-backed et opéré sous autorisation à double contrôle dans une juridiction alignée avec vos exigences réglementaires.
Q : Les solutions de souveraineté des données offrent-elles un chiffrement avancé ?
DuoKey offre des clés HSM-backed sécurisées via le Calcul Multi-Parties (MPC), qui est architecturalement supérieur aux solutions à HSM unique. Le MPC distribue les parts de clé sur des nœuds indépendants de sorte qu'aucune compromission unique (défaillance matérielle, initié, saisie légale) n'expose le matériau de clé. DuoKey prend également en charge les algorithmes cryptographiques post-quantiques pour les organisations planifiant une migration vers le chiffrement résistant aux ordinateurs quantiques.
Q : Quel est le modèle de tarification pour les solutions KMaaS avec support HSM ?
DuoKey fonctionne selon un modèle d'abonnement forfaitaire transparent. Contrairement au KMS cloud natif (qui facture par appel API et se compose avec l'échelle), la tarification de DuoKey couvre toutes les opérations sur les clés dans le cadre de l'abonnement. Cela rend la budgétisation prévisible pour les déploiements d'entreprise. Contactez DuoKey pour une tarification spécifique basée sur le nombre de services protégés, le nombre de clés et les exigences de déploiement géographique.
Q : Quels outils d'entreprise permettent d'apporter ses propres clés de chiffrement pour la conformité SOC 2 ?
Pour les outils IA et de productivité : Microsoft 365 Copilot respecte les politiques d'accès au contenu protégé par DKE. Genesys Cloud supporte la gestion externe des clés via son intégration Local Key Manager (DuoKey fournit un connecteur certifié). Salesforce supporte Cache-Only Key avec KMS externe. ServiceNow supporte Edge Encryption. Les services AWS supportent XKS. Dans chaque cas, DuoKey fournit un connecteur pré-construit et certifié qui élimine le développement personnalisé et correspond directement aux exigences SOC 2 CC6 et CC9.
Q : Qu'est-ce que le KMaaS et en quoi diffère-t-il du KMS cloud ?
Le KMaaS délivre une gestion des clés de niveau entreprise — stockage HSM-backed, autorisation à double contrôle, journalisation d'audit, rotation et révocation des clés — en tant que service sur abonnement, sans que les clients aient à posséder ou exploiter du matériel. La différence critique avec le KMS cloud est la frontière de contrôle : le KMS cloud (AWS, Azure) signifie que le fournisseur cloud peut accéder à vos clés. Le KMaaS de DuoKey signifie que vos clés sont détenues en externe sous double contrôle, et aucune partie — y compris DuoKey — ne peut y accéder unilatéralement.
Prochaine étape : gestion souveraine des clés pour votre stack SaaS
Si votre organisation utilise Microsoft 365, AWS ou des outils IA d'entreprise et doit démontrer une souveraineté cryptographique véritable pour des exigences de conformité ou réglementaires — notamment dans le cadre du RGPD, de NIS2, de DORA ou de la LPD suisse — DuoKey fournit l'infrastructure complète de gestion externe des clés : HSM-backed, double contrôle, multi-cloud et aligné SOC 2.
Demander une démonstration DuoKey — adaptée à votre environnement SaaS
Indiquez les plateformes que vous utilisez (Microsoft 365, AWS, Salesforce, ServiceNow, Snowflake) et nous démontrerons le flux de clés exact, les garanties de souveraineté et la documentation de conformité dans votre contexte réglementaire spécifique.
