Considerazioni sulla sicurezza per le condizioni di assegnazione dei ruoli in Azure in Azure Blob Storage

Per proteggere completamente le risorse usando il controllo degli accessi in base all'attributo di Azure, è necessario proteggere anche gli attributi usati nelle condizioni di assegnazione dei ruoli di Azure. Ad esempio, se la condizione è basata su un percorso di file, è necessario prestare attenzione a che l'accesso può essere compromesso se l'entità dispone di un'autorizzazione senza restrizioni per rinominare un percorso di file.

Questo articolo descrive le considerazioni sulla sicurezza da considerare nelle condizioni di assegnazione dei ruoli.

Uso di altri meccanismi di autorizzazione

Le condizioni di assegnazione dei ruoli vengono valutate solo quando si usa il controllo degli accessi in base al ruolo di Azure per l'autorizzazione. Queste condizioni possono essere ignorate se si consente l'accesso usando metodi di autorizzazione alternativi:

• Autorizzazione con chiave condivisa
• Firma di accesso condiviso dell'account
• Accesso Condiviso del Servizio SAS.

Analogamente, le condizioni non vengono valutate quando viene concesso l'accesso usando elenchi di controllo di accesso (ACL) negli account di archiviazione con uno spazio dei nomi gerarchico (HNS).

È possibile impedire l'autorizzazione tramite chiave condivisa, firma di accesso condiviso a livello di account e firma di accesso condiviso a livello di servizio disabilitando l'autorizzazione della chiave condivisa per l'account di archiviazione. Poiché la delegazione utente SAS dipende dal Controllo degli Accessi Basato sui Ruoli di Azure (Azure RBAC), le condizioni di assegnazione dei ruoli vengono valutate quando si utilizza questo metodo di autorizzazione.

Protezione degli attributi di archiviazione usati nelle condizioni

Percorso Blob

Quando si usa il percorso BLOB come attributo @Resource per una condizione, è anche consigliabile impedire agli utenti di rinominare un BLOB per ottenere l'accesso a un file quando si usano account con uno spazio dei nomi gerarchico. Ad esempio, se si vuole creare una condizione in base al percorso DEL BLOB, è necessario limitare anche l'accesso dell'utente alle azioni seguenti:

Tag indice BLOB

I tag di indice BLOB vengono usati come attributi in formato libero per le condizioni nell'archiviazione. Se si creano condizioni di accesso usando questi tag, è necessario proteggere anche i tag stessi. In particolare, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction consente agli utenti di modificare i tag in un oggetto di archiviazione. È possibile limitare questa azione per impedire agli utenti di modificare una chiave o un valore di tag per ottenere l'accesso a oggetti non autorizzati.

Inoltre, se i tag dell'indice BLOB sono utilizzati nelle condizioni, i dati potrebbero essere vulnerabili se i dati e i relativi tag di indice vengono aggiornati in operazioni separate. È possibile usare le condizioni @Request nelle operazioni di scrittura sui blob per richiedere che i tag di indice siano impostati nella stessa operazione di aggiornamento. Questo approccio consente di proteggere i dati dall'istante in cui viene scritto nell'archiviazione.

Tag nei BLOB copiati

Per impostazione predefinita, i tag di indice BLOB non vengono copiati da un BLOB di origine alla destinazione quando si usa l'API Copia BLOB o una delle relative varianti. Per mantenere l'ambito di accesso per il BLOB al momento della copia, è necessario copiare anche i tag.

Etichette per gli snapshot

Non è possibile modificare i tag sugli snapshot blob. Pertanto, è necessario aggiornare i tag in un BLOB prima di acquisire lo snapshot. Se si modificano i tag in un BLOB di base, i tag nello snapshot continuano a avere il valore precedente.

Se un tag in un BLOB di base viene modificato dopo l'acquisizione di uno snapshot, l'ambito di accesso può essere diverso per il BLOB di base e lo snapshot.

Tag sulle versioni BLOB

I tag di indice BLOB non vengono copiati quando viene creata una versione del BLOB tramite le API Put BLOB, Put Block List o Copy Blob . È possibile specificare tag tramite l'intestazione per queste API.

I tag possono essere impostati singolarmente in un BLOB di base corrente e in ogni versione del BLOB. Quando si modificano i tag in un BLOB di base, i tag nelle versioni precedenti non vengono aggiornati. Se si vuole modificare l'ambito di accesso per un BLOB e tutte le relative versioni usando i tag, è necessario aggiornare i tag in ogni versione.

Limitazioni di query e filtro per versioni e snapshot

Quando si usano tag per eseguire query e filtrare i BLOB in un contenitore, nella risposta vengono inclusi solo i BLOB di base. Le versioni o gli snapshot del BLOB con le chiavi e i valori richiesti non sono inclusi.

Ruoli e autorizzazioni

Se usi condizioni di assegnazione di ruolo per i ruoli predefiniti di Azure, dovresti esaminare attentamente tutte le autorizzazioni concesse dal ruolo a un'entità.

Assegnazioni di ruolo ereditate

Le assegnazioni di ruolo possono essere configurate per un gruppo di gestione, una sottoscrizione, un gruppo di risorse, un account di archiviazione o un contenitore e vengono ereditate a ogni livello nell'ordine indicato. Azure RBAC ha un modello aggiuntivo, quindi le autorizzazioni effettive sono la somma delle assegnazioni di ruolo a ogni livello. Se a un principale è assegnato lo stesso permesso tramite più assegnazioni di ruolo, l'accesso per un'operazione che usa tale permesso viene valutato separatamente per ogni assegnazione a ciascun livello.

Poiché le condizioni vengono implementate come condizioni per le assegnazioni di ruolo, qualsiasi assegnazione di ruolo incondizionato può consentire agli utenti di ignorare la condizione. Supponiamo di assegnare il ruolo Collaboratore ai dati dei BLOB di archiviazione a un utente per un account di archiviazione e nell'ambito di una sottoscrizione, ma aggiungere una condizione solo all'assegnazione relativa all'account di archiviazione. Il risultato è che l'utente ha accesso illimitato all'account di archiviazione tramite l'assegnazione di ruolo a livello di sottoscrizione.

Pertanto, è consigliabile applicare le condizioni in modo coerente per tutte le assegnazioni di ruolo in una gerarchia di risorse.

Altre considerazioni

Operazioni di condizione che scrivono BLOB

Molte operazioni che scrivono BLOB richiedono l'autorizzazione Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. I ruoli predefiniti, ad esempio proprietario dei dati dei BLOB di archiviazione e Collaboratore ai dati dei BLOB di archiviazione , concedono entrambe le autorizzazioni a un'entità di sicurezza.

Quando si definisce una condizione di assegnazione di ruolo in questi ruoli, è necessario usare condizioni identiche per entrambe queste autorizzazioni per garantire restrizioni di accesso coerenti per le operazioni di scrittura.

Comportamento per la copia di BLOB e la copia di BLOB dall'URL

Per le operazioni Copia BLOB e Copia BLOB da URL , @Request le condizioni che usano il percorso BLOB come attributo per l'azione Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write e le relative sottooperazioni vengono valutate solo per il BLOB di destinazione.

Per le condizioni sul BLOB di origine, @Resource vengono valutate le condizioni relative all'azione Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read.

Vedere anche

• Autorizzare l'accesso ai BLOB usando le condizioni di assegnazione dei ruoli di Azure
• Azioni e attributi per le condizioni di assegnazione di ruolo di Azure in Archiviazione BLOB di Azure
• Che cos'è il controllo degli accessi in base all'attributo di Azure?