Condividi tramite

Linee guida per l'uso di Azure Key Vault in una soluzione multi-tenant

Azure Key Vault viene usato per gestire i dati sicuri per la soluzione, inclusi segreti, chiavi di crittografia e certificati. In questo articolo vengono descritte alcune delle funzionalità di Azure Key Vault utili per le soluzioni multi-tenant. Vengono quindi forniti collegamenti alle linee guida che possono aiutarti, quando pianifichi l'uso di Key Vault.

Modalità di isolamento

Quando si usa un sistema multi-tenant con Key Vault, è necessario prendere una decisione sul livello di isolamento che si vuole usare. La scelta dei modelli di isolamento usati dipende dai fattori seguenti:

  • Quanti tenant si prevede di avere?
  • Si condivide il livello dell'applicazione tra più tenant, si distribuiscono istanze di applicazioni a tenant singolo o si distribuiscono istanze di distribuzione separate per ogni tenant?
  • I tenant devono gestire le proprie chiavi di crittografia?
  • I vostri inquilini hanno requisiti di conformità che richiedono che i loro segreti vengano archiviati separatamente dai segreti di altri inquilini?

La tabella seguente riepiloga le differenze tra i modelli di tenancy principali per Key Vault:

Considerazioni Insieme di credenziali per tenant, nella sottoscrizione del provider Cassaforte per tenant, nella sottoscrizione del tenant Cassaforte condivisa
Isolamento dei dati Alto Molto alto Basso
Isolamento delle prestazioni Medio. La velocità di elaborazione elevata potrebbe essere limitata, anche con molte casseforti. Alto Basso
Complessità della distribuzione Medio-basso, a seconda del numero di inquilini Elevato. Il tenant deve concedere correttamente l'accesso al provider Basso
Complessità operativa Alto Basso per il provider, maggiore per l'inquilino Più basso
Scenario di esempio Singole istanze dell'applicazione per tenant Chiavi di crittografia gestite dal cliente Soluzione multi-tenant di grandi dimensioni con un livello applicazione condiviso

Insieme di credenziali per tenant, nella sottoscrizione del provider

Si potrebbe considerare di distribuire una cassaforte per ciascun tenant all'interno della sottoscrizione di Azure del provider di servizi. Questo approccio offre un forte isolamento dei dati tra i dati di ogni tenant. Tuttavia, è necessario distribuire e gestire un numero crescente di archivi, man mano che aumenta il numero di tenant.

Non esiste alcun limite al numero di vault che è possibile distribuire in una sottoscrizione di Azure. Tuttavia è consigliabile valutare i seguenti limiti:

Cassaforte per tenant, nella sottoscrizione del tenant

In alcune situazioni, i tenant potrebbero creare volumi sicuri nelle proprie sottoscrizioni di Azure e potrebbero voler concedere all'applicazione l'accesso per gestire segreti, certificati o chiavi. Questo approccio è appropriato quando si consentono chiavi gestite dal cliente (CMK) per la crittografia all'interno della soluzione.

Per accedere ai dati nel vault del tenant, il tenant deve fornire alla tua applicazione l'accesso al proprio vault. Questo processo richiede che l'applicazione esegua l'autenticazione tramite l'istanza di Microsoft Entra. Un approccio consiste nel pubblicare un'applicazione Microsoft Entra multi-tenant. I tuoi inquilini devono effettuare un processo di consenso una tantum. Prima di tutto registrano l'applicazione Microsoft Entra multi-tenant nel proprio ambiente Microsoft Entra. Concedono quindi all'applicazione Microsoft Entra multi-tenant il livello di accesso appropriato all'insieme di credenziali. Devono anche fornire l'ID risorsa completo dell'insieme di credenziali creato. Il codice dell'applicazione può quindi usare un'entità servizio associata all'applicazione Microsoft Entra multi-tenant nel proprio Microsoft Entra ID per accedere all'insieme di credenziali di ogni tenant.

In alternativa, è possibile chiedere a ogni tenant di creare un principale del servizio da usare per il tuo servizio e di fornirti le sue credenziali. Tuttavia, questo approccio richiede di archiviare e gestire le credenziali in modo sicuro per ogni tenant, che è una responsabilità per la sicurezza.

Se i tuoi tenant configurano i controlli di accesso alla rete sulle loro cassette di sicurezza, assicurati di poter accedere alle cassette di sicurezza. Progetta la tua applicazione per gestire le situazioni in cui un tenant modifica i controlli di accesso alla rete e impedisce l'accesso ai suoi archivi.

Cassaforti condivise

È possibile scegliere di condividere i segreti dei tenant all'interno di un singolo caveau. La cassaforte viene distribuita nella tua sottoscrizione di Azure (fornita dal provider di soluzioni) e sei responsabile della sua gestione. Questo approccio è più semplice, ma offre il minor isolamento dei dati e l'isolamento delle prestazioni.

È anche possibile scegliere di implementare più cassette di sicurezza condivise. Ad esempio, se si segue lo schema Deployment Stamps, è probabile che si distribuirà un vault condiviso all'interno di ogni stampo. Analogamente, se si implementa una soluzione multi-regionale, è necessario implementare cassaforti in ogni regione per i motivi che seguono.

  • Per evitare la latenza del traffico tra regioni quando si lavora con i dati nel tuo archivio.
  • Per supportare i requisiti di residenza dei dati.
  • Per abilitare l'uso di vault regionali all'interno di altri servizi che richiedono distribuzioni nella stessa regione.

Quando si lavora con una cassetta di sicurezza condivisa, è importante considerare il numero di operazioni eseguite sulla cassetta stessa. Le operazioni includono la lettura dei segreti e l'esecuzione di operazioni di crittografia o decrittografia. Key Vault impone limiti al numero di richieste che possono essere effettuate su un singolo insieme di credenziali e in tutti gli insiemi di credenziali all'interno di una sottoscrizione di Azure. Assicurati di seguire le linee guida sulla limitazione. È importante seguire le procedure consigliate, inclusa la memorizzazione nella cache sicura dei segreti recuperati e l'uso della crittografia envelope per evitare l'invio di tutte le operazioni di crittografia a Key Vault. Quando si seguono queste best practice, è possibile eseguire soluzioni su larga scala in un singolo caveau.

Se è necessario archiviare segreti, chiavi o certificati specifici del tenant, è consigliabile usare una convenzione di denominazione come un prefisso di denominazione. Ad esempio, è possibile anteporre l'ID del tenant al nome di ogni segreto. Il codice dell'applicazione può quindi caricare facilmente il valore di un segreto specifico per un tenant specifico.

Funzionalità di Azure Key Vault che supportano la multi-tenancy

Tag

Key Vault supporta l'assegnazione di tag a segreti, certificati e chiavi con metadati personalizzati, quindi è possibile usare un tag per tenere traccia dell'ID tenant per ogni segreto specifico del tenant. Tuttavia, Key Vault non supporta l'esecuzione di query in base ai tag, quindi questa funzionalità è più adatta per scopi di gestione, anziché per l'uso all'interno della logica dell'applicazione.

Ulteriori informazioni:

Supporto di Criteri di gruppo

Se si decide di distribuire un numero elevato di insiemi di credenziali, è importante assicurarsi che seguano uno standard coerente per la configurazione, la registrazione e il controllo di accesso alla rete. È consigliabile usare Criteri di Azure per verificare che gli insiemi di credenziali siano stati configurati in base alle esigenze.

Ulteriori informazioni:

HSM gestito e HSM dedicato

Se è necessario eseguire un numero elevato di operazioni al secondo e i limiti delle operazioni di Key Vault non sono sufficienti, è consigliabile usare HSM gestito o HSM dedicato. Entrambi i prodotti offrono una quantità riservata di capacità, ma in genere sono più costose di Key Vault. Tenere inoltre presente i limiti relativi al numero di istanze di questi servizi che è possibile distribuire in ogni area.

Ulteriori informazioni:

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

Esaminare gli approcci di distribuzione e configurazione per la multi-tenancy.