Log de Auditoria
Log de auditoria
O Chinaski mantém várias trilhas lado a lado: uma trilha de auditoria de quem mudou o quê, um event log operacional, um log de autenticação, mais build logs e histórico de configurações. Apenas admin em todos os casos, então tudo aqui é para administradores do site.
A trilha de auditoria
Cada mutação de conteúdo (criar, atualizar ou apagar páginas, posts, blocos, documentos, categorias, mídia, temas, usuários, configurações, formulários, itens de navegação e mais) é registrada com o autor (o nome de usuário logado), a ação, o tipo e o ID da entidade, uma linha curta de detalhe e um timestamp. Operações de backup (restauração, push, erros) também aparecem ali.
Você pode navegar por ela na entrada de auditoria da área de admin. As entradas são paginadas de cinquenta em cinquenta, e você pode fazer busca de texto livre em detalhes e nomes, ou filtrar por autor, ação, tipo de entidade, ID da entidade ou qualquer combinação. A página também mostra a idade da entrada mais antiga, ou seja, quanto histórico você realmente tem. Uma exportação em CSV baixa o conjunto atualmente filtrado.
Limites honestos: a trilha de auditoria registra o que aconteceu, mas não é um cofre à prova de adulteração: é uma tabela simples no banco de dados. Textos de detalhe com mais de 4000 caracteres são truncados.
O event log
Mensagens operacionais (avisos, erros, notificações) vão para o event log. Ele é exibido na página Health da área de admin, paginado de cinquenta em cinquenta, com um filtro de nível: avisos mais erros, ou apenas erros.
Sinta-se à vontade para limpá-lo quando ficar barulhento: um controle na página Health apaga entradas com mais de 30 dias por padrão, ou tudo, se você escolher. Limpar o log é, por si só, registrado na trilha de auditoria, então a limpeza não fica invisível.
Log de autenticação
O resultado de cada tentativa de login (sucesso, falha ou bloqueio por conta suspensa ou bloqueio de IP) é registrado com o nome de usuário, o endereço IP e o timestamp.
- Uma visão por usuário (o histórico de login de qualquer conta) fica na página de cada usuário na área de admin.
- A página Health mostra as últimas 100 entradas de autenticação.
- Falhas repetidas de um mesmo IP disparam bloqueios crescentes: 60 segundos após 5 falhas consecutivas, 5 minutos após 10 e 30 minutos após 20. Taxas de falha sustentadas geram um alerta no event log.
Retenção
Entradas antigas são removidas automaticamente de forma contínua, aproximadamente a cada 15 minutos:
| Trilha | Mantido |
|---|---|
| Trilha de auditoria | últimas 50.000 entradas |
| Log de autenticação | últimas 10.000 entradas |
| Event log | últimas 5.000 entradas |
| Revisões de configurações | últimos 50 snapshots |
| Build log | últimos ~100 builds concluídos |
Tokens de redefinição de senha expiram após 7 dias, e sessões de usuário expiradas são limpas. Se você precisa que os registros sobrevivam a essa retenção, use a exportação em CSV ou um log de segurança externo (abaixo) antes que as entradas sejam descartadas.
Histórico de configurações
Cada salvamento em configurações tira um snapshot de todas as configurações não secretas para um histórico de revisões antes da gravação. Você pode revisar e restaurar a partir dos últimos snapshots na aba Settings → History. Valores secretos (senha SMTP, segredos de webhook, segredo de cliente SSO, chave do Turnstile, segredo do Spaces) são excluídos dos snapshots: eles são sempre armazenados criptografados e nunca aparecem em texto simples no histórico.
Log de segurança estruturado
Para fins forenses, o Chinaski também emite linhas JSON estruturadas para eventos de segurança de alto sinal: login bem-sucedido, falha de login, bloqueio e suspensão de login, login SSO, limpeza de sessões obsoletas, limitação de taxa de registro e acessos a honeypots. Elas vão para o journal do sistema (journald em uma instalação systemd padrão: use journalctl -u chinaski@1 para lê-las).
Se você definir o destino do log de segurança (Settings → Security) como um caminho de arquivo, esses eventos também são anexados ali, como JSON separado por quebras de linha, com file mode 0600, de modo que um registro sobreviva mesmo se o próprio banco de dados for comprometido. Aponte-o para um local excluído de qualquer limpeza automatizada do diretório da instância, se essa durabilidade importar para você.