Simulateur de politiques

L'écran Simulateur de politiques permet de comparer les décisions d'une politique candidate avec celles des politiques actives, sur des entrées que vous rédigez et sur des décisions enregistrées par la plateforme, sans rien modifier, et de lire les révisions d'une politique avec la différence entre deux d'entre elles. Chemin dans le portail : /security/policy-simulator, menu Sécurité et gouvernance > Simulateur de politiques. Il sert aux responsables sécurité, aux administrateurs de tenant et aux développeurs avant de publier un changement de politique, et aux auditeurs qui lisent l'historique.

Ce que montre l'écran

L'écran (PolicySimulator dans portal/src/screens/security-kit.tsx) comporte deux sections.

• Simuler une politique candidate (« Rien n'est modifié : les décisions sont comparées sur les entrées et les décisions enregistrées. ») : un formulaire avec Candidat (JSON, prérempli avec une politique builtin qui refuse model.invoke), Politique (identifiant de la politique que le candidat remplace ; vide : le candidat est ajouté), Entrées (liste JSON de requêtes Policy Contract, par défaut []) et Décisions enregistrées (nombre des dernières décisions enregistrées à rejouer, par défaut 50). Le résultat montre quatre badges, Total, Modifiées, Autorisé vers refusé, Refusé vers autorisé (en orange au-dessus de zéro), et un tableau avec L'actuel autorise, Le candidat autorise, Modifié et Entrée, une ligne par entrée comparée. Sans ligne : « Aucune entrée comparée ».
• Révisions (« Chaque création, modification et suppression ajoute une révision immuable. ») : un sélecteur Politique avec Appliquer, puis un tableau des révisions, colonnes Révision, Modification, Nom, Version, Statut, et à côté « Différence de la révision {from} à {to} (cliquez deux lignes) » avec le JSON de la différence. Sans révision : « Aucune révision ».

Exemple de Candidat et d'Entrées :

{
  "candidate": {"name": "candidate", "engine": "builtin", "priority": 100,
                "rules": [{"effect": "deny", "actions": ["model.invoke"], "resource_types": ["model"]}]},
  "inputs": [{"action": "model.invoke", "resource": {"type": "model", "id": "claude-sonnet-eu"}}]
}

Actions

Bouton ou action	Effet	Appel API	Rôles
Exécuter (Simuler une politique candidate)	Évalue chaque entrée et chaque décision enregistrée avec les politiques actives, puis avec le candidat en place, et renvoie les différences ; audité sous policy.simulate. Rien n'est enregistré.	POST /v1/policies/simulate	tenant_admin, security_officer, developer (formulaire masqué pour les autres)
Appliquer (Révisions, sélecteur Politique)	Charge les révisions de la politique et la différence de son dernier changement.	GET /v1/policies/{policy_id}/revisions, GET /v1/policies/{policy_id}/revisions/diff	tenant_admin, security_officer, auditor, developer
Clic sur une première ligne, puis une seconde	Fixe la borne from puis to et lit la différence entre ces deux révisions ; un troisième clic démarre une nouvelle plage.	GET /v1/policies/{policy_id}/revisions/diff (paramètres from_revision, to_revision)	Les mêmes
Réessayer (état d'erreur)	Relit les révisions.	GET /v1/policies/{policy_id}/revisions	Les mêmes

Rôles

Le portail affiche le formulaire de simulation à ROLES.policySimulators (tenant_admin, security_officer, developer, portal/src/lib/kit.ts) ; les autres utilisateurs voient « Nécessite l'un de ces rôles ». Le Control Plane (services/control-plane/src/eai/domains/policies/__init__.py) exige les mêmes rôles pour la simulation, et tenant_admin, security_officer, auditor ou developer pour les révisions et leur différence. platform_admin passe tous les contrôles de rôle ; son rôle est retiré des sujets simulés.

Tâches courantes

Mesurer l'effet d'une nouvelle règle avant de la publier

1. Rédiger le candidat. Le candidat est une politique complète, au même format que sur l'écran Politiques ; seul le moteur builtin peut être simulé. Modifiez Candidat. Résultat attendu : un JSON valide dans le champ. En cas d'échec : « JSON invalide » sous le champ.
2. Choisir ce qui est comparé. Les décisions enregistrées montrent le trafic réel, les entrées montrent les cas qui vous intéressent. Gardez Décisions enregistrées 50 et ajoutez vos Entrées. Résultat attendu : au moins une source de cas. En cas d'échec : validation_error (HTTP 422) « inputs or recorded is required » quand les deux sont vides ou nuls.
3. Exécuter. Cliquez Exécuter. Résultat attendu : les quatre badges et une ligne par cas ; Autorisé vers refusé compte ce que le candidat bloquerait. En cas d'échec : simulation_engine_unsupported (HTTP 422) pour un candidat opa ; forbidden pour un rôle manquant.
4. Décider. Aucun changement n'a été fait. Si les différences sont celles attendues, créez ou modifiez la politique sur l'écran Politiques. Résultat attendu : les décisions de la plateforme suivent la nouvelle règle.

Comparer deux révisions d'une politique

1. Charger l'historique. Saisissez l'identifiant (UUID) de la politique dans Politique et cliquez Appliquer. Résultat attendu : les révisions avec leur Modification (create, update, delete). En cas d'échec : not_found signale une politique inconnue ou un identifiant qui n'est pas un UUID.
2. Choisir la plage. Cliquez la révision la plus ancienne, puis la plus récente. Résultat attendu : « Différence de la révision X à Y » et le JSON de la différence. En cas d'échec : not_found avec policy_revision signale une plage inexistante.

Dépannage

Symptôme	Cause	Correction
validation_error (HTTP 422) « inputs or recorded is required »	Aucune entrée et Décisions enregistrées à 0.	Ajoutez des entrées ou rejouez des décisions enregistrées.
validation_error (HTTP 422) sur Candidat	Le candidat ne suit pas le format d'une politique (nom, moteur, règles), ou plus de 200 entrées, ou Décisions enregistrées au-dessus de 500.	Corrigez le JSON ou les nombres.
simulation_engine_unsupported (HTTP 422)	Seules les politiques candidates à règles intégrées peuvent être simulées.	Simulez un candidat builtin.
not_found avec policy	Politique est inconnue ou n'est pas un UUID.	Copiez l'identifiant depuis l'écran Politiques.
forbidden (HTTP 403)	La simulation exige tenant_admin, security_officer ou developer ; les révisions acceptent aussi auditor.	Demandez l'un de ces rôles.
« Aucune entrée comparée »	La simulation n'a renvoyé aucun cas.	Ajoutez des entrées, ou vérifiez que des décisions ont été enregistrées.

Pages liées

• Politiques
• Journal des décisions
• Politiques du studio
• Guide de développement des politiques
• Brique moteur de politiques