Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Una delle decisioni importanti che si prendono durante il processo di migrazione è dove archiviare i dati cronologici. Per decidere dove archiviare i dati cronologici, è necessario comprendere e 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 questo articolo si applicano solo alla migrazione cronologica dei log. Non si applicano ad altri scenari, ad esempio la conservazione a lungo termine dei dati operativi.
Percorso consigliato: Microsoft Sentinel data lake
Per la maggior parte delle nuove migrazioni, è consigliabile archiviare i dati cronologici in Microsoft Sentinel data lake, il livello dati nativo della piattaforma Microsoft Sentinel. Il data lake offre:
- Conservazione economica e a lungo termine: conserva fino a 12 anni di dati di sicurezza in un unico store a formato aperto (Parquet), senza scegliere tra copertura e costo.
- Una singola copia dei tuoi dati: I dati nel livello di analisi vengono speculati sul livello del lago, quindi non devi pagare per mantenere copie duplicate per caccia e investigazione.
- Integrazione nativa di Sentinel e Defender: Cerca, indaga ed esegui analisi su dati storici direttamente dal portale Microsoft Defender—senza cluster o proxy separati da gestire.
- Molteplici motori di analisi: Usa KQL per query ad hoc e i notebook Jupyter con librerie Python e di machine learning per analisi più approfondite, forensi e rilevamento di anomalie.
- Un servizio completamente gestito: non si distribuisce, non scala o si patcha l'infrastruttura.
Scegliere Microsoft Sentinel data lake quando si vuole il percorso più semplice di una cronologia unificata e su cui è possibile eseguire query sui dati di sicurezza all'interno di Microsoft Sentinel.
Per altre informazioni, vedi Che cos'è Microsoft Sentinel data lake? e Effettuare l'onboarding a Microsoft Sentinel data lake.
Piattaforme di destinazione alternative
Microsoft Sentinel data lake è la destinazione consigliata per la maggior parte dei clienti, ma altre piattaforme rimangono valide per scenari specifici. Usare il confronto in questa sezione quando si dispone di un investimento esistente in Esplora dati di Azure (ADX) o Archiviazione BLOB di Azure o quando uno scenario specifico non è ancora coperto dal data lake.
| Data lake di Microsoft Sentinel | Esplora dati di Azure (ADX) | Archiviazione BLOB di Azure | |
|---|---|---|---|
| Funzionalità: | - Data Lake di sicurezza appositamente progettato integrato con Microsoft Sentinel e il portale Defender. - Copia singola dei dati nei livelli di analisi e lacustri. - Fino a 12 anni di conservazione in formato open parquet. - Query con quaderni KQL e Jupyter (librerie di machine learning + Python). - Promuovere i dati su richiesta al livello di analisi quando si necessitano di piene capacità SIEM. |
- ADX e Microsoft Sentinel utilizzano entrambi il Kusto Query Language (KQL), quindi puoi interrogare, aggregare o correlare dati su 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, hai un controllo sostanziale sulla dimensione e configurazione del cluster. Ad esempio, è possibile creare un cluster di dimensioni maggiori per ottenere una velocità effettiva di inserimento superiore o un cluster più piccolo per controllare i costi. |
- L'archiviazione blob è ottimizzata per memorizzare enormi quantità di dati non strutturati. - Offre costi competitivi. - Adatto quando la tua organizzazione non dà priorità all'accessibilità o alle prestazioni, come quando devi rispettare requisiti di conformità o audit. |
| Usabilità: |
Grande Eseguire query e analizzare i dati cronologici direttamente dal portale di Microsoft Defender con la stessa esperienza KQL già usata per Sentinel. I notebook offrono un'interfaccia familiare per l'analisi avanzata. |
Buone Abbastanza facile da usare nel contesto di Microsoft Sentinel. Ad esempio, è possibile usare una cartella di lavoro 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. |
Povero Con le migrazioni dei dati cronologiche, potrebbe essere necessario gestire milioni di file e l'esplorazione dei dati diventa una sfida. |
| Overhead di gestione: |
Completamente gestito Microsoft gestisce l'infrastruttura data lake, il ridimensionamento e l'applicazione di patch. Non gestisci un cluster né gli account di archiviazione. |
Alto ADX è esterno a Microsoft Sentinel e richiede monitoraggio e manutenzione. |
Basso La piattaforma stessa richiede poca manutenzione, ma è comunque necessario configurare attività di monitoraggio e configurazione, ad esempio la gestione del ciclo di vita. |
| Prestazioni: |
Alto Il data lake separa l'archiviazione dal calcolo e supporta più motori di analisi, in modo da poter ridimensionare i carichi di lavoro di query in modo indipendente dall'inserimento. Alzare di livello i dati al livello di analisi quando sono necessarie prestazioni SIEM interattive. |
Da alto a basso - Le prestazioni delle query ADX dipendono dal numero di nodi nel cluster, dallo SKU della macchina virtuale del cluster, dalla partizionazione dei dati e altro ancora. - Man mano che aggiungi nodi al cluster, le prestazioni migliorano a costo aggiuntivo. - Se usi ADX, ti consigliamo di dimensionare il cluster in modo da bilanciare prestazioni e costi in base alle esigenze della tua organizzazione, inclusa la velocità con cui la migrazione deve essere completata, la frequenza con cui i dati vengono acceduti e il tempo di risposta atteso. |
Basso Offre due livelli di prestazioni: Premium o Standard. Entrambi sono un'opzione per l'archiviazione a lungo termine, ma Standard è più conveniente. Informazioni sui limiti di prestazioni e scalabilità. |
| Costo: |
Da basso a medio Pagare per l'archiviazione nel livello lake oltre alla capacità di calcolo on-demand per i processi KQL e i notebook. Il modello a copia singola consente di evitare addebiti di archiviazione duplicati in Sentinel e nel lake. Per informazioni dettagliate, vedere fatturazione Microsoft Sentinel data lake. |
Da alto a basso - ADX è un cluster di macchine virtuali, quindi viene addebitato in base all'uso di calcolo, archiviazione e rete, più un aumento ADX (vedi i dettagli dei prezzi). Più nodi si aggiungono e più dati vengono archiviati, maggiore è il costo. - ADX offre anche l'autoscaling per adattarsi alla domanda e beneficia dei prezzi delle istanze riservate. È possibile eseguire calcoli dei costi personalizzati nel Calcolatore prezzi Azure. |
Basso Con una configurazione ottimale, Archiviazione BLOB di Azure offre i costi più bassi. Per una maggiore efficienza e una riduzione dei costi, usa gestione del ciclo di vita di Archiviazione di Azure per spostare automaticamente i blob meno recenti in livelli di archiviazione più economici. |
| Come accedere ai dati: | Query KQL e notebook Jupyter dal portale di Microsoft Defender; riportare i dati al livello di analisi quando necessario. | Query KQL dirette | Operatore externaldata KQL |
| Scenario: |
Impostazione predefinita consigliata Usare per la maggior parte delle nuove migrazioni quando si vuole la conservazione a lungo termine, l'analisi integrata e l'analisi avanzata all'interno di Microsoft Sentinel senza gestire l'infrastruttura. |
Accesso frequente Rilevante quando è necessario accedere frequentemente ai dati ed è necessario controllare le dimensioni e la configurazione del cluster. |
Conformità/controllo - Ottimale per memorizzare enormi quantità di dati non strutturati. - Rilevanti quando non è necessario un accesso rapido ai dati o alte prestazioni, ad esempio per scopi di conformità o audit. |
| Complessità: | Bassa | Medio | Bassa |
Considerazioni generali
Dopo aver esaminato il confronto della piattaforma, usare i fattori seguenti per finalizzare la decisione.
- In che modo l'organizzazione userà i log inseriti?
- Quanto velocemente deve essere eseguita la migrazione?
- Qual è la quantità di dati da inserire?
- Quali sono i costi stimati per la migrazione, durante e dopo la migrazione?
Considera come la tua organizzazione utilizzerà i log ingeriti
Definite come la tua organizzazione utilizzerà i log acquisiti per orientare la scelta della piattaforma di acquisizione.
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 quando l'organizzazione accede ai dati, le prestazioni elevate e la facilità d'uso non sono prioritarie.
- L'organizzazione deve conservare i log in modo che i team possano accedervi facilmente e in modo abbastanza rapido.
- L'organizzazione deve conservare i log in modo che i team possano accedervi occasionalmente. Le prestazioni e la facilità d'uso sono secondarie.
Nella maggior parte degli scenari di conformità, accesso frequente e accesso occasionale, il data lake Microsoft Sentinel è il target raccomandato. Esamina la tabella di confronto delle piattaforme target alternative quando una delle piattaforme alternative soddisfa un investimento esistente o un requisito specializzato.
Valutare i fattori che influenzano la velocità di migrazione
In alcuni scenari, è necessario rispettare una scadenza ristretta. Ad esempio, l'organizzazione potrebbe dover passare urgentemente da un sistema SIEM precedente a causa di un evento di scadenza della licenza.
Esaminare i componenti e i fattori che determinano la velocità di migrazione: origine dati, potenza di calcolo e piattaforma di destinazione.
Come la fonte dati influenza la velocità di migrazione
L'origine dati è in genere un file system locale o un archivio cloud, ad esempio Amazon S3. Le prestazioni di archiviazione di un server dipendono da più fattori, tra cui la tecnologia del disco (SSD e HDD), la natura delle richieste di I/O e le dimensioni di ogni richiesta.
Ad esempio, Azure le prestazioni delle macchine virtuali 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 che usano dischi NVM Express (NVMe). Informazioni su come progettare la macchina virtuale Azure per prestazioni di archiviazione elevate. Puoi anche applicare la maggior parte di questi concetti di progettazione delle prestazioni dello storage VM Azure ai server on-premise.
Come la capacità di calcolo influisce sulla velocità di migrazione
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. Quando la potenza di calcolo è il collo di bottiglia, è possibile scegliere una di queste opzioni di ridimensionamento:
- Scala verticalmente: aumenta la potenza di un singolo server aggiungendo più CPU o aumentando la velocità della CPU.
- Scala orizzontalmente" Aggiungi più server, il che aumenta il parallelismo del processo di copia.
Come la piattaforma target influenza la velocità di migrazione
Microsoft Sentinel data lake, Esplora dati di Azure e Archiviazione BLOB di Azure hanno ciascuno un profilo di prestazioni diverso.
- Microsoft Sentinel data lake: Il data lake è progettato per l'ingestione ad alta produttività di grandi volumi di dati di sicurezza. Poiché l'archiviazione e il calcolo sono separati, l'acquisizione dei dati può essere scalata in modo indipendente rispetto ai carichi di lavoro delle query. Per i limiti del servizio, vedere Limiti del servizio Data Lake di Microsoft Sentinel.
- Esplora dati di Azure: Le prestazioni di ingestione variano a seconda della dimensione del cluster che si fornisce e delle impostazioni di batching 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 della dimensione dei file, della dimensione del lavoro, della concorrenza e di altri fattori. Informazioni su come ottimizzare le prestazioni di AzCopy con archiviazione Azure.
Valutare come il volume dei dati influenzi la pianificazione della migrazione
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 individuare dove potrebbe trovarsi il collo di bottiglia, occorre considerare la quantità di dati e la velocità di acquisizione della piattaforma di destinazione. Ad esempio, se si seleziona una piattaforma di destinazione in grado di inserire 1 GB al secondo ed è necessario eseguire la migrazione di 100 TB, la migrazione richiede almeno 100.000 GB diviso per 1 GB al secondo. Dividere il risultato per 3.600 e la migrazione richiede almeno 27 ore. La stima della durata minima di 27 ore è corretta solo quando il resto dei componenti della pipeline—come il disco locale, la rete e le macchine virtuali—può funzionare a una velocità di 1 GB al secondo.