Ridimensionare la gestione delle assegnazioni di ruolo di Azure usando condizioni e attributi di sicurezza personalizzati

Articolo
11/16/2023

Il controllo degli accessi in base al ruolo di Azure prevede un limite di assegnazioni di ruolo per ogni sottoscrizione. Se è necessario creare centinaia o persino migliaia di assegnazioni di ruolo di Azure, è possibile che si verifichi questo limite. La gestione di centinaia o migliaia di assegnazioni di ruolo può essere difficile. A seconda dello scenario, potrebbe essere possibile ridurre il numero di assegnazioni di ruolo e semplificare la gestione dell'accesso.

Questo articolo descrive una soluzione per ridimensionare la gestione delle assegnazioni di ruolo usando le condizioni di controllo degli accessi in base agli attributi di Azure e gli attributi di sicurezza personalizzati di Microsoft Entra per le entità.

Scenario di esempio

Si consideri una società denominata Contoso con migliaia di clienti che vogliono configurare la configurazione seguente:

Distribuire i dati dei clienti tra 128 account di archiviazione per motivi di sicurezza e prestazioni.
Aggiungere 2.000 contenitori a ogni account di archiviazione in cui è presente un contenitore per ogni cliente.
Rappresentare ogni cliente da un'entità servizio Microsoft Entra univoca.
Consentire a ogni cliente di accedere agli oggetti nel contenitore, ma non ad altri contenitori.

Questa configurazione potrebbe richiedere potenzialmente 256.000 Archiviazione assegnazioni di ruolo Proprietario dati BLOB in una sottoscrizione, che supera il limite di assegnazioni di ruolo. Avere queste numerose assegnazioni di ruolo sarebbe difficile, se non impossibile, mantenere.

Diagram showing thousands for role assignments.

Soluzione di esempio

Un modo per gestire questo scenario in modo gestibile consiste nell'usare le condizioni di assegnazione di ruolo. Il diagramma seguente illustra una soluzione per ridurre le 256.000 assegnazioni di ruolo a una sola assegnazione di ruolo usando una condizione. L'assegnazione di ruolo si trova in un ambito di gruppo di risorse superiore e una condizione consente di controllare l'accesso ai contenitori. La condizione controlla se il nome del contenitore corrisponde all'attributo di sicurezza personalizzato nell'entità servizio per il cliente.

Diagram showing one role assignment and a condition.

Ecco l'espressione nella condizione che rende questa soluzione funzionante:

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

La condizione completa sarà simile alla seguente. L'elenco di azioni può essere modificato in base alle azioni necessarie.

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

Perché usare questa soluzione?

Esistono diversi meccanismi di controllo di accesso che è possibile usare per fornire l'accesso alle risorse del piano dati.

Le chiavi di accesso sono un modo comune per fornire l'accesso alle risorse del piano dati. Le chiavi di accesso forniscono autorizzazioni di lettura, scrittura ed eliminazione a chiunque disponga della chiave di accesso. Ciò significa che gli utenti malintenzionati possono ottenere l'accesso ai dati sensibili se possono ottenere le chiavi di accesso. Le chiavi di accesso non hanno l'associazione di identità, non hanno una scadenza e rappresentano un rischio per la sicurezza da archiviare.

Come le chiavi di accesso, i token di firma di accesso condiviso (SAS) non hanno un'associazione di identità, ma scadono regolarmente. La mancanza di associazione di identità rappresenta gli stessi rischi per la sicurezza delle chiavi di accesso. È necessario gestire la scadenza per assicurarsi che i client non ottengano errori. I token di firma di accesso condiviso richiedono codice aggiuntivo per gestire e operare quotidianamente e possono essere un sovraccarico significativo per un team DevOps.

Il controllo degli accessi in base al ruolo di Azure offre un controllo di accesso centralizzato con granularità fine. Il controllo degli accessi in base al ruolo di Azure ha un'associazione di identità che riduce il rischio di sicurezza. Usando le condizioni è possibile ridimensionare potenzialmente la gestione delle assegnazioni di ruolo e semplificare la gestione del controllo di accesso perché l'accesso si basa su attributi flessibili e dinamici.

Ecco alcuni dei vantaggi di questa soluzione:

Controllo di accesso centralizzato
Più facile da gestire
Non si basa su chiavi di accesso o token di firma di accesso condiviso
Non richiede la gestione dell'accesso per ogni oggetto
Può potenzialmente migliorare il comportamento di sicurezza

È possibile usare questa soluzione?

Se si ha uno scenario simile, seguire questa procedura per verificare se è possibile usare questa soluzione.

Passaggio 1: Determinare se si soddisfano i prerequisiti

Per usare questa soluzione, è necessario disporre di:

Più assegnazioni di ruolo predefinite o personalizzate con azioni sui dati di archiviazione BLOB. Sono inclusi i ruoli predefiniti seguenti:

Passaggio 2: Identificare gli attributi che è possibile usare nella condizione

Esistono diversi attributi che è possibile usare nella condizione, ad esempio:

Nome contenitore
Percorso BLOB
Tag di indice BLOB [Chiavi]
Tag di indice BLOB [Valori nella chiave]

È anche possibile definire attributi di sicurezza personalizzati per utenti, applicazioni aziendali e identità gestite.

Per altre informazioni, vedere Formato e sintassi della condizione di assegnazione dei ruoli di Azure e Che cosa sono gli attributi di sicurezza personalizzati in Microsoft Entra ID?.

Passaggio 3: Creare una condizione in un ambito superiore

Creare una o più assegnazioni di ruolo che usano una condizione in un ambito superiore per gestire l'accesso. Per altre informazioni, vedere Aggiungere o modificare condizioni di assegnazione di ruolo di Azure usando il portale di Azure.

Condividi tramite