Sua organização usa um único workspace do Microsoft Sentinel. A conformidade exige que os dados do Windows SecurityEvent sejam retidos por 180 dias em armazenamento "hot" e, em seguida, arquivados, enquanto os dados do Syslog devem ser retidos por 30 dias. Para reduzir a ingestão, apenas os IDs de evento do Windows 4624, 4625 e 4688 devem ser coletados. Quais duas ações você deve tomar?

As ações corretas são configurar políticas de retenção e arquivamento em nível de tabela e criar uma Regra de Coleta de Dados (DCR). A retenção e o arquivamento em nível de tabela permitem definir períodos de retenção "hot" e arquivamento distintos para as tabelas SecurityEvent e Syslog dentro do mesmo workspace, atendendo aos requisitos de conformidade. Uma DCR com filtragem de dados é essencial para coletar apenas os IDs de evento do Windows especificados (4624, 4625, 4688), reduzindo significativamente a ingestão de dados e os custos associados. As opções incorretas são: Habilitar um limite diário de workspace é uma medida de controle de custos, mas não substitui a necessidade de retenção específica por tabela nem a filtragem de eventos. Criar workspaces separados para SecurityEvent e Syslog não é necessário, pois a retenção por tabela permite gerenciar diferentes requisitos dentro de um único workspace, o que é mais eficiente. Mudar para o conector Security Events herdado não é recomendado. O Azure Monitor Agent (AMA) com DCRs é a abordagem moderna e flexível para coleta de dados, oferecendo melhor controle e filtragem do que os conectores herdados.