Uma sessão não pode ser carregada ilimitadamente sobre a confiança concedida no login
Muitos gateways validam o usuário uma única vez no login e, depois disso, presumem que ele é confiável até a sessão expirar. Essa suposição é cômoda — e cara quando falha.
Cookies são roubados e reproduzidos a partir de outro país. A sessão do navegador é sequestrada enquanto o usuário está logado. Três administradores compartilham silenciosamente uma única conta privilegiada. Um usuário que abriu sessão em um dispositivo confiável se afasta e deixa a sessão aberta no notebook de um café. Nenhum desses momentos dispara um novo login; por isso, nenhum deles é capturado em um modelo de confiança que só olha para o momento do login.
O outro extremo — reautenticação curta e frequente — pune usuários legítimos sem resolver o problema; porque o intervalo entre dois desafios ainda é uma janela em que tudo pode acontecer.
A confiança conquistada no login deve ser continuamente reavaliada à medida que a sessão avança — silenciosamente enquanto tudo parece normal, e de forma decidida no momento em que não parece.
Nossa abordagem
As sessões são vinculadas, monitoradas, limitadas e encerradas por um único motor.
Cada sessão tem uma impressão digital que deve continuar a corresponder
No login, a sessão é vinculada ao IP do usuário, ao user agent e à impressão digital do dispositivo. Cada requisição subsequente é verificada contra essas vinculações. Uma divergência não é ignorada silenciosamente — o fluxo de anomalia de vinculação é disparado; esse fluxo pode reautenticar, restringir ou encerrar a sessão de acordo com a política.
Quando algo muda, a ressincronização força uma avaliação nova
Quando a política de acesso muda, quando uma propriedade é atualizada ou quando o risco aumenta dentro da sessão, o AAM pode iniciar uma ressincronização forçada — o contexto de confiança é reconstruído, a política de acesso condicional é reavaliada e as novas regras são aplicadas sem reiniciar o usuário a partir da página de login.
As sessões concorrentes são limitadas, não ilimitadas
Um único usuário não pode ter um número ilimitado de sessões ativas. Os limites são configurados por grupo de usuários e por serviço. Assim, uma conta privilegiada não pode ser compartilhada silenciosamente entre três operadores e o notebook de um contratado não pode ser aberto a dezenas de logins paralelos.
O logout fecha não apenas uma aba, mas todas as portas
O logout feito a partir de uma aplicação limpa a sessão no gateway e se propaga a cada serviço conectado. Tokens roubados tornam-se inutilizáveis, logouts parciais não deixam abas em segundo plano autenticadas, e o logout de fim de dia realmente encerra o dia.
Capacidades
Os controles de sessão que transformam um login único em confiança contínua.
Vinculação de sessão — IP, user agent e impressão digital do dispositivo devem continuar a corresponder
Cada sessão autenticada é vinculada ao IP original, ao user agent e à impressão digital do dispositivo calculada no login. Uma divergência em qualquer um desses sinais roteia para o fluxo de anomalia de vinculação: reautenticar, restringir a recursos seguros, encerrar a sessão ou registrar-e-alertar, de acordo com a política de acesso condicional daquele serviço.
Ressincronização forçada de sessão — renove a confiança sem reiniciar o usuário
Quando a política que autorizou a sessão muda, quando uma propriedade é atualizada ou quando um sinal externo o solicita, o AAM pode iniciar uma ressincronização. O contexto de confiança é reconstruído, a política de acesso condicional é reavaliada e a sessão continua — sem que o usuário repita o login ou perca o trabalho em andamento.
Timeout de sessão por inatividade e absoluto
As sessões terminam com dois contadores: o timeout de inatividade que roda quando o usuário está passivo e o timeout absoluto que roda independentemente da atividade. Ambos são configurados por grupo de serviços; uma aplicação de intranet de baixo risco pode permanecer aberta o dia todo, enquanto uma sessão administrativa privilegiada termina após uma curta janela de inatividade.
Limites de sessão concorrente por usuário e por serviço
Os administradores definem o número máximo de sessões ativas por usuário, grupo ou serviço. Quando o limite é atingido, um novo login é rejeitado, substitui a sessão mais antiga ou solicita confirmação explícita — impedindo o compartilhamento silencioso de conta e trazendo à luz instantaneamente picos incomuns de login.
Logout único abrangente entre serviços conectados
Fazer logout de uma aplicação dispara um encerramento limpo de sessão no gateway, que então se propaga a cada serviço conectado. Não há sessão órfã ainda ativa em outra aba, não há token ainda válido em um navegador esquecido e não há logout parcial que o usuário pensa estar concluído.
Recuperação de perda de sessão sem descartar o trabalho em andamento
Se uma sessão for perdida temporariamente — um breve soluço de armazenamento, uma ressincronização forçada, uma curta interrupção de rede — o usuário chega a uma página de recuperação que reautentica sua identidade e restaura seu contexto. O fluxo é intencional e auditado, não um relogin silencioso; uma tentativa de recuperação maliciosa não pode se misturar ao tráfego normal.
Profundidade operacional
A infraestrutura que torna a avaliação contínua confiável, rápida e auditável.
Pods de gateway stateless coordenados via Redis
O estado da sessão vive no Redis; assim, qualquer pod de gateway pode assumir qualquer sessão em qualquer passo. As verificações de vinculação, os gatilhos de ressincronização e as contagens de sessão concorrente permanecem consistentes entre os pods em implantações escaladas horizontalmente, sem sobrecarga de coordenação.
Trilha de auditoria baseada em eventos
Cada evento de sessão — vincular, divergência detectada, ressincronização forçada, timeout disparado, limite concorrente atingido, logout — escreve uma entrada de auditoria estruturada com timestamp, IP de origem, user agent e resultado. As sessões podem ser reconstruídas em uma única linha do tempo a partir do log de auditoria e o fluxo é roteado ao destino de SIEM streaming da plataforma.
Orquestração de step-up MFA dentro da sessão
Quando a sessão precisa de step-up — o risco aumentou, o usuário alcançou um recurso mais sensível, a política o exige — o avaliador de confiança delega à ação de MFA dentro da política de acesso condicional. O usuário apenas conclui o fator adicional; a própria sessão continua sem novo login.
Rebaixamento para somente-leitura para recursos privilegiados
Quando a confiança cai, em vez de encerrar a sessão diretamente, a política pode rebaixá-la para o modo somente-leitura — permitindo que o usuário continue vendo o trabalho que está fazendo, enquanto bloqueia uma operação destrutiva. O usuário vê um aviso claro; a equipe de segurança vê a decisão no fluxo de auditoria.
Em quais cenários é usado
Cookie de sessão roubado
Um atacante que vaza um cookie de sessão e o reproduz a partir de outra rede e navegador é capturado por divergência de vinculação no instante em que a primeira requisição chega ao gateway — sem esperar o próximo login do usuário.
Mudança geográfica ou de dispositivo dentro da sessão
Um operador privilegiado cujo IP de origem muda de país dentro da sessão é elevado a MFA adicional antes da próxima ação sensível; um endpoint que sai da postura gerenciada tem a sessão rebaixada para o modo somente-leitura até o dispositivo voltar à conformidade.
Compartilhamento silencioso de conta
Uma única conta privilegiada compartilhada silenciosamente por três operadores é trazida à luz pelo limite de sessão concorrente e pela linha do tempo de auditoria — visível a partir de uma única consulta, sem que ninguém precise admitir que compartilhou.
Evidência de conformidade por sessão
As auditorias de PCI-DSS, HIPAA, GDPR e ISO 27001 procuram evidências de que as sessões privilegiadas são limitadas, monitoradas e encerradas de forma limpa. A auditoria baseada em eventos fornece uma única linha do tempo para cada sessão; o auditor a reproduz sem reconstrução manual.
Perguntas frequentes
Por quais sinais a vinculação de sessão é correspondida?
Quantas sessões concorrentes um usuário pode ter ao mesmo tempo?
O que acontece se a confiança cair dentro da sessão?
O logout encerra uma aba ou todas as sessões conectadas?
Mantenha a confiança sob avaliação, não sob suposição
Um único motor para vinculação, tempo de vida, limites concorrentes e logout — cada evento de sessão é auditado. Vamos guiá-lo por uma instalação ao vivo nas suas próprias aplicações.