Pourquoi le chiffrement Microsoft 365 par défaut ne suffit pas
Cet article explore les limites du chiffrement Microsoft 365 « standard » et explique pourquoi les organisations doivent renforcer leurs contrôles pour protéger les données sensibles.
Microsoft 365 chiffre vos données. C’est vrai. Microsoft utilise le chiffrement AES-256, TLS pour les données en transit et BitLocker au repos. Ce sont des mesures reconnues dans l’industrie.
Mais « chiffré » ne veut pas dire « inaccessible à tous ».
Lorsque Microsoft gère les clés de chiffrement, Microsoft peut accéder à vos données. Pour la majorité des organisations, c’est acceptable. Pour les secteurs réglementés, la propriété intellectuelle sensible ou les données soumises à d’exigeantes exigences de souveraineté, c’est un vide important.
Voyons pourquoi le chiffrement M365 par défaut atteint vite ses limites — et ce que vous pouvez y faire.
Le vrai problème : les clés
Un chiffrement n’est fiable que si le contrôle des clés l’est aussi.
Avec le chiffrement M365 par défaut, Microsoft génère, stocke et exploite les clés dans Azure Key Vault. Microsoft applique de solides pratiques de sécurité, mais le fond du problème reste : qui détient la clé peut déchiffrer.
Trois risques en découlent :
1. Exposition en cas d’incident
En 2023, l’attaque Storm-0558 a compromis une clé de signature de compte Microsoft. Les attaquants l’ont utilisée pour accéder à Outlook Web Access chez plus de vingt-cinq organisations. Avec cette clé, ils pouvaient lire des courriels, accéder à des fichiers SharePoint et usurper des identités Azure AD.
Avec des clés réellement contrôlées par le client, la seule compromission de la clé Microsoft n’aurait pas suffi à déchiffrer leurs données protégées distinctement.
2. Accès des autorités
Microsoft est une société américaine. Au titre de textes tels que le CLOUD Act, les autorités américaines peuvent contraindre Microsoft à fournir l’accès aux données clients stockées n’importe où dans le monde — souvent sans information du responsable du traitement.
Pour les organisations européennes soumises au RGPD ou les entreprises suisses sous FINMA, cela entre en tension directe avec les obligations de protection des données.
3. Lacunes de conformité
Des cadres tels que le RGPD, HIPAA ou la réglementation financière exigent de démontrer le contrôle sur l’accès aux données. Si le fournisseur cloud détient les clés, vous ne pouvez pas prouver un contrôle exclusif.
Certains auditeurs acceptent le chiffrement entièrement géré par Microsoft. Beaucoup d’autres non.
Exigences de conformité par secteur
Les cadres les plus stricts attendent à la fois du chiffrement et des preuves que le déchiffrement ne repose pas uniquement sur la seule discrétion opérationnelle du fournisseur cloud. Voici des obligations représentatives qui recoupent la manière dont les clés M365 sont contrôlées.
Services financiers (UE) — DORA
Le Digital Operational Resilience Act (DORA) (règlement (UE) 2022/2554) s’applique à un large périmètre d’entités financières et fixe des attentes en matière de gestion des risques TIC, y compris des pratiques sécurisées pour les prestataires tiers. L’article 28 traite notamment de la gestion des risques de sous-traitance TIC — pertinent lorsqu’un même fournisseur héberge les données et opère les clés. Pour une lecture opérationnelle du rôle du chiffrement et d’une gouvernance des clés distribuée, voir la page DuoKey conformité DORA.
Entités essentielles et importantes (UE) — NIS2
La directive NIS2 (directive (UE) 2022/2555) étend les obligations de cybersécurité à de nombreux secteurs, de l’énergie aux infrastructures numériques en passant par certaines administrations publiques. Le paragraphe 21(2)(h) impose des politiques et procédures relatives à la cryptographie et, le cas échéant, au chiffrement — souvent interprété avec des attentes de gouvernance des clés vérifiables. Guide détaillé : NIS2 : exigences de chiffrement et conformité.
Administration publique suisse — protection des données et confidentialité
Les autorités fédérales et cantonales traitent souvent des données personnelles sensibles ou des informations soumises à des obligations légales de confidentialité (secret professionnel, secret officiel, etc.). La Loi fédérale sur la protection des données (LPD) impose des mesures techniques et organisationnelles appropriées ; des dispositions fédérales et cantonales complètent le cadre pour les documents officiels et certains secteurs. Les autorités de protection des données suisses ont insisté sur le fait que lorsque le fournisseur cloud peut techniquement accéder aux clés de déchiffrement, les déploiements standards de M365 peuvent être insuffisants pour les catégories les plus sensibles — et que des architectures comme le Double Key Encryption, qui maintiennent une clé décisive hors de l’environnement du fournisseur, sont pertinentes. Voir l’approche DuoKey : Microsoft 365 et administration publique suisse.
Ce qu’apporte Customer Key
Customer Key va au-delà du chiffrement par défaut : vous fournissez des clés racines que Microsoft utilise pour chiffrer vos données.
Cela ajoute une couche sous contrôle client :
- Chiffrement de service Microsoft (toujours présent)
- Votre Customer Key (dans Azure Key Vault, rattachée à votre locataire)
- BitLocker (couche physique)
Customer Key améliore le contrôle, mais les clés restent dans l’infrastructure Microsoft. En cas de compromission de votre locataire Azure, vos Customer Keys sont exposées.
Ce qu’apporte le Double Key Encryption
Le Double Key Encryption (DKE) va plus loin : il faut deux clés distinctes pour déchiffrer le contenu protégé :
- Une clé dans Azure Key Vault (à laquelle Microsoft peut accéder)
- Une clé dans un système externe (à laquelle Microsoft ne peut pas accéder)
Les deux sont nécessaires. Microsoft ne peut pas déchiffrer le contenu DKE sans votre clé externe.
Conséquences :
- Protection contre les attaques — il faut compromettre deux systèmes distincts
- Souveraineté — votre clé externe peut rester dans votre juridiction
- Conformité — vous pouvez démontrer que Microsoft ne peut pas accéder au contenu protégé
Quand le chiffrement par défaut ne suffit pas
Il convient aux données métier courantes. Envisagez un renforcement lorsque :
- Vous traitez des données soumises au RGPD, HIPAA, FINMA ou équivalent
- Votre secteur présente un risque d’incident élevé (finance, santé, juridique)
- Vous stockez de la propriété intellectuelle ou des secrets d’affaires
- Vous opérez sous des exigences de souveraineté des données
- Les auditeurs exigent une preuve de contrôle exclusif sur l’accès
Pour beaucoup d’organisations, cela concerne environ 5 à 10 % des données — le noyau réellement sensible.
Mettre en œuvre le DKE avec DuoKey
DuoKey fournit la composante externe de gestion des clés pour le Double Key Encryption Microsoft.
Contrairement à un déploiement HSM classique, DuoKey s’appuie sur la gestion de clés en MPC : la clé est répartie entre plusieurs serveurs indépendants. Aucune entité unique — ni DuoKey, ni un administrateur — ne détient jamais la clé complète.
Cela réduit les points de défaillance uniques tout en conservant la simplicité d’un service managé.
Conclusion
Le chiffrement Microsoft 365 protège vos données contre des attaquants externes. Il ne les protège pas contre Microsoft, contre des réquisitions transitant par Microsoft, ni contre une compromission de l’infrastructure Microsoft elle-même.
Pour les données sensibles, cette distinction compte.
Le Double Key Encryption comble cet écart en exigeant une seconde clé qui n’entre jamais dans l’environnement Microsoft. Vos données restent chiffrées même si les systèmes Microsoft sont compromis.
La question n’est pas de savoir si le chiffrement M365 est « bon ». Elle est de savoir s’il est suffisant pour vos données les plus sensibles. Pour de nombreuses organisations, la réponse est non.
Prochaine étape : voir la démo DKE DuoKey sur la page produit Microsoft 365.
