A ingestão de logs no Microsoft Sentinel é um dos processos fundamentais para quem trabalha com monitoramento de segurança e análise de ameaças em ambientes cloud. Quando você configura corretamente como fazer ingestão de logs no Microsoft Sentinel, consegue coletar dados de múltiplas fontes — desde aplicações on-premises até serviços em nuvem — e centralizá-los em um único repositório para análise em tempo real. Isso é essencial para detectar padrões anormais, investigar incidentes de segurança e manter a conformidade regulatória da sua organização.
O processo envolve diferentes métodos de conexão e conectores pré-configurados que o Sentinel oferece nativamente, além de opções personalizadas para dados não estruturados. Compreender as melhores práticas de ingestão garante que você não perca informações críticas e otimiza a performance da sua solução SIEM. Profissionais que dominam essa configuração se destacam no mercado, especialmente em funções de administrador de segurança, analista de SOC e engenheiro de cloud.
Neste guia, você aprenderá os passos práticos para configurar a ingestão de logs, explorar os principais conectores disponíveis e implementar estratégias eficientes de coleta de dados.
O que é ingestão de logs no Microsoft Sentinel e por que ela é essencial?
A ingestão de logs é o processo pelo qual o Microsoft Sentinel recebe, processa e armazena dados de eventos provenientes de diferentes fontes — sistemas operacionais, aplicações, firewalls, serviços em nuvem, endpoints e muito mais. Sem esse fluxo de dados, o Sentinel é apenas uma plataforma vazia: toda a capacidade de detecção de ameaças, correlação de eventos e resposta automatizada depende diretamente da qualidade e abrangência dos logs que chegam ao sistema.
O Sentinel funciona sobre o Azure Log Analytics Workspace, que é o repositório central onde os logs são armazenados e consultados via linguagem KQL (Kusto Query Language). A ingestão conecta essas duas camadas: coleta os dados na fonte, transmite ao workspace e os disponibiliza para regras analíticas, workbooks, playbooks e investigações manuais.
Do ponto de vista de segurança, a ingestão bem configurada é o que diferencia um SOC eficiente de um ambiente com pontos cegos. Fontes não conectadas representam vetores de ataque invisíveis. Por isso, planejar quais logs ingerir, como ingerir e com qual custo é uma das decisões mais estratégicas na implantação do Sentinel.
Pré-requisitos antes de começar a ingerir logs no Microsoft Sentinel
Workspace do Log Analytics: como criar e vincular ao Sentinel
O primeiro passo é ter um Log Analytics Workspace criado e vinculado ao Sentinel. No portal do Azure, acesse Microsoft Sentinel e clique em Criar. Você pode criar um novo workspace nesse momento ou selecionar um existente. Recomenda-se criar um workspace dedicado ao Sentinel para facilitar o controle de custos e permissões, evitando misturá-lo com logs de monitoramento de infraestrutura genérica.
Ao criar o workspace, defina a região com cuidado: logs de compliance muitas vezes exigem que os dados permaneçam em uma geografia específica. Após a criação, o Sentinel é habilitado sobre esse workspace com um único clique, e a partir desse momento o ambiente já está pronto para receber conectores.
Permissões e funções necessárias no Azure
Para configurar conectores e gerenciar a ingestão, o usuário precisa de permissões adequadas em dois níveis:
- Microsoft Sentinel Contributor: permite habilitar conectores, criar regras analíticas e gerenciar workbooks dentro do Sentinel.
- Log Analytics Contributor: necessário para criar tabelas customizadas, configurar Data Collection Rules e gerenciar o workspace.
- Owner ou User Access Administrator: exigido quando um conector precisa conceder permissões em recursos do Azure, como assinar diagnósticos de um recurso específico.
Para conectores que integram serviços como Microsoft Entra ID (antigo Azure AD), é comum que o administrador global ou um administrador de segurança precise autorizar a coleta de logs de auditoria e de sign-in. Verifique as permissões necessárias na documentação de cada conector antes de iniciar.
Principais métodos de ingestão de logs no Microsoft Sentinel
Conectores de dados nativos: como habilitar fontes Microsoft (Azure AD, Defender, Office 365)
Os conectores nativos são a forma mais simples e recomendada de começar. No painel do Sentinel, acesse Configuração > Conectores de dados e filtre por “Microsoft”. Você encontrará conectores prontos para:
- Microsoft Entra ID: logs de sign-in, auditoria e provisionamento. Basta autorizar a coleta e selecionar quais categorias de log deseja ingerir.
- Microsoft Defender XDR: alertas, incidentes e dados de hunting avançado de endpoints, e-mail, identidade e aplicações.
- Office 365: atividades de Exchange, SharePoint e Teams.
- Azure Activity: operações no plano de controle do Azure (criação de recursos, alterações de políticas etc.).
Para habilitar, clique no conector desejado, leia os pré-requisitos e clique em Abrir página do conector. A maioria exige apenas que você clique em um botão de autorização e selecione as categorias de log. O status muda para “Conectado” em poucos minutos.
Conectores via CEF e Syslog: ingestão de appliances e sistemas Linux
Syslog é o protocolo padrão de envio de logs em sistemas Linux e em muitos appliances de rede. CEF (Common Event Format) é uma extensão do Syslog com campos padronizados, amplamente usada por firewalls e sistemas de segurança.
Para ingerir via Syslog ou CEF, você precisa de uma máquina Linux atuando como log forwarder (coletora). Essa máquina recebe os logs dos dispositivos na rede e os encaminha ao Sentinel via agente. O processo geral é:
- Provisionar uma VM Linux (Ubuntu ou RHEL são recomendados) com acesso de rede aos dispositivos de origem.
- Instalar o Agente do Azure Monitor (AMA) na VM.
- Configurar o rsyslog ou syslog-ng para receber logs na porta 514 e encaminhá-los ao agente.
- No Sentinel, habilitar o conector CEF ou Syslog e criar uma DCR apontando para essa máquina.
Para CEF, execute o script de instalação disponível na página do conector dentro do Sentinel, que automatiza parte da configuração do forwarder.
API de ingestão de logs (Data Collection Rules – DCR): passo a passo
A Logs Ingestion API (anteriormente chamada de Data Collector API) permite enviar logs customizados diretamente ao workspace via requisições HTTP POST autenticadas. É ideal para aplicações proprietárias, scripts e pipelines de dados que precisam enviar eventos ao Sentinel sem um agente instalado.
O fluxo moderno usa Data Collection Rules (DCR) e um Data Collection Endpoint (DCE):
- Crie um DCE no portal do Azure (Monitor > Data Collection Endpoints).
- Crie uma DCR do tipo “Direct Ingestion” e associe-a ao DCE e à tabela de destino.
- Registre um aplicativo no Entra ID e conceda a ele a função Monitoring Metrics Publisher na DCR.
- Envie os logs via POST para o endpoint da DCR, incluindo o token de acesso OAuth 2.0 no cabeçalho.
Essa abordagem é mais segura e flexível do que a API legada (HTTP Data Collector API), pois permite transformações inline e controle granular de destino.
Agente do Azure Monitor (AMA): instalação e configuração para coleta de logs
O Azure Monitor Agent (AMA) substituiu os agentes legados MMA e OMS e é hoje o método recomendado para coletar logs de VMs Windows e Linux, tanto no Azure quanto on-premises via Azure Arc. Sua configuração é feita inteiramente por DCRs, sem necessidade de editar arquivos de configuração locais.
Para instalar o AMA em uma VM Azure, acesse a VM no portal, vá em Extensões + aplicativos e adicione a extensão AzureMonitorWindowsAgent ou AzureMonitorLinuxAgent. Para máquinas on-premises, primeiro integre-as ao Azure Arc e depois instale o agente da mesma forma. Após a instalação, crie ou associe uma DCR que define quais logs coletar (Event Logs do Windows, Syslog do Linux, logs de segurança) e qual workspace é o destino.
Ingestão de logs customizados via Logstash e conectores de terceiros
O Logstash é um pipeline de processamento de dados open-source que possui um plugin oficial de output para o Microsoft Sentinel (microsoft-sentinel-logstash-output-plugin). Ele é especialmente útil quando você precisa coletar logs de fontes heterogêneas, aplicar transformações complexas (parsear campos, mascarar dados sensíveis, enriquecer com GeoIP) antes de enviar ao Sentinel.
A configuração básica envolve definir um input (arquivo, Beats, Kafka, banco de dados), um filter com as transformações desejadas e o output apontando para o DCE e a DCR do Sentinel, autenticado via service principal do Entra ID.
Integração com soluções de parceiros (ex.: SonicWall, Palo Alto, Fortinet)
O Sentinel possui um ecossistema rico de conectores de parceiros disponíveis no Content Hub (antigo Solutions). Para firewalls como Palo Alto, Fortinet, SonicWall, Check Point e outros, o processo típico é:
- Instalar a solução do parceiro no Content Hub, que traz o conector, regras analíticas, workbooks e playbooks prontos.
- Configurar o appliance para enviar logs via CEF/Syslog para o log forwarder Linux.
- Habilitar o conector específico do parceiro no Sentinel, que já sabe como parsear o formato proprietário do dispositivo.
Essa abordagem reduz significativamente o tempo de implementação e garante que os campos dos logs sejam mapeados corretamente para o schema do Sentinel.
Como configurar transformações de dados durante a ingestão (Data Transformation)
O que são Data Collection Rules (DCR) e como usá-las para filtrar e transformar logs
As Data Collection Rules são objetos do Azure Monitor que definem o que coletar, como transformar e para onde enviar os dados. A grande vantagem das DCRs é a possibilidade de aplicar transformações KQL inline durante a ingestão — antes que os dados sejam gravados no workspace — o que permite:
- Descartar eventos desnecessários (ex.: eventos de logon bem-sucedidos de contas de serviço conhecidas).
- Filtrar campos sensíveis antes do armazenamento.
- Adicionar colunas calculadas ou enriquecer dados.
- Rotear diferentes tipos de eventos para tabelas distintas.
A transformação é definida no campo transformKql da DCR usando uma expressão KQL que recebe a tabela source e retorna as linhas e colunas desejadas. Por exemplo, para descartar eventos com EventID 4624 de uma conta específica, você usaria: source | where not (EventID == 4624 and Account == "svc_backup").
Criando tabelas customizadas no Log Analytics para logs personalizados
Quando nenhuma tabela nativa do Sentinel atende ao formato do seu log, você pode criar tabelas customizadas (Custom Tables) no Log Analytics. O nome da tabela deve terminar com o sufixo _CL (Custom Log). O processo moderno é feito via portal:
- Acesse o Log Analytics Workspace > Tabelas > Criar > Nova tabela customizada.
- Faça upload de um arquivo JSON de exemplo com a estrutura dos logs para que o Azure infira o schema.
- Revise e ajuste os tipos de dados das colunas.
- Crie uma DCR associada a essa tabela para definir como os dados chegarão a ela.
Tabelas customizadas podem ser classificadas como Analytics (custo padrão, suportam alertas e workbooks), Basic (custo reduzido, retenção curta, apenas consultas ad-hoc) ou Auxiliary (custo mínimo, para logs de alto volume e baixo valor analítico).
Gerenciando custos da ingestão de logs no Microsoft Sentinel
Como o modelo de precificação do Sentinel funciona (por GB ingerido x Commitment Tiers)
O Microsoft Sentinel cobra separadamente do Log Analytics Workspace, e ambos incidem sobre o volume de dados ingeridos. O modelo padrão é Pay-As-You-Go (por GB), mas para volumes previsíveis, os Commitment Tiers oferecem descontos significativos a partir de 100 GB/dia. Quanto maior o tier contratado, maior o desconto por GB. É fundamental monitorar o volume diário para identificar o tier mais econômico.
Tabelas de log auxiliares e básicas: como reduzir custos sem perder visibilidade
A Microsoft introduziu dois planos de tabela alternativos para reduzir custos:
- Basic Logs: custo de ingestão ~80% menor que o Analytics. Suportam retenção de até 8 dias e consultas ad-hoc limitadas. Ideais para logs de verbose (ex.: logs de acesso a CDN, logs de diagnóstico detalhados).
- Auxiliary Logs: custo ainda menor, para logs de altíssimo volume e baixíssimo valor de alerta, com retenção configurável e consultas via Search Jobs.
A estratégia é manter em tabelas Analytics apenas os logs que alimentam regras de detecção e investigações frequentes, movendo o restante para Basic ou Auxiliary.
Benefício de ingestão gratuita com Microsoft 365 E5: o que está incluso
Clientes com licenciamento Microsoft 365 E5, E5 Security ou Microsoft Defender XDR têm direito a um benefício de ingestão gratuita no Sentinel para dados específicos. Os tipos de dados cobertos incluem logs do Microsoft Entra ID (sign-in e auditoria), alertas do Defender for Endpoint, Defender for Office 365, Defender for Identity e Defender for Cloud Apps. O volume gratuito é proporcional ao número de usuários licenciados (aproximadamente 5 MB/usuário/dia para o conjunto de fontes elegíveis).
Como estimar o volume de ingestão e usar a calculadora de preços do Azure
Antes de habilitar conectores em produção, estime o volume esperado. Use a Calculadora de Preços do Azure (azure.microsoft.com/pricing/calculator) selecionando Microsoft Sentinel e Log Analytics. Para fontes já conectadas, consulte a tabela Usage no workspace com a query: Usage | summarize sum(Quantity) by DataType, Solution. Isso mostra o volume por fonte nos últimos dias e permite projetar o custo mensal com precisão.
Boas práticas para otimizar a ingestão de logs no Microsoft Sentinel
Filtrando logs desnecessários antes da ingestão para reduzir ruído e custo
Ingerir tudo indiscriminadamente é o erro mais comum e caro na implantação do Sentinel. Antes de habilitar um conector, questione: esse log alimenta alguma regra de detecção ou investigação real? Use transformações nas DCRs para descartar eventos de baixo valor antes da gravação. Para eventos do Windows, evite ingerir todos os níveis de auditoria — foque nos eventos de segurança críticos (logons, alterações de privilégio, criação de processos) e descarte ruído como eventos informativos de serviços conhecidos.
Monitorando o volume de ingestão com workbooks e alertas de custo
O Sentinel oferece o workbook Workspace Usage Report (disponível na galeria de workbooks) que mostra o volume ingerido por tabela, tendências ao longo do tempo e projeções de custo. Complemente com alertas de orçamento no Azure Cost Management: configure um alerta para notificar quando o gasto mensal atingir 80% do orçamento previsto. Isso evita surpresas na fatura e permite agir antes que o custo escape ao controle.
Estratégia de retenção de logs: hot, warm e cold storage no Azure Monitor
O Azure Monitor oferece três camadas de retenção:
- Interactive Retention (hot): padrão de 90 dias para tabelas Analytics, com consultas rápidas e suporte total a alertas. Configurável até 2 anos.
- Long-term Retention (warm/cold): dados são arquivados por até 12 anos a um custo muito menor. Acessíveis via Search Jobs ou Restore, que trazem os dados de volta para a camada interativa temporariamente.
Defina políticas de retenção por tabela conforme os requisitos de compliance (ex.: PCI-DSS exige 1 ano, ISO 27001 recomenda ao menos 3 meses de acesso imediato). Não mantenha tudo na camada interativa por mais tempo do que o necessário.
Solução de problemas comuns na ingestão de logs no Microsoft Sentinel
Logs não aparecem no Sentinel: causas e como diagnosticar
Quando logs esperados não aparecem, siga esta sequência de diagnóstico:
- Verifique o status do conector: na página do conector no Sentinel, o campo “Últimos dados recebidos” indica quando o último log chegou.
- Consulte a tabela Heartbeat: para agentes AMA, execute
Heartbeat | where TimeGenerated > ago(1h)para confirmar que o agente está ativo e comunicando. - Verifique conectividade de rede: o agente ou forwarder precisa de acesso HTTPS à porta 443 para os endpoints do Azure Monitor. Firewalls e proxies são causas frequentes de bloqueio.
- Revise a DCR: uma transformação KQL mal escrita pode descartar todos os eventos. Teste a query de transformação isoladamente no Log Analytics.
- Verifique permissões: o service principal ou a identidade gerenciada usada pelo agente precisa da função correta na DCR.
Latência na ingestão: o que esperar e como monitorar
O Sentinel não é uma ferramenta de streaming em tempo real. A latência típica de ingestão varia de 2 a 5 minutos para a maioria das fontes, podendo chegar a 10-15 minutos em picos de carga ou para fontes via CEF/Syslog com forwarder intermediário. Para monitorar a latência real, use a query: SecurityEvent | extend Latency = ingestion_time() - TimeGenerated | summarize avg(Latency) by bin(TimeGenerated, 1h). Se a latência consistentemente ultrapassar 15 minutos, investigue a saúde do agente, a capacidade do forwarder e possíveis gargalos de rede.
Perguntas Frequentes sobre ingestão de logs no Microsoft Sentinel
Qual é o limite de tamanho de log suportado pelo Microsoft Sentinel?
O limite máximo por registro (linha de log) na Logs Ingestion API é de 1 MB. Para o agente AMA e conectores nativos, o limite prático é similar. Logs que excedam esse tamanho precisam ser fragmentados antes do envio. O tamanho máximo de um lote de requisição via API é de 1 GB, mas na prática lotes menores (alguns MB) garantem melhor desempenho e confiabilidade.
É possível ingerir logs de ambientes on-premises no Microsoft Sentinel?
Sim. Para servidores on-premises, a abordagem recomendada é integrar as máquinas ao Azure Arc, o que permite instalar o AMA e gerenciar DCRs como se fossem recursos nativos do Azure. Para appliances de rede sem suporte a agente, configure um servidor Linux on-premises como log forwarder CEF/Syslog, com conectividade de saída para os endpoints do Azure Monitor. Essa arquitetura é amplamente usada em ambientes híbridos e é totalmente suportada pela Microsoft. Se você está começando a construir uma carreira em cibersegurança defensiva com ferramentas Microsoft, entender essa arquitetura híbrida é um diferencial importante.
Qual a diferença entre o agente MMA (antigo) e o AMA (novo)?
O MMA (Microsoft Monitoring Agent), também chamado de agente OMS ou Log Analytics Agent, é o agente legado que será descontinuado. Ele usa um modelo de configuração baseado em workspace (as configurações ficam no próprio workspace) e não suporta transformações inline. O AMA (Azure Monitor Agent) é o substituto moderno: usa DCRs para configuração centralizada e granular, suporta múltiplos destinos e transformações durante a ingestão, tem menor footprint de recurso e é o único suportado para novos cenários. A Microsoft encerrou o suporte ao MMA em agosto de 2024, portanto toda nova implantação deve usar exclusivamente o AMA. Para quem deseja aprofundar os conhecimentos em segurança Microsoft e entender como essas peças se conectam ao ecossistema de identidade, vale conhecer também a diferença entre Microsoft Entra ID e Azure AD e como os logs de identidade se integram ao Sentinel para detecção de acessos suspeitos e riscos de login.
