L'accès conditionnel ne peut pas être géré avec une simple liste d'autorisation
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.
Notre approche
Un moteur de flux qui s'approprie l'authentification, la MFA, les décisions et le routage dans une seule définition par service.
Chaque service exécute son propre flux d'accès
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.
Branchement par motif sur n'importe quelle variable
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.
Les signaux venant de la périphérie entrent dans le flux
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 transition est dans le journal d'audit
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.
Capacités
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.
Moteur de flux — une seule chaîne pour auth, MFA, décision et routage
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.
Définition de flux par service
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.
Switch — routage multivoies selon la correspondance de motifs
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.
Points de décision pour le branchement oui/non
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.
Variables de gabarit AAM dans les conditions
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.
Step-up et MFA chaînée pilotés par le flux
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.
Profondeur opérationnelle
Le mécanisme qui assure le déploiement sûr et l'audit facile des changements de politique.
Audit par étape avec entrée et résultat
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.
Exécution de flux sans état coordonnée via Redis
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.
Verrouillage coordonné tout au long du flux
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.
Configuration de flux versionnée
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.
Dans quels scénarios on l'utilise
Imposition de MFA par service
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.
Accès tenant compte de la geo et de la réputation IP
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.
Branchement basé sur le rôle et le groupe
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.
Chemins d'accès soumis à la conformité
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.
Questions fréquentes
Comment une politique d'accès conditionnel est-elle définie aujourd'hui ?
Comment des conditions comme la localisation géographique, le temps et la posture de l'appareil sont-elles évaluées ?
Le switch (routage par correspondance de motifs) prend-il en charge regex ?
Comment chaque décision d'accès est-elle auditée ?
Un changement de politique peut-il être testé avant la mise en production ?
Reprenez votre politique d'accès dans un seul moteur
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.