Progettazione di identità e accessi aziendali

Negli ambienti Azure aziendali, la gestione delle identità e degli accessi deve scalare per supportare centinaia di sottoscrizioni, migliaia di utenti e decine di team, ciascuno con esigenze diverse di accesso alle risorse. Un modello di identità ben progettato previene sia l'assegnazione di autorizzazioni eccessive (utenti con più accessi del necessario) sia quella di autorizzazioni insufficienti (utenti impossibilitati a svolgere il proprio lavoro). La base è costituita da Microsoft Entra ID, insieme ad Azure RBAC e a strumenti di governance come Privileged Identity Management (PIM).

Azure Role-Based Access Control (RBAC) concede l'accesso tramite tre componenti:

• Entità di sicurezza — chi (utente, gruppo, entità servizio o identità gestita)
• Definizione del ruolo — che cosa (un insieme di azioni consentite, ad esempio 'Contributor')
• Ambito — dove (gruppo di gestione, sottoscrizione, gruppo di risorse o singola risorsa)

La combinazione di questi tre elementi crea un'assegnazione di ruolo. I ruoli vengono ereditati lungo la gerarchia: un ruolo assegnato a un gruppo di gestione si applica a tutte le sottoscrizioni sottostanti.

Azure fornisce oltre 100 ruoli predefiniti per gli scenari comuni (Owner, Contributor, Reader e ruoli specifici dei servizi). Per la maggior parte dei casi d'uso aziendali, i ruoli predefiniti sono sufficienti. Tuttavia, quando sono necessarie autorizzazioni che non corrispondono ad alcun ruolo predefinito — ad esempio un ruolo che consenta di leggere le VM ma non di eliminarle — è possibile creare un ruolo personalizzato con le autorizzazioni esatte necessarie, seguendo il principio del privilegio minimo.

Ove possibile, assegni i ruoli ai gruppi Entra ID anziché ai singoli utenti. Quando assegna un ruolo a un gruppo, tutti i membri ereditano il ruolo. Concedere o revocare l'accesso consiste quindi nell'aggiungere o rimuovere un utente dal gruppo, senza modificare le assegnazioni dei ruoli in più ambiti. Questo riduce notevolmente il carico amministrativo e garantisce un accesso coerente tra i membri del team che svolgono la stessa funzione.

Privileged Identity Management (PIM) è un servizio di Entra ID che fornisce accesso con privilegi just-in-time (JIT) alle risorse Azure e ai ruoli di Entra ID. Anziché disporre permanentemente dell'accesso Owner o Global Administrator, gli utenti sono idonei per i ruoli con privilegi e devono richiederne l'attivazione quando necessitano di un accesso elevato. L'attivazione può richiedere l'MFA, una motivazione e l'approvazione da parte di un approvatore designato.

PIM offre diversi vantaggi in termini di sicurezza negli ambienti aziendali:

• Superficie di attacco ridotta — non sono presenti account amministratore permanenti che potrebbero essere compromessi
• Traccia di controllo — ogni attivazione viene registrata con data e ora, motivazione e approvatore
• Revisioni degli accessi — PIM supporta revisioni periodiche durante le quali i responsabili confermano quali utenti debbano rimanere idonei
• Accesso a tempo limitato — anche l'accesso approvato scade automaticamente, impedendo che vengano dimenticate autorizzazioni elevate

Un modello RBAC aziendale ben progettato presenta in genere questi livelli:

• Livello del gruppo di gestione — ampio accesso di visualizzazione per i team di governance; assegnazioni dei criteri
• Livello della sottoscrizione — accesso Contributor a livello di team per i team delle applicazioni che gestiscono una sottoscrizione
• Livello del gruppo di risorse — ruoli specifici del servizio (ad esempio Storage Blob Contributor per un'applicazione che necessita solo dell'accesso ai blob)
• Livello della risorsa — solo per casi eccezionali in cui è necessario un controllo granulare

Le applicazioni e i processi automatizzati non devono usare account utente per autenticarsi ad Azure. È invece opportuno usare:

• Entità servizio — registrazioni di applicazioni in Entra ID con un ID client e un segreto o un certificato; usate dalle pipeline CI/CD e dall'automazione locale
• Identità gestite — credenziali gestite automaticamente per le risorse ospitate in Azure (VM, App Service, AKS); non è necessario gestire o ruotare segreti

Assegnate i ruoli RBAC minimi necessari alle entità servizio e alle identità gestite.

Le criteri di accesso condizionale in Entra ID aggiungono informazioni contestuali alle decisioni di autenticazione. Per la gestione delle risorse Azure, è possibile richiedere che l'accesso amministrativo (portale Azure, CLI) sia consentito solo:

• da dispositivi conformi (gestiti da Intune)
• da posizioni denominate (rete aziendale o VPN)
• dopo l'autenticazione MFA (sempre applicata per le azioni con privilegi)

La combinazione di Accesso condizionale e PIM crea un livello di sicurezza molto elevato per l'accesso amministrativo ad Azure.

Le revisioni degli accessi di Entra ID consentono agli amministratori di verificare periodicamente che gli utenti abbiano ancora bisogno dell'accesso loro concesso. Le revisioni possono essere delegate ai proprietari delle risorse o ai responsabili, che per ogni utente indicano «Sì, questa persona ha ancora bisogno dell'accesso» oppure «No, rimuovi questo accesso». Le revisioni degli accessi possono essere pianificate con cadenza trimestrale e automatizzare la rimozione degli accessi non più approvati, impedendo l'accumulo dei privilegi nel tempo.

Ogni azienda dovrebbe mantenere almeno due account di accesso di emergenza (break-glass) — account con il ruolo di Amministratore globale non protetti dall'Accesso condizionale o dai requisiti MFA (usano invece chiavi hardware FIDO2). Questi account vengono usati solo quando i sistemi Entra ID o MFA non sono disponibili e non è possibile accedere ai normali account amministrativi. L'uso di un account di accesso di emergenza dovrebbe attivare immediatamente gli avvisi di sicurezza ed essere sottoposto a un audit rigoroso.

In questa lezione avete appreso che l'RBAC aziendale usa assegnazioni basate sui gruppi con ambito a livello di gruppo di gestione, sottoscrizione e gruppo di risorse; Privileged Identity Management fornisce accesso just-in-time per eliminare i ruoli amministrativi permanenti; e che per l'autenticazione delle applicazioni è opportuno usare identità gestite ed entità servizio invece degli account utente. Congratulazioni: avete completato la sezione sull'architettura aziendale e la governance del percorso AZ-900!