Selecione uma plataforma do Azure de destino para hospedar os dados históricos exportados

  • Artigo

Uma das decisões importantes que você toma durante o processo de migração é onde armazenar seus dados históricos. Para tomar essa decisão, você precisa entender e ser capaz de comparar as várias plataformas de destino.

Este artigo compara as plataformas de destino em termos de desempenho, custo, usabilidade e sobrecarga de gerenciamento.

Observação

As considerações nesta tabela se aplicam apenas à migração de log histórico e não se aplicam em outros cenários, como a retenção de longo prazo.

Logs/Arquivos Básicos ADX (Azure Data Explorer) Armazenamento de Blobs do Azure ADX + Armazenamento de Blobs do Azure
Funcionalidades: • Aplicar a maioria das experiências existentes de logs do Azure Monitor a um custo mais baixo.
• Os logs básicos são retidos por oito dias e são transferidos automaticamente para o arquivo (de acordo com o período de retenção original).
• Use trabalhos de pesquisa para pesquisar petabytes de dados e localizar eventos específicos.
• Para investigações profundas em um intervalo de tempo específico, restaure os dados do arquivo morto. Os dados estão disponíveis no cache quente para análise adicional.		 • O ADX e o Microsoft Sentinel usam a Linguagem de Consulta Kusto (KQL), permitindo consultar, agregar ou correlacionar dados em ambas as plataformas. Por exemplo, você pode executar uma consulta KQL do Microsoft Sentinel para unir dados armazenados no ADX com dados armazenados no Log Analytics.
• Com o ADX, você tem um controle substancial sobre o tamanho e a configuração do cluster. Por exemplo, você pode criar um cluster maior para obter uma taxa de transferência de ingestão maior ou criar um cluster menor para controlar seus custos.		 • O Armazenamento de Blobs é otimizado para armazenar grandes quantidades de dados não estruturados.
• Oferece custos competitivos.
• Adequado para um cenário em que sua organização não prioriza a acessibilidade ou o desempenho, como quando a organização deve se alinhar aos requisitos de conformidade ou auditoria.		 • Os dados são armazenados em um armazenamento de blobs, que tem baixos custos.
• Você usa o ADX para consultar os dados em KQL, permitindo que você acesse facilmente os dados. Saiba como consultar dados do Azure Monitor com o ADX
Usabilidade: Ótimo

As opções de arquivo e pesquisa são simples de usar e acessíveis no portal do Microsoft Sentinel. No entanto, os dados não estão disponíveis imediatamente para consultas. Você precisa executar uma pesquisa para recuperar os dados, o que pode levar algum tempo, dependendo da quantidade de dados que estão sendo examinados e retornados.		 Satisfatório

Bastante fácil de usar no contexto do Microsoft Sentinel. Por exemplo, você pode usar uma pasta de trabalho do Azure para visualizar dados distribuídos no Microsoft Sentinel e no ADX. Você também pode consultar dados do ADX no portal do Microsoft Sentinel usando o proxy do ADX.		 Ruim

Com migrações de dados históricos, talvez seja necessário lidar com milhões de arquivos, e explorar os dados torna-se um desafio.		 Razoável

Embora o uso do operador externaldata seja muito desafiador com um grande número de blobs a serem referenciados, o uso de tabelas ADX externas elimina esse problema. A definição de tabela externa entende a estrutura de pastas de armazenamento de blobs e permite consultar de forma transparente os dados contidos em muitos blobs e pastas diferentes.
Sobrecarga de gerenciamento: Totalmente gerenciado

As opções de pesquisa e arquivamento são totalmente gerenciadas e não adicionam sobrecarga de gerenciamento.		 Alta

O ADX é externo ao Microsoft Sentinel, que requer monitoramento e manutenção.		 Baixo

Embora essa plataforma exija pouca manutenção, a seleção dessa plataforma adiciona tarefas de monitoramento e configuração, como configurar o gerenciamento do ciclo de vida.		 Média

Com essa opção, você mantém e monitora o ADX e Armazenamento de Blobs do Azure, ambos componentes externos do Microsoft Sentinel. Embora o ADX possa ser desligado às vezes, considere a sobrecarga de gerenciamento extra com essa opção.
Desempenho: Média

Normalmente, você interage com logs básicos dentro do arquivo usando trabalhos de pesquisa, que são adequados quando você deseja manter o acesso aos dados, mas não precisa de acesso imediato aos dados.		 Alto a baixo

• O desempenho da consulta de um cluster ADX depende do número de nós no cluster, do SKU da máquina virtual do cluster, do particionamento de dados e muito mais.
• À medida que você adiciona nós ao cluster, o desempenho melhora, com custo adicional.
• Se você usar o ADX, recomendamos que você configure o tamanho do cluster para equilibrar o desempenho e o custo. Essa configuração depende das necessidades da sua organização, incluindo a rapidez com que sua migração precisa ser concluída, a frequência com que os dados são acessados e o tempo de resposta esperado.		 Baixo

Oferece duas camadas de desempenho: Premium ou Standard. Embora ambas as camadas sejam uma opção para armazenamento de longo prazo, o Standard é mais econômico. Saiba mais sobre os limites de desempenho e escalabilidade.		 Baixo

Como os dados residem no Armazenamento de Blobs, o desempenho é limitado por essa plataforma.
Custo: Alta

O custo é composto por dois componentes:
• Custo de ingestão. Cada GB de dados ingeridos nos Logs Básicos está sujeito aos custos de ingestão de Logs do Microsoft Sentinel e do Azure Monitor, que somam aproximadamente US$ 1/GB. Veja os detalhes de preços.
• Custo de arquivamento. O custo dos dados na camada de arquivos soma aproximadamente US$ 0,02/GB por mês. Veja os detalhes de preços.
Além desses dois componentes de custo, se você precisar de acesso frequente aos dados, os custos extras serão aplicados ao acessar dados por meio de trabalhos de pesquisa.		 Alto a baixo

• Como o ADX é um cluster de máquinas virtuais, você é cobrado com base no uso de computação, armazenamento e rede, além de uma marcação do ADX (consulte os detalhes de preços. Portanto, quanto mais nós você adicionar ao cluster e quanto mais dados armazenar, maior será o custo.
• O ADX também oferece recursos de dimensionamento automático para se adaptar à carga de trabalho sob demanda. O ADX também pode se beneficiar de preços de Instância Reservada. Você pode executar seus próprios cálculos de custo na Calculadora de Preços do Azure.		 Baixo

Com a configuração ideal, o Armazenamento de Blobs do Azure tem os custos mais baixos. Para maior eficiência e economia de custos, o gerenciamento do ciclo de vida do Armazenamento do Microsoft Azure pode ser usado para colocar automaticamente blobs mais antigos em camadas de armazenamento mais baratas.		 Baixo

O ADX atua apenas como um proxy nesse caso, para que o cluster possa ser pequeno. Além disso, o cluster pode ser desligado quando você não precisa acessar os dados e apenas iniciá-los quando o acesso a dados for necessário.
Como acessar os dados: Trabalhos de pesquisa Consultas KQL diretas externaldata Consultas KQL modificadas
Cenário: Acesso ocasional

Relevante em cenários em que você não precisa executar análises pesadas ou disparar regras de análise, e você só precisa acessar os dados ocasionalmente.		 Acesso frequente

Relevante em cenários em que você precisa acessar os dados com frequência e precisa controlar como o cluster é dimensionado e configurado.		 Conformidade/auditoria

• Ideal para armazenar grandes quantidades de dados não estruturados.
• Relevante em cenários em que você não precisa de acesso rápido aos dados ou alto desempenho, como para fins de conformidade ou auditoria.		 Acesso ocasional

Relevante em cenários em que você deseja se beneficiar do baixo custo de Armazenamento de Blobs do Azure e manter o acesso relativamente rápido aos dados.
Complexidade: Muito baixa Médio Baixo Alto
Preparação: GA GA GA GA

Considerações gerais

Agora que você sabe mais sobre as plataformas de destino disponíveis, examine esses principais fatores para finalizar sua decisão.

Uso de logs ingeridos

Defina como sua organização usará os logs ingeridos para orientar sua seleção da plataforma de ingestão.

Considere estes três cenários gerais:

  • Sua organização precisa manter os logs apenas para fins de conformidade ou auditoria. Nesse caso, sua organização raramente acessará os dados. Mesmo que sua organização acesse os dados, o alto desempenho ou a facilidade de uso não são uma prioridade.
  • Sua organização precisa reter os logs para que suas equipes possam acessar os logs com facilidade e rapidez.
  • Sua organização precisa reter os logs para que suas equipes possam acessar os logs ocasionalmente. O desempenho e a facilidade de uso são secundários.

Consulte a comparação de plataforma para entender qual plataforma se adequa a cada um desses cenários.

Velocidade de migração

Em alguns cenários, talvez seja necessário cumprir um prazo apertado, por exemplo, sua organização pode precisar mudar urgentemente do SIEM anterior devido a um evento de expiração de licença.

Examine os componentes e fatores que determinam a velocidade da migração.

Fonte de dados

A fonte de dados normalmente é um sistema de arquivos local ou armazenamento em nuvem, por exemplo, S3. O desempenho de armazenamento de um servidor depende de vários fatores, como a tecnologia de disco (SSD vs HDD), a natureza das solicitações de E/S e o tamanho de cada solicitação.

Por exemplo, o desempenho da máquina virtual do Azure varia de 30 MB por segundo em SKUs de VM menores a 20 GB por segundo para algumas das SKUs otimizadas para armazenamento usando discos NVM Express (NVMe). Saiba como projetar sua VM do Azure para alto desempenho de armazenamento. Você também pode aplicar a maioria dos conceitos a servidores locais.

Potência de computação

Em alguns casos, mesmo que seu disco seja capaz de copiar seus dados rapidamente, a potência da computação é o gargalo no processo de cópia. Nesses casos, você pode escolher uma destas opções de dimensionamento:

  • Escalar verticalmente. Você aumenta a potência de um único servidor adicionando mais CPUs ou aumentando a velocidade da CPU.
  • Escalar horizontalmente. Você adiciona mais servidores, o que aumenta o paralelismo do processo de cópia.

Plataforma de destino

Cada uma das plataformas de destino discutidas nesta seção tem um perfil de desempenho diferente.

  • Logs básicos do Azure Monitor. Por padrão, os logs básicos podem ser enviados por push para o Azure Monitor a uma taxa de aproximadamente 1 GB por minuto. Essa taxa permite que você ingira aproximadamente 1,5 TB por dia ou 43 TB por mês.
  • Azure Data Explorer. O desempenho da ingestão varia, dependendo do tamanho do cluster que você provisiona e das configurações de envio em lote que você aplica. Saiba mais sobre as práticas recomendadas de ingestão, incluindo desempenho e monitoramento.
  • Armazenamento de Blobs do Azure. O desempenho de uma conta de Armazenamento de Blobs do Azure pode variar muito dependendo do número e do tamanho dos arquivos, tamanho do trabalho, simultaneidade e assim por diante. Saiba como otimizar o desempenho do AzCopy com o Armazenamento do Microsoft Azure.

Quantidade de dados

A quantidade de dados é o principal fator que afeta a duração do processo de migração. Portanto, você deve considerar como configurar seu ambiente dependendo do conjunto de dados.

Para determinar a duração mínima da migração e onde o gargalo pode estar, considere a quantidade de dados e a velocidade de ingestão da plataforma de destino. Por exemplo, você seleciona uma plataforma de destino que pode ingerir 1 GB por segundo e precisa migrar 100 TB. Nesse caso, sua migração terá um mínimo de 100.000 GB, multiplicado pela velocidade de 1 GB por segundo. Divida o resultado por 3600, o que é igual a 27 horas. Esse cálculo estará correto se o restante dos componentes no pipeline, como o disco local, a rede e as máquinas virtuais, puderem ser executados a uma velocidade de 1 GB por segundo.

Próximas etapas

Neste artigo, você aprendeu a mapear suas regras de migração do QRadar para o Microsoft Sentinel.

Selecionar ferramenta de ingestão de dados