Contas de Acesso de Emergência Break Glass do Entra ID: Ausentes, Não Monitoradas, Não Excluídas

O que é uma Conta de Acesso de Emergência Break Glass do Entra ID

Uma conta de acesso de emergência break-glass do Entra ID é uma conta de Global Administrator mantida em reserva para o único cenário que todo outro caminho de administração é projetado para evitar: o bloqueio total. A própria orientação da Microsoft lista as situações para as quais essas contas existem — uma interrupção de federação que deixa todo admin sincronizado sem acesso, uma falha de dispositivo ou serviço de MFA que bloqueia a ativação de função, a saída do último Global Administrator ativo, um desastre natural que derruba redes telefônicas, ou um impasse de aprovação do Privileged Identity Management (PIM) em que toda atribuição elegível de Global Administrator ou Privileged Role Administrator precisa de um aprovador e nenhum está ativo. Para uma visão mais ampla de como as atribuições do PIM e a contagem de Global Admins permanentes impulsionam o risco do tenant, veja Azure Privileged Access: Muitos Global Admins.

Nenhum desses cenários é exótico. São os casos extremos específicos que "basta usar MFA" e "basta usar PIM" não cobrem, porque MFA e PIM são exatamente o que pode falhar.

A lacuna de governança abordada neste artigo não é o conceito — a maioria das equipes de segurança já ouviu falar de contas break-glass. É que o catálogo de auditoria da Microsoft rastreia três formas distintas e comuns pelas quais o controle falha em tenants reais:

1. Nenhuma conta de acesso de emergência existe (PA_NO_EMERGENCY_ACCOUNTS) — o caso base e, segundo o catálogo da EtcSec, a classificação padrão de severidade crítica: zero cobertura break-glass significa zero caminho de recuperação se o caminho de administração primário falhar.
2. A conta existe mas não está excluída do Conditional Access (PA_EMERGENCY_NO_EXCLUSION / CA_NO_BREAK_GLASS_EXCLUSION) — de modo que exatamente a política pensada para proteger o tenant é o que bloqueia a conta de recuperação durante a emergência para a qual ela foi criada.
3. A conta existe e está excluída, mas ninguém a monitora (PA_EMERGENCY_NO_MONITORING) — de modo que um evento de login que deveria acender todos os alarmes (uma conta de Global Admin fora dos controles normais de CA acabou de autenticar) não gera absolutamente nenhum alerta.

Uma quarta lacuna relacionada aparece na mesma família do catálogo: credenciais obsoletas (PA_EMERGENCY_CREDENTIAL_STALE) — uma conta de emergência cujo método de autenticação ou dispositivo não é validado há tanto tempo que ninguém sabe ao certo se ainda funciona.

Como a Lacuna Acontece na Prática

Contas break-glass normalmente são criadas uma única vez, durante a configuração inicial do tenant ou uma iniciativa de compliance, e depois deixadas de lado — o que é precisamente o problema, porque "deixadas de lado" funciona nos dois sentidos.

Totalmente ausente

Tenants menores, tenants migrados de um provedor de identidade mais antigo, ou tenants que presumiram que "todos os nossos admins têm MFA" já contava como cobertura, frequentemente não têm nenhuma conta de acesso de emergência dedicada. A Microsoft recomenda criar duas ou mais contas somente na nuvem no domínio padrão *.onmicrosoft.com do tenant — não federadas, não sincronizadas do ambiente local — justamente para que uma interrupção local ou de federação não derrube também o caminho de recuperação.

Não excluída do Conditional Access

Esse é o modo de falha que transforma um controle em uma armadilha. Uma política de CA que exige um dispositivo compatível, um método específico de MFA ou bloqueia por localização vai se aplicar tranquilamente à conta de emergência como a qualquer outro Global Administrator — o que significa que exatamente a política que deveria proteger o tenant se torna a razão pela qual a conta de emergência não consegue fazer login durante a interrupção ou o bloqueio para o qual ela existe. A Microsoft é explícita aqui: exclua contas break-glass de qualquer política de CA que bloqueie ou restrinja o login; políticas em modo somente relatório não bloqueiam o acesso e não precisam da exclusão. Este é um caso específico de um padrão mais amplo — veja Lacunas de Conditional Access do Entra ID sobre como erros no escopo de exclusão aparecem nas políticas de forma geral.

Não monitorada

Mesmo com uma conta corretamente criada e excluída, a maioria dos tenants não tem alertas configurados para seu uso. Uma conta break-glass é projetada para quase nunca fazer login. Essa característica torna o monitoramento barato e de alto sinal: qualquer autenticação vinda dela é ou um simulado de validação programado ou um incidente ativo (uma emergência legítima, ou um invasor que encontrou e comprometeu a única conta explicitamente reservada fora da aplicação da política). Sem um alerta permanente, esse sinal fica invisível até que alguém revise os logs de login por acaso — o que, para a maioria dos tenants, é raro ou nunca acontece. Esse ponto cego está ao lado de lacunas mais amplas de sinal de risco abordadas em Azure Identity Protection: Bloqueando Credenciais Vazadas.

Detecção

Confirme o estado da cobertura de contas de acesso de emergência break-glass com estas verificações, mapeadas para as entradas do catálogo:

Construindo a consulta de alerta de login

Especificamente para a verificação de monitoramento, a abordagem documentada pela Microsoft é uma regra de alerta de log customizado do Log Analytics contra a tabela SigninLogs, indexada pelo Object ID da conta (encontrado em Entra ID → Users → [conta] → Object ID):

// Alert query — any sign-in from an emergency access account
SigninLogs
| where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"
| project TimeGenerated, UserPrincipalName, UserId, IPAddress, ResultType, ResultDescription

Defina o valor de limite do alerta como 0 (maior que), a severidade como 0 – Crítico, e anexe um grupo de ação que envie e-mail e SMS à sua equipe de segurança — porque, segundo a orientação da Microsoft, qualquer login dessa conta deve acionar uma revisão, seja um simulado programado ou um incidente real.

Também colete as entradas do log de auditoria da conta (não apenas o log de login) — mudanças de atribuição de função, registros de credenciais e mudanças de associação em políticas de CA que envolvam a conta são todos eventos que valem alerta independentemente da atividade de login. Se você estiver construindo esse tipo de verificação como parte de uma revisão mais ampla do tenant em vez de uma ação pontual, Como Auditar a Segurança do Microsoft Entra ID percorre o escopo completo de revisão no qual isso se encaixa.

Correção

1. Crie pelo menos duas contas de acesso de emergência. Somente nuvem, domínio *.onmicrosoft.com, não federadas nem sincronizadas. A orientação da Microsoft recomenda duas ou mais para que uma única credencial comprometida ou indisponível não elimine totalmente a capacidade de recuperação.
2. Use autenticação sem senha e resistente a phishing. Passkey (FIDO2) é o método recomendado pela Microsoft; a autenticação baseada em certificado é a alternativa se sua organização já opera uma PKI. Não reutilize o método de MFA que suas contas de admin normais usam — se o push do Microsoft Authenticator é padrão para admins, coloque a conta de emergência em uma chave de hardware FIDO2 em vez disso, para que uma única classe de interrupção ou comprometimento não derrube os dois caminhos ao mesmo tempo.
3. Atribua Global Administrator como permanente, ativo — não elegível — no PIM. Uma conta de emergência protegida por uma etapa de ativação do PIM anula o propósito se o próprio PIM for parte da interrupção.
4. Exclua as contas de toda política de Conditional Access que bloqueie ou restrinja o login. Crie um grupo de segurança dedicado (nome de exemplo da Microsoft: EmergencyAccess) e exclua esse grupo das políticas aplicadas — políticas somente relatório não precisam da exclusão, já que não conseguem bloquear o acesso. Reverifique a lista de exclusão sempre que uma nova política de CA for publicada.
5. Configure o monitoramento de login antes de precisar dele. Construa a regra de alerta do Log Analytics acima, direcione-a para um grupo de ação real (e-mail + SMS, não uma caixa de entrada que ninguém observa), e defina a severidade como Crítica.
6. Armazene as credenciais em um local seguro e com controle de acesso — armazenamento fisicamente separado e à prova de fogo para tokens de hardware ou certificados CBA, acessível a mais de uma pessoa autorizada, não vinculado ao dispositivo de um único funcionário.
7. Valide a cada 90 dias e após qualquer mudança na equipe de admin. Confirme que a conta ainda faz login com sucesso sob a configuração atual de CA, confirme que o alerta ainda dispara, e confirme que a lista de usuários autorizados está atualizada. A orientação da Microsoft é explícita de que essa validação deve ocorrer pelo menos a cada 90 dias e após qualquer mudança de pessoal — uma conta de acesso de emergência que ninguém testou em condições reais de falha não é um controle funcional, é uma suposição.
8. Execute um post-mortem em cada acionamento, simulado ou real, para confirmar que o uso foi autorizado e que as ações tomadas corresponderam ao incidente.

A cobertura break-glass é uma peça de uma base mais ampla de hardening do tenant — veja Azure Tenant Hardening: Corrigindo Configurações Padrão Inseguras para as outras lacunas de configuração padrão que valem a pena fechar junto com esta.

Como a EtcSec Detecta Isso

A auditoria de Entra ID da EtcSec verifica os três modos de falha abordados aqui: PA_NO_EMERGENCY_ACCOUNTS sinaliza tenants sem contas de acesso de emergência qualificadas, PA_EMERGENCY_NO_EXCLUSION (pareado com CA_NO_BREAK_GLASS_EXCLUSION) sinaliza contas ainda dentro do escopo de uma política de Conditional Access aplicada, PA_EMERGENCY_NO_MONITORING sinaliza contas sem configuração correspondente de alerta de login, e PA_EMERGENCY_CREDENTIAL_STALE sinaliza contas cujas credenciais não foram validadas dentro da janela recomendada.