Conta break-glass: evite lockout no Microsoft Entra

O Que É uma Conta de Emergência

Uma conta de emergência, ou break-glass account, é uma conta administrativa criada exclusivamente para recuperar o acesso ao Microsoft Entra quando o caminho normal falha. Ela preserva uma forma controlada de entrar no tenant para corrigir uma política, investigar uma indisponibilidade de autenticação ou restaurar o acesso de outros administradores.

Ela recebe privilégio elevado de propósito, normalmente Global Administrator, e é mantida fora das políticas de Conditional Access que poderiam bloquear a própria recuperação. Por isso, não substitui a conta administrativa de trabalho: fica reservada para incidentes e testes periódicos, com credencial protegida, responsáveis definidos e todo uso registrado.

O Lockout que Não Dá para Corrigir pelo Portal

Uma política de Conditional Access pode bloquear justamente quem tem permissão para alterá-la. Isso acontece, por exemplo, quando uma regra passa a exigir dispositivo compatível para todas as contas administrativas antes de o Intune estar estável, ou quando uma nova exigência de autenticação afeta o método usado pelo administrador.

Nessa situação, não basta saber onde fica a configuração no Entra admin center. Se ninguém consegue entrar, ninguém consegue corrigir a política. A conta break-glass, também chamada de conta de acesso de emergência, existe para manter uma rota administrativa separada para esse cenário.

A regra é simples: ela não é uma conta administrativa de uso diário. É uma exceção documentada, com acesso permanente de propósito, usada somente para recuperar o controle do tenant ou testar o plano de emergência.

O Que Torna uma Conta de Emergência Confiável

A orientação da Microsoft para contas de acesso de emergência recomenda pelo menos duas contas. Uma conta única continua sendo um ponto único de falha: pode ter a senha indisponível, sofrer comprometimento ou simplesmente não estar acessível para a pessoa responsável no momento do incidente.

As duas contas devem ser cloud-only, preferencialmente usando o domínio *.onmicrosoft.com. Assim, o acesso não depende de sincronização com Active Directory, de um provedor de identidade externo ou da disponibilidade do domínio personalizado da organização.

Também vale separar o modo de autenticação dessas contas do caminho normal usado pelos administradores. O objetivo não é eliminar controles sem critério; é garantir que uma indisponibilidade no fluxo padrão de autenticação não elimine a capacidade de recuperação. Documente a decisão, use uma senha forte e única e mantenha o material de acesso em locais seguros, com responsáveis definidos.

Por que duas contas? A segunda não existe para ser usada no dia a dia. Ela reduz o risco de uma única credencial, um único cofre ou uma única pessoa impedir a recuperação administrativa.

Checklist de Configuração

Antes de considerar a conta de emergência pronta, confirme:

Existem duas contas cloud-only criadas no Microsoft Entra, usando o domínio *.onmicrosoft.com e sem dependência de sincronização com AD DS ou de domínio personalizado.
O papel Global Administrator está atribuído diretamente às duas contas, sem exigir ativação pelo Privileged Identity Management (PIM).
As duas contas estão explicitamente excluídas de cada política de Conditional Access que poderia impedir a recuperação administrativa.
Cada conta usa um método de autenticação forte e independente do fluxo administrativo cotidiano, com credenciais únicas e protegidas.
As credenciais e o procedimento de acesso estão sob custódia definida, com responsáveis, local seguro e registro de retirada.
A solução de monitoramento registra e alerta sobre qualquer tentativa de entrada, com sucesso ou falha, nas duas contas.
Um teste controlado de login foi concluído e registrado, confirmando o acesso ao Entra admin center e o recebimento do alerta.

Configurando sem Criar Outra Dependência

O procedimento abaixo concentra o mínimo necessário. Adapte os nomes, responsáveis e o método de armazenamento ao processo de segurança da sua organização.

1. Crie duas contas cloud-only

Crie as contas diretamente no Microsoft Entra ID, sem sincronizá-las do AD DS local. Use nomes que deixem o propósito claro, como emergency-access-01@tenant.onmicrosoft.com e emergency-access-02@tenant.onmicrosoft.com.

Registre no runbook quem pode solicitar o uso, quem pode abrir o material de acesso e quem deve ser avisado depois de um login. Evite usar a conta como uma alternativa conveniente quando o administrador normal perde o MFA ou esquece a senha. Esse tipo de uso banaliza a exceção e dificulta identificar um incidente real.

2. Atribua Global Administrator diretamente

As contas precisam ter o papel Global Administrator atribuído de forma direta. Não dependa de Privileged Identity Management para ativar o papel em uma emergência: se o problema estiver no próprio fluxo de autenticação, aprovação ou elevação, a conta deixa de cumprir seu objetivo.

Para todas as demais contas privilegiadas, o padrão continua sendo o oposto: privilégio mínimo e elevação just-in-time pelo PIM quando disponível. A conta break-glass é uma exceção limitada e monitorada, não um argumento para manter administradores permanentes.

3. Exclua as contas das políticas aplicáveis

Revise cada política de Conditional Access e registre explicitamente as contas de emergência nas exclusões necessárias. Não presuma que excluir de uma política de MFA basta: uma política de dispositivo compatível, de risco de entrada ou uma nova política global também pode provocar lockout.

Faça essa revisão antes de habilitar uma política em produção. Para mudanças novas, use primeiro o modo Report-only, valide o impacto nos logs e avance por grupo piloto. A exclusão da conta de emergência não substitui esse cuidado; ela apenas preserva a capacidade de recuperar uma configuração que saiu errada.

⚠️ Cuidado: mantenha a lista de exclusões curta e revisada. Contas de acesso de emergência precisam ser exceção. Contas de serviço, integrações e administradores comuns exigem controles próprios, não uma inclusão automática nessa mesma lista.

Teste Antes de Precisar

Uma conta criada e nunca testada é uma suposição, não um controle. Inclua um teste periódico no calendário de segurança, com periodicidade definida pelo risco da organização. O teste deve confirmar que a conta ainda autentica, continua fora do escopo das políticas planejadas e mantém o papel administrativo necessário.

Use um procedimento controlado:

Abra um ticket de mudança ou registro de teste antes do login.
Recupere a credencial pelo processo de custódia definido, sem expor a senha em canais de chat ou e-mail.
Faça login e confirme, nos logs de entrada, a conta, o horário, o aplicativo e o resultado da autenticação.
Valide que a conta consegue acessar o Entra admin center, sem executar mudanças fora do escopo do teste.
Encerre a sessão, registre o resultado e confirme que o alerta de uso foi recebido.

O objetivo não é usar a conta para administrar o tenant. É provar que a rota de recuperação continua disponível e que o processo de monitoramento funciona de ponta a ponta.

Monitore Todo Uso, Inclusive Testes

Uma conta de emergência sem monitoramento cria uma rota administrativa de alto privilégio sem contexto. Todo login, bem-sucedido ou falho, merece investigação ou ao menos registro formal.

O ponto de partida é o log de entrada do Microsoft Entra. Configure a solução de monitoramento adotada pela organização para identificar eventos dessas duas contas e notificar o time responsável. Azure Monitor, Microsoft Sentinel ou outro SIEM podem cumprir esse papel, desde que a regra seja testada com um login controlado.

Também separe as evidências corretamente: os sign-in logs mostram o uso da conta; os Audit logs mostram mudanças como criação de usuário, atribuição de papel e alteração nas políticas de Conditional Access. Essa distinção facilita tanto a resposta a incidente quanto uma auditoria futura.

Uma regra operacional simples fecha o ciclo: qualquer uso da conta, inclusive teste, gera um registro com motivo, responsável, horário, resultado e ação tomada. Sem esse histórico, a equipe descobre tarde demais se o acesso foi uma emergência legítima ou um evento que deveria ter sido investigado.

A Exceção Não Pode Virar Modelo de Operação

O break-glass resolve um risco específico: indisponibilidade administrativa causada por falha de configuração ou dependência de autenticação. Ele não resolve governança de privilégios, revisão de acesso ou proteção contra credenciais comprometidas.

Para o restante da operação, mantenha o princípio de menor privilégio, use PIM quando licenciado e revise regularmente as políticas de Conditional Access. Durante essa revisão, confira três pontos: as duas contas ainda existem e estão acessíveis, as exclusões permanecem corretas e os alertas de login continuam chegando ao destino certo.

Essa disciplina evita dois extremos comuns: não ter como recuperar o tenant quando uma política falha, ou manter várias contas administrativas permanentes sob a justificativa de que "podem ser necessárias".

O Que Você Ganha com um Plano Testado

Duas contas cloud-only, exclusões documentadas, custódia definida, alertas funcionais e testes periódicos formam um plano de recuperação administrativo que funciona quando a configuração normal deixa de funcionar. O objetivo não é flexibilizar a segurança, mas impedir que um único erro de acesso imobilize a organização inteira.

Antes da próxima alteração de Conditional Access, revise se esse plano existe de verdade. Se a resposta depender de memória, uma senha antiga ou uma conta que ninguém testou, o momento de corrigir é agora, não durante um lockout.