# Saber o que está a correr: inventário de todos os sites e servidores

> Um inventário de TI de todos os sites e servidores: que dados incluir, como encontrar sistemas esquecidos e como manter a lista sempre atualizada.

Fonte: https://phpsos.de/pt/blog/inventar-websites-server/  
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:** um inventário de TI de servidores web é uma lista de todos os sites, portais, lojas e servidores com os dados de que se precisa de imediato perante um alerta de segurança: onde corre, com que versão e modo de operação do PHP, que aplicação, quem é o responsável e que dados seriam afetados. Sem esta lista, qualquer reação começa por procurar. Com ela, a comparação perante um alerta como o PHP2Shell demora minutos em vez de dias.

## A primeira pergunta foi: onde é que, na nossa empresa, corre PHP?

Quando o projeto PHP publicou os patches a 21/10/2026 e o BSI (Gabinete Federal Alemão para a Segurança da Informação) recomendou agir de imediato, a instrução era clara: atualizar o PHP, reiniciar todos os processos. Para muitas empresas, o primeiro passo não foi, ainda assim, a atualização, mas um inventário. O site principal era conhecido. Mas o portal de revendedores? A página de carreiras num outro fornecedor? A página de destino de uma campanha de há três anos? A wiki interna?

A imprensa especializada e os serviços de medição tornaram visível a dimensão do problema. A Palo Alto Networks (Unit 42) contou mais de 22,6 milhões de instâncias expostas e potencialmente vulneráveis. Entre elas haverá muitos sistemas em que os próprios operadores simplesmente já não pensam.

## O que deve constar de um inventário de TI de servidores web

Um inventário útil é uma tabela com uma linha por site ou aplicação. Estas colunas revelaram-se eficazes:

| Coluna | Exemplo | Para quê |
|---|---|---|
| Endereço | loja.exemplo.pt | atribuição inequívoca |
| Finalidade e importância | loja online, crítica para a faturação | priorização |
| Fornecedor de alojamento ou local | servidor gerido do fornecedor X | a quem se telefona |
| Servidor e sistema operativo | vServer, Debian | via de atualização, fontes de segurança |
| Servidor web e modo de operação do PHP | Nginx com PHP-FPM | risco, p. ex. mod_php |
| Versão do PHP e estado do pacote | 8.3, pacote com data | comparação com os alertas |
| Aplicação e versão | Shopware, plugins | alertas dos fabricantes |
| Responsável interno / externo | direção de TI / agência Y | quem age |
| Dados tratados | contas de clientes, encomendas | obrigações de notificação, urgência |
| Cópias de segurança | diárias, externas, testadas pela última vez em … | recuperação |
| Último comprovativo de patch | data e documento | prova perante terceiros |

O modo de operação merece atenção especial. No PHP2Shell, a equipa do PHP classificou o risco mais elevado no Apache com mod_php. Quem sabe que sistemas funcionam assim pode tratar deles primeiro. A coluna do estado do pacote é importante porque o número de versão apresentado, depois de backports, muitas vezes permanece igual; encontra indicações em [Verificar corretamente a versão do PHP e o estado dos patches](https://phpsos.de/pt/php2shell/php-version-pruefen/).

## Encontrar sistemas esquecidos: como proceder

Os sistemas conhecidos são rapidamente registados. O verdadeiro trabalho são os desconhecidos. Estas fontes ajudam a descobri-los:

1. **Domínios e DNS:** percorra todos os domínios da empresa e os seus subdomínios. Cada entrada que aponte para um servidor web é um candidato.
2. **Faturas:** a contabilidade conhece cada fornecedor de alojamento, registador e fornecedor de nuvem que recebe dinheiro. Muitas vezes é a lista mais completa.
3. **Agências e departamentos:** marketing, vendas e recursos humanos gostam de encomendar sites diretamente. Pergunte.
4. **Servidores conhecidos:** em cada servidor, a configuração mostra que sites ele serve de facto.
5. **Dispositivos com interface web:** NAS, routers e appliances trazem por vezes o seu próprio PHP, veja [PHP em NAS, routers e appliances](https://phpsos.de/pt/blog/php-auf-nas-und-appliances/).

Para o passo 4, ajudam em servidores Linux alguns comandos só de leitura. Mostram os sites configurados, os serviços PHP e os pools FPM:

```bash
# Sites configurados (Apache ou Nginx)
apachectl -S 2>/dev/null
nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort -u
# Serviços e processos PHP em execução
systemctl list-units --type=service | grep -iE "php|fpm|lsws|litespeed"
ps -eo user,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep | sort | uniq -c
# Pools FPM em Debian e Ubuntu
ls /etc/php/*/fpm/pool.d/ 2>/dev/null
```

Se num servidor correm várias versões do PHP em paralelo, cada uma tem de constar da lista. Cada uma tem de ser atualizada e reiniciada individualmente.

> **Dica:**
> Registe também os sistemas que, na verdade, deviam ser desligados. São muitas vezes precisamente esses que continuam a funcionar, não são atualizados há anos e são esquecidos. Com uma entrada «desligar até …», a tarefa permanece visível.

## Manter o inventário atualizado

Um inventário vale tanto quanto a sua última atualização. Três regras mantêm-no vivo. Primeira: uma pessoa é responsável e é informada de cada novo site, de cada mudança e de cada desativação, mesmo quando é uma agência a fazer o trabalho. Segunda: uma vez por trimestre, a lista é comparada com o DNS, as faturas e a configuração dos servidores. Terceira: o inventário faz parte do plano de emergência e existe também fora da própria TI, por exemplo em papel.

Para empresas com muitos sistemas distribuídos, como portais de revendedores, configuradores e acessos de fornecedores, [Segurança de TI para PME e indústria](https://phpsos.de/pt/branchen/mittelstand-industrie/) descreve locais de descoberta típicos. Como integrar o inventário no plano de emergência, vê-se em [Criar um plano de emergência de TI para servidores web](https://phpsos.de/pt/compliance/notfallplan-erstellen/).

## Erros frequentes no inventário de servidores web

Muitos inventários existem, mas não ajudam numa emergência. As causas assemelham-se:

- **Só servidores, sem sites:** a lista indica máquinas, mas não que sites correm nelas nem quem responde por eles do ponto de vista funcional. Perante uma vulnerabilidade, ninguém sabe então que departamento é afetado.
- **Versão em vez de estado do pacote:** «PHP 8.3» diz pouco depois do PHP2Shell. Só o estado do pacote e a data mostram se a correção está incluída.
- **Faltam sistemas externos:** o que corre numa agência ou num serviço de plataforma é omitido, porque «aí não somos responsáveis». A responsabilidade pelos dados continua, ainda assim, dentro de casa.
- **Sem interlocutores:** uma entrada sem nome e número de telefone do responsável faz perder tempo numa emergência.
- **Ação pontual:** o inventário é criado numa semana de crise e nunca mais é aberto. Ao fim de um ano, boa parte já não está certa.

Quem evitar estes cinco pontos terá, no próximo alerta, uma lista com a qual se pode realmente trabalhar.

## Como ajuda concretamente a PHP SOS?

- Registamos consigo todos os sites e servidores, incluindo os esquecidos, através do DNS, das faturas, dos prestadores de serviços e da configuração dos servidores.
- Apuramos, para cada sistema, o modo de operação, a versão do PHP e o estado efetivo do pacote.
- Priorizamos os sistemas segundo a acessibilidade, os dados e o modo de operação e indicamos onde é preciso agir primeiro.
- Onde o PHP2Shell ainda está em aberto, fechamos a vulnerabilidade através da [ajuda imediata PHP2Shell](https://phpsos.de/pt/leistungen/php2shell-soforthilfe/) e registamos o comprovativo no inventário.

**Conclusão:** um inventário é a medida de segurança mais discreta e, ao mesmo tempo, a mais eficaz. Quem sabe o que está a correr pode agir de imediato no próximo alerta, em vez de começar por procurar.


## Perguntas frequentes

**Que dados são o mínimo num inventário de servidores web?**  
Endereço do site, servidor ou fornecedor de alojamento, modo de operação do PHP, versão do PHP com o estado do pacote, aplicação com versão, pessoa responsável interna e externa, tipo de dados tratados e local das cópias de segurança. Com estes dados, cada novo alerta de segurança pode ser comparado rapidamente.

**Como encontro sites de que ninguém já se lembra?**  
Por vários caminhos em simultâneo: gestão de domínios e zonas DNS, faturas de fornecedores de alojamento e de registadores, perguntas a agências e departamentos e a configuração dos servidores conhecidos. Páginas de campanhas antigas, sistemas de teste e subdomínios costumam assim aparecer.

**Quem deve manter o inventário?**  
Uma pessoa designada, em regra na área de TI ou na direção de TI. É importante que qualquer alteração a sites e servidores seja ali comunicada, mesmo quando é um departamento ou uma agência a desencadeá-la.

**Basta uma tabela ou é preciso software?**  
Para a maioria das PME, basta uma tabela bem mantida. Um software compensa quando muitos sistemas devem ser registados automaticamente. O que decide é a atualidade, não a ferramenta.

## Fontes

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: versões suportadas](https://www.php.net/supported-versions.php)
- [BSI](https://www.bsi.bund.de/)