Em resumo: a autenticação de dois fatores para acessos de administração garante que uma palavra-passe roubada ou adivinhada, por si só, não chega. Tem de valer em todos os sítios onde alguém pode alterar o seu site ou servidor: CMS, alojamento, painel, SSH, domínio, DNS e as caixas de correio dos administradores. Tão importantes como a configuração são os códigos de emergência e uma regra clara sobre quem tem acesso próprio a quê.
Porque é que as palavras-passe sozinhas não chegam para administradores
As palavras-passe perdem-se por muitos caminhos: por e-mails de phishing, software malicioso num computador de trabalho, fugas de dados noutros serviços ou simplesmente por reutilização. Os ataques automatizados experimentam sem parar credenciais roubadas contra páginas de login conhecidas.
Com um segundo fator, o atacante precisa adicionalmente de algo que só o utilizador autorizado possui, por exemplo um smartphone com aplicação de autenticação ou uma chave de segurança. Isto eleva a barreira de forma considerável, sobretudo em contas com permissões alargadas.
Para a gestão, uma delimitação é importante: a autenticação de dois fatores protege acessos, não o software que está por trás. Uma vulnerabilidade como o PHP2Shell, que permite a execução de código sem autenticação, não é fechada por ela. As duas coisas andam juntas: software atualizado e acessos bem protegidos.
Que métodos de dois fatores são adequados
Os métodos diferem em segurança e conforto de utilização. Para contas de administração, deve usar pelo menos aplicações de autenticação, e para os acessos particularmente críticos chaves de segurança ou passkeys.
| Método | Proteção contra phishing | Adequação para administradores |
|---|---|---|
| Código SMS | baixa | só como transição |
| Aplicação de autenticação (TOTP) | média | bom padrão |
| Confirmação push | média, vulnerável a ataques de fadiga | adequada com confirmação do número |
| Chave de segurança ou passkey (FIDO2/WebAuthn) | alta | recomendada para acessos críticos |
| Chave SSH com frase-passe | alta | padrão para acessos a servidores |
Os códigos de utilização única de uma aplicação podem ser intercetados numa página de phishing enganadoramente autêntica e reutilizados de imediato. Os métodos FIDO2, em contrapartida, verificam o endereço da página e não funcionam numa página falsificada. É esta a razão pela qual são a melhor escolha para administradores com acesso a muitos sistemas.
Autenticação de dois fatores para acessos de administração: a lista completa
Os atacantes procuram o acesso mais fraco. Percorra por isso todos os pontos em que alguém pode alterar o seu site, o seu servidor ou o seu domínio:
- CMS e backend da loja: WordPress, Shopware, TYPO3 e outros oferecem autenticação de dois fatores no núcleo ou através de extensões mantidas. Que variante é recomendada, consta da documentação do fabricante.
- Conta de cliente do alojamento: quem aí entrar pode muitas vezes repor palavras-passe, descarregar cópias de segurança ou reinstalar o servidor.
- Painel do servidor, como o Plesk ou o cPanel, se existir.
- SSH e SFTP: chaves em vez de palavra-passe, ver a secção seguinte.
- Registrador de domínios e DNS: uma definição de DNS alterada redireciona os seus visitantes e e-mails sem que o servidor seja afetado.
- Caixas de correio dos administradores: é por elas que passam as reposições de palavras-passe de quase todos os outros serviços.
- Repositório de código e deployment: quem aí pode escrever pode distribuir código malicioso.
- CDN, WAF, Google Search Console e prestadores de pagamento.
Registe para cada ponto quem tem acesso, se o segundo fator está ativo e onde estão os códigos de recuperação. Esta lista é ao mesmo tempo uma parte importante do seu plano de emergência, pois após um incidente estes mesmos acessos têm de ser verificados e renovados em pouco tempo.
SSH: chaves em vez de palavra-passe
Para acessos a servidores, o login com chave SSH é a habitual proteção forte. A chave privada fica no dispositivo do administrador e está protegida por uma frase-passe; em servidores particularmente sensíveis pode estar numa chave de hardware. Quando o login com chave estiver configurado e testado para todos os administradores, desative o login por palavra-passe:
# /etc/ssh/sshd_config (excerto)
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
# Verificar a configuração antes de recarregar o serviço
sshd -t && systemctl reload ssh # em sistemas RHEL: sshd
Ao fazer a mudança, deixe uma sessão existente aberta e teste o login numa segunda janela. Assim, em caso de erro, não fica bloqueado. Cada administrador recebe uma chave própria; chaves partilhadas por uma equipa inteira não podem ser retiradas de forma limpa quando uma pessoa sai. Outros fundamentos descreve-os Proteger você mesmo servidores root e vServers.
Acesso de emergência e códigos de recuperação
Uma boa introdução prevê também a falha. Os smartphones perdem-se, os colaboradores saem da empresa, as chaves de segurança avariam-se. Sem plano, no momento errado ninguém tem acesso disponível.
Registe dois fatores para cada conta crítica, por exemplo uma chave de segurança no escritório e uma aplicação de autenticação, e guarde os códigos de recuperação separados da palavra-passe.
Outras regras que se revelaram eficazes:
- Contas pessoais em vez de logins de administração partilhados, para que as alterações sejam rastreáveis.
- Um acesso de emergência documentado, com credenciais guardadas em separado, cuja utilização se note e seja registada.
- Na saída de colaboradores ou prestadores de serviços, retirar todos os acessos e chaves no mesmo dia.
- Após um incidente de segurança, verificar não só as palavras-passe, mas também os fatores registados e as sessões ativas.
Na introdução na equipa, tem-se revelado eficaz um procedimento claro. Comece pelas contas que podem causar o maior dano: alojamento, domínio, DNS e as caixas de correio dos administradores. Seguem-se depois servidores, CMS e serviços. Defina uma data a partir da qual deixam de ser possíveis logins sem segundo fator e certifique-se antes de que todos os envolvidos estão configurados.
Explique brevemente à equipa por que a mudança é necessária e como funciona no dia a dia. Um guia de uma página com capturas de ecrã reduz claramente as perguntas. Os prestadores de serviços externos e as agências devem receber acessos próprios e pessoais com segundo fator, em vez de um login partilhado, para que os acessos permaneçam atribuíveis e possam ser retirados de forma limpa após o fim do projeto.
Como proteger adicionalmente as páginas de login contra tentativas automatizadas, está no guia Proteger logins de administração contra brute force.
Como ajuda concretamente a PHP SOS?
- Elaboramos consigo uma lista completa de todos os acessos de administração e mostramos onde falta o segundo fator.
- Convertemos os acessos a servidores para chaves SSH e desativamos de forma controlada os logins por palavra-passe no âmbito do reforço de segurança do servidor.
- Documentamos os acessos de emergência e as vias de recuperação de modo que funcionem no caso real.
- No contrato de manutenção de segurança, verificamos regularmente os acessos e removemos contas órfãs.
Perguntas frequentes
Qual é o método de dois fatores mais seguro?
As chaves de segurança de hardware e as passkeys segundo a norma FIDO2 são consideradas especialmente resistentes ao phishing, porque estão ligadas ao endereço verdadeiro. As aplicações de autenticação com códigos de utilização única são um bom padrão. O SMS é melhor do que nada, mas é a variante mais fraca.
O que acontece se o smartphone com a aplicação de autenticação se perder?
Para isso existem códigos de recuperação, que são apresentados na configuração. Devem ser guardados em segurança, por exemplo num cofre ou num gestor de palavras-passe protegido. Adicionalmente, pelo menos um segundo administrador deve poder repor o acesso.
A autenticação de dois fatores também protege contra o PHP2Shell?
Não. O PHP2Shell permite a execução de código sem autenticação, e o login nem sequer é utilizado. Contra o PHP2Shell só ajuda a atualização para uma versão corrigida do PHP, com reinício de todos os workers. A autenticação de dois fatores protege contra palavras-passe roubadas ou adivinhadas.
Basta a autenticação de dois fatores no CMS?
Não, um atacante escolhe o acesso mais fraco. A conta de alojamento, o painel do servidor, o SSH, a gestão de domínios, o DNS e as caixas de correio dos administradores têm de estar igualmente protegidos, caso contrário a proteção do CMS pode ser contornada.