Progettare un'architettura dell'area di lavoro Log Analytics

Articolo
10/15/2024

Una singola area di lavoro Log Analytics potrebbe essere sufficiente per molti ambienti che usano Monitoraggio di Azure e Microsoft Sentinel. Molte organizzazioni creano tuttavia più aree di lavoro per ottimizzare i costi e soddisfare meglio i requisiti aziendali. Questo articolo presenta un set di criteri per determinare se usare una singola area di lavoro o più aree di lavoro. Illustra anche la configurazione e il posizionamento di tali aree di lavoro per soddisfare i requisiti, ottimizzando al tempo stesso i costi.

Nota

Questo articolo illustra Monitoraggio di Azure e Microsoft Sentinel perché a molti clienti occorrono entrambi nella progettazione. La maggior parte dei criteri decisionali si applica a entrambi i servizi. Se si usa solo uno di questi servizi, è possibile ignorare l'altro nella valutazione.

In questo video vengono illustrate le nozioni di base dei log di Monitoraggio di Azure, le procedure consigliate e le considerazioni di progettazione per la progettazione di una distribuzione di log di monitoraggio di Azure:

Strategia di progettazione

La progettazione deve iniziare sempre con una singola area di lavoro per ridurre la complessità della gestione di più aree di lavoro e dell'esecuzione di query sui dati che contiene. Non esistono limitazioni delle prestazioni dovute alla quantità di dati nell'area di lavoro. Più servizi e origini dati possono inviare dati alla stessa area di lavoro. Quando si identificano i criteri per creare più aree di lavoro, la progettazione deve usare il minor numero di aree di lavoro per soddisfare i requisiti.

La progettazione di una configurazione dell'area di lavoro include la valutazione di più criteri. Ma alcuni dei criteri potrebbero essere in conflitto. Ad esempio, è possibile ridurre gli addebiti in uscita creando un'area di lavoro separata in ogni area di Azure. Il consolidamento in una singola area di lavoro potrebbe consentire di ridurre ulteriormente i costi con un livello di impegno. Valutare ogni criterio singolarmente. Prendere in considerazione i requisiti e le priorità per determinare quale progettazione sia più efficace per l'ambiente in uso.

Criteri di progettazione

La tabella seguente presenta i criteri da considerare quando si progetta l'architettura dell'area di lavoro. Le sezioni che seguono descrivono i criteri.

Criteri	Descrizione
Dati operativi e di sicurezza	È possibile scegliere di combinare i dati operativi di Monitoraggio di Azure nella stessa area di lavoro dei dati di sicurezza di Microsoft Sentinel oppure separare ognuno di essi nella propria area di lavoro. Se vengono combinati si ha una migliore visibilità su tutti i dati, ma gli standard di sicurezza potrebbero richiederne la separazione affinché il team di sicurezza disponga di un'area di lavoro dedicata. È anche possibile avere implicazioni in termini di costi per ogni strategia.
Tenant di Azure	Se si hanno più tenant di Azure, in genere si creerà un'area di lavoro in ogni tenant. Alcune origini dati possono inviare dati di monitoraggio solo a un'area di lavoro nello stesso tenant di Azure.
Aree di Azure	Ogni area di lavoro si trova in una determinata area di Azure. Potrebbero essere previsti requisiti normativi o di conformità per archiviare i dati in posizioni specifiche.
Proprietà dei dati	È possibile scegliere di creare aree di lavoro separate per definire la proprietà dei dati. Ad esempio, è possibile creare aree di lavoro per filiali o società affiliate.
Suddivisione della fatturazione	Inserendo le aree di lavoro in sottoscrizioni separate, possono essere fatturate a parti diverse.
Conservazione dei dati	È possibile impostare impostazioni di conservazione diverse per ogni area di lavoro e ogni tabella di un'area di lavoro. È necessaria un'area di lavoro separata se sono necessarie impostazioni di conservazione diverse per risorse diverse che inviano dati alle stesse tabelle.
Livelli di impegno	I livelli di impegno consentono di ridurre i costi di inserimento eseguendo il commit a una quantità minima di dati giornalieri in un'unica area di lavoro.
Limitazioni dell'agente legacy	Gli agenti di macchine virtuali legacy presentano limitazioni sul numero di aree di lavoro a cui possono connettersi.
Controllo di accesso ai dati	Configurare l'accesso all'area di lavoro e a tabelle e dati diversi da risorse diverse.
Resilienza	Per assicurarsi che i dati nell'area di lavoro siano disponibili in caso di errore dell'area, è possibile inserire dati in più aree di lavoro in aree diverse.

Dati operativi e di sicurezza

La scelta di combinare i dati operativi di Monitoraggio di Azure nella stessa area di lavoro dei dati di sicurezza di Microsoft Sentinel oppure di separarli ognuno nella propria area di lavoro dipende dai requisiti di sicurezza e dalle potenziali implicazioni sui costi per l'ambiente.

Aree di lavoro dedicate La creazione di aree di lavoro dedicate per Monitoraggio di Azure e Microsoft Sentinel consentirà di separare la proprietà dei dati tra i team operativi e di sicurezza. Questo approccio può anche essere utile per ottimizzare i costi poiché quando Microsoft Sentinel è abilitato in un'area di lavoro, tutti i dati in tale area di lavoro sono soggetti ai prezzi di Microsoft Sentinel, anche se sono dati operativi raccolti da Monitoraggio di Azure.

Un'area di lavoro con Microsoft Sentinel ottiene tre mesi di conservazione dei dati gratuita invece di 31 giorni. Questo scenario comporta in genere costi più elevati per i dati operativi in un'area di lavoro senza Microsoft Sentinel. Vedere Dettagli sui prezzi dei Log di Monitoraggio di Azure.

Area di lavoro combinata Combinare i dati di Monitoraggio di Azure e Microsoft Sentinel nella stessa area di lavoro offre una migliore visibilità su tutti i dati, consentendo di combinare entrambi facilmente sia nelle query che nelle cartelle di lavoro. Se l'accesso ai dati di sicurezza deve essere limitato a un determinato team, è possibile usare il controllo degli accessi in base al ruolo a livello di tabella per impedire a determinati utenti di accedere a tabelle con dati di sicurezza o per limitare agli utenti l'accesso all'area di lavoro usando il contesto delle risorse.

Questa configurazione può comportare risparmi sui costi se consente di raggiungere un livello di impegno, che offre uno sconto sui costi di inserimento. Si consideri, ad esempio, un'organizzazione con dati operativi e dati di sicurezza, che inserisce circa 50 GB al giorno per ciascun tipo di dati. La combinazione dei dati nella stessa area di lavoro consente un livello di impegno di 100 GB al giorno. Questo scenario offre uno sconto del 15% per Monitoraggio di Azure e uno sconto del 50% per Microsoft Sentinel.

Se si creano aree di lavoro separate per altri criteri, in genere si creeranno più coppie di aree di lavoro. Ad esempio, se si dispone di due tenant di Azure, è possibile creare quattro aree di lavoro con un'area di lavoro operativa e una di sicurezza in ogni tenant.

Se si usano sia Monitoraggio di Azure sia Microsoft Sentinel: prendere in considerazione la separazione di ognuna in un'area di lavoro dedicata se ciò è richiesto dal team di sicurezza o se comporta un risparmio sui costi. Valutare la possibilità di combinarle per una migliore visibilità sui dati di monitoraggio combinati o se ciò consente di raggiungere un livello di impegno.
Se si usano sia Microsoft Sentinel che Microsoft Defender for Cloud: è consigliabile usare la stessa area di lavoro per entrambe le soluzioni per mantenere i dati di sicurezza in un'unica posizione.

Tenant di Azure

La maggior parte delle risorse può inviare dati di monitoraggio solo a un'area di lavoro nello stesso tenant di Azure. Le macchine virtuali che usano l'agente di Monitoraggio di Azure o gli agenti di Log Analytics possono inviare dati alle aree di lavoro in tenant di Azure separati. Questo scenario può essere considerato come provider di servizi.

Se si ha un singolo tenant di Azure: creare una singola area di lavoro per tale tenant.
Se sono presenti più tenant di Azure: creare un'area di lavoro per ogni tenant. Per altre opzioni, incluse le strategie per i provider di servizi, vedere Strategie multi-tenant.

Aree di Azure

Ogni area di lavoro Log Analytics si trova in una determinata area di Azure. Potrebbero essere presenti scopi normativi o di conformità per cui occorre mantenere i dati in una determinata area. Ad esempio, un'azienda internazionale potrebbe collocare un'area di lavoro in ogni area geografica principale, ad esempio Stati Uniti ed Europa.

Se si hanno requisiti per il mantenimento dei dati in una determinata area geografica: creare un'area di lavoro separata per ogni area con tali requisiti.
Se non si hanno requisiti per il mantenimento dei dati in una determinata area geografica: usare una singola area di lavoro per tutte le aree.
Se si inviano dati a un'area geografica o a un'area esterna all'area dell'area di lavoro, indipendentemente dal fatto che la risorsa di invio risieda in Azure: prendere in considerazione l'uso di un'area di lavoro nella stessa area geografica o nella stessa area geografica dei dati.

Considerare anche i potenziali costi di larghezza di banda che potrebbero essere applicati quando si inviano dati a un'area di lavoro da una risorsa di un'altra area. Questi addebiti sono in genere minori rispetto ai costi di inserimento dei dati per la maggior parte dei clienti. Questi addebiti comportano in genere l'invio di dati all'area di lavoro da una macchina virtuale. Il monitoraggio dei dati da altre risorse di Azure tramite le impostazioni di diagnostica non comporta addebiti in uscita.

Usare il calcolatore prezzi di Azure per stimare il costo e determinare le aree necessarie. Prendere in considerazione le aree di lavoro in più aree se gli addebiti per la larghezza di banda sono significativi.

Se i costi della larghezza di banda sono abbastanza significativi da giustificare la complessità aggiuntiva: creare un'area di lavoro separata per ogni area con macchine virtuali.
Se i costi della larghezza di banda non sono abbastanza significativi da giustificare la complessità aggiuntiva: usare una singola area di lavoro per tutte le aree.

Proprietà dei dati

Potrebbe essere necessario separare i dati o definire i confini in base alla proprietà. Ad esempio, si potrebbero avere filiali o società affiliate diverse che richiedono di delineare i propri dati di monitoraggio.

Se è necessaria la separazione dei dati: usare un'area di lavoro separata per ogni proprietario dei dati.
Se non è necessaria la separazione dei dati: usare una singola area di lavoro per tutti i proprietari dei dati.

Suddivisione della fatturazione

Potrebbe essere necessario suddividere la fatturazione tra parti diverse o eseguire il chargeback a un cliente o a una business unit interna. È possibile usare Gestione dei costi e fatturazione di Azure per visualizzare gli addebiti in base all'area di lavoro. È anche possibile usare una query di log per visualizzare il volume di dati fatturabile per risorsa, per gruppo di risorse o per sottoscrizione di Azure. Questo approccio potrebbe essere sufficiente per i requisiti di fatturazione.

Se non è necessario suddividere la fatturazione o eseguire il chargeback: usare una singola area di lavoro per tutti i proprietari dei costi.
Se è necessario suddividere la fatturazione o eseguire il chargeback: valutare se la Gestione dei costi e fatturazione di Azure o una query di log fornisce report sui costi che siano sufficientemente granulari per i requisiti. In caso contrario, usare un'area di lavoro separata per ogni proprietario dei costi.

Conservazione dei dati

È possibile configurare le impostazioni di conservazione dei dati predefinite per un'area di lavoro o configurare impostazioni diverse per ogni tabella. Potrebbero essere necessarie impostazioni diverse per set di dati diversi in una tabella specifica. In tal caso, è necessario separare i dati in aree di lavoro diverse, ognuna con impostazioni di conservazione univoche.

Se è possibile usare le stesse impostazioni di conservazione per tutti i dati in ogni tabella: usare una singola area di lavoro per tutte le risorse.
Se sono necessarie impostazioni di conservazione diverse per risorse diverse nella stessa tabella: usare un'area di lavoro separata per risorse diverse.

Livelli di impegno

I livelli di impegno offrono uno sconto per i costi di inserimento dell'area di lavoro quando si esegue il commit a una quantità specifica di dati giornalieri. È possibile scegliere di consolidare i dati in una singola area di lavoro per raggiungere un determinato livello. Questo stesso volume di dati distribuito in più aree di lavoro non sarebbe idoneo per lo stesso livello, a meno che non si disponga di un cluster dedicato.

Se è possibile eseguire il commit all'inserimento giornaliero di almeno 100 GB al giorno, è necessario implementare un cluster dedicato che offre funzionalità e prestazioni aggiuntive. I cluster dedicati consentono anche di combinare i dati di più aree di lavoro nel cluster per raggiungere il livello di impegno.

Se si inseriscono almeno 100 GB al giorno tra tutte le risorse: creare un cluster dedicato e impostare il livello di impegno appropriato.
Se si inseriscono almeno 100 GB al giorno tra le risorse: è consigliabile combinarle in un'unica area di lavoro per sfruttare un livello di impegno.

Limitazioni dell'agente legacy

È consigliabile evitare di inviare dati duplicati a più aree di lavoro a causa dei costi aggiuntivi, ma potrebbero essere presenti macchine virtuali connesse a più aree di lavoro. Lo scenario più comune è un agente connesso a aree di lavoro separate per Monitoraggio di Azure e Microsoft Sentinel.

L'agente di Monitoraggio di Azure e l'agente di Log Analytics per Windows possono connettersi a più aree di lavoro. L'agente di Log Analytics per Linux può connettersi solo a una singola area di lavoro.

Se si usa l'agente di Log Analytics per Linux: eseguire la migrazione all'agente di Monitoraggio di Azure o assicurarsi che i computer Linux richiedano solo l'accesso a una singola area di lavoro.

Controllo di accesso ai dati

Quando si concede a un utente l'accesso a un'area di lavoro, l'utente ha accesso a tutti i dati in essa contenuti. Questo accesso è appropriato per un membro di un team di amministrazione centrale o di sicurezza che deve accedere ai dati per tutte le risorse. L'accesso all'area di lavoro è determinato anche dal controllo degli accessi in base al ruolo con contesto delle risorse e a livello di tabella.

Controllo degli accessi in base al ruolo con contesto delle risorse: per impostazione predefinita, se un utente ha accesso in lettura a una risorsa di Azure, eredita le autorizzazioni a tutti i dati di monitoraggio di tale risorsa inviati all'area di lavoro. Questo livello di accesso consente agli utenti di accedere alle informazioni sulle risorse che gestiscono, senza che gli venga concesso l'accesso esplicito all'area di lavoro. Se è necessario bloccare questo accesso, è possibile modificare la modalità di controllo di accesso in modo che richieda autorizzazioni esplicite per l'area di lavoro.

Se si vuole consentire agli utenti di accedere ai dati per le proprie risorse: mantenere la modalità di controllo di accesso predefinita di Usa autorizzazioni per la risorsa o l'area di lavoro.
Se si desidera assegnare in modo esplicito le autorizzazioni per tutti gli utenti: modificare la modalità di controllo di accesso in Richiedi autorizzazioni per l'area di lavoro.

Controllo degli accessi in base al ruolo a livello di tabella: con il controllo degli accessi in base al ruolo a livello di tabella, è possibile concedere o negare l'accesso a tabelle specifiche nell'area di lavoro. In questo modo, è possibile implementare autorizzazioni granulari necessarie per situazioni specifiche nell'ambiente.

Ad esempio, è possibile concedere l'accesso solo a tabelle specifiche raccolte da Microsoft Sentinel a un team di controllo interno. In alternativa, è possibile negare l'accesso alle tabelle correlate alla sicurezza ai proprietari di risorse a cui servono dati operativi correlati alle risorse.

Se non è necessario un controllo di accesso granulare in base alla tabella: concedere al team delle operazioni e della sicurezza l'accesso alle proprie risorse e consentire ai proprietari delle risorse di usare il controllo degli accessi in base al ruolo con contesto delle risorse per le proprie risorse.
Se è necessario un controllo di accesso granulare in base alla tabella: concedere o negare l'accesso a tabelle specifiche usando il controllo degli accessi in base al ruolo a livello di tabella.

Per altre informazioni, vedere Gestire l'accesso ai dati di Microsoft Sentinel in base alla risorsa.

Resilienza

Per assicurarsi che i dati critici nell'area di lavoro siano disponibili in caso di errore dell'area, è possibile inserire alcuni o tutti i dati in più aree di lavoro in aree diverse.

Questa opzione richiede la gestione dell'integrazione con altri servizi e prodotti separatamente per ogni area di lavoro. Anche se i dati saranno disponibili nell'area di lavoro alternativa in caso di errore, le risorse che si basano sui dati, ad esempio avvisi e cartelle di lavoro, non sapranno passare all'area di lavoro alternativa. Prendere in considerazione l'archiviazione dei modelli di ARM per le risorse critiche con la configurazione per l'area di lavoro alternativa in Azure DevOps oppure come criteri disabilitati che possono essere abilitati rapidamente in uno scenario di failover.

Usare più aree di lavoro

Molte progettazioni includono più aree di lavoro. Ad esempio, un team delle operazioni per la sicurezza centrale potrebbe usare le proprie aree di lavoro di Microsoft Sentinel per gestire artefatti centralizzati, ad esempio regole di analisi o cartelle di lavoro.

Sia Monitoraggio di Azure sia Microsoft Sentinel includono funzionalità che assistono nell'analisi di questi dati tra aree di lavoro. Per altre informazioni, vedi:

Quando si assegna un nome a ogni area di lavoro, è consigliabile includere un indicatore significativo nel nome in modo che sia possibile identificare facilmente lo scopo di ogni area di lavoro.

Strategie multi-tenant

Gli ambienti con più tenant di Azure, inclusi i provider di servizi Microsoft (MSP), i fornitori di software indipendenti (ISV) e le aziende di grandi dimensioni, spesso richiedono una strategia in cui un team di amministrazione centrale ha accesso ad amministrare le aree di lavoro situate in altri tenant. Ognuno dei tenant può rappresentare clienti separati o business unit diverse.

Nota

Per i partner e i provider di servizi che fanno parte del programma Cloud Solution Provider (CSP), Log Analytics in Monitoraggio di Azure è uno dei servizi di Azure disponibili nelle sottoscrizioni di Azure CSP.

Nelle sezioni seguenti sono descritte due strategie di base per questa funzionalità.

Architettura distribuita

In un'architettura distribuita viene creata un'area di lavoro Log Analytics in ogni tenant di Azure. Questa opzione è l'unica che è possibile usare se si esegue il monitoraggio di servizi di Azure diversi dalle macchine virtuali.

Sono disponibili due opzioni per consentire agli amministratori del provider di servizi di accedere alle aree di lavoro nei tenant dei clienti:

Usare Azure Lighthouse per accedere a ogni tenant del cliente. Gli amministratori del provider di servizi sono inclusi in un gruppo di utenti Microsoft Entra nel tenant del provider di servizi. A questo gruppo viene concesso l'accesso durante il processo di onboarding per ogni cliente. Gli amministratori possono quindi accedere alle aree di lavoro di ogni cliente dall'interno del proprio tenant del provider di servizi anziché dover accedere singolarmente al tenant di ogni cliente. Per altre informazioni, vedere Monitorare le risorse dei clienti su larga scala.
Aggiungere singoli utenti dal provider di servizi come utenti guest di Microsoft Entra (B2B). Gli amministratori tenant del cliente gestiscono l'accesso individuale per ogni amministratore del provider di servizi. Gli amministratori del provider di servizi devono accedere alla directory per ogni tenant nel portale di Azure per accedere a queste aree di lavoro.

Vantaggi di questa strategia:

I log possono essere raccolti da tutti i tipi di risorse.
Il cliente può confermare livelli specifici di autorizzazioni con la gestione delle risorse delegate di Azure. In alternativa, il cliente può gestire l'accesso ai log usando il proprio controllo degli accessi in base al ruolo di Azure.
Ogni cliente può definire impostazioni diverse per la propria area di lavoro, ad esempio in termini di conservazione e di limitazione sull'uso dei dati.
Isolamento tra i clienti in termini di normative e conformità.
L'addebito per ogni area di lavoro è incluso nella fattura per la sottoscrizione del cliente.

Svantaggi di questa strategia:

La visualizzazione centralizzata e l'analisi dei dati nei tenant dei clienti con strumenti come le cartelle di lavoro di Monitoraggio di Azure possono comportare esperienze più lente. Questo accade soprattutto quando si analizzano i dati in più di 50 aree di lavoro.
Se non viene eseguito l'onboarding dei clienti per la gestione delle risorse delegata di Azure, è necessario effettuare il provisioning degli amministratori del provider di servizi nella directory del cliente. Questo requisito rende più difficile per il provider di servizi gestire contemporaneamente molti tenant dei clienti.

Centralizzato

Viene creata una singola area di lavoro nella sottoscrizione del provider di servizi. Questa opzione può raccogliere dati solo dalle macchine virtuali dei clienti. Gli agenti installati nelle macchine virtuali sono configurati per inviare i log a questa area di lavoro centrale.