Partilhar via

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 despesas gerais de gerenciamento.

Nota

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

Logs básicos/Arquivo Azure Data Explorer (ADX) Armazenamento de Blobs do Azure ADX + Armazenamento de Blob do Azure
Capacidades: • Aplique a maioria das experiências existentes do Azure Monitor Logs a um custo mais baixo.
• Os logs básicos são retidos por oito dias e, em seguida, são automaticamente transferidos para o arquivo (de acordo com o período de retenção original).
• Use a pesquisa de empregos para pesquisar petabytes de dados e encontrar eventos específicos.
• Para investigações profundas em um intervalo de tempo específico, restaure os dados do arquivo. Os dados ficam disponíveis no hot cache para análises adicionais.		 • Tanto o ADX quanto o Microsoft Sentinel usam a Kusto Query Language (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 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 mais alta ou criar um cluster menor para controlar seus custos.		 • O armazenamento de Blob é 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 estar alinhada com os requisitos de conformidade ou auditoria.		 • Os dados são armazenados em um armazenamento de blob, que é de baixo custo.
• Você usa ADX para consultar os dados no 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 a partir do portal Microsoft Sentinel. No entanto, os dados não estão imediatamente disponíveis para consultas. Você precisa realizar uma pesquisa para recuperar os dados, o que pode levar algum tempo, dependendo da quantidade de dados que estão sendo digitalizados e retornados.		 Boa

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

Com migrações de dados históricos, você pode ter que lidar com milhões de arquivos, e explorar os dados se torna um desafio.		 Justo

Embora o uso do externaldata operador seja muito desafiador com um grande número de blobs para referência, o uso de tabelas ADX externas elimina esse problema. A definição de tabela externa compreende a estrutura de pastas de armazenamento de blob e permite que você consulte de forma transparente os dados contidos em muitos blobs e pastas diferentes.
Despesas gerais de gestão: Totalmente gerido

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

O ADX é externo ao Microsoft Sentinel, o 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 a configuração do gerenciamento do ciclo de vida.		 Medium

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

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 para baixo

• O desempenho da consulta de um cluster ADX depende do número de nós no cluster, da 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ê usa o ADX, recomendamos que 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 a migração precisa ser concluída, a frequência com que os dados são acessados e o tempo de resposta esperado.		 Baixo

Oferece dois níveis de desempenho: Premium ou Standard. Embora ambos os níveis 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: Alto

O custo é composto por duas componentes:
• Custo de ingestão. Cada GB de dados ingeridos em Logs Básicos está sujeito aos custos de ingestão do Microsoft Sentinel e do Azure Monitor Logs, que somam aproximadamente US$ 1/GB. Consulte os detalhes de preços.
• Custo de arquivo. O custo dos dados na camada de arquivamento é de aproximadamente US$ 0,02/GB por mês. Consulte os detalhes de preços.
Além desses dois componentes de custo, se você precisar de acesso frequente aos dados, custos adicionais se aplicam quando você acessa dados por meio de vagas de pesquisa.		 Alto para 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 ADX (consulte os detalhes de preços. Portanto, quanto mais nós você adicionar ao cluster e 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 dos preços da 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 Azure pode ser usado para colocar automaticamente blobs mais antigos em níveis de armazenamento mais baratos.		 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 precisar acessar os dados e iniciá-lo apenas quando o acesso aos dados for necessário.
Como aceder aos dados: Pesquisar Ofertas de Emprego Consultas diretas do KQL dados externos Consultas KQL modificadas
Cenário: Acesso ocasional

Relevante em cenários em que você não precisa executar análises pesadas ou acionar regras de análise, e 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 do Armazenamento de Blobs do Azure e manter um acesso relativamente rápido aos dados.
Complexidade: Muito baixa Médio Baixo Alta
Prontidão: GA Disponibilidade Geral Disponibilidade Geral GA

Considerações gerais

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

Utilização de toros 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 acessá-los de forma fácil e bastante rápida.
  • Sua organização precisa reter os logs para que suas equipes possam acessá-los ocasionalmente. O desempenho e a facilidade de uso são secundários.

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

Velocidade de migração

Em alguns cenários, você pode precisar 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.

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

Data source

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, tais como a tecnologia de disco (SSD vs HDD), a natureza dos pedidos de E/S e o tamanho de cada pedido.

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.

Poder de computação

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

  • Dimensione verticalmente. Você aumenta o poder de um único servidor adicionando mais CPUs ou aumenta a velocidade da CPU.
  • Dimensione 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. Esta taxa permite-lhe ingerir aproximadamente 1,5 TB por dia ou 43 TB por mês.
  • Azure Data Explorer. O desempenho de ingestão varia, dependendo do tamanho do cluster provisionado e das configurações de lote aplicadas. Saiba mais sobre as melhores práticas de ingestão, incluindo desempenho e monitoramento.
  • Armazenamento de Blobs do Azure. O desempenho de uma conta de Armazenamento de Blob do Azure pode variar muito, dependendo do número e tamanho dos arquivos, tamanho do trabalho, simultaneidade e assim por diante. Saiba como otimizar o desempenho do AzCopy com o Armazenamento do 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, a migração levará um mínimo de 100.000 GB, multiplicado pela velocidade de 1 GB por segundo. Divida o resultado por 3600, que calcula até 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, puder ser executado a uma velocidade de 1 GB por segundo.

Próximos passos

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

Selecione uma ferramenta de ingestão de dados