Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questo articolo descrive alcune procedure consigliate per l'uso del controllo degli accessi in base al ruolo di Azure. Le procedure consigliate si basano sull'esperienza di tecnici e clienti con il controllo degli accessi in base al ruolo di Azure.
Concedere solo agli utenti l'accesso necessario
Usando il controllo degli accessi in base al ruolo di Azure, è possibile separare i compiti all'interno del team e concedere solo la quantità di accesso agli utenti necessari per svolgere il proprio lavoro. Anziché concedere a tutti le autorizzazioni senza restrizioni nella sottoscrizione o nelle risorse di Azure, è possibile consentire solo determinate azioni in un determinato ambito.
Quando si pianifica la strategia di controllo di accesso, è consigliabile concedere agli utenti il privilegio minimo per svolgere il proprio lavoro. Evitare di assegnare ruoli più ampi a ambiti più ampi anche se inizialmente sembra più conveniente farlo. Quando si creano ruoli personalizzati, includere solo le autorizzazioni necessarie agli utenti. Limitando ruoli e ambiti, si limitano anche le risorse a rischio in caso di compromissione dell’entità di sicurezza.
Il diagramma seguente illustra un modello suggerito per l'uso di Azure RBAC.
Diagramma del modello suggerito per l'uso di Azure RBAC e privilegio minimo.
Per informazioni su come assegnare ruoli, vedere Assegnare ruoli di Azure usando il portale di Azure.
Limitare il numero di proprietari di sottoscrizioni
È necessario disporre di un massimo di 3 proprietari di sottoscrizioni per ridurre il rischio di violazione da parte di un proprietario compromesso. Questa raccomandazione può essere monitorata in Microsoft Defender for Cloud. Per altre raccomandazioni su identità e accesso in Defender for Cloud, vedere Raccomandazioni sulla sicurezza - guida di riferimento.
Limitare le assegnazioni di ruolo di amministratore con privilegi
Alcuni ruoli vengono identificati come ruoli di amministratore con privilegi. Prendere in considerazione le azioni seguenti per migliorare il comportamento di sicurezza:
- Rimuovere le assegnazioni di ruolo con privilegi non necessarie.
- Evitare di assegnare un ruolo di amministratore con privilegi quando si può utilizzare un ruolo di funzione lavorativa invece.
- Se è necessario assegnare un ruolo di amministratore con privilegi, usare un ambito ristretto, ad esempio un gruppo di risorse o una risorsa, anziché un ambito più ampio, ad esempio un gruppo di gestione o una sottoscrizione.
- Se si assegna un ruolo con l'autorizzazione per creare assegnazioni di ruolo, è consigliabile aggiungere una condizione per vincolare l'assegnazione di ruolo. Per altre informazioni, vedere Delegare la gestione delle assegnazioni di ruolo di Azure ad altri utenti con condizioni.
Per altre informazioni, vedere Elencare o gestire le assegnazioni di ruolo di amministratore con privilegi.
Usare Microsoft Entra Privileged Identity Management
Per proteggere gli account con privilegi da attacchi informatici dannosi, è possibile usare Microsoft Entra Privileged Identity Management (PIM) per ridurre il tempo di esposizione dei privilegi e aumentare la visibilità sull'uso tramite report e avvisi. PIM consente di proteggere gli account con privilegi fornendo l'accesso just-in-time alle risorse di Microsoft Entra ID e Azure. L'accesso può essere associato al tempo dopo il quale i privilegi vengono revocati automaticamente.
Per altre informazioni, vedere Che cos'è Microsoft Entra Privileged Identity Management?.
Assegnare ruoli ai gruppi, non agli utenti
Per rendere più gestibili le assegnazioni di ruolo, evitare di assegnare ruoli direttamente agli utenti. Assegnare invece ruoli ai gruppi. L'assegnazione di ruoli ai gruppi anziché agli utenti consente anche di ridurre al minimo il numero di assegnazioni di ruolo, con un limite di assegnazioni di ruolo per ogni sottoscrizione.
Assegnare ruoli usando l'ID ruolo univoco anziché il nome del ruolo
Esistono un paio di volte in cui un nome di ruolo può cambiare, ad esempio:
- Stai usando il tuo ruolo personalizzato e decidi di modificare il nome.
- Si usa un ruolo di anteprima con (anteprima) nel nome. Quando il ruolo viene rilasciato, viene rinominato.
Anche se un ruolo viene rinominato, l'ID ruolo non cambia. Se si usano script o automazione per creare le assegnazioni di ruolo, è consigliabile usare l'ID ruolo univoco anziché il nome del ruolo. Pertanto, se un ruolo viene rinominato, è più probabile che gli script funzionino.
Per altre informazioni, vedere Assegnare un ruolo usando l'ID ruolo univoco e Azure PowerShell e Assegnare un ruolo usando l'ID ruolo univoco e l'interfaccia della riga di comando di Azure.
Evitare di usare un carattere jolly durante la creazione di ruoli personalizzati
Quando si creano ruoli personalizzati, è possibile usare il carattere jolly (*) per definire le autorizzazioni. È consigliabile specificare Actions e DataActions in modo esplicito anziché usare il carattere jolly (*). L'accesso aggiuntivo e le autorizzazioni concesse tramite future Actions o DataActions potrebbero essere comportamenti indesiderati usando il carattere jolly. Per ulteriori informazioni, consultare Ruoli personalizzati in Azure.