Glossario sulla sicurezza per Azure Cosmos DB per la tabella
SI APPLICA A: Tabella
Diagramma della sequenza della guida alla distribuzione, inclusi questi percorsi, in ordine: Panoramica, Concetti, Preparazione, Controllo degli accessi in base al ruolo e Riferimento. Il percorso "Concetti" è attualmente evidenziato.
Questo articolo include un glossario della terminologia comune usata in questa guida alla sicurezza per Azure Cosmos DB per la tabella.
Controllo degli accessi in base al ruolo
Il controllo degli accessi in base al ruolo fa riferimento a un metodo per gestire l'accesso alle risorse in Azure. Questo metodo si basa su identità specifiche assegnate ai ruoli che gestiscono il livello di accesso a una o più risorse. Il controllo degli accessi in base al ruolo offre un sistema flessibile di gestione degli accessi con granularità fine che garantisce che le identità abbiano solo il livello di accesso con privilegi minimi necessario per svolgere le proprie task.
Per altre informazioni, vedere Informazioni generali sul controllo degli accessi in base al ruolo.
Identità/entità di sicurezza
Le identità fanno riferimento agli oggetti all'interno di Microsoft Entra che rappresentano un'entità di sicurezza che potrebbe richiedere un livello di accesso al sistema. Nel contesto di Azure e Microsoft Entra, le identità possono fare riferimento a uno dei seguenti tipi di entità di sicurezza:
Descrizione | |
---|---|
Identità dei carichi di lavoro | Un'identità del carico di lavoro rappresenta un carico di lavoro software che deve accedere ad altri servizi o risorse |
Identità umane | Un'identità umana rappresenta un utente che può essere nativo del tenant o aggiunto come guest |
Identità gestite | Le identità gestite sono risorse distinte in Azure che rappresentano l'identità di un servizio di Azure |
Entità servizio | Un'entità servizio è un account del servizio che può essere usato in un numero flessibile di scenari di autenticazione |
Identità dei dispositivi | Un'identità del dispositivo è un oggetto in Microsoft Entra mappato a un dispositivo |
Gruppi | I gruppi sono oggetti usati per gestire l'accesso a una o più identità come singola operazione |
Per altre informazioni, vedere Nozioni fondamentali sull’identità.
Ruolo
I ruoli sono le unità primarie di applicazione dell'accesso e delle autorizzazioni. Si assegna un ruolo a un'identità e la definizione del ruolo determina il livello di accesso che l'identità può avere. L’ambito dell'assegnazione determina esattamente a cosa ha accesso l'identità.
Azure dispone di un’ampia gamma di ruoli predefiniti che è possibile usare per concedere l'accesso a varie risorse. Si consideri questo esempio:
Valore | |
---|---|
Ruolo | CosmosBackupOperator |
Definizione | Microsoft.DocumentDB/databaseAccounts/backup/action & Microsoft.DocumentDB/databaseAccounts/restore/action |
Scope | Un gruppo di risorse |
In questo esempio viene assegnato il ruolo CosmosBackupOperator
per un gruppo di risorse specifico. Questa assegnazione consente di accedere per eseguire le azioni backup
o restore
in qualsiasi account Azure Cosmos DB all'interno di tale gruppo di risorse.
Importante
Alcuni servizi di Azure, ad esempio Azure Cosmos DB, hanno una propria implementazione nativa del controllo degli accessi in base al ruolo che usa proprietà diverse di Azure Resource Manager, comandi dell'interfaccia della riga di comando di Azure e cmdLet di Azure PowerShell. I comandi usati in genere per gestire il controllo degli accessi in base al ruolo non funzioneranno con l'accesso al piano dati di Azure Cosmos DB. Alcuni dei comandi per il controllo degli accessi in base al ruolo di Azure potrebbero funzionare con l'accesso al piano di controllo di Azure Cosmos DB.
Per altre informazioni, vedere Ruoli predefiniti di Azure
Definizione del ruolo
Una definizione di ruolo è un oggetto JSON che contiene l'elenco delle azioni del piano di controllo e del piano dati consentite e non consentite. Si consideri questo esempio troncato dal ruolo predefinito CosmosRestoreOperator
:
{
"roleName": "CosmosRestoreOperator",
"type": "Microsoft.Authorization/roleDefinitions",
...
"permissions": [
{
"actions": [
"Microsoft.DocumentDB/locations/restorableDatabaseAccounts/restore/action",
"Microsoft.DocumentDB/locations/restorableDatabaseAccounts/*/read",
"Microsoft.DocumentDB/locations/restorableDatabaseAccounts/read"
],
"notActions": [],
"dataActions": [],
"notDataActions": []
}
],
...
}
In questa definizione, un'identità assegnata a questo ruolo può eseguire un'azione restore
. Al termine dell'operazione di ripristino, l'identità può leggere varie risorse per verificare che il ripristino sia riuscito. È possibile determinare che può leggere queste risorse a causa dell'operatore *
(caratteri jolly) per read
.
Per altre informazioni, vedere i concetti della definizione del ruolo.
Assegnazione di ruolo
Un'assegnazione di ruolo concede a un'identità l'accesso a una risorsa di Azure specifica. Le assegnazioni di ruolo sono costituite dai componenti seguenti:
Descrizione | |
---|---|
Server principale | A quale identità è assegnato questo ruolo |
Ruolo | Il ruolo assegnato all'identità |
Scope | Risorsa o gruppo di Azure di destinazione dell'assegnazione |
Nome/Descrizione | Metadati che semplificano la gestione delle assegnazioni su larga scala |
Suggerimento
Nel controllo degli accessi in base al ruolo, è possibile che vengano visualizzati i termini identità ed entità di sicurezza usati in modo intercambiabile.
Per altre informazioni, vedere i concetti delle assegnazioni di ruolo.
Azioni
Le azioni definiscono le autorizzazioni specifiche di un ruolo per una risorsa di destinazione. Le azioni sono stringhe che in genere includono il tipo di risorsa e un nome descrittivo indica in dettaglio le autorizzazioni concesse dall'azione. Di seguito sono riportati alcuni esempi comuni:
Descrizione | Plane | |
---|---|---|
Microsoft.DocumentDB/databaseAccounts/listKeys/action |
Sola lettura delle chiavi dell'account | Piano di controllo |
Microsoft.DocumentDB/databaseAccounts/backup/action |
Eseguire backup | Piano di controllo |
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace |
Sostituire completamente un elemento esistente | Piano dati |
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery |
Eseguire una query NoSQL | Piano dati |
Le azioni possono contenere anche caratteri *
(caratteri jolly), pertanto non è necessario specificare manualmente ogni sottomissione specifica. Ecco alcuni esempi di azioni con caratteri jolly:
Descrizione | |
---|---|
Microsoft.DocumentDb/databaseAccounts/* |
Creare e gestire account Azure Cosmos DB |
Microsoft.DocumentDB/*/read |
Leggere qualsiasi contenitore o database |
Le azioni sono separate in piano di controllo e piano dati. È necessario definire separatamente le azioni sulle risorse e sulle azioni del piano di controllo che possono influenzare i dati. In una definizione di ruolo, le azioni del piano di controllo usano le azioni della proprietà actions
e le azioni del piano dati si trovano all'interno della proprietà dataActions
. È anche possibile definire azioni che un'identità non può eseguire usando le rispettive proprietà notActions
e notDataActions
.
Nota
La separazione delle azioni nel controllo e nel piano dati è una misura di sicurezza per impedire che le azioni con caratteri jolly dalle definizioni di ruolo legacy possano avere accesso illimitato e non intenzionale ai dati.
Per altre informazioni, vedere azioni di controllo e dati.
Privilegi minimi
Il concetto di "privilegio minimo" si riferisce a una procedura operativa consigliata per garantire che tutti gli utenti dispongano solo del livello minimo di accesso necessario per eseguire il task o il lavoro. Ad esempio, un'applicazione che legge i dati da un database richiede solo l'accesso in lettura all'archivio dati. Se tale applicazione aveva accesso in lettura e in scrittura all'archivio dati, potrebbero verificarsi alcuni eventi, ad esempio:
- L'applicazione potrebbe eliminare definitivamente e in modo casuale i dati
- Un utente non autorizzato potrebbe ottenere l'accesso alle credenziali dell'applicazione e modificare i dati
Seguendo la pratica dei privilegi minimi, si garantisce che eventuali violazioni dei dati potenziali siano limitate nell'ambito. Questa pratica ottimizza la sicurezza operativa consentendo agli utenti di rimanere efficaci.
Per altre informazioni, vedere ruoli con privilegi raccomandati per task.
Piano di controllo
L'accesso al piano di controllo si riferisce alla possibilità di gestire le risorse per un servizio di Azure senza gestire i dati. Ad esempio, l'accesso al piano di controllo di Azure Cosmos DB può includere la possibilità di:
- Leggere tutti i metadati di account e risorse
- Leggere e rigenerare chiavi dell'account e stringhe di connessione
- Eseguire backup e ripristino dell'account
- Avviare e tenere traccia dei processi di trasferimento dei dati
- Gestire database e contenitori
- Modificare le proprietà dell'account
Importante
In Azure Cosmos DB sono necessari gli accessi del piano di controllo per gestire le definizioni e le assegnazioni native del controllo degli accessi in base al ruolo del piano dati. Poiché il meccanismo di controllo degli accessi in base al ruolo del piano dati di Azure Cosmos DB è nativo, sarà necessario accedere al piano di controllo per creare definizioni e assegnazioni e archiviarle come risorse all'interno di un account Azure Cosmos DB.
Piano dati
L'accesso al piano dati si riferisce alla possibilità di leggere e scrivere dati all'interno di un servizio di Azure senza la possibilità di gestire le risorse nell'account. Per esempio, l'accesso al piano dati di Azure Cosmos DB può includere la possibilità di:
- Leggere alcuni metadati di account e risorse
- Creare, leggere, aggiornare, applicare patch ed eliminare elementi
- Eseguire query NoSQL
- Leggere da un feed di modifiche del contenitore
- Eseguire stored procedure
- Gestire i conflitti nel feed dei conflitti
Autenticazione portabile
In fase di sviluppo, è comune scrivere due set di logica di autenticazione distinti per lo sviluppo locale e le istanze di produzione. Con Azure SDK è possibile scrivere la logica usando una singola tecnica e prevedere che il codice di autenticazione funzioni perfettamente in fase di sviluppo e produzione.
La libreria clienti di Identità di Azure è disponibile in più linguaggi di programmazione come parte di Azure SDK. Usando questa libreria, è possibile creare un oggetto DefaultAzureCredential
che illustra in modo intelligente più opzioni per trovare le credenziali corrette in base all'ambiente. Queste opzioni di autenticazione includono (in ordine):
- Segreto client o archivio certificati come variabile di ambiente
- ID carico di lavoro Microsoft Entra
- Identità gestita assegnata dall'utente e assegnata dal sistema
- Credenziali di Azure derivate dalle impostazioni di Visual Studio
- Credenziali usate nell'estensione Account di Azure di Visual Studio Code
- Credenziali correnti dall'interfaccia della riga di comando di Azure
- Credenziali correnti da Azure PowerShell
- Credenziali correnti da Azure Developer CLI
- Sessione interattiva che avvia il browser del sistema per l'accesso
Ogni libreria moderna di Azure SDK supporta un costruttore per i rispettivi oggetti client o classi che accettano un'istanza DefaultAzureCredential
o il relativo tipo di base.
Suggerimento
Per semplificare il debug e aumentare la prevedibilità del codice di produzione, è possibile scegliere di usare DefaultAzureCredential
in fase di sviluppo e passare a credenziali più specifiche, ad esempio WorkloadIdentityCredential
o ManagedIdentityCredential
dopo l’implementazione dell'applicazione. Tutte queste classi si basano sulla classe TokenCredential
prevista da molti SDK di Azure come parte della logica di inizializzazione del client, rendendo più semplice lo scambio avanti e indietro.
Identificatore univoco
Ogni identità in Microsoft Entra ha un identificatore univoco. A volte viene visualizzato questo identificatore univoco denominato id
, objectId
o principalId
. Quando si creano assegnazioni di ruolo, è necessario l'identificatore univoco per l'identità da usare con l'assegnazione.
Ambito
Quando si assegna un ruolo, è necessario decidere a quali risorse o gruppi di Azure concedere l'accesso. L'ambito di un'assegnazione di ruolo definisce il livello in cui viene effettuata un'assegnazione.
Ad esempio:
- Un singolo ambito di risorsa applica le autorizzazioni solo a quella singola risorsa
- Un ambito impostato a livello di gruppo di risorse applica le autorizzazioni a tutte le risorse pertinenti all'interno del gruppo
- Gli ambiti a livello di gruppo di gestione o sottoscrizione si applicano a tutti i gruppi e le risorse figlio
Quando si assegna un ruolo nel controllo degli accessi in base al ruolo di Azure, è consigliabile impostare l'ambito di tale assegnazione in modo da includere le risorse minime necessarie per il carico di lavoro. Ad esempio, è possibile impostare l'ambito di un'assegnazione su un gruppo di risorse. L'ambito del gruppo di risorse include tutte le risorse di Azure Cosmos DB all'interno del gruppo di risorse:
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>
In alternativa, è possibile impostare l'ambito su una singola risorsa di Azure e rendere più granulare e ristretta l'assegnazione delle autorizzazioni. In questo esempio, il provider e il nome della risorsa Azure Cosmos DB vengono usati per restringere l'ambito:
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>
Per altre informazioni, vedere Ambito di controllo degli accessi in base al ruolo di Azure.
Ambito (nativo di Azure Cosmos DB)
Nell'implementazione nativa di Azure Cosmos DB del controllo degli accessi in base al ruolo, l'ambito fa riferimento alla granularità delle risorse all'interno di un account per cui si vuole applicare l'autorizzazione.
Al livello più alto, è possibile definire l'ambito di un'assegnazione di controllo degli accessi in base al ruolo del piano dati all'intero account usando l'ambito più grande. Questo ambito include tutti i database e i contenitori all'interno dell'account:
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/
In alternativa, è possibile definire l'ambito dell'assegnazione di ruolo del piano dati al database predefinito:
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/TablesDB
Importante
Il database predefinito, TablesDB
, fa distinzione tra maiuscole e minuscole. Se si usa la combinazione di maiuscole e minuscole errate in un ambito, l'ambito verrà troncato all'ambito più grande consentito (livello di account).
Infine, è possibile definire l'ambito dell'assegnazione a un singolo contenitore (tabella), l'ambito più granulare:
/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/TablesDB/colls/<container-name>