Che cos'è il controllo degli accessi in base all'attributo di Azure?

2025-05-20

Il controllo degli accessi in base all'attributo è un sistema di autorizzazione che definisce l'accesso in base agli attributi associati a entità di sicurezza, risorse e ambiente di una richiesta di accesso. Con il controllo accessi basato sugli attributi (ABAC), puoi concedere a un'entità di sicurezza l'accesso a una risorsa in base agli attributi. Azure ABAC si riferisce all'implementazione del controllo degli accessi basato sugli attributi per Azure.

Che cosa sono le condizioni di assegnazione di ruolo?

Il controllo degli accessi in base al ruolo di Azure è un sistema di autorizzazione che consente di gestire chi ha accesso alle risorse di Azure, le operazioni che possono eseguire con tali risorse e le aree a cui hanno accesso. Nella maggior parte dei casi, Azure RBAC fornirà la gestione degli accessi necessaria usando definizioni di ruolo e assegnazioni di ruolo. In alcuni casi, tuttavia, potrebbe essere necessario fornire una gestione degli accessi più granulare o semplificare la gestione di centinaia di assegnazioni di ruolo.

Il controllo degli accessi in base all'attributo di Azure si basa sul controllo degli accessi in base al ruolo di Azure aggiungendo condizioni di assegnazione di ruolo basate su attributi nel contesto di azioni specifiche. Una condizione di assegnazione di ruolo è un controllo aggiuntivo che è possibile aggiungere facoltativamente all'assegnazione di ruolo per fornire un controllo di accesso più granulare. Una condizione filtra le autorizzazioni concesse come parte della definizione del ruolo e dell'assegnazione di ruolo. Ad esempio, è possibile aggiungere una condizione che richiede che un oggetto abbia un tag specifico per leggere l'oggetto. Non è possibile negare esplicitamente l'accesso a risorse specifiche usando condizioni.

L'uso del controllo degli accessi in base al ruolo di Azure (RBAC) e del controllo degli accessi basato su attributi di Azure (ABAC) integra i vantaggi di entrambi i modelli di controllo degli accessi. Il controllo degli accessi in base al ruolo di Azure (RBAC) è più semplice da implementare grazie al suo stretto allineamento con la logica aziendale, mentre il controllo degli accessi basato su attributi di Azure (ABAC) offre maggiore flessibilità in alcuni scenari principali. Combinando questi due metodi, le organizzazioni possono ottenere un livello di autorizzazione più sofisticato.

Perché usare le condizioni?

Esistono tre vantaggi principali per l'uso delle condizioni di assegnazione di ruolo:

Fornire un controllo di accesso più granulare - un'assegnazione di ruolo usa una definizione di ruolo con azioni e azioni sui dati per permettere le autorizzazioni al soggetto di sicurezza. È possibile scrivere condizioni per filtrare tali autorizzazioni per un controllo di accesso più granulare. È anche possibile aggiungere condizioni a azioni specifiche. Ad esempio, è possibile concedere a John l'accesso in lettura ai BLOB nella sottoscrizione solo se i BLOB vengono contrassegnati come Project=Blue.
Ridurre il numero di assegnazioni di ruolo : ogni sottoscrizione di Azure ha attualmente un limite di assegnazione di ruolo. Esistono scenari che richiedono migliaia di assegnazioni di ruolo. Tutte queste assegnazioni di ruolo devono essere gestite. In questi scenari, è possibile aggiungere condizioni per usare un numero significativamente inferiore di assegnazioni di ruolo.
Usare attributi che hanno un significato aziendale specifico : le condizioni consentono di usare attributi che hanno un significato aziendale specifico per l'utente nel controllo di accesso. Alcuni esempi di attributi sono il nome del progetto, la fase di sviluppo software e i livelli di classificazione. I valori di questi attributi di risorsa sono dinamici e cambiano man mano che gli utenti si spostano tra team e progetti.

Scenari di esempio per le condizioni

Esistono diversi scenari in cui è possibile aggiungere una condizione all'assegnazione di ruolo. Ecco alcuni esempi.

Accesso in lettura ai blob con il tag Project=Cascade
I nuovi BLOB devono includere il tag Project=Cascade
I BLOB esistenti devono essere contrassegnati con almeno una chiave project o una chiave program
I BLOB esistenti devono essere contrassegnati con una chiave Progetto e i valori Cascade, Baker o Skagit.
Leggere, scrivere o eliminare BLOB nei contenitori chiamati blob-example-container
Accesso in lettura ai BLOB nei contenitori denominati blobs-example-container con un percorso di sola lettura
Accesso in scrittura ai BLOB nei contenitori denominati Contosocorp con un percorso di caricamento/contoso
Accesso in lettura ai blob con il tag Program=Alpine e un percorso di log
Accesso in lettura ai BLOB con il tag Project=Baker e l'utente ha un attributo corrispondente Project=Baker
Accesso in lettura ai BLOB durante un intervallo di data/ora specifico.
Accesso in scrittura ai blob solo tramite un collegamento privato o da una subnet specifica.

Per altre informazioni su come creare questi esempi, vedere Condizioni di assegnazione di ruolo di Azure di esempio per l'archiviazione BLOB.

Dove è possibile aggiungere condizioni?

Attualmente, le condizioni possono essere aggiunte alle assegnazioni di ruolo predefinite o personalizzate con azioni sui dati di archiviazione BLOB o di archiviazione in coda. Le condizioni vengono aggiunte allo stesso ambito dell'assegnazione di ruolo. Analogamente alle assegnazioni di ruolo, è necessario disporre Microsoft.Authorization/roleAssignments/write delle autorizzazioni per aggiungere una condizione.

Ecco alcuni attributi di Blob storage che puoi usare nelle tue condizioni.

Nome dell'account
Tag indice BLOB
Percorso Blob
Prefisso BLOB
Nome contenitore
Nome ambito di crittografia
È la versione corrente
Spazio dei nomi gerarchico abilitato
È collegamento privato
Istantanea
UTC ora (data e ora correnti nel Tempo Universale Coordinato)
ID versione

Che aspetto ha una condizione?

È possibile aggiungere condizioni alle assegnazioni di ruolo nuove o esistenti. Di seguito è riportato il ruolo Lettore dati BLOB di archiviazione assegnato a un utente denominato Chandra nell'ambito di un gruppo di risorse. È stata aggiunta anche una condizione che consente solo l'accesso in lettura ai BLOB con il tag Project=Cascade.

Diagramma dell'assegnazione di ruolo con una condizione.

Se Chandra tenta di leggere un BLOB senza il tag Project=Cascade, l'accesso non sarà consentito.

Diagramma di accesso non è permesso quando c'è una condizione.

Di seguito è riportato l'aspetto della condizione nel portale di Azure:

Ecco l'aspetto della condizione nel codice:

(
    (
        !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
        AND NOT
        SubOperationMatches{'Blob.List'})
    )
    OR
    (
        @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
    )
)

Per altre informazioni sul formato delle condizioni, vedere Formato e sintassi della condizione di assegnazione dei ruoli di Azure.

Stato delle funzionalità relative alla condizione

La tabella seguente elenca lo stato delle funzionalità relative alle condizioni.

Caratteristica / Funzionalità	stato	Dati
Usare gli attributi di ambiente in una condizione	GA	Aprile 2024
Aggiungere condizioni usando l'editor di condizioni nel portale di Azure	GA	Ottobre 2022
Aggiungere condizioni usando Azure PowerShell, l'interfaccia della riga di comando di Azure o l'API REST	GA	Ottobre 2022
Usare gli attributi delle risorse e delle richieste per combinazioni specifiche di risorse di archiviazione di Azure, tipi di attributi di accesso e livelli di prestazioni dell'account di archiviazione. Per altre informazioni, vedere Stato delle funzionalità condizionali in Archiviazione di Azure.	GA	Ottobre 2022
Usare attributi di sicurezza personalizzati su un principale in una condizione	GA	Novembre 2023

Condizioni e Microsoft Entra PIM

È anche possibile aggiungere condizioni alle assegnazioni di ruolo idonee usando Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) per le risorse di Azure. Con Microsoft Entra PIM, gli utenti finali devono attivare un'assegnazione di ruolo idonea per ottenere l'autorizzazione per eseguire determinate azioni. L'uso delle condizioni in Microsoft Entra PIM consente non solo di limitare l'accesso di un utente a una risorsa usando condizioni con granularità fine, ma anche di usare Microsoft Entra PIM per proteggerlo con un'impostazione associata al tempo, un flusso di lavoro di approvazione, un audit trail e così via. Per altre informazioni, vedere Assegnare ruoli delle risorse di Azure in Privileged Identity Management.

Terminologia

Per comprendere meglio il controllo degli accessi in base al ruolo di Azure e il controllo degli accessi in base agli attributi di Azure, si può fare riferimento ai seguenti termini.

Termine	Definizione
Controllo degli accessi in base all'attributo	Sistema di autorizzazione che definisce l'accesso in base agli attributi associati a entità di sicurezza, risorse e ambiente. Con il controllo accessi basato sugli attributi (ABAC), puoi concedere a un'entità di sicurezza l'accesso a una risorsa in base agli attributi.
Controllo degli accessi basato sugli attributi di Azure	Fa riferimento all'implementazione del controllo degli accessi basato sugli attributi per Azure.
condizione di assegnazione di ruolo	Controllo aggiuntivo che è possibile aggiungere facoltativamente all'assegnazione di ruolo per fornire un controllo di accesso più granulare.
attributo	In questo contesto, una coppia chiave-valore, ad esempio Project=Blue, dove Project è la chiave dell'attributo e Blue è il valore dell'attributo. Attributi e tag sono sinonimi per scopi di controllo di accesso.
espressione	Istruzione in una condizione che restituisce true o false. Un'espressione ha il formato di <attributo><operatore><valore>.

Limiti

Ecco alcuni dei limiti per le condizioni.

Conto risorse	Limite	Note
Numero di espressioni per condizione tramite l'editor visuale	5	È possibile aggiungere più di cinque espressioni usando l'editor di codice

Problemi noti

Ecco i problemi noti relativi alle condizioni:

Se si usano Microsoft Entra Privileged Identity Management (PIM) e attributi di sicurezza personalizzati, Principal non viene visualizzato nell'origine attributo quando si aggiunge una condizione.