Ação Imediata no SSC – Limitando Sessões Concorrentes para Eliminar o Risco de Sequestro de Sessão

tiagomacul · 3 hours ago

Introdução: A Segurança Começa na Sessão

Garantir a segurança da sua instância ServiceNow é uma tarefa contínua, e o ServiceNow Security Center (SSC) é o seu painel de controle para essa missão. Um dos itens de conformidade mais críticos, e frequentemente ignorado, é o risco de sequestro de sessão (session hijacking).

Este artigo detalha como ativar e configurar o plugin Limit Concurrent Sessions para mitigar esse risco e elevar imediatamente o seu Hardening Score no SSC, conforme detalhado em nosso guia central: SSC — O Guia Definitivo para Blindar Sua Instância e Atingir a Conformidade.

Por Que Limitar as Sessões Concorrentes?

O sequestro de sessão ocorre quando um atacante rouba o cookie de uma sessão ativa e não expirada. Se um usuário tiver cinco ou dez abas ou dispositivos logados simultaneamente, o atacante tem cinco ou dez "portas" abertas para explorar.

O plugin Limit Concurrent Sessions (com.glide.limit.concurrent.sessions) atua diretamente nesse vetor de ataque:

Ao limitar o número de sessões ativas por usuário ou por perfil de acesso, reduzimos drasticamente a superfície de ataque e minimizamos as chances de sucesso de um sequestro de sessão.

Se um usuário com um perfil de alta criticidade (como admin ou security_admin) é limitado a apenas uma sessão, qualquer nova tentativa de login irá invalidar a sessão mais antiga, forçando a autenticação novamente e frustrando o ataque.

Guia de Ativação do Plugin (Em 3 Passos)

A ativação e configuração deste recurso é um processo simples, mas crucial para o cumprimento das melhores práticas de segurança.

Passo 1: Instalação do Plugin

Navegue para a Gestão de Aplicações: No campo de filtro da sua instância, digite e navegue até:
- System Definition > Plugins
- Ou acesse o Admin Center (Admin Center > Application Manager).

2.Busque pelo ID: Busque pelo nome do plugin ou pelo seu ID:

Plugin ID: com.glide.limit.concurrent.sessions

3.Instale: Clique no plugin e selecione Instalar (ou Install).

⚠️ Melhor Prática: Como em qualquer alteração de segurança, sempre recomendamos realizar a instalação e teste inicial em um ambiente de não-produção (sub-production) para validar o comportamento esperado.

Passo 2: Configuração da Propriedade (O Passo Essencial)

A simples instalação do plugin NÃO garante a conformidade. É necessário definir a propriedade do sistema que ativa o limite.

Navegue para Propriedades: No campo de filtro, digite e navegue até:
- sys_properties.list
Crie ou Modifique a Propriedade: Busque pela propriedade: glide.ui.limit_concurrent_sessions.
Defina o Valor: Defina o valor para o número máximo de sessões permitidas.
- Valor Recomendado: 1 (Uma sessão por usuário).
- Outras Opções: Você pode usar 2 ou 3 para acomodar usuários que precisam estar logados em múltiplas abas, mas o valor 1 é o mais seguro.

Passo 3: Validação no Security Center (SSC)

Após a instalação e configuração da propriedade, o ServiceNow Security Center (SSC) irá reconhecer a mudança e atualizar o seu Hardening Score.

Navegue para o SSC: Acesse Security Center > Configuration Console.
Verifique a Conformidade: Na área de Hardening Settings, procure pelo item relacionado à limitação de sessões. O status mudará de "Não Conforme" para "Conforme" (Compliant).

A conformidade com esta métrica é um passo sólido para blindar sua instância e garantir que você esteja aderindo às diretrizes de segurança mais rigorosas da ServiceNow.

Como o Limite de Sessões (Valor = 1) Afeta a Experiência do Usuário

Ao configurar a propriedade glide.ui.limit_concurrent_sessions com o valor 1 (uma sessão por usuário), o sistema impõe uma restrição baseada no agente do navegador (browser) utilizado, e não no número de abas abertas.

O que define uma única sessão:

A mesma sessão: Múltiplas abas (tabs) abertas em um único navegador (Ex: Google Chrome) são consideradas parte da mesma sessão ativa. A navegação será contínua em todas as abas.
Uma nova sessão: Realizar o login em um navegador diferente (Ex: Microsoft Edge, Mozilla Firefox) ou em um dispositivo diferente forçará o início de uma nova sessão.

Comportamento em Caso de Conflito:

Se o usuário estiver logado no Navegador A (Chrome) e tentar logar no Navegador B (Edge):

O login no Navegador B será bem-sucedido.
A sessão anterior no Navegador A será marcada para expirar.
Qualquer ação subsequente realizada no Navegador A (como um clique, atualização da página, salvamento de registro ou navegação) resultará no encerramento imediato da sessão, exigindo que o usuário faça login novamente.

Em resumo, a propriedade garante que o usuário esteja ativo em apenas um contexto de navegador por vez, eliminando o risco de múltiplas sessões válidas abertas em diferentes agentes.

Se precisar de mais detalhes sobre como este item se encaixa no panorama geral do SSC, consulte o artigo CORE: SSC — O Guia Definitivo para Blindar Sua Instância e Atingir a Conformidade.

Participe, entre nas comunidades, acompanhem os posts:

Joatan Fontoura

Olá, Tiago!

Obrigado por compartilhar sobre este tema!

Uma dúvida (só para confirmar): com esta configuração feita, isso impedirá que os usuários utilizem simultaneamente múltiplas abas do browser de internet para navegar pela instância?

Obrigado!

tiagomacul

@Joatan Fontoura

Excelente pergunta, vamos melhorar o KB/DOC.

Se colocar a propriedade com valor 01 (um)

Sim, só abre um navegador por vez.

Quando você está em um navegador com várias ABAs isso não configura duas sessões você continua na mesma sessão.

Exemplo abaixo de sessão única

Neste caso utilizei o Google Chrome

Se por acaso utilizar outro navegador IE, por exemplo (rs).

Será outra sessão, ou seja, assim que realizar o login no outro navegador sua sessão anterior será encerrada após qualquer ação. (reload, click, save, update...)