Procedure consigliate per l'architettura delle aree di lavoro di Microsoft Azure Sentinel
Quando si pianifica la distribuzione dell'area di lavoro di Microsoft Sentinel, è necessario progettare anche l'architettura dell'area di lavoro Log Analytics. Le decisioni sull'architettura dell'area di lavoro sono in genere guidate dai requisiti aziendali e tecnici. Questo articolo esamina i fattori decisionali chiave per determinare l'architettura dell'area di lavoro appropriata per le organizzazioni, tra cui:
- Se si userà un singolo tenant o più tenant
- Eventuali requisiti di conformità per la raccolta e l'archiviazione dei dati
- Come controllare l'accesso ai dati di Microsoft Sentinel
- Implicazioni dei costi per diversi scenari
Per altre informazioni, vedere Progettare l'architettura dell'area di lavoro di Microsoft Sentinel e Progettare aree di lavoro di esempio per scenari comuni e attività di pre-distribuzione e prerequisiti per la distribuzione di Microsoft Sentinel.
Vedere il video relativo all'architettura di SecOps per il successo: Procedure consigliate per la distribuzione di Microsoft Sentinel.
Questo articolo fa parte della Guida alla distribuzione per Microsoft Sentinel.
Considerazioni sulla tenancy
Anche se numeri ridotti di aree di lavoro sono più semplici da gestire, in alcuni casi specifiche esigenze richiedono più tenant e aree di lavoro. Ad esempio, molte organizzazioni hanno un ambiente cloud che contiene più tenant di Microsoft Entra, risultanti da fusioni e acquisizioni o a causa di requisiti di separazione delle identità.
Per determinare il numero di tenant e aree di lavoro da usare, considerare che la maggior parte delle funzionalità di Microsoft Sentinel opera con una singola area di lavoro o una singola istanza di Microsoft Sentinel e che Microsoft Sentinel inserisce tutti i log ospitati nell'area di lavoro.
I costi sono una delle considerazioni principali per determinare l'architettura di Microsoft Sentinel. Per altre informazioni, vedere Costi e fatturazione di Microsoft Sentinel.
Uso di più tenant
Se si dispone di più tenant, ad esempio se si è un provider di servizi di sicurezza gestito (MSSP), è consigliabile creare almeno un'area di lavoro per ogni tenant di Microsoft Entra per supportare i connettori dati predefiniti, da servizio a servizi che funzionano solo all'interno del proprio tenant di Microsoft Entra.
Tutti i connettori basati sulle impostazioni di diagnostica non possono essere connessi a un'area di lavoro che non si trova nello stesso tenant in cui risiede la risorsa. Questo vale per i connettori, ad esempio Firewall di Azure, Archiviazione di Azure, Attività di Azure o MICROSOFT Entra ID.
Usare Azure Lighthouse per gestire più istanze di Microsoft Sentinel in tenant diversi.
Nota
I connettori dati dei partner sono spesso basati su raccolte di API o agenti e pertanto non sono collegati a uno specifico tenant di Microsoft Entra.
Considerazioni sulla conformità
Dopo aver raccolto, archiviato ed elaborato i dati, la conformità può diventare un requisito di progettazione importante, con un impatto significativo sull'architettura di Microsoft Sentinel. La possibilità di convalidare e dimostrare chi può accedere ai dati in tutte le condizioni è un requisito fondamentale di sovranità dei dati in molti paesi e aree geografiche, quindi per molti clienti è prioritario valutare i rischi e ottenere informazioni dettagliate nei flussi di lavoro di Microsoft Sentinel.
In Microsoft Sentinel i dati vengono archiviati ed elaborati principalmente nella stessa area geografica, con alcune eccezioni, ad esempio quando si usano le regole di rilevamento che sfruttano Machine Learning di Microsoft. In questi casi, i dati potrebbero essere copiati all'esterno dell'area di lavoro geografica per l'elaborazione.
Per altre informazioni, vedere:
- Disponibilità geografica e residenza dei dati
- Residenza dei dati in Azure
- Blog sull'archiviazione e l'elaborazione dei dati dell'UE nell'UE - Criteri ue
Per iniziare a convalidare la conformità, valutare le origini dati e come e dove inviano dati.
Nota
L'agente di Log Analytics supporta TLS 1.2 per garantire la sicurezza dei dati in transito tra l'agente e il servizio Log Analytics, nonché lo standard FIPS 140.
Se si inviano dati a un'area geografica o a un'area geografica diversa dall'area di lavoro di Microsoft Sentinel, indipendentemente dal fatto che la risorsa di invio risieda in Azure, è consigliabile usare un'area di lavoro nella stessa area geografica o nella stessa area geografica.
Considerazioni sulle aree
Usare istanze separate di Microsoft Sentinel per ogni area. Anche se Microsoft Sentinel può essere usato in più aree, potrebbe essere necessario disporre di requisiti per separare i dati in base a team, area geografica o sito o controlli e controlli che rendono i modelli in più aree impossibili o più complessi del necessario. L'uso di istanze e aree di lavoro separate per ogni area consente di evitare costi di larghezza di banda/in uscita per lo spostamento dei dati tra aree.
Quando si usano più aree, tenere presenti le considerazioni seguenti:
I costi in uscita si applicano in genere quando è necessario l'agente di Log Analytics o Monitoraggio di Azure per raccogliere i log, ad esempio nelle macchine virtuali.
Vengono addebitati anche costi in uscita internet, che potrebbero non influire sull'utente a meno che non si esportano dati all'esterno dell'area di lavoro Log Analytics. Ad esempio, è possibile che vengano addebitati addebiti in uscita internet se si esportano i dati di Log Analytics in un server locale.
I costi della larghezza di banda variano a seconda dell'area di origine e dell'area di destinazione e del metodo di raccolta. Per altre informazioni, vedere:
Usare modelli per le regole di analisi, le query personalizzate, le cartelle di lavoro e altre risorse per rendere più efficienti le distribuzioni. Distribuire i modelli anziché distribuire manualmente ogni risorsa in ogni area.
I connettori basati sulle impostazioni di diagnostica non comportano costi di larghezza di banda. Per altre informazioni, vedere Addebiti per i trasferimenti di dati tramite Log Analytics.
Ad esempio, se si decide di raccogliere i log da Macchine virtuali negli Stati Uniti orientali e inviarli a un'area di lavoro di Microsoft Sentinel negli Stati Uniti occidentali, verranno addebitati costi in ingresso per il trasferimento dei dati. Poiché l'agente di Log Analytics comprime i dati in transito, le dimensioni addebitate per la larghezza di banda potrebbero essere inferiori alle dimensioni dei log in Microsoft Sentinel.
Se si raccolgono log Syslog e CEF da più origini in tutto il mondo, è possibile configurare un agente di raccolta Syslog nella stessa area dell'area di lavoro di Microsoft Sentinel per evitare costi di larghezza di banda, purché la conformità non sia un problema.
Per capire se i costi della larghezza di banda giustificano aree di lavoro di Microsoft Sentinel separate, è necessario valutare il volume di dati da trasferire tra le aree. Usare il calcolatore dei prezzi di Azure per stimare i costi.
Per altre informazioni, vedere Residenza dei dati in Azure.
Considerazioni sull'accesso
Potrebbero essere previste situazioni in cui team diversi dovranno accedere agli stessi dati. Ad esempio, il team SOC deve avere accesso a tutti i dati di Microsoft Sentinel, mentre i team di operazioni e applicazioni dovranno accedere solo a parti specifiche. I team di sicurezza indipendenti potrebbero anche dover accedere alle funzionalità di Microsoft Sentinel, ma con diversi set di dati.
Combinare il controllo degli accessi in base al ruolo del contesto delle risorse e il controllo degli accessi in base al ruolo a livello di tabella per fornire ai team un'ampia gamma di opzioni di accesso che devono supportare la maggior parte dei casi d'uso.
Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.
Controllo degli accessi in base al ruolo nel contesto delle risorse
L'immagine seguente mostra una versione semplificata di un'architettura di area di lavoro in cui i team di sicurezza e operazioni hanno l'esigenza di accedere a set diversi di dati e viene usato il controllo degli accessi in base al ruolo nel contesto delle risorse per fornire le autorizzazioni necessarie.
In questa immagine l'area di lavoro di Microsoft Sentinel viene inserita in una sottoscrizione separata per isolare meglio le autorizzazioni.
Nota
Un'altra opzione consiste nell'inserire Microsoft Sentinel in un gruppo di gestione separato dedicato alla sicurezza, che garantisce che vengano ereditate solo le assegnazioni minime di autorizzazione. All'interno del team di sicurezza, a diversi gruppi vengono assegnate autorizzazioni in base alle relative funzioni. Poiché questi team hanno accesso all'intera area di lavoro, avranno accesso all'esperienza completa di Microsoft Sentinel, limitata solo dai ruoli di Microsoft Sentinel assegnati. Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.
Oltre alla sottoscrizione di sicurezza, viene usata una sottoscrizione separata per i ospitare i carichi di lavoro dei team di applicazioni. Ai team di applicazioni viene concesso l'accesso ai rispettivi gruppi di risorse, in cui possono gestire le loro risorse. Questo controllo degli accessi in base al ruolo nel contesto delle risorse e con sottoscrizioni separate consente a questi team di visualizzare i log generati da tutte le risorse a cui hanno accesso, anche se i log sono archiviati in un'area di lavoro a cui non hanno accesso diretto. I team di applicazioni possono accedere ai log tramite l'area Log del portale di Azure, per visualizzare i log per una risorsa specifica, oppure tramite Monitoraggio di Azure per visualizzare tutti i log a cui possono accedere contemporaneamente.
Le risorse di Azure dispongono del supporto predefinito per il controllo degli accessi in base al ruolo del contesto delle risorse, ma potrebbero richiedere un'ulteriore ottimizzazione quando si lavora con risorse non di Azure. Per altre informazioni, vedere Configurare in modo esplicito il controllo degli accessi in base al ruolo del contesto delle risorse.
Controllo degli accessi in base al ruolo a livello di tabella
Il controllo degli accessi in base al ruolo a livello di tabella consente di definire tipi di dati specifici (tabelle) in modo che siano accessibili solo a un set specificato di utenti.
Si consideri, ad esempio, se l'organizzazione la cui architettura è descritta nell'immagine precedente deve anche concedere l'accesso ai log di Office 365 a un team di controllo interno. In questo caso, potrebbe usare il controllo degli accessi in base al ruolo di tabella per concedere al team di controllo l'accesso all'intera tabella OfficeActivity, senza concedere autorizzazioni per altre tabelle.
Considerazioni sull'accesso con più aree di lavoro
Se sono presenti entità, filiali o aree geografiche diverse all'interno dell'organizzazione, ognuna con i propri team di sicurezza che devono accedere a Microsoft Sentinel, usare aree di lavoro separate per ogni entità o filiale. Implementare le aree di lavoro separate all'interno di un singolo tenant di Microsoft Entra o in più tenant usando Azure Lighthouse.
Il team SOC centrale può anche usare un'area di lavoro aggiuntiva facoltativa di Microsoft Sentinel per gestire artefatti centralizzati, ad esempio regole di analisi o cartelle di lavoro.
Per altre informazioni, vedere Semplificare l'uso di più aree di lavoro.
Procedure consigliate tecniche per la creazione dell'area di lavoro
Usare le procedure consigliate seguenti per creare l'area di lavoro Log Analytics che verrà usata per Microsoft Sentinel:
Quando si assegna un nome all'area di lavoro, includere Microsoft Sentinel o un altro indicatore, in modo che sia facile da identificare tra le altre aree di lavoro.
Usare la stessa area di lavoro sia per Microsoft Sentinel che per Microsoft Defender per il cloud, in modo che tutti i log raccolti da Microsoft Defender per il cloud possano essere inseriti e usati anche da Microsoft Sentinel. L'area di lavoro predefinita creata da Microsoft Defender for Cloud non verrà visualizzata come area di lavoro disponibile per Microsoft Sentinel.
Usare un cluster di aree di lavoro dedicato se l'inserimento dei dati previsto è all'incirca o superiore a 1 TB al giorno. Un cluster dedicato consente di proteggere le risorse per i dati di Microsoft Sentinel, che consentono prestazioni migliori delle query per set di dati di grandi dimensioni. I cluster dedicati offrono anche l'opzione per una maggiore crittografia e controllo delle chiavi dell'organizzazione.
Non applicare un blocco delle risorse a un'area di lavoro Log Analytics che verrà usata per Microsoft Sentinel. Un blocco delle risorse in un'area di lavoro può causare errori in molte operazioni di Microsoft Sentinel.
Semplificare l'uso di più aree di lavoro
Se è necessario usare più aree di lavoro, semplificare la gestione e l'analisi degli eventi imprevisti condensando ed elencando tutti gli eventi imprevisti di ogni istanza di Microsoft Sentinel in un'unica posizione.
Per fare riferimento ai dati contenuti in altre aree di lavoro di Microsoft Sentinel, ad esempio nelle cartelle di lavoro tra aree di lavoro, usare query tra aree di lavoro.
Il momento migliore per usare le query tra aree di lavoro è quando le informazioni importanti vengono archiviate in un'area di lavoro, una sottoscrizione o un tenant diversi e possono fornire valore all'azione corrente. Ad esempio, il codice seguente mostra una query tra aree di lavoro di esempio:
union Update, workspace("contosoretail-it").Update, workspace("WORKSPACE ID").Update
| where TimeGenerated >= ago(1h)
| where UpdateState == "Needed"
| summarize dcount(Computer) by Classification
Per altre informazioni, vedere Estendere Microsoft Sentinel tra aree di lavoro e tenant.
Passaggi successivi
In questo articolo sono stati illustrati i fattori decisionali chiave per determinare l'architettura dell'area di lavoro appropriata per le organizzazioni.