Politiques d'accès (RBAC + ABAC)
Les deux couches de contrôle d'accès de Cockpit v2 — l'administration basée sur les rôles et les politiques d'accès ABAC protégeant les clés, les apps Oracle TDE et les services DKE.
Cockpit v2 possède deux couches de contrôle d'accès distinctes. Il est important 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 (par ex. déployer une app Oracle TDE, faire pivoter une clé DKE) |
| Politiques d\'accès ABAC | Qui, depuis où, et quand peut effectuer une opération cryptographique à l\'exécution | Liées aux clés, aux apps (dont Oracle TDE) et aux services DKE ; évaluées au moment du déchiffrement / de l'accès à la clé |
Une courte vidéo de 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 (gérer les clés, les apps, les services DKE et 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 ; chaque rôle accorde un ensemble de permissions et peut être limité à une unité organisationnelle (OU). Les administrateurs passent tous les contrôles.
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 ou une opération sur la clé maître Oracle TDE). Elle reflète le modèle de politiques d'accès du Cockpit historique, réimplémenté sur un moteur de politiques.
Forme de la politique
Une politique possède un nom et une description, une action globale (Allow, Block, ou Bypass), un type d'app cible (par exemple DKE 365, Oracle TDE, ou une app universelle), 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 dimension est une liste d'entrées ; chaque entrée porte un mode de correspondance (liste blanche, liste noire, ou obligatoire) et, le cas échéant, un opérateur de correspondance.
| 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. Cockpit v2 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. DKE 365 prend en charge les cinq ; plusieurs types d'app universels ne prennent en charge que IP / localisation / heure.
Lier une politique
| Cible | Comment elle se lie |
|---|---|
| Service DKE | access_policy_id sur le service — appliquée à chaque déchiffrement |
| Apps génériques (dont Oracle TDE) | access_policy_id sur l'app — appliquée aux opérations cryptographiques de l'app |
| AWS XKS | Un access_policy_id par point de terminaison, appliqué 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. 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 l'absence de restriction).
Construire le contexte d'accès
Le Cockpit construit un contexte d'accès à partir de l'identité et du transport de l'appelant : 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 ne sont fiables que 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 (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é.
Gérer les politiques
Les politiques sont créées et gérées depuis le Cockpit, qui expose également la matrice de capacités par type d'app, les groupes disponibles pour les règles de groupe, et la piste d'audit d'application.
Exemples de règles
Les politiques d'accès combinent les cinq dimensions avec une sémantique simple de liste blanche / liste noire / obligatoire. Les règles typiques incluent : bloquer tout pays sanctionné tout en autorisant vos pays d'entreprise (localisation) ; n'autoriser que des utilisateurs nommés ou exclure un motif (utilisateur) ; restreindre à une plage IP et aux heures ouvrables (IP + heure) ; ou exiger l'appartenance à un groupe spécifique du fournisseur d'identité.
Appliquer une politique d'accès à une app Oracle TDE
Créer la politique
Créez une politique d'accès ciblant le type d'app Oracle TDE, avec les règles souhaitées — par exemple, autoriser les opérations sur la clé maître uniquement depuis le sous-réseau de la base de données (dimension IP) pendant les heures ouvrables (dimension heure).
La lier à l'app
Liez-la à l'app Oracle TDE en définissant le access_policy_id de l'app.
Appliquer et auditer
Chaque opération de gestion de la clé maître sur cette app est ensuite é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 Oracle TDE typique combine une règle IP (uniquement les hôtes / sous-réseau de la base de données) avec une règle heure (fenêtres de maintenance pour la rotation des clés), laissant le jeton porteur access_guid pour l'authentification et la politique pour l'autorisation.