Fala pessoal, tudo certo?

Recentemente apoiei um cliente na criação das contas de acesso emergencial (as famosas break-glass accounts) no tenant do Microsoft Entra ID. Criar as contas é a parte fácil. O ponto que quase sempre fica para depois — e que a Microsoft trata como obrigatório — é monitorar cada tentativa de uso dessas contas.

Neste artigo mostro, passo a passo, como enviar os sign-in logs do Entra ID para o Log Analytics, criar um Action Group, configurar uma regra de alerta crítica (Sev 0) com KQL e, por fim, validar tudo com um roteiro de testes documentado. Todo o procedimento é baseado na documentação oficial da Microsoft, com os links ao final do post.

Por que monitorar contas break-glass?

Contas break-glass existem para um único cenário: recuperar o acesso administrativo ao tenant quando todo o resto falhou — uma política de Acesso Condicional mal configurada que bloqueou todos os administradores, uma falha no provedor de MFA federado, um incidente que tirou o acesso das contas nominais.

Por definição, essas contas:

• Possuem o papel Global Administrator de forma permanente (não elegível via PIM);
• Normalmente são excluídas de boa parte das políticas de Acesso Condicional;
• Não deveriam ser usadas no dia a dia — nunca.

É exatamente essa combinação que transforma qualquer sign-in nelas em um evento de altíssimo risco. Se a conta foi usada, das duas uma: ou houve uma emergência real (e a equipe precisa saber), ou alguém está tentando abusar dela (e a equipe precisa saber agora). Por isso a recomendação da Microsoft é alertar em qualquer tentativa de sign-in, bem-sucedida ou não.

💡 NOTA: A regra de alerta filtra pelo Object ID da conta, e não pelo UPN. O Object ID é imutável; o UPN pode ser renomeado. Filtrar por UPN abriria uma brecha simples: renomear a conta e o alerta deixa de disparar.

Opções para monitorar as contas

Existem algumas formas de chegar ao mesmo resultado. Neste artigo sigo a abordagem documentada pela Microsoft com Azure Monitor, que funciona em qualquer tenant com Entra ID P1/P2 e um workspace do Log Analytics.

Pré-requisitos

Passo a passo

1. Enviar os sign-in logs do Entra ID para o Log Analytics

Sem esta etapa, a tabela SigninLogs fica vazia no workspace e a regra de alerta simplesmente nunca dispara — sem dar nenhum erro. É o tipo de falha silenciosa que só aparece no pior momento.

1. Acesse o Microsoft Entra admin center como Security Administrator ou Global Administrator.
2. Navegue até Entra ID > Monitoring & health > Diagnostic settings.
3. Clique em + Add diagnostic setting.

4. Dê um nome à configuração, por exemplo send-signinlogs-to-loganalytics.
5. Em Logs, marque no mínimo: SignInLogs, AuditLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs e ManagedIdentitySignInLogs.
6. Em Destination details, marque Send to Log Analytics workspace e selecione a assinatura e o workspace.
7. Clique em Save.

⚠️ ATENÇÃO: Na primeira configuração, a ingestão pode levar de 15 minutos a algumas horas. Não siga para a criação do alerta antes de confirmar que os dados estão chegando.

Para validar, abra o workspace no portal Azure, vá em Logs e execute:

SigninLogs
| where TimeGenerated > ago(1h)
| take 10

Se retornar linhas, está tudo certo. Se continuar vazio por mais de 2 horas, revise o Diagnostic setting.

2. Obter o Object ID das contas break-glass

1. No Entra admin center, vá em Entra ID > Users.
2. Pesquise pela primeira conta break-glass e abra o perfil.
3. Copie o valor de Object ID (formato GUID).
4. Repita para a segunda conta.

💡 ALTERNATIVA VIA POWERSHELL: com o Microsoft Graph PowerShell SDK, os dois IDs saem em um comando:

Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "startsWith(userPrincipalName,'emergency-')" |
    Select-Object UserPrincipalName, Id

Guarde esses IDs em local seguro, junto da documentação das contas de emergência.

3. Criar o Action Group

O Action Group define quem recebe o alerta e por qual canal (e-mail, SMS, push, voz, webhook, Logic App).

1. No portal Azure, abra Monitor > Alerts > Action groups > + Create.
2. Na aba Basics, preencha:
   • Subscription / Resource group: os mesmos do workspace;
   • Region: Global;
   • Action group name: AG-BreakGlas;
   • Display name (máx. 12 caracteres): BG-Alert.

💡 NOTA: Configure pelo menos dois canais distintos — por exemplo, e-mail corporativo + SMS de um celular de plantão. Se o cenário de emergência for justamente uma falha no e-mail, o SMS ainda chega.

4. Criar a regra de alerta de sign-in

1. No portal Azure, abra Monitor > Alerts > + Create > Alert rule.
2. Na aba Scope, clique em Select a resource, filtre por Log Analytics workspaces, selecione o workspace que recebe os logs e clique em Apply.

3. Na aba Condition, em Signal name, selecione Custom log search.
4. Cole a query abaixo, substituindo os GUIDs pelos Object IDs coletados no passo 2:

// Alerta de sign-in em contas break-glass
let breakGlassIds = dynamic([
    "00000000-0000-0000-0000-000000000001",  // emergency-01
    "00000000-0000-0000-0000-000000000002"   // emergency-02
]);
union SigninLogs, AADNonInteractiveUserSignInLogs
| where UserId in (breakGlassIds)
| project TimeGenerated, UserPrincipalName, UserId, IPAddress,
          ResultType, ResultDescription, AppDisplayName, ClientAppUsed

💡 NOTA: A query da documentação da Microsoft consulta apenas SigninLogs (sign-ins interativos). Incluí o AADNonInteractiveUserSignInLogs no union para capturar também a renovação de tokens feita em segundo plano por uma sessão já aberta. Para contas que nunca deveriam ser usadas, mais cobertura é melhor.

8. Na aba Actions, clique em Select action groups e selecione AG-BreakGlass.

8. Na aba Details:
   • Severity: 0 – Critical;
   • Alert rule name: ALT-BreakGlass-SignIn;
   • Description: Alerta crítico – sign-in detectado em conta break-glass;
   • Region: a mesma do workspace;
   • Advanced options: marque Enable upon creation.

5. Alertas complementares: senha e papéis

Além do sign-in, vale alertar quando alguém mexe nas contas: troca de senha e alteração de papéis. Um atacante com acesso privilegiado pode tentar redefinir a senha de uma conta break-glass para usá-la depois. Repita o passo 4 com as queries abaixo, apontando para o mesmo Action Group.

5.1 – Alteração de senha (sugestão de nome: ALT-BreakGlass-PasswordChange, Sev 0):

AuditLogs
| where OperationName in (“Reset user password”, “Change user password”,
“Update user”, “Reset password (self-service)”)
| mv-expand TargetResources
| extend targetUpn = tostring(TargetResources.userPrincipalName)
| where targetUpn in~ (“modelo01@fulanodetal.onmicrosoft.com“, “modelo02@fulanodetal.onmicrosoft.com“)
| project TimeGenerated, OperationName, targetUpn,
InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Result

Ou modelo abaixo

let breakGlassIds = dynamic([
    "00000000-0000-0000-0000-000000000001",
    "00000000-0000-0000-0000-000000000002"
]);
AuditLogs
| where OperationName in ("Reset user password", "Change user password",
                          "Reset password (self-service)", "Change password (self-service)")
| mv-expand TargetResources
| where tostring(TargetResources.id) in (breakGlassIds)
| project TimeGenerated, OperationName,
          TargetUpn   = tostring(TargetResources.userPrincipalName),
          InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
          Result

5.2 – Alteração de papéis (sugestão de nome: ALT-BreakGlass-RoleChange, Sev 0):

AuditLogs
| where OperationName in (“Add member to role”, “Remove member from role”,
“Add eligible member to role”, “Remove eligible member from role”)
| mv-expand TargetResources
| extend targetUpn = tostring(TargetResources.userPrincipalName)
| where targetUpn in~ (“modelo01@fulanodetal.onmicrosoft.com“, “modelo02@fulanodetal.onmicrosoft.com“)
| project
TimeGenerated,
OperationName,
targetUpn,
InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
Result

Ou modelo abaixo

let breakGlassIds = dynamic([
    "00000000-0000-0000-0000-000000000001",
    "00000000-0000-0000-0000-000000000002"
]);
AuditLogs
| where OperationName has_any ("member to role", "member from role")
| mv-expand TargetResources
| where tostring(TargetResources.id) in (breakGlassIds)
| project TimeGenerated, OperationName,
          TargetUpn   = tostring(TargetResources.userPrincipalName),
          InitiatedBy = tostring(InitiatedBy.user.userPrincipalName),
          Result

💡 NOTA: O has_any cobre tanto as operações diretas (Add member to role) quanto as do PIM (Add eligible member to role…). Os nomes exatos de OperationName podem variar entre tenants — rode a query com ago(30d) antes de criar a regra para conferir o que aparece no seu ambiente.

6. Testar e documentar

Alerta que nunca foi testado é só uma expectativa. A Microsoft recomenda validar as contas break-glass e o mecanismo de alerta pelo menos a cada 90 dias. O roteiro que uso é este:

Preparação

• Avise a equipe de SecOps sobre a janela de teste, para não abrir incidente falso;
• Registre data, hora, executor e propósito do teste;
• Tenha em mãos o método de autenticação da conta (FIDO2/passkey ou certificado).

Teste 1 – Validação da query (sem sign-in real)

No workspace, rode a query da regra com janela ampliada:

let breakGlassIds = dynamic([
    "00000000-0000-0000-0000-000000000001",
    "00000000-0000-0000-0000-000000000002"
]);
union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where UserId in (breakGlassIds)

Se as contas nunca foram usadas, o resultado vazio é o esperado. O objetivo aqui é só garantir que a query executa sem erro.

Teste 2 – Sign-in controlado com a primeira conta

1. Em uma estação dedicada (idealmente uma PAW), abra o portal Azure em janela anônima;
2. Faça sign-in com a primeira conta break-glass usando o método passwordless configurado;
3. Anote o horário exato, faça apenas navegação passiva e saia;
4. Aguarde a avaliação da regra e confirme o recebimento do e-mail/SMS;
5. Em Monitor > Alerts, confirme o disparo.

Teste 3 – Segunda conta: repita o teste anterior com a segunda conta, para garantir que os dois Object IDs estão corretos na query.

Teste 4 – Falha intencional (opcional): faça uma tentativa com credencial inválida e confirme que o alerta também dispara.

Registro pós-teste

Todo uso de conta break-glass — inclusive em teste — deve gerar um registro. Documente:

• Data/hora do sign-in e do recebimento do alerta, e a latência entre os dois;
• Canais que dispararam (e-mail, SMS) e quem confirmou o recebimento;
• Ações executadas na conta (nenhuma, no caso de teste);
• Assinatura do executor e do revisor;
• Data do próximo teste (D+90) agendada em calendário compartilhado.

Por dentro das queries

Troubleshooting

Boas práticas em produção

• Trate qualquer alerta como incidente real até prova em contrário. Não existe “falso positivo” para conta break-glass fora de janela de teste.
• Proteja a própria trilha de monitoramento: restrinja quem pode alterar o Diagnostic setting, a regra de alerta e o Action Group. Um atacante que desativa o alerta antes de usar a conta anula todo o trabalho.
• Considere alertar também a remoção do Diagnostic setting (operação registrada nos AuditLogs / Activity Log).
• Use autenticação forte nas contas: a recomendação atual da Microsoft é FIDO2/passkey ou certificado, com métodos diferentes entre as duas contas quando possível.
• Use Object IDs, nunca UPNs, no filtro principal.
• Teste a cada 90 dias e sempre que houver troca na equipe de segurança, nos números de plantão ou no workspace.
• Mantenha a documentação offline: procedimento, IDs e localização das credenciais acessíveis mesmo sem o tenant.

Contribua com a comunidade

Se este conteúdo te ajudou, compartilhe com seu time e deixe nos comentários como vocês monitoram as contas de emergência no seu ambiente. Mais scripts e templates estão disponíveis no meu GitHub: github.com/ErickMedeiros — se algum repositório te for útil, deixa uma ⭐ por lá!

Referências oficiais Microsoft

• Manage emergency access accounts in Microsoft Entra ID
• Integrate Microsoft Entra logs with Azure Monitor logs
• Create or edit a log search alert rule
• Create and manage action groups in the Azure portal
• Security operations for privileged accounts
• SigninLogs table reference
• AuditLogs table reference

Forte abraço pessoal 👊