Procedure consigliate per il controllo degli accessi in base al ruolo di Azure

Questo articolo descrive alcune procedure consigliate per l'uso del controllo degli accessi in base al ruolo di Azure. Queste procedure consigliate derivano dall'esperienza con il controllo degli accessi in base al ruolo di Azure e dalle esperienze dei clienti come te stesso.

Concedere solo l'accesso necessario per gli utenti

Usando il controllo degli accessi in base al ruolo di Azure, è possibile separare le mansioni all'interno del team e concedere agli utenti solo la quantità di accesso di cui hanno bisogno per svolgere il loro lavoro. Invece di concedere a tutti autorizzazioni senza restrizioni per la sottoscrizione o le risorse di Azure, è possibile consentire solo determinate azioni in un particolare ambito.

Quando si pianifica la strategia di controllo degli accessi, è consigliabile concedere agli utenti almeno il privilegio per completare la propria sessione di lavoro. Evitare di assegnare ruoli più ampi in ambiti più ampi anche se inizialmente sembra più pratico. 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 mostra uno schema consigliato per l'uso del controllo degli accessi in base al ruolo di Azure.

Azure RBAC and least privilege

Per informazioni su come assegnare ruoli, vedere Assegnare ruoli di Azure usando il portale di Azure.

Limitare il numero di proprietari di sottoscrizioni

Designare al massimo 3 proprietari di sottoscrizione in modo da ridurre la probabilità di violazione da parte di un proprietario compromesso. Questa raccomandazione può essere monitorata in Microsoft Defender per il cloud. Per altre raccomandazioni su identità e accesso in Defender per il 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 è possibile usare un ruolo di funzione del processo.
  • 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 le assegnazioni di ruolo più gestibili, 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:

  • Si sta usando il proprio ruolo personalizzato e si decide di modificare il nome.
  • Si usa un ruolo di anteprima con (anteprima) nel nome. Quando il ruolo viene rilasciato, il ruolo 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 un comportamento futuro Actions o DataActions potrebbero essere indesiderate usando il carattere jolly. Per altre informazioni, vedere Ruoli personalizzati in Azure.

Passaggi successivi