La décision d'accès moderne ne se résume plus à la seule question « le nom d'utilisateur est-il correct ? ». La bonne décision doit considérer ensemble l'identité de l'utilisateur, l'état de confiance de l'appareil, la localisation, le temps, la sensibilité du service accédé, le niveau de MFA demandé et les changements de risque au sein de la session.
Les règles statiques et les listes d'autorisation simples ne peuvent pas porter cette complexité. Avec le temps, chaque exception devient une nouvelle règle, chaque application un nouveau cas particulier, chaque signal de risque un point de contrôle distinct. Le résultat est un amas de politiques que personne ne peut lire de bout en bout, dont on ne peut pas expliquer clairement à l'audit pourquoi il a autorisé ou refusé.
Certaines solutions transfèrent cette décision vers un cloud de politique distinct. Cela rend aussi l'instant le plus critique de l'authentification dépendant d'une API externe. Lorsque l'identité, la MFA, le routage de service et l'audit se dispersent dans différents systèmes, le chemin d'accès devient invisible ; l'organisation ne voit que le résultat, pas comment la décision s'est formée.
Pourtant, l'accès conditionnel devrait être un seul moteur de décision fonctionnant aux côtés de vos identités et de vos services. Chaque étape doit être visible, chaque condition explicable, chaque décision auditable.
Car la sécurité d'accès ne concerne pas seulement qui est entré, mais dans quel contexte, avec quelle force de vérification et pour quelle raison l'autorisation a été accordée.
Un moteur de flux qui s'approprie l'authentification, la MFA, les décisions et le routage dans une seule définition par service.
Un flux d'accès chaîne la connexion, la MFA, les points de décision, les switch, la gestion du verrouillage et les terminaux access-granted/denied. Chaque service déclare son propre flux ; une application intranet à faible risque reste simple, un chemin d'administrateur privilégié reste strict — sans contraindre les deux à la même forme.
Les nœuds switch routent sur n'importe quelle variable que le flux peut voir — propriétés de session, en-têtes de requête, gabarits évalués, signaux upstream venant de votre périphérie — avec cinq modes de correspondance (exact, prefix, suffix, contains, regex) et une option case-insensitive optionnelle. Les décisions sont exprimées comme une correspondance de motif, pas comme un script.
Localisation géographique, réputation IP, score de risque, zone réseau — tout ce que votre périphérie peut calculer peut être injecté comme en-tête de requête et lu par un switch ou un point de décision. Le flux reste la source unique ; les signaux venant de l'extérieur de la passerelle alimentent le flux sans insérer de service externe sur le chemin d'authentification.
Chaque évaluation d'action — quelle étape s'est exécutée, quelle était l'entrée, quelle branche a été choisie, quel terminal a été atteint — tombe dans un flux d'audit structuré. Les opérateurs rejouent les sessions étape par étape ; les équipes sécurité corrèlent les décisions d'accès avec le reste de la télémétrie via le streaming SIEM.
Le moteur de flux en détail, les blocs de construction qui composent les règles de politique et les ajouts planifiés pour les étendre.
Un seul moteur orchestre la connexion, le challenge multifacteur, la gestion du verrouillage, les points de décision, le routage par switch et les terminaux access-granted / access-denied. Chaque étape est une action avec des transitions explicites ; le chemin de la requête anonyme à la session authentifiée est un graphe composé plutôt qu'une configuration éparpillée.
Chaque service enregistre sa propre définition de flux. Un proxy SaaS peut ne demander que le SSO ; une application interne peut ajouter le TOTP ; un système de production peut chaîner le TOTP plus un OTP frais plus un point de décision explicite. Changer la politique d'un service n'affecte pas les autres.
L'action switch évalue une variable configurable (en-tête, propriété de session, gabarit AAM) et route le flux vers une action cible en la faisant correspondre à une liste ordonnée de motifs. Cinq modes de correspondance — exact, prefix, suffix, contains, regex — avec case-insensitive optionnel ; cela couvre tout, du contrôle de rôle à la correspondance regex sur le chemin de la requête.
Les actions DecisionPoint divisent le flux en deux voies selon la présence ou l'absence d'un signal configuré. Aujourd'hui, le signal est un en-tête de requête défini par votre périphérie (CDN, module de politique upstream ou passerelle réseau) ; la surface de l'action garde la structure du flux stable, tandis que la condition sous-jacente est développée pour évaluer des expressions plus riches.
Les variables intégrées dans la configuration du flux — identité de l'utilisateur, appartenance aux groupes, id du service, environnement, propriétés de session personnalisées — sont résolues via le moteur de gabarits AAM au moment de l'évaluation. La même syntaxe de gabarit utilisée dans le branding, le routage et les messages d'erreur pilote aussi les décisions de politique ; les opérateurs apprennent un seul langage de substitution et l'utilisent partout.
Comme la MFA est une action au sein du même flux, l'accès conditionnel peut demander un deuxième facteur uniquement sur certaines branches — par exemple demander le TOTP lorsque le switch détecte le rôle admin, ou chaîner le TOTP plus un OTP frais lorsque la route atteint un terminal à haute sensibilité. L'élévation vit dans la politique, pas dans la perception de l'utilisateur.
Un langage d'expression natif est en cours de développement qui permettra à une seule politique de combiner l'identité, le groupe, le temps, l'IP source, la localisation géographique et la posture de l'appareil en une seule règle lisible — par exemple une seule expression disant « rôle admin ET temps dans les heures de bureau ET origine géographique dans la liste autorisée ET confiance de l'appareil au-dessus du seuil ». La même logique peut être obtenue aujourd'hui en chaînant les actions Switch et DecisionPoint ; le DSL condense les chaînes courantes en une seule expression.
Les évaluateurs natifs pour la recherche IP-vers-geo, la fenêtre temporelle et le score de confiance de l'appareil (via le endpoint trust manager) sont sur la feuille de route ; ainsi les flux peuvent se brancher sur ces signaux sans que l'upstream ait à les calculer au préalable. Pour les environnements qui disposent déjà d'une source geo ou de réputation IP préférée, le chemin d'injection par en-tête reste pris en charge.
Le mécanisme qui assure le déploiement sûr et l'audit facile des changements de politique.
Chaque évaluation d'action dans le flux écrit une entrée d'audit structurée — id d'action, type d'action, variables d'entrée, branche choisie, terminal atteint, latence. Les sessions sont rejouées étape par étape dans une vue chronologique unique au lieu d'être reconstruites à partir de journaux éparpillés.
L'état du flux vit dans Redis ; ainsi n'importe quelle instance de passerelle peut reprendre n'importe quelle session à n'importe quelle étape. La mise à l'échelle horizontale et les mises à niveau progressives sans interruption ne perdent pas l'état d'authentification en cours ; les opérateurs peuvent exécuter plusieurs pods de passerelle derrière un équilibreur de charge sans surcharge de coordination.
Les tentatives de facteur échouées, les challenges MFA refusés et les terminaux access-denied alimentent les mêmes compteurs de verrouillage utilisés par la couche de protection contre les attaques de connexion de la plateforme. Un utilisateur ne peut pas brute-forcer un facteur échoué en le réessayant tandis qu'une branche switch attend une tentative parallèle à une autre étape.
Les définitions de flux vivent dans la configuration JSON livrée à la passerelle ; les changements de configuration peuvent être progressifs, revus et déployés par environnement. La combinaison de la configuration versionnée et de l'audit par étape rend la question « pourquoi cet utilisateur est-il entré hier ? » répondable depuis une source unique.
Un éditeur graphique pour le moteur de flux est en cours de développement ; les opérateurs pourront construire visuellement les flux d'accès, vérifier les transitions et prévisualiser les résultats avec des utilisateurs synthétiques sans éditer le JSON à la main. Jusqu'à sa publication, les flux sont définis dans la configuration versionnée et revus avec le contrôle de changement standard.
Le mode dry-run planifié fait passer une session synthétique à travers un flux sans affecter les utilisateurs réels ; il renvoie la trace action par action et le résultat final. Combiné au constructeur visuel, il transforme les changements de politique en artefacts testables plutôt qu'en déploiements de production à l'aveugle.
Le même moteur de flux qui authentifie l'utilisateur décide si un service donné nécessite la MFA, quel facteur sera appliqué et si le raccourci d'appareil de confiance est valide. La politique MFA n'est pas un produit distinct — c'est un nœud dans le flux d'accès de ce service.
Les composants de périphérie (CDN, flux de réputation IP, passerelle réseau) injectent des en-têtes geo et de réputation ; les switch et les points de décision du flux se branchent selon ces signaux — par exemple refuser les connexions venant de réseaux malveillants connus ou diriger les régions à haut risque vers des chaînes MFA plus strictes.
Les nœuds switch qui routent selon le rôle de l'utilisateur ou l'appartenance aux groupes composent des couches d'accès dans un seul flux — les administrateurs passent par une voie avec une MFA plus stricte, les utilisateurs normaux par une voie sans friction, les prestataires par une troisième voie liée au temps et à une liste de ressources. Le flux reste auditable comme un artefact unique.
Les services soumis à PCI-DSS, HIPAA, GDPR, ISO 27001 exécutent leurs propres flux plus stricts — MFA obligatoire, enregistrement obligatoire au début de session, pas de raccourci d'appareil de confiance. L'auditeur examine une seule définition de flux et un seul flux d'audit au lieu d'un amas de règles superposées.
Un seul moteur de flux, une seule source, un seul flux d'audit — pour chaque service, chaque étape, chaque décision. Laissez-nous vous guider dans une installation en direct sur vos propres applications.