Utenti, gruppi e assegnazioni di ruolo

Azure Role-Based Access Control (RBAC) è il sistema di autorizzazione che controlla chi può eseguire quali operazioni sulle risorse Azure. Invece di assegnare direttamente le autorizzazioni ai singoli utenti, si assegnano ruoli ai principal di sicurezza (utenti, gruppi, entità servizio o identità gestite) a uno specifico ambito. Questa separazione mantiene gestibili le autorizzazioni man mano che l'organizzazione cresce.

Ogni assegnazione RBAC comprende tre componenti. Un principal di sicurezza indica chi riceve l'accesso (utente, gruppo o identità gestita). Una definizione del ruolo indica quali azioni sono consentite (ad esempio, leggere le macchine virtuali o scrivere nell'archiviazione). Un ambito indica dove si applica l'accesso, dal più ampio al più ristretto: gruppo di gestione, sottoscrizione, gruppo di risorse o singola risorsa. L'accesso viene ereditato verso il basso nella gerarchia degli ambiti.

Azure offre centinaia di ruoli predefiniti. I quattro più usati, indipendentemente dal tipo di risorsa, sono: Owner: accesso completo, inclusa la possibilità di assegnare ruoli ad altri; Contributor: accesso completo per creare e gestire le risorse, ma senza la possibilità di concedere l'accesso ad altri; Reader: accesso in sola visualizzazione; e User Access Administrator: possibilità di gestire le assegnazioni dei ruoli senza modificare direttamente le risorse.

Un'assegnazione di ruolo concede al principal di sicurezza specificato le autorizzazioni definite nella definizione del ruolo, all'ambito indicato. Le assegnazioni dei ruoli si propagano a tutti gli ambiti figlio: assegnare Contributor a livello di gruppo di risorse concede l'accesso Contributor a ogni risorsa contenuta nel gruppo. L'assegnazione a livello di sottoscrizione concede Contributor in tutti i gruppi di risorse della sottoscrizione.

Il principio del privilegio minimo stabilisce che ogni identità debba disporre solo delle autorizzazioni minime necessarie per svolgere il proprio lavoro. In Azure RBAC questo significa preferire Reader a Contributor quando non è necessaria la scrittura, preferire l'ambito del gruppo di risorse a quello della sottoscrizione e usare, quando possibile, ruoli specifici a livello di risorsa (ad esempio, Storage Blob Data Contributor) invece dell'ampio ruolo Contributor.

Quando nessun ruolo predefinito soddisfa esattamente i requisiti, è possibile creare un ruolo personalizzato. Una definizione di ruolo personalizzato specifica un insieme di Actions (operazioni del piano di controllo consentite), NotActions (escluse dall'insieme consentito), DataActions (operazioni del piano dati sulle risorse, come la lettura del contenuto dei blob) e AssignableScopes (sottoscrizioni o gruppi di gestione in cui il ruolo può essere assegnato).

Assegnare i ruoli ai gruppi anziché ai singoli utenti è una procedura consigliata. Quando un nuovo sviluppatore entra nel DevTeam, lo si aggiunge al gruppo di sicurezza DevTeam in Entra ID: eredita automaticamente tutte le assegnazioni di ruolo del gruppo, senza apportare modifiche ad Azure RBAC. Questo punto di gestione centralizzato evita assegnazioni individuali distribuite, difficili da controllare o revocare quando un utente lascia l'organizzazione.

Un principal di servizio è un'identità usata da applicazioni, script e strumenti di automazione per autenticarsi in Azure e accedere alle risorse. A differenza di un'identità utente, i principal di servizio non possono eseguire l'accesso interattivo. Si creano a partire dalle registrazioni delle app in Entra ID e si assegnano quindi i ruoli RBAC all'ambito appropriato, ad esempio concedendo a una pipeline CI/CD l'accesso Contributor a un singolo gruppo di risorse per distribuire l'infrastruttura.

Le assegnazioni di negazione bloccano azioni specifiche per i principal di sicurezza anche quando un'assegnazione di ruolo le consentirebbe. A differenza delle assegnazioni di ruolo, le assegnazioni di negazione non possono essere create direttamente dagli amministratori: vengono associate da Azure Blueprints o dalle applicazioni gestite per impedire agli utenti di modificare le risorse protette. Un'assegnazione di negazione ha la precedenza su qualsiasi assegnazione di ruolo corrispondente.

Privileged Identity Management (PIM) è una funzionalità di Entra ID P2 che offre accesso con privilegi just-in-time. Invece di assegnare permanentemente il ruolo Owner o Global Administrator, si rendono gli utenti idonei per quel ruolo. Quando ne hanno bisogno, attivano l'assegnazione per un periodo di tempo limitato (ad esempio, 1-8 ore), con la possibilità di richiedere un flusso di approvazione e una motivazione. In questo modo si riduce drasticamente la superficie di attacco permanente dovuta agli account con privilegi eccessivi.

Le revisioni degli accessi (Entra ID P2) sono revisioni periodiche automatizzate che chiedono ai proprietari delle risorse o ai responsabili di confermare se i membri del loro team hanno ancora bisogno delle assegnazioni di ruolo correnti. I revisori approvano o negano la continuazione dell'accesso direttamente dall'interfaccia di revisione. Questo consente di individuare autorizzazioni obsolete dovute a cambiamenti di ruolo, conclusione di progetti o uscita di dipendenti: un requisito fondamentale per i programmi di conformità normativa.

Verifichi la comprensione dei concetti di Microsoft Azure Fundamentals (AZ-900) presentati in questa lezione.

In questa lezione ha appreso che: Azure RBAC assegna ruoli ai principal di sicurezza a uno specifico ambito; il principio del privilegio minimo consiste nel concedere solo le autorizzazioni minime necessarie; e PIM offre l'attivazione just-in-time dei ruoli con privilegi elevati invece dell'assegnazione permanente. Nella prossima lezione parleremo dell'autenticazione a più fattori e dell'accesso condizionale in Entra ID.