Em resumo: Quem quer mudar de fornecedor de alojamento após um incidente de segurança deve primeiro preservar as provas e esclarecer o incidente, depois transferir apenas dados verificados para um sistema novo e só então terminar o contrato antigo. O novo fornecedor escolhe-se segundo critérios de segurança: processos de patch comprováveis, separação dos clientes, acesso aos registos, cópias de segurança e interlocutores claros. Mudar de fornecedor de alojamento faz sentido quando faltam confiança ou desempenho, mas não substitui uma limpeza.
Quando a confiança desapareceu
Depois do PHP2Shell, muitas empresas vivem pela primeira vez o seu fornecedor de alojamento sob pressão. Algumas obtiveram depressa uma informação clara sobre o estado do patch. Outras esperaram dias por uma resposta, receberam apenas fórmulas genéricas ou constataram que o seu site corria numa versão do PHP desatualizada. Se a isto se juntar um incidente, o desejo de mudar é compreensível.
Mudar de fornecedor de alojamento não é, porém, um passo da gestão do incidente, mas da reestruturação que vem depois. Quem o coloca na ordem errada leva, no pior dos casos, o atacante consigo e perde ao mesmo tempo os vestígios que mostram o que aconteceu.
A ordem certa na mudança
- Preservar os vestígios enquanto existem. Registos, ficheiros e base de dados do sistema antigo devem ficar numa cópia de segurança antes de se apagar ou rescindir seja o que for. Pergunte expressamente ao fornecedor antigo pelos registos de acesso e de erros a partir de 20 de outubro de 2026 e pelo respetivo período de conservação. Como proceder está descrito no artigo Preservar provas antes de reinstalar.
- Delimitar o incidente. Que sistemas estão afetados, que acessos foram usados, que dados estavam acessíveis? Disso dependem as obrigações de notificação e a questão do que pode levar consigo.
- Verificar as obrigações de notificação. Se puderem estar em causa dados pessoais, o prazo para uma eventual notificação nos termos do RGPD começa com o conhecimento do incidente, não com a mudança. Os antecedentes estão em Obrigação de notificação do RGPD: 72 horas.
- Montar o novo sistema de forma limpa. Versão do PHP suportada, pacotes atuais, configuração reforçada, antes de ser transferido o primeiro ficheiro.
- Transferir apenas o que foi verificado. Código de uma fonte limpa, base de dados e ficheiros multimédia depois de controlados.
- Alterar todas as credenciais. Base de dados, contas de administrador, SSH, FTP, chaves de API, incluindo as que estão em ficheiros de configuração.
- Comutar e observar. Alteração do DNS e, a seguir, durante algum tempo, monitorização mais apertada.
- Terminar o contrato antigo. Só quando os registos e as cópias de segurança estiverem guardados e a nova operação estiver estável.
Não rescinda o contrato antigo antes de ter os registos e as cópias de segurança em seu poder. Com o fim do contrato, o fornecedor pode apagar dados de que precisa para seguradoras, autoridades ou para o seu próprio apuramento.
O que não deve levar consigo
Seria cómodo copiar simplesmente o diretório web completo ou uma imagem do servidor. É precisamente isso que, após um incidente, é arriscado. As webshells disfarçam-se de ficheiros inofensivos, as backdoors escondem-se em ficheiros de configuração como .htaccess ou .user.ini, e o código introduzido pode estar em conteúdos da base de dados.
Transfira por isso o código da aplicação a partir de uma fonte limpa, por exemplo o pacote do fabricante na versão adequada ou o seu sistema de controlo de versões. Os ficheiros multimédia leve-os sem ficheiros executáveis, e a base de dados depois de verificar conteúdos suspeitos e novas contas de administrador. O que foi encontrado no sistema antigo ajuda nesta verificação.
Pense também em tudo o que, além do site, está junto do fornecedor antigo. Caixas de correio, entradas DNS, certificados e redirecionamentos esquecem-se facilmente na mudança. Reduza o tempo de validade das entradas DNS alguns dias antes da comutação, para que a alteração chegue depressa aos visitantes. Se o correio eletrónico também se muda, planeie a mudança das caixas de correio em separado, porque também aí podem estar afetadas credenciais depois de um incidente.
Escolher o novo fornecedor de alojamento pela segurança
O preço e o espaço de armazenamento constam de qualquer proposta. As perguntas de segurança decisivas, tem de as fazer normalmente você mesmo. A lista seguinte ajuda na comparação:
| Critério | Pergunta ao fornecedor | Porque conta |
|---|---|---|
| Processo de patch | Como e em que quadro são aplicadas e reiniciadas as atualizações de segurança do PHP? | O PHP2Shell mostrou como é importante um processo comprovável |
| Comprovativo | Recebo, a pedido, uma confirmação escrita do estado do patch? | Base para a sua própria documentação |
| Versões do PHP | Que ramos são oferecidos e durante quanto tempo? | Ramos antigos sem atualizações são um risco permanente |
| Separação | Cada site corre com utilizador próprio e processo PHP próprio? | Limita os danos se um vizinho for atacado |
| Registos | Tenho acesso aos registos de acesso e de erros e durante quanto tempo são conservados? | Sem registos não há esclarecimento |
| Cópias de segurança | Com que frequência, durante quanto tempo, separadas do servidor web, com teste de restauro? | Recuperação após um incidente |
| Contacto de emergência | Como contacto uma pessoa competente num incidente? | O tempo é o fator mais escasso numa emergência |
| Subcontratação de tratamento de dados | Existe um contrato nos termos do RGPD e uma lista de subcontratantes? | Obrigatório com dados pessoais |
Um modelo para a pergunta sobre o estado do patch está no guia Perguntar ao fornecedor de alojamento pelo estado do patch. Serve também para comparar fornecedores antes de fechar o contrato.
Será outro modelo de operação a melhor resposta?
Por vezes o problema está menos no fornecedor de alojamento do que no modelo de operação. Quem opera um servidor próprio sem manutenção regular fica muitas vezes melhor servido com uma oferta gerida e bem acompanhada. Inversamente, uma empresa com TI própria pode ganhar mais controlo sobre os momentos dos patches se gerir ela mesma. A ponderação está descrita no artigo Alojamento gerido ou servidor próprio?.
Independentemente do modelo, vale o seguinte: registe por escrito a divisão de tarefas. Quem aplica as atualizações do PHP, quem reinicia, quem verifica a aplicação, quem contacta quem numa emergência? No PHP2Shell, muitos atrasos surgiram precisamente neste ponto, porque cada lado pensava que o outro tratava do assunto.
Como ajuda concretamente a PHP SOS?
- Preservamos os registos e os dados do sistema antigo e esclarecemos o que aconteceu no incidente.
- Montamos o novo sistema com hardening e transferimos apenas conteúdos verificados, provenientes de fontes limpas.
- Avaliamos as propostas de novos fornecedores com base nos critérios de segurança e colocamos as perguntas certas.
- Num incidente em curso, trabalhamos no âmbito da nossa resposta a incidentes, até o incidente estar concluído e documentado.
Perguntas frequentes
Devo mudar de fornecedor de alojamento logo depois de uma intrusão?
Não de imediato. Primeiro é preciso preservar os vestígios, delimitar o incidente e esclarecer a causa. Uma mudança precipitada pode levar código malicioso consigo e destruir provas junto do fornecedor antigo.
A culpa foi do fornecedor de alojamento se o meu site foi atacado através do PHP2Shell?
Depende do contrato e do momento. No alojamento partilhado, as atualizações do PHP são em regra da responsabilidade do fornecedor; em servidores próprios, do operador. Os patches surgiram a 21 de outubro de 2026; se e quando foram aplicados só se esclarece com comprovativos. Para questões de responsabilidade, consulte aconselhamento jurídico.
Que dados posso levar para o novo fornecedor de alojamento?
Apenas conteúdos verificados: a base de dados depois de verificada quanto a código introduzido, ficheiros multimédia sem ficheiros executáveis e código de uma fonte limpa, como o pacote do fabricante ou o seu sistema de controlo de versões. Não deve transferir sem verificação imagens completas do servidor nem diretórios web do sistema comprometido.
Tenho de envolver a proteção de dados depois de um incidente?
Se puderem estar em causa dados pessoais, pode existir uma obrigação de notificação nos termos do RGPD, em regra no prazo de 72 horas. Junto do novo fornecedor de alojamento precisa ainda de um contrato de subcontratação de tratamento de dados. Esclareça isto com o seu encarregado da proteção de dados; isto não constitui aconselhamento jurídico.