Planos de retenção de log no Microsoft Sentinel
Há dois aspectos concorrentes de retenção e coleta de logs que são essenciais para um programa de detecção de ameaças bem-sucedido. Por um lado, você quer maximizar o número de fontes de log coletadas, para que você tenha a cobertura de segurança mais abrangente possível. Por outro lado, você precisa minimizar os custos incorridos pela ingestão de todos esses dados.
Essas necessidades concorrentes exigem uma estratégia de gerenciamento de logs que equilibra a acessibilidade aos dados, o desempenho da consulta e os custos de armazenamento.
Este artigo discute categorias de dados e os estados de retenção usados para armazenar e acessar seus dados. Ele também descreve os planos de log que o Microsoft Sentinel oferece para criar uma estratégia de retenção e gerenciamento de logs.
Importante
O tipo de log Logs Auxiliares está atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para termos legais adicionais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.
O Microsoft Sentinel está geralmente disponível na plataforma de operações de segurança unificada da Microsoft no portal do Microsoft Defender. Para visualização, o Microsoft Sentinel está disponível no portal do Defender sem o Microsoft Defender XDR ou uma licença E5. Para obter mais informações, confira Microsoft Sentinel no portal do Microsoft Defender.
Categorias de dados ingeridos
A Microsoft recomenda classificar os dados ingeridos no Microsoft Sentinel em duas categorias gerais:
Dados de segurança primários são dados que contêm valor crítico de segurança. Esses dados são usados para monitoramento proativo em tempo real, alertas agendados e análise para detectar ameaças à segurança. Os dados precisam estar prontamente disponíveis para todas as experiências do Microsoft Sentinel quase em tempo real.
Dados de segurança secundários são dados complementares, geralmente em logs detalhados de alto volume. Esses dados são de valor limitado de segurança, mas podem fornecer mais riqueza e contexto para detecções e investigações, ajudando a descrever um incidente de segurança completo. Eles não precisam estar prontamente disponível, mas devem ser acessíveis sob demanda conforme necessário e em doses apropriadas.
Dados de segurança primários
Essa categoria consiste em logs que contêm um valor crítico de segurança para sua organização. Os dados de segurança primários podem ser descritos pelos seguintes casos de uso para operações de segurança:
Monitoramento frequente. Regras de detecção de ameaças (análise) são executadas nesses dados em intervalos frequentes ou quase em tempo real.
Busca sob demanda. Consultas complexas são executadas nesses dados para executar a busca interativa e de alto desempenho por ameaças à segurança.
Correlação. Os dados dessas fontes estão correlacionados com dados de outras fontes primárias de dados de segurança para detectar ameaças e criar histórico de ataque.
Relatório regular. Os dados dessas fontes estão prontamente disponíveis para compilação em relatórios regulares da integridade de segurança da organização, para os tomadores de decisões gerais e de segurança.
Análise do comportamento. Os dados dessas fontes são usados para criar perfis de comportamento de linha de base de seus usuários e dispositivos, permitindo que você identifique comportamentos subjacentes como suspeitos.
Alguns exemplos de fontes de dados primárias incluem logs de sistemas EDR (detecção e resposta corporativa) ou de antivírus, logs de autenticação, trilhas de auditoria de plataformas de nuvem, feeds de inteligência contra ameaças e alertas de sistemas externos.
Os logs que contêm dados de segurança primários devem ser armazenados usando o plano de logs de Análise descrito posteriormente neste artigo.
Dados de segurança secundários
Essa categoria abrange logs cujo valor de segurança individual é limitado, mas são essenciais para fornecer uma visão abrangente de um incidente ou violação de segurança. Normalmente, esses logs são de alto volume e podem ser detalhados. Os casos de uso das operações de segurança para esses dados incluem o seguinte:
Inteligência contra ameaças. Os dados primários podem ser verificados em relação a listas de Indicadores de Comprometimento (IoC) ou Indicadores de Ataque (IoA) para detectar ameaças de forma rápida e fácil.
Busca/investigações ad hoc. Os dados podem ser consultados interativamente por 30 dias, facilitando a análise crucial para busca e investigações de ameaças.
Pesquisas em larga escala. Os dados podem ser ingeridos e pesquisados em segundo plano em escala de petabytes, enquanto são armazenados de forma eficiente com processamento mínimo.
Resumo por meio de regras de resumo. Resumir logs de alto volume em informações de agregação e armazenar os resultados como dados de segurança primários. Para saber mais sobre regras de resumo, consulte o artigo Agregação de dados do Microsoft Sentinel com regras de resumo.
Alguns exemplos de fontes secundárias de log de dados são logs de acesso ao armazenamento na nuvem, logs do NetFlow, logs de certificado TLS/SSL, logs de firewall, logs de proxy e logs de IoT. Para saber mais sobre como cada uma dessas fontes agrega valor às detecções de segurança sem ser necessária o tempo todo, consulte Fontes de log a serem usadas para ingestão de Logs Auxiliares.
Os logs que contêm dados de segurança secundários devem ser armazenados usando o plano de Logs Auxiliares (agora em Versão Prévia) descrito posteriormente neste artigo.
Para uma opção que não seja de versão prévia, você pode usar Logs Básicos em vez disso.
Planos de gerenciamento de logs
O Microsoft Sentinel fornece dois diferentes planos de armazenamento de log, ou tipos, para acomodar essas categorias de dados ingeridos.
O plano de Logs de Análise foi projetado para armazenar dados de segurança primários e torná-los facilmente e constantemente acessíveis em alto desempenho.
O plano de Logs Auxiliares foi projetado para armazenar dados de segurança secundários a um custo muito baixo por longos períodos de tempo, ao mesmo tempo em que ainda permite acessibilidade limitada.
Um terceiro plano, Logs Básicos, é o antecessor do plano de logs auxiliares e pode ser usado como um substituto dele enquanto o plano de logs auxiliares permanece em versão prévia.
Cada um desses planos preserva dados em dois estados diferentes:
O estado de retenção interativa é o estado inicial no qual os dados são ingeridos. Esse estado permite diferentes níveis de acesso aos dados, dependendo do plano, e os custos desse estado variam muito, dependendo do plano.
O estado de retenção de longo prazo preserva dados mais antigos em suas tabelas originais por até 12 anos, a um custo extremamente baixo, independentemente do plano.
Para saber mais sobre estados de retenção, consulte Gerenciar a retenção de dados em um workspace do Log Analytics.
O diagrama a seguir resume e compara esses dois planos de gerenciamento de log.
Plano de logs de análise
O plano de Logs de Análise mantém os dados no estado de retenção interativa por 90 dias por padrão, extensível por até dois anos. Esse estado interativo, embora caro, permite que você consulte seus dados de forma ilimitada, com alto desempenho, sem custo por consulta.
Quando o período de retenção interativo termina, os dados entram no estado de retenção de longo prazo, enquanto permanecem em sua tabela original. O período de retenção de longo prazo não é definido por padrão, mas você pode defini-lo para durar até 12 anos. Esse estado de retenção preserva seus dados a um custo extremamente baixo, para fins de conformidade regulatória ou política interna. Você pode acessar os dados nesse estado apenas usando um trabalho de pesquisa ou restauração para extrair conjuntos limitados de dados para uma nova tabela em retenção interativa, em que você pode trazer os recursos completos de consulta para suportá-los.
Plano de logs auxiliares
O plano de Logs Auxiliares mantém os dados no estado de retenção interativa por 30 dias. No plano Auxiliar, esse estado tem custos de retenção muito baixos em comparação com o plano de Análise. No entanto, os recursos de consulta são limitados: as consultas são cobradas por gigabyte de dados verificados e são limitadas a uma única tabela e o desempenho é significativamente menor. Embora esses dados permaneçam no estado de retenção interativo, você pode executar regras de resumo nesses dados para criar tabelas de agregação, dados de resumo no plano de Logs de Análise, para que você tenha os recursos completos de consulta nesses dados agregados.
Quando o período de retenção interativo termina, os dados entram no estado de retenção de longo prazo, permanecendo em sua tabela original. A retenção de longo prazo no plano de logs auxiliares é semelhante à retenção de longo prazo no plano de logs de análise, exceto que a única opção para acessar os dados é com um trabalho de pesquisa. Não há suporte para Restauração no plano de logs auxiliares.
Plano de logs básicos
Um terceiro plano, conhecido como Logs Básicos, fornece funcionalidade semelhante ao plano de logs auxiliares, mas com um custo de retenção interativo mais alto (embora não tão alto quanto o plano de logs de análise). Embora o plano de logs auxiliares permaneça em versão prévia, os logs básicos poderão ser uma opção para retenção de longo prazo e baixo custo se sua organização não usar versão prévia de recursos. Para saber mais sobre o plano de logs básico, consulte Planos de tabela na documentação do Azure Monitor.
Conteúdo relacionado
Para obter uma comparação mais detalhada dos planos de dados de log e informações mais gerais sobre tipos de log, consulte Visão geral dos Logs do Azure Monitor | Planos de tabela.
Para configurar uma tabela no plano de Logs Auxiliares, consulte Configurar uma tabela com o plano Auxiliar em seu workspace do Log Analytics (versão prévia).
Para entender mais sobre os períodos de retenção existentes, que existe entre os planos, consulte Gerenciar retenção de dados em um workspace do Log Analytics.