Une session ne peut pas être portée indéfiniment au-delà de la confiance accordée à la connexion
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.
Notre approche
Les sessions sont liées, surveillées, limitées et terminées via un seul moteur.
Chaque session a une empreinte qui doit continuer à correspondre
À 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.
La resynchronisation force une évaluation fraîche lorsque quelque chose change
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.
Les sessions concurrentes sont limitées, pas illimitées
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.
La déconnexion ferme toutes les portes, pas seulement un onglet
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.
Capacités
Les contrôles de session qui transforment une connexion unique en confiance continue.
Liaison de session — l'IP, le user agent et l'empreinte de l'appareil doivent continuer à correspondre
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.
Resynchronisation forcée de session — renouveler la confiance sans relancer l'utilisateur
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.
Délai d'attente de session inactif et absolu
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é.
Limites de sessions concurrentes par utilisateur et par service
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.
Déconnexion unique étendue entre les services liés
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.
Récupération de session perdue sans abandon du travail en cours
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.
Profondeur opérationnelle
L'infrastructure qui rend l'évaluation continue fiable, rapide et auditable.
Pods de passerelle sans état coordonnés via Redis
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.
Piste d'audit par événement
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.
Orchestration de MFA step-up en cours de session
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.
Rétrogradation en lecture seule pour les ressources privilégiées
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.
Dans quels scénarios on l'utilise
Cookie de session volé
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.
Changement géographique ou d'appareil en cours de session
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é.
Partage silencieux de compte
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.
Preuve de conformité par session
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.
Questions fréquentes
Sur quels signaux la liaison de session est-elle mise en correspondance ?
Combien de sessions concurrentes un utilisateur peut-il avoir simultanément ?
Que se passe-t-il si la confiance baisse au sein de la session ?
La déconnexion termine-t-elle un onglet ou toutes les sessions liées ?
Maintenez la confiance sous évaluation, pas sous supposition
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.