De nombreuses passerelles vérifient l'utilisateur une seule fois à la connexion et supposent ensuite qu'il reste digne de confiance jusqu'à l'expiration de la session. Cette supposition est confortable — et coûteuse lorsqu'elle échoue.
Les cookies sont volés et rejoués depuis un autre pays. La session du navigateur est détournée pendant que l'utilisateur est connecté. Trois administrateurs partagent silencieusement un même compte privilégié. Un utilisateur qui se connecte sur un appareil de confiance s'éloigne et laisse la session ouverte sur un ordinateur portable de café. Aucun de ces moments ne déclenche une nouvelle connexion ; c'est pourquoi aucun n'est attrapé dans un modèle de confiance qui ne regarde que l'instant de la connexion.
L'autre extrême — une réauthentification courte et fréquente — punit les utilisateurs légitimes sans résoudre le problème ; car la durée entre deux challenges reste une fenêtre où tout peut arriver.
La confiance gagnée à la connexion doit être réévaluée en continu à mesure que la session avance — silencieusement tant que tout semble normal, et de manière décisive à l'instant où ça ne l'est plus.
Les sessions sont liées, surveillées, limitées et terminées via un seul moteur.
À la connexion, la session est liée à l'IP de l'utilisateur, à son user agent et à l'empreinte de son appareil. Chaque requête suivante est contrôlée contre ces liaisons. Une non-concordance n'est pas ignorée silencieusement — le flux d'anomalie de liaison est déclenché ; ce flux peut effectuer, selon la politique, une réauthentification, une restriction ou une terminaison de session.
Lorsque la politique d'accès change, qu'une propriété est mise à jour ou que le risque augmente au sein de la session, AAM peut démarrer une resynchronisation forcée — le contexte de confiance est reconstruit, la politique d'accès conditionnel est réévaluée et les nouvelles règles sont appliquées sans relancer l'utilisateur depuis la page de connexion.
Un seul utilisateur ne peut pas avoir un nombre illimité de sessions actives. Les limites sont configurées par groupe d'utilisateurs et par service. Ainsi, un compte privilégié ne peut pas être partagé silencieusement entre trois opérateurs et un ordinateur portable de prestataire ne peut pas être ouvert à des dizaines de connexions parallèles.
Une déconnexion depuis une application nettoie la session sur la passerelle et se propage à chaque service lié. Les jetons volés deviennent inutilisables, les déconnexions partielles ne laissent pas les onglets en arrière-plan authentifiés, et la déconnexion de fin de journée ferme réellement la journée.
Les contrôles de session qui transforment une connexion unique en confiance continue — plus les signaux de la feuille de route qui l'approfondiront.
Chaque session authentifiée est liée à l'IP d'origine, au user agent et à l'empreinte de l'appareil calculée à la connexion. Une non-concordance sur l'un de ces signaux dirige vers le flux d'anomalie de liaison : réauthentification, restriction aux ressources sûres, terminaison de session ou journalisation-et-alerte, selon la politique d'accès conditionnel de ce service.
Lorsque la politique qui autorise la session change, qu'une propriété est mise à jour ou qu'un signal externe le demande, AAM peut démarrer une resynchronisation. Le contexte de confiance est reconstruit, la politique d'accès conditionnel est réévaluée et la session continue — sans que l'utilisateur répète la connexion ou perde son travail en cours.
Les sessions expirent avec deux compteurs : le délai d'attente d'inactivité qui se déclenche lorsque l'utilisateur est passif et le délai d'attente absolu qui se déclenche indépendamment de l'activité. Les deux sont configurés par groupe de services ; une application intranet à faible risque peut rester ouverte toute la journée tandis qu'une session d'administrateur privilégié expire après une courte fenêtre de passivité.
Les administrateurs déterminent le nombre maximal de sessions actives par utilisateur, par groupe ou par service. Lorsque la limite est atteinte, une nouvelle connexion est soit refusée, soit remplace la session la plus ancienne, soit demande une confirmation explicite — cela empêche le partage silencieux de compte et met instantanément en lumière les intensités de connexion inhabituelles.
Se déconnecter d'une application déclenche une terminaison de session propre sur la passerelle, puis se propage à chaque service lié. Il n'y a pas de session orpheline restée active dans un autre onglet, pas de jeton encore valide dans un navigateur oublié, et pas de déconnexion partielle que l'utilisateur croyait terminée.
Si une session est temporairement perdue — un bref hoquet de stockage, une resynchronisation forcée, une courte coupure réseau — l'utilisateur atterrit sur une page de récupération qui ré-authentifie son identité et restaure son contexte. Le flux est intentionnel et audité, ce n'est pas une reconnexion silencieuse ; une tentative de récupération malveillante ne peut pas se fondre dans le trafic normal.
Un moteur de score de confiance planifié combinera plusieurs signaux en direct — force de correspondance de liaison, durée de session, cadence de clics, motif de navigation, entrée de confiance du point de terminaison, stabilité géographique — en un seul score continu qui pilote les décisions de politique. Aujourd'hui, les mêmes signaux sont évalués de manière discrète via la non-concordance de liaison, les compteurs de durée de vie et les événements de resynchronisation ; le score les agrège en un seul nombre ajustable.
Les lignes de base comportementales (rythme de frappe, motif de navigation, heure de la journée, ordre d'accès aux ressources) en tant que signaux supplémentaires pour le moteur de score de confiance sont sur la feuille de route. L'objectif n'est pas de prendre l'empreinte des utilisateurs de manière intrusive ; c'est de faire émerger les écarts évidents — comme un utilisateur qui ne touche jamais à l'application financière téléchargeant soudain tous les rapports — en tant qu'anomalies qui élèvent les exigences de confiance.
L'infrastructure qui rend l'évaluation continue fiable, rapide et auditable.
L'état de session vit dans Redis ; ainsi n'importe quel pod de passerelle peut reprendre n'importe quelle session à n'importe quelle étape. Les contrôles de liaison, les déclencheurs de resynchronisation et les comptages de sessions concurrentes restent cohérents entre les pods dans les déploiements à mise à l'échelle horizontale sans surcharge de coordination.
Chaque événement de session — liaison, non-concordance détectée, resynchronisation forcée, délai d'attente déclenché, limite concurrente atteinte, déconnexion — écrit une entrée d'audit structurée avec horodatage, IP source, user agent et résultat. Les sessions peuvent être reconstruites depuis le journal d'audit en une seule chronologie et le flux est dirigé vers la cible de streaming SIEM de la plateforme.
Lorsqu'une session a besoin d'une élévation — le risque a augmenté, l'utilisateur a atteint une ressource plus sensible, la politique le demande — l'évaluateur de confiance délègue à l'action MFA au sein de la politique d'accès conditionnel. L'utilisateur complète seulement le facteur supplémentaire ; la session elle-même continue sans reconnexion.
Lorsque la confiance baisse, au lieu de couper directement la session, la politique peut la rétrograder en mode lecture seule — en permettant à l'utilisateur de continuer à voir le travail effectué tout en empêchant une opération destructrice. L'utilisateur voit un avertissement clair ; l'équipe sécurité voit la décision dans le flux d'audit.
L'entrée native depuis le composant endpoint trust manager (ETM) est sur la feuille de route ; ainsi les changements de posture de l'appareil — chiffrement de disque désactivé, dérive de signature AV, détection de jailbreak — sont directement alimentés dans l'évaluation de confiance de la session. Aujourd'hui, les mêmes signaux passent par les en-têtes de requête ; l'intégration native rend cela plus étroit et avec une latence plus faible.
Un panneau de session en direct est planifié ; les administrateurs verront les sessions actives par utilisateur et par ressource, pourront descendre jusqu'à l'état de liaison et à la chronologie d'audit, et déclencher la resynchronisation, l'élévation ou la terminaison depuis la même vue. Jusqu'à sa publication, les mêmes opérations fonctionnent via l'API d'administration de la passerelle.
Un attaquant qui exfiltre un cookie de session et le rejoue depuis un autre réseau et navigateur est attrapé par la non-concordance de liaison à l'instant où la première requête atteint la passerelle — sans attendre la prochaine connexion de l'utilisateur.
Un opérateur privilégié dont l'IP source change de pays au sein de la session est élevé à une MFA supplémentaire avant la prochaine action sensible ; un point de terminaison qui sort de la posture gérée voit sa session rétrogradée en mode lecture seule jusqu'à ce que l'appareil revienne en conformité.
Un seul compte privilégié silencieusement partagé par trois opérateurs est mis en lumière par la limite de sessions concurrentes et la chronologie d'audit — visible depuis une seule requête sans que personne ait à avouer le partage.
Les audits PCI-DSS, HIPAA, GDPR et ISO 27001 recherchent la preuve que les sessions privilégiées sont limitées, surveillées et terminées proprement. L'audit par événement donne une seule chronologie pour chaque session ; l'auditeur la rejoue sans reconstruction manuelle.
Un seul moteur pour la liaison, la durée de vie, les limites concurrentes et la déconnexion — chaque événement de session est audité. Laissez-nous vous guider dans une installation en direct sur vos propres applications.