Contas break-glass não são apenas mais um administrador protegido por MFA

Todos os MSP acabam por ser questionados sobre a razão de um cliente precisar de contas de acesso de emergência dedicadas, se todos os administradores já são obrigados a utilizar autenticação multifator. A resposta é que as contas break-glass resolvem um problema diferente: manterem-se utilizáveis quando o fornecedor de identidade ou o próprio sistema de MFA fica indisponível, e não acrescentar mais uma camada sobre um sistema que já está a funcionar.

O que a Microsoft recomenda

A orientação da Microsoft para o Entra ID exige, no mínimo, duas contas de acesso de emergência apenas na cloud, não sincronizadas a partir de um diretório no local nem federadas através de um fornecedor de identidade externo — porque uma conta que depende da mesma infraestrutura que deveria salvar não é, na verdade, uma conta de emergência. A Microsoft recomenda autenticação resistente a phishing, como chaves FIDO2 ou autenticação baseada em certificados, deliberadamente independente dos métodos usados pelos administradores comuns, e uma atribuição permanente — não elegível nem limitada no tempo — da função de Administrador Global no Privileged Identity Management, uma vez que um fluxo de ativação é exatamente o que pode não funcionar durante uma indisponibilidade. Estas contas devem continuar abrangidas por políticas de Acesso Condicional que exigem MFA resistente a phishing; a exclusão recomendada é especificamente do bloqueio baseado em geolocalização, e não dos controlos de acesso em geral, dados os casos anteriores de inícios de sessão legítimos terem sido geograficamente mal classificados durante horas a fio.

O que o NIST e a OWASP acrescentam

O controlo AC-2(2) do NIST SP 800-53 enquadra as contas de emergência como algo que é ativado para uma crise definida e depois desativado ou removido automaticamente, em vez de permanecer indefinidamente. A orientação de MFA da OWASP assinala os processos de recuperação e de bypass como um alvo de atacantes por direito próprio: qualquer mecanismo que restabeleça o acesso durante uma emergência não pode, silenciosamente, tornar-se uma forma de ignorar o MFA em condições normais.

O que significa «provar que funciona»

• Monitorize os inícios de sessão destas contas especificamente, com um alerta em cada tentativa — bem-sucedida ou falhada.
• Realize simulacros de acesso num calendário fixo, normalmente de 90 em 90 dias, em vez de assumir que a configuração continua a funcionar.
• Faça uma breve análise pós-incidente após cada utilização real ou simulacro e ajuste a configuração com base no que for detetado.
• Documente quem pode recuperar credenciais e como, uma vez que redundância sem um processo de recuperação não é, na verdade, redundância.

Uma conceção de acesso de emergência que nunca foi testada numa falha simulada não é uma salvaguarda — é um pressuposto.

Fontes: Microsoft Learn — contas de acesso de emergência, NIST SP 800-53 Rev. 5.