Gestire l'accesso ai dati Microsoft Sentinel per risorsa

L'accesso a un'area di lavoro viene gestito tramite Azure controllo degli accessi in base al ruolo. In genere, anche gli utenti che hanno accesso a un'area di lavoro Log Analytics abilitata per Microsoft Sentinel hanno accesso a tutti i dati dell'area di lavoro, incluso il contenuto di sicurezza. Gli amministratori possono usare Azure ruoli per configurare l'accesso a funzionalità specifiche in Microsoft Sentinel, a seconda dei requisiti di accesso nel team.

Tuttavia, è possibile che alcuni utenti debbano accedere solo a dati specifici nell'area di lavoro, ma non abbiano accesso all'intero ambiente Microsoft Sentinel. Ad esempio, è possibile fornire a un team di operazioni non di sicurezza (non SOC) l'accesso ai dati degli eventi di Windows per i server di cui è proprietario.

In questi casi, è consigliabile configurare il controllo degli accessi in base al ruolo in base alle risorse consentite agli utenti, anziché fornire loro l'accesso all'area di lavoro o a specifiche funzionalità di Microsoft Sentinel. Questo metodo è noto anche come configurazione del controllo degli accessi in base al contesto delle risorse.

Quando gli utenti hanno accesso ai dati Microsoft Sentinel tramite le risorse a cui possono accedere anziché all'area di lavoro, possono visualizzare i log e le cartelle di lavoro usando i metodi seguenti:

Tramite la risorsa stessa, ad esempio una macchina virtuale Azure. Usare questo metodo per visualizzare i log e le cartelle di lavoro solo per una risorsa specifica.
Tramite Azure Monitor. Usare questo metodo quando si desidera creare query che si estendono su più risorse e/o gruppi di risorse. Quando si accede a log e cartelle di lavoro in monitoraggio Azure, definire l'ambito in uno o più gruppi di risorse o risorse specifici.

Abilitare il controllo degli accessi in base al contesto delle risorse in Monitoraggio Azure. Per altre informazioni, vedere Gestire l'accesso ai dati di log e alle aree di lavoro in Azure Monitor.

Nota

Se i dati non sono una risorsa Azure, ad esempio i dati syslog, CEF o Microsoft Entra ID o i dati raccolti da un agente di raccolta personalizzato, sarà necessario configurare manualmente l'ID risorsa usato per identificare i dati e abilitare l'accesso. Per altre informazioni, vedere Configurare in modo esplicito il controllo degli accessi in base al contesto delle risorse per le risorse non Azure.

Inoltre, le funzioni e le ricerche salvate non sono supportate nei contesti incentrati sulle risorse. Pertanto, Microsoft Sentinel funzionalità come l'analisi e la normalizzazione non sono supportate per il controllo degli accessi in base al ruolo nel contesto di risorse in Microsoft Sentinel.

Scenari per il controllo degli accessi in base al ruolo nel contesto delle risorse

La tabella seguente evidenzia gli scenari in cui il controllo degli accessi in base al ruolo del contesto delle risorse è più utile. Si noti le differenze nei requisiti di accesso tra i team SOC e i team non SOC.

Tipo di requisito	Team SOC	Team non SOC
Autorizzazioni	L'intera area di lavoro	Solo risorse specifiche
Accesso ai dati	Tutti i dati nell'area di lavoro	Solo i dati per le risorse a cui il team è autorizzato ad accedere
Funzionalità	L'esperienza di Microsoft Sentinel completa, possibilmente limitata dalle autorizzazioni funzionali assegnate all'utente	Solo query di log e cartelle di lavoro

Se il team ha requisiti di accesso simili al team non SOC descritto nella tabella precedente, il controllo degli accessi in base al ruolo nel contesto delle risorse potrebbe essere una buona soluzione per l'organizzazione.

Ad esempio, l'immagine seguente mostra una versione semplificata di un'architettura dell'area di lavoro in cui i team di sicurezza e operazioni devono accedere a diversi set di dati e il controllo degli accessi in base al ruolo del contesto di risorsa viene usato per fornire le autorizzazioni necessarie.

In questa immagine:

L'area di lavoro Log Analytics abilitata per Microsoft Sentinel viene inserita in una sottoscrizione separata per isolare meglio le autorizzazioni dalla sottoscrizione usata dai team delle applicazioni per ospitare i carichi di lavoro.
Ai team delle applicazioni viene concesso l'accesso ai rispettivi gruppi di risorse, in cui possono gestire le risorse.

Questa sottoscrizione separata e il controllo degli accessi in base al contesto delle risorse consentono a questi team di visualizzare i log generati dalle risorse a cui hanno accesso, anche quando i log vengono archiviati in un'area di lavoro in cui non hanno accesso diretto. I team delle applicazioni possono accedere ai log tramite l'area Log del portale di Azure, per visualizzare i log per una risorsa specifica o tramite monitoraggio Azure, per visualizzare tutti i log a cui possono accedere contemporaneamente.

Configurare in modo esplicito il controllo degli accessi in base al ruolo del contesto delle risorse per le risorse non Azure

Azure risorse hanno il supporto predefinito per il controllo degli accessi in base al ruolo nel contesto delle risorse, ma potrebbero richiedere un'ottimizzazione aggiuntiva quando si usano risorse non Azure. Ad esempio, i dati nell'area di lavoro Log Analytics abilitati per Microsoft Sentinel che non sono Azure risorse includono dati Syslog, CEF o AAD o dati raccolti da un agente di raccolta personalizzato.

Se si vuole configurare il controllo degli accessi in base al ruolo nel contesto delle risorse, usare la procedura seguente, ma i dati non sono una risorsa Azure.

Per configurare in modo esplicito il controllo degli accessi in base al contesto delle risorse:

Assicurarsi di aver abilitato il controllo degli accessi in base al contesto delle risorse in Monitoraggio Azure.
Creare un gruppo di risorse per ogni team di utenti che devono accedere alle risorse senza l'intero ambiente Microsoft Sentinel.

Assegnare autorizzazioni di lettura log per ogni membro del team.
Assegnare risorse ai gruppi di team di risorse creati e contrassegnare gli eventi con gli ID delle risorse pertinenti.

Quando Azure risorse inviano dati a Microsoft Sentinel, i record di log vengono automaticamente contrassegnati con l'ID risorsa dell'origine dati.

Consiglio

È consigliabile raggruppare le risorse per cui si concede l'accesso in un gruppo di risorse specifico creato per lo scopo.

In caso contrario, assicurarsi che il team disponga delle autorizzazioni di lettura dei log direttamente per le risorse a cui si vuole accedere.

Per altre informazioni sugli ID risorsa, vedere:

ID risorsa con inoltro dei log

Quando gli eventi vengono raccolti usando COMMON Event Format (CEF) o Syslog, l'inoltro dei log viene usato per raccogliere eventi da più sistemi di origine.

Ad esempio, quando una macchina virtuale di inoltro CEF o Syslog è in ascolto delle origini che inviano eventi Syslog e le inoltra a Microsoft Sentinel, l'ID risorsa della macchina virtuale di inoltro dei log viene assegnato a tutti gli eventi che inoltrano.

Se sono presenti più team, assicurarsi di disporre di macchine virtuali di inoltro log separate che elaborano gli eventi per ogni team separato.

Ad esempio, la separazione delle macchine virtuali garantisce che gli eventi Syslog appartenenti al team A vengano raccolti usando la macchina virtuale dell'agente di raccolta A.

Consiglio

Quando si usa una macchina virtuale locale o un'altra macchina virtuale cloud, ad esempio AWS, come server d'inoltro del log, assicurarsi che disponga di un ID risorsa implementando Azure Arc.
Per ridimensionare l'ambiente della macchina virtuale di inoltro dei log, è consigliabile creare un set di scalabilità di macchine virtuali per raccogliere i log CEF e Syslog.

ID risorsa con raccolta Logstash

Se si raccolgono i dati usando il plug-in di output Microsoft Sentinel Logstash, usare il campo azure_resource_id per configurare l'agente di raccolta personalizzato per includere l'ID risorsa nell'output.

Se si usa il controllo degli accessi in base al ruolo del contesto di risorsa e si vuole che gli eventi raccolti dall'API siano disponibili per utenti specifici, usare l'ID risorsa del gruppo di risorse creato per gli utenti.

Ad esempio, il codice seguente mostra un file di configurazione Logstash di esempio:

 input {
     beats {
         port => "5044"
     }
 }
 filter {
 }
 output {
     microsoft-logstash-output-azure-loganalytics {
       workspace_id => "4g5tad2b-a4u4-147v-a4r7-23148a5f2c21" # <your workspace id>
       workspace_key => "u/saRtY0JGHJ4Ce93g5WQ3Lk50ZnZ8ugfd74nk78RPLPP/KgfnjU5478Ndh64sNfdrsMni975HJP6lp==" # <your workspace key>
       custom_log_table_name => "tableName"
       azure_resource_id => "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Consiglio

È possibile aggiungere più output sezioni per distinguere i tag applicati a eventi diversi.

ID risorsa con la raccolta di API Log Analytics

Quando si raccoglie usando l'API agente di raccolta dati di Log Analytics, è possibile assegnare a eventi con un ID risorsa usando l'intestazione della richiesta HTTP x-ms-AzureResourceId .

Alternative al controllo degli accessi in base al ruolo nel contesto delle risorse

A seconda delle autorizzazioni necessarie nell'organizzazione, l'uso del controllo degli accessi in base al contesto delle risorse potrebbe non fornire una soluzione completa. Si consideri, ad esempio, se l'organizzazione la cui architettura è descritta nella sezione precedente deve anche concedere l'accesso ai log di Office 365 a un team di controllo interno. In questo caso, possono usare il controllo degli accessi in base al ruolo a livello di tabella per concedere al team di controllo l'accesso all'intera tabella OfficeActivity , senza concedere autorizzazioni ad altre tabelle.

L'elenco seguente descrive gli scenari in cui altre soluzioni per l'accesso ai dati possono soddisfare meglio i requisiti:

Scenario	Soluzione
Una filiale ha un team SOC che richiede un'esperienza di Microsoft Sentinel completa.	In questo caso, usare un'architettura a più aree di lavoro per separare le autorizzazioni per i dati. Per altre informazioni, vedere: Estendere Microsoft Sentinel tra aree di lavoro e tenant > Usare gli eventi imprevisti in molte aree di lavoro contemporaneamente
Si vuole fornire l'accesso a un tipo specifico di evento.	Ad esempio, fornire a un amministratore di Windows l'accesso agli eventi Sicurezza di Windows in tutti i sistemi. In questi casi, usare il controllo degli accessi in base al ruolo a livello di tabella per definire le autorizzazioni per ogni tabella.
Limitare l'accesso a un livello più granulare, non basato sulla risorsa o solo a un subset dei campi in un evento	Ad esempio, è possibile limitare l'accesso ai log Office 365 in base alla filiale di un utente. In questo caso, fornire l'accesso ai dati usando l'integrazione predefinita con i dashboard e i report di Power BI.
Limitare l'accesso per gruppo di gestione	Inserire Microsoft Sentinel in un gruppo di gestione separato dedicato alla sicurezza, assicurando che solo le autorizzazioni minime vengano ereditate ai membri del gruppo. All'interno del team di sicurezza assegnare le autorizzazioni a gruppi diversi in base a ogni funzione di gruppo. Poiché tutti i team hanno accesso all'intera area di lavoro, avranno accesso all'esperienza di Microsoft Sentinel completa, limitata solo dai ruoli Microsoft Sentinel assegnati. Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.

Per altre informazioni, vedere:

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-04-23