Politiques d'accès (RBAC + ABAC)
Les deux couches de contrôle d'accès du DuoKey Cockpit — l'administration basée sur les rôles et les politiques d'accès basées sur les attributs (ABAC) qui régissent chaque opération cryptographique à l'exécution.
Le Cockpit possède deux couches de contrôle d'accès distinctes. Elles répondent à des questions différentes et sont appliquées à des points différents, il est donc essentiel de les garder séparées :
| Couche | Régit | Où elle s'applique |
|---|---|---|
| RBAC (rôles & permissions) | Qui peut administrer le Cockpit | L'API de gestion — déployer une app, faire tourner une clé, modifier une politique |
| Politiques d\'accès ABAC | Qui, depuis où, et quand peut effectuer une opération cryptographique à l\'exécution | Liées aux services DKE, aux apps et aux points de terminaison XKS ; évaluées au moment du déchiffrement / de l'accès à la clé |
Une courte démonstration de la création d'une politique d'accès et de son application sera ajoutée ici.
RBAC — permissions d'administration
Les actions administratives sont protégées par des permissions basées sur les rôles, granulaires et hiérarchiques, qui régissent qui peut effectuer chaque action. Un utilisateur se voit accorder une action s'il détient la permission correspondante ou tout parent qui l'implique ; les administrateurs passent tous les contrôles.
Permissions
Des permissions granulaires qui s'imbriquent hiérarchiquement — une permission parente accorde implicitement tout ce qui se trouve en dessous.
Rôles
Chaque rôle regroupe un ensemble de permissions et est attribué aux utilisateurs. Les rôles peuvent être limités à une unité organisationnelle (OU) de sorte qu'un octroi ne s'applique qu'au sein de cette branche.
Périmètre OU
Une attribution de rôle limitée à une OU confine les permissions aux ressources de cette unité organisationnelle, ce qui permet une administration déléguée.
Les rôles, leurs ensembles de permissions et leur périmétrage par unité organisationnelle sont créés et gérés depuis la console d'administration du Cockpit.
ABAC — politiques d'accès
Une politique d'accès est un enregistrement limité au tenant, évalué chaque fois qu'une clé protégée est utilisée — par exemple un déchiffrement DKE, une opération cryptographique générique d'app, ou un déchiffrement AWS XKS. Les politiques sont appliquées par le moteur de politiques de la plateforme et constituent la couche d'autorisation qui se superpose à tout jeton porteur ayant authentifié l'appelant.
Forme de la politique
| Attribut | Signification |
|---|---|
| Nom | Nom lisible de la politique |
| Description | Description en texte libre |
| Action | Action globale de la politique — Allow, Block, ou Bypass |
| Type d'app | Type d'app cible — par ex. DKE365, Oracle TDE, AWS XKS |
| Périmètre OU | Périmètre optionnel d'unité organisationnelle (non défini = à l'échelle du tenant) |
| Activée | Si la politique est active |
| Règles + groupes | Quatre blocs de règles typés — utilisateur, appareil (IP), localisation et heure — plus les groupes du fournisseur d'identité |
Les cinq dimensions d'accès
Chaque dimension est une liste d'entrées. Chaque entrée porte un mode de correspondance (Include = liste blanche, Exclude = liste noire, Require) et, le cas échéant, un opérateur de correspondance (any-of, contains).
| 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é |
Tous les types d'app ne prennent pas en charge toutes les dimensions. Le Cockpit expose une matrice de capacités qui déclare lesquelles des cinq catégories chaque type d'app peut honorer, et l'interface grise les onglets de règles qui ne s'appliquent pas. DKE365 prend en charge les cinq dimensions ; plusieurs types d'app universels ne prennent en charge que IP / localisation / heure.
Lier une politique
Une politique n'a aucun effet tant qu'elle n'est pas liée à une ressource. La liaison rattache la politique à la cible :
| Cible | Comment elle se lie |
|---|---|
| Service DKE | Rattachée au service — appliquée à chaque déchiffrement |
| Apps génériques (dont Oracle TDE) | Rattachée à l'app — appliquée aux opérations cryptographiques de l'app |
| Point de terminaison AWS XKS | Rattachée par point de terminaison — appliquée dans le chemin de déchiffrement XKS |
Comment fonctionne l'application
Rechercher la politique liée
Lorsqu'une opération protégée s'exécute, le Cockpit recherche la politique liée à la ressource. Si aucune n'est rattachée, ou si la politique est désactivée, l'opération est autorisée — l'absence de politique signifie que la ressource n'est pas restreinte.
Construire le contexte d'accès
Le Cockpit construit un contexte d'accès à partir de l'identité de l'appelant et du transport : utilisateur (depuis le JWT), IP, pays, heure actuelle, et appartenance aux groupes. Le JWT 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 prise en charge est évaluée par le moteur de politiques par rapport au contexte.
Appliquer la préséance des décisions
Les décisions sont résolues par préséance : Bypass > Block > Allow > refus par défaut.
Échouer en mode fermé
Une politique activée sans aucune règle refuse — elle n'autorise pas silencieusement. Si un enregistrement d'audit de sécurité ne peut pas être écrit pour une décision allow en production, l'opération est refusée.
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é.
Le comportement par défaut est le refus. Rattacher une politique activée mais vide bloque tout accès à la ressource jusqu'à ce qu'au moins une règle Include/Allow corresponde à l'appelant. Vérifiez une politique de bout en bout avant de la lier à une ressource de production.
API des politiques d'accès
Les politiques d'accès sont créées, listées, mises à jour, liées à des ressources et auditées via la console du Cockpit et son API de gestion. La même interface expose la matrice de capacités par type d'app et les groupes disponibles pour les règles de groupe.
Exemples de règles
Les cinq dimensions se combinent pour exprimer des règles telles que :
- Bloquer un pays — refuser les opérations provenant d'un pays ISO-3166 donné.
- Autoriser uniquement des utilisateurs spécifiques — permettre des utilisateurs nommés (par email ou UPN) et en exclure d'autres.
- Restreindre par IP et heure — n'autoriser qu'un sous-réseau connu, et uniquement pendant une fenêtre quotidienne définie (par exemple du lundi 08h00 à 18h00).
- Restreindre par groupe du fournisseur d'identité — exiger l'appartenance à un groupe IdP spécifique.
Mettre tout cela en pratique
Créer la politique
Créez la politique pour le bon type d'app avec les règles souhaitées — par exemple, autoriser les opérations uniquement depuis un sous-réseau connu (dimension IP) pendant les heures ouvrables (dimension heure).
La lier à une ressource
Rattachez-la à la cible — un service DKE, une app générique, ou un point de terminaison AWS XKS.
Appliquer et auditer
Chaque opération cryptographique sur cette ressource est évaluée par rapport à la politique, et chaque décision est enregistrée dans la piste d'audit des politiques d'accès.
Une politique durcie typique combine une règle IP (uniquement les hôtes clients / sous-réseau attendus) avec une règle heure (la fenêtre d'exploitation ou de maintenance autorisée), laissant le jeton porteur pour l'authentification et la politique pour l'autorisation. Ajoutez une règle utilisateur ou groupe par-dessus lorsque l'identité de l'appelant est connue.