O session hijacking é um problema clássico, mas ainda crítico. Quando o cookie de sessão do usuário é capturado, o atacante tenta assumir a sessão com o mesmo token. Se o sistema olha apenas para a existência do token, ele não verifica em qual contexto de IP, dispositivo, navegador ou usuário esse token foi gerado. Nesse caso, o identificador de sessão por si só torna-se o limite de segurança.
Esquecer as flags de segurança de cookie também é uma fraqueza comum. Sem HttpOnly, scripts do lado do cliente podem acessar o cookie; sem Secure, a camada de transporte enfraquece; sem SameSite, as requisições cross-site tornam-se mais arriscadas. Esperar que essas configurações sejam aplicadas de forma consistente por cada equipe de aplicação não é realista em grandes organizações.
A gestão de timeout também costuma ser mal configurada. O idle timeout determina por quanto tempo a sessão permanece aberta após a última atividade; o absolute timeout, por sua vez, limita a vida máxima a partir do momento do login, mesmo que o usuário esteja ativo. Especialmente em portais financeiros, de saúde e corporativos, esses dois limites precisam ser gerenciados separadamente.
O controle de sessões simultâneas não se resolve sozinho com o sistema de cookie padrão. Decisões como de quantos dispositivos um usuário pode fazer login, se um novo login deve derrubar a sessão antiga ou se o novo login deve ser recusado exigem um session store central e o acompanhamento de sessões ativas. Em estruturas multi-nó, isso se torna ainda mais crítico.
A Proteção de Sessão do TR7 reúne essa necessidade sob um único policy graph: geração de session ID, flags de segurança de cookie, binding IP / IP+UA / composite, idle e absolute timeout, máximo de sessões simultâneas e criptografia de cookie opcional convergem no mesmo modelo de gestão.
O TR7 aplica a proteção de sessão não como uma única configuração de cookie, mas como uma política multicamada que vai da geração à validação e da renovação ao encerramento.
O SAM gerencia em conjunto a session affinity, o nome do cookie, a origem do cookie, o formato da sessão e as flags de segurança. O TR7 pode gerar o session ID ou operar com o cookie gerado pelo backend; podem ser usadas as opções de formato UUID, IP+timestamp+random, IP+random ou custom.
Depois de a sessão ser aberta, pode-se aplicar um dos modos de binding IP, IP+UA, composite ou none. Quando uma mudança de contexto é detectada, marca-se session mismatch e a aplicação pode solicitar reautenticação ou um controle adicional.
Quando a criptografia de cookie baseada em AES-256-CBC é ativada, os cookies selecionados tornam-se ilegíveis no lado do cliente. Graças ao binding adicional derivado do contexto IP+UA, dificulta-se a reutilização do token em outro cliente.
A operação de session refresh é executada de forma atômica com funções Lua do Redis. O idle timeout pode ser renovado a cada atividade; o absolute timeout fica vinculado ao momento do login. O controle de máximo de sessões simultâneas também pode ser aplicado pelo session state central.
A Proteção de Sessão oferece perfis prontos, opções de binding, gestão de timeout e segurança de cookie para diferentes necessidades de segurança e experiência do usuário.
O perfil default é projetado para o uso padrão corporativo, com binding IP, 8 horas de idle timeout e 7 dias de absolute timeout. O perfil session_strict proporciona segurança mais rígida, com binding IP+UA, 30 minutos de idle, 8 horas de absolute timeout e uma única sessão simultânea. O perfil session_relaxed, sem binding, com 7 dias de idle e 90 dias de absolute timeout, é adequado a sessões SaaS de longa duração. O perfil session_singleDevice, com binding IP e política de única sessão simultânea, é usado em aplicações que exigem restrição de licença ou de dispositivo.
O TR7 não força o formato do session ID a um único modelo fixo. O formato ipTimestampRandom proporciona o formato forte padrão, com a combinação de IP, tempo e valor random; o formato uuid gera um valor opaco e sem IP. O formato ipRandom usa IP e valor random; o formato custom permite que o operador crie a chave de sessão a partir de header, cookie ou variáveis personalizadas. Essa flexibilidade adapta-se a diferentes arquiteturas de aplicação.
Na camada SAM, HttpOnly pode ser configurada como flag de segurança mínima. Flags adicionais como Secure, SameSite=Strict ou SameSite=Lax também podem ser adicionadas no nível de política. O valor Max-Age do cookie pode ser associado ao absolute timeout. Assim, não se espera que cada equipe de aplicação faça sem erro, separadamente, as configurações de segurança de cookie.
Quando o valor samCookieSource é TR7, o cookie de sessão é gerado na camada ADC. Se o backend continuar gerando seu próprio cookie, pode-se usar o cookie originado do backend. No modelo híbrido, se houver cookie do backend, prossegue-se com esse valor; caso contrário, o TR7 pode gerar um novo valor de sessão. Essa abordagem adapta-se tanto a aplicações novas quanto a sistemas antigos.
O binding ip preserva o contexto do IP de origem em que o usuário fez login; é forte em cenários de escritório corporativo ou VPN. O binding ip+ua proporciona controle mais rígido ao avaliar em conjunto o par IP e User-Agent. O binding composite pode ser estendido com componentes adicionais como Accept-Language, header personalizado ou TLS fingerprint. O modo none, por sua vez, comporta-se de forma mais flexível em usos SaaS com sessão de longa duração e mudanças frequentes de rede.
A criptografia de cookie não é considerada ativa por padrão; é uma proteção opcional habilitada para os cookies selecionados. Quando ativa, aplica-se o fluxo cookie_encrypt no lado da response e cookie_decrypt no lado da request. Com salt, padding e formatação base64 para cada cookie, o valor no lado do cliente torna-se sem sentido. Quando a descriptografia falha, o valor não é tratado como dado de sessão confiável e a aplicação pode decidir reautenticar ou recusar.
O sessionIdleTimeout determina por quanto tempo a sessão permanece válida após a última atividade. O sessionAbsoluteTimeout, por sua vez, limita a vida máxima da sessão a partir do momento do login e não se estende continuamente com a atividade. Essa distinção é crítica especialmente em aplicações bancárias, portais corporativos e aplicações com dados sensíveis. A experiência do usuário e o limite de segurança são equilibrados na mesma política.
Com o valor maxConcurrentSessions determina-se quantas sessões ativas um usuário pode ter ao mesmo tempo. Quando o limite é excedido, a sessão mais antiga pode ser derrubada com logout_oldest, ou o novo login pode ser recusado com deny_new. Essa estrutura pode ser usada para licença de dispositivo único, segurança bancária ou controle de acesso corporativo. A lista de sessões ativas é acompanhada no session state central.
Durante o login a sessão é criada, durante cada request pode ser feito o idle refresh, quando há binding mismatch a sessão é marcada como suspeita e durante o logout a sessão é invalidada. Esse ciclo de vida garante que a sessão seja gerenciada não apenas no início, mas durante todo o período de uso. Os fluxos de SIEM e auditoria podem produzir sinais de segurança a partir desses eventos. O histórico de sessão é importante especialmente em investigações de account takeover.
Para preservar o session state em múltiplos nós TR7, podem-se usar em conjunto a sincronização de peers e o store central baseado em Redis. O projeto é feito de modo a preservar a continuidade da sessão em cenários de failover ou rolling restart. Com opções de replication e persistência no lado do Redis, pode-se aumentar a resiliência do session state. Essa estrutura impede que a proteção de sessão fique presa a um único nó.
A proteção de sessão é operada em conjunto com o nome do cookie, a geração de attributes, o composite binding, as categorias de auditoria, o session store e os comportamentos de fallback de timeout.
O nome de cookie padrão pode ser usado como TR7SID. Para cada pool pode-se definir um nome diferente com samCookieName. Isso é usado para conformidade de marca, padrão de aplicação ou compatibilidade com a arquitetura de cookie existente.
Ao gerar o valor do cookie, attributes como HttpOnly, Secure, SameSite e Max-Age são adicionados conforme as configurações de política. Esses attributes só podem ser definidos quando uma nova sessão é gerada. Assim, a segurança de cookie é padronizada por política central.
O composite binding pode ser estabelecido por padrão com componentes como IP de origem e User-Agent. O operador pode incluir componentes adicionais como Accept-Language, Accept-Encoding, header personalizado ou TLS fingerprint. Esse cálculo deve ser feito em estágio tardio, depois de as variáveis relevantes serem geradas.
Os eventos de sessão e acesso podem ser registrados com categorias como whitelisted, authorized ou unauthorized. Essa informação facilita no lado do SIEM as investigações de account takeover, abuso e acesso não autorizado. Para cada request, o contexto de usuário e sessão torna-se mais visível.
O session state do AAM pode ser mantido no Redis e as operações de session refresh são executadas de forma atômica com funções Lua. Esse modelo retira a latência clássica de banco de dados do caminho de controle de sessão. Com recursos do Redis como AOF e replication, pode-se aumentar a persistência e a resiliência.
Se a configuração de idle timeout estiver ausente, pode-se usar o fallback de 1 hora. Se o absolute timeout estiver ausente, pode-se aplicar o valor de fallback de 24 horas. Esses valores fornecem pressupostos seguros que impedem a criação de sessões ilimitadas quando a configuração está ausente.
Uma aplicação bancária pode querer manter o usuário em um único dispositivo e fechar a sessão após 30 minutos de inatividade. O perfil session_strict é aplicado com binding IP+UA, 30 minutos de idle, 8 horas de absolute timeout e política de única sessão simultânea. Se uma sessão roubada for usada em outro contexto, gera-se um sinal de mismatch.
Usuários de SaaS B2B podem querer acessar a mesma conta por laptop, telefone e tablet. O perfil session_relaxed preserva a experiência do usuário, sem binding e com longos valores de idle e absolute timeout. Mudança de IP ou diversidade de dispositivos não produz reautenticação desnecessária.
No portal do funcionário, o usuário faz login pela rede do escritório ou VPN e trabalha durante todo o dia de trabalho sem fazer login novamente. O perfil default pode ser aplicado com binding IP, 8 horas de idle timeout e 7 dias de absolute timeout. Se o contexto de IP mudar, a aplicação pode solicitar reautenticação.
Uma aplicação premium ou serviço licenciado pode querer que a conta seja usada em um único dispositivo por vez. O perfil session_singleDevice, com no máximo 1 sessão simultânea e comportamento logout_oldest, derruba a sessão antiga em um novo login. O compartilhamento de licença e o uso múltiplo não controlado tornam-se mais difíceis.
Geração de session ID, flags de segurança de cookie, binding IP+UA, política de timeout e limite de sessões simultâneas sob um único policy graph. Vamos guiá-lo por uma configuração ao vivo com seus próprios serviços.