Trilha de Auditoria

Abrir na plataforma

A Trilha de Auditoria registra quem fez o quê na plataforma. Toda ação relevante (criar host, editar regra, excluir manutenção, mudar status, login) gera um evento que fica armazenado e pesquisável. Serve pra compliance, governança e investigação de incidentes do tipo "quem mexeu nessa regra ontem?".

Quem usa

A trilha não é uma ferramenta operacional do dia a dia. Ela atende três frentes:

• Compliance e auditoria interna: revisar mudanças num período pra evidenciar controle. Útil pra ISO, SOC 2, LGPD e auditorias do cliente.
• Administração da plataforma: entender quem criou, editou ou removeu recursos. Importante quando o tenant tem mais de um admin e a equipe precisa alinhar responsabilidades.
• Investigação de incidentes: quando algo quebra, a primeira pergunta costuma ser "o que mudou?". A trilha responde, com timestamps e o payload completo da requisição.

Pra quem busca o comportamento dos alertas (quem disparou, quando, por quanto tempo), o lugar é o Histórico de Alertas. A Trilha é sobre ação humana na plataforma, não sobre eventos do ambiente monitorado.

O que é auditado

A trilha cobre as ações administrativas e de configuração. A lista não é exaustiva, mas dá uma ideia clara:

• Hosts: criação, edição, exclusão e mudança de status (habilitar/desabilitar).
• Regras de alerta: criação, edição, exclusão, troca de severidade, ativação e desativação.
• Canais de notificação: criação, edição, exclusão e teste.
• Manutenções: agendamento, edição e cancelamento.
• Dashboards: criação, edição, exclusão, compartilhamento.
• Coletores (agentes e hubs): registro, atualização, remoção.
• Usuários e ACL: convite, troca de nível, remoção, redefinição de senha.
• Sessão: login, logout e tentativas de acesso negadas.
• Configurações do tenant: parâmetros globais, integrações, chaves.

Consultas e leituras (abrir uma tela, listar hosts, baixar um relatório) não entram na trilha. O foco é em escrita, ou seja, no que muda o estado da plataforma.

A tabela

Cada linha é um evento. As colunas:

Coluna	Conteúdo
Data/Hora	Timestamp do evento no fuso do seu usuário. Ordenação padrão: mais recente primeiro.
Usuário	Email de quem executou a ação (ex: admin@example.com).
Ação	Badge colorido: Criado, Atualizado, Excluído ou Status Alterado.
Tipo	Categoria do recurso afetado: Host, Regra, Alerta, Dashboard, Manutenção, Canal, Usuário, etc.
Recurso	Nome ou identificador do recurso afetado (ex: host-srv-prd-01, dashboard-42).
Detalhes	Ícone de olho que abre o modal com o payload completo da requisição.

A toolbar acima da tabela tem campo de busca livre (casa em nome de recurso e endpoint), botão Atualizar, seletor de Linhas por página (25, 50, 100) e o contador Total com o número de eventos no recorte atual.

Filtros

A barra de filtros no topo da página combina cinco campos. Todos opcionais, todos compostos com E (todos os ativos precisam casar).

• Data de e Data até: dois datepickers. Por padrão a página abre nas últimas 24 horas. Pra revisão mensal, ajuste pro primeiro e último dia do mês.
• Ação: dropdown com Todas, Criado, Atualizado, Excluído e Status Alterado. Útil pra recortar só remoções num período (campo importante pra compliance).
• Tipo de Recurso: dropdown dinâmico que carrega a lista de tipos efetivamente presentes no banco. Permite focar em uma categoria, por exemplo só Regra quando você está investigando alertas que mudaram.
• Usuário: campo de texto com o email. Aceita correspondência parcial, então @example.com traz todos os eventos do domínio.

Os botões Aplicar e Limpar ficam à direita. Limpar zera todos os campos e volta pro recorte padrão de 24 horas.

Combine filtros pra investigação dirigida

Pra responder "o admin@example.com mexeu em regras ontem entre 14h e 18h?", preencha Data de e Data até com o intervalo, Ação = Atualizado, Tipo de Recurso = Regra e Usuário = admin@example.com. O resultado já vem pronto pra exportar como evidência.

Tipos de ação

Quatro categorias cobrem 100% dos eventos, com cores distintas no badge:

Ação	Cor	Significado
Criado	Verde	Recurso novo entrou na plataforma. Inclui hosts cadastrados, regras criadas, dashboards publicados, canais adicionados.
Atualizado	Azul	Recurso existente foi modificado. Mudança de nome, severidade, destinatário, configuração, threshold.
Excluído	Vermelho	Recurso removido em definitivo. A trilha preserva o evento, mas o recurso em si some.
Status Alterado	Âmbar	Mudança de estado sem alterar configuração: habilitar/desabilitar host, pausar/retomar regra, ativar/encerrar manutenção.

A separação entre Atualizado e Status Alterado ajuda na leitura: quando você quer saber "quem desativou aquela regra", basta filtrar por Status Alterado e ignorar o ruído das edições de configuração.

Detalhe do evento

O ícone de olho na coluna Detalhes abre um modal com o evento completo.

O modal tem duas seções:

Metadados (em duas colunas):

• Usuário: email do executor.
• Data/Hora: timestamp do evento.
• Ação: badge colorido (mesmo da tabela).
• Status: código HTTP da resposta. 200 ou 201 indicam sucesso; 4xx indica que a ação foi tentada mas rejeitada (ex: validação falhou, permissão negada). Eventos 4xx/5xx também ficam na trilha, e são úteis pra investigar acesso indevido.
• Tipo de Recurso: categoria.
• Recurso: nome ou ID.
• Endpoint: rota da API chamada (ex: PUT /api/rules/123).

Payload: bloco JSON com o body completo da requisição. É o que o usuário enviou, antes do banco gravar. Em ações Atualizado, esse JSON é a fonte da verdade pra reconstituir o estado anterior, comparando com o estado atual do recurso.

Quando abrir o detalhe

A tabela responde quem, quando, o quê. O modal responde como. Use ele quando precisar de evidência granular: o valor exato configurado, o destinatário inserido, o threshold alterado. Em auditorias formais, capture o JSON como anexo do relatório.

Filtros expandidos

A barra de filtros agrega os campos de uso mais frequente. Pra recortes maiores ou compartilhar resultado com o time, combine com a busca livre da toolbar.

A busca livre casa em Recurso e Endpoint simultaneamente, então digitar host-srv-prd-01 traz todas as ações que tocaram aquele host, independente do tipo de operação.

Limites e retenção

A página foi pensada pra investigação pontual, não pra análise estatística de grandes volumes:

• Paginação: até 200 linhas por página. O padrão é 50, e o seletor da toolbar oferece 25, 50, 100. Pra ir além de 200, refine os filtros (período menor, tipo específico, usuário).
• Navegação: padrão < 1 2 ... N >. O total de páginas vem do contador da toolbar.
• Retenção: a definir com SpecialOne, conforme o plano contratado. Em geral mantemos histórico longo (meses), mas se você precisa exportar evidência pra auditoria externa, vale combinar antes a janela exata que será preservada.

ACL

O acesso à Trilha de Auditoria é restrito a admin do tenant. Usuários operacionais não veem o menu nem conseguem chamar a API.

A própria mudança de ACL é auditada. Quando alguém promove um usuário pra admin, o evento aparece na trilha como Status Alterado sobre o recurso Usuário, e o payload do modal mostra o nível antigo e o novo.

A trilha registra, não impede

A auditoria é um controle detectivo, não preventivo. Se um admin agir indevidamente, a ação ainda acontece, mas fica registrada. Pra controle preventivo (limitar quem pode fazer o quê), o lugar é a configuração de ACL em Administração → Usuários.

Cenários de uso

Quem editou aquela regra ontem?

1. Em Data de e Data até, recorte as últimas 24 ou 48 horas.
2. Em Ação, escolha Atualizado.
3. Em Tipo de Recurso, escolha Regra.
4. Na busca da toolbar, digite o nome da regra.
5. Click no ícone de olho da linha relevante pra ver o payload e confirmar exatamente o que foi mudado.

Auditoria mensal de mudanças

1. Em Data de, primeiro dia do mês 00:00.
2. Em Data até, último dia do mês 23:59.
3. Ação: Todas (pra ter o panorama completo).
4. Navegue por usuário ou por tipo conforme a estrutura do relatório.
5. Capture o JSON de eventos críticos (criação e exclusão) como anexo.

Pra evidências formais, anexe também a captura da barra de filtros ativa, pra demonstrar o recorte usado.

Investigar incidente: o que mudou nas últimas 4 horas?

Quando uma regra parou de disparar ou um host sumiu da visão, o roteiro é:

1. Em Data de, agora menos 4 horas.
2. Em Data até, agora.
3. Tipo de Recurso: deixe Todos num primeiro varredura.
4. Na toolbar, ordene por Data/Hora ascendente, pra ler na ordem cronológica.
5. Procure eventos vermelhos (Excluído) ou âmbar (Status Alterado) que envolvam o recurso afetado.

Em incidentes de configuração, a trilha costuma cortar caminho de várias horas de investigação.

Boas práticas

• Revisão semanal: reserve 15 minutos uma vez por semana pra varrer os eventos da semana. Quanto mais cedo você detecta uma mudança inesperada, mais barata é a correção.
• Padronize nomenclatura: a coluna Recurso mostra o nome do recurso no momento da ação. Se sua equipe segue uma convenção (host-srv-prd-01, regra-cpu-alta-web), a leitura da trilha vira intuitiva e dispensa abrir o modal pra cada linha.
• Exporte pra evidência: pra auditorias formais, capture print da tabela filtrada e o JSON do modal dos eventos relevantes. Vale também salvar a URL com os filtros aplicados na descrição do ticket de auditoria.

Próximos passos

• Alertas

  ---

  A tela operacional, em tempo real, com os alertas em andamento. Toda mudança em regra de alerta aparece na Trilha.

  Ver Alertas

• Histórico de Alertas

  ---

  Lista os alertas que já se resolveram, com início, fim e duração. Pra comparar pesquisa cronológica.

  Ver Histórico

• Regras de notificação

  ---

  Quem recebe o quê, quando e por qual canal. Alterações em regras são auditadas.

  Ver Regras

• Coletores

  ---

  Agentes e hubs registrados no tenant. Ações administrativas em coletores entram na Trilha.

  Ver Coletores

• Manutenções

  ---

  Janelas programadas pra silenciar alertas. Agendamentos e cancelamentos ficam auditados.

  Ver Manutenções