Normalização do tempo de ingestão
Análise do tempo de consulta
Como debate na descrição geral do ASIM, o Microsoft Sentinel utiliza o tempo de consulta e a normalização do tempo de ingestão para tirar partido dos benefícios de cada um.
Para utilizar a normalização do tempo de consulta, utilize o tempo de consulta que unifica os analisadores, como _Im_Dns
nas suas consultas. A normalização com a análise do tempo de consulta tem várias vantagens:
- Preservar o formato original: a normalização da hora da consulta não requer que os dados sejam modificados, preservando assim o formato de dados original enviado pela origem.
- Evitar o potencial armazenamento duplicado: uma vez que os dados normalizados são apenas uma vista dos dados originais, não é necessário armazenar dados originais e normalizados.
- Desenvolvimento mais fácil: uma vez que os analisadores de tempo de consulta apresentam uma vista dos dados e não modificam os dados, são fáceis de desenvolver. O desenvolvimento, o teste e a correção de um analisador podem ser feitos em dados existentes. Além disso, os analisadores podem ser corrigidos quando um problema é detetado e a correção será aplicada aos dados existentes.
Análise de tempo de ingestão
Enquanto os analisadores de tempo de consulta ASIM estão otimizados, a análise do tempo de consulta pode abrandar as consultas, especialmente em grandes conjuntos de dados.
A análise de tempo de ingestão permite transformar eventos num esquema normalizado à medida que são ingeridos no Microsoft Sentinel e armazená-los num formato normalizado. A análise do tempo de ingestão é menos flexível e os analisadores são mais difíceis de desenvolver, mas como os dados são armazenados num formato normalizado, oferece um melhor desempenho.
Os dados normalizados podem ser armazenados nas tabelas normalizadas nativas do Microsoft Sentinel ou numa tabela personalizada que utiliza um esquema ASIM. Uma tabela personalizada que tenha um esquema próximo, mas não idêntico, de um esquema ASIM, também fornece os benefícios de desempenho da normalização do tempo de ingestão.
Atualmente, o ASIM suporta as seguintes tabelas normalizadas nativas como destino para a normalização do tempo de ingestão:
- ASimAuditEventLogs para o esquema de Evento de Auditoria .
- ASimAuthenticationEventLogs para o esquema de Autenticação .
- ASimDnsActivityLogs para o esquema DNS .
- ASimNetworkSessionLogs para o esquema de Sessão de Rede
- ASimWebSessionLogs para o esquema de Sessão Web .
A vantagem das tabelas normalizadas nativas é que estão incluídas por predefinição nos parsers unificadores unificadores do ASIM. As tabelas normalizadas personalizadas podem ser incluídas nos analisadores unificadores, conforme discutido em Gerir Parsers.
Combinar a normalização do tempo de ingestão e do tempo de consulta
As consultas devem utilizar sempre o tempo de consulta que unifica os analisadores, como _Im_Dns
para tirar partido do tempo de consulta e da normalização do tempo de ingestão. As tabelas normalizadas nativas são incluídas nos dados consultados através de um analisador stub.
O analisador stub é um analisador de tempo de consulta que utiliza como entrada a tabela normalizada. Uma vez que a tabela normalizada não requer análise, o analisador stub é eficiente.
O analisador stub apresenta uma vista para a consulta de chamada que adiciona à tabela nativa do ASIM:
- Aliases – para não desperdiçar armazenamento em valores repetidos, os aliases não são armazenados em tabelas nativas do ASIM e são adicionados no momento da consulta pelos analisadores stub.
- Valores constantes – como aliases e, pelo mesmo motivo, as tabelas normalizadas do ASIM também não armazenam valores constantes, como EventSchema. O analisador stub adiciona esses campos. A tabela normalizada asIM é partilhada por muitas origens e os analisadores de tempo de ingestão podem alterar a respetiva versão de saída. Por conseguinte, campos como EventProduct, EventVendor e EventSchemaVersion não são constantes e não são adicionados pelo analisador stub.
- Filtragem – o analisador stub também implementa a filtragem. Embora as tabelas nativas do ASIM não precisem de análises de filtragem para obter um melhor desempenho, a filtragem é necessária para suportar a inclusão no analisador unificador.
- Atualizações e correções – a utilização de um analisador stub permite corrigir problemas mais rapidamente. Por exemplo, se os dados tiverem sido ingeridos incorretamente, um endereço IP pode não ter sido extraído do campo de mensagem durante a ingestão. O endereço IP pode ser extraído pelo analisador stub no momento da consulta.
Ao utilizar tabelas normalizadas personalizadas, crie o seu próprio analisador stub para implementar esta funcionalidade e adicione-a aos parsers unificadores, conforme discutido em Gerir Parsers. Utilize o analisador stub para a tabela nativa, como o analisador stub da tabela nativa DNS e o respetivohomólogo de filtragem, como ponto de partida. Se a tabela estiver semi-normalizada, utilize o analisador stub para efetuar a análise e normalização adicionais necessárias.
Saiba mais sobre como escrever analisadores em Desenvolver analisadores ASIM.
Implementar a normalização do tempo de ingestão
Para normalizar os dados na ingestão, terá de utilizar uma Regra de Recolha de Dados (DCR). O procedimento para implementar o DCR depende do método utilizado para ingerir os dados. Para obter mais informações, consulte o artigo Transformar ou personalizar dados no momento da ingestão no Microsoft Sentinel.
Uma consulta de transformação KQL é o núcleo de um DCR. A versão KQL utilizada nos DCRs é ligeiramente diferente da versão utilizada noutro local no Microsoft Sentinel para acomodar os requisitos de processamento de eventos do pipeline. Por conseguinte, terá de modificar qualquer analisador de tempo de consulta para utilizá-lo num DCR. Para obter mais informações sobre as diferenças e como converter um analisador de tempo de consulta num analisador de tempo de ingestão, leia sobre as limitações de KQL do DCR.
Passos seguintes
Para obter mais informações, consulte:
Comentários
https://aka.ms/ContentUserFeedback.
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja:Submeter e ver comentários