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 |
Dopo aver appreso di più sulle piattaforme di destinazione disponibili, esaminare questi fattori principali per finalizzare la decisione.
- In che modo l'organizzazione userà i log inseriti?
- Quanto è veloce l'esecuzione della migrazione?
- Qual è la quantità di dati da inserire?
- Quali sono i costi di migrazione stimati, durante e dopo la migrazione? Consultare il confronto tra le piattaforme per confrontare i costi.
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.
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.
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.
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.
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.
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.
In questo articolo è stato illustrato come eseguire il mapping delle regole di migrazione da QRadar a Microsoft Sentinel.