| Camada | O que captura | Ferramenta típica |
|---|---|---|
| Aplicação | Ações no wp-admin: login, edição, ativação de plugin | WP Activity Log, Simple History |
| Arquivo | Alteração em arquivos PHP via checksum e hash | All in One Security, Sucuri |
| Banco de dados | Escrita direta em wp_options e wp_users | WP-CLI, query monitor |
Legenda: a trilha de auditoria mostra ator, ação e horário lado a lado, o mínimo para reconstruir um incidente.
--- ## Por que o WordPress não audita mudanças por padrão O WordPress não nasce com auditoria de mudanças porque o core mira simplicidade, não conformidade. A instalação padrão guarda só revisões de post: não há registro de logins, de troca de papel de usuário nem de ativação de plugin, deixando 0 rastro dessas ações de alto risco. Em sites com um único dono isso raramente incomoda, mas numa operação com agência, freelancer e cliente no mesmo painel, a ausência de trilha vira ponto cego. A auditoria de mudanças preenche essa lacuna ao interceptar os hooks de ação do WordPress e gravar cada evento com ator, horário e valor anterior do campo. É essa camada extra, e não o core, que entrega a rastreabilidade que negócios e a LGPD exigem na prática do dia a dia. Quem gerencia papéis e permissões de usuário em equipe sente a falta primeiro, no dia do primeiro incidente. --- ## Passo a passo: Configurar a auditoria de mudanças em 5 etapas A configuração da auditoria de mudanças leva cerca de 30 minutos e cobre da escolha do plugin ao teste de retenção. As 5 etapas abaixo seguem a ordem que reduz retrabalho: primeiro o log de aplicação, depois a integridade de arquivo, por fim a validação. Nenhuma depende de código fora do padrão do WordPress. Cada etapa entrega uma camada da trilha de auditoria descrita no diagnóstico. Faça em ambiente de staging antes de produção sempre que possível, para não disparar alertas reais durante o teste. ### Passo 1: Instale um plugin de log de atividade Comece pela camada de aplicação instalando WP Activity Log ou Simple History. O WP Activity Log cobre mais de 100 tipos de evento (login, falha de login, edição de post, mudança de papel, ativação de plugin) e marca cada um com usuário, IP e data via . O Simple History é mais leve e gratuito, indicado para sites menores. Ative o plugin, abra o painel de log e confirme que o primeiro evento (a própria ativação) já aparece registrado com seu nome de usuário. ### Passo 2: Defina o que registrar e a retenção Ajuste o escopo para não afogar a auditoria de mudanças em ruído. Habilite eventos de alto valor: login e logout, falha de login, criação e exclusão de usuário, troca de papel, ativação ou desativação de plugin e edição de arquivo via editor do painel. Defina a retenção do log para no mínimo 90 dias, porque a maioria dos incidentes só é percebida semanas depois. Retenção curta apaga a evidência antes da detecção, o ponto cego mais comum que a gente vê no suporte da FULL. ### Passo 3: Ative a verificação de integridade de arquivo Cubra a camada de arquivo com checksum, que pega o que o log de aplicação não vê. O All in One Security e o Sucuri comparam o hash de cada arquivo PHP com um valor de referência e disparam alerta quando algo muda fora do painel, como um upload por FTP comprometido. Agende a varredura para rodar a cada 12 horas. Essa camada é o que detecta injeção de malware silenciosa, já que código malicioso quase nunca passa pelo wp-admin e por isso escapa do log de atividade puro. ### Passo 4: Exporte o log para fora do site Envie a auditoria de mudanças para um destino externo, porque log que mora só no banco do site some quando o site cai. Configure o plugin para exportar em CSV semanal ou enviar eventos para um syslog externo. Em sites de cliente, a gente também usa o WP-CLI para extrair o log via linha de comando e arquivar em storage separado. Esse passo garante que, mesmo com o painel inacessível após um ataque, a trilha de auditoria continue disponível para a investigação. ### Passo 5: Teste a trilha com uma mudança controlada Valide a auditoria de mudanças provocando um evento de teste e conferindo o registro. Crie um usuário de teste, troque o papel dele para administrador e desative um plugin não crítico. Abra o log e confirme que os três eventos aparecem com ator, horário e valor anterior. Depois faça uma alteração simulada em um arquivo de tema e veja se a varredura de integridade a sinaliza. Se algum evento não aparecer, o escopo do passo 2 está incompleto e precisa de ajuste. --- ## Erros comuns que cegam a auditoria de mudanças A auditoria de mudanças falha menos por falta de plugin e mais por configuração incompleta, e 3 erros respondem por boa parte dos casos. O primeiro é registrar tudo sem filtro: o log incha, fica lento e ninguém o lê. O segundo é manter a retenção padrão de 30 dias, curta demais para incidentes de descoberta tardia. O terceiro erro é confiar só no log de aplicação e ignorar a integridade de arquivo, deixando a porta do FTP sem vigilância. Há ainda um caso silencioso: mudanças feitas direto no banco via phpMyAdmin não passam pelos hooks do WordPress, então nenhum plugin de atividade as captura. Para fechar esse vão, combine o log de plugin com auditoria de logs no nível de servidor e com a varredura de checksum do passo 3, que cobre exatamente as escritas fora do painel. --- ## Como validar que a auditoria de mudanças está funcionando Uma auditoria de mudanças validada precisa passar em 4 checagens objetivas, não só estar instalada. Primeira: cada evento de teste do passo 5 aparece com ator, ação e horário completos. Segunda: a varredura de integridade detecta uma alteração de arquivo dentro do intervalo agendado de 12 horas. Terceira: o export externo gera um arquivo legível fora do site. Quarta: a retenção configurada bate com a janela real exibida no painel. Se as 4 passam, a trilha de auditoria reconstrói qualquer incidente das últimas semanas. Sites que mantêm essa rotina junto a um checklist de manutenção periódico reduzem o intervalo entre a mudança suspeita e a resposta efetiva. A gente vê no suporte da FULL que esse intervalo de detecção é o que mais pesa no prejuízo final de um site invadido. --- ## Por que centralizar a auditoria de mudanças no painel da FULL Gerenciar auditoria de mudanças em dezenas de sites avulsos custa caro em tempo e em licenças. O plano PRO da FULL sai por R$849 por mês e cobre até 10 sites, o que dá R$85 por site, com a camada All in One Security já incluída no bundle, sem licença extra de plugin de log premium. A gente vê no suporte da FULL que centralizar o monitoramento de mudanças e atualizações em um painel de gestão de sites único corta o tempo de resposta a incidentes, porque o gestor enxerga todos os logs de um lugar só. Como a FULL é a única CNA brasileira reconhecida pela CISA, o catálogo de vulnerabilidades que alimenta esses alertas vem da mesma fonte oficial. Conheça os planos da FULL. ---Parcialmente, sim, mas com lacunas. O WordPress guarda revisões de post nativamente e o servidor mantém logs de acesso, o que cobre parte das edições. Porém logins, troca de papel de usuário e ativação de plugin não ficam registrados sem um plugin de log como o WP Activity Log. Para uma trilha completa, a verificação de integridade de arquivo via WP-CLI ou checksum também é necessária. Sem plugin, a auditoria fica incompleta.
Porque os plugins de auditoria de mudanças escutam os hooks de ação do WordPress, e uma escrita direta no MySQL via phpMyAdmin não dispara nenhum hook. Quando alguém altera wp_options ou wp_users por SQL, o evento ocorre fora do ciclo de execução do PHP que o plugin monitora. Por isso a integridade de arquivo e o log no nível de servidor complementam o log de aplicação: juntos, eles fecham o vão que uma única camada deixa aberto.
O mínimo recomendado é 90 dias, e 180 dias para sites com obrigação de conformidade. Boa parte dos incidentes só é percebida semanas após a invasão, então uma retenção de 30 dias costuma apagar a evidência antes da detecção. Em sites sob LGPD, manter de 6 a 12 meses ajuda a demonstrar rastreabilidade. O custo de armazenar log por mais tempo é baixo perto do prejuízo de não conseguir reconstruir um incidente.
A auditoria de mudanças cria a trilha que comprova quem acessou e alterou dados pessoais, exigência prática da LGPD. Registrar criação de usuário, troca de papel e exportação de dados permite responder a um pedido de titular ou a um incidente com evidência datada. Sem esse log, o site não consegue demonstrar controle de acesso. A FULL, como CNA reconhecida pela CISA, trata essa rastreabilidade como parte da gestão básica, não como item opcional.
O impacto é pequeno quando o escopo é bem definido. Registrar todos os eventos possíveis, incluindo cada carregamento de página, infla o banco e pesa no desempenho. Limitar o log a eventos de alto valor (login, edição, ativação de plugin, mudança de papel) mantém o overhead abaixo do perceptível na maioria dos sites. Mover o log para uma tabela própria ou exportar para fora do banco, como mostra o passo 4, elimina quase todo o efeito sobre a velocidade.