Em resumo: um plano de emergência de TI para servidores web define previamente quem decide na emergência, quem se pode contactar, que sistemas podem estar afetados e que passos se seguem, por que ordem. Quem quer elaborar um plano de emergência de TI não precisa de um manual espesso, mas de poucas páginas atualizadas, acessíveis mesmo sem TI a funcionar. A situação em torno do PHP2Shell é uma boa ocasião para o fazer agora.
Porque é que um plano de emergência poupa tempo e danos
Na emergência, as primeiras horas perdem-se muitas vezes à procura: quem tem acesso ao fornecedor de alojamento? Onde estão as cópias de segurança? Quem decide se a loja fica offline? Quem tem de ser informado? Um plano de emergência responde a estas perguntas antes, com calma.
O PHP2Shell mostrou como o tempo pode ser curto. A 20/10/2026, o php.net anunciou os patches, a 21/10, às 16:00 (hora alemã), foram publicados, e o BSI recomendou a atualização imediata ou a desativação temporária. As empresas com plano sabiam a quem telefonar e que servidores verificar. As outras tiveram primeiro de descobrir onde é que o PHP corre sequer.
Elaborar um plano de emergência de TI: os componentes
Um plano utilizável para servidores web inclui estas partes:
1. Funções e decisões. Quem dirige na emergência, quem substitui, quem pode desligar sistemas, quem fala para o exterior? Registe nomes e substituições.
2. Lista de contactos. Interlocutores internos, fornecedor de alojamento, agência, prestador de serviços de TI, encarregado da proteção de dados, aconselhamento jurídico, seguro ciber com número da apólice, autoridade de controlo da proteção de dados competente, o ponto de contacto central para cibercrime (Zentrale Ansprechstelle Cybercrime) do seu estado federado alemão. Esta lista tem de estar disponível em papel.
3. Inventário de sistemas. Cada site, cada loja e cada portal com servidor, fornecedor de alojamento, modo de operação, versão PHP, aplicação, responsável e tipo de dados tratados.
4. Regras de decisão. Em que condições retiramos um sistema da rede? Quem pode decidir isso? O que vale à noite e ao fim de semana?
5. Procedimentos. Sequências de passos curtas para casos típicos: vulnerabilidade crítica conhecida, suspeita de intrusão, site desfigurado, dados exfiltrados, extorsão.
6. Vias de notificação. Quem verifica um dever de notificação nos termos do Art. 33 do RGPD, se possível no prazo de 72 horas após o conhecimento? Quem notifica o BSI em caso de obrigação NIS2? Quem informa a seguradora?
7. Recuperação. Onde estão as cópias de segurança, quem as pode repor, quanto tempo demora, quando foi testado pela última vez?
Exemplo: procedimento “vulnerabilidade crítica do PHP”
Assim pode ser um procedimento como o que foi necessário no PHP2Shell:
| Passo | Quem | Resultado |
|---|---|---|
| Avaliar o aviso (php.net, BSI) | Responsáveis de TI | sistemas afetados segundo o inventário |
| Instalar a atualização, reiniciar todos os workers | Administrador ou prestador de serviços | Comprovativo com nível dos pacotes e hora dos processos |
| Onde não é possível atualizar: medidas provisórias ou retirar da rede | A direção decide | decisão documentada |
| Preservar registos, verificar vestígios | Administrador ou forense | Achado ou nenhum achado |
| Em caso de achado: iniciar o procedimento de incidente | Direção de emergência | verificar vias de notificação |
O importante aqui: um patch fecha a vulnerabilidade, mas não remove software malicioso introduzido antes. Por isso, a busca de vestígios faz parte fixa do procedimento.
Defina durante quanto tempo se conservam os registos do servidor web e onde ficam fora do servidor. No PHP2Shell, a imprensa especializada recomendou guardar os registos a partir de 20/10/2026. Quem só guarda os registos durante poucos dias não consegue aplicar tais recomendações.
Prevenção que torna o plano eficaz
Um plano vale tanto quanto os pressupostos que tem por trás. Verifique se existem cópias de segurança segundo a regra 3-2-1 e se estão testadas; veja Cópias de segurança segundo a regra 3-2-1. Esclareça por escrito com o fornecedor de alojamento e a agência quem assume o quê em caso de vulnerabilidades críticas. Mantenha credenciais de acesso para emergências guardadas em segurança mas acessíveis, por exemplo num cofre de palavras-passe protegido com acesso de emergência.
Prepare além disso modelos de texto: informação interna, comunicação aos clientes, aviso numa página de manutenção estática. Há indicações em Comunicação de crise após um ataque.
Exercitar e manter atualizado
Um plano que nunca foi exercitado contém quase sempre lacunas. Simule uma vez por ano um cenário, por exemplo “vulnerabilidade crítica do PHP numa sexta-feira à tarde”, e anote onde falha. Para começar basta um teste simples: uma segunda pessoa consegue, sem ajuda da primeira, contactar o fornecedor de alojamento, repor uma cópia de segurança e colocar o site em modo de manutenção? Se não, falta algo no plano, geralmente um acesso, um número de telefone ou uma descrição. São precisamente essas lacunas que os exercícios devem tornar visíveis, antes de a situação ser a sério. Atualize o plano após cada exercício e após cada alteração relevante. Como enquadramento metodológico servem a proteção de base das TI (IT-Grundschutz) do BSI e a norma BSI 200-4 sobre gestão da continuidade da atividade.
As questões jurídicas, por exemplo sobre deveres de notificação, o plano não as esclarece de forma definitiva. Assegura que as pessoas certas são envolvidas a tempo. Esta página é informação geral e não constitui aconselhamento jurídico.
Como ajuda concretamente a PHP SOS?
- Elaboramos consigo o inventário de sistemas dos seus servidores web, incluindo modo de operação e versão PHP.
- Escrevemos os procedimentos técnicos para cenários típicos e articulamo-los com o fornecedor de alojamento e a agência.
- Realizamos um exercício e incorporamos as conclusões no plano.
- Na emergência, assumimos a parte técnica através da resposta a incidentes, se desejar com o apoio de um contrato de manutenção de segurança.
Perguntas frequentes
Que extensão deve ter um plano de emergência de TI?
Tão curto quanto possível, tão detalhado quanto necessário. Para servidores web bastam muitas vezes poucas páginas com contactos, lista de sistemas, regras de decisão e procedimentos. Mais importante do que a extensão é que esteja atualizado e seja encontrado na emergência.
Onde guardo o plano de emergência?
Em pelo menos um local acessível mesmo sem TI a funcionar, por exemplo impresso ou num dispositivo separado. Um plano que esteja apenas no servidor afetado ou na rede bloqueada da empresa não ajuda na emergência.
Com que frequência se deve verificar o plano?
Pelo menos uma vez por ano e após cada alteração relevante, como a mudança de fornecedor de alojamento ou software novo. Faz sentido um exercício curto em que se simula um cenário.
O BSI disponibiliza modelos?
O BSI trata a gestão de emergências no âmbito da proteção de base das TI (IT-Grundschutz) e na norma BSI 200-4 sobre gestão da continuidade da atividade. Servem como enquadramento; para servidores web compensa uma versão concisa e prática.