# ISO 27001 e TISAX: o que afeta os servidores web

> ISO 27001 e TISAX no servidor web: que requisitos tocam em patches, fornecedores e incidentes e que comprovativos entram no dossiê após o PHP2Shell.

Fonte: https://phpsos.de/pt/blog/iso-27001-tisax-webserver/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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.

1. **Entrada:** quem recebeu o alerta, quando, e onde está registado?
2. **Avaliação:** que sistemas são afetados? Isso pressupõe um inventário atualizado, veja [Saber o que está a correr](https://phpsos.de/pt/blog/inventar-websites-server/).
3. **Decisão:** patch, medida provisória ou desligamento temporário, com fundamentação e o nome da pessoa que decide.
4. **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](https://phpsos.de/pt/php2shell/php-version-pruefen/).
5. **Fornecedores:** confirmação escrita do fornecedor de alojamento de que o patch foi aplicado e houve reinício.
6. **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](https://phpsos.de/pt/blog/schwachstellenmanagement-mittelstand/) e [Gestão de patches como processo](https://phpsos.de/pt/blog/patch-management-prozess/).

## 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](https://phpsos.de/pt/compliance/nis2/). Isto é informação geral, não aconselhamento jurídico.

> **Importante:**
> 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](https://phpsos.de/pt/leistungen/php-patch-service/): 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.

## Fontes

- [ENX Association: TISAX](https://www.enx.com/de-DE/TISAX/)
- [BSI: IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: avisos de segurança](https://www.php.net/)
- [PHP: versões suportadas](https://www.php.net/supported-versions.php)