Contrôle d'accès Zero Trust pour Microsoft 365
Contrôle d'accès Zero Trust
Politiques d'accès conditionnel pour les opérations sur les clés de chiffrement, une première dans le secteur — disponible uniquement avec DuoKey
Pourquoi le Zero Trust pour les clés de chiffrement ?
Microsoft 365 utilise un chiffrement robuste pour protéger les données, mais il ne dispose pas de contrôles granulaires sur les personnes pouvant accéder aux clés de chiffrement elles-mêmes. Lorsqu'un utilisateur autorisé a accès aux clés, cet accès est généralement binaire — il l'a ou il ne l'a pas, indépendamment d'autres facteurs de risque tels que la localisation, la sécurité de l'appareil ou l'heure d'accès.
DuoKey comble cette lacune en appliquant les principes du zero-trust spécifiquement à la gestion des clés de chiffrement. Chaque requête d'accès à une clé est évaluée par rapport à plusieurs conditions avant d'être accordée — garantissant que même les utilisateurs autorisés doivent satisfaire à des critères de sécurité supplémentaires.
DuoKey est le seul fournisseur DKE à offrir un contrôle d'accès Zero Trust pour les clés de chiffrement. Aucun autre fournisseur — ni Thales, Entrust, Fortanix ou Utimaco — ne propose ce niveau d'accès conditionnel granulaire pour Microsoft 365 Double Key Encryption.
Architecture
Le contrôle d'accès Zero Trust de DuoKey se situe entre la requête d'accès à une clé de l'utilisateur et le service de clés DKE. Chaque requête est évaluée par rapport à vos politiques configurées avant que l'opération sur la clé ne soit autorisée.
Vérifier explicitement
Chaque requête d'accès à une clé est authentifiée et autorisée en fonction de tous les points de données disponibles : identité de l'utilisateur, localisation, appareil et appartenance à des groupes
Accès au moindre privilège
Limitez l'accès aux clés avec des politiques d'accès juste-à-temps et juste-suffisant. Appliquez des règles granulaires d'inclusion, d'exigence et d'exclusion
Présumer la compromission
Réduisez le rayon d'impact grâce à un accès segmenté, à la vérification du chiffrement de bout en bout et à une piste d'audit complète de toutes les opérations sur les clés
Dimensions de la politique de contrôle d'accès
DuoKey évalue les requêtes d'accès aux clés selon 5 dimensions indépendantes. Chaque dimension peut inclure, exiger ou exclure des conditions spécifiques.
| Dimension | Contrôles | Exemple de cas d'usage |
|---|---|---|
| Utilisateur (e-mail) | Autoriser/bloquer des adresses e-mail ou des domaines spécifiques | N'autoriser que les cadres dirigeants à déchiffrer les documents du conseil d'administration |
| Appareil (IP) | Inclure/exiger/exclure des adresses IP et des plages | Restreindre l'accès aux clés aux seules IP du réseau d'entreprise |
| Localisation (pays) | Inclure/exclure des pays ou des régions | S'assurer que les clés ne sont accessibles que depuis la Suisse et la France |
| Groupes externes (IDP) | Filtrer par groupes Azure AD / Okta | N'autoriser que les membres du groupe AD « Project-Confidential » |
| Audit & historique | Suivi complet des modifications et piste d'audit | Suivre chaque modification de politique avec l'utilisateur, l'action et l'horodatage |
Prise en main
Étape 1 : Accéder au module de politique de contrôle d'accès
Accédez à Administration > Access control policy dans la barre latérale de DuoKey Cockpit.
Étape 2 : Consulter et gérer les politiques
Le tableau de bord Access Control Policy affiche toutes les politiques existantes avec leurs unités d'organisation associées et leurs ID externes.
Depuis le menu déroulant Actions de n'importe quelle politique, vous pouvez :
| Action | Description |
|---|---|
| View | Afficher la configuration complète de la politique en mode lecture seule |
| Edit | Modifier les règles et conditions de la politique |
| Delete | Supprimer définitivement la politique |
| History | Afficher la piste d'audit complète de toutes les modifications |
Étape 3 : Créer une nouvelle politique d'accès
Cliquez sur + Create New Access Policy pour définir une nouvelle politique d'accès conditionnel.
Nommez votre politique
Sélectionnez une action
Attribuez des unités d'organisation
Configurez les règles
Enregistrez
Actions de politique
Chaque politique peut appliquer l'une des trois actions suivantes :
| Action | Comportement |
|---|---|
| Allow | Accorder l'accès à la clé lorsque toutes les conditions sont remplies |
| Block | Refuser l'accès à la clé lorsque les conditions correspondent (remplace les règles allow) |
| Bypass | Ignorer entièrement la vérification du contrôle d'accès pour les conditions correspondantes |
Configurer les règles d'accès
Accès basé sur l'utilisateur (liste d'autorisation d'e-mails)
Contrôlez l'accès aux clés en fonction des adresses e-mail des utilisateurs. Ajoutez des utilisateurs spécifiques ou des domaines entiers à la liste d'autorisation.
Sélectionnez l'onglet Utilisateur
Choisissez le type de filtre
Ajoutez des utilisateurs
Ajoutez ou supprimez
Accès basé sur l'appareil (plages d'IP)
Restreignez l'accès aux clés à des adresses IP ou à des plages réseau spécifiques. Prend en charge les types de règles Include, Require et Exclude.
| Type de règle | Description | Exemple |
|---|---|---|
| Include | Autoriser l'accès depuis ces IP (au moins une doit correspondre) | 102.163.24.161 — bureau de l'entreprise |
| Require | L'accès DOIT provenir de ces plages d'IP | Plage VPN d'entreprise 10.0.0.0/8 |
| Exclude | Bloquer l'accès depuis ces IP (remplace include) | Plages d'IP connues comme risquées |
Sélectionnez l'onglet Appareil
Ajoutez des règles Include
Ajoutez des règles Require (facultatif)
Ajoutez des règles Exclude (facultatif)
Accès basé sur la localisation (pays)
Restreignez l'accès aux clés à des localisations géographiques spécifiques. Faites respecter la souveraineté des données en limitant les opérations sur les clés aux pays approuvés.
Sélectionnez l'onglet Localisations
Ajoutez des pays Include
Ajoutez des pays Exclude (facultatif)
Groupes externes (groupes Azure AD / Okta)
Tirez parti de vos groupes de fournisseur d'identité existants pour contrôler l'accès aux clés. Synchronisez avec les groupes Azure AD ou Okta pour un accès basé sur les rôles sans friction.
Sélectionnez l'onglet Groupes externes
Sélectionnez le fournisseur d'identité
Sélectionnez les groupes
Audit & historique
Chaque modification de politique est suivie avec une piste d'audit complète indiquant l'action, l'utilisateur et l'horodatage.
| Champ | Description |
|---|---|
| Action | Type de modification (Created, Updated, Deleted) |
| User name | L'administrateur ayant effectué la modification |
| Time | Horodatage exact de la modification |
Avantage concurrentiel
Le contrôle d'accès Zero Trust de DuoKey est une capacité inédite dans le secteur. Aucun autre fournisseur DKE ne propose de politiques d'accès conditionnel dynamiques et pilotées par interface pour les clés de chiffrement.
| Capacité | DuoKey | Thales | Entrust | Fortanix | Utimaco |
|---|---|---|---|---|---|
| Accès Zero Trust aux clés | Interface dynamique | ||||
| Liste d'autorisation d'e-mails d'utilisateurs | Interface dynamique | Statique (appsettings.json) | Statique (appsettings.json) | Statique (appsettings.json) | |
| Restriction des clés par IP | Interface dynamique | ||||
| Restriction par pays/géographie | Interface dynamique | ||||
| Intégration des groupes IDP | Interface dynamique | ||||
| Piste d'audit des politiques | |||||
| Sécurité des clés basée sur MPC | |||||
| Règles Allow/Block/Bypass | |||||
| Modifications de politiques en temps réel | Aucun redémarrage requis | Nécessite un redéploiement | Nécessite un redéploiement | Nécessite un redéploiement |
Thales, Entrust et Fortanix n'offrent qu'une autorisation statique basée sur les e-mails codée en dur dans le fichier de configuration appsettings.json. Toute modification nécessite une édition manuelle du fichier et un redéploiement du service DKE. DuoKey est la seule solution dotée d'une interface dynamique en temps réel — les politiques prennent effet immédiatement sans aucun redémarrage ni redéploiement du service.
Pourquoi les concurrents ne peuvent pas rivaliser
Les fournisseurs DKE traditionnels (Thales, Entrust, Fortanix) s'appuient sur un fichier appsettings.json statique pour définir l'autorisation basée sur les e-mails. Cette approche présente des limitations critiques :
- Aucune interface — les administrateurs doivent modifier manuellement les fichiers de configuration JSON
- Aucune règle basée sur l'IP, la localisation ou les groupes — uniquement une liste d'autorisation d'e-mails basique
- Nécessite un redéploiement — chaque modification implique de redémarrer le service DKE
- Aucune piste d'audit — aucun suivi de qui a modifié quoi et quand
- Aucune logique Include/Exclude — simple autorisation ou refus binaire, sans règles en couches
L'architecture de DuoKey, propulsée par le calcul multipartite sécurisé (MPC), permet :
Sécurité distribuée des clés
Les clés sont réparties sur plusieurs serveurs MPC indépendants. Aucune entité unique ne possède jamais la clé complète.
Accès conditionnel aux clés
Chaque requête de clé est évaluée par rapport à des politiques multidimensionnelles avant autorisation — impossible avec les architectures traditionnelles reposant uniquement sur un HSM.
Contrôle géo-souverain
Restreignez les opérations sur les clés à des pays et régions spécifiques, garantissant la conformité au RGPD, à DORA et aux lois locales sur la protection des données.
Conformité d'audit complète
Chaque accès à une clé et chaque modification de politique est journalisé avec des pistes d'audit inviolables à des fins de reporting réglementaire.