Politiques d'accès pour DKE 365 (RBAC + ABAC)
Le modèle de contrôle d'accès de Cockpit v2 pour DKE 365 — RBAC pour l'administration et politiques d'accès ABAC appliquées au déchiffrement.
Cockpit v2 possède deux couches de contrôle d'accès distinctes. Pour DKE 365, elles répondent à deux questions différentes :
| Couche | Régit | Pour DKE, cela signifie |
|---|---|---|
| RBAC (rôles & permissions) | Qui peut administrer le Cockpit | Qui peut déployer / activer / faire pivoter les services DKE |
| Politiques d\'accès ABAC | Qui, depuis où, et quand peut effectuer une opération cryptographique à l'exécution | Qui peut déchiffrer le contenu protégé par DKE, depuis quelle IP / pays / heure / groupe |
Les pages existantes RBAC et Contrôle d'accès Zero Trust décrivent le contrôle d'accès sur Cockpit v1. Sur Cockpit v2, la même intention est mise en œuvre par le moteur de politiques décrit ci-dessous, lié à un service DKE via son access_policy_id.
RBAC — permissions d'administration
Les actions administratives (déployer, activer et faire pivoter les services DKE, gérer les politiques d'accès) sont régies par le contrôle d'accès basé sur les rôles. Les rôles sont attribués aux utilisateurs et peuvent être limités à une unité organisationnelle (OU) ; les administrateurs passent tous les contrôles.
ABAC — politiques d'accès liées à un service DKE
Une politique d'accès est un enregistrement limité au tenant, évalué à chaque déchiffrement DKE. Liez-la à un service en définissant le access_policy_id du service (voir Configuration DKE).
La couche de contrôle d'accès de Cockpit v2 est un véritable moteur de politiques, et non une simple liste d'autorisation statique. Une seule politique compose cinq dimensions indépendantes (utilisateur, IP, localisation, heure, groupe), chacune avec une sémantique liste blanche / liste noire / obligatoire, sous l'une des trois actions de politique (Allow / Block / Bypass) avec une préséance déterministe. Elle est fail-closed, limitée au tenant, optionnellement limitée à une OU, pilotée par une matrice de capacités par type d'app, et chaque décision est écrite dans une piste d'audit forensique — le tout appliqué côté serveur sur le chemin de déchiffrement, de sorte que la protection de l'étiquette voyage avec la donnée plutôt qu'avec le client.
Forme de la politique
Une politique possède un nom et une description, une action globale (Allow, Block, ou Bypass), un périmètre optionnel d'unité organisationnelle (sinon à l'échelle du tenant), un indicateur d'activation, et des blocs de règles pour chacune des cinq dimensions d'accès ci-dessous.
Les cinq dimensions d'accès
Chaque entrée de dimension porte un mode de correspondance (liste blanche, liste noire, ou obligatoire) et, le cas échéant, un opérateur de correspondance. DKE 365 prend en charge les cinq dimensions.
| Dimension | Correspond à |
|---|---|
| Utilisateur | UPN / nom d'affichage / email (compatible regex) |
| IP | Adresse exacte, plage CIDR, ou plage de début-fin (IPv4/IPv6) |
| Localisation | Codes pays ISO-3166 |
| Heure | Jour de la semaine + plage minute-de-la-journée |
| Groupe | Appartenance à un groupe du fournisseur d'identité |
Comment fonctionne l'application (au déchiffrement)
Aucune politique signifie aucune restriction
Si aucune politique n'est rattachée (ou si elle est désactivée), le déchiffrement est autorisé (l'absence de politique signifie l'absence de restriction).
Construire le contexte d'accès
Cockpit v2 construit un contexte d'accès à partir de l'appelant : utilisateur, IP, pays, heure actuelle et appartenance aux groupes. Le JWT Azure AD fait autorité ; les en-têtes transmis / CDN (IP client, pays) ne sont utilisés qu'en repli et pour recoupement, et uniquement lorsqu'ils proviennent d'adresses source figurant dans la liste CIDR de proxies de confiance configurée.
Évaluer chaque dimension
Chaque dimension est évaluée par le moteur de politiques.
Appliquer la préséance des décisions
Préséance des décisions : Bypass > Block > Allow > refus par défaut.
Échouer en mode fermé
Une politique activée sans aucune règle refuse. Si un enregistrement d'audit de sécurité ne peut pas être écrit pour un allow en production, le déchiffrement est refusé.
Enregistrer la décision
Chaque décision est écrite dans un journal forensique d'audit de politique d'accès, exposé dans les journaux d'activité.
Les politiques sont créées et gérées depuis le Cockpit, et chaque décision d'application est disponible sous forme de piste d'audit exposée dans les journaux d'activité.
Exemple : une politique de déchiffrement DKE
Une politique de déchiffrement DKE typique n'autorise le déchiffrement que pour les membres d'un groupe spécifique du fournisseur d'identité (par exemple, l'audience de l'étiquette), depuis vos pays d'entreprise, pendant les heures ouvrables — tout en bloquant purement et simplement tout pays sanctionné. Vous combinez une règle groupe avec des règles localisation et heure, vous liez la politique au service DKE (access_policy_id), et chaque déchiffrement est ensuite évalué par rapport à elle, chaque décision étant enregistrée dans la piste d'audit.
Les politiques d'accès sont la manière dont DKE 365 met en œuvre le déchiffrement zero-trust sur Cockpit v2 : l'authentification est le jeton Azure AD, et l'autorisation — qui / où / quand / quel groupe — est la politique d'accès. Combinez une règle groupe (uniquement l'audience de l'étiquette) avec des règles localisation et heure pour une posture stricte.