Aller au contenu

Recette : trier la dérive de moindre privilège

Objectif : transformer le résultat de dérive — l’écart entre ce que les agents peuvent faire et ce qu’on observe qu’ils font — en décisions, à un rythme régulier, jusqu’à ce que le diff soit silencieux.

Fenêtre de terminal
curl -ks "$BASE/v1/m/accessmap/drift" \
-H "Authorization: Bearer $TOKEN" -H "X-Olivares-Tenant: $TENANT" | python3 -m json.tool

(Ou en HCL, pour revue dans une PR : la source de données Terraform olivares_access_edges avec include_drift = truegérer comme du code.)

Le résultat comporte trois classes, et ce sont des problèmes différents :

ClasseSignificationLa question à poser
Accès inattenduobservé, mais aucune habilitation ne le couvreest-ce une habilitation manquante, ou une vraie violation ?
Habilitation inutiliséeaccordée, jamais observée en usagepourquoi cette permission existe-t-elle ?
Réconciliation en attenteobservé, mais le lien agent↔identité n’est pas résoluun problème d’identité, pas (encore) de sécurité

Accès inattendu — lisez les axes d’honnêteté de l’arête avant d’agir :

  • attribution_tier: firm + coverage_tier: clean est le constat de la plus haute qualité que vous obtiendrez : une identité spécifique a touché une ressource spécifique et l’audit propre du store l’a classé. Décidez : si légitime, déclarez l’habilitation (politique ou liaison) pour que la carte reflète l’intention ; sinon, révoquez l’accès sous-jacent et traitez-le comme un incident.
  • Une attribution approximate signifie que l’accès a eu lieu mais que le qui est une credential partagée. Ne gaspillez pas une enquête sur « quel agent était-ce » — le correctif durable est l’identité par agent, et d’ici là l’arête dit honnêtement ce qu’elle ne peut pas prouver.
  • Une arête reposant uniquement sur un indice mcp_annotation n’est pas une preuve — l’indice n’est pas digne de confiance par spécification. Corroborez avec une source observée avant de décider quoi que ce soit.

Les habilitations inutilisées sont du sur-provisionnement trouvé gratuitement : chacune est une candidate à la révocation, avec la réserve que l’absence d’observation n’a de sens que là où la couverture existe — vérifiez le palier de couverture de la ressource avant de vous réjouir (couverture par paliers).

La réconciliation en attente est routée vers le backlog d’identité : câblez ou corrigez la source de roster qui devrait lier cette credential, et l’arête se résout à la passe suivante.

Prenez la décision là où elle est gouvernée : déclarez les habilitations comme du code (Terraform) ou via l’API gouvernée, mettez la direction risquée derrière une approbation, et laissez le ledger enregistrer qui a décidé quoi. Puis re-récupérez la dérive : les arêtes réconciliées sortent du diff — seules les vraies lacunes subsistent. Cette convergence est tout l’enjeu ; l’estate de démonstration la montre en miniature (quickstart).

Dans la console, le panneau Permitted vs observed de la carte d’accès est cette recette rendue en direct.

Le tri de dérive fonctionne comme une courte boucle hebdomadaire plus un canal d’alerte pour la classe à fort signal (écritures inattendues firm + clean). Routez ces constats vers votre astreinte via une destination de notification plutôt que d’attendre la passe hebdomadaire.