Entra ID Logs: Retenção, Diagnóstico, SIEM

Registro de Logs do Entra ID: Retenção, Diagnóstico, Exportação SIEM: O Que Está Faltando

Retenção de logs do Entra ID, configurações de diagnóstico, exportação para SIEM — três controles separados, e por padrão nenhum deles faz o que a maioria das equipes assume. Os logs de sign-in e auditoria expiram em dias, não em meses. Nada é roteado para lugar nenhum sem uma configuração de diagnóstico explícita. E a menos que alguém tenha configurado um event hub ou um workspace do Log Analytics, o Microsoft Sentinel ou um SIEM de terceiros nunca vê um único evento do Entra ID.

Essa é uma lacuna de configuração, não uma técnica de ataque — mas é uma das lacunas de maior alavancagem em todo o catálogo do Azure, porque ela decide se todas as outras detecções deste blog são realmente utilizáveis. Uma política de Conditional Access que bloqueia autenticação legada não vale nada para investigar depois do fato se o sign-in que a disparou já expirou do log. Uma detecção de risco do Identity Protection não significa nada para um SOC que não tem um pipeline alimentando seu SIEM.

Quatro achados relacionados fazem parte deste cluster:

• AZ_AUDIT_LOG_RETENTION_SHORT — os logs de auditoria são retidos por menos tempo do que a licença do tenant permite (ou do que uma janela de resposta a incidentes exige).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — os logs de sign-in estão na janela padrão do tier gratuito e desaparecem antes mesmo do início da maioria das linhas do tempo de detecção de violação.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — não existe nenhuma configuração de diagnóstico para rotear os logs para lugar nenhum, então a janela de retenção padrão é a única retenção que existe.
• AZ_NO_SIEM_EXPORT — os logs podem chegar a um workspace do Log Analytics, mas nunca saem dele em direção a um SIEM monitorado, então ninguém está alertando sobre eles.

Como as Lacunas Realmente Acontecem

Retenção é um teto de licença, não uma política que você define

De acordo com a documentação da Microsoft sobre retenção de dados do Microsoft Entra, a janela de retenção nativa para logs de auditoria e sign-in é:

Dois detalhes tornam isso pior do que parece:

1. Mudanças de retenção não são retroativas. A documentação da Microsoft afirma diretamente: ao fazer upgrade de Free para P1/P2, você só recupera o que ainda está dentro da janela gratuita de 7 dias — dados que já expiraram estão perdidos, a menos que tenham sido arquivados anteriormente.
2. Os logs de atividade do Microsoft Graph não estão disponíveis no Entra ID Free e não são retidos por padrão nem no P1/P2 — a própria tabela de retenção da Microsoft os lista como dependentes de integração com armazenamento ou ferramentas de análise desde o primeiro dia; não há uma janela padrão de fallback como existe para os logs de auditoria e sign-in.

Se um incidente é descoberto nove dias depois — uma linha do tempo bem comum para comprometimento baseado em credenciais —, um tenant P1/P2 sem exportação configurada já perdeu a evidência de sign-in dos dois primeiros dias da intrusão, e um tenant Free perdeu quase tudo.

Configurações de diagnóstico são opt-in, por categoria de log, por destino

Rotear logs para fora da janela de retenção padrão do Entra ID exige uma configuração de diagnóstico, feita em Central de administração do Entra → Monitoramento e integridade → Configurações de diagnóstico por alguém com a função Administrador de Segurança (Como configurar as configurações de diagnóstico do Microsoft Entra). Isso não é automático e não cobre "tudo", a menos que cada categoria de log relevante seja explicitamente selecionada.

A Microsoft documenta as categorias de log que podem ser transmitidas, cada uma precisando ser escolhida individualmente (Logs disponíveis para streaming a partir do Microsoft Entra ID) — as relevantes para segurança incluem:

AuditLogs                          SignInLogs
NonInteractiveUserSignInLogs       ServicePrincipalSignInLogs
ManagedIdentitySignInLogs          ProvisioningLogs
ADFSSignInLogs                     RiskyUsers
UserRiskEvents                     RiskyServicePrincipals
ServicePrincipalRiskEvents         RiskyAgents / AgentRiskEvents
NetworkAccessTrafficLogs           MicrosoftGraphActivityLogs
EnrichedOffice365AuditLogs         CustomSecurityAttributeAuditLogs

Um tenant pode ter uma configuração de diagnóstico que encaminha apenas AuditLogs, enquanto SignInLogs, RiskyUsers e UserRiskEvents — as categorias que de fato carregam telemetria de autenticação e risco — permanecem sem roteamento e sujeitas ao teto de 7/30 dias acima. Esse é um estado parcialmente configurado muito comum: alguém ativou o logging uma vez para marcar uma caixinha de compliance, escolheu uma ou duas categorias e nunca mais revisou. A mesma lacuna prejudica diretamente as investigações de atividade de função privilegiada rastreadas pelo Azure PIM — um histórico de ativação só é tão durável quanto o log de auditoria em que foi gravado.

O próprio destino precisa já existir antes que a configuração de diagnóstico possa apontar para ele: um workspace do Log Analytics, um event hub ou uma conta de armazenamento. Os logs podem levar até três dias para começar a aparecer depois que uma configuração é salva, o que importa na hora de validar uma correção.

Um workspace do Log Analytics não é um SIEM

É aqui que AZ_NO_SIEM_EXPORT diverge de AZ_DIAGNOSTIC_SETTINGS_MISSING: um tenant pode ter configurações de diagnóstico totalmente configuradas, despejando cada categoria em um workspace do Log Analytics, e ainda assim ter cobertura de detecção zero — porque ninguém está rodando regras de análise contra esse workspace, ou o workspace nunca foi conectado ao Microsoft Sentinel nem exportado para um SIEM de terceiros (Splunk, Elastic, QRadar) via event hub.

A própria documentação de integração da Microsoft observa que conectar os logs do Entra aos logs do Azure Monitor ativa automaticamente o conector de dados do Microsoft Entra dentro do Microsoft Sentinel (Integrar logs do Microsoft Entra com logs do Azure Monitor) — mas só se o Sentinel estiver implantado nesse mesmo workspace, para começar. Um workspace sem Sentinel (ou uma ingestão de SIEM equivalente) por cima é um arquivo apenas de gravação: os dados estão sendo retidos, mas ninguém, e nada, está olhando para eles.

Detecção

Verifique cada uma das quatro lacunas de forma independente — um tenant frequentemente tem algumas corrigidas, mas não todas.

1. Confirme o que realmente está configurado, não o que você assume que está. Na central de administração do Entra, vá em Monitoramento e integridade → Configurações de diagnóstico e verifique cada configuração existente: quais categorias de log estão selecionadas e para qual destino elas apontam. Se a lista estiver vazia, AZ_DIAGNOSTIC_SETTINGS_MISSING se aplica imediatamente — o tenant está rodando apenas com a retenção padrão.

2. Verifique o teto de retenção definido pela licença em relação aos seus requisitos reais de resposta a incidentes. Uma janela de 7 dias no Entra ID Free, ou mesmo a janela de 30 dias no P1/P2, é curta comparada às estatísticas típicas de tempo de permanência em intrusões baseadas em identidade — se nada a estende, marque AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Verifique se os dados estão realmente chegando ao Log Analytics, não apenas se uma configuração existe. No Sentinel ou em um workspace conectado, execute:

SigninLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

AuditLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

Note que os nomes das tabelas no Log Analytics usam SigninLogs ("i" minúsculo), diferente do nome da categoria de configuração de diagnóstico SignInLogs — uma fonte comum de confusão do tipo "por que minha consulta está vazia". Se LastEvent estiver desatualizado ou a tabela não existir, a configuração de diagnóstico não foi salva, não inclui essa categoria, ou está apontando para um workspace diferente daquele que você está consultando.

4. Confirme o lado do SIEM, não apenas o pipe. Se o Microsoft Sentinel for o destino, verifique em Conectores de dados → Microsoft Entra ID se aparece conectado, com SignInLogs e AuditLogs ambos ativados — isso é um switch separado, distinto da configuração de diagnóstico do lado do Entra, e ambos precisam apontar para o mesmo workspace. Para um SIEM de terceiros, confirme se o event hub realmente tem um grupo de consumidores ativo lendo dele, não apenas que a configuração de diagnóstico lista um event hub como destino.

5. Para coleta programática de evidências, o Microsoft Graph PowerShell SDK expõe os dados subjacentes diretamente, independente de qualquer pipeline de SIEM, o que é útil para confirmar o que o próprio Entra ID mantém atualmente:

# Confirmar até onde os dados de sign-in retrocedem atualmente
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Mesma verificação para eventos de auditoria de diretório
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Remediação

1. Monte o destino primeiro. Crie (ou identifique) um workspace do Log Analytics e, se também for necessário armazenamento frio de longo prazo, uma conta de armazenamento separada — as configurações de diagnóstico precisam que o destino já exista antes de poderem apontar para ele.
2. Crie a configuração de diagnóstico com cada categoria relevante para segurança selecionada, não apenas AuditLogs. No mínimo: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Adicione ADFSSignInLogs e ProvisioningLogs se forem aplicáveis ao seu ambiente.
3. Conecte o workspace ao Microsoft Sentinel (ou ao grupo de consumidores de event hub do seu SIEM) e confirme que o conector de dados do Microsoft Entra ID mostra SignInLogs e AuditLogs ambos conectados — um workspace recebendo dados sem nenhum SIEM os lendo fecha AZ_DIAGNOSTIC_SETTINGS_MISSING, mas deixa AZ_NO_SIEM_EXPORT aberto.
4. Estenda a retenção além do teto da licença configurando a política de retenção própria do workspace do Log Analytics ou da conta de armazenamento, independentemente do padrão de 7/30 dias do Entra ID — a janela de retenção do Entra ID deixa de importar assim que os dados passam a residir no Azure Monitor. Organizações com licenciamento Microsoft 365 E5 / Purview Suite podem, alternativamente, estender a retenção via Microsoft Purview Audit (Premium).
5. Execute novamente as consultas de detecção acima depois de salvar a configuração — dê até três dias para os dados aparecerem antes de concluir que falhou — e confirme que LastEvent em SigninLogs / AuditLogs está atual, não apenas que a consulta retorna algumas linhas.
6. Documente quem é dono da revalidação. Configurações de diagnóstico driftam silenciosamente: uma migração de workspace, um onboarding do Sentinel que esqueceu de reapontar o conector, ou uma licença do Purview vencida podem parar o pipeline silenciosamente, sem nenhum erro visível na central de administração do Entra.

Como o EtcSec Detecta Isso

O EtcSec verifica AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING e AZ_NO_SIEM_EXPORT em toda auditoria de Azure/Entra ID — confirmando não apenas que uma configuração de diagnóstico existe, mas quais categorias de log ela realmente encaminha e se o destino é monitorado pelo seu SOC. Essa é uma verificação complementar ao panorama mais amplo de hardening do tenant coberto em como auditar a segurança do Microsoft Entra ID e na baseline de fortalecimento do tenant Azure.