Gestire l'accesso ai dati di Microsoft Sentinel in base alle risorse

In genere, gli utenti che hanno accesso a un'area di lavoro Log Analytics abilitata per Microsoft Sentinel hanno accesso anche a tutti i dati dell'area di lavoro, inclusi i contenuti 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 del team.

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

In questi casi, è consigliabile configurare il controllo degli accessi in base al ruolo (RBAC) 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 ruolo del contesto delle risorse.

Quando gli utenti hanno accesso ai dati di Microsoft Sentinel tramite le risorse a cui possono accedere anziché l'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 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 per creare query che includano più risorse e/o gruppi di risorse. Quando si passa ai registri e alle cartelle di lavoro in Monitoraggio di Azure, definire l'ambito per uno o più gruppi di risorse o risorse specifiche.

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 di log e alle aree di lavoro in Monitoraggio di Azure.

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

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

Se il team ha requisiti di accesso simili a quelli del team non SOC descritto nella tabella precedente, il controllo degli accessi in base al ruolo nel contesto delle risorse può 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 delle risorse 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 che i team delle applicazioni usano per ospitare i carichi di lavoro.
• Ai team di applicazioni viene concesso l'accesso ai rispettivi gruppi di risorse, in cui possono gestire le loro risorse.

Questo controllo degli accessi in base al ruolo nel contesto delle risorse e con sottoscrizioni separate consente a questi team di visualizzare i log generati da tutte le risorse a cui hanno accesso, anche se i log sono archiviati in un'area di lavoro a cui non hanno accesso diretto. I team di applicazioni possono accedere ai log tramite l'area Log del portale di Azure, per visualizzare i log per una risorsa specifica, oppure tramite Monitoraggio di 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 di Azure

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

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

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 dei log per ognuno dei membri del team.

3. Assegnare le 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 a 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 log direttamente alle risorse a cui si vuole che accedano.

   Per altre informazioni sugli ID risorsa, vedere:

   • ID risorsa con inoltro dei log
   • ID risorsa con raccolta Logstash
   • ID risorsa con la raccolta di API di Log Analytics

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 del log viene assegnato a tutti gli eventi inoltrati.

Se si dispone di più team, assicurarsi di avere macchine virtuali di inoltro dei log separate che elaborino gli eventi per ogni team separato.

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

ID risorsa con raccolta Logstash

Se si raccolgono i dati usando il plug-in di output Logstash 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 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/wvvu95a2-99u4-uanb-hlbg-2vatvgqtyk7b/resourceGroups/contosotest" # <your resource ID>   
     }
 }

ID risorsa con la raccolta di API di Log Analytics

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

Se si usa il controllo degli accessi in base al ruolo del contesto delle risorse 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.

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

A seconda delle autorizzazioni necessarie per l'organizzazione, l'uso del controllo degli accessi in base al ruolo del contesto delle risorse potrebbe non fornire una soluzione completa. Ad esempio, si consideri che l'organizzazione la cui architettura è descritta nella sezione precedente deve anche concedere l'accesso ai log di Office 365 a un team di audit interno. In questo caso, si potrebbe 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 al meglio i requisiti:

Passaggi successivi

Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.