O Microsoft Sentinel é a plataforma SIEM da Microsoft para centralizar logs, correlacionar eventos, detectar ameaças, organizar incidentes e automatizar respostas em ambientes locais, multicloud e Microsoft. Seu funcionamento depende de cinco decisões: quais dados ingerir, como detectar desvios, como tratar incidentes, o que automatizar e quanto manter armazenado.
O Microsoft Sentinel resolve um problema recorrente de segurança: evidências distribuídas entre firewall, endpoints, Microsoft 365, servidores, identidades e dispositivos de rede. A plataforma reúne esses sinais em uma camada central de análise, permitindo relacionar eventos que, observados isoladamente, dificilmente revelariam a sequência completa de um incidente.
O valor do SIEM, porém, não está apenas em concentrar logs. A arquitetura precisa definir quais fontes entram, como os dados são normalizados, quais regras geram alertas, quando um alerta vira incidente e quais respostas podem ser automatizadas. Essas escolhas também determinam o volume de ingestão, a retenção e o comportamento da fatura.
O conteúdo detalha a arquitetura do Microsoft Sentinel, os mecanismos de detecção e investigação, o uso de SIEM, SOAR e UEBA, o modelo de cobrança e os critérios para avaliar quando a plataforma faz sentido para uma empresa de médio porte.
O Microsoft Sentinel em uma definição
Existem outros produtos chamados Sentinel no mercado, e o objeto aqui é um só: a plataforma da Microsoft executada sobre o Azure. A documentação oficial descreve o produto como solução SIEM nativa da nuvem para ambientes multicloud e multiplataforma, que combina IA, automação e informações sobre ameaças. O nome antigo era Azure Sentinel. Ficou para trás.
SIEM, SOAR e UEBA: o que cada sigla resolve
SIEM centraliza log de origens diferentes, normaliza o formato, correlaciona eventos e gera alerta; SOAR é a camada seguinte, com orquestração, automação e resposta. Uma enxerga, a outra age. UEBA é o terceiro componente, e usa perfil de comportamento no lugar de regra fixa.
Os três vêm no mesmo produto, junto com o data lake. Não há três contratos e três integrações para manter.
O que “nativo de nuvem” muda
Não há appliance para comprar, dimensionar e trocar daqui a três anos. A capacidade acompanha o volume ingerido. Sai o investimento grande com ciclo de renovação, entra o custo recorrente proporcional ao dado.
Para o CFO, muda o comportamento da conta. Despesa de appliance é alta e rara; custo de ingestão é baixo, mensal e cresce sozinho quando ninguém olha.
O que o Microsoft Sentinel não é
Quatro confusões aparecem em toda reunião de escopo, e cada uma custa dinheiro.
- Não é antivírus. O SIEM lê o que o agente do endpoint reporta; não mata processo na máquina.
- Não é um centro de operações. O Sentinel é ferramenta; operação é gente, turno e processo.
- Não é backup. Log de segurança reconstrói evento, não restaura arquivo de negócio.
- Não é monitoramento de infraestrutura. O NOC olha disponibilidade; o SIEM olha comportamento hostil.
Cabe um quinto: Sentinel não é Defender. O Defender protege endpoint, identidade e correio; o Sentinel correlaciona o sinal deles e o de terceiros. Alimentado, encerra a pergunta “onde está o log disso?”.
Como os dados entram no Microsoft Sentinel
Todo o valor do Sentinel depende de uma decisão anterior à tecnologia: qual dado entra. A plataforma não descobre sozinha o que importa no seu ambiente. Ela processa o que foi conectado, cobra pelo que entrou e ignora o resto.
Conectores prontos, CEF, Syslog e API
São mais de 350 conectores prontos para uso, com integração em tempo real, e mais de 400 no total; para origem sem conector nativo restam três caminhos: Common Event Format, Syslog e REST API. Quando nem isso resolve, escreve-se um conector personalizado.
Ligar conector é fácil. Escolher qual ligar é que custa.
O workspace do Log Analytics e a normalização
O Sentinel não guarda dado em lugar próprio: roda sobre um workspace do Azure Monitor Log Analytics, a unidade de armazenamento, de consulta, de retenção e de cobrança. Quem desenha workspace desenha fatura.
Cada origem nomeia o mesmo campo de um jeito, e a normalização ASIM resolve isso na ingestão e na consulta, para que uma regra escrita uma vez rode sobre fontes distintas.
Dado primário e dado secundário: a decisão que define a fatura
A documentação de planos de log separa dois tipos. Dado primário de segurança carrega valor crítico e precisa ficar disponível para detecção em tempo quase real. Dado secundário é suplementar: volumoso, verboso, de valor unitário baixo, indispensável só para remontar o quadro completo de um incidente. A Microsoft lista os suspeitos de sempre: storage em nuvem, NetFlow, TLS e SSL, firewall, proxy e IoT.
Classificar errado um log de firewall é o erro mais caro do projeto: ele entra na camada cara e aparece na fatura antes de aparecer numa investigação.
Escolher o que ingerir é decisão de orçamento tomada por engenharia. Nenhum desconto conserta escolha errada.
Como a detecção acontece
Dado ingerido não detecta nada sozinho. A detecção mora nas regras de análise, que consultam o dado e produzem alerta, e no motor que junta alerta solto em caso investigável. A documentação de detecção de ameaças descreve os tipos.
Os tipos de regra de análise
Regras agendadas rodam consultas Kusto sobre o dado bruto de um período de lookback definido, o formato mais usado; regras near-real-time rodam uma vez por minuto, para o que não pode esperar o agendamento. Regras de anomalia constroem linha de base por machine learning e gravam na tabela de anomalias, sem gerar alerta próprio: servem de insumo para outras regras e para caça.
Acima delas está o Fusion, que correlaciona muitos alertas de baixa fidelidade em incidentes de alta fidelidade e acionáveis. As regras de inteligência de ameaças cruzam indicadores de domínio, endereço e URL com o log.
Fidelidade decide se alguém abre o caso. Cem alertas medianos por dia produzem zero investigação.
KQL: a linguagem que faz a consulta
Kusto Query Language é a língua da casa: escreve regra, escreve caça, consulta o data lake, e sem alguém que escreva KQL a empresa fica com as regras prontas do content hub. Elas funcionam, e param onde o seu ambiente deixa de ser o ambiente médio.
UEBA: quando o desvio é a pista
A análise de comportamento de entidades usa machine learning para construir perfis dinâmicos de usuários, hosts, endereços IP e aplicações. Em vez de checar se a ação é proibida, checa se ela é típica daquela entidade, e o que rende bem é conta comprometida, ataque de origem interna e movimento lateral. Os scores saem em duas escalas, de 0 a 10 e de 0 a 1.
O UEBA vem incluído sem custo extra e depende de conectores de identidade ligados. Sem log de identidade não há linha de base.
A plataforma ainda mapeia a cobertura contra o framework MITRE ATT&CK: mostra quais táticas e técnicas têm regra ativa e quais seguem descobertas. Menos alerta inútil é menos hora de gente cara em triagem.
Do alerta ao incidente
Alerta isolado é sinal. Incidente é caso. A distância entre os dois separa a ferramenta que gera ruído da que organiza trabalho.
Alerta, incidente e grafo de entidades
Os alertas são agregados e correlacionados em incidentes, os arquivos de caso que podem ser atribuídos a um responsável e investigados. Dentro do incidente, o grafo de entidades mostra a relação entre usuário, host, endereço e arquivo, e deixa navegar pelo evento em vez de ler linha de log.
É daqui que sai a métrica de operação. Incidente aberto, atribuído, tratado e fechado é unidade contável. Alerta não é.
Regras de automação e playbooks sobre Logic Apps
Regras de automação centralizam o tratamento: aplicam a mesma decisão a todo incidente que casa com um critério, atribuem responsável, mudam severidade e disparam playbook. Os playbooks são fluxos de trabalho criados no Azure Logic Apps, com conectores para ferramentas de chamado como ServiceNow e Jira.
Os usos são pouco glamourosos e muito úteis: abrir o chamado, enriquecer a entidade, avisar o responsável, isolar um host. O Azure Logic Apps tem cobrança própria, separada do Sentinel. Ainda assim, automação bem feita custa menos que a hora de analista que ela dispensa.
O limite da automação
Automação fecha o que já se sabe. Conta de diretor financeiro acessada de madrugada, de outro estado, com regra de encaminhamento nova na caixa postal, pede alguém que ligue para o diretor. Nenhum playbook faz essa ligação.
O tempo entre detectar e conter determina o tamanho do prejuízo, e esse tempo depende de haver alguém olhando a fila.
Quanto custa: o modelo de cobrança por volume
Aqui vem a objeção número um, e ela é legítima: o medo da fatura sem teto. O modelo de cobrança é público. O valor unitário não é. A Microsoft não exibe número na página de preços, remete à calculadora oficial e avisa que a tarifa muda por região, moeda e contrato. Preço por GB de agregador de terceiros é estimativa com cara de tabela.
Pagamento por uso e compromisso diário
O pagamento por uso é o padrão, calculado sobre o volume real de dado armazenado, medido em GB. O tier de compromisso é o outro caminho: a empresa compromete um volume diário fixo, a partir de 100 GB por dia, e paga menos por GB. A Microsoft indica economia de até 52% sobre a tarifa de uso.
Uma regra estrutural vale mais que o desconto. O tier sobe quando você quiser, mas só cai a cada 31 dias. Quem contrata compromisso sem conhecer o próprio padrão de ingestão compra um mês de arrependimento.
O que entra sem custo de ingestão
Parte do dado mais útil não é cobrada na entrada: Azure Activity, o monitoramento de saúde do próprio Sentinel, os logs de auditoria do Office 365 em SharePoint, Exchange e Teams, e os alertas das soluções Defender.
A pegadinha está na mesma página. Alerta é gratuito, log bruto de vários desses produtos não é. Quem lê só a primeira metade erra a estimativa em ordem de grandeza.
Retenção: 90 dias e o que vem depois
Todo dado ingerido fica retido sem cobrança adicional nos primeiros 90 dias; depois, vale a tarifa padrão de retenção do Log Analytics. No analytics tier, a retenção interativa padrão é de 90 dias e se estende por até dois anos, com prazo configurável por tabela. O histórico mais antigo vai para o data lake tier, cobrado por GB ao mês, com compressão uniforme de 6 para 1 e consulta cobrada por GB descomprimido varrido.
Retenção é onde a conformidade encontra o orçamento. Guardar tudo por dois anos na camada cara é decisão que ninguém defende depois de ver a fatura.
Três escolhas controlam o custo, todas de engenharia: o que ingerir, em qual camada e por quanto tempo. Serviços vizinhos escapam do orçamento: Azure Logic Apps e as Azure Functions de alguns conectores. Previsibilidade se compra com curadoria de log, nunca com desconto. Quem prefere transferir essa curadoria começa pelo monitoramento de segurança gerenciado.
O Microsoft Sentinel dentro do portal do Microsoft Defender
A casa do produto mudou de endereço. O Microsoft Sentinel já está disponível no portal do Microsoft Defender, inclusive para clientes sem Defender XDR e sem licença E5. Ali a fila de incidentes é unificada e a busca avançada cobre as duas origens.
Existe data marcada. Após 31 de março de 2027, o Microsoft Sentinel deixa de ser suportado no portal do Azure. Não é pânico: é item de planejamento com prazo conhecido, e prazo conhecido é o risco mais barato de tratar.
O workspace do Log Analytics segue obrigatório. Trocou a interface, não a arquitetura de dado.
Quando o Microsoft Sentinel faz sentido para uma empresa de médio porte
O produto é bom. Isso não significa que ele seja a próxima compra da sua empresa.
Faz sentido quando o ambiente é híbrido, com parte no Azure e parte no rack da matriz, e ninguém consegue dizer de onde partiu um acesso. Faz sentido quando há dado regulado e auditoria recorrente: o Sentinel herda do Azure Monitor as práticas de proteção contra adulteração, em plataforma somente de acréscimo, onde registro gravado não é editado depois. Faz sentido, principalmente, depois de um incidente que ninguém conseguiu reconstruir.
Ainda não faz sentido quando falta o degrau anterior. Sem identidade centralizada, o log que alimenta o UEBA não existe. Sem proteção de endpoint, metade do sinal nunca é emitida. E sem ninguém designado para ler alerta, o desfecho é conhecido: o console fica ligado, a fatura roda e a empresa acredita estar monitorada.
Console ligado sem ninguém lendo cobra duas vezes: pela ferramenta e pelo risco. O passo seguinte é contratar a operação, formato descrito em serviços gerenciados de segurança.
Como conduzimos monitoramento de segurança na Qualiserve
O Sentinel é plataforma Microsoft. A Qualiserve não revende licença. Entrega o serviço que faz a plataforma valer o que custa: desenho do que será ingerido, afinação de regra, tratamento do incidente.
O direito de falar sobre volume de log e fadiga de alerta vem de operar monitoramento em escala. São 20 anos de mercado, a virada de 2019 do break-fix reativo para serviços gerenciados, mais de 50.000 usuários atendidos e um NOC próprio que monitora mais de 20.000 dispositivos. Somos Microsoft Solution Partner, e a operação usa a delegação do Azure Lighthouse: gerenciamos as assinaturas delegadas sem tomar posse do tenant.
Quem opera nesse volume já pagou pela decisão errada de ingestão. Por isso a conversa começa pelo dado.
Perguntas frequentes sobre o Microsoft Sentinel
As dúvidas abaixo aparecem antes da primeira reunião técnica. As respostas seguem a documentação da Microsoft e não trazem preço unitário, que não é público.
O que é o Microsoft Sentinel e para que ele serve?
O Microsoft Sentinel é a solução SIEM nativa da nuvem da Microsoft, executada sobre o Azure. Ele reúne log de ambientes multicloud, locais e de terceiros, correlaciona os sinais em incidentes investigáveis e automatiza parte da resposta. Serve para responder com evidência o que aconteceu, quando e quem estava envolvido.
Qual é a diferença entre SIEM e SOAR?
SIEM é coleta, normalização, correlação e alerta: a camada que enxerga. SOAR é orquestração, automação e resposta: a camada que age sobre o que foi visto. No Microsoft Sentinel os dois vêm no mesmo produto: as regras de automação e os playbooks do Azure Logic Apps fazem o papel de SOAR.
O Microsoft Sentinel substitui o antivírus?
Não substitui. O antivírus e as ferramentas de endpoint agem no dispositivo, bloqueando processo e arquivo. O Sentinel lê o que elas reportam, cruza com log de identidade, de rede e de nuvem e transforma alertas dispersos em um incidente único.
Quanto custa o Microsoft Sentinel?
A cobrança é por volume de dado ingerido e analisado, medido em GB, mais a retenção que passar dos 90 dias iniciais. Há dois modelos: pagamento por uso e tier de compromisso diário, a partir de 100 GB por dia. O valor unitário varia por região, moeda e contrato, e sai da calculadora oficial.
Existe período de teste gratuito?
Existe, e é útil. Os primeiros 10 GB por dia ingeridos no plano de logs Analytics ficam gratuitos por 31 dias, sujeitos ao limite de 20 workspaces por tenant do Azure. É prazo suficiente para medir o volume real das fontes que interessam, número que costuma faltar em toda estimativa de orçamento.
É preciso ter licença Microsoft 365 E5?
Não é preciso. O Microsoft Sentinel está disponível no portal do Microsoft Defender inclusive para clientes sem Defender XDR e sem licença E5. A decisão de licenciamento é separada da decisão de arquitetura do SIEM, e tratar as duas como uma coisa só costuma atrasar o projeto sem reduzir risco.
O que sustenta o Microsoft Sentinel depois do console ligado
O caminho inteiro cabe em cinco palavras: ingestão, detecção, incidente, automação, custo. Cada etapa é decisão sua, não padrão de fábrica. O Sentinel converte log disperso em decisão rastreável quando alguém escolhe o que entra, ajusta o que dispara e trata o que sobra. Sem essa rotina, vira armazenamento caro com painel bonito.
Duas questões separam o projeto que se sustenta daquele que será cortado no ciclo seguinte. Quais fontes valem a ingestão? Quem lê o alerta na quinta-feira à noite?
Antes de ligar conector, vale saber quanto do seu ambiente precisa mesmo ser ingerido. É o que o nosso assessment de maturidade de segurança responde: leitura do ambiente, mapa das fontes de log que valem entrar e estimativa de volume antes da decisão de plataforma. Prefere conversar direto? WhatsApp (11) 4941-1500.
