Six critères pratiques pour choisir un fournisseur Microsoft 365 Double Key Encryption (DKE) : rotation avec continuité, provisioning Graph, multi-tenant B2B, ABAC, custody des clés et opérations.
Microsoft 365 Double Key Encryption (DKE) ne livre un contrôle indépendant que si le fournisseur de la seconde clé peut opérer les clés comme une équipe sécurité gère réellement la production : rotator sans casser les labels, provisionner proprement dans Azure, supporter les tenants partenaires, et enforce qui peut unwraper sous quel contexte.
Utilisez ces six critères pour shortlister un fournisseur de clés DKE. Ce sont des tests de capacité, pas un classement vendors. Demandez à chaque candidat de les démontrer en pilot.
Demandez : Quand nous rotatons une clé DKE, les utilisateurs continuent-ils d'ouvrir le contenu protégé sans un nouveau déploiement de labels Purview ni un programme de change management ?
Pourquoi ça compte. Une rotation qui force de nouveaux labels, une reclassification ou un weekend de documents cassés sera reportée. Une rotation reportée, c'est du risque résiduel.
Ce à quoi ressemble le bon. Une fenêtre de cache configurable pour que la clé précédente serve encore les opérations de déchiffrement pendant la rotation. La continuité est un comportement produit, pas une excuse de runbook.
Demandez : L'app registration Azure et le câblage de l'endpoint DKE sont-ils provisionnés via Microsoft Graph, ou est-ce une checklist manuelle dans le portail ?
Pourquoi ça compte. Le drift d'app registration manuelle, c'est ainsi que les pilots calent et que la production diverge du diagramme.
Ce à quoi ressemble le bon. Provisioning automatisé via Graph de l'application registration et de la configuration requise, répétable par environnement.
Demandez : Les domaines partenaires et les issuers dédiés peuvent-ils participer sans aplatir tout le monde dans un seul modèle de trust tenant ?
Pourquoi ça compte. Les estates réels incluent filiales, cabinets d'avocats et guests B2B. Un DKE qui ne marche que pour un tenant propre échoue au premier test de collaboration externe.
Ce à quoi ressemble le bon. Support des domaines partenaires et issuers dédiés pour que la collaboration cross-tenant reste sous politique de clé explicite.
Demandez : L'unwrap peut-il être refusé ou autorisé selon utilisateur, IP, localisation, heure, groupes Azure et état MFA, pas seulement « membre du groupe X » ?
Pourquoi ça compte. Un DKE sans contrôle d'accès contextuel devient binaire : quiconque peut s'authentifier au key service peut unwraper. Ce n'est pas ainsi que le mail et les fichiers réglementés sont censés fonctionner.
Ce à quoi ressemble le bon. Règles attribute-based évaluées à chaque accès clé : identité, réseau, geo, heure, membership de groupe, MFA.
Demandez : Qui peut reconstruire ou utiliser seul la clé contrôlée par le client ? Une seule partie (y compris le vendor DKE ou l'hyperscaler) détient-elle un secret d'unwrap complet ?
Pourquoi ça compte. DKE existe pour que Microsoft ne puisse pas unwraper seul. La seconde clé ne doit pas recréer un nouveau point unique de compromission chez le fournisseur.
Ce à quoi ressemble le bon. Contrôle côté client avec technologie de clé distribuée (par exemple MPC) pour qu'aucun opérateur ni appliance seul ne détienne la clé complète. Voir MPC vs HSM.
Demandez : Pouvons-nous montrer aux auditeurs qui a accédé aux clés, quand la rotation a eu lieu, et comment les issuers B2B sont scopés, sans exporter le savoir tribal de l'implémenteur ?
Pourquoi ça compte. Les programmes de souveraineté échouent aux audits sur les preuves, pas sur les slides.
Ce à quoi ressemble le bon. Pistes d'audit, ownership de clé clair, historique de rotation documenté, et runbooks opérationnels qui correspondent à ce que le produit fait réellement.
Sur DuoKey for Microsoft 365 DKE, ces critères sont des capacités produit, pas des slogans roadmap :
| Critère | Comportement DuoKey |
|---|---|
| Rotation avec continuité | Fenêtre de cache configurable ; la clé précédente sert encore pendant la rotation ; pas de nouveau label Purview requis pour la continuité |
| Provisioning Graph | Application registration Azure provisionnée automatiquement via Microsoft Graph |
| Multi-tenant / B2B | Domaines partenaires et issuers dédiés |
| ABAC contextuel | Contrôle d'accès par utilisateur, IP, localisation, heure, groupes Azure et MFA |
| Custody indépendante | Key management distribué MPC ; Microsoft ne détient pas votre seconde clé |
| Opérabilité | Modèle tenant/vault dédié avec règles granulaires hors Microsoft |
Utilisez les six questions ci-dessus contre tout fournisseur, y compris nous. La bonne shortlist est celle qui peut démontrer chaque item avec votre tenant, pas celle avec le plus long PDF de features.
Évaluer les fournisseurs DKE sur la seule familiarité de marque rate les défaillances opérationnelles qui tuent les programmes : rotation qui casse les labels, câblage Azure manuel, pas de chemin B2B, et règles d'unwrap qui ignorent le contexte. Scorez chaque candidat sur ces six critères en pilot. Gardez Microsoft hors de la seconde clé, et empêchez votre propre fournisseur de devenir le nouveau point unique de défaillance.
Écrit par
Nagib Aouini
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
