Progettare un'architettura dell'area di lavoro Log Analytics

Anche se un'unica area di lavoro Log Analytics può essere sufficiente per molti ambienti usando Monitoraggio di Azure e Microsoft Sentinel, molte organizzazioni creeranno più aree di lavoro per ottimizzare i costi e soddisfare meglio i diversi requisiti aziendali. Questo articolo presenta un set di criteri per determinare se usare un'unica area di lavoro o più aree di lavoro e la configurazione e la posizione di tali aree di lavoro per soddisfare i requisiti specifici ottimizzando i costi.

Nota

Questo articolo include sia Monitoraggio di Azure che Microsoft Sentinel poiché molti clienti devono prendere in considerazione sia nella progettazione che nella maggior parte dei criteri decisionali si applicano entrambi. Se si usa solo uno di questi servizi, è sufficiente ignorare l'altro nella valutazione.

Strategia di progettazione

La progettazione deve iniziare sempre con un'unica area di lavoro perché riduce la complessità della gestione di più aree di lavoro e nell'esecuzione di query sui dati da essi. Non esistono limitazioni delle prestazioni dalla quantità di dati nell'area di lavoro e più servizi e origini dati possono inviare dati alla stessa area di lavoro. Quando si identificano i criteri per creare aree di lavoro aggiuntive, la progettazione deve usare il numero più basso che corrisponde ai requisiti specifici.

La progettazione di una configurazione dell'area di lavoro include la valutazione di più criteri, alcuni dei quali possono essere in conflitto. Ad esempio, è possibile ridurre gli addebiti in uscita creando un'area di lavoro separata in ogni area di Azure, ma il consolidamento in un'unica area di lavoro potrebbe consentire di ridurre ancora di più gli addebiti con un livello di impegno. Valutare ognuno dei criteri seguenti in modo indipendente e considerare i requisiti e le priorità specifici per determinare quale progettazione sarà più efficace per il proprio ambiente specifico.

Criteri di progettazione

La tabella seguente presenta brevemente i criteri da considerare nella progettazione dell'architettura dell'area di lavoro. Le sezioni seguenti descrivono ognuno di questi criteri in dettaglio completo.

Criteri Descrizione
Separare i dati operativi e di sicurezza Molti clienti creeranno aree di lavoro separate per i dati operativi e di sicurezza per la proprietà dei dati e il costo aggiuntivo di Microsoft Sentinel. In alcuni casi, tuttavia, potrebbe essere possibile risparmiare costi consolidando in un'unica area di lavoro per qualificarsi per un livello di impegno.
Tenant di Azure Se sono presenti più tenant di Azure, in genere si creerà un'area di lavoro in ognuna perché diverse origini dati possono inviare solo i dati di monitoraggio a un'area di lavoro nello stesso tenant di Azure.
Aree di Azure Ogni area di lavoro si trova in un'area di Azure specifica e potrebbe essere necessario disporre di requisiti normativi o di conformità per archiviare i dati in determinate posizioni.
Proprietà dei dati È possibile scegliere di creare aree di lavoro separate per definire la proprietà dei dati, ad esempio le filiali o le società associate.
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 tabella in un'area di lavoro, ma è necessario 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 hanno 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.

Separare i dati operativi e di sicurezza

La maggior parte dei clienti che usano Monitoraggio di Azure e Microsoft Sentinel creerà un'area di lavoro dedicata per ognuno per separare la proprietà dei dati tra i team operativi e di sicurezza e anche per ottimizzare i costi. Se Microsoft Sentinel è abilitato in un'area di lavoro, tutti i dati dell'area di lavoro sono soggetti ai prezzi di Sentinel, anche se sono dati operativi raccolti da Monitoraggio di Azure. Mentre un'area di lavoro con Sentinel ottiene 3 mesi di conservazione gratuita dei dati anziché 31 giorni, questo comporta in genere un costo più elevato per i dati operativi in un'area di lavoro senza Sentinel. Vedere Dettagli sui prezzi dei log di Monitoraggio di Azure.

L'eccezione è se la combinazione dei dati nella stessa area di lavoro 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 ogni inserimento di circa 50 GB al giorno. La combinazione dei dati nella stessa area di lavoro consente un livello di impegno a 100 GB al giorno che fornisce uno sconto del 15% per Monitoraggio di Azure e il 50% di sconto per Sentinel.

Se si creano aree di lavoro separate per altri criteri, in genere si creeranno coppie di aree di lavoro aggiuntive. Ad esempio, se sono presenti due tenant di Azure, è possibile creare quattro aree di lavoro, ovvero un'area di lavoro operativa e di sicurezza in ogni tenant.

  • Se si usano sia Monitoraggio di Azure che Microsoft Sentinal, creare un'area di lavoro separata per ognuna. È consigliabile combinare i due se consente di raggiungere un livello di impegno.

Tenant di Azure

La maggior parte delle risorse può inviare solo i dati di monitoraggio 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, che potrebbero essere uno scenario considerato come provider di servizi.

  • Se si dispone di un singolo tenant di Azure, creare un'unica area di lavoro per tale tenant.
  • Se sono presenti più tenant di Azure, creare un'area di lavoro per ogni tenant. Vedere Più strategie tenant per altre opzioni, tra cui strategie per i provider di servizi.

Aree di Azure

Le aree di lavoro Log Analytics risiedono in un'area di Azure specifica e possono avere scopi normativi o di conformità per mantenere i dati in un'area specifica. Ad esempio, un'azienda internazionale potrebbe individuare un'area di lavoro in ogni area geografica principale, ad esempio Stati Uniti e Europa.

  • Se si hanno requisiti per mantenere i dati in un'area geografica specifica, creare un'area di lavoro separata per ogni area con tali requisiti.
  • Se non si hanno requisiti per mantenere i dati in un'area geografica specifica, usare un'unica area di lavoro per tutte le aree.

È anche consigliabile considerare potenziali costi di larghezza di banda che possono essere applicati quando si inviano dati a un'area di lavoro da una risorsa in un'altra area, anche se questi addebiti sono in genere minori relativi 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 dei prezzi di Azure per stimare il costo e determinare quali aree sono effettivamente necessarie. Prendere in considerazione le aree di lavoro in più aree se gli addebiti per la larghezza di banda sono significativi.

  • Se i costi di larghezza di banda sono sufficienti per giustificare la complessità aggiuntiva, creare un'area di lavoro separata per ogni area con macchine virtuali.
  • Se i costi di larghezza di banda non sono sufficienti per giustificare la complessità aggiuntiva, usare un'unica area di lavoro per tutte le aree.

Proprietà dei dati

Potrebbe essere necessario separare i dati o definire limiti in base alla proprietà. Ad esempio, è possibile che siano presenti diverse filiali o società associate 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 un'unica area di lavoro per tutti i proprietari di dati.

Suddivisione della fatturazione

Potrebbe essere necessario dividere la fatturazione tra parti diverse o eseguire il addebito a un cliente o a un'unità aziendale interna. Gestione costi e fatturazione di Azure consente di 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, che può essere sufficiente per i requisiti di fatturazione.

  • Se non è necessario dividere la fatturazione o eseguire il chargeback, usare un'unica area di lavoro per tutti i proprietari dei costi.
  • Se è necessario suddividere la fatturazione o eseguire il chargeback, valutare se Gestione costi di Azure e fatturazione o una query di log offre report sui costi sufficienti 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. È possibile richiedere impostazioni diverse per diversi set di dati in una determinata tabella. In questo 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 è possibile richiedere 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 ai costi di inserimento dell'area di lavoro quando si esegue il commit in una determinata quantità 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 500 GB/giorno, è necessario implementare un cluster dedicato che offre funzionalità e prestazioni aggiuntive. I cluster dedicati consentono inoltre di combinare i dati da più aree di lavoro nel cluster per raggiungere il livello di un livello di impegno.

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

Limitazioni dell'agente legacy

Anche se è consigliabile evitare l'invio di dati duplicati a più aree di lavoro a causa degli addebiti aggiuntivi, 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 Log Analytics per Windows possono connettersi a più aree di lavoro. L'agente di Log Analytics per Linux può tuttavia 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 l'accesso solo a una singola area di lavoro.

Controllo di accesso ai dati

Quando si concede a un utente l'accesso a un'area di lavoro, ha accesso a tutti i dati nell'area di lavoro. Ciò è 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. Ciò consente agli utenti di accedere alle informazioni sulle risorse gestite senza concedere l'accesso esplicito all'area di lavoro. Se è necessario bloccare l'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 di Usare le autorizzazioni delle risorse o dell'area di lavoro.
  • Se si desidera assegnare in modo esplicito le autorizzazioni per tutti gli utenti, modificare la modalità di controllo di accesso impostando 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 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.

Uso di più aree di lavoro

Poiché molte progettazioni includeranno più aree di lavoro, Monitoraggio di Azure e Microsoft Sentinel includono funzionalità che consentono di analizzare questi dati tra aree di lavoro. Per informazioni dettagliate, vedere gli argomenti seguenti:

Più strategie del tenant

Gli ambienti con più tenant di Azure, inclusi i provider di servizi (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 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.

Esistono due strategie di base per questa funzionalità, come descritto di seguito.

Architettura distribuita

In un'architettura distribuita viene creata un'area di lavoro Log Analytics in ogni tenant di Azure. Questa è l'unica opzione 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 di Azure AD nel tenant del provider di servizi e 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 Azure Active Directory (B2B). Gli amministratori tenant del cliente gestiscono l'accesso individuale per ogni amministratore del provider di servizi e gli amministratori del provider di servizi devono accedere alla directory per ogni tenant nel portale di Azure per poter accedere a queste aree di lavoro.

I vantaggi di questa strategia sono:

  • 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 o 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 conservazione e limite di dati.
  • Isolamento tra i clienti per la conformità e le normative.
  • Addebito per ogni area di lavoro inclusa nella fattura per la sottoscrizione del cliente.

Gli svantaggi di questa strategia sono:

  • La visualizzazione centralizzata e l'analisi dei dati nei tenant dei clienti con strumenti come cartelle di lavoro di Monitoraggio di Azure possono comportare esperienze più lente, 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 delegate di Azure, è necessario effettuare il provisioning degli amministratori del provider di servizi nella directory del cliente. Ciò rende più difficile per il provider di servizi gestire contemporaneamente un numero elevato di tenant dei clienti.

Centralizzato

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

I vantaggi di questa strategia sono:

  • Facilità di gestione di un numero elevato di clienti.
  • Il provider di servizi ha la proprietà completa sui log e sui vari artefatti, ad esempio funzioni e query salvate.
  • Il provider di servizi può eseguire analisi in tutti i clienti.

Gli svantaggi di questa strategia sono:

  • I log possono essere raccolti solo dalle macchine virtuali con un agente. Non funzionerà con le origini dati PaaS, SaaS e Azure Fabric.
  • Può essere difficile separare i dati tra i clienti, perché i dati condividono una singola area di lavoro. Le query devono usare il nome di dominio completo (FQDN) del computer o l'ID sottoscrizione di Azure.
  • Tutti i dati di tutti i clienti verranno archiviati nella stessa area con un'unica fattura e con le stesse impostazioni di conservazione e di configurazione.

Ibrido

In un modello ibrido ogni tenant ha una propria area di lavoro e viene usato un meccanismo per eseguire il pull dei dati in una posizione centrale per la creazione di report e l'analisi. Questi dati possono includere un numero ridotto di tipi di dati o un riepilogo dell'attività, ad esempio le statistiche giornaliere.

Esistono due opzioni per implementare i log in una posizione centrale:

Passaggi successivi