Perché il least privilege in Sentinel è una domanda d’esame

Microsoft Sentinel vive su Azure, quindi il suo modello di autorizzazione è Azure RBAC applicato a uno scope: la subscription, il resource group o il singolo workspace di Log Analytics. Non esiste un “ruolo SOC” generico: esistono ruoli built-in specifici di Sentinel, e la domanda d’esame è quasi sempre la stessa nella sostanza — dato questo compito, qual è il ruolo con i permessi minimi? Rispondere bene richiede due cose: sapere cosa aggiunge ciascun livello rispetto al precedente, e sapere dove quella scala si interrompe.

La scala built-in è cumulativa. Ogni ruolo contiene tutto ciò che fa il precedente e ci aggiunge qualcosa. Questo significa che la risposta corretta a “permessi minimi” è sempre il gradino più basso che copre l’azione richiesta, mai un gradino sopra “per sicurezza”. Se uno scenario chiede solo di leggere, la risposta non è Contributor.

Reader, Responder, Contributor

Microsoft Sentinel Reader è il livello di sola lettura: vede i dati nel workspace, gli incident, gli alert, i workbook, le hunting query, le analytics rule già configurate. È il ruolo giusto per un auditor, per un manager che guarda le dashboard, per un analista in affiancamento o per chi deve solo consultare un report. Un Reader non può cambiare nulla: non può nemmeno assegnare a sé stesso un incident o scriverci un commento.

Microsoft Sentinel Responder è il ruolo operativo del tier-1. Aggiunge la gestione del ciclo di vita dell’incident: cambiare lo stato (New, Active, Closed) con la relativa classification, assegnare l’owner, aggiungere comment e tag, unire o chiudere incident duplicati. È esattamente il perimetro di chi lavora in coda: tocca gli incident ma non tocca la configurazione. Un Responder non crea né modifica analytics rule, non aggiunge connettori, non cambia i workbook. Nella maggior parte degli scenari d’esame che descrivono “un analista che deve triage e chiudere gli incident”, Responder è la risposta.

Microsoft Sentinel Contributor aggiunge la configurazione: creare e modificare analytics rule (Scheduled, NRT, Microsoft Security, Fusion, Anomaly, Threat Intelligence), creare e modificare workbook, gestire i data connector, creare automation rule. È il ruolo dell’ingegnere di detection, non dell’analista di turno. Assegnarlo a tutto il team è l’anti-pattern classico: dà a chiunque la possibilità di disabilitare una regola di detection.

Sopra questi, per la gestione degli artefatti di automation, esiste Microsoft Sentinel Automation Contributor, usato principalmente dal servizio stesso per permettere alle automation rule di invocare i playbook.

Il gradino che manca: i playbook

Qui sta la trappola più frequente. I playbook di Sentinel sono Logic Apps, e le Logic Apps vivono in un resource group, non dentro il workspace. Nessuno dei ruoli di Sentinel — Reader, Responder, Contributor — include il permesso di eseguire una Logic App. Di conseguenza un Responder che apre un incident e prova a lanciare manualmente un playbook di containment riceve un errore di autorizzazione, anche se l’incident lo gestisce perfettamente.

Il permesso mancante si concede con Microsoft Sentinel Playbook Operator, che dà il diritto di elencare, visualizzare ed eseguire manualmente i playbook, senza dare la possibilità di modificarli. Va assegnato sul resource group che contiene le Logic App, e questo è il secondo punto delicato: l’assegnazione sul workspace non basta, perché lo scope non copre le risorse dove i playbook risiedono realmente. Se il playbook deve poi agire su altre risorse (per esempio isolare una macchina), serve anche che la managed identity della Logic App abbia i permessi sul target — è un’autorizzazione separata da quella dell’analista.

Il pattern di least privilege da ricordare per il tier-1 che deve anche rispondere con automazione è quindi: Responder sul workspace più Playbook Operator sul resource group dei playbook. E se i playbook devono essere modificati, serve Logic App Contributor su quel resource group, non Sentinel Contributor.

Trappole tipiche d’esame

  • L’analista deve chiudere gli incident e assegnarli, niente più → soluzione: Microsoft Sentinel Responder. Reader non permette di scrivere stato, owner, comment o tag; Contributor è oltre il minimo necessario e apre la configurazione delle detection.
  • Il tier-1 deve poter lanciare un playbook a mano da un incident → soluzione: Responder + Microsoft Sentinel Playbook Operator sul resource group dei Logic App. Responder da solo non esegue playbook: è il caso che l’esame usa più spesso per far scegliere erroneamente Contributor.
  • Un auditor deve consultare incident e workbook senza toccare nulla → soluzione: Microsoft Sentinel Reader. Assegnare Responder “così può almeno commentare” viola il least privilege richiesto dalla domanda.
  • Serve creare una nuova analytics rule o aggiungere un data connector → soluzione: Microsoft Sentinel Contributor. Responder non tocca la configurazione, e nessun ruolo sui playbook aiuta qui.
  • Il permesso è stato assegnato sul workspace ma il playbook resta non eseguibile → soluzione: verificare lo scope. Playbook Operator va concesso dove vivono le Logic App; lo scope sbagliato è indistinguibile da un ruolo sbagliato nei sintomi.
  • Il playbook parte ma l’azione sulla risorsa target fallisce → soluzione: permessi della managed identity del Logic App. È un’autorizzazione della risorsa che esegue, non dell’utente che clicca.