A implementação do Microsoft Sentinel não é instalação de software: é uma sequência de decisões de arquitetura e de dado, cada uma com preço recorrente. Este guia trata de quais logs entram, em qual camada, por quanto tempo ficam, quanto isso custa por mês e quem opera a plataforma depois do go-live.
A implementação do Microsoft Sentinel é o projeto que define quais fontes alimentam o SIEM, em qual camada de ingestão, com qual retenção e sob qual operação contínua. Habilitar a plataforma leva minutos. Implementá-la bem leva semanas. Operá-la é permanente. Confundir as três coisas é a origem da maior parte dos projetos de SIEM que decepcionam.
O projeto foi aprovado em janeiro. Na primeira semana, o time ligou todos os conectores que apareceram na lista. Trinta dias depois, a reunião de acompanhamento tinha mudado de assunto: ninguém falava mais em detecção, falava-se em fatura. É o desfecho previsível de tratar como configuração aquilo que é decisão de arquitetura com efeito direto no custo mensal.
Este guia percorre as decisões que determinam o resultado: escolha e priorização de fontes, camadas de ingestão e retenção, dimensionamento de custo antes do go-live, regras analíticas e automação, e o desenho de operação sem o qual a plataforma entrega log em vez de resposta.
O que a implementação do Microsoft Sentinel realmente decide
Sentinel é o SIEM nativo de nuvem da Microsoft: coleta, detecção, investigação, caça e resposta automatizada sobre dado de nuvem, de ambiente local e de plataformas de terceiros, conforme a documentação oficial.
Onde ele vive mudou, e vale acertar isso antes da conversa de projeto. A experiência de referência passou a ser o portal do Microsoft Defender, não o portal do Azure. Na maioria dos casos, quem fez o onboarding do primeiro workspace após 1º de julho de 2025 já foi conectado automaticamente ao novo portal, e após 31 de março de 2027 o Sentinel deixa de ser suportado no portal do Azure. Ele está disponível no portal do Defender inclusive sem Defender XDR e sem licença E5. Com mais de um workspace conectado, um deles é designado primário e os demais entram como secundários.
O que não mudou importa mais: continua sendo necessário um workspace do Log Analytics com o Sentinel habilitado. A interface trocou; a decisão de arquitetura de dado, não.
Traduzindo para a mesa do decisor: o que se define numa implementação é quanta visibilidade a empresa compra e por qual custo recorrente. E o prazo de 2027 é item de roadmap, não curiosidade técnica.
As etapas de uma implementação de Microsoft Sentinel
A documentação de implantação organiza o trabalho em três fases: planejar e preparar, implantar, afinar e revisar. Cada uma pede um perfil diferente, tipicamente arquiteto de SOC, depois analistas, depois engenharia de segurança. São três competências distintas, e quase nenhuma PME tem as três dentro de casa.
1. Arquitetura de workspace, a decisão que ninguém desfaz barato
A recomendação da Microsoft é começar por um único workspace e só multiplicar quando um critério concreto exigir:
- Região do Azure e residência de dado. Cada workspace vive em uma região, e exigência regulatória de manter dado em determinada geografia justifica separar.
- Múltiplos tenants do Microsoft Entra. Vários tipos de fonte só enviam dado para workspace no mesmo tenant.
- Separação entre dado operacional e dado de segurança. O ponto de custo mais ignorado do projeto: habilitado o Sentinel em um workspace, todo o dado daquele workspace passa a ser cobrado sob o modelo do Sentinel, inclusive telemetria operacional que nada tem a ver com segurança. Em contrapartida, consolidar volume pode ser o que permite alcançar um tier de compromisso com desconto. É um trade-off real, não uma regra fixa.
- Retenção diferente por conjunto de dado, controle de acesso (RBAC de workspace, por tabela e por contexto de recurso), rateio entre centros de custo e resiliência a falha de região.
Essa é a decisão mais difícil de reverter no projeto inteiro. Refazer arquitetura de workspace depois de meses de ingestão significa perder correlação histórica ou pagar duas vezes pelo mesmo dado.
2. Conectores de dados: quais ligar primeiro e por quê
A ordem oficial de priorização de conectores começa pelas fontes gratuitas: Azure Activity, logs de auditoria do Microsoft 365 (SharePoint, Exchange, Teams), o monitoramento de saúde do próprio Sentinel e os alertas de segurança das soluções Defender (XDR, Endpoint, Identity, Office 365, Cloud Apps e Cloud). Isso entrega valor de detecção imediato enquanto o orçamento das demais fontes ainda está sendo dimensionado. Só depois entram conectores personalizados e de parceiros, começando por CEF ou Syslog nas fontes de maior prioridade.
Uma ressalva que muita gente atropela: alerta é gratuito, log bruto não é. Os logs brutos de várias fontes Microsoft, incluindo Entra ID e componentes do Defender, são cobrados. Conector que oferece tipos de dado gratuitos e pagos permite selecionar o que entra, e essa seleção é trabalho de engenharia, não de checkbox.
O critério a cravar: priorize por valor de detecção, não por facilidade de conexão. Conector fácil de ligar e pobre em sinal custa caro todo mês e não detecta nada.
3. Regras de análise: as prontas, as customizadas e o trabalho de afinação
As regras do content hub são ponto de partida, nunca linha de chegada. O trabalho real começa depois de ligá-las: verificar se o volume de incidentes reflete o que acontece no ambiente, tratar falso positivo por automação ou por modificação da regra agendada, usar os recursos nativos de fine-tuning e conferir a cobertura contra o framework MITRE ATT&CK, que a plataforma exibe indicando quais táticas e técnicas já estão cobertas.
Correlação é o que transforma alerta de baixa fidelidade em incidente de alta fidelidade. Sem afinação, ela só multiplica ruído. A diferença de negócio é direta: regra afinada gera um incidente que alguém investiga; regra não afinada gera cem que ninguém abre.
4. Automação e resposta: playbooks
Playbooks no Sentinel são construídos sobre Azure Logic Apps e podem ser disparados sob demanda ou por regras de automação. Os usos concretos são banais e valiosos: abrir chamado em ferramenta de ITSM, enriquecer entidade antes da triagem, isolar um host, notificar um responsável.
Um detalhe que escapa do orçamento: Logic Apps tem cobrança própria, separada do Sentinel, assim como o Azure Functions usado por alguns conectores. Ainda assim, automação bem feita não é firula técnica. É o que impede que o custo de operação cresça na mesma proporção do volume de alerta.
5. Onboarding para operação contínua
O checklist pós-implantação documentado pela Microsoft é a espinha dessa entrega: revisar incidentes e o processo de tratamento, afinar regras de análise e de automação, manter watchlists atualizadas, revisar o tier de compromisso, acompanhar custo de ingestão pelas workbooks de uso, afinar os DCRs e garantir processo de caça proativa. Nada disso é evento único. Tudo isso é rotina, e rotina precisa de dono.
Custos do Microsoft Sentinel: o que faz a fatura crescer
O mecanismo: paga-se pelo dado que entra e pelo dado que fica
O modelo de cobrança é baseado em volume: quanto dado entra e por quanto tempo permanece. A cobrança acontece pelo tier em que o dado é ingerido. No analytics tier existem dois caminhos: pay-as-you-go, baseado no volume armazenado, e tiers de compromisso, em que se compromete um volume diário fixo a preço melhor, com o excedente cobrado à mesma taxa efetiva do tier.
Duas regras estruturais valem mais que qualquer número. O tier de compromisso pode ser aumentado a qualquer momento, mas só reduzido após 31 dias. E ele vale por workspace, salvo em cluster dedicado. Quem contrata compromisso sem conhecer o padrão real de ingestão fica preso a ele por um mês.
Na retenção, o dado ingerido em workspace com Sentinel habilitado tem 90 dias sem cobrança adicional. A partir daí, retenção é cobrada, com possibilidade de prazos diferentes por tabela. Dado que envelhece além da retenção analítica permanece acessível no data lake tier, para preservação de longo prazo a custo reduzido. A camada de arquivamento clássica, o antigo archive, foi absorvida por esse modelo e hoje é nomenclatura legada.
A classificação por plano de log separa dado primário de segurança, de valor crítico e monitorado em tempo quase real, que vai para o analytics tier, de dado secundário: volumoso, verboso, de valor individual limitado, mas essencial para reconstruir o quadro completo de um incidente. Exemplos de dado secundário na documentação: logs de acesso a storage em nuvem, NetFlow, certificado TLS e SSL, firewall, proxy e IoT. É aqui que mora a maior alavanca de custo do projeto. Classificar errado um log volumoso é a diferença entre um projeto sustentável e um projeto cortado no ciclo orçamentário seguinte.
As alavancas de controle de custo
Todas são decisões de engenharia tomadas no projeto, não negociação comercial:
- Filtrar na origem. As regras de coleta de dado (DCRs) permitem ao Azure Monitor Agent selecionar quais eventos são coletados e descartar o resto antes da ingestão.
- Transformação em tempo de ingestão, descartando dado irrelevante antes do primeiro armazenamento.
- Escolha de tier por tabela, movendo dado secundário para o data lake tier, e política de retenção por tabela no lugar de uma retenção única e generosa para tudo.
- Retenção total no data lake para o histórico exigido por compliance, e tier de compromisso alinhado ao consumo real, revisado periodicamente.
- Separar dado não relacionado à segurança em outro workspace, recomendação explícita da documentação de redução de custo.
- Cluster dedicado para quem ingere volume alto e concentrado, e nada de duplicar dado entre workspaces sem necessidade.
O erro mais caro e mais comum: ligar tudo no primeiro dia
Ele acontece porque parece prudente. “Vamos coletar tudo, melhor sobrar do que faltar.” O resultado é sempre o mesmo: fatura crescendo mais rápido que a capacidade de análise, mais ruído que sinal e, no ciclo seguinte, a pergunta que mata o projeto, que é para que a empresa paga por aquilo. A própria documentação antecipa o cenário ao orientar que, se a ingestão ficar cara rápido demais, se pare ou se filtre o encaminhamento de logs.
Custo de Sentinel não é preço de plataforma, é consequência de decisão de arquitetura. Quem decide com critério gasta menos e detecta mais. Quem não decide, gasta mais e detecta menos. Não existe negociação que corrija arquitetura ruim, e o raciocínio é o mesmo que sustenta qualquer trabalho sério de otimização de custos em nuvem.
Operação: Sentinel implementado não é Sentinel operando
O trabalho que só aparece depois do go-live
Implementar é projeto, tem começo e fim. Operar é rotina, e é na rotina que o SIEM entrega valor. O que exige gente todo dia: afinar a regra que dispara demais, investigar o incidente que dispara de verdade, manter watchlist atualizada, revisar cobertura MITRE conforme o ambiente muda, acompanhar custo de ingestão e caçar proativamente o que nenhuma regra pegou.
Alerta ignorado é pior que nenhum alerta
SIEM sem operação vira gerador de alerta ignorado, e alerta ignorado é pior que nenhum alerta, porque cria falsa sensação de cobertura. A empresa acredita que está monitorada, o orçamento está comprometido, o console está lá, e ninguém olha. Paga-se pela ferramenta e pelo risco ao mesmo tempo.
Para a PME, a pergunta prática não é técnica, é de estrutura: existe alguém, dentro de casa, disponível para fazer isso todos os dias, com escala para cobrir fora do horário comercial? Em empresas de 50 a 500 colaboradores, a resposta honesta costuma ser não. Não por falta de competência do time de TI, mas porque esse time já tem um dia inteiro antes de olhar para o SIEM. É esse o papel de uma operação de SOC gerenciado para empresas, e vale entender também a diferença entre EDR, XDR e MDR para ver como as camadas de detecção se encaixam com o SIEM.
Como conduzimos esse projeto na Qualiserve
O Sentinel é plataforma Microsoft. O que a Qualiserve entrega é outra coisa: o projeto de implementação, a afinação e a operação contínua. Não vendemos a plataforma, vendemos o trabalho que faz a plataforma funcionar.
O direito de falar sobre custo de ingestão e sobre fadiga de alerta vem de operar monitoramento em escala. São 20 anos de mercado, a virada de 2019 de break-fix reativo para serviços gerenciados proativos e um NOC próprio que monitora mais de 20.000 dispositivos. Quem opera nesse volume já pagou pelas decisões erradas de arquitetura de dado e sabe onde o custo se esconde.
Perguntas frequentes sobre implementação do Microsoft Sentinel
Quanto tempo leva uma implementação do Microsoft Sentinel?
Depende de quatro variáveis: quantidade e tipo de fonte, complexidade da arquitetura de workspace, volume de regra customizada e nível de automação. Habilitar o serviço leva minutos, mas um projeto real se conta em semanas, e a afinação continua depois do go-live.
O Microsoft Sentinel ainda é configurado pelo portal do Azure?
O portal do Microsoft Defender passou a ser a experiência de referência, com onboarding automático na maioria dos casos para quem entrou após 1º de julho de 2025, e após 31 de março de 2027 o Sentinel deixa de ser suportado no portal do Azure. Independentemente do portal, o workspace do Log Analytics continua obrigatório.
Preciso ter licença E5 ou Defender XDR para usar o Sentinel?
Não. O Sentinel no portal do Defender está disponível inclusive para quem não tem Defender XDR nem licença E5. A decisão de licenciamento é separada da decisão de arquitetura do SIEM.
O que mais encarece o Microsoft Sentinel?
Volume ingerido no analytics tier e retenção acima da necessidade real. Os dois vilões são o conector verboso ligado sem critério e o log volumoso classificado como dado primário quando deveria ir para o data lake tier.
Dá para reduzir custo sem perder visibilidade?
Sim, e é o trabalho de engenharia do projeto: filtrar na origem com DCRs, transformar na ingestão, classificar corretamente entre analytics tier e data lake tier, ajustar retenção por tabela e alinhar o tier de compromisso ao consumo real.
Preciso de um time interno para operar o Sentinel depois de implantado?
Precisa de alguém operando, interno ou parceiro. Sem afinação contínua e sem investigação, o SIEM vira gerador de alerta ignorado e devolve falsa sensação de cobertura.
O que decidir antes de assinar o projeto
Três perguntas separam um projeto sustentável de um que será cortado no ano seguinte. Quais fontes valem a ingestão. Qual desenho de workspace e de retenção sustenta o orçamento. Quem vai operar depois do go-live. Quem não as responde antes de começar vai respondê-las depois, no boleto.
Governança é subproduto do projeto bem feito. Retenção por tabela, RBAC desenhado, cobertura mapeada contra MITRE e custo acompanhado por workbook produzem, sem esforço adicional, o material de evidência que auditoria, seguradora cibernética e adequação à LGPD vão pedir.
Se a sua empresa está dimensionando esse projeto, comece por um assessment de segurança e de arquitetura de dado, que responde às três perguntas antes de a primeira linha de log entrar. A Qualiserve entrega o projeto e a operação, apoiada em NOC próprio. Conheça as soluções de segurança ou a página de monitoramento de segurança e SOC. Prefere conversar direto? WhatsApp (11) 4941-1500.
