29. Sessão, trilha e contas de serviço

Por que a sessão expira, o rastro de cada alteração e a identidade própria das integrações.

Três garantias que sustentam a regra tudo é editável, e tudo fica registrado: a sessão não fica aberta para sempre, toda alteração deixa rastro, e integração não usa o login de uma pessoa.

O tempo de vida do token é a janela de inatividade. Cada ação sua renova a janela; parar de usar derruba a sessão sozinho. A janela é de cada tenant: o console da instalação a define (de 5 a 720 minutos), e sem escolha vale o padrão da instalação. Um segundo limite impede que a sessão viva para sempre só porque alguém continua mexendo.

O perfil de Monitoramento não tem desconexão por inatividade nem o limite de duração da sessão — uma tela parada na parede não deve deslogar sozinha. O token dele ainda tem prazo: vale 24 horas e a própria tela o renova antes de vencer. Renovar é o que prova que a tela ainda existe: um token copiado de uma televisão que ninguém mais usa para de valer sozinho no dia seguinte. Se o perfil da tela deixar de ser sem inatividade, a sessão que já estava aberta passa a valer como as outras na renovação seguinte: volta a cair por inatividade e ganha, dali em diante, o limite de duração.

Tudo é editável, e toda alteração é registrada campo a campo: quem mudou, quando, de que valor para qual. A trilha é append-only — a aplicação não consegue reescrevê-la nem apagá-la.

Em Configuração ▸ Trilha de auditoria (permissão admin:usuarios), para achar uma alteração:

1.     Escolha a tabela em Todas as tabelas — cada opção mostra quantas alterações ela tem.

2.     Para um registro específico, cole o identificador em Id do registro…; clicar no registro de uma linha faz o mesmo filtro (Ver tudo o que aconteceu com este registro).

3.     Em Quem alterou…, digite o login; no seletor de período, escolha de Últimas 24 horas a Desde sempre (o padrão é Últimos 30 dias).

4.     Marque incluir sessão e token só quando procurar login e sessão — por padrão eles ficam fora, porque cada entrada gera uma alteração e afoga o dado de negócio.

5.     Exportar esta página baixa o que está na tela; limpar filtros volta ao padrão.

Cada linha diz o que foi criado, alterado ou excluído, por quem e quando, com os campos e os dois valores lado a lado. O selo de origem diz se veio de uma pessoa pela interface, de uma integração pela API ou da própria plataforma (carga de catálogo, migração, rotina).

A plataforma autentica de dois modos: local, guardando usuário e senha, ou por gestor de identidade externo, via OpenID Connect. A escolha é de configuração, e nada abaixo da camada de segurança sabe qual está em uso — nos dois casos o que circula depois é o mesmo token com login, tenant e permissões.

A tela Administração ▸ Diretório e identidade mostra o que está valendo e prova que o provedor responde. O capítulo Integração com o diretório trata dela.

Identidade de sistema, com chave própria e perfil próprio, para integrações. Integrar com o login de uma pessoa faz o sistema parar quando o token dela expira, herda as permissões de quem emprestou o acesso e registra na trilha um responsável que não fez nada daquilo.

Em Administração ▸ Contas de serviço:

1.     Clique em Nova conta.

2.     Preencha Nome (ex.: Integração com o SIEM) e O que ela faz — é o que explica a conta a quem ler a trilha daqui a um ano.

3.     Em Perfil, escolha o menor perfil que cobre a integração: ela poderá tudo o que o perfil permite, e nada além. Escolher o de administrador "porque funciona" é o problema que a tela existe para evitar.

4.     Opcional: Vence em — prazo obriga alguém a reconfirmar que a integração ainda existe.

5.     Clique em Criar e mostrar a chave e use copiar. A chave aparece uma vez só: o que fica guardado é o hash, e nem o administrador a vê de novo. Guarde-a no cofre da integração.

A integração envia a chave no cabeçalho X-API-Key. Cada conta mostra o perfil, quando foi criada, quando vence e o último uso (nunca usada aparece destacado). Os três ícones da linha (o nome aparece ao passar o mouse):

•     a seta circular — Gerar chave nova; a atual para de valer. É o que fazer quando a chave vaza: troca o segredo e mantém nome, perfil e histórico;

•     o círculo cortado — Revogar: a conta para de autenticar e continua explicando a trilha;

•     a lixeira — Apagar. Quase sempre pior que revogar: a trilha passa a apontar para um identificador sem nome.

Os três perguntam antes, porque os três derrubam a integração na hora: a pergunta mostra o último uso da conta, e o botão diz o que vai acontecer — Gerar chave nova, Revogar ou Excluir. O foco nasce no Cancelar, e o Esc desiste.

Abrir a documentação da API abre, numa aba nova, a descrição de todas as rotas (Swagger), já com o tenant de quem abriu. A aba entra por um acesso de 30 minutos que o botão concede: o token da sua sessão não vai para o endereço, e o link copiado para outra pessoa não abre nada.

De qual tenant é a chave. A tela mostra o tenant destas chaves, com código e id. Toda chave criada aqui pertence a ele, e é a própria chave que diz o tenant ao servidor: não há como uma chave gravar noutro tenant. Atrás de um API gateway com endereço único para todas as empresas, mande também o cabeçalho X-Tenant com o código (ou o id) do tenant. Ele confere, não escolhe: se não for o tenant da chave, a chamada é recusada (403), e uma chave trocada é pega na porta em vez de gravar no lugar errado. No login de pessoa pela API (POST /api/v1/auth/login) por um gateway desses, é o X-Tenant que diz o tenant.

As contas de serviço são o que liga à plataforma o coletor da Área de automação (perfil Coletor de inspeção), as integrações de casos e as plataformas que enviam dado ao IMR.