Os registos de auditoria registam todas as ações que alteram o estado na sua organização — atribuição de funções, edições do motor, emissão de chaves de API, alterações de faturação — e apresentam-nas numa cronologia pesquisável e filtrável. Disponível no plano Enterprise, juntamente com Funções e permissões.
O registo é append-only ao nível da base de dados: a ligação da aplicação não pode atualizar, eliminar nem truncar linhas de auditoria. O que é escrito, fica escrito.
O que é registado#
Cada evento capta o autor, a ação, o alvo e o contexto HTTP em que o pedido foi recebido.
| Campo | Notas |
|---|---|
| Autor | O utilizador ou a chave de API que executou a ação |
| Ação | Um valor tipado como engine.created ou member.role_changed |
| Alvo | A entidade afetada (por exemplo, um motor, uma função ou um item do glossário) |
| Metadados | IDs de entidades relacionadas — nunca nomes, emails ou excertos de conteúdo |
| Contexto do pedido | request_id, endereço IP, user agent — captados quando a chamada chegou por HTTP |
| Carimbo temporal | UTC, mais um número de sequência monotónico para deteção de lacunas |
Só IDs, por design
A coluna de metadados armazena IDs, não valores legíveis por humanos. A interface associa os nomes atuais no momento da leitura, pelo que mudar o nome de um motor ou utilizador não reescreve o histórico. Além disso, mantém as linhas de auditoria fora de conflitos com o direito ao apagamento do RGPD — não há conteúdo para ocultar.
Ações abrangidas#
Os eventos são agrupados em categorias que correspondem ao filtro no dashboard.
| Categoria | Ações atualmente ligadas |
|---|---|
| Organização | org.created, org.settings_updated, org.ownership_transferred, org.deleted |
| Membros | member.invited, member.removed, member.role_changed |
| Funções | role.created, role.updated, role.deleted |
| Motores | engine.created, engine.updated, engine.deleted |
| Chaves de API | api_key.created, api_key.revoked |
| Conteúdo | glossary_item.*, instruction.*, brand_voice.* (apenas operações individuais) |
Aceder ao registo#
A entrada Registos de auditoria só aparece na barra lateral de Organização quando a funcionalidade está ativa para a sua organização. No interior, encontrará:
- Lista filtrável — filtre por autor, categoria de ação, tipo de alvo e intervalo de datas. As datas futuras são bloqueadas e o limite superior é sempre ≥ ao limite inferior.
- Scroll infinito — os eventos mais recentes primeiro; os mais antigos carregam à medida que faz scroll.
- Painel de detalhes — clique em qualquer linha para ver todos os metadados, o ID do pedido, o IP e o user agent.
- Atualizar — obtém os eventos mais recentes sem perder a seleção de filtros. Os filtros e o evento aberto refletem-se no URL, por isso qualquer vista pode ser partilhada.
Quem pode ver#
O acesso à página é controlado por dois critérios:
- Direito — a funcionalidade audit-logs tem de estar ativada para a organização (plano Enterprise).
- Permissão — a função do utilizador tem de incluir
org:view_audit_logs. A função predefinida Acesso total inclui-a por predefinição; os Owners têm-na sempre.
Os membros sem esta permissão veem uma página de "sem acesso" em vez da cronologia. Os membros de uma organização sem este direito veem um paywall.
Se o seu plano Enterprise expirar
Os registos de auditoria fazem parte do mesmo direito ao nível de RBAC. Os eventos anteriores permanecem na base de dados, mas a página fica oculta e os endpoints de leitura devolvem 403 até o plano ser reativado.
Resistência a adulterações#
Os registos de auditoria não são apenas um registo — são efetivamente difíceis de alterar a posteriori.
- Append-only ao nível da base de dados. A migração que instala a tabela executa
REVOKE UPDATE, DELETE, TRUNCATEna função da API. Qualquer caminho de código futuro — bug, novo endpoint, até injeção SQL — é rejeitado pelo Postgres antes de conseguir alterar uma linha. - Sequência monotónica. Cada linha inclui uma coluna
seqestritamente crescente. Um auditor que percorra a sequência consegue detetar eliminações através de lacunas.
Isto é suficiente para controlos do tipo SOC 2. Não protege contra um atacante com credenciais diretas da base de dados de produção — posturas mais robustas (função de proprietário separada, espelho WORM) estão disponíveis mediante pedido.
Retenção#
Os eventos de auditoria são mantidos indefinidamente por predefinição. Janelas de retenção personalizadas — normalmente 1, 3 ou 7 anos — estão disponíveis no Enterprise. Contacte-nos se precisar de uma política de retenção específica para conformidade ou questionários de segurança.
O que não está abrangido#
Alguns limites deliberados da v1 a ter em conta:
- Emissão em best-effort, não transacional. A emissão transacional está no roadmap de curto prazo. O evento de auditoria é escrito depois da ação que descreve — não dentro da mesma transação da base de dados. Em casos raros de falha (uma ação é concluída com sucesso e depois a inserção de auditoria falha), a ação pode acontecer sem um evento correspondente.
- Alguns tipos de ação ainda não estão ligados. Alterações de pertença a motores, ligar / atualizar / desligar integrações, edições de configuração do modelo, alterações de subscrição de faturação e operações de conteúdo em massa (upload CSV,
createMany/updateMany/deleteMany) ainda não produzem eventos. O vocabulário de ações está reservado para que apareçam nas categorias de filtro existentes assim que forem ligadas. - As leituras não são auditadas. Ver o próprio registo de auditoria, consultar registos de pedidos do motor ou descarregar um glossário não produz eventos. Apenas as ações que alteram o estado o fazem.
- Ainda não há exportações. Os dados de auditoria são apresentados através do dashboard. Exportação CSV, webhook SIEM e espelho S3 estão no roadmap — diga-nos se precisar deles.
- Não existe vista por motor. Todos os eventos de auditoria da organização aparecem numa única cronologia. Filtre por tipo de alvo ou ID do alvo para restringir.
- Não há live tail. A lista é atualizada a pedido ou quando clica em Atualizar — não existe stream WebSocket.
