Selezionare una piattaforma di Azure di destinazione per ospitare i dati cronologici esportati

Una delle decisioni importanti che si prendono durante il processo di migrazione è dove archiviare i dati cronologici. Per prendere questa decisione, è necessario comprendere ed essere in grado di confrontare le varie piattaforme di destinazione.

Questo articolo confronta le piattaforme di destinazione in termini di prestazioni, costi, usabilità e sovraccarico di gestione.

Nota

Le considerazioni contenute in questa tabella si applicano solo alla migrazione cronologica dei log e non in altri scenari, ad esempio la conservazione a lungo termine.

Log di base/Archivio Azure Esplora dati (ADX) Archiviazione BLOB di Azure ADX + Archiviazione BLOB di Azure
Funzionalità: • Applicare la maggior parte delle esperienze dei log di monitoraggio Azure esistenti a un costo inferiore.
• I log di base vengono conservati per otto giorni e quindi trasferiti automaticamente all'archivio (in base al periodo di conservazione originale).
• Usare i processi di ricerca per eseguire ricerche in petabyte di dati e trovare eventi specifici.
• Per indagini approfondite su un intervallo di tempo specifico, ripristinare i dati dall'archivio. I dati sono quindi disponibili nella cache ad accesso frequente per ulteriori analisi.		 • Sia ADX che Microsoft Sentinel usano il Linguaggio di query Kusto (KQL), consentendo di eseguire query, aggregare o correlare i dati in entrambe le piattaforme. Ad esempio, è possibile eseguire una query KQL da Microsoft Sentinel per unire i dati archiviati in ADX con i dati archiviati in Log Analytics.
• Con ADX si ha un controllo sostanziale sulle dimensioni e sulla configurazione del cluster. Ad esempio, è possibile creare un cluster di dimensioni maggiori per ottenere una velocità effettiva di inserimento più elevata o creare un cluster più piccolo per controllare i costi.		 • L'archiviazione BLOB è ottimizzata per l'archiviazione di grandi quantità di dati non strutturati.
• Offre costi competitivi.
• Adatto per uno scenario in cui l'organizzazione non assegna priorità all'accessibilità o alle prestazioni, ad esempio quando l'organizzazione deve allinearsi ai requisiti di conformità o controllo.		 • I dati vengono archiviati in un archivio BLOB, che è a basso costo.
• Si usa ADX per eseguire query sui dati in KQL, consentendo di accedere facilmente ai dati. Informazioni su come eseguire query sui dati di monitoraggio Azure con ADX
Usabilità: Grande

Le opzioni di archiviazione e ricerca sono semplici da usare e accessibili dal portale di Microsoft Sentinel. Tuttavia, i dati non sono immediatamente disponibili per le query. È necessario eseguire una ricerca per recuperare i dati, che potrebbero richiedere del tempo, a seconda della quantità di dati analizzati e restituiti.		 Buone

Abbastanza facile da usare nel contesto di Microsoft Sentinel. Ad esempio, è possibile usare una cartella di lavoro Azure per visualizzare i dati distribuiti tra Microsoft Sentinel e ADX. È anche possibile eseguire query sui dati ADX dal portale di Microsoft Sentinel usando il proxy ADX.		 Povero

Con le migrazioni dei dati cronologiche, potrebbe essere necessario gestire milioni di file e l'esplorazione dei dati diventa una sfida.		 Fiera

Sebbene l'uso dell'operatore externaldata sia molto complesso con un numero elevato di BLOB a cui fare riferimento, l'uso di tabelle ADX esterne elimina questo problema. La definizione di tabella esterna comprende la struttura delle cartelle di archiviazione BLOB e consente di eseguire query in modo trasparente sui dati contenuti in molti BLOB e cartelle diversi.
Overhead di gestione: Completamente gestito

Le opzioni di ricerca e archiviazione sono completamente gestite e non aggiungono sovraccarichi di gestione.		 High

ADX è esterno a Microsoft Sentinel, che richiede monitoraggio e manutenzione.		 Basso

Anche se questa piattaforma richiede poca manutenzione, la selezione di questa piattaforma aggiunge attività di monitoraggio e configurazione, ad esempio la configurazione della gestione del ciclo di vita.		 Medium

Con questa opzione è possibile gestire e monitorare ADX e Archiviazione BLOB di Azure, entrambi componenti esterni da Microsoft Sentinel. Mentre ADX può essere arrestato a volte, considerare il sovraccarico di gestione aggiuntivo con questa opzione.
Prestazioni: Medium

In genere si interagisce con i log di base all'interno dell'archivio usando i processi di ricerca, adatti quando si vuole mantenere l'accesso ai dati, ma non è necessario l'accesso immediato ai dati.		 Da alto a basso

• Le prestazioni delle query di un cluster ADX dipendono dal numero di nodi nel cluster, dallo SKU della macchina virtuale del cluster, dal partizionamento dei dati e altro ancora.
• Quando si aggiungono nodi al cluster, le prestazioni migliorano, con costi aggiuntivi.
• Se si usa ADX, è consigliabile configurare le dimensioni del cluster per bilanciare le prestazioni e i costi. Questa configurazione dipende dalle esigenze dell'organizzazione, tra cui la velocità di completamento della migrazione, la frequenza con cui si accede ai dati e il tempo di risposta previsto.		 Basso

Offre due livelli di prestazioni: Premium o Standard. Anche se entrambi i livelli sono un'opzione per l'archiviazione a lungo termine, Standard è più conveniente. Informazioni sui limiti di prestazioni e scalabilità.		 Basso

Poiché i dati risiedono nell'archiviazione BLOB, le prestazioni sono limitate da tale piattaforma.
Costo: High

Il costo è costituito da due componenti:
• Costo di inserimento. Ogni GB di dati inseriti nei log di base è soggetto a Microsoft Sentinel e Azure i costi di inserimento dei log di monitoraggio, che si sommano a circa $1/GB. Vedere i dettagli sui prezzi.
• Costo di archiviazione. Il costo per i dati nel livello archivio si somma a circa $ 0,02/GB al mese. Vedere i dettagli sui prezzi.
Oltre a questi due componenti di costo, se è necessario un accesso frequente ai dati, si applicano costi aggiuntivi quando si accede ai dati tramite processi di ricerca.		 Da alto a basso

• Poiché ADX è un cluster di macchine virtuali, vengono addebitati costi in base all'utilizzo di calcolo, archiviazione e rete, oltre a un markup ADX (vedere i dettagli dei prezzi. Di conseguenza, maggiore è il numero di nodi aggiunti al cluster e maggiore sarà il numero di dati archiviati, maggiore sarà il costo.
• ADX offre anche funzionalità di scalabilità automatica per adattarsi al carico di lavoro su richiesta. ADX può anche trarre vantaggio dai prezzi dell'istanza riservata. È possibile eseguire calcoli dei costi personalizzati nel Calcolatore prezzi Azure.		 Basso

Con una configurazione ottimale, Archiviazione BLOB di Azure ha i costi più bassi. Per una maggiore efficienza e risparmi sui costi, Azure gestione del ciclo di vita dell'archiviazione può essere usata per inserire automaticamente i BLOB meno recenti in livelli di archiviazione più economici.		 Basso

ADX funge solo da proxy in questo caso, quindi il cluster può essere piccolo. Inoltre, il cluster può essere arrestato quando non è necessario accedere ai dati e avviarlo solo quando è necessario l'accesso ai dati.
Come accedere ai dati: Processi di ricerca Query KQL dirette Operatore externaldata KQL Query KQL modificate
Scenario: Accesso occasionale

Rilevante negli scenari in cui non è necessario eseguire analisi complesse o attivare regole di analisi ed è necessario accedere ai dati solo occasionalmente.		 Accesso frequente

Rilevante negli scenari in cui è necessario accedere spesso ai dati ed è necessario controllare le dimensioni e la configurazione del cluster.		 Conformità/controllo

• Ottimale per l'archiviazione di grandi quantità di dati non strutturati.
• Rilevante negli scenari in cui non è necessario un accesso rapido ai dati o prestazioni elevate, ad esempio a scopo di conformità o controllo.		 Accesso occasionale

Rilevante negli scenari in cui si vuole trarre vantaggio dal basso costo di Archiviazione BLOB di Azure e mantenere un accesso relativamente rapido ai dati.
Complessità: Molto bassa Medio Bassa Alta
Idoneità: GA GA GA GA

Considerazioni generali

Ora che si conoscono meglio le piattaforme di destinazione disponibili, esaminare questi fattori principali per finalizzare la decisione.

Uso dei log inseriti

Definire come l'organizzazione userà i log inseriti per guidare la selezione della piattaforma di inserimento.

Considerare questi tre scenari generali:

  • L'organizzazione deve mantenere i log solo a scopo di conformità o controllo. In questo caso, l'organizzazione accede raramente ai dati. Anche se l'organizzazione accede ai dati, le prestazioni elevate o la facilità d'uso non sono una priorità.
  • L'organizzazione deve conservare i log in modo che i team possano accedere ai log in modo semplice e abbastanza rapido.
  • L'organizzazione deve conservare i log in modo che i team possano accedere ai log occasionalmente. Le prestazioni e la facilità d'uso sono secondarie.

Vedere il confronto tra piattaforme per comprendere quale piattaforma si adatta a ognuno di questi scenari.

Velocità di migrazione

In alcuni scenari, potrebbe essere necessario rispettare una scadenza ravvicinata, ad esempio l'organizzazione potrebbe dover passare con urgenza dal SIEM precedente a causa di un evento di scadenza della licenza.

Esaminare i componenti e i fattori che determinano la velocità della migrazione.

Origine dati

L'origine dati è in genere un file system locale o un archivio cloud, ad esempio S3. Le prestazioni di archiviazione di un server dipendono da più fattori, ad esempio la tecnologia del disco (SSD e HDD), la natura delle richieste di I/O e le dimensioni di ogni richiesta.

Ad esempio, Azure prestazioni della macchina virtuale variano da 30 MB al secondo su SKU di macchine virtuali più piccole a 20 GB al secondo per alcuni SKU ottimizzati per l'archiviazione che usano dischi NVM Express (NVMe). Informazioni su come progettare la macchina virtuale Azure per prestazioni di archiviazione elevate. È anche possibile applicare la maggior parte dei concetti ai server locali.

Potenza di calcolo

In alcuni casi, anche se il disco è in grado di copiare rapidamente i dati, la potenza di calcolo è il collo di bottiglia nel processo di copia. In questi casi, è possibile scegliere una di queste opzioni di ridimensionamento:

  • Ridimensionare verticalmente. È possibile aumentare la potenza di un singolo server aggiungendo più CPU o aumentando la velocità della CPU.
  • Ridimensionare orizzontalmente. Si aggiungono altri server, aumentando il parallelismo del processo di copia.

Piattaforma di destinazione

Ognuna delle piattaforme di destinazione descritte in questa sezione ha un profilo di prestazioni diverso.

  • Azure Monitorare i log di base. Per impostazione predefinita, è possibile eseguire il push dei log di base in Monitoraggio Azure con una velocità di circa 1 GB al minuto. Questa tariffa consente di inserire circa 1,5 TB al giorno o 43 TB al mese.
  • Azure Esplora dati. Le prestazioni di inserimento variano a seconda delle dimensioni del cluster di cui si esegue il provisioning e delle impostazioni di invio in batch applicate. Informazioni sulle procedure consigliate per l'inserimento, tra cui prestazioni e monitoraggio.
  • Archiviazione BLOB di Azure. Le prestazioni di un account Archiviazione BLOB di Azure possono variare notevolmente a seconda del numero e delle dimensioni dei file, delle dimensioni del processo, della concorrenza e così via. Informazioni su come ottimizzare le prestazioni di AzCopy con archiviazione Azure.

Quantità di dati

La quantità di dati è il fattore principale che influisce sulla durata del processo di migrazione. È quindi consigliabile considerare come configurare l'ambiente in base al set di dati.

Per determinare la durata minima della migrazione e dove potrebbe essere il collo di bottiglia, considerare la quantità di dati e la velocità di inserimento della piattaforma di destinazione. Ad esempio, si seleziona una piattaforma di destinazione che può inserire 1 GB al secondo ed è necessario eseguire la migrazione di 100 TB. In questo caso, la migrazione richiederà almeno 100.000 GB, moltiplicati per la velocità di 1 GB al secondo. Dividere il risultato per 3600, che calcola fino a 27 ore. Questo calcolo è corretto se il resto dei componenti nella pipeline, ad esempio il disco locale, la rete e le macchine virtuali, può essere eseguito a una velocità di 1 GB al secondo.

Passaggi successivi

In questo articolo si è appreso come eseguire il mapping delle regole di migrazione da QRadar a Microsoft Sentinel.

Selezionare uno strumento di inserimento dati

  • Last updated on