Usare i ruoli per controllare l'accesso alle risorse

Completato

Ruoli predefiniti per le risorse di Azure (con PowerShell)

Azure offre diversi ruoli predefiniti per soddisfare la maggior parte degli scenari di sicurezza più comuni. Per comprendere il funzionamento dei ruoli, di seguito verranno illustrati i tre ruoli applicabili a tutti i tipi di risorse:

  • Proprietario: ha accesso completo a tutte le risorse, oltre al diritto di delegare l'accesso ad altri utenti.
  • Collaboratore: può creare e gestire tutti i tipi di risorse di Azure, ma non può concedere l'accesso ad altri.
  • Lettore: può visualizzare le risorse di Azure esistenti.

Definizioni dei ruoli

Ogni ruolo è un set di proprietà definite in un file JSON (JavaScript Object Notation). Questa definizione di ruolo include Name, ID e Description. Sono inclusi anche le autorizzazioni consentite (Actions), le autorizzazioni negate (NotActions) e l'ambito (ad esempio, l'accesso in lettura) per il ruolo.

Per il ruolo Proprietario, questo significa tutte le azioni, indicate da un asterisco (*); nessuna azione negata e tutti gli ambiti, indicati da una barra (/).

È possibile ottenere queste informazioni tramite il cmdlet di PowerShell Get-AzRoleDefinition Owner.

Get-AzRoleDefinition Owner

Questo codice deve produrre l'output seguente:

Name             : Owner
Id               : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom         : False
Description      : Lets you manage everything, including access to resources.
Actions          : {*}
NotActions       : {}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}

Per visualizzare le azioni consentite e negate, provare a eseguire la stessa operazione per i ruoli Collaboratore e Lettore.

Esaminare i ruoli predefiniti

Si vedranno ora alcuni degli altri ruoli predefiniti.

  1. Apri il portale di Azure.

  2. Nella home page di Azure selezionare Gruppi di risorse nel menu a sinistra.

  3. Selezionare un gruppo di risorse. Verrà visualizzato il riquadro Gruppo di risorse.

  4. Nel riquadro dei menu a sinistra selezionare Controllo di accesso (IAM). Verrà visualizzato il riquadro Controllo di accesso (IAM) per il gruppo di risorse.

  5. Nella barra dei menu interna selezionare la scheda Ruoli come indicato di seguito per visualizzare l'elenco dei ruoli disponibili.

    Screenshot showing the roles in the Azure portal.

Che cos'è una definizione di ruolo?

Una definizione di ruolo è una raccolta di autorizzazioni, Una definizione di ruolo elenca le operazioni che il ruolo può eseguire, ad esempio lettura, scrittura ed eliminazione. È anche possibile elencare le operazioni che non possono essere eseguite o le operazioni correlate ai dati sottostanti.

Come descritto in precedenza, una definizione di ruolo ha la struttura seguente:

Name Descrizione
Id Identificatore univoco per il ruolo, assegnato da Azure
IsCustom True se è un ruolo personalizzato, False se è un ruolo predefinito
Description Descrizione leggibile del ruolo
Actions [] Autorizzazioni consentite, * indica tutte
NotActions [] Autorizzazioni negate
DataActions [] Autorizzazioni consentite specifiche applicate ai dati, ad esempio Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
NotDataActions [] Autorizzazioni specifiche negate applicate ai dati.
AssignableScopes [] Ambiti a cui si applica questo ruolo; / indica globale, ma può essere esteso a un albero gerarchico

Questa struttura è rappresentata come JSON quando viene usata nel controllo degli accessi in base al ruolo (RBAC) o dall'API sottostante. Ad esempio, di seguito è riportata la definizione del ruolo Collaboratore in formato JSON.

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Lets you manage everything except access to resources.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ]
}

Actions e NotActions

È possibile personalizzare le proprietà Actions e NotActions per concedere e negare le autorizzazioni esatte necessarie. Queste proprietà sono sempre nel formato: {Company}.{ProviderName}/{resourceType}/{action}.

Di seguito sono riportate le azioni per i tre ruoli esaminati in precedenza:

Ruolo predefinito Azioni NotActions
Proprietario (tutte le azioni consentite) * -
Collaboratore (tutte le azioni consentite eccetto la scrittura o l'eliminazione di assegnazioni di ruolo) * Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action
Lettore (tutte le azioni di lettura consentite) */read -

L'operazione con caratteri jolly (*) in Actions indica che l'entità di sicurezza assegnata a questo ruolo può eseguire tutte le azioni. In altre parole, questo ruolo può gestire tutti gli elementi, incluse le azioni definite in futuro, poiché Azure aggiunge nuovi tipi di risorse. Con il ruolo Lettore è consentita solo l'azione read.

Le operazioni in NotActions vengono sottratte da Actions. Con il ruolo Collaboratore, NotActions rimuove la capacità del ruolo di gestire e assegnare l'accesso alle risorse.

DataActions e NotDataActions

Le operazioni sui dati vengono specificate nelle proprietà DataActions e NotDataActions. È possibile specificare operazioni sui dati separatamente dalle operazioni di gestione. In tal modo, si impedisce alle assegnazioni di ruolo correnti con caratteri jolly (*) di accedere immediatamente ai dati. Ecco alcune operazioni sui dati che è possibile specificare in DataActions e NotDataActions:

  • Leggere un elenco dei BLOB in un contenitore
  • Scrivere un BLOB di archiviazione in un contenitore
  • Eliminare un messaggio in una coda

È possibile aggiungere operazioni sui dati solo alle DataActions proprietà e NotDataActions . I provider di risorse identificano le operazioni sui dati impostando la proprietà isDataAction su true. I ruoli che non dispongono di operazioni sui dati possono omettere queste proprietà dalla definizione del ruolo.

Queste azioni funzionano esattamente come le controparti per la gestione. È possibile specificare le azioni che si vogliono consentire (o * per tutte) e quindi fornire un elenco di azioni specifiche da rimuovere nella raccolta NotDataActions. Di seguito sono riportati alcuni esempi. È possibile trovare l'elenco completo di azioni e azioni sui dati nella documentazione relativa al provider di risorse:

Operazione sui dati Descrizione
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete Eliminazione di dati BLOB
Microsoft.Compute/virtualMachines/login/action Accesso a una macchina virtuale come utente normale
Microsoft.EventHub/namespaces/messages/send/action Invio di messaggi su un hub eventi
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read Restituzione di un file/una cartella o di un elenco di file/cartelle
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read Lettura di un messaggio da una coda

Ambiti assegnabili

La definizione delle proprietà Actions e NotActions non è sufficiente per implementare in modo completo un ruolo. È anche necessario definire correttamente l'ambito del ruolo.

La proprietà AssignableScopes del ruolo specifica gli ambiti, ovvero sottoscrizioni, gruppi di risorse o risorse, entro i quali il ruolo è disponibile per l'assegnazione. È possibile rendere disponibile il ruolo personalizzato per l'assegnazione solo nelle sottoscrizioni o nei gruppi di risorse che lo richiedono, evitando così di complicare l'esperienza utente per le altre sottoscrizioni o gli altri gruppi di risorse.

Di seguito sono riportati alcuni esempi:

Al Usare l'ambito
Limitare a una sottoscrizione "/subscriptions/{sub-id}"
Limitare a un gruppo di risorse specifico in una sottoscrizione specifica "/subscriptions/{sub-id}/resourceGroups/{rg-name}"
Limitare a una risorsa specifica "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}"
Rendere un ruolo disponibile per l'assegnazione in due sottoscrizioni "/subscriptions/{sub-id}", "/subscriptions/{sub-id}"

Creazione di ruoli

L’ID Microsoft Entra include ruoli predefiniti che probabilmente coprono il 99% delle esigenze. Se possibile, è preferibile usare un ruolo predefinito. Tuttavia, se necessario, è possibile creare ruoli personalizzati.

Nota

La creazione di ruoli personalizzati richiede Microsoft Entra ID P1 o P2; non è possibile creare ruoli personalizzati nel livello gratuito.

Si può creare un nuovo ruolo tramite diversi meccanismi:

  • Portale di Azure: Puoi usare il portale di Azure per creare un ruolo personalizzato selezionando l’l’ID Microsoft Entra>Ruoli e amministratori>Nuovo ruolo personalizzato.

  • Azure PowerShell: si può possibile usare il cmdlet New-AzRoleDefinition per definire un nuovo ruolo.

  • API Graph di Azure: si può usare una chiamata REST all'API Graph per creare un nuovo ruolo a livello di codice.

La sezione Riepilogo del modulo include un collegamento alla documentazione per tutti e tre gli approcci.

Verificare le conoscenze

1.

Quali informazioni rappresenta Action in una definizione di ruolo?

2.

Quale delle istruzioni seguenti imposta il gruppo di risorse myResourceGroup come ambito di un ruolo?

3.

In che modo si usa NotActions in una definizione di ruolo?