Considerazioni sulla sicurezza per le condizioni di assegnazione dei ruoli di Azure in Archiviazione BLOB di Azure
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.
Importante
Il controllo degli accessi in base all'attributo di Azure è disponibile a livello generale per controllare l'accesso a Archiviazione BLOB di Azure, Azure Data Lake Archiviazione Gen2 e Code di Azure usando requestgli attributi , resourceenvironment, e principal nei livelli di prestazioni dell'account di archiviazione Standard e Premium. Attualmente, l'attributo della risorsa dei metadati del contenitore e l'attributo di richiesta di inclusione del BLOB di elenco sono disponibili in ANTEPRIMA. Per informazioni complete sullo stato della funzionalità di controllo degli accessi in base all'attributo (ABAC) per Archiviazione di Azure, vedere Stato delle funzionalità relative alle condizioni in Archiviazione di Azure.
Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.
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
- Firma di accesso condiviso del servizio.
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 di firma di accesso condiviso, 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 firma di accesso condiviso della delega utente dipende dal controllo degli accessi in base al ruolo di Azure, le condizioni di assegnazione dei ruoli vengono valutate quando si usa 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:
| Azione | Descrizione |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action |
Questa azione consente ai clienti di rinominare un file usando l'API Path Create. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action |
Questa azione consente l'accesso a varie operazioni di file system e percorso. |
Tag indice del 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 vengono usati tag di indice BLOB in condizioni, i dati potrebbero essere vulnerabili se i dati e i tag di indice associati vengono aggiornati in operazioni separate. È possibile usare @Request le condizioni per le operazioni di scrittura 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.
Tag 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 nelle versioni del 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 si usano condizioni di assegnazione di ruolo per i ruoli predefiniti di Azure, è consigliabile esaminare attentamente tutte le autorizzazioni concesse dal ruolo a un'entità di sicurezza.
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. Il controllo degli accessi in base al ruolo di Azure ha un modello aggiuntivo, quindi le autorizzazioni valide sono la somma delle assegnazioni di ruolo a ogni livello. Se a un'entità è assegnata la stessa autorizzazione tramite più assegnazioni di ruolo, l'accesso per un'operazione che usa tale autorizzazione viene valutato separatamente per ogni assegnazione a ogni 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. Si supponga di assegnare il ruolo Collaboratore dati BLOB Archiviazione a un utente per un account di archiviazione e in una sottoscrizione, ma aggiungere una condizione solo all'assegnazione per l'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 o l'autorizzazione Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action . I ruoli predefiniti, ad esempio Archiviazione Proprietario dati BLOB e Archiviazione Collaboratore dati BLOB 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 nel BLOB di origine, @Resource vengono valutate le condizioni sull'azione Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read .