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.
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. 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?.
Em 90 dias para uma equipa web atenta
Um programa não precisa de ser grande para resultar. Estes passos revelaram-se eficazes:
- 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.
- 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.
- Primeira sessão curta por função (semana 3 a 4): 20 minutos, exemplos do próprio CMS, capturas de ecrã de menus reais.
- 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.
- 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.
- 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, 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.