# Consciência de segurança para administradores e editores: sensibilização na equipa web

> Sensibilização para administradores e editores: riscos por função, formações curtas que resultam e como preparar uma equipa web em 90 dias.

Fonte: https://phpsos.de/pt/blog/sicherheitsbewusstsein-redaktion/  
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 sensibilização para a segurança dos colaboradores da equipa web significa que cada pessoa que mantém um site conhece os três a quatro riscos da sua função, reconhece anomalias e comunica-as depressa e sem medo de censuras. Os editores precisam de conteúdos diferentes dos dos administradores. Sessões curtas e recorrentes, com exemplos do próprio CMS, resultam melhor do que uma formação obrigatória anual.

## Porque é que a equipa web está agora no centro

A situação em torno do PHP2Shell mostrou quanto cai em poucos dias sobre os operadores de sites: avisos do BSI (Gabinete Federal Alemão para a Segurança da Informação), comunicações de fornecedores de alojamento, conselhos em fóruns e redes sociais, entre eles também falsos. Em semanas assim, decidem não só os administradores, mas também os editores, o marketing e a assistência, que e-mail abrem e em que ligação clicam.

As grandes situações noticiosas são, segundo a experiência, uma oportunidade para os burlões. Conte com e-mails que se fazem passar pelo fornecedor de alojamento, pelo fabricante do CMS ou pelo «departamento de TI» e que exigem um início de sessão urgente ou uma suposta atualização de segurança. Quem conhece a situação real cai nisso com menos frequência. A vulnerabilidade técnica em si, nenhum editor a fecha, mas um acesso de administrador roubado abre a porta mesmo sem vulnerabilidade.

## Sensibilização dos colaboradores: quem precisa de quê?

Uma formação para todos com os mesmos diapositivos falha, em regra, o seu objetivo. Mais sensato é um ajuste por funções. O quadro seguinte ajuda no planeamento:

| Função | Riscos típicos | O que a pessoa deve saber fazer |
|---|---|---|
| Editor, marketing | e-mails de phishing, uploads de ficheiros inseguros, acessos partilhados | verificar o remetente, carregar apenas os tipos de ficheiro esperados, nunca transmitir as próprias credenciais |
| Administrador de CMS | plugins de origem desconhecida, demasiadas contas de administrador, contas antigas de ex-colaboradores | atribuir direitos com parcimónia, verificar as contas com regularidade, instalar extensões só após aprovação |
| Administrador de servidor | dicas não verificadas da Internet, alterações sem registo, ficheiros de teste esquecidos | avaliar fontes, documentar alterações, conhecer o caminho de emergência |
| Gerência | pressão para decisões rápidas, responsabilidades pouco claras | definir vias de decisão, levar os alertas a sério, libertar orçamento para a prevenção |
| Agência externa | acessos partilhados, falta de acordos | usar contas próprias e pessoais, anunciar alterações |

O quadro mostra também onde a técnica tem de ajudar. Contas pessoais em vez de acessos coletivos e uma autenticação de dois fatores para todos com direitos de escrita tiram muita pressão à formação. Como fazê-lo, vê-se em [Autenticação de dois fatores para acessos de administração](https://phpsos.de/pt/ratgeber/zwei-faktor-admin/).

## O que os editores devem saber sem se tornarem técnicos

Os editores não precisam de saber o que é um worker PHP. Devem, porém, dominar com segurança três coisas. Primeira: um pedido para voltar a iniciar sessão «por causa de um incidente de segurança» nunca se resolve pela ligação do e-mail, mas pelo caminho habitual para o CMS ou perguntando ao administrador.

Segunda: comunicar anomalias. Incluem-se contas de utilizador desconhecidas na lista de utilizadores, páginas ou artigos que ninguém criou, redirecionamentos súbitos e avisos no navegador. Um editor vê muitas vezes o site com mais frequência do que o administrador e repara mais cedo nas alterações.

Terceira: tratar os uploads com consciência. Imagens e PDF são o dia a dia, mas um ficheiro com extensão invulgar, um arquivo «para reencaminhar» ou um documento com macros não pertence ao CMS. Se um ficheiro não pode ser carregado, é em regra intencional e não um erro que se deva contornar.

## O que os administradores precisam além disso

Para os administradores, trata-se menos de phishing e mais de discernimento sob pressão de tempo. Na semana do PHP2Shell circularam conselhos que os autores especializados rejeitam expressamente, por exemplo bloquear todos os pedidos com `PHPSESSID`. Uma visão geral desses desvios encontra-se no artigo [Dicas perigosas sobre o PHP2Shell](https://phpsos.de/pt/blog/gefaehrliche-falschtipps/). Bons administradores verificam primeiro a fonte primária, isto é, o php.net, o BSI ou o fabricante, antes de alterarem uma configuração.

A isto junta-se a disciplina nas alterações: o que foi alterado, quando, porquê e como se pode reverter? Uma breve entrada no ticket ou na wiki chega. Numa emergência, esta lista vale ouro, porque mostra que alteração é sua e qual não é.

Por fim, os administradores devem saber por que sinais reconhecem uma possível intrusão e o que então não fazer: não apagar à pressa, não reinstalar de imediato, mas preservar e comunicar. Os sinais típicos resume-os [Será que já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## Em 90 dias para uma equipa web atenta

Um programa não precisa de ser grande para resultar. Estes passos revelaram-se eficazes:

1. **Esclarecer a situação atual (semana 1 a 2):** quem tem que acessos ao CMS, alojamento, domínio e servidor? Dissolver as contas coletivas, bloquear as contas antigas.
2. **Definir a via de comunicação (semana 2):** um endereço ou canal para «algo me parece estranho». Cada comunicação recebe resposta, mesmo que tenha sido inofensiva.
3. **Primeira sessão curta por função (semana 3 a 4):** 20 minutos, exemplos do próprio CMS, capturas de ecrã de menus reais.
4. **Introduzir a autenticação de dois fatores (até à semana 6):** para todos com direitos de escrita, com códigos de emergência em local seguro.
5. **E-mail de exercício e avaliação (semana 8):** uma campanha de teste anunciada, sem expor pessoas individuais. Avalia-se se houve comunicação, não quem clicou.
6. **Segunda sessão por ocasião de um acontecimento (semana 10 a 12):** por exemplo, uma situação de segurança atual, simulada no próprio sistema.

Meça o êxito pelas comunicações e não pelas taxas de cliques. Uma equipa que comunica muito está atenta. Uma equipa que nunca comunica é perfeita ou está insegura, e a primeira hipótese é rara.

## Como ajuda concretamente a PHP SOS?

- Apuramos consigo quem tem que acessos e mostramos contas coletivas, administradores a mais e acessos esquecidos.
- Damos sessões curtas por função, à distância, com exemplos do seu CMS e do seu ambiente de servidores.
- Ajudamos a montar a via de comunicação e avaliamos as suspeitas recebidas, se o desejar.
- No âmbito de um [contrato de manutenção de segurança](https://phpsos.de/pt/leistungen/security-wartungsvertrag/), repetimos as sessões por ocasião de acontecimentos atuais e verificamos as contas com regularidade.

## Conclusão

A consciência de segurança na equipa web não nasce do medo, mas da clareza: cada pessoa conhece a sua função, os seus riscos típicos e o caminho para comunicar anomalias. Combinada com contas pessoais e autenticação de dois fatores, é uma proteção que se mantém também na próxima semana de crise.


## Perguntas frequentes

**Os editores precisam mesmo de formação em segurança?**  
Sim. Os editores têm acesso ao CMS, carregam ficheiros e recebem e-mails que parecem mensagens do sistema. Não precisam de compreender a técnica, mas de reconhecer quando algo é invulgar e de saber a quem o comunicar.

**Com que frequência se deve formar a equipa web?**  
Melhor curto e regular do que uma vez por ano e longo. Revelaram-se eficazes sessões de 15 a 20 minutos com intervalos de poucas semanas, complementadas por uma ocasião como uma situação de segurança atual.

**O que fazer se um colaborador clicou numa ligação de phishing?**  
Fazer com que comunique de imediato, sem censura. Depois, alterar a palavra-passe afetada, terminar as sessões ativas e verificar se algo foi alterado com a conta. Quanto mais cedo chega a comunicação, menor costuma ser o dano.

**Uma formação substitui as medidas técnicas de proteção?**  
Não. Formação e técnica completam-se. A autenticação de dois fatores, funções separadas e software atualizado absorvem erros que acontecem também a pessoas bem formadas.

## Fontes

- [BSI: informações para empresas](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net: avisos de segurança](https://www.php.net/)