Em resumo: a ISO 27001 e o TISAX afetam os servidores web sobretudo através de três requisitos: as vulnerabilidades têm de ser reconhecidas e tratadas, os prestadores de serviços, como fornecedores de alojamento e agências, têm de ser geridos, e os incidentes de segurança precisam de um procedimento regulado. Uma situação como o PHP2Shell é um teste prático para qualquer SGSI. Quem documenta de forma rastreável a avaliação, o patch e o reinício tem uma boa base para a próxima auditoria. Um certificado ou selo não substitui o patch.
O que são a ISO 27001 e o TISAX, em dois parágrafos
A ISO/IEC 27001 descreve os requisitos de um sistema de gestão da segurança da informação, abreviadamente SGSI. Trata-se de um ciclo ordenado: avaliar riscos, definir medidas, executá-las, verificá-las e melhorá-las. A edição atual, de 2022, contém no Anexo A um catálogo de 93 medidas em quatro temas. Quais delas se aplicam, decide-o a empresa com base na sua avaliação de risco e regista-o na declaração de aplicabilidade.
O TISAX é o mecanismo de auditoria e de intercâmbio difundido na indústria automóvel. É gerido pela ENX Association; a base é o catálogo de requisitos ISA, que a ENX mantém e a VDA (associação alemã da indústria automóvel) publica. Prestadores de auditoria independentes realizam uma avaliação (assessment), cujo âmbito depende da necessidade de proteção e vai de verificações documentais a visitas no local. Segundo a ENX, os resultados são atribuídos como selos, são válidos por três anos e só são partilhados com parceiros selecionados através do portal da ENX.
ISO 27001 no servidor web: que requisitos se aplicam?
Um servidor web raramente é um capítulo próprio no SGSI. Aparece em vários pontos, e é precisamente aí que surgem lacunas. A visão geral seguinte ordena em termos gerais os temas mais importantes. Não substitui a consulta da sua própria declaração de aplicabilidade.
| Tema no SGSI | O que significa no servidor web | Comprovativo que ajuda na auditoria |
|---|---|---|
| Inventário de ativos | Cada site, cada servidor, cada versão do PHP está registado | Lista atualizada com operador, versão, responsável |
| Tratamento de vulnerabilidades técnicas | Alertas como o PHP2Shell são avaliados e tratados | Ticket com avaliação, decisão, data do patch |
| Relações com fornecedores | O fornecedor de alojamento e a agência têm obrigações de segurança claras | Contrato, repartição de tarefas, confirmação escrita do estado dos patches |
| Registo e monitorização | Os registos do servidor web são conservados e analisados | Regra de conservação, exemplo de uma análise |
| Gestão de incidentes | A suspeita é comunicada, avaliada e encerrada | Registo de incidentes, lições aprendidas |
| Gestão de configuração | As definições do PHP e do servidor web estão fixadas | Configuração de referência e verificação de desvios |
No TISAX aplicam-se temas comparáveis, porque o catálogo ISA está harmonizado com outras normas importantes. Além disso, alguns objetivos de auditoria, como a proteção de protótipos, exigem especial cuidado com sistemas através dos quais parceiros trocam dados. Também podem ser portais baseados em PHP.
O PHP2Shell como teste prático do SGSI
A 21/10/2026, o projeto PHP publicou as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Para o PHP 8.1 e anteriores já não há atualizações oficiais. Um SGSI que funcione deve, nesta situação, desencadear uma cadeia que mais tarde se possa comprovar.
- Entrada: quem recebeu o alerta, quando, e onde está registado?
- Avaliação: que sistemas são afetados? Isso pressupõe um inventário atualizado, veja Saber o que está a correr.
- Decisão: patch, medida provisória ou desligamento temporário, com fundamentação e o nome da pessoa que decide.
- Execução: estado do pacote, reinício de todos os processos PHP, verificação. No caso de backports da distribuição, conta o changelog do pacote e não o número de versão apresentado; como o comprovar, mostra-o Verificar corretamente a versão do PHP e o estado dos patches.
- Fornecedores: confirmação escrita do fornecedor de alojamento de que o patch foi aplicado e houve reinício.
- Verificação posterior: procura de sinais de comprometimento desde 17/10/2026, porque um patch não desfaz intrusões anteriores.
Como transformar esta cadeia pontual num procedimento permanente, descrevem-no Gestão de vulnerabilidades para PME e Gestão de patches como processo.
Fragilidades frequentes na documentação
Na prática, o comprovativo raramente falha por causa da técnica, mas por lacunas na cadeia. É típico um site que um departamento opera com uma agência e que falta no inventário. Igualmente frequentes são contratos de alojamento sem qualquer indicação sobre a rapidez com que as atualizações de segurança são instaladas e se os clientes são informados.
Outro clássico: o ticket do patch está fechado, mas ninguém reiniciou os processos PHP. Formalmente o ponto está concluído, tecnicamente o código antigo continua a correr. Um bom comprovativo contém por isso não só «atualização instalada», mas também o reinício e uma verificação posterior.
Torna-se difícil também com sistemas que não podem receber o patch de imediato, por exemplo uma aplicação no PHP 8.1. Aqui um SGSI não exige milagres, mas uma decisão consciente: que medidas provisórias se aplicam, quem aceitou o risco remanescente e até quando está planeada a mudança? Uma aceitação de risco escrita, com data de validade, é claramente melhor na auditoria do que um sistema antigo que continua em silêncio. Igualmente importantes são os registos. A imprensa especializada e autores especializados aconselharam, após o PHP2Shell, a conservar os registos do servidor a partir de 20/10/2026. Se a sua regra de conservação o permite e se os registos estão no fornecedor de alojamento ou consigo, deve ficar esclarecido antes do próximo incidente e não durante ele.
Se a sua empresa também estiver abrangida pela NIS2, estes requisitos reforçam-se. Os traços gerais estão em NIS2 e segurança de servidores web. Isto é informação geral, não aconselhamento jurídico.
Um certificado ou selo descreve o estado de um sistema de gestão no momento da auditoria. Não protege nenhum servidor individual de uma nova vulnerabilidade. O decisivo é que o procedimento funcione de facto numa emergência.
Como ajuda concretamente a PHP SOS?
- Registamos os seus servidores web e instalações PHP de modo a que se encaixem no inventário do seu SGSI.
- Aplicamos patches e documentamos com o nosso serviço de patches PHP: estado do pacote, reinício, verificação, com data e comprovativos.
- Formulamos as perguntas a fornecedores de alojamento e agências e avaliamos as suas respostas para a sua gestão de fornecedores.
- Entregamos aos responsáveis do seu SGSI os factos técnicos. A avaliação no sistema de gestão e a auditoria ficam consigo e com a sua entidade de auditoria.
Conclusão
A ISO 27001 e o TISAX não exigem um servidor web em particular, mas um tratamento rastreável do mesmo. O PHP2Shell mostra se o inventário, o tratamento de vulnerabilidades e a gestão de fornecedores funcionam em conjunto. Quem comprova de forma limpa a cadeia de entrada, avaliação, patch, reinício e verificação posterior tem não só a auditoria, mas sobretudo o servidor sob controlo.
Perguntas frequentes
O site da empresa faz parte do âmbito de uma ISO 27001?
Depende de como a sua empresa definiu o âmbito. Se o site trata dados de clientes, está ligado a sistemas internos ou é operado por um prestador de serviços, há muitos motivos para o incluir ou, pelo menos, para o abranger através da gestão de fornecedores.
O TISAX é um certificado?
A ENX Association fala de uma avaliação (assessment) por prestadores de auditoria independentes, cujos resultados são atribuídos como selos TISAX. Segundo a ENX, os selos são válidos por três anos e são partilhados de forma direcionada com parceiros através do portal da ENX, não são públicos.
Depois do PHP2Shell, tenho de informar o meu auditor?
Não existe uma obrigação geral nesse sentido. O seu SGSI deve, porém, documentar como avaliou e tratou a vulnerabilidade. Esta documentação é normalmente consultada na próxima auditoria.
Qual é a versão atual da ISO 27001?
A edição de referência é a ISO/IEC 27001:2022. O seu Anexo A organiza as medidas em quatro temas: organizacional, relativo às pessoas, físico e tecnológico.