Configurare le chiavi gestite dal cliente tra tenant per l'account Azure Cosmos DB con Azure Key Vault
SI APPLICA A: NoSQL MongoDB Cassandra Gremlin Tabella
I dati archiviati nell'account Azure Cosmos DB vengono crittografati automaticamente e facilmente con le chiavi gestite dal servizio gestite da Microsoft. Tuttavia, è possibile scegliere di aggiungere un secondo livello di crittografia con chiavi gestite personalmente. Queste chiavi sono note come chiavi gestite dal cliente (o CMK). Le chiavi gestite dal cliente vengono archiviate in un'istanza di Azure Key Vault.
Questo articolo illustra come configurare la crittografia con chiavi gestite dal cliente al momento della creazione di un account Azure Cosmos DB. In questo esempio di scenario tra tenant, l'account Azure Cosmos DB risiede in un tenant gestito da un fornitore di software indipendente (ISV) denominato provider di servizi. La chiave usata per la crittografia dell'account Azure Cosmos DB risiede in un insieme di credenziali delle chiavi in un tenant diverso gestito dal cliente.
Informazioni sulle chiavi gestite dal cliente tra tenant
Molti provider di servizi che creano offerte SaaS (Software as a Service) in Azure vogliono offrire ai clienti la possibilità di gestire le proprie chiavi di crittografia. Le chiavi gestite dal cliente consentono a un provider di servizi di crittografare i dati del cliente usando una chiave di crittografia gestita dal cliente del provider e non accessibile al provider stesso. In Azure, il cliente del provider di servizi può usare Azure Key Vault per gestire le chiavi di crittografia nel proprio tenant e nella propria sottoscrizione di Microsoft Entra.
I servizi e le risorse della piattaforma Azure di proprietà del provider di servizi e che risiedono nel suo tenant richiedono l'accesso alla chiave dal tenant del cliente per eseguire le operazioni di crittografia/decrittografia.
L'immagine seguente mostra la crittografia dei dati inattivi con identità federata in un flusso di lavoro CMK tra tenant che interessa un provider di servizi e il relativo cliente.
Nell'esempio precedente sono presenti due tenant di Microsoft Entra: il tenant di un provider di servizi indipendenti (Tenant 1) e il tenant di un cliente (Tenant 2). Tenant 1 ospita i servizi della piattaforma Azure e Tenant 2 ospita l'insieme di credenziali delle chiavi del cliente.
La registrazione di un'applicazione multi-tenant viene creata dal provider di servizi in Tenant 1. In questa applicazione viene creata una credenziale di identità federata usando un'identità gestita assegnata dall'utente. Il nome e l'ID applicazione dell'app vengono quindi condivisi con il cliente.
Un utente con le autorizzazioni appropriate installa l'applicazione del provider di servizi nel tenant del cliente, ovvero in Tenant 2. Un utente concede quindi all'entità servizio associato all'applicazione installata l'accesso all'insieme di credenziali delle chiavi del cliente. Il cliente archivia anche la chiave di crittografia o la chiave gestita dal cliente nell'insieme di credenziali delle chiavi. Il cliente condivide il percorso della chiave (l'URL della chiave) con il provider di servizi.
Il provider di servizi dispone ora di:
- Un ID applicazione per un'applicazione multi-tenant installata nel tenant del cliente, a cui è stato concesso l'accesso alla chiave gestita dal cliente.
- Un'identità gestita configurata come credenziale nell'applicazione multi-tenant.
- La posizione della chiave nell'insieme di credenziali delle chiavi del cliente.
Con questi tre parametri, il provider di servizi effettua il provisioning delle risorse di Azure in Tenant 1 che possono essere crittografate con la chiave gestita dal cliente in Tenant 2.
A questo punto, è possibile suddividere la soluzione end-to-end precedente in tre fasi:
- Il provider di servizi configura le identità.
- Il cliente concede all'app multi-tenant del provider di servizi l'accesso a una chiave di crittografia in Azure Key Vault.
- Il provider di servizi crittografa i dati in una risorsa di Azure usando la chiave gestita dal cliente.
Le operazioni nella fase 1 sono una configurazione una tantum per la maggior parte delle applicazioni del provider di servizi. Le operazioni nelle fasi 2 e 3 si ripetono invece per ogni cliente.
Fase 1: il provider di servizi configura un'applicazione Microsoft Entra
Procedi | Descrizione | Ruolo minimo a livello di controllo degli accessi in base al ruolo di Azure | Ruolo minimo a livello di controllo degli accessi in base al ruolo di Microsoft Entra |
---|---|---|---|
1. | Creare una nuova registrazione dell'applicazione Microsoft Entra multi-tenant o iniziare con una registrazione dell'applicazione esistente. Prendere nota dell'ID applicazione (ID client) della registrazione dell'applicazione tramite il portale di Azure, l'API Microsoft Graph, Azure PowerShell o l'interfaccia della riga di comando di Azure | None | Sviluppatore di applicazioni |
2. | Creare un'identità gestita assegnata dall'utente (da usare come credenziale di identità federata). Portale di Azure / Interfaccia della riga di comando di Azure / Azure PowerShell/ Modelli di Azure Resource Manager |
Collaboratore di identità gestita | None |
3. | Configurare l'identità gestita assegnata dall'utente come credenziale di identità federata nell'applicazione, in modo che possa rappresentare l'identità dell'applicazione. Informazioni di riferimento sulle API Graph/ Portale di Azure/ Interfaccia della riga di comando di Azure/ Azure PowerShell |
None | Proprietario dell'applicazione |
4. | Condividere il nome dell'applicazione e l'ID applicazione con il cliente, in modo che possano installare e autorizzare l'applicazione. | None | None |
Considerazioni per i provider di servizi
- I modelli di Azure Resource Manager (ARM) non sono consigliati per la creazione di applicazioni Microsoft Entra.
- La stessa applicazione multi-tenant può essere usata per accedere alle chiavi in un numero qualsiasi di tenant, ad esempio Tenant 2, Tenant 3, Tenant 4 e così via. In ogni tenant viene creata un'istanza indipendente dell'applicazione con lo stesso ID applicazione ma un ID oggetto diverso. Ogni istanza di questa applicazione viene quindi autorizzata in modo indipendente. Si consideri il modo in cui l'oggetto applicazione usato per questa funzionalità viene impiegato per partizionare l'applicazione in tutti i clienti.
- L'applicazione può avere un massimo di 20 credenziali di identità federate e ciò comporta che un provider di servizi condivida le identità federate tra i propri clienti. Per altre informazioni sulle considerazioni e sulle restrizioni di progettazione delle identità federate, vedere Configurare un'app per considerare attendibile un provider di identità esterno
- In rari scenari, un provider di servizi potrebbe usare un singolo oggetto Application per ogni cliente, ma richiede costi di manutenzione significativi per gestire le applicazioni su larga scala in tutti i clienti.
- Nel tenant del provider di servizi non è possibile automatizzare la verifica del server di pubblicazione.
Fase 2: il cliente autorizza l'accesso all'insieme di credenziali delle chiavi
Procedi | Descrizione | Ruoli Controllo degli accessi in base al ruolo di Azure con privilegi minimi | Ruoli di Microsoft Entra con privilegi minimi |
---|---|---|---|
1. | None | Utenti con autorizzazioni per installare le applicazioni | |
2. | Creare un'istanza di Azure Key Vault e una chiave usata come chiave gestita dal cliente. | A un utente deve essere assegnato il ruolo Collaboratore di Key Vault per creare l'insieme di credenziali delle chiavi A un utente deve essere assegnato il ruolo Responsabile della crittografia di Key Vault per aggiungere una chiave all'insieme di credenziali delle chiavi |
None |
3. | Concedere all'identità dell'applicazione concessa l'accesso all'insieme di credenziali delle chiavi di Azure assegnando il ruolo Utente di crittografia del servizio di crittografia di Key Vault | Per assegnare il ruolo Utente di crittografia del servizio di crittografia di Key Vault all'applicazione, è necessario aver assegnato il ruolo Amministratore accessi utente. | None |
4. | Copiare l'URL dell'insieme di credenziali delle chiavi e il nome della chiave nella configurazione delle chiavi gestite dal cliente dell'offerta SaaS. | None | None |
Nota
Per autorizzare l'accesso al modulo di protezione hardware gestito per la crittografia tramite la chiave gestita dal cliente, vedere l'esempio relativo all'account di archiviazione qui. Per altre informazioni sulla gestione delle chiavi mediante il modulo di protezione hardware gestito, vedere Gestire un modulo di protezione hardware gestito con l'interfaccia della riga di comando di Azure
Considerazioni per i clienti dei provider di servizi
- Nel tenant del cliente, Tenant 2, un amministratore può impostare criteri per impedire agli utenti non amministratori di installare le applicazioni. Questi criteri possono impedire agli utenti non amministratori di creare entità servizio. Se questi criteri sono configurati, è necessario coinvolgere gli utenti con autorizzazioni per creare entità servizio.
- L'accesso ad Azure Key Vault può essere autorizzato usando il controllo degli accessi in base al ruolo di Azure o i criteri di accesso. Quando si concede l'accesso a un insieme di credenziali delle chiavi, assicurarsi di usare il meccanismo attivo per l'insieme di credenziali delle chiavi in uso.
- Una registrazione dell'applicazione Microsoft Entra ha un ID applicazione (ID client). Quando l'applicazione viene installata nel tenant, viene creata un'entità servizio. L'entità servizio condivide lo stesso ID applicazione della registrazione dell'app, ma genera il proprio ID oggetto. Quando si autorizza l'applicazione ad avere accesso alle risorse, potrebbe essere necessario usare l'entità servizio
Name
o la proprietàObjectID
.
Fase 3: il provider di servizi crittografa i dati in una risorsa di Azure usando la chiave gestita dal cliente
Al termine delle fasi 1 e 2, il provider di servizi può configurare la crittografia nella risorsa di Azure con la chiave e l'insieme di credenziali delle chiavi nel tenant del cliente e la risorsa di Azure nel tenant del fornitore di software indipendente. Il provider di servizi può configurare chiavi gestite dal cliente tra tenant con gli strumenti client supportati da tale risorsa di Azure, con un modello di Resource Manager o con l'API REST.
Configurare chiavi gestite dal cliente tra tenant
Questa sezione descrive come configurare una chiave gestita dal cliente multi-tenant e crittografare i dati dei clienti. Si apprenderà come crittografare i dati dei clienti in una risorsa in Tenant1 usando una chiave gestita dal cliente archiviata in un insieme di credenziali delle chiavi in Tenant2. È possibile usare il portale di Azure, Azure PowerShell o l'interfaccia della riga di comando di Azure.
Accedere al portale di Azure e seguire questi passaggi.
Il provider di servizi configura le identità
I passaggi seguenti vengono eseguiti dal provider di servizi nel proprio tenant, ovvero Tenant1.
Il provider di servizi crea una nuova registrazione dell'app multi-tenant
È possibile creare una nuova registrazione dell'applicazione Microsoft Entra multi-tenant o iniziare con una registrazione dell'applicazione multi-tenant esistente. Se si inizia con una registrazione dell'applicazione esistente, prendere nota dell'ID applicazione (ID client) dell'applicazione.
Per creare una nuova registrazione:
Cercare Microsoft Entra ID nella casella di ricerca. Individuare e selezionare l'estensione Microsoft Entra ID.
Selezionare Gestisci > Registrazioni app nel riquadro sinistro.
Seleziona + Nuova registrazione.
Specificare il nome della registrazione dell'applicazione e selezionare Account in qualsiasi directory organizzativa (qualsiasi directory Microsoft Entra - Multi-tenant).
Selezionare Registra.
Prendere nota dell'ID applicazione/ID client dell'applicazione.
Il provider di servizi crea un'identità gestita assegnata dall'utente
Creare un'identità gestita assegnata dall'utente (da usare come credenziale di identità federata).
Cercare Identità gestite nella casella di ricerca. Individuare e selezionare l'estensione Identità gestite.
Seleziona + Crea.
Specificare il gruppo di risorse, l'area e il nome per l'identità gestita.
Selezionare Rivedi e crea.
Al termine della distribuzione, prendere nota dell'ID risorsa di Azure dell'identità gestita assegnata dall'utente, disponibile in Proprietà. Ad esempio:
/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA
Il provider di servizi configura l'identità gestita assegnata dall'utente come credenziale federata nell'applicazione
Configurare un'identità gestita assegnata dall'utente come credenziale di identità federata nell'applicazione, in modo che possa rappresentare l'identità dell'applicazione.
Passare a Microsoft Entra ID > Registrazioni app > applicazione desiderata.
Selezionare Certificati e segreti.
Selezionare Credenziali federate.
Selezionare + Aggiungi credenziali.
In Scenario credenziali federate selezionare Chiavi gestite dal cliente.
Fare clic su Selezionare un'identità gestita. Nel riquadro selezionare la sottoscrizione. In Identità gestita selezionare Identità gestita assegnata dall'utente. Nella casella Seleziona cercare l'identità gestita creata in precedenza, quindi fare clic su Seleziona nella parte inferiore del riquadro.
In Dettagli credenziali specificare un nome e una descrizione facoltativa per le credenziali e selezionare Aggiungi.
Il provider di servizi condivide l'ID applicazione con il cliente
Trovare l'ID applicazione (ID client) dell'applicazione multi-tenant e condividerlo con il cliente.
Il cliente concede all'app del provider di servizi l'accesso alla chiave nell'insieme di credenziali delle chiavi
I passaggi seguenti vengono eseguiti dal cliente nel tenant del cliente Tenant2. Il cliente può usare il portale di Azure, Azure PowerShell o l'interfaccia della riga di comando di Azure.
L'utente che esegue i passaggi deve essere un amministratore con un ruolo con privilegi, ad esempio Amministratore applicazione, Amministratore applicazione cloud o Amministratore globale.
Accedere al portale di Azure e seguire questi passaggi.
Il cliente installa l'applicazione del provider di servizi nel tenant del cliente
Per installare l'applicazione registrata del provider di servizi nel tenant del cliente, creare un'entità servizio con l'ID applicazione dall'app registrata. È possibile creare l'entità servizio in uno dei modi seguenti:
- Usare Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell o l'interfaccia della riga di comando di Azure per creare manualmente l'entità servizio.
- Creare un URL di consenso amministratore e concedere il consenso a livello di tenant per creare l'entità servizio. Sarà necessario specificare queste informazioni usando AppId.
Il cliente crea un insieme di credenziali delle chiavi
Per creare l'insieme di credenziali delle chiavi, all'account dell'utente deve essere assegnato il ruolo Collaboratore di Key Vault o un altro ruolo che consenta la creazione di un insieme di credenziali delle chiavi.
Nel menu del portale di Azure o dalla pagina Home selezionare + Crea una risorsa. Nella casella Cerca immettere Insiemi di credenziali delle chiavi. Nell'elenco dei risultati scegliere Insiemi di credenziali delle chiavi . Nella pagina Insiemi di credenziali delle chiavi selezionare Crea.
Nella scheda Informazioni di base scegliere una sottoscrizione. In Gruppo di risorse selezionare Crea nuovo e immettere un nome per il gruppo di risorse.
Immettere un nome univoco per l'insieme di credenziali delle chiavi.
Selezionare un'area e un piano tariffario.
Abilitare la protezione dalla rimozione definitiva per il nuovo insieme di credenziali delle chiavi.
Nella scheda Criteri di accesso selezionare Controllo degli accessi in base al ruolo di Azure per Modello di autorizzazione.
Selezionare Rivedi e crea e quindi Crea.
Prendere nota del nome dell'insieme di credenziali delle chiavi e dell'URI. Le applicazioni che accedono all'insieme di credenziali delle chiavi devono usare questo URI.
Per altre informazioni, vedere Avvio rapido: Creare un'istanza di Azure Key Vault tramite il portale di Azure.
Il cliente assegna il ruolo Responsabile della crittografia di Key Vault a un account utente
Questo passaggio garantisce che sia possibile creare chiavi di crittografia.
- Passare all'insieme di credenziali delle chiavi e selezionare Controllo di accesso (IAM) nel riquadro sinistro.
- Sotto Concedi l'accesso a questa risorsa, seleziona Aggiungi assegnazione ruolo.
- Cercare e selezionare Responsabile della crittografia di Key Vault.
- In Membri selezionare Utente, gruppo o entità servizio.
- Selezionare Membri e cercare l'account utente.
- Selezionare Rivedi + Assegna.
Il cliente crea una chiave di crittografia
Per creare la chiave di crittografia, all'account dell'utente deve essere assegnato il ruolo Responsabile della crittografia di Key Vault o un altro ruolo che consenta la creazione di una chiave.
- Nella pagina delle proprietà dell'istanza di Key Vault selezionare Chiavi.
- Seleziona Genera/Importa.
- Nella schermata Crea una chiave specificare un nome per la chiave. Lasciare invariati gli altri valori predefiniti.
- Seleziona Crea.
- Copiare l'URI della chiave.
Il cliente concede all'applicazione del provider di servizi l'accesso alla chiave nell'insieme di credenziali delle chiavi
Assegnare il ruolo Controllo degli accessi in base al ruolo di Azure Utente di crittografia del servizio di crittografia di Key Vault all'applicazione registrata del provider di servizi in modo che possa accedere all'insieme di credenziali delle chiavi.
- Passare all'insieme di credenziali delle chiavi e selezionare Controllo di accesso (IAM) nel riquadro sinistro.
- Sotto Concedi l'accesso a questa risorsa, seleziona Aggiungi assegnazione ruolo.
- Cercare e selezionare Utente di crittografia del servizio di crittografia di Key Vault.
- In Membri selezionare Utente, gruppo o entità servizio.
- Selezionare Membri e cercare il nome dell'applicazione installata dal provider di servizi.
- Selezionare Rivedi + Assegna.
È ora possibile configurare le chiavi gestite dal cliente con l'URI e la chiave dell'insieme di credenziali delle chiavi.
Creare un nuovo account Azure Cosmos DB crittografato con una chiave da un tenant diverso
A questo punto, è stata configurata l'applicazione multi-tenant nel tenant del provider di servizi. L'applicazione è stata installata anche nel tenant del cliente e sono stati configurati l'insieme di credenziali delle chiavi e la chiave nel tenant del cliente. Successivamente è possibile creare un account Azure Cosmos DB nel tenant del provider di servizi e configurare le chiavi gestite dal cliente con la chiave del tenant del cliente.
Quando si crea un account Azure Cosmos DB con chiavi gestite dal cliente, è necessario assicurarsi che abbia accesso alle chiavi usate dal cliente. Negli scenari a tenant singolo, concedere l'accesso diretto dell'insieme di credenziali delle chiavi all'entità di sicurezza di Azure Cosmos DB o usare un'identità gestita specifica. In uno scenario tra tenant, non è più possibile dipendere dall'accesso diretto all'insieme di credenziali delle chiavi perché si trova in un altro tenant gestito dal cliente. Questo vincolo è il motivo per cui nelle sezioni precedenti è stata creata un'applicazione tra tenant ed è stata registrata un'identità gestita all'interno dell'applicazione per concedere l'accesso all'insieme di credenziali delle chiavi del cliente. Questa identità gestita, abbinata all'ID applicazione tra tenant, è ciò che verrà usato durante la creazione dell'account Azure Cosmos DB tra tenant. Per altre informazioni, vedere la sezione Fase 3: il provider di servizi crittografa i dati in una risorsa di Azure usando la chiave gestita dal cliente.
Ogni volta che è disponibile una nuova versione della chiave nell'insieme di credenziali delle chiavi, essa verrà aggiornata automaticamente nell'account Azure Cosmos DB.
Uso dei modelli JSON di Azure Resource Manager
Distribuire un modello di Resource Manager con i parametri specifici seguenti:
Nota
Se si ricrea questo esempio in uno dei modelli di Azure Resource Manager, impostare apiVersion
su 2022-05-15
.
Parametro | Descrizione | Valore di esempio |
---|---|---|
keyVaultKeyUri |
Identificatore della chiave gestita dal cliente che risiede nell'insieme di credenziali delle chiavi del provider di servizi. | https://my-vault.vault.azure.com/keys/my-key |
identity |
Oggetto che specifica che l'identità gestita deve essere assegnata all'account Azure Cosmos DB. | "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}} |
defaultIdentity |
Combinazione dell'ID risorsa dell'identità gestita e dell'ID applicazione dell'applicazione Microsoft Entra multi-tenant. | UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e |
Ecco un esempio di segmento di modello con i tre parametri configurati:
{
"kind": "GlobalDocumentDB",
"location": "East US 2",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity": {}
}
},
"properties": {
"locations": [
{
"locationName": "East US 2",
"failoverPriority": 0,
"isZoneRedundant": false
}
],
"databaseAccountOfferType": "Standard",
"keyVaultKeyUri": "https://my-vault.vault.azure.com/keys/my-key",
"defaultIdentity": "UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
}
}
Importante
Questa funzionalità non è ancora supportata in Azure PowerShell, nell'interfaccia della riga di comando di Azure o nel portale di Azure.
Non è possibile configurare chiavi gestite dal cliente con una versione specifica della versione della chiave quando si crea un nuovo account Azure Cosmos DB. La chiave stessa deve essere passata senza versioni e senza barre rovesciate finali.
Per revocare o disabilitare le chiavi gestite dal cliente, vedere Configurare le chiavi gestite dal cliente per l'account Azure Cosmos DB con Azure Key Vault