Le contrôle HITL garantit qu’aucune action d’agent à haut risque ne procède sans jugement humain. Ce cookbook parcourt le cycle de vie complet de l’approbation — du moment où une action gouvernée déclenche une requête jusqu’à la résolution du niveau de risque, les décisions humaines, et la soupape de secours break-glass — pour que vous puissiez tracer chaque élément avant de le rencontrer en production.
Si vous n’avez pas encore lu le modèle d’autorisation, commencez par Gouvernance. Le guide Gouverner et approuver couvre la même mécanique du point de vue opérateur ; cette page est la référence étape par étape.
Le cycle de vie de la requête
Une requête d’approbation s’ouvre fermée par défaut et limitée dans le temps. Elle démarre pending, porte une expiration, et n’autorise rien tant que suffisamment d’humains n’ont pas décidé. La requête ne peut pas abaisser sa propre barre — une politique d’approbation correspondante fait autorité pour le seuil et les délais.
La requête est liée à un hash de plan de la charge utile exacte de l’appel d’outil. C’est la défense anti-TOCTOU : si l’action sous-jacente change entre la requête et la décision, le hash ne correspondra pas et l’approbation ne pourra pas se lier. Une approbation périmée n’autorise jamais une action différente.
Résolution du niveau de risque
Quatre niveaux déterminent combien de contrôle humain une action gouvernée requiert :
| Niveau | Ce que cela signifie |
|---|---|
low / medium | Assigné uniquement par politique d’approbation explicite — rien ne se retrouve ici par défaut |
high | Le défaut pour tout ce qui atteint la file d’approbation. Une approbation humaine requise |
critical | Plancher obligatoire à deux personnes (autorisation duale NIST SP 800-53 AC-3(2)) |
Le niveau est re-dérivé de l’ensemble des politiques en vigueur à chaque décision, jamais lu depuis un instantané stocké. Un changement de politique prend effet immédiatement. Une ligne périmée ne peut jamais maintenir la barre plus bas que la classification actuelle — c’est fermé par défaut par construction.
L’ensemble critical intégré couvre les actions véritablement irréversibles : déploiement et retrait en production, suppression et effacement de données, changements d’application de sécurité et du coupe-circuit, garde et rotation de clés, et décommissionnement de NHI.
Une politique d’approbation avec un risk_tier explicite peut augmenter ou diminuer le défaut par action. Mais elle ne peut jamais abaisser une action critical en dessous du plancher de double contrôle.
Étape par étape
1. Une action gouvernée déclenche une requête
Une action gouvernée — deploy apply, agent fire, dérogation budgétaire, ou toute action correspondant à une politique d’approbation — atteint le moteur d’approbation. Le moteur ouvre une nouvelle requête en état pending.
2. La requête se lie à un hash de plan
La requête enregistre un hash de la charge utile exacte de l’appel d’outil. Cette liaison au hash de plan est la défense TOCTOU : la décision n’autorisera que l’action pour laquelle la requête a été créée.
3. Le niveau de risque se résout depuis la politique actuelle
Le moteur évalue l’ensemble des politiques en vigueur (RBAC, ABAC natif, et tout PDP externe) pour dériver le niveau de risque. Le niveau n’est jamais mis en cache depuis une évaluation antérieure.
4. Un réviseur humain décide
Un humain avec un rôle suffisant émet un approve ou un deny. Le serveur applique trois invariants à ce stade, indexés sur l’identité stable de l’utilisateur :
- Séparation des fonctions. Le demandeur ne peut pas décider sa propre requête. Cela s’indexe sur l’identité stable de l’utilisateur, pas sur la chaîne d’identifiant qu’une même personne pourrait varier.
- Garde anti-doublon de décideur. Un index unique backstoppe une course de décideur dupliqué — un humain ne compte qu’une fois vers le seuil.
- Expiration contraignante. Une requête expirée ne peut jamais recevoir de décision contraignante, même avant qu’un balayage ne matérialise l’expiration. Le statut effectif est re-dérivé à chaque décision.
5. Actions critiques : double contrôle avec AAL3
Pour le niveau critical : le seuil est planché à deux approbateurs humains distincts. Le plancher est appliqué à la création (le seuil stocké ne peut jamais démarrer en dessous de deux) et re-appliqué à la décision (une requête créée avant que l’action ne devienne critique ne peut toujours pas passer avec un seul humain).
Chaque humain décideur doit avoir une session vérifiée par matériel — step-up WebAuthn ou PIV (AAL3). Un token système ne porte aucune assurance humaine et est refusé.
6. La décision est enregistrée dans le registre
Chaque décision ajoute une ligne immuable au parcours de décision de la requête et un événement de registre enregistrant la décision, le statut résultant, et le niveau de risque sous lequel elle a été prise. Le registre est append-only, chaîné par hash, et signé Ed25519 — réécrire l’historique est cryptographiquement détectable.
Expiration
L’expiration est dérivée à la lecture, pas écrite une seule fois. Une requête expirée ne peut jamais recevoir de décision contraignante même si aucun balayage en arrière-plan n’a encore matérialisé l’expiration. Le statut effectif est toujours re-dérivé, donc un balayage lent est un délai cosmétique, pas une faille de sécurité.
Configuration de politique
Les politiques d’approbation vous permettent de surcharger le niveau de risque par défaut par classe d’action. Une politique avec un risk_tier explicite peut déplacer une action de high à low, ou élever un medium à critical. La seule contrainte : vous ne pouvez jamais abaisser critical en dessous du plancher de double contrôle. L’exigence des deux personnes pour les actions irréversibles est structurelle, pas configurable.
Break-glass
Quand un quorum est injoignable — l’incident de 3 heures du matin où le second approbateur dort — le break-glass fournit une soupape de secours auditée. Il est bruyant par construction.
L’activation requiert tout ce qui suit :
- L’activateur est un admin, toujours un vrai humain — un token système est refusé.
- Un step-up AAL3 frais (WebAuthn ou PIV).
- Une justification écrite enregistrée dans la même transaction.
- Une session activement enregistrée comme précondition.
Limitation temporelle : l’autorisation est d’une heure par défaut, plafonnée à 24. Une urgence qui nécessite plus longtemps est un mode opératoire, pas une urgence, et doit passer par le double contrôle normal.
Chaque utilisation est enregistrée. Chaque action prise sous break-glass ajoute une ligne immuable et un événement de registre nommant l’autorisation, l’action, et le sujet. Une action qui a procédé sous break-glass est définitivement distinguable d’une action correctement approuvée.
Revue post-mortem obligatoire. Une nouvelle autorisation ne peut pas être activée tant qu’une autorisation précédente est non révisée. La revue doit provenir d’un humain différent de l’activateur. Vous ne pouvez pas empiler les urgences pour esquiver l’examen.
Le break-glass assouplit un quorum manquant ; il ne surpasse jamais un rejet explicite. Une requête que quelqu’un a délibérément refusée reste refusée.
Ce qui est enregistré
Chaque décision — approbation, refus, expiration, ou utilisation du break-glass — est ajoutée à deux endroits :
- Le parcours de décision de la requête : une séquence immuable de lignes de décision sur la requête elle-même, chacune portant le décideur, le verdict, et l’horodatage.
- Le registre d’audit : un événement chaîné par hash, signé Ed25519, enregistrant la décision, le statut résultant de la requête, et le niveau de risque sous lequel elle a été prise.
Les deux écritures se produisent dans la même transaction que le changement d’état. Vous ne pouvez pas prendre une décision gouvernée que le registre oublierait silencieusement.
Voir aussi
- Gouverner et approuver — le guide opérateur couvrant la même mécanique.
- Gouvernance — le modèle d’autorisation, la posture d’auto-audit, et la mécanique du coupe-circuit.
- Cookbook : exercice coupe-circuit — l’exercice du contrôle de refus à l’échelle de l’environnement.
- Coupe-circuit — la page produit de l’arrêt d’urgence.