Progettare un'architettura dell'area di lavoro Log Analytics

Articolo
11/28/2023

Una singola area di lavoro Log Analytics potrebbe essere sufficiente per molti ambienti che usano Monitoraggio di Azure e Microsoft Sentinel. Tuttavia, molte organizzazioni creeranno più aree di lavoro per ottimizzare i costi e soddisfare meglio requisiti aziendali diversi. 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é molti clienti devono prendere in considerazione 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.

Ecco un video sui concetti fondamentali dei log di Monitoraggio di Azure e sulle procedure consigliate e sulle considerazioni di progettazione per la progettazione della distribuzione dei 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 nell'esecuzione di query sui dati da essi contenuti. Non esistono limitazioni delle prestazioni dalla 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 numero minimo che corrisponderà ai 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 ognuno dei criteri in modo indipendente. Prendere in considerazione i requisiti e le priorità per determinare quale progettazione sarà 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 o separare ognuno di essi nella propria area di lavoro. La combinazione offre una migliore visibilità su tutti i dati, mentre gli standard di sicurezza potrebbero richiedere la separazione in modo che 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. Diverse 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 da società affiliate o società affiliate.
Suddivisione della fatturazione	Inserendo aree di lavoro in sottoscrizioni separate, possono essere fatturate a parti diverse.
Conservazione e archiviazione dei dati	È possibile impostare impostazioni di conservazione diverse per ogni area di lavoro e ogni tabella in 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 per il 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 decisione se combinare i dati operativi di Monitoraggio di Azure nella stessa area di lavoro dei dati di sicurezza di Microsoft Sentinel o separarli 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.

L'area di lavoro combinata Combina 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 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 tabelle con dati di sicurezza o limitare gli utenti all'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 per gli addebiti per l'inserimento. Si consideri, ad esempio, un'organizzazione con dati operativi e dati di sicurezza ognuno che inserisce circa 50 GB al giorno. 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 di sicurezza in ogni tenant.

Se si usano Sia Monitoraggio di Azure che Microsoft Sentinel: prendere in considerazione la separazione di ognuna in un'area di lavoro dedicata, se richiesta dal team di sicurezza o se comporta un risparmio sui costi. Valutare la possibilità di combinare i due per una migliore visibilità dei dati di monitoraggio combinati o se consente di raggiungere un livello di impegno.
Se si usano sia Microsoft Sentinel che Microsoft Defender per il 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 mantenere i dati in una determinata area. Ad esempio, un'azienda internazionale potrebbe individuare un'area di lavoro in ogni area geografica principale, ad esempio il Stati Uniti e l'Europa.

Se si hanno requisiti per mantenere i dati in una determinata area geografica: creare un'area di lavoro separata per ogni area con tali requisiti.
Se non si hanno requisiti per mantenere i dati in una determinata area geografica: usare una singola area di lavoro per tutte le aree.

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 in 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 sufficientemente significativi per 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 sufficientemente significativi per 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 limiti in base alla proprietà. Ad esempio, si potrebbero avere società affiliate o società affiliate diverse che richiedono la delineazione dei 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 di dati.

Suddivisione della fatturazione

Potrebbe essere necessario suddividere la fatturazione tra parti diverse o eseguire il chargeback a un cliente o a un'unità aziendale interna. È possibile usare Gestione 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, gruppo di risorse o 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 Gestione costi e fatturazione di Azure o una query di log fornisce report sui costi sufficientemente granulari per i requisiti. In caso contrario, usare un'area di lavoro separata per ogni proprietario dei costi.

Conservazione e archiviazione dei dati

È possibile configurare le impostazioni predefinite di conservazione e archiviazione dei dati 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 e archiviazione per tutti i dati in ogni tabella: usare una singola area di lavoro per tutte le risorse.
Se sono necessarie impostazioni di conservazione e archiviazione 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 il livello di 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 in 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 combinarli 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 tale area di lavoro. 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 del contesto delle risorse e dal controllo degli accessi in base al ruolo a livello di tabella.

Controllo degli accessi in base al ruolo del contesto delle risorse: per impostazione predefinita, se un utente ha accesso in lettura a una risorsa di Azure, eredita le autorizzazioni per uno dei dati di monitoraggio di tale risorsa inviati all'area di lavoro. Questo livello di accesso consente agli utenti di accedere alle informazioni sulle risorse gestite senza concedere l'accesso esplicito all'area di lavoro. Se è necessario bloccare questo accesso, è possibile modificare la modalità di controllo di accesso per richiedere autorizzazioni esplicite per l'area di lavoro.

Se si vuole che gli utenti possano accedere ai dati per le proprie risorse: mantenere la modalità di controllo di accesso predefinita delle autorizzazioni Usa risorsa o 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 dell'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 delle risorse che necessitano di dati operativi correlati alle risorse.

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

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 arm per le risorse critiche con la configurazione per l'area di lavoro alternativa in Azure DevOps o 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, quindi Monitoraggio di Azure e Microsoft Sentinel includono funzionalità che consentono di analizzare questi dati tra aree di lavoro. Per altre informazioni, vedi:

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 per amministrare le aree di lavoro situate in altri tenant. Ognuno dei tenant può rappresentare clienti separati o diverse business unit.

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 dei 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. 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ò avere impostazioni diverse per l'area di lavoro, ad esempio il limite di conservazione e dati.
Isolamento tra i clienti per la conformità e le normative.
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 è il caso soprattutto quando si analizzano i dati in più di 50 aree di lavoro.
Se i clienti non vengono distribuiti per la gestione delle risorse delegate 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.