Gestire l'accesso ai dati Microsoft Sentinel per risorsa

L'accesso a un'area di lavoro viene gestito tramite Azure RBAC. 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 impostazione di RBAC basato sul 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.

• Via Monitoraggio di Azure. Usare questo metodo quando si desidera creare query che si estendono su più risorse e/o gruppi di risorse. Quando si accede ai log 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 (RBAC) del contesto della risorsa 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 (RBAC) nel contesto delle risorse

La tabella seguente mostra gli scenari in cui l'RBAC nel contesto delle risorse risulta più utile. Si noti le differenze nei requisiti di accesso tra i team SOC e i team non SOC.

Se il tuo team ha requisiti di accesso simili a quelli del team non SOC descritto nella tabella sopra, il modello RBAC con contesto delle risorse potrebbe essere una buona soluzione per la tua organizzazione.

Ad esempio, l'immagine seguente mostra una versione semplificata dell'architettura di un'area di lavoro in cui i team di sicurezza e operativi devono accedere a diversi insiemi di dati, e viene usato l'RBAC basato sul contesto della risorsa 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 esplicitamente l'RBAC nel contesto delle risorse per le risorse non-Azure

Le risorse di Azure includono il supporto integrato per l'RBAC con ambito risorsa, ma potrebbero richiedere ulteriori regolazioni quando si lavora con risorse esterne ad 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 desidera configurare l'RBAC nel contesto delle risorse, ma i dati non sono una risorsa di Azure, seguire questa procedura.

Per configurare esplicitamente l'RBAC del contesto della risorsa:

1. Assicurarsi di aver abilitato il RBAC 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 Microsoft Sentinel.

   Assegnare autorizzazioni di lettura log per ogni membro del team.

3. 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.

   Se non è possibile, assicurarsi che il team disponga direttamente delle autorizzazioni di lettura dei log per le risorse a cui deve accedere.

   Per altre informazioni sugli ID risorsa, vedere:

   • ID delle risorse con inoltro dei log
   • ID risorsa con raccolta tramite Logstash
   • ID delle risorse 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 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.

ID risorsa con raccolta tramite 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 utilizza l'RBAC basato sul contesto della risorsa e si desidera che gli eventi raccolti dall'API siano disponibili per utenti specifici, utilizzare l'ID della risorsa del gruppo di risorse creato per i propri 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>   
     }
 }

Gli ID risorsa nella raccolta di API di Log Analytics

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

Se si utilizza l'RBAC basato sul contesto della risorsa e si desidera che gli eventi raccolti tramite l'API siano disponibili per utenti specifici, utilizzare l'ID della risorsa del gruppo di risorse creato per i propri utenti.

Alternative all'RBAC basato sul 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, potrebbero usare il RBAC a livello di tabella per concedere al team di audit l'accesso all'intera tabella OfficeActivity, senza concedere autorizzazioni su altre tabelle.

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

Contenuto correlato

Per altre informazioni, vedere:

• Autorizzazioni in Microsoft Sentinel
• Gestire l'accesso alle aree di lavoro di Log Analytics
• Che cos'è il controllo degli accessi in base al ruolo di Azure (Azure RBAC)?