Progettare l'architettura delle aree di lavoro di Microsoft Azure Sentinel
Questo articolo fornisce un albero delle decisioni che consente di prendere decisioni chiave su come progettare l'architettura dell'area di lavoro di Microsoft Sentinel. Per altre informazioni, vedere Progetti di aree di lavoro di esempio di Microsoft Sentinel e procedure consigliate per l'architettura dell'area di lavoro di Microsoft Sentinel. Questo articolo fa parte della Guida alla distribuzione per Microsoft Sentinel.
Prerequisiti
Prima di esaminare l'albero delle decisioni, assicurarsi di avere le informazioni seguenti:
| Prerequisito | Descrizione |
|---|---|
| Requisiti normativi relativi alla residenza dei dati di Azure | Microsoft Sentinel può essere eseguito nelle aree di lavoro nella maggior parte delle aree, ma non in tutte le aree supportate in disponibilità generale per Log Analytics. Le aree di Log Analytics appena supportate potrebbero richiedere del tempo per eseguire l'onboarding del servizio Microsoft Sentinel. I dati generati da Microsoft Sentinel, ad esempio eventi imprevisti, segnalibri e regole di analisi, potrebbero contenere alcuni dati dei clienti originati dalle aree di lavoro Log Analytics del cliente. Per altre informazioni, vedere Disponibilità geografica e residenza dei dati. |
| Origini dati | Individuare le origini dati necessarie per connettersi, inclusi i connettori predefiniti alle soluzioni Microsoft e non Microsoft. È anche possibile usare Common Event Format (CEF), Syslog o REST-API per connettere le origini dati con Microsoft Sentinel. Se si dispone di macchine virtuali di Azure in più posizioni di Azure da cui è necessario raccogliere i log e il risparmio sui costi di uscita dei dati è importante per l'utente, è necessario calcolare il costo di uscita dei dati usando il calcolatore prezzi della larghezza di banda per ogni località di Azure. |
| Ruoli utente e livelli di accesso ai dati/autorizzazioni | Microsoft Sentinel usa il controllo degli accessi in base al ruolo di Azure per fornire ruoli predefiniti che possono essere assegnati a utenti, gruppi e servizi in Azure. Tutti i ruoli predefiniti di Microsoft Sentinel concedono l'accesso in lettura ai dati nell'area di lavoro di Microsoft Sentinel. È quindi necessario determinare se è necessario controllare l'accesso ai dati per ogni origine dati o livello di riga, in quanto ciò influirà sulla decisione di progettazione dell'area di lavoro. Per altre informazioni, vedere Ruoli personalizzati e controllo degli accessi in base al ruolo avanzato di Azure. |
| Frequenza di inserimento giornaliera | La frequenza di inserimento giornaliera, in genere in GB/giorno, è uno dei fattori chiave della gestione dei costi e delle considerazioni sulla pianificazione e sulla progettazione dell'area di lavoro per Microsoft Sentinel. Nella maggior parte degli ambienti cloud e ibridi, i dispositivi di rete, ad esempio firewall o proxy, e i server Windows e Linux producono i dati più inseriti. Per ottenere i risultati più accurati, Microsoft consiglia un inventario completo delle origini dati. In alternativa, il calcolatore dei costi di Microsoft Sentinel include tabelle utili per stimare i footprint delle origini dati. Importante: queste stime sono un punto di partenza e le impostazioni di dettaglio dei log e il carico di lavoro produrranno variazioni. È consigliabile monitorare regolarmente il sistema per tenere traccia delle modifiche. Il monitoraggio regolare è consigliato in base al proprio scenario. Per ulteriori informazioni, consultare Dettagli dei prezzi dei log del Monitoraggio di Azure. |
Albero delle decisioni
L'immagine seguente mostra un grafico di flusso completo dell'albero delle decisioni per comprendere come progettare al meglio l'area di lavoro.
Le sezioni seguenti forniscono una versione full-text di questo albero delle decisioni, incluse le note seguenti a cui fa riferimento l'immagine:
Nota #1 | Nota #2 | Nota #3 | Nota #4 | Nota #5 | Nota #6 Nota #7 | | Nota #8 | Nota #9 | Nota #10
Passaggio 1: Area di lavoro nuova o esistente?
Si dispone di un'area di lavoro esistente che è possibile usare per Microsoft Sentinel?
In caso contrario, si creerà una nuova area di lavoro in qualsiasi caso, continuare direttamente con il passaggio 2.
Se si dispone di un'area di lavoro esistente che è possibile usare, prendere in considerazione la quantità di dati che verranno inseriti.
Se si inseriscono più di 100 GB al giorno, è consigliabile usare un'area di lavoro separata per l'efficienza dei costi.
Se si inseriscono meno di 100 GB al giorno, continuare con il passaggio 2 per un'ulteriore valutazione. Considerare di nuovo questa domanda quando si presenta nel passaggio 5.
Passaggio 2: Mantenere i dati in aree geografiche di Azure diverse?
Se sono previsti requisiti normativi per mantenere i dati in aree geografiche di Azure diverse, usare un'area di lavoro di Microsoft Sentinel separata per ogni area di Azure con requisiti di conformità. Per altre informazioni, vedere Considerazioni sull'area geografica.
Se non è necessario mantenere i dati in aree geografiche di Azure diverse, continuare con il passaggio 3.
Passaggio 3: Sono presenti più tenant di Azure?
Se si ha un solo tenant, continuare direttamente con il passaggio 4.
Se si hanno più tenant di Azure, valutare se si raccolgono log specifici di un limite del tenant, ad esempio Office 365 o Microsoft Defender XDR.
Se non si hanno log specifici del tenant, continuare direttamente con il passaggio 4.
Se si raccolgono log specifici del tenant, usare un'area di lavoro di Microsoft Sentinel separata per ogni tenant di Microsoft Entra. Continuare con il passaggio 4 per altre considerazioni.
Nota sull'albero delle decisioni n. 1: i log specifici dei limiti del tenant, ad esempio da Office 365 e Microsoft Defender per il cloud, possono essere archiviati solo nell'area di lavoro all'interno dello stesso tenant.
Anche se è possibile usare agenti di raccolta personalizzati per raccogliere log specifici del tenant da un'area di lavoro in un altro tenant, non è consigliabile farlo a causa degli svantaggi seguenti:
- I dati raccolti dai connettori personalizzati verranno inseriti in tabelle personalizzate. Pertanto, non sarà possibile usare tutte le regole e le cartelle di lavoro predefinite.
- Le tabelle personalizzate non vengono considerate da alcune delle funzionalità predefinite, ad esempio UEBA e regole di Machine Learning.
- Costi aggiuntivi e impegno necessari per i connettori personalizzati, ad esempio l'uso di Funzioni di Azure e app per la logica.
Se questi svantaggi non sono un problema per l'organizzazione, continuare con il passaggio 4 anziché usare aree di lavoro di Microsoft Sentinel separate.
Passaggio 4: Suddivisione della fatturazione/chargeback?
Se è necessario suddividere la fatturazione o il chargeback, valutare se la creazione di report sull'utilizzo o l'addebito incrociato manuale funziona per l'utente.
Se non è necessario suddividere la fatturazione o il chargeback, continuare con il passaggio 5.
Se è necessario suddividere la fatturazione o il chargeback, prendere in considerazione l'uso dell'addebito incrociato manuale. Per ottenere costi accurati per entità, è possibile usare una versione modificata della cartella di lavoro Costo di Microsoft Sentinel che suddivide il costo in base all'entità.
Se la creazione di report sull'utilizzo o l'addebito incrociato manuale funziona per l'utente, continuare con il passaggio 5.
Se nessuna delle due segnalazioni di utilizzo o l'addebito incrociato manuale funzionerà per l'utente, usare un'area di lavoro separata di Microsoft Sentinel per ogni proprietario dei costi.
Nota sull'albero delle decisioni n. 2: per altre informazioni, vedere Costi e fatturazione di Microsoft Sentinel.
Passaggio 5: Raccolta di dati non SOC?
Se non si raccolgono dati non SOC, ad esempio i dati operativi, è possibile passare direttamente al passaggio 6.
Se si raccolgono dati non SOC, valutare se sono presenti sovrapposizioni, in cui la stessa origine dati è necessaria per i dati SOC e non SOC.
Se si hanno sovrapposizioni tra i dati SOC e non SOC, considerare i dati sovrapposti solo come dati SOC. Valutare quindi se l'inserimento per i dati SOC e non SOC singolarmente è minore di 100 GB/giorno, ma più di 100 GB/giorno quando combinato:
- Sì: procedere con il passaggio 6 per un'ulteriore valutazione.
- No: non è consigliabile usare la stessa area di lavoro per motivi di efficienza dei costi. Procedere con il passaggio 6 per un'ulteriore valutazione.
In entrambi i casi, per altre informazioni, vedere la nota 10.
Se non sono presenti dati sovrapposti, valutare se l'inserimento per i dati SOC e non SOC singolarmente è minore di 100 GB/giorno, ma più di 100 GB/giorno quando combinato:
- Sì: procedere con il passaggio 6 per un'ulteriore valutazione. Per altre informazioni, vedere la nota 3.
- No: non è consigliabile usare la stessa area di lavoro per motivi di efficienza dei costi. Procedere con il passaggio 6 per un'ulteriore valutazione.
Combinazione dei dati SOC e non SOC
Nota sull'albero delle decisioni n. 3: Sebbene in genere si consiglia ai clienti di mantenere un'area di lavoro separata per i dati non SOC, in modo che i dati non SOC non siano soggetti ai costi di Microsoft Sentinel, potrebbero verificarsi situazioni in cui la combinazione di dati SOC e non SOC è meno costosa rispetto alla separazione.
Si consideri, ad esempio, un'organizzazione con log di sicurezza che inseriscono 50 GB al giorno, i log delle operazioni che inseriscono a 50 GB al giorno e un'area di lavoro nell'area Stati Uniti orientali.
La tabella seguente confronta le opzioni dell'area di lavoro con e senza aree di lavoro separate.
Nota
I costi e i termini elencati nella tabella seguente sono falsi e usati solo a scopo illustrativo. Per informazioni aggiornate sui costi, vedere il calcolatore dei prezzi di Microsoft Sentinel.
| Architettura dell'area di lavoro | Descrizione |
|---|---|
| Il team SOC ha una propria area di lavoro, con Microsoft Sentinel abilitato. Il team Ops dispone di una propria area di lavoro, senza l'abilitazione di Microsoft Sentinel. |
Team SOC: Il costo di Microsoft Sentinel per 50 GB al giorno è di $ 6.500 al mese. I primi tre mesi di conservazione sono gratuiti. Team Ops: - Il costo di Log Analytics a 50 GB al giorno è di circa $ 3.500 al mese. - I primi 31 giorni di conservazione sono gratuiti. Il costo totale per entrambi è uguale a $ 10.000 al mese. |
| I team SOC e Ops condividono la stessa area di lavoro con Microsoft Sentinel abilitato. | Combinando entrambi i log, l'inserimento sarà di 100 GB al giorno, idoneo per l'idoneità per il livello di impegno (50% per Sentinel e 15% per LA). Il costo di Microsoft Sentinel per 100 GB/giorno è uguale a $ 9.000 al mese. |
In questo esempio si avrà un risparmio sui costi di $ 1.000 al mese combinando entrambe le aree di lavoro e il team Ops godrà anche di 3 mesi di conservazione gratuita invece di soli 31 giorni.
Questo esempio è rilevante solo quando i dati SOC e non SOC hanno una dimensione di >inserimento pari a =50 GB/giorno e <100 GB al giorno.
Nota sull'albero delle decisioni n. 10: è consigliabile usare un'area di lavoro separata per i dati non SOC in modo che i dati non SOC non siano soggetti ai costi di Microsoft Sentinel.
Tuttavia, questa raccomandazione per aree di lavoro separate per i dati non SOC proviene da una prospettiva puramente basata sui costi e ci sono altri fattori chiave di progettazione da esaminare quando determinare se usare una singola o più aree di lavoro. Per evitare il doppio costo di inserimento, è consigliabile raccogliere dati sovrapposti in una singola area di lavoro solo con il controllo degli accessi in base al ruolo di Azure a livello di tabella.
Passaggio 6: Più aree?
Se si raccolgono log da macchine virtuali di Azure solo in una singola area, continuare direttamente con il passaggio 7.
Se si raccolgono log da macchine virtuali di Azure in più aree, in che modo si preoccupano i costi di uscita dei dati?
Nota sull'albero delle decisioni n. 4: i dati in uscita fanno riferimento al costo della larghezza di banda per lo spostamento dei dati dai data center di Azure. Per altre informazioni, vedere Considerazioni sull'area geografica.
Se la riduzione della quantità di lavoro necessaria per mantenere aree di lavoro separate è una priorità, continuare con il passaggio 7.
Se il costo in uscita dei dati è sufficiente per rendere utile la gestione di aree di lavoro separate, usare un'area di lavoro separata di Microsoft Sentinel per ogni area in cui è necessario ridurre i costi di uscita dei dati.
Nota albero delle decisioni n. 5: è consigliabile avere il minor numero possibile di aree di lavoro. Usare il calcolatore prezzi di Azure per stimare il costo e determinare quali aree sono effettivamente necessarie e combinare le aree di lavoro per le aree con costi di uscita ridotti. I costi della larghezza di banda possono essere solo una piccola parte della fattura di Azure rispetto ai costi di inserimento di Microsoft Sentinel e Log Analytics separati.
Ad esempio, il costo potrebbe essere stimato come segue:
- 1.000 macchine virtuali, ognuna delle quali genera 1 GB al giorno;
- Invio di dati da un'area degli Stati Uniti a un'area dell'UE;
- Uso di una velocità di compressione 2:1 nell'agente
Il calcolo per questo costo stimato sarà:
1000 VMs * (1GB/day ÷ 2) * 30 days/month * $0.05/GB = $750/month bandwidth costQuesto costo di esempio sarebbe molto meno costoso rispetto ai costi mensili di un'area di lavoro Separata di Microsoft Sentinel e Log Analytics.
Nota
I costi elencati sono falsi e vengono utilizzati solo a scopo illustrativo. Per informazioni aggiornate sui costi, vedere il calcolatore dei prezzi di Microsoft Sentinel.
Passaggio 7: Separazione dei dati o definizione dei limiti in base alla proprietà?
Se non è necessario separare i dati o definire limiti di proprietà, continuare direttamente con il passaggio 8.
Se è necessario separare i dati o definire limiti in base alla proprietà, ogni proprietario dei dati deve usare il portale di Microsoft Sentinel?
Se ogni proprietario dei dati deve avere accesso al portale di Microsoft Sentinel, usare un'area di lavoro separata di Microsoft Sentinel per ogni proprietario.
Nota sull'albero delle decisioni n. 6: l'accesso al portale di Microsoft Sentinel richiede che ogni utente abbia almeno un ruolo lettore di Microsoft Sentinel, con autorizzazioni di lettura per tutte le tabelle nell'area di lavoro. Se un utente non ha accesso a tutte le tabelle nell'area di lavoro, dovrà usare Log Analytics per accedere ai log nelle query di ricerca.
Se l'accesso ai log tramite Log Analytics è sufficiente per tutti i proprietari senza accesso al portale di Microsoft Sentinel, continuare con il passaggio 8.
Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.
Passaggio 8: Controllo dell'accesso ai dati in base all'origine dati o alla tabella?
Se non è necessario controllare l'accesso ai dati in base all'origine o alla tabella, usare una singola area di lavoro di Microsoft Sentinel.
Se è necessario controllare l'accesso ai dati in base all'origine o alla tabella, è consigliabile usare il controllo degli accessi in base al ruolo del contesto delle risorse nelle situazioni seguenti:
Se è necessario controllare l'accesso a livello di riga, ad esempio fornire più proprietari in ogni origine dati o tabella
Se sono presenti più origini dati o tabelle personalizzate, in cui ognuna necessita di autorizzazioni separate
In altri casi, quando non è necessario controllare l'accesso a livello di riga, fornire più origini dati o tabelle personalizzate con autorizzazioni separate, usare una singola area di lavoro di Microsoft Sentinel, con il controllo degli accessi in base al ruolo a livello di tabella per il controllo di accesso ai dati.
Considerazioni sul contesto delle risorse o sul controllo degli accessi in base al ruolo a livello di tabella
Quando si prevede di usare il controllo degli accessi in base al ruolo a livello di risorsa o di tabella, prendere in considerazione le informazioni seguenti:
Nota sull'albero delle decisioni n. 7: per configurare il controllo degli accessi in base al ruolo del contesto delle risorse per le risorse non di Azure, è possibile associare un ID risorsa ai dati durante l'invio a Microsoft Sentinel, in modo che l'autorizzazione possa essere con ambito tramite il controllo degli accessi in base al ruolo del contesto delle risorse. Per altre informazioni, vedere Configurare in modo esplicito il controllo degli accessi in base al ruolo del contesto delle risorse e le modalità di accesso in base alla distribuzione.
Nota albero delle decisioni n. 8: le autorizzazioni delle risorse o il contesto delle risorse consentono agli utenti di visualizzare i log solo per le risorse a cui hanno accesso. La modalità di accesso all'area di lavoro deve essere impostata su Autorizzazioni utente o area di lavoro. Solo le tabelle rilevanti per le risorse in cui l'utente dispone delle autorizzazioni verranno incluse nei risultati della ricerca dalla pagina Log in Microsoft Sentinel.
Nota sull'albero delle decisioni n. 9: il controllo degli accessi in base al ruolo a livello di tabella consente di definire un controllo più granulare per i dati in un'area di lavoro Log Analytics oltre alle altre autorizzazioni. Questo controllo consente di definire tipi di dati specifici accessibili solo a un set specifico di utenti. Per altre informazioni, vedere Controllo degli accessi in base al ruolo a livello di tabella in Microsoft Sentinel.
Passaggi successivi
In questo articolo è stato esaminato un albero delle decisioni che consente di prendere decisioni chiave su come progettare l'architettura dell'area di lavoro di Microsoft Sentinel.