--- title: 29. Sessão, trilha e contas de serviço slug: 29-sessao-trilha-e-contas-de-servico docTags: createdAt: 2026-10-13T14:43:59.545Z --- *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. *** ### A sessão expira por inatividade 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. *** ### A exceção, e o preço dela 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. :::hint{type="info"} Justamente por isso ele **não recebe nenhuma permissão de escrita**, e o banco recusa qualquer tentativa de dar-lhe uma. Sessão sem inatividade somada a direito de alterar significaria que quem passa perto da televisão altera o painel que a diretoria lê, sem nada que encerre esse acesso. ::: *** ### A trilha de auditoria 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). *** ### Entrar pela organização 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. *** ### Contas de serviço 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*.