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

Articolo
10/17/2024

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.

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, è 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 per risorse non Azure.

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

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.

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 relativi alle risorse a cui il team è autorizzato ad accedere
Esperienza	L'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 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:

Assicurarsi di aver abilitato il controllo degli accessi in base al ruolo del contesto delle risorse in Monitoraggio di Azure.
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.
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

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.

Suggerimento

Quando si usa una macchina virtuale locale o un'altra macchina virtuale cloud, ad esempio AWS, come server d'inoltro dei log, assicurarsi di avere un ID risorsa implementando Azure Arc.
Per ridimensionare l'ambiente di macchine virtuali per l'inoltro dei log, prendere in considerazione la possibilità di creare un set di scalabilità di macchine virtuali per raccogliere i log CEF e Sylog.

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>   
     }
 }

Suggerimento

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

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.

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:

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 più aree di lavoro e tenant >Usare eventi imprevisti in più 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 di 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, si potrebbe voler limitare l'accesso ai log di 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 in base al gruppo di gestione	Posizionare Microsoft Sentinel in un gruppo di gestione separato dedicato alla sicurezza, assicurando che solo le autorizzazioni minime vengano ereditate dai membri del gruppo. All'interno del team di sicurezza assegnare le autorizzazioni a gruppi diversi in base alle funzioni di ogni gruppo. Poiché tutti i team hanno accesso all'intera area di lavoro, avranno accesso all'esperienza completa di Microsoft Sentinel, limitata solo dai ruoli di Microsoft Sentinel assegnati. Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.

Passaggi successivi

Per altre informazioni, vedere Autorizzazioni in Microsoft Sentinel.

Condividi tramite