Josimar Hedler
Índice
Na primeira parte desta série, construímos a base da nossa arquitetura de centralização de logs, utilizando o Azure Event Hubs para receber eventos provenientes do Azure Activity Log, permitindo acompanhar operações relacionadas aos recursos e ao Azure RBAC.
Nesta segunda parte, vamos ampliar essa arquitetura trazendo o Microsoft Entra ID como uma nova fonte de eventos. O objetivo é centralizar também informações relacionadas à identidade, como autenticações, alterações em usuários e grupos, aplicações, funções administrativas e outras atividades relevantes dentro do tenant.
Para isso, vamos configurar as Diagnostic Settings do Microsoft Entra ID e direcionar os logs selecionados para o mesmo Azure Event Hub utilizado anteriormente. Dessa forma, começamos a reunir eventos de identidade e de acesso aos recursos Azure dentro de uma arquitetura centralizada, preparando o ambiente para as próximas etapas de monitoramento, análise e segurança.
Atenção: As implementações apresentadas em nossos artigos foram desenvolvidas com base em documentações oficiais e nas boas práticas recomendadas pela Microsoft. Entretanto, enfatizamos que qualquer implementação deve ser previamente testada em ambientes de homologação ou testes para garantir a segurança e a estabilidade do ambiente de produção
Para o artigo não ficar muito longo, vamos direto para o Hands-On
Com a estrutura criada na primeira parte, agora vamos avançar para a integração do Microsoft Entra ID com o Azure Event Hubs, utilizando os recursos que já provisionamos anteriormente, nosso primeiro passo será configurar o envio dos logs do Microsoft Entra ID para o Event Hub.
Configurando o envio dos logs do Microsoft Entra ID
Vá para o portal do Microsoft Entra ID, desça ate a sesção Monitoring & health, depois clique em Diagnostic settings -> Add diagnostic settings
Para este cenário, não vamos selecionar todas as categorias disponíveis no Microsoft Entra ID. O objetivo é manter a coleta direcionada aos eventos mais relevantes para identidade, autenticação, auditoria e Workload Identities, evitando o envio de categorias que não fazem parte do escopo desta arquitetura.
Selecionamos os seguintes logs:
- AuditLogs: registra alterações administrativas realizadas no Microsoft Entra ID, como modificações em usuários, grupos, aplicações, funções e políticas.
- SignInLogs: registra autenticações interativas realizadas pelos usuários.
- NonInteractiveUserSignInLogs: registra autenticações que não exigem interação direta do usuário, como determinados processos de renovação e utilização de tokens.
- ServicePrincipalSignInLogs: permite acompanhar autenticações realizadas por Service Principals e aplicações.
- ManagedIdentitySignInLogs: registra autenticações realizadas por Managed Identities.
- ProvisioningLogs: fornece informações sobre operações de provisionamento e desprovisionamento de identidades.
- RiskyUsers e UserRiskEvents: adicionam visibilidade sobre usuários e eventos de risco identificados pelo Microsoft Entra ID Protection.
- RiskyServicePrincipals e ServicePrincipalRiskEvents: ampliam essa visibilidade para riscos relacionados às Workload Identities.
- MicrosoftGraphActivityLogs: permite acompanhar atividades e requisições realizadas por meio do Microsoft Graph.
Em Destination details, selecionamos Stream to an event hub, pois queremos encaminhar esses eventos para a infraestrutura de centralização criada na Parte 1. Utilizamos a subscription Subscription-Prod, o namespace evhns-identity-monitoring-prd, o Event Hub evh-identity-events e a policy send-policy.
A send-policy possui somente a permissão necessária para envio dos eventos, seguindo o princípio do menor privilégio. Dessa forma, o Microsoft Entra ID atua como produtor dos eventos, enquanto o Azure Event Hubs funciona como a camada de ingestão e distribuição dentro da nossa arquitetura.
Observação: a disponibilidade e a geração de algumas categorias de logs podem variar conforme o licenciamento e os recursos habilitados no Microsoft Entra ID, para saber mais clique aqui.
Validando o recebimento dos eventos no Azure Event Hubs
Após configurar o Diagnostic Setting do Microsoft Entra ID, podemos validar se o Azure Event Hubs está recebendo novas mensagens. Para isso, acesse o Event Hubs Namespace → Monitoring → Metrics e selecione a métrica Incoming Messages.
No exemplo abaixo, realizamos uma alteração no Microsoft Entra ID para gerar uma atividade e, na sequência, observamos o registro de uma nova mensagem no Event Hub, a métrica Incoming Messages confirma que o Event Hub está recebendo dados, porém não permite identificar o conteúdo da mensagem. Na próxima etapa, utilizaremos o Event Hubs Capture para validar os eventos persistidos no Storage Account e confirmar os dados recebidos.
Validando os eventos no Event Hubs Capture
Como o Capture já foi habilitado na Parte 1, não precisamos configurá-lo novamente, agora vamos verificar se os eventos recebidos pelo Event Hub foram persistidos no Storage Account.
No portal do Azure, acesse, Storage accounts → seu Storage Account → Data storage → Containers abra o container que configuramos como destino do Event Hubs Capture, no meu caso já tinha criado na parte 1
Após configurarmos o envio dos logs do Microsoft Entra ID para o Azure Event Hubs, podemos verificar se o Event Hubs Capture está realizando a persistência das mensagens no Storage Account configurado na Parte 1.
Para isso, acesse o Storage Account utilizado na arquitetura e navegue até Data storage → Containers → capture.
Dentro do container, o Event Hubs Capture organiza automaticamente os arquivos seguindo uma estrutura hierárquica que identifica o Event Hubs Namespace, o Event Hub, a partition e o período em que os eventos foram capturados.
No nosso exemplo, podemos observar o caminho: evhns-identity-monitoring-prd / evh-identity-events / 0 / 2026 / 08 / 10 / 18 / 20 / 22.avro
Dentro dele, você deverá encontrar uma estrutura de diretórios criada automaticamente pelo Capture, normalmente organizada pelo namespace, Event Hub, partition e período de captura.
Visualizando os eventos do Microsoft Entra ID no Data Explorer
- Acesse o Event Hubs Namespace utilizado na arquitetura e selecione o Event Hub evh-identity-events.
- No menu lateral, acesse Data Explorer.
- Em Event position, escolha a posição a partir da qual deseja iniciar a leitura dos eventos. A opção Oldest position permite consultar eventos a partir dos mais antigos disponíveis, enquanto Newest position é indicada quando queremos acompanhar os eventos mais recentes que estão chegando ao Event Hub. Também é possível utilizar Custom position para definir uma posição específica.
- Clique em View events para iniciar a leitura, os eventos recebidos serão apresentados na parte direita da tela, contendo informações como Sequence Number, Partition ID, Enqueued Time e Event Body.
Ao selecionar uma mensagem, podemos analisar seu Event Body e identificar a origem e os detalhes do evento, no exemplo abaixo, encontramos eventos provenientes do Microsoft Entra ID, incluindo a categoria NonInteractiveUserSignInLogs, confirmando que os logs configurados anteriormente estão sendo encaminhados corretamente para o Azure Event Hubs.
Dica: como o mesmo Event Hub também recebe os eventos configurados na Parte 1, podemos utilizar o Data Explorer para visualizar, em um único ponto, eventos provenientes tanto do Azure Activity Log quanto do Microsoft Entra ID. Dessa forma, conseguimos observar na prática a centralização dos eventos proposta nesta arquitetura.
Arquitetura final
Com a conclusão desta segunda etapa, passamos a centralizar em uma única arquitetura eventos provenientes de dois contextos diferentes: operações realizadas sobre recursos do Azure, por meio do Azure Activity Log, e eventos de identidade e autenticação do Microsoft Entra ID.
Na Parte 1, configuramos o Azure Activity Log para encaminhar eventos relacionados às operações realizadas nos recursos Azure para o Azure Event Hubs. Também habilitamos o Event Hubs Capture, permitindo a persistência das mensagens recebidas em um Storage Account.
Nesta Parte 2, ampliamos a arquitetura adicionando o Microsoft Entra ID como uma nova fonte de eventos. Por meio do Diagnostic Setting, categorias como AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs e outras selecionadas passaram a ser encaminhadas para o mesmo Event Hub.
Com isso, o Azure Event Hubs atua como camada central de ingestão, recebendo eventos de diferentes fontes, enquanto o Capture permite armazená-los no Storage Account para retenção e processamento posterior.
Conclusão
Nesta segunda parte, evoluímos a arquitetura construída anteriormente adicionando o Microsoft Entra ID como uma nova fonte de eventos.
Por meio do Diagnostic Setting, diferentes categorias de logs de identidade e autenticação passaram a ser encaminhadas para o Azure Event Hubs, permitindo centralizar eventos do Microsoft Entra ID e do Azure Activity Log em uma mesma arquitetura.
Também validamos o funcionamento do fluxo utilizando as métricas do Event Hub, o Event Hubs Capture, a persistência dos arquivos no Storage Account e o Data Explorer, onde foi possível visualizar o conteúdo dos eventos recebidos.
Com isso, concluímos a etapa de coleta, centralização e persistência. Porém, centralizar os eventos é apenas parte do processo. Também precisamos proteger os componentes responsáveis por transportar e armazenar essas informações e transformar os dados coletados em capacidade de monitoramento e detecção.
Próxima etapa Fortalecendo a segurança da arquitetura
Na Parte 3, vamos fortalecer a segurança da arquitetura construída até aqui, revisando os controles aplicados aos seus componentes e integrando os eventos ao Microsoft Sentinel. A partir dessa integração, vamos explorar como os dados centralizados podem contribuir para ampliar a visibilidade, correlação e detecção de atividades relacionadas à identidade e aos recursos do Azure.
Links de referência
Configure as definições de diagnóstico do Microsoft Entra para registos de atividades.
Quais são as opções de integração do registro de atividades do Microsoft Entra?
Como transmitir registros de atividades para um hub de eventos.
Chegamos ao final desta segunda parte!
O que você achou da integração dos eventos do Microsoft Entra ID à arquitetura que construímos?
Sua organização já centraliza eventos do Azure Activity Log e do Microsoft Entra ID, ou utiliza uma arquitetura diferente para monitoramento de identidade e acesso?
Na Parte 3, vamos continuar evoluindo essa arquitetura, desta vez fortalecendo sua segurança e integrando-a ao Microsoft Sentinel.
Compartilhe sua experiência com a comunidade, deixe sua opinião nos comentários e conte como esse tipo de centralização é realizado no seu ambiente.