Como Proteger um Banco de Dados WordPress: Endurecimento, Criptografia e Proteção Contínua

Todo site WordPress roda em um banco de dados. Ele contém suas postagens, seus usuários, suas senhas, as configurações dos seus plugins e os pedidos dos seus clientes.

Arquivos no servidor contêm seu tema e suas imagens. O banco de dados contém todo o resto.

É por isso que é a primeira coisa que um invasor sério ataca.

Injeção de SQL ainda é um vetor de ataque comum no WordPress. Invasores enviam entradas criadas através de formulários de login, caixas de pesquisa ou campos de plugins vulneráveis que enganam o banco de dados para executar comandos que não deveria.

Uma injeção bem-sucedida pode criar novas contas de administrador, redirecionar seus visitantes para sites de spam, injetar código malicioso no seu conteúdo ou apagar o banco de dados completamente.

A maioria desses ataques não faz barulho. Código injetado e contas de administrador maliciosas podem ficar quietas no banco de dados por semanas antes que algo visível dê errado.

Trabalhei com sites que tinham todos os plugins atualizados, autenticação de dois fatores ativada e senhas fortes em todos os lugares. Eles ainda foram atingidos através de uma conexão de banco de dados que ninguém havia bloqueado.

É sobre isso que este tutorial trata.

Você passará por 13 etapas para proteger seu banco de dados: as primeiras oito endurecem o próprio banco de dados e fecham os caminhos de ataque mais comuns, e as últimas cinco configuram a camada de backup, monitoramento e recuperação que protege você quando o endurecimento sozinho não é suficiente.

Ao final, você terá proteção proativa e contínua do banco de dados em vigor.

Aqui estão os principais pontos:

• As 13 etapas cobrem duas camadas: endurecimento do banco de dados (Etapas 1-8) e configuração de backup, monitoramento e recuperação (Etapas 9-13). Você precisa de ambas, porque o endurecimento sozinho não protege você após uma violação ter passado.
• Algumas violações de banco de dados não mostram sintomas visíveis por dias ou semanas, então o monitoramento via plugin Activity Log é tão importante quanto o endurecimento de segurança.
• Um arquivo de backup não criptografado em armazenamento em nuvem é uma segunda cópia do seu banco de dados inteiro. Qualquer pessoa que ganhe acesso a essa conta de armazenamento pode lê-lo sem nunca tocar no seu site ativo — a criptografia na Etapa 9 fecha essa lacuna.
• Faça um backup completo do site antes de iniciar a Etapa 1. Várias etapas fazem alterações diretas no banco de dados que são difíceis de desfazer sem um.
• Salve sua URL de recuperação de desastres do Duplicator em algum lugar fora do WordPress durante a Etapa 11. É a única ferramenta que permite o retorno quando seu painel está completamente bloqueado, mas apenas se você a armazenou antes que as coisas dessem errado.
• A seção de solução de problemas cobre seis cenários de falha, incluindo um caminho de recuperação completo para quando seu site está sem resposta e seu painel do WordPress não carrega.

Sumário

O que é um Banco de Dados WordPress?

O WordPress armazena todo o conteúdo dinâmico do seu site em um banco de dados. Quando alguém visita seu site, o WordPress consulta o banco de dados, extrai o conteúdo relevante e monta a página dinamicamente. Se você alterar uma configuração, publicar um post ou adicionar um usuário, isso vai para o banco de dados.

Uma instalação nova do WordPress cria 12 tabelas principais. Veja o que as mais importantes contêm:

• wp_posts: cada post, página, revisão e tipo de post personalizado no seu site
• wp_users: todas as contas de usuário, nomes de usuário e senhas com hash
• wp_usermeta: funções de usuário, permissões e preferências da conta
• wp_options: configurações de todo o site, configurações de plugins e dados do tema ativo
• wp_comments: todos os comentários de visitantes e seus metadados

Plugins e temas adicionam suas próprias tabelas além das padrão do WordPress. Uma loja WooCommerce adiciona tabelas para pedidos, produtos e dados de clientes. Um plugin de formulário adiciona tabelas para cada envio.

Quanto mais você constrói no WordPress, mais seu banco de dados cresce.

Por que Você Precisa Proteger Seu Banco de Dados WordPress

O banco de dados é um ponto de falha que todo hacker sério almeja. Tudo o que vale a pena roubar ou destruir está lá.

Injeção de SQL ainda é um método de ataque comum. Um hacker envia entradas cuidadosamente elaboradas através de um formulário de login, uma caixa de pesquisa ou um campo de plugin vulnerável. Se a entrada não for devidamente higienizada, o banco de dados a trata como um comando e a executa.

A partir daí, o invasor pode ler e exportar todo o seu banco de dados, criar novas contas de administrador, injetar conteúdo malicioso em seus posts ou excluir tudo de uma vez.

Seu arquivo wp-config.php é o outro alvo principal. Ele contém o nome do seu banco de dados, nome de usuário e senha em texto simples. Um invasor que obtém esse arquivo não precisa do seu login do WordPress. Ele se conecta diretamente ao banco de dados e ignora o WordPress completamente.

O que pega a maioria dos proprietários de sites de surpresa é o quão silenciosas são essas violações. Contas de administrador maliciosas e código injetado geralmente não quebram nada visível imediatamente. Quando você percebe os redirecionamentos de spam ou o conteúdo adulterado, o invasor já está com acesso há semanas.

É por isso que o endurecimento da segurança sozinho não é suficiente. Você também precisa de uma maneira de detectar alterações e se recuperar de um backup limpo quando algo passar.

O Que Você Precisa Antes de Começar

Antes de fazer qualquer alteração, certifique-se de ter tudo o que está abaixo em vigor. Pular a etapa de backup em particular já prejudicou muitas pessoas em etapas como a alteração do prefixo da tabela. Não vale a pena o risco.

• Acesso ao painel de controle de hospedagem. Você precisará fazer login no cPanel, MyKinsta, no painel do WP Engine ou em qualquer painel que seu host forneça. Várias etapas envolvem o phpMyAdmin, que geralmente é encontrado na seção Bancos de Dados do seu painel de controle.
• Acesso FTP ou Gerenciador de Arquivos. Você precisará de uma maneira de visualizar e editar arquivos em seu servidor, especificamente o wp-config.php. A maioria dos hosts fornece um gerenciador de arquivos diretamente no painel de controle.
• Suas credenciais atuais do banco de dados. Abra o wp-config.php e localize os valores DB_NAME, DB_USER, DB_PASSWORD e DB_HOST. Você os referenciará nas Etapas 3 a 5.
• Um backup completo do site feito antes de você começar. Use um plugin de backup como o Duplicator ou crie um backup manual. Certifique-se de ter cópias dos arquivos do seu site e do banco de dados. Algumas dessas etapas fazem alterações diretas no seu banco de dados, e você precisa de um ponto de restauração limpo se algo der errado.
• Acesso administrativo ao WordPress. Você precisará estar logado como administrador para várias etapas deste tutorial.

Como Proteger Seu Banco de Dados WordPress

Vou te dar 13 etapas fáceis para proteger seu banco de dados WordPress antes que um ataque aconteça.

As primeiras oito etapas fortalecem o próprio banco de dados e fecham os caminhos de ataque mais comuns. As etapas 9 a 13 configuram a camada de backup, monitoramento e recuperação que protege você quando o fortalecimento sozinho não é suficiente.

Aqui está uma visão geral do que você fará:

• Etapa 1: Altere o nome de usuário e o ID de usuário administrador padrão. Remova as duas credenciais mais visadas em ataques automatizados ao WordPress.
• Etapa 2: Altere o prefixo da tabela do banco de dados padrão. Substitua o prefixo `wp_` previsível que os scripts de injeção SQL são criados para ter como alvo.
• Etapa 3: Crie um usuário de banco de dados dedicado com privilégios limitados. Reduza seu usuário de banco de dados a apenas as quatro permissões que o WordPress realmente precisa.
• Etapa 4: Desabilite conexões remotas ao banco de dados. Feche o acesso externo ao seu banco de dados no nível de configuração do MySQL.
• Etapa 5: Proteja seu arquivo wp-config.php. Bloqueie o arquivo que armazena suas credenciais de banco de dados em texto simples.
• Etapa 6: Habilite SSL para conexões de banco de dados. Criptografe dados em trânsito entre o WordPress e o MySQL se eles forem executados em servidores separados.
• Etapa 7: Adicione um Firewall de Aplicação Web. Filtre tentativas de injeção de SQL antes que elas cheguem ao seu banco de dados.
• Etapa 8: Limpe tabelas de plugins abandonados. Remova tabelas órfãs deixadas por plugins desinstalados que incham seu banco de dados e carregam vulnerabilidades sem correção.
• Etapa 9: Configure backups criptografados. Ative a criptografia AES-256 para que seus arquivos de backup não possam ser lidos sem sua chave, mesmo que alguém os baixe diretamente.
• Etapa 10: Agende backups automáticos do banco de dados. Remova o erro humano da sua rotina de backup para que você sempre tenha um ponto de restauração recente, independentemente de quão ocupado as coisas fiquem.
• Etapa 11: Armazene backups fora do local. Mantenha cópias fora do seu servidor para que uma violação no nível do host não possa apagar suas opções de recuperação.
• Etapa 12: Monitore alterações no banco de dados. Capture a criação de contas de administrador não autorizadas e alterações não autorizadas em tempo real.
• Etapa 13: Teste uma restauração do banco de dados. Confirme se o seu plano de recuperação funciona antes que você precise dele.

Etapa 1: Altere o Nome de Usuário e ID de Administrador Padrão

O WordPress cria um usuário com o nome de usuário “admin” e um ID de 1 durante a instalação. Esses dois valores são incorporados em quase todos os scripts automatizados de força bruta e injeção de SQL que visam o WordPress. Alterá-los remove dois dos alvos mais previsíveis em seu banco de dados.

Aqui está um método fácil para alterar seu nome de usuário de administrador sem tocar no banco de dados:

1. Crie uma nova conta de administrador diretamente no WordPress
2. Faça login como esse novo usuário
3. Exclua a conta de administrador original
4. Reatribua o conteúdo para a nova conta

Se você precisar fazer a alteração diretamente no banco de dados, veja como fazer isso via phpMyAdmin.

Faça login no phpMyAdmin a partir do seu painel de hospedagem, selecione seu banco de dados WordPress na barra lateral esquerda e clique na guia SQL. Execute as seguintes consultas uma de cada vez:

UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';

UPDATE wp_users SET ID = 101 WHERE ID = 1;

UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;

UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;

Todas as quatro consultas são necessárias. Seu ID de usuário aparece em wp_users, wp_posts e wp_usermeta, portanto, atualizar apenas a primeira tabela deixa referências quebradas nas outras duas.

Um aviso antes de executar qualquer coisa: faça um backup completo primeiro. Um erro de digitação em uma consulta SQL direta pode quebrar seu site de maneiras difíceis de desfazer sem um.

Eu gosto de usar o Duplicator para isso. Ele tem predefinições de backup fáceis para iniciantes que fornecem cópias rápidas do seu banco de dados ou do site inteiro.

O Duplicator tem as melhores ferramentas de restauração de todos os plugins de backup que experimentei. Você verá como eles funcionam mais adiante neste tutorial!

Para confirmar que a alteração funcionou, saia do WordPress e faça login novamente com seu novo nome de usuário. Seu painel deve carregar exatamente como antes.

Etapa 2: Altere o Prefixo Padrão das Tabelas do Banco de Dados

O WordPress nomeia todas as tabelas do banco de dados com um prefixo wp_ por padrão. Scripts de injeção de SQL que visam o WordPress são construídos em torno disso.

Alterar o prefixo para algo imprevisível não impedirá um invasor sofisticado por si só, mas remove seu site da piscina de alvos que as ferramentas automatizadas atingem na primeira passagem.

Existem duas maneiras de fazer isso: usando um plugin de segurança (recomendado para a maioria dos usuários) ou fazendo as alterações manualmente via phpMyAdmin.

Método do plugin (recomendado)

O método do plugin é a escolha mais segura para iniciantes, pois ele lida com dados serializados automaticamente. Algumas tabelas de opções de plugin armazenam o prefixo dentro de dados PHP serializados, e uma pesquisa e substituição SQL bruta pode quebrar esses dados se não for tratada com cuidado.

O All-In-One Security inclui uma ferramenta de prefixo de banco de dados com salvaguardas integradas.

Instale o plugin escolhido, navegue até a seção de ferramentas de banco de dados e execute a alteração de prefixo a partir daí. O plugin atualizará o wp-config.php, renomeará todas as tabelas e lidará com referências de dados serializados em uma única passagem.

Método manual

Se preferir alterar seu prefixo de tabela de banco de dados manualmente, siga estas etapas.

Primeiro, abra o wp-config.php via FTP ou Gerenciador de Arquivos e atualize a linha $table_prefix para seu novo prefixo. Use apenas letras, números e underscores:

$table_prefix = 'site82_';

Segundo, faça login no phpMyAdmin, selecione seu banco de dados WordPress e abra a guia SQL. Execute uma consulta RENAME TABLE para cada tabela em seu banco de dados:

RENAME TABLE wp_posts TO site82_posts;

RENAME TABLE wp_users TO site82_users;

Repeat this for all 12 core tables and any tables added by plugins.

Em seguida, atualize a tabela wp_options, que contém linhas que ainda referenciam o prefixo antigo na coluna option_name:

UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';

Por fim, atualize a tabela wp_usermeta pela mesma razão:

UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';

Verifique seus plugins ativos após executar essas consultas. Alguns plugins armazenam o prefixo em suas próprias linhas de dados e precisam que essas também sejam atualizadas. Se algo parecer quebrado, seu backup pré-alteração é a maneira mais rápida de voltar a um estado funcional.

Para confirmar que tudo funcionou, visite a página inicial do seu site e, em seguida, saia e faça login novamente no seu painel do WordPress. Ambos devem funcionar exatamente como antes.

Etapa 3: Crie um Usuário de Banco de Dados Dedicado com Privilégios Limitados

Quando o WordPress é instalado, a maioria das configurações de hospedagem cria um usuário de banco de dados com acesso administrativo total a todo o banco de dados. O WordPress geralmente precisa apenas de quatro permissões básicas para funcionar: SELECT, INSERT, UPDATE e DELETE. Cada permissão além disso pode criar um risco extra.

Se um invasor explorar uma vulnerabilidade de plugin e obter acesso às suas credenciais de banco de dados, privilégios limitados são a diferença entre eles lerem seus dados e eles excluírem todo o seu banco de dados.

Existem duas maneiras de abordar isso: restrinja os privilégios do usuário de banco de dados existente ou crie um novo usuário dedicado com apenas as permissões que o WordPress precisa.

Restringindo privilégios via phpMyAdmin

Faça login no phpMyAdmin, clique em Contas de Usuário no topo, encontre seu usuário de banco de dados do WordPress na lista e clique em Editar Privilégios. Desmarque tudo, exceto SELECT, INSERT, UPDATE e DELETE. Role para baixo e clique em Ir para salvar.

Criando um novo usuário dedicado via SQL

Se preferir uma configuração limpa, execute estas consultas na guia SQL do phpMyAdmin:

CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';

FLUSH PRIVILEGES;

If you create a new user, update your wp-config.php file with the new credentials:

define('DB_USER', 'wpuser_secure');

define('DB_PASSWORD', 'StrongPasswordHere');

Uma nota importante: alguns plugins e atualizações principais do WordPress precisam de permissões CREATE ou ALTER para adicionar ou modificar tabelas de banco de dados durante a instalação. Se a instalação de um plugin falhar após esta etapa, redefina temporariamente essas permissões, conclua a instalação e, em seguida, revogue-as novamente.

Se você executa vários sites WordPress no mesmo servidor, use um banco de dados completamente separado e um usuário de banco de dados separado para cada um. Se um site for comprometido, essa contenção impede que o invasor alcance os outros.

Para confirmar que as permissões estão definidas corretamente, crie um rascunho de postagem no WordPress, salve-o e exclua-o. Se todas as três ações forem bem-sucedidas, seu usuário de banco de dados tem o que precisa e nada mais.

Etapa 4: Desativar Conexões Remotas de Banco de Dados

Na maioria das configurações do WordPress, o WordPress e o MySQL são executados no mesmo servidor. Não há razão para permitir que IPs externos se conectem diretamente ao seu banco de dados. Deixar o acesso remoto aberto significa que um invasor pode tentar se autenticar no MySQL de qualquer lugar da internet, contornando completamente o WordPress.

Existem dois lugares para fechar isso, e você deve verificar ambos.

Configuração do MySQL

Se você gerencia seu próprio servidor (VPS ou hospedagem em nuvem), localize seu arquivo de configuração do MySQL. Ele geralmente é encontrado em /etc/mysql/mysql.conf.d/mysqld.cnf. Encontre a linha bind-address e confirme se ela está definida como 127.0.0.1:

bind-address = 127.0.0.1

Se estiver definida como 0.0.0.0, altere para 127.0.0.1 e reinicie o MySQL para aplicar a alteração:

sudo systemctl restart mysql

Nome do host do usuário do banco de dados

Mesmo com o MySQL vinculado ao localhost, vale a pena confirmar se o seu usuário do banco de dados do WordPress também está restrito a conexões locais no nível do usuário.

No phpMyAdmin, clique em Contas de Usuário e encontre seu usuário do banco de dados do WordPress. A coluna Host deve mostrar localhost ou 127.0.0.1. Se você vir um curinga %, esse usuário pode se conectar de qualquer endereço IP.

Exclua quaisquer usuários definidos como % e recrie-os com localhost como host:

DROP USER 'wpuser'@'%';

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';

FLUSH PRIVILEGES;

Usuários de hospedagem compartilhada

Se você estiver em hospedagem compartilhada e não tiver acesso ao arquivo de configuração do MySQL, verifique seu painel de controle. No cPanel, procure por MySQL Remoto na seção Bancos de Dados.

Remova quaisquer endereços IP listados lá. Isso é o equivalente a fechar o acesso remoto no nível da hospedagem.

Para confirmar que o acesso remoto está desabilitado, seu usuário do banco de dados do WordPress deve mostrar localhost como o único host permitido na tela Contas de Usuário do phpMyAdmin.

Etapa 5: Proteja seu arquivo wp-config.php

Seu arquivo wp-config.php contém o nome do seu banco de dados, nome de usuário, senha e chaves de autenticação em texto simples. Se um invasor conseguir ler este arquivo, ele terá tudo o que precisa para se conectar diretamente ao seu banco de dados. É um dos primeiros arquivos visados em qualquer ataque ao WordPress.

Aplique as três proteções a seguir juntas. Cada uma fecha uma exposição diferente.

1. Mova o arquivo acima da raiz da web

O WordPress procura automaticamente um diretório acima da raiz se não conseguir encontrar o wp-config.php no local, então você pode mover o arquivo sem alterar nenhuma configuração. Se a raiz do seu site for /public_html, mova o wp-config.php para /home/username/. Use FTP ou o Gerenciador de Arquivos do seu host para fazer isso.

Isso funciona na maioria das configurações de hospedagem padrão, mas alguns provedores de hospedagem gerenciada não permitem. Se o seu host restringir o acesso acima da raiz da web, pule para as próximas duas proteções.

2. Bloqueie o acesso web via .htaccess

Adicione a seguinte regra ao seu arquivo .htaccess, que está localizado no diretório raiz do seu WordPress. Isso informa ao Apache para negar todas as solicitações do navegador para o arquivo diretamente, mesmo que alguém conheça o caminho:

<Files wp-config.php>

order allow,deny

deny from all

</Files>

Se o seu host usar uma configuração mais recente do Apache, use esta versão em vez disso:

<Files "wp-config.php">

Require all denied

</Files>

3. Defina as permissões de arquivo como 400 ou 440

Permissões de arquivo controlam quais usuários no servidor podem ler, escrever ou executar um arquivo. Definir wp-config.php como 400 significa que apenas o proprietário do arquivo pode lê-lo. Definir como 440 estende o acesso de leitura ao grupo do servidor também, o que algumas configurações de hospedagem exigem.

No Gerenciador de Arquivos do seu host, clique com o botão direito em wp-config.php, selecione Alterar Permissões e insira 400. Via FTP, a maioria dos clientes permite que você clique com o botão direito no arquivo e defina as permissões diretamente.

Para confirmar que as três proteções estão em vigor, tente acessar seu_dominio.com/wp-config.php em um navegador. Você deverá receber um erro 403 Forbidden.

Etapa 6: Habilitar SSL para Conexões de Banco de Dados

Quando o WordPress e o MySQL são executados no mesmo servidor, os dados entre eles permanecem locais e nunca cruzam uma rede. Mas se o seu banco de dados for executado em um servidor separado (comum em configurações de VPS, hospedagem em nuvem ou ambientes gerenciados), esses dados viajam por uma conexão de rede. Sem SSL, eles viajam em texto simples, incluindo credenciais de login e tokens de sessão.

Se você estiver em hospedagem compartilhada padrão com WordPress e MySQL no mesmo servidor, pode pular esta etapa. Se você estiver em uma arquitetura multisservidor ou em uma configuração de nuvem onde seu banco de dados é executado separadamente, não pule.

Verifique primeiro com seu provedor de hospedagem

Muitos provedores de hospedagem gerenciada lidam com SSL para conexões de banco de dados automaticamente. Kinsta, WP Engine e Cloudways impõem conexões de banco de dados criptografadas no nível da infraestrutura. Verifique a documentação do seu provedor antes de fazer quaisquer alterações manuais - você já pode estar coberto.

Habilitar SSL no servidor MySQL

Se você gerencia seu próprio servidor, adicione o seguinte ao seu arquivo mysqld.cnf para configurar certificados SSL e exigir conexões criptografadas:

[mysqld]

ssl-ca = /path/to/ca.pem

ssl-cert = /path/to/server-cert.pem

ssl-key = /path/to/server-key.pem

require_secure_transport = ON

Reinicie o MySQL após salvar o arquivo.

Diga ao WordPress para usar SSL

Adicione a seguinte linha ao seu arquivo wp-config.php, acima da linha que diz /* Isso é tudo, pare de editar! */:

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Isso informa à conexão de banco de dados do WordPress para exigir SSL ao se conectar ao MySQL.

Para confirmar que o SSL está ativo, verifique o log de erros do seu servidor MySQL após o WordPress fazer sua próxima conexão de banco de dados. Você deverá ver o SSL listado como ativo para o usuário do aplicativo.

Etapa 7: Adicione um Firewall de Aplicação Web

O endurecimento do banco de dados nas etapas anteriores reduz significativamente sua superfície de ataque. Mas não elimina o risco de um plugin vulnerável se tornar um ponto de entrada para injeção de SQL.

Um Firewall de Aplicativo Web (WAF) fica na frente do seu site e filtra solicitações maliciosas antes que elas cheguem ao WordPress ou ao seu banco de dados.

Para segurança do banco de dados, o trabalho mais importante de um WAF é reconhecer padrões de injeção de SQL em entradas de formulário, parâmetros de URL e cabeçalhos de solicitação e bloqueá-los antes que sejam executados. Ele também bloqueia IPs e bots maliciosos, reduz tentativas de login por força bruta e mantém um log de solicitações bloqueadas que você pode revisar se algo parecer suspeito.

Três opções de WAF funcionam bem para a maioria dos sites WordPress:

• Wordfence: Instala-se diretamente como um plugin do WordPress. O nível gratuito inclui um WAF com proteção básica contra injeção de SQL. O nível premium adiciona inteligência de ameaças em tempo real e atualizações de regras mais rápidas.
• Sucuri: Oferece um scanner baseado em plugin e um WAF no nível do DNS. A opção no nível do DNS roteia todo o tráfego através da rede da Sucuri antes que ele chegue ao seu servidor, o que fornece proteção mais forte, mas requer um plano pago.
• Cloudflare: Um WAF no nível do DNS com um nível gratuito que cobre filtragem básica de ataques. Os planos pagos adicionam regras mais granulares e melhor cobertura para ataques na camada de aplicação.

Se precisar ajustar as regras de firewall após a configuração, teste quaisquer alterações em uma cópia de staging do seu site antes de aplicá-las à produção. Uma regra mal configurada pode bloquear tráfego legítimo — formulários de contato, fluxos de checkout e ações administrativas são vítimas comuns.

Um WAF é uma camada complementar, não um substituto para as etapas de fortalecimento que você já concluiu. Pense nele como o filtro que pega o que escapa de todo o resto.

Etapa 8: Limpe Tabelas de Plugins Abandonados

Quando você desinstala um plugin no WordPress, suas tabelas de banco de dados geralmente ficam para trás. O WordPress não as exclui automaticamente, e a maioria dos plugins não faz uma limpeza após a remoção.

Com o tempo, essas tabelas órfãs incham seu banco de dados e criam um risco de segurança oculto: uma tabela de um plugin com uma vulnerabilidade conhecida de injeção de SQL ainda é explorável, mesmo após o plugin ter sido removido.

Para identificar tabelas órfãs, use um plugin como WP-Optimize ou Advanced Database Cleaner. Ambos escaneiam seu banco de dados e sinalizam tabelas que não correspondem a nenhum plugin atualmente ativo.

Instale um, execute um scan de otimização do banco de dados e revise os resultados antes de excluir qualquer coisa.

Você também pode revisar a lista de tabelas manualmente no phpMyAdmin. Selecione seu banco de dados WordPress na barra lateral esquerda e percorra a lista de tabelas. Tabelas que não correspondem ao seu $table_prefix atual ou que carregam o nome de um plugin que você não usa mais são candidatas à remoção.

No entanto, crie um backup fresco do banco de dados primeiro. Excluir uma tabela é permanente, e algumas tabelas que parecem abandonadas ainda estão ativamente em uso.

Tenha especial cautela com quaisquer tabelas associadas ao WooCommerce, plugins de formulário como Gravity Forms ou WPForms, e plugins de associação ou LMS. Estes frequentemente armazenam registros de transações, envios de formulários e dados de usuários que você pode precisar, mesmo que o plugin não esteja mais ativo.

Cruze cada tabela candidata com sua lista de plugins ativos antes de removê-la. Se você não tem certeza a que uma tabela pertence, pesquise o nome da tabela junto com a palavra "WordPress" para identificar o plugin que a criou.

Para excluir uma tabela órfã confirmada no phpMyAdmin, selecione a tabela, clique em Operações e role para baixo para clicar em Excluir Tabela. Alternativamente, execute-a através da aba SQL:

DROP TABLE old_plugin_table_name;

Para confirmar que a limpeza ocorreu sem problemas, execute um teste funcional rápido no seu site após remover as tabelas. Verifique sua página inicial, envie um formulário de teste se tiver um, e saia e entre novamente.

Etapa 9: Configure Backups Criptografados

As etapas acima reduzem as chances de um ataque bem-sucedido ao seu banco de dados. Esta etapa é o que tira você de um.

A maioria das pessoas pensa em backups como uma ferramenta de recuperação de desastres. Dependendo de como você os cria, eles também podem ser um risco de segurança.

Um arquivo de backup não criptografado em uma pasta do Google Drive é uma segunda cópia de todo o seu banco de dados. Qualquer pessoa que ganhe acesso a essa conta de armazenamento pode baixá-lo, abri-lo e ler todos os registros de usuários, hashes de senhas e pedidos de clientes sem nunca tocar no seu site ativo. A criptografia torna esse arquivo inútil sem sua chave.

É por isso que sempre criptografo backups com o Duplicator. Este plugin permite ativar a criptografia AES-256 em cada backup.

AES-256 é o mesmo padrão de criptografia usado por instituições financeiras e sistemas governamentais. Com ele ativado, seu arquivo de backup fica completamente ilegível sem a senha, mesmo que alguém baixe o arquivo diretamente da sua conta de armazenamento.

Duas coisas a fazer antes de salvar: anote esta senha e guarde-a em um gerenciador de senhas. Se você a perder, seus backups criptografados se tornarão permanentemente inacessíveis. Mantenha uma cópia em algum lugar fora do WordPress.

Etapa 10: Agende Backups Automáticos do Banco de Dados

Um backup criptografado só protege você se você realmente tiver um quando algo der errado.

Backups manuais falham na prática porque a vida acontece. Você se lembra de executar um antes de uma grande atualização, talvez após uma migração, ocasionalmente quando algo parece errado. O que você não faz é executar um todos os dias, sem falhar.

Essa lacuna é a diferença entre um rollback limpo e um confuso. Se um invasor criar uma conta de administrador maliciosa ou injetar conteúdo malicioso hoje e você não perceber por duas semanas, você precisará de um backup de antes que isso acontecesse.

Uma programação diária oferece um ponto de restauração limpo que nunca tem mais de 24 horas. Um hábito de backup manual oferece o que você executou por último.

No seu painel do WordPress, navegue até Duplicator Pro » Agendar Backup e clique em Adicionar Novo. Dê um nome à programação de backup e escolha um modelo. Por exemplo, você pode criar um modelo de backup de banco de dados.

Escolha um local de armazenamento. O Duplicator suporta backups locais, bem como armazenamento em nuvem popular como Duplicator Cloud, Google Drive, Amazon S3 e Google Cloud.

Defina a frequência com base na atividade do seu site.

Backups diários do banco de dados são a escolha certa para qualquer site que publica conteúdo regularmente, processa pedidos ou tem contas de usuário ativas. Semanalmente funciona para sites estáticos ou de baixo tráfego onde o banco de dados muda com pouca frequência.

Etapa 11: Armazene Backups Fora do Local com Duplicator Cloud

Um backup armazenado no mesmo servidor do seu site não é um backup de verdade. Se o seu servidor for comprometido, ransomware criptografar seus arquivos ou seu host sofrer uma falha catastrófica, você perderá seu backup no mesmo momento em que perder seu site.

Armazenamento off-site é o que separa "Perdi tudo" de "Restaurei em 20 minutos."

Duplicator Cloud é a opção de armazenamento de backup do WordPress mais simples. Foi construído para backups do WordPress, integra-se diretamente ao Duplicator Pro e não requer autenticação de API.

Se você preferir uma alternativa, o Duplicator Pro também suporta Google Drive, Amazon S3, Dropbox, OneDrive e qualquer provedor de armazenamento compatível com S3, incluindo Cloudflare R2, Backblaze B2 e DigitalOcean Spaces.

Depois que seu armazenamento estiver conectado, edite sua programação de backup e defina-o para enviar cópias para seu provedor de armazenamento conectado automaticamente após cada execução.

Mantenha no mínimo uma cópia em seu host e uma cópia em armazenamento em nuvem off-site. Para sites críticos ou aqueles que lidam com dados de clientes, uma terceira cópia baixada localmente adiciona outra camada de proteção.

Se precisar restaurar, o Duplicator Pro pode puxar diretamente do seu armazenamento em nuvem conectado sem precisar baixar o arquivo para o seu servidor primeiro.

Navegue até Duplicator Pro » Backups. Encontre um backup na nuvem e clique em Restaurar. Isso é mais rápido que um download manual e funciona mesmo que suas cópias de backup locais tenham sido perdidas.

Mesmo que você não tenha acesso ao seu painel wp-admin, você pode restaurar um backup na nuvem. Seu painel Duplicator Cloud permite reverter instantaneamente qualquer backup remotamente, até mesmo backups parciais do banco de dados!

Etapa 12: Monitore Mudanças no Banco de Dados com Activity Log

O movimento mais comum que um invasor faz após obter acesso ao banco de dados é criar uma conta de administrador maliciosa. Isso lhes dá uma maneira persistente de retornar ao seu site, mesmo depois que o ponto de entrada original for fechado e limpo.

Sem monitoramento, essa conta pode ficar inativa por semanas. Com um plugin de log de atividades, ela aparece no momento em que é criada.

Activity Log registra cada ação em seu site WordPress com um carimbo de data/hora e endereço IP. Você acompanhará sem esforço logins de usuários, criação de novas contas, alterações de função e alterações de configurações.

Para segurança do banco de dados, os eventos que mais importam são novos usuários que você não criou, escalonamentos de função onde uma conta de nível inferior de repente ganha acesso de administrador e tentativas de login de endereços IP desconhecidos.

Activity Log está incluído gratuitamente com o Duplicator Elite. Assim que seu plano estiver ativo, baixe o plugin e instale-o no WordPress. Ele começará a rastrear imediatamente.

Verifique o log regularmente em busca de três coisas.

1. Qualquer nova conta de usuário que você não reconheça.
2. Qualquer usuário existente cuja função foi alterada sem sua ação.
3. Qualquer login de um endereço IP que não corresponda às localizações da sua equipe.

Qualquer um desses pode indicar uma violação ativa ou uma comprometimento que ocorreu dias ou semanas atrás.

Activity Log permite que você filtre o log por usuário, tipo de ação ou intervalo de datas e exporte os resultados. Isso é útil tanto para auditorias de rotina quanto para resposta a incidentes, onde você precisa identificar exatamente quando uma alteração não autorizada ocorreu.

Etapa 13: Teste a Restauração do Seu Banco de Dados

A maioria das pessoas descobre que seu backup está quebrado exatamente quando está sob a maior pressão para se recuperar rapidamente. Um teste leva apenas alguns minutos. Uma restauração falha durante um incidente ativo custa muito mais.

O recurso de staging de um clique do Duplicator Pro permite que você restaure um backup para uma URL de staging separada sem tocar no seu site ativo. Em Duplicator Pro » Staging, crie um novo site de staging.

Selecione um backup recente do site completo como modelo. Escolha um esquema de cores de administrador exclusivo para diferenciar seus sites de staging e ativos.

Assim que o Duplicator terminar de criar seu site de staging, você terá uma réplica completa do seu site ativo. Este é um campo de testes eficaz para realizar testes de restauração.

Faça o upload de um backup para a página Importar Backups do Duplicator. Percorra o site de staging após a conclusão da restauração.

Verifique sua página inicial, faça login no painel do WordPress, abra alguns posts e confirme se as configurações do seu plugin estão corretas. Se algo estiver faltando ou quebrado, você encontrou o problema agora, em vez de durante uma recuperação real.

Para confirmar que seu teste de restauração foi bem-sucedido, seu site de staging deve carregar limpo, com todo o conteúdo, usuários e configurações intactos da data do backup.

Solução de problemas de segurança de banco de dados

Mesmo quando você segue cada etapa cuidadosamente, as coisas podem dar errado. Aqui estão os pontos de falha mais comuns e como superá-los.

Seu site fica em branco após alterar o prefixo da tabela

O que você vê: Uma tela branca ou um erro genérico de PHP imediatamente após alterar o prefixo da tabela.

Por que acontece: A causa mais comum é uma referência de tabela perdida. Alguns plugins armazenam o prefixo antigo dentro de dados PHP serializados nas tabelas de opções ou usermeta. Se uma consulta SQL bruta atualizou os nomes das tabelas, mas perdeu essas referências internas, o WordPress não consegue encontrar o que procura.

Como corrigir: Restaure um backup imediatamente. É exatamente por isso que esse backup é inegociável antes de iniciar essas etapas de segurança do banco de dados.

Assim que você voltar a um estado funcional, use um plugin como All-In-One Security para fazer a alteração do prefixo. As ferramentas deles lidam com dados serializados automaticamente e são muito menos propensas a deixar referências quebradas para trás.

WordPress não consegue se conectar ao banco de dados após editar wp-config.php

O que você vê: Uma mensagem "Erro ao estabelecer uma conexão com o banco de dados" no front-end ou uma tela branca em branco.

Por que acontece: Um erro de digitação em um dos valores de credenciais do banco de dados é a causa mais comum. Mover o wp-config.php para um local que seu servidor não consegue encontrar é a segunda causa mais comum. Permissões de arquivo definidas de forma muito restritiva (como 000) também podem impedir que o WordPress leia o arquivo.

Como corrigir: Conecte-se via FTP ou Gerenciador de Arquivos e abra o wp-config.php diretamente. Verifique se DB_NAME, DB_USER, DB_PASSWORD e DB_HOST estão todos corretos e correspondem exatamente ao que está no seu painel de hospedagem. Se você moveu o arquivo, confirme se ele está um diretório acima da raiz do WordPress, não mais fundo. Defina as permissões para 400 ou 440 se elas foram alteradas para qualquer outra coisa.

Um plugin para de funcionar após você restringir os privilégios do banco de dados

O que você vê: Um plugin gera um erro, falha ao salvar configurações ou exibe um aviso relacionado ao banco de dados após você concluir a Etapa 3.

Por que acontece: Alguns plugins precisam de permissões CREATE ou ALTER para instalar ou atualizar suas próprias tabelas de banco de dados. Uma vez que essas permissões são revogadas, o plugin não consegue fazer as alterações estruturais de que precisa.

Como corrigir: Conceda temporariamente as permissões CREATE e ALTER ao seu usuário de banco de dados via phpMyAdmin. Atualize ou reinstale o plugin, deixe-o concluir sua configuração e, em seguida, revogue essas permissões novamente. Esta é uma parte normal da manutenção de uma configuração de banco de dados de privilégio mínimo.

Nada está funcionando: Caminho de recuperação completo

Se o seu site não responder, seu painel do WordPress estiver travado e você não conseguir acessá-lo pelos meios normais, use uma das opções de recuperação de desastres do Duplicator.

Para backups armazenados na Nuvem Duplicator, você pode restaurá-los remotamente. Seu site voltará a ficar online sem nenhum problema adicional.

Antes que os desastres aconteçam, você também pode definir um backup como ponto de recuperação no WordPress. Salve o URL de recuperação de desastres em um local seguro.

Se o seu site não estiver funcionando, cole este URL em um navegador da web e siga as instruções.

Se você não configurou um backup de desastres ou backups na nuvem, entre em contato com a linha de suporte de emergência do seu provedor de hospedagem. A maioria dos hosts gerenciados mantém seus próprios snapshots no nível do servidor. Para sites sob ataque ativo com malware se espalhando em tempo real, Wordfence e Sucuri oferecem serviços pagos de resposta a emergências.

Perguntas Frequentes (FAQs)

Você Fortaleceu seu Banco de Dados. Veja Como Mantê-lo Assim.

Se você trabalhou em todas essas etapas, seu banco de dados está em melhor forma do que a maioria dos sites WordPress em execução no momento.

O trabalho não acabou, no entanto. A segurança do banco de dados não é uma configuração única. É uma prática de manutenção.

Revise seu registro de atividades mensalmente e procure por qualquer coisa que não corresponda à sua própria atividade. Teste uma restauração trimestralmente — as conexões de armazenamento expiram, as senhas de criptografia são perdidas e a única maneira de saber se seus backups são utilizáveis é usá-los.

Reavalie as permissões de usuário do seu banco de dados após qualquer instalação de novo plugin, pois alguns plugins reescalam permissões durante atualizações sem torná-lo óbvio. E se você migrar para um novo host, refaça as Etapas 4 e 5 do zero. As configurações de acesso remoto e as permissões de arquivo nem sempre são transferidas como você esperaria.

Após concluir esta configuração, crie um backup apenas do banco de dados e rotule-o claramente como sua linha de base pós-fortalecimento. Se você precisar investigar uma violação meses depois, essa linha de base lhe dará um ponto de referência limpo para comparar.

Mais de 1,5 milhão de profissionais de WordPress usam o Duplicator Pro para lidar com backups, migrações, staging e recuperação de desastres. É a ferramenta por trás de arquivos criptografados AES-256, armazenamento off-site Duplicator Cloud, restaurações de um clique, recuperação apenas do banco de dados e URLs de recuperação de desastres que o trazem de volta mesmo quando o próprio WordPress não carrega.

Se este tutorial ajudou, estes guias também valem a pena ser marcados.

• Como Otimizar Seu Banco de Dados WordPress
• Aqui estão as etapas de reparo do banco de dados do WordPress que fiz pessoalmente (sem necessidade de desenvolvedor)
• Manutenção do Banco de Dados do WordPress: O Que Fazer Semanalmente, Mensalmente e Trimestralmente
• O WordPress é Seguro? Revelando a Verdade
• Como Proteger Seu Site Contra Hackers (Guia Definitivo de Segurança)
• Como Recuperar um Site WordPress Invadido (9 Dicas de Especialistas)