Gestire l'accesso ai dati di Microsoft Sentinel per risorsa

In genere, gli utenti che hanno accesso a un'area di lavoro di Microsoft Sentinel hanno anche accesso a tutti i dati dell'area di lavoro, incluso il contenuto di sicurezza. Gli amministratori possono usare i ruoli di Azure per configurare l'accesso a funzionalità specifiche in Microsoft Sentinel, a seconda dei requisiti di accesso nel team.

Tuttavia, potrebbe essere necessario avere alcuni utenti che devono accedere solo a dati specifici nell'area di lavoro di Microsoft Sentinel, ma non dovrebbero avere accesso all'intero ambiente Microsoft Sentinel. Ad esempio, è possibile fornire un team non di sicurezza (non SOC) con accesso ai dati degli eventi Windows per i server proprietari.

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

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

• Tramite la risorsa stessa, ad esempio una macchina virtuale di Azure. Usare questo metodo per visualizzare i log e le cartelle di lavoro solo per una risorsa specifica.

• Tramite Monitoraggio di Azure. Usare questo metodo quando si desidera creare query che si estendono su più risorse e/o gruppi di risorse. Quando si passa a log e cartelle di lavoro in Monitoraggio di Azure, definire l'ambito a uno o più gruppi di risorse o risorse specifici.

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

Nota

Se i dati non sono una risorsa di Azure, ad esempio Syslog, CEF o dati AAD raccolti da un agente di raccolta personalizzata, è 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 ruolo del contesto delle risorse.

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

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

Nella tabella seguente sono evidenziati gli scenari in cui il controllo degli accessi in base al contesto delle risorse è più utile. Si notino le differenze tra i requisiti di accesso tra i team SOC e i team non SOC.

Tipo di requisito	Team SOC	Team non SOC
Autorizzazioni	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
Esperienza	Esperienza completa di Microsoft Sentinel, eventualmente 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 contesto delle risorse può essere una soluzione ottimale per l'organizzazione.

Metodi alternativi per l'implementazione del 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 ruolo del contesto delle risorse potrebbe non fornire una soluzione completa.

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 completa di Microsoft Sentinel.	In questo caso, usare un'architettura multi-area di lavoro per separare le autorizzazioni dei 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 su 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 dashboard e report di Power BI.

Configurare in modo esplicito il controllo degli accessi in base al ruolo del contesto delle risorse

Usare la procedura seguente se si vuole configurare il controllo degli accessi in base al ruolo del contesto delle risorse, ma i dati non sono una risorsa di Azure.

Ad esempio, i dati nell'area di lavoro di Microsoft Sentinel che non sono risorse di Azure includono dati Syslog, CEF o AAD o dati raccolti da un agente di raccolta personalizzata.

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

1. Assicurarsi di aver abilitato il controllo degli accessi in base al ruolo del contesto delle risorse in Monitoraggio di Azure.

2. Creare un gruppo di risorse per ogni team di utenti che devono accedere alle risorse senza l'intero ambiente di Microsoft Sentinel.

   Assegnare le autorizzazioni di lettura del log per ognuno dei membri del team.

3. Assegnare risorse ai gruppi del team di risorse creati e contrassegnare gli eventi con gli ID risorsa pertinenti.

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

   Suggerimento

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

   Se non è possibile, assicurarsi che il team disponga delle autorizzazioni di lettura log direttamente alle risorse a cui si vuole accedere.

   Per altre informazioni sugli ID risorsa, vedere:

   • ID risorsa con inoltro log
   • ID risorsa con l'insieme Logstash
   • ID risorsa con la raccolta API Log Analytics

ID risorsa con inoltro 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 ascolta le origini che inviano eventi Syslog e li inoltra a Microsoft Sentinel, l'ID risorsa della macchina virtuale di inoltro del log viene assegnato a tutti gli eventi inoltrati.

Se sono presenti più team, assicurarsi di disporre di vm di inoltro dei 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 di raccolta A.

Suggerimento

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

ID risorsa con l'insieme Logstash

Se si raccolgono i dati usando il plug-in di output logtash di Microsoft Sentinel, 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 delle risorse e si desidera 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 Logtash 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

Suggerimento

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

ID risorsa con la raccolta API Log Analytics

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

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

Passaggi successivi

Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.