Glossario sulla sicurezza per Azure Cosmos DB for NoSQL

SI APPLICA A: NoSQL

Diagramma della sequenza della guida alla distribuzione, inclusi questi percorsi, in ordine: Panoramica, Concetti, Preparazione, Controllo degli accessi in base al ruolo, Rete 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 for NoSQL.

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):

1. Segreto client o archivio certificati come variabile di ambiente
2. ID dei carichi di lavoro di Microsoft Entra
3. Identità gestita assegnata dall'utente e assegnata dal sistema
4. Credenziali di Azure derivate dalle impostazioni di Visual Studio
5. Credenziali usate nell'estensione Account di Azure di Visual Studio Code
6. Credenziali correnti dall'interfaccia della riga di comando di Azure
7. Credenziali correnti da Azure PowerShell
8. Credenziali correnti da Azure Developer CLI
9. 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 a un database specifico:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>

Infine, è possibile definire l'ambito dell'assegnazione a un singolo contenitore, l'ambito più granulare:

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>/colls/<container-name>

Passaggio successivo

Ottenere l'identità dell'account connesso