Normalização do tempo de ingestão

Análise do tempo de consulta

Como debate na descrição geral do ASIM, 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 consultas. A normalização com a análise do tempo de consulta tem várias vantagens:

  • Preservar o formato original: a normalização do tempo de 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 é 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 em 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 uma vez que 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 com um esquema próximo, mas não idêntico, a 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:

A vantagem das tabelas normalizadas nativas é que estão incluídas por predefinição nos analisadores unificadores unificadores do ASIM. As tabelas normalizadas personalizadas podem ser incluídas nos analisadores unificadores, conforme abordado 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 de 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 de stub.
  • Valores constantes – tal como os aliases e, pela mesma razão, as tabelas normalizadas do ASIM também não armazenam valores constantes, como EventSchema. O analisador de 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, os campos como EventProduct, EventVendor e EventSchemaVersion não são constantes e não são adicionados pelo analisador de stub.
  • Filtragem – o analisador de 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 de stub permite corrigir problemas mais rapidamente. Por exemplo, se os dados tiverem sido ingeridos incorretamente, um endereço IP poderá 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 analisadores unificadores, conforme abordado em Gerir Parsers. Utilize o analisador stub para a tabela nativa, como o analisador stub da tabela nativa de DNS e o respetivo homó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 parsers em Desenvolver analisadores ASIM.

Implementar a normalização do tempo de ingestão

Para normalizar os dados na ingestão, tem 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 noutros Microsoft Sentinel para acomodar os requisitos de processamento de eventos do pipeline. Por conseguinte, tem 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 do KQL do DCR.

Passos seguintes

Para mais informações, consulte:

  • Last updated on