Leggere in inglese

Condividi tramite


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

Una delle decisioni importanti prese durante il processo di migrazione è la posizione in cui archiviare i dati storici. 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 overhead di gestione.

Nota

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

Log di base/archivio Esplora dati di Azure(ADX) Archiviazione BLOB di Azure Esplora dati di Azure + Archiviazione BLOB di Azure
Funzionalità: • Applicare la maggior parte delle esperienze dei log di Monitoraggio di Azure esistenti a un costo inferiore.
• I log di base vengono conservati per otto giorni e vengono 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 notevole controllo sulle dimensioni e sulla configurazione del cluster. Ad esempio, è possibile creare un cluster di dimensioni maggiori per ottenere una velocità effettiva di inserimento superiore o creare un cluster più piccolo per controllare i costi.
• L'archiviazione BLOB è ottimizzata per archiviare enormi quantità di dati non strutturati.
• Offre costi competitivi.
• Adatto a 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 di controllo.
• I dati vengono archiviati in un archivio BLOB, che è basso in costi.
• 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 di Azure con ADX
Usabilità: Ottima

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.
Bene

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

Per le migrazioni di dati storici potrebbe essere necessario gestire milioni di file e l'esplorazione dei dati diventa una sfida.
Discreta

Anche se l'uso dell'operatore externaldata è 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.
Nessun sovraccarico di gestione: Completamente gestito

Le opzioni di ricerca e archiviazione sono completamente gestite e non aggiungono overhead di gestione.
Alto

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

Anche se questa piattaforma richiede poca manutenzione, selezionando questa piattaforma vengono aggiunte 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 a Microsoft Sentinel. Anche se ADX può essere arrestato a volte, prendere in considerazione 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 di accesso 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 si trovano nell'archivio BLOB, le prestazioni sono limitate da tale piattaforma.
Costo: Alto

Il costo è composto da due componenti:
Costo di inserimento. Ogni GB di dati inseriti nei log di base è soggetto ai costi di inserimento dei log di Microsoft Sentinel e di Monitoraggio di Azure, che sommano circa $1/GB. Vedere i dettagli dei prezzi .
Costo dell'archiviazione. Il costo per i dati nel livello archivio somma fino a circa $ 0,02/GB al mese. Vedere i dettagli sui prezzi.
Oltre a questi due componenti di costo, se è necessario l'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 sui prezzi. Di conseguenza, più nodi si aggiungono al cluster e più dati vengono 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 delle istanze riservate. È possibile eseguire calcoli dei costi personalizzati nel Calcolatore prezzi di Azure.
Basso

Con la configurazione ottimale, Archiviazione BLOB di Azure ha i costi più bassi. Per una maggiore efficienza e un rispiarmio sui costi, è possibile usare la gestione del ciclo di vita di Archiviazione di Azure 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 di piccole dimensioni. 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 externaldata Query KQL modificate
Scenario: Accesso occasionale

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

Rilevante negli scenari in cui è necessario accedere frequentemente 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 accedere rapidamente ai dati o alle 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 Ridotto Elevato
Idoneità: Disponibilità generale Disponibilità generale Disponibilità generale Disponibilità generale

Considerazioni generali

Dopo aver appreso di più sulle piattaforme di destinazione disponibili, esaminare questi fattori principali per finalizzare la decisione.

Uso dei log inseriti

Definire il modo in cui 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 accederà raramente ai dati. Anche se l'organizzazione accede ai dati, le prestazioni elevate o la facilità d'uso non sono prioritarie.
  • L'organizzazione deve conservare i log in modo che i team possano accedere ai log in modo semplice e rapido.
  • L'organizzazione deve conservare i log in modo che i team possano accedere occasionalmente ai log. Le prestazioni e la facilità d'uso sono secondarie.

Consultare il confronto tra le piattaforme per comprendere la piattaforma adatta a ognuno di questi scenari.

Velocità di migrazione

In alcuni scenari, potrebbe essere necessario rispettare una scadenza stretta, ad esempio, l'organizzazione potrebbe dover passare urgentemente dal sistema 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, le prestazioni delle macchine virtuali di Azure vanno da 30 MB al secondo in SKU di macchine virtuali più piccole, a 20 GB al secondo per alcuni SKU ottimizzati per l'archiviazione usando dischi NVM Express (NVMe). Informazioni su come progettare la macchina virtuale di 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 delle opzioni di ridimensionamento seguenti:

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

Piattaforma di destinazione

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

  • Log di base di Monitoraggio di Azure. Per impostazione predefinita, è possibile eseguire il push dei log di base in Monitoraggio di Azure a una velocità di circa 1 GB al minuto. Questa velocità consente di inserire circa 1,5 TB al giorno o 43 TB al mese.
  • Esplora dati di Azure. Le prestazioni di inserimento variano a seconda delle dimensioni del cluster di cui si effettua il provisioning e delle impostazioni di invio in batch applicate. Informazioni sulle procedure consigliate per l'inserimento, incluse le prestazioni e il monitoraggio.
  • Archiviazione BLOB di Azure. Le prestazioni di un account di 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 di 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 il collo di bottiglia, prendere in considerazione la quantità di dati e la velocità di inserimento della piattaforma di destinazione. Ad esempio, si seleziona una piattaforma di destinazione in grado di inserire 1 GB al secondo ed è necessario eseguire la migrazione di 100 TB. In questo caso, la migrazione richiederà almeno 100.000 GB, moltiplicato per la velocità di 1 GB al secondo. Dividere il risultato per 3600, che calcola 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ò eseguire a una velocità di 1 GB al secondo.

Passaggi successivi

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