Sovereign protection of confidential documents: The double encryption solution
Laurent TERUIN | 22/12/2025
French & English version
Il y a peu, les documents bureautiques sensibles créés par les utilisateurs étaient protégés par des droits d’accès positionnés sur des serveurs de fichiers ou de façon plus élaborée, à travers une Gestion Electronique de Documents.
La protection était ainsi positionnée sur le contenant plutôt que sur le contenu, laissant la possibilité à un utilisateur ayant accès à ce document de pouvoir aisément le transférer à l’extérieur de l’entreprise.
En cas de compromission de la sécurité du contenant, le hacker avait donc toute la possibilité d’accéder aux documents et de pouvoir organiser une fuite de données massive.
Une solution alternative consistait également à chiffrer le document avec un certificat dont la possession pouvait être partagée pour permettre l’accès à ces informations. La gestion du cycle de vie de ces certificats et le risque de vol de ce dernier, pouvait également compromettre l’accès aux documents chiffrés.
L’arrivée des solutions cloud a permis de renforcer considérablement d’une part, l’authentification des utilisateurs, et d’autre part, la mise en place de sécurités plus élaborées pour les documents produits par l’entreprise.
Se protéger contre l’ingérence étrangère.
L’utilisation massive de solutions américaines induit nativement un risque d’ingérence étrangère pour l’entreprise et ce, même si les documents qui reposent dans les centres de données du fournisseur sont chiffrés avec une clef de chiffrement issue de la PKI de l’entreprise.
Car vous en conviendrez , « celui qui possède la clef ouvre la porte » ; Or dans la plupart des cas comme dans l’environnement Microsoft 365, la clef de chiffrement issue de la PKI souveraine de l’entreprise doit pour des fonctions comme l’indexation , ou la coédition notamment, être accessible aux services Cloud. Autrement dit, les services cloud doivent pouvoir accéder au contenu documentaire pour offrir à l’utilisateur des services interactifs. Avec M365, la clef issue de la PKI interne est stockée dans Azure.
C’est le cas de la solution CustomerKey de Microsoft qui permet de stocker dans Azure une clef de chiffrement issue d’une PKI souveraine et qui permet de chiffrer les données du tenant avec celle-ci plutôt qu’avec celle fournie par l’entreprise Microsoft.
Si cette solution (CustomerKey) répond à des obligations légales, elle ne protège pas l’entreprise du risque d’ingérence étrangère comme ceux pouvant provenir des Etats-Unis.
2 DKE : la solution
2.1 Le principe
C’est tout l’intérêt de la solution de chiffrement à double clef (ou Double Key Encryption) présente dans l’environnement Microsoft.
Celle-ci va permettre de littéralement, « surchiffrer » un document avec un clef souveraine stockée en dehors du périmètre de sécurité du fournisseur Cloud. Autrement dit, les documents générés et classés DKE via la classification Microsoft Purview seront chiffrés une première fois par la clef de chiffrement du tenant, puis avec une clef souveraine.
L’image ci-dessous issue de la documentation Microsoft illustre ce processus de double chiffrement.
Si le document est envoyé vers l’extérieur , par courriel ou via un espace de partage vers des personnes extérieures à l’entreprise, il ne sera déchiffrable que, si l’utilisateur le recevant, est identifié comme bénéficiaire et si ce dernier est en mesure de joindre le service de chiffrement DKE souverain de l’entreprise. Si votre document DKE est téléchargé vers une IA en ligne , le contenu sera naturellement inexploitable car indéchiffrable.
Si votre service de chiffrement DKE n’est joignable uniquement que depuis les réseaux de votre entreprise alors ce document ne pourra pas être consulté à moins d’être connecté au sein de l’entreprise et de disposer d’autorisation spécifiques inscrites dans le document lui-même.
Ces autorisations doivent impérativement comprendre des identités présentes dans les métadata du document mais peuvent être également générales comme par exemple, tous les utilisateurs de votre entreprise ou un sous ensemble de personnes.
2.2 Des avantages mais aussi des limitations.
2.2.1 Limitation fonctionnelle
Le fournisseur cloud ne disposant pas de la seconde clef sera incapable d’accéder au contenu, ce qui nécessairement bloque certaines fonctionnalités natives. Dans l’environnement Microsoft, les fonctions ci-dessous ne sont par conséquent plus disponibles avec des productions documentaires chiffrées en DKE.
- Règles de flux de messagerie, y compris anti-malware et anti-spam, qui nécessitent une visibilité sur les pièces jointes
- Microsoft Delve
- eDiscovery
- Recherche et indexation de contenu
- Office Web Apps, y compris la fonctionnalité de co-création
- Copilot
2.2.2 Partage vers l’extérieur
Si vous devez partager vers l’extérieur des documents DKE il sera nécessaire de mettre en place un service de chiffrement DKE ouvert vers l’extérieur et déclarer dans votre annuaire un compte utilisateur permettant à la personne extérieure de s’authentifier dans le but de prouver son identité.
Certaines entreprises choisiront deux clefs de chiffrement documentaires, une clef de chiffrement interne uniquement accessible depuis les réseaux de l’entreprise et une autre accessible de l’extérieur.
Vous disposerez également de la fonctionnalité d’expiration datée d’un document rendant impossible son déchiffrement après une date précise et ce même si les ayants droits ont été déclarés.
2.2.3 Suppression d’une clef DKE
Si en théorie la suppression des clefs DKE est possible, elle est cependant compliquée sauf à parfaitement s’assurer qu’aucun document chiffré ayant eu recours à cette clef n’existe au préalable. Dans le cas contraire, les documents chiffrés avec une clef supprimée demeureront indéchiffrables.
2.3 Des avantages mais aussi des obligations
2.3.1 Haute disponibilité du service et stockage Offline.
Les documents étants doublement chiffrés (une fois par la clef du tenant, la seconde fois par la clef souveraine), l’importance de la présence de ces clefs est cruciale. Sans ces deux clefs et notamment la clef DKE, l’accès au document demeurera impossible. Le service de publication de ces clefs devant par conséquent être implanté en prenant en compte cette obligation. La mise en cluster, la sauvegarde offline des clefs de chiffrement constituera pour le service exploitant, une obligation.
2.4 Quels services de chiffrement DKE ?
Il existe plusieurs façons de mettre en place un service de chiffrement DKE. Naturellement, vous devez impérativement prendre en compte les contraintes de sécurité de votre entreprise et garantir la haute disponibilité du service.
Le service en question de chiffrement DKE peut, soit être déployé via une solution fournie par Microsoft (Solution qui s’apparente plutôt à une solution de PoC, plutôt qu’à une solution ayant vocation à fonctionner en production) soit avec une solution d’éditeur tiers.
Le recours à des solutions du marché validées par Microsoft comme celles présentées ci-dessous seront plus à même de garantir la disponibilité du service et offriront des fonctionnalités complémentaires. ( à étudier)
3 Conclusion
La solution DKE est une solution robuste et efficace pour assurer une protection documentaire de qualité . Elle nécessite naturellement la prise en compte des contraintes de sécurité et de disponibilité, et ne fera pas l’impasse d’un accompagnement utilisateur. Accompagnée des fonctions de classification Purview elle permettra de mieux protéger les données documentaires de l’entreprise.
*************************************************************************************************************
Until recently, sensitive office documents created by users were protected by access rights placed on file servers or in a more elaborate way, through Electronic Document Management.
The protection was thus positioned on the container rather than on the content, leaving the possibility for a user with access to this document to be able to easily transfer it outside the company.
In the event of a compromise of the security of the container, the hacker had every opportunity to access the documents and be able to organize a massive data leak.
An alternative solution was also to encrypt the document with a certificate that could be shared possession to allow access to this information. Managing the lifecycle of these certificates and the risk of theft could also compromise access to encrypted documents.
The arrival of cloud solutions has made it possible to considerably strengthen user authentication, on the one hand, and on the other hand, the implementation of more elaborate security for the documents produced by the company.
The massive use of American solutions natively induces a risk of foreign interference for the company, even if the documents that reside in the provider’s data centers are encrypted with an encryption key from the company’s PKI.
For you will agree, « he who has the key opens the door »; However, in most cases, as in the Microsoft 365 environment, the encryption key from the company’s sovereign PKI must be accessible to Cloud services for functions such as indexing, or co-editing in particular. In other words, cloud services must be able to access document content to provide the user with interactive services. With M365, the key from the internal PKI is stored in Azure.
This is the case of Microsoft’s CustomerKey solution, which allows an encryption key from a sovereign PKI to be stored in Azure and allows the tenant’s data to be encrypted with it rather than with the one provided by Microsoft.
While this solution (CustomerKey) meets legal obligations, it does not protect the company from the risk of foreign interference such as those that may come from the United States.
2 DKE : la solution
2.1 The principle
This is the whole point of the Double Key Encryption solution present in the Microsoft environment. This will make it possible to literally « over-encrypt » a document with a sovereign key stored outside the cloud provider’s security perimeter. In other words, documents generated and classified DKE via the Microsoft Purview classification will be encrypted first by the tenant’s encryption key, and then with a sovereign key.
The image below from the Microsoft documentation illustrates this double encryption process.
If the document is sent externally, by email or via a sharing space to people outside the company, it will only be decipherable if the user receiving it is identified as the beneficiary and if the user is able to reach the company’s sovereign DKE encryption service. If your DKE document is uploaded to an online AI, the content will naturally be unusable because it cannot be deciphered.
If your DKE encryption service can only be reached from your company’s networks, then this document will not be available for viewing unless you are logged in within the company and have specific permissions written into the document itself.
These permissions must include identities present in the document’s metadata, but can also be general, such as all users in your company or a subset of people.
2.2 Advantages but also limitations.
2.2.1 Functional limitation
The cloud provider that does not have the second key will be unable to access the content, which necessarily blocks some native features. In the Microsoft environment, the following functions are therefore no longer available with DKE-encrypted document productions.
- Mail flow rules, including anti-malware and anti-spam, that require visibility into attachments
- Microsoft Delve
- eDiscovery
- Content Search and Indexing
- Office Web Apps, including co-authoring functionality
- Copilot
2.2.2 Sharing to the outside world
If you need to share DKE documents externally, it will be necessary to set up a DKE encryption service open to the outside world and declare in your directory a user account allowing the external person to authenticate themselves in order to prove their identity.
Some companies will choose two document encryption keys, an internal encryption key that can only be accessed from the company’s networks and another that can be accessed from the outside.
You will also have the feature of expiring a document dated making it impossible to decrypt it after a specific date, even if the rights holders have been declared.
2.2.3 Deleting a DKE key
While in theory the removal of DKE keys is possible, it is however complicated unless you make sure that no encrypted document that has used this key exists beforehand. Otherwise, documents encrypted with a deleted key will remain indecipherable.
2.3 Advantages but also obligations
2.3.1 High availability of the service and offline storage.
As the documents are doubly encrypted (once by the key of the holder, the second time by the sovereign key), the importance of the presence of these keys is crucial. Without these two keys, and in particular the DKE key, access to the document will remain impossible. The service for the publication of these keys must therefore be implemented taking this obligation into account. Clustering, offline backup of encryption keys will be an obligation for the operating service.
2.4 Which DKE encryption services?
There are a few ways to set up a KEI encryption service. Naturally, it is imperative that you take into account the security constraints of your company and guarantee the high availability of the service.
The DKE encryption service in question can either be deployed via a solution provided by Microsoft (a solution that is more like a PoC solution, rather than a solution intended to work in production) or with a third-party vendor solution
The use of Microsoft-validated solutions on the market such as those presented below will be more likely to guarantee the availability of the service and will offer complementary functionalities.
3 Conclusion
The DKE solution is a robust and effective solution to ensure quality document protection. It naturally requires security and availability constraints to be taken into account, and will not ignore user support. Accompanied by Purview classification functions, it will better protect the company’s document data.
Travailler ensemble 