Obexal Docs

Docs/Contrôle d'accès/Simulation et versions

Versions et simulation de politique

Chaque changement de politique d'accès devient une version immuable restaurable, et toute politique candidate peut être simulée sur 30 jours de trafic de connexion réel avant application.

Modifier une politique d'accès conditionnel est l'une des opérations d'administration les plus risquées : une mauvaise règle peut enfermer dehors toute une organisation. Obexal supprime deux fois l'incertitude : chaque changement est archivé comme version immuable restaurable, et toute politique candidate peut être simulée sur votre trafic de connexion réel avant de l'appliquer.

Chaque changement est une version

Chaque application réussie de la politique d'accès (un PUT ou une restauration) ajoute une version à un historique en append-only. Une version enregistre l'instantané complet des règles et de l'action par défaut, un numéro de version, une note décrivant le changement, l'e-mail de l'auteur et un horodatage RFC 3339. L'historique n'est jamais réécrit : restaurer une ancienne version en crée une nouvelle par-dessus, avec une note comme « Restauration de la version 3 ». L'archivage est best-effort par conception : un incident de stockage sur l'historique ne bloque jamais l'application de la politique elle-même.

Consulter l'historique et restaurer

curl -sS https://accounts.obexal.com/v1/admin/access-policy/versions \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"
{
  "versions": [
    {
      "id": "9f0e6c2a", "version": 4,
      "rules": [{"name": "Bureau", "networks": ["203.0.113.0/24"], "action": "allow", "enabled": true}],
      "defaultAction": "deny",
      "note": "Modification",
      "author": "admin@example.com",
      "createdAt": "2026-06-28T09:14:03Z"
    }
  ]
}

La liste renvoie les 50 versions les plus récentes, de la plus récente à la plus ancienne. Pour revenir en arrière :

curl -sS -X POST \
  https://accounts.obexal.com/v1/admin/access-policy/versions/9f0e6c2a/restore \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"
# 204 No Content : l'instantané est ré-appliqué comme NOUVELLE version

Une restauration passe par la même validation et le même garde-fou anti-verrouillage que tout changement : une version qui refuserait aujourd'hui votre connexion courante, ou exigerait une MFA que vous n'avez pas enrôlée, est rejetée. Les deux endpoints exigent la permission tenant:manage ; un domaine personnalisé remplace accounts.obexal.com.

Simuler avant d'appliquer

POST /v1/admin/access-policy/simulate prend exactement le même corps que le PUT et n'applique rien. Il évalue la politique courante et la candidate contre les IP de connexion réelles de votre tenant sur les 30 derniers jours (jusqu'à 1000 IP distinctes, chacune pondérée par le nombre de connexions qu'elle a produites), en résolvant les pays avec la même base GeoIP locale qu'à la connexion. La réponse est contrefactuelle : ce qui aurait changé pour le trafic que vous avez réellement eu.

Exemple

curl -sS -X POST https://accounts.obexal.com/v1/admin/access-policy/simulate \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "rules": [
      {"name": "Bureau", "networks": ["203.0.113.0/24"], "action": "allow", "enabled": true}
    ],
    "defaultAction": "require_mfa"
  }'
{
  "windowDays": 30,
  "distinctIps": 42,
  "sampled": 1287,
  "unparseable": 0,
  "current": {"allow": 1287},
  "candidate": {"allow": 1121, "require_mfa": 166},
  "changes": [
    {
      "from": "allow", "to": "require_mfa",
      "count": 166, "distinctIps": 9,
      "sampleIps": ["198.51.100.23", "192.0.2.41"]
    }
  ]
}

Lire les résultats

  • current et candidate donnent la répartition des actions, pondérée par les occurrences de connexion : ici 166 des 1287 connexions récentes basculeraient vers un step-up MFA.
  • changes est la matrice des bascules de/vers, triée par impact : chaque entrée porte le compte pondéré, le nombre d'IP distinctes affectées et jusqu'à 5 IP d'exemple à investiguer.
  • Un tableau changes vide signifie que la politique candidate ne change rien pour votre trafic réel.

Le flux de travail à adopter : simuler, vérifier que personne ne tombe en deny par surprise, appliquer, et garder l'historique de versions comme chemin de retour arrière.

Limites

  • L'échantillon est constitué des IP de connexion enregistrées sur les 30 derniers jours, plafonné à 1000 IP distinctes ; un tenant tout neuf sans historique obtient des répartitions vides.
  • Les règles à fenêtre horaire sont évaluées à l'instant de la simulation, pas à l'horodatage d'origine de chaque connexion : une règle « heures ouvrées » montre son effet pour « maintenant ».
  • Les IP non analysables sont comptées dans unparseable et exclues des répartitions.
  • La simulation couvre la politique d'accès à règles, pas le score de risque, qui dépend de l'historique de chaque utilisateur au moment de la connexion.