Em resumo: Um contrato com um prestador de TI não deve mencionar a segurança apenas de passagem, mas regulá-la de forma concreta: quem atualiza que componentes, em que prazo e com que comprovativo, como se informa sobre falhas críticas, quem colabora num incidente, como os registos são conservados e os acessos geridos e o que acontece na saída. Esta página dá indicações gerais e não constitui aconselhamento jurídico; os contratos são verificados por um advogado.
A pergunta que o PHP2Shell colocou: quem é responsável?
Em 21 de outubro de 2026, às 16 h, hora alemã, o projeto PHP publicou os patches. O BSI (Gabinete Federal Alemão para a Segurança da Informação) recomendou a atualização imediata ou, onde isso não fosse possível, retirar temporariamente os servidores web da rede. Em muitas empresas começou depois não o trabalho, mas a procura da responsabilidade. A agência remeteu para o fornecedor de alojamento, o fornecedor de alojamento para o contrato, e no contrato dizia “manutenção por tempo despendido”.
Estas lacunas contratuais não são um caso isolado. Muitos contratos com agências e prestadores foram celebrados quando se tratava de construir um site, não da sua operação segura ao longo de anos. Uma falha crítica no runtime do PHP, que não afeta nem o CMS nem o código da aplicação, cai então facilmente entre todas as cadeiras.
O que um contrato com prestador de TI deve regular sobre segurança
A visão geral seguinte indica os pontos que se revelaram importantes na prática. Não substitui uma verificação jurídica, mas ajuda a reconhecer lacunas no contrato existente.
| Ponto de regulação | O que deve ficar registado | Relação com o PHP2Shell |
|---|---|---|
| Âmbito da prestação | Que camadas são tratadas: sistema operativo, runtime PHP, servidor web, CMS, plugins, código próprio | O runtime PHP faltava muitas vezes na enumeração |
| Prazos de atualização | escalonados por gravidade, com regra de exceção para emergências | falha crítica com CVSS v4.0 9,2 |
| Reinício e comprovativo | as atualizações só se consideram concluídas após o reinício de todos os processos, com prova escrita | ficheiros novos, por si só, não fecham a falha |
| Informação | notificação ativa em caso de falhas críticas, com avaliação e plano | muitos clientes tiveram de perguntar por si |
| Colaboração em incidentes | apoio na análise, preservação, recuperação, interlocutor | busca de vestígios após o patch |
| Registos | tipo, conservação, entrega a pedido | a imprensa especializada aconselhou a guardar registos a partir de 20/10 |
| Acessos | contas pessoais, autenticação de dois fatores, lista de todos os acessos | quem tinha, afinal, acesso? |
| Subcontratantes | quem mais está envolvido, informação em caso de mudança | o fornecedor do fornecedor de alojamento |
| Fim de vida do software | aviso com antecedência antes do fim do suporte, plano de migração | o PHP 8.2 termina a 31 de dezembro de 2026 |
| Saída | entrega de dados, documentação e acessos, retirada de direitos | mudança após um incidente |
Prazos e comprovativos: os pontos que mais contam
Os prazos são o cerne. Uma formulação como “em tempo útil” não ajuda em caso grave. Acorde prazos separados por gravidade e defina por que critério a gravidade é medida, por exemplo a classificação do fabricante ou do BSI. Para situações excecionais deve valer uma regra de emergência: quem está contactável, quem decide se um sistema é temporariamente retirado da rede e como é faturado o esforço adicional.
Igualmente importante é o comprovativo. No PHP2Shell, o número de versão apresentado dizia muitas vezes pouco, porque as distribuições e os fornecedores de alojamento aplicam correções como backport. Uma prova fiável indica o estado do pacote, o momento da instalação e o reinício de todos os processos PHP. Que indicações contam exatamente é descrito em Confirmação da atualização PHP do alojamento: como perguntar pelo estado do patch. Inclua estas indicações como conteúdo obrigatório no contrato.
Peça ao prestador uma matriz de tarefas para o contrato: uma linha por componente, uma coluna por tarefa, um nome em cada célula. As lacunas saltam logo à vista, muito antes do próximo aviso.
Acessos, subcontratantes e saída
Os prestadores precisam de acessos, e são precisamente estes um caminho de ataque frequente. Regule que cada pessoa recebe uma conta própria, que a autenticação de dois fatores é obrigatória onde a técnica o permita e que pode, a qualquer momento, pedir uma lista atualizada de todos os acessos. Os colaboradores do prestador que saiam têm de ser removidos de todos os sistemas em tempo útil.
Se o próprio prestador trabalhar com parceiros, por exemplo um centro de dados ou uma equipa forense especializada, deve saber-se. Se um desses parceiros tratar dados pessoais, acrescem obrigações de proteção de dados. Mais sobre isto no artigo Subcontratação de dados quando prestadores acedem a servidores.
A saída é o que mais se esquece na celebração do contrato. Registe que, no fim do contrato, dados, configuração, documentação e credenciais são entregues por completo, todos os acessos do prestador são retirados e isso é confirmado por escrito. Sobretudo após um incidente, uma mudança ordenada é de outro modo difícil.
Verificar contratos existentes: como proceder
Não tem de renegociar todos os contratos. Um procedimento pragmático chega para começar:
- Reunir todos os contratos com agências, fornecedores de alojamento e prestadores de TI que digam respeito a sites ou servidores.
- Comparar cada contrato com a tabela acima e assinalar os pontos em aberto.
- Abordar por escrito junto do prestador as lacunas mais importantes, começando pelo âmbito da prestação, os prazos e o comprovativo.
- Registar os resultados como acordo complementar e mandá-los verificar juridicamente.
- Integrar a matriz de tarefas no plano de emergência.
Para a administração, este passo é também uma questão de diligência. Quem regula claramente as responsabilidades e documenta as decisões está em melhor posição se mais tarde forem feitas perguntas. Antecedentes sobre isto em Responsabilidade da gerência por vulnerabilidades de segurança informática. A divisão típica de tarefas em servidores com assistência é descrita em Servidor gerido: esclarecer a responsabilidade.
Como ajuda concretamente a PHP SOS?
- Lemos os seus contratos e descrições de serviços existentes do ponto de vista técnico e assinalamos que componentes e tarefas faltam.
- Elaboramos uma matriz de tarefas para todos os sites e servidores, que pode acordar com os seus prestadores.
- Formulamos os requisitos técnicos de prazos, comprovativos e vias de comunicação, que o seu advogado pode incorporar no contrato.
- Onde ninguém é responsável, assumimos nós as tarefas através de um contrato de manutenção de segurança com âmbito claramente descrito.
Conclusão: Um bom contrato não evita uma falha de segurança, mas evita que, em caso grave, se perca tempo com a pergunta sobre a responsabilidade. Esta página é informação geral e não constitui aconselhamento jurídico.
Perguntas frequentes
Um prestador de TI tem de aplicar atualizações de segurança sem encomenda?
Depende do contrato. Sem regulação clara, é muitas vezes controverso se as atualizações fazem parte da prestação devida. Por isso, o contrato deve registar expressamente quem atualiza que componentes e em que prazo. Para a avaliação jurídica em cada caso é competente um advogado.
Preciso, além disso, de um contrato de subcontratação (AVV)?
Se o prestador tratar dados pessoais por conta de outrem ou lhes puder aceder, é em regra necessário um contrato de subcontratação nos termos do Art. 28 do RGPD. Não substitui o contrato de prestação de serviços, complementa-o. Esclareça-o com o seu encarregado da proteção de dados.
Que prazos para atualizações de segurança são habituais?
Não há valores fixos. Faz sentido um escalonamento por gravidade, por exemplo prazos separados para falhas críticas, graves e restantes. É importante que os prazos estejam por escrito e incluam uma regra de exceção para emergências como o PHP2Shell.
O que acontece aos acessos quando o contrato termina?
O contrato deve regulá-lo: devolução ou eliminação de dados, entrega de credenciais e documentação, retirada de todos os acessos do prestador e uma confirmação disso.