# Segurança do site para consultórios médicos e MVZ

> Marcação de consultas, pedidos de receita, formulário de contacto: como consultórios e MVZ protegem o site contra o PHP2Shell e os dados de saúde.

Fonte: https://phpsos.de/pt/branchen/arztpraxen/  
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:** no site de um consultório médico trata-se de segurança de dados de saúde, e não apenas de um cartão de visita na Internet. Verifique que formulários guardam dados ou os enviam por e-mail, peça a confirmação escrita do nível de patch do PHP do servidor e, em caso de suspeita, guarde de imediato os registos.

## Que sistemas PHP existem em consultórios e MVZ

A maioria dos sites de consultórios assenta num CMS PHP, muitas vezes [WordPress](https://phpsos.de/pt/plattformen/wordpress/), mais raramente TYPO3 ou Joomla. O interessante está nas funções adicionais: formulários para pedidos de receitas e de credenciais de encaminhamento, questionários de anamnese para descarregar ou carregar, inscrições de recall, anúncios de emprego com envio de candidaturas e marcação de consultas online.

A marcação de consultas é muitas vezes um serviço externo que apenas é incorporado. Nesse caso, os dados das consultas ficam no fornecedor. Alguns consultórios usam, porém, plugins de marcação que guardam as consultas, com o motivo, na base de dados do próprio site. É precisamente esta diferença que deve conhecer antes de avaliar o risco.

## Dados de saúde: por que razão o site é mais sensível do que parece

Uma frase como “Preciso outra vez do meu medicamento para a tensão arterial” no formulário de contacto é um dado de saúde. Estas indicações pertencem às categorias especiais de dados pessoais nos termos do Art. 9 do RGPD. Para médicos e médicas aplica-se ainda o dever de sigilo, cuja violação pode ser punível nos termos do § 203 StGB (Código Penal alemão).

Para o site, isto significa: as entradas de formulários que permanecem na base de dados, as cópias em plugins de formulários, os registos de correio no servidor e os documentos carregados ficam ao alcance num ataque. Quem executa código no servidor lê, em regra, tudo isso também.

> **Dica:**
> Mande verificar se o seu plugin de formulários guarda adicionalmente as entradas na base de dados. Muitos fazem-no por predefinição. O que não está guardado também não pode ser extraído.

## O que significa para o consultório uma falha ou uma fuga de dados

Se o site falha, os doentes telefonam, e o telefone do consultório já está de qualquer modo sobrecarregado. É incómodo, mas controlável. Mais grave é um ataque não detetado: redirecionamentos para páginas fraudulentas com o nome do consultório, formulários falsificados ou pedidos captados com referência a doenças.

Um incidente deste tipo pode desencadear obrigações de notificação à autoridade de proteção de dados e, consoante o risco, também a comunicação aos titulares dos dados. O [prazo de 72 horas do RGPD](https://phpsos.de/pt/compliance/dsgvo-meldepflicht-72-stunden/) começa a contar assim que tem conhecimento da violação. Esclareça a avaliação com o seu encarregado da proteção de dados.

## Site do consultório e segurança: a típica lacuna de responsabilidade

Nos consultórios há normalmente três intervenientes, cada um dos quais se sente responsável por uma parte:

| Interveniente | Ocupa-se, em regra, de | Muitas vezes fora do radar |
|---|---|---|
| Prestador de TI do consultório | PVS (sistema de gestão do consultório), rede, conector, postos de trabalho | Servidor do site no fornecedor de alojamento |
| Agência web | Design, conteúdos, plugins | Versão do PHP e reinício do servidor |
| Fornecedor de alojamento | Operação do servidor | Dados de formulários e plugins do consultório |

No PHP2Shell, a vulnerabilidade situa-se precisamente entre estes papéis: no PHP do servidor web. No [alojamento partilhado](https://phpsos.de/pt/server/shared-hosting/), o responsável é normalmente o fornecedor de alojamento, mas a confirmação do estado do pacote tem de ser pedida por si. Nos MVZ (centros de cuidados médicos) com vários locais, junta-se muitas vezes a entidade gestora, que impõe regras próprias.

## Existe uma ponte entre o site e a rede do consultório?

Em regra, o site do consultório está no fornecedor de alojamento e não tem ligação direta ao sistema de gestão do consultório. Mas há exceções que deve conhecer: formulários que transferem dados automaticamente para o PVS, um servidor do site no centro de dados do próprio MVZ ou credenciais usadas em simultâneo para o site, as contas de correio e a manutenção remota.

Nestes casos, um servidor web comprometido não é apenas um problema do site. Peça ao seu prestador de TI do consultório e ao responsável pelo site que verifiquem em conjunto que ligações existem e que palavras-passe são usadas em vários locais. Para a TI do consultório aplicam-se ainda as exigências da Associação Federal dos Médicos do Seguro de Saúde (Kassenärztliche Bundesvereinigung) em matéria de segurança informática. Até que ponto afetam o site, esclareça-o com o seu encarregado da proteção de dados.

## As primeiras horas após um aviso

1. Perguntar ao fornecedor de alojamento se o PHP está em 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 ou se foi instalado um backport, e se todos os processos PHP foram reiniciados.
2. Se isso não estiver confirmado: desligar temporariamente o site ou substituí-lo por uma página de aviso estática com os horários de atendimento telefónico, como o BSI (Gabinete Federal Alemão para a Segurança da Informação) recomenda para servidores sem possibilidade de patch.
3. Guardar os registos do servidor e de acesso desde 20/10/2026.
4. Estar atento a [sinais de comprometimento](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/): ficheiros desconhecidos, novas contas de administrador, redirecionamentos alterados.
5. Envolver cedo o encarregado da proteção de dados, e não só depois da limpeza.

## Como ajuda concretamente a PHP SOS?

- Esclarecemos com o fornecedor de alojamento e a agência quem aplica o patch ao PHP e o reinicia, e obtemos a confirmação com o estado do pacote.
- Verificamos onde estão no servidor web os dados de formulários, os uploads e as cópias de correio e se existem ligações à rede do consultório.
- Em caso de suspeita, preservamos vestígios, procuramos webshells e limpamos o servidor no âmbito da nossa [assistência de emergência para sites hackeados](https://phpsos.de/pt/leistungen/website-gehackt-notfallhilfe/).
- Documentamos o incidente de modo a que o seu encarregado da proteção de dados possa avaliar a obrigação de notificação.
- Em seguida, reduzimos os dados guardados e reforçamos o servidor, para que da próxima vez haja menos em jogo.


## Perguntas frequentes

**O software do meu consultório está afetado pelo PHP2Shell?**  
O sistema de gestão do consultório e o acesso à infraestrutura telemática funcionam, em regra, separados do site. Estão afetados os servidores web PHP, ou seja, normalmente o site do consultório e os formulários ou portais a ele ligados. Se existem ligações entre o site e a rede do consultório, deve ser o seu prestador de serviços de TI a verificá-lo.

**Os dados do formulário de contacto são dados de saúde?**  
Muitas vezes sim. Já o pedido de uma receita de seguimento ou de uma consulta por determinadas queixas permite tirar conclusões sobre a saúde. Esses dados pertencem às categorias especiais nos termos do Art. 9 do RGPD. A classificação exata esclarece-a com o seu encarregado da proteção de dados.

**Tenho de informar os doentes se o site foi hackeado?**  
Depende de estarem em causa dados pessoais e de qual é o risco para os doentes. No caso de dados de saúde, o risco é frequentemente elevado. A decisão toma-a com o seu encarregado da proteção de dados e, se necessário, com aconselhamento jurídico.

**Quem é responsável pelas atualizações do PHP no site do consultório?**  
Isso consta do contrato de alojamento ou de manutenção. No alojamento partilhado e no alojamento gerido, o patch costuma ser aplicado pelo fornecedor de alojamento; num servidor próprio, pelo prestador de serviços contratado. Se não houver uma regra clara, deve registá-la agora por escrito.

## Fontes

- [php.net: avisos de segurança](https://www.php.net/)
- [BSI: avisos e recomendações](https://www.bsi.bund.de/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)