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.

Per gli utenti che hanno bisogno di accedere solo a dati specifici nello spazio di lavoro, consigliamo di configurare il controllo di accesso basato sui ruoli (RBAC) in base alle risorse consentite a quegli utenti, invece di fornire loro l'accesso allo spazio 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.
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 accede a registri e a cartelle di lavoro in Monitoraggio di Azure, impostare l'ambito per uno o più gruppi di risorse o risorse specifiche.

Abilitare il controllo degli accessi in base al ruolo nel 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, sarà necessario configurare manualmente l'ID risorsa usato per identificare i dati e abilitare l'accesso. Per altre informazioni, vedere Configurare esplicitamente RBAC basato sul contesto della risorsa per le risorse non di Azure.

Inoltre, le funzioni e le ricerche salvate non sono supportate nei contesti incentrati sulle risorse. Pertanto, funzionalità di Microsoft Sentinel come il parsing e la normalizzazione non sono supportate per il controllo degli accessi in base al ruolo con ambito risorsa in Microsoft Sentinel.

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.

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
Esperienza	L'esperienza di Microsoft Sentinel completa, possibilmente limitata dalle autorizzazioni funzionali assegnate all'utente	Solo query di log e cartelle di lavoro

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.

Nel diagramma architetturale RBAC di esempio risorsa-contesto:

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.

Posizionare lo spazio di lavoro in un abbonamento separato e utilizzare RBAC nel contesto delle risorse permette ai team applicativi di visualizzare i log generati da qualsiasi risorsa a cui hanno accesso, anche quando i log sono memorizzati in uno spazio di lavoro dove 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 nel tuo workspace Log Analytics abilitato per Microsoft Sentinel che non sono risorse Azure includono dati Syslog, CEF o Microsoft Entra ID, oppure dati raccolti da un collezionista personalizzato.

Per configurare l'RBAC nel contesto delle risorse per dati non Azure, si completa la procedura seguente.

Per configurare esplicitamente l'RBAC del contesto della risorsa:

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

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 risorse 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 è 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 VM locale o un'altra VM nel cloud, ad esempio AWS, come server di inoltro dei log, assicurarsi che disponga di un ID risorsa implementando Azure Arc.
Per scalare l'ambiente VM per l'inoltro dei log, prendi in considerazione la creazione di un set di scalabilità VM per raccogliere i log CEF e Syslog.

ID risorse 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 stai usando RBAC nel contesto delle risorse e vuoi che gli eventi raccolti dall'API siano disponibili per utenti specifici, usa l'ID della risorsa del gruppo di risorse che hai configurato in Configura esplicitamente RBAC nel contesto delle risorse non Azure.

Ad esempio, il seguente file di configurazione Logstash mostra come ingerire eventi tramite input Beats e inviarli a uno spazio di lavoro Log Analytics usando il plugin di output Microsoft Sentinel, con il azure_resource_id campo impostato per etichettare gli eventi con un gruppo di risorse specifico per il contesto risorsa RBAC:

 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 delle risorse con la 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.

Alternative all'RBAC basato sul contesto delle risorse

A seconda dei permessi richiesti nella tua organizzazione, l'uso di RBAC nel contesto delle risorse potrebbe non soddisfare completamente tutti i requisiti di accesso ai dati della tua organizzazione. Ad esempio, consideriamo se un'organizzazione che utilizza l'architettura di spazio di lavoro a abbonamento separato descritta in Scenari per RBAC nel contesto delle risorse deve anche concedere l'accesso ai log di Office 365 a un team di audit 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:

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 più aree di lavoro e tenant > Lavora con gli incidenti 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 Sicurezza di Windows in tutti i sistemi. In questi casi, utilizzare RBAC 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-08-14