Usare i ruoli per controllare l'accesso alle risorse
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.
Apri il portale di Azure.
Nella home page di Azure selezionare Gruppi di risorse nel menu a sinistra.
Selezionare un gruppo di risorse. Verrà visualizzato il riquadro Gruppo di risorse.
Nel riquadro dei menu a sinistra selezionare Controllo di accesso (IAM). Verrà visualizzato il riquadro Controllo di accesso (IAM) per il gruppo di risorse.
Nella barra dei menu interna selezionare la scheda Ruoli come indicato di seguito per visualizzare l'elenco dei ruoli disponibili.
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.