Multi-tenancy e Azure Key Vault
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 utili per pianificare l'uso dell'insieme di credenziali delle chiavi.
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 applicazione tra più tenant, si distribuiscono istanze di applicazioni a tenant singolo o si distribuiscono indicatori di distribuzione separati per ogni tenant?
- I tenant devono gestire le proprie chiavi di crittografia?
- I tenant hanno requisiti di conformità che richiedono che i segreti vengano archiviati separatamente dai segreti di altri tenant?
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 | Insieme di credenziali per tenant, nella sottoscrizione del tenant | Insieme di credenziali condiviso |
|---|---|---|---|
| Isolamento dei dati | Alto | Molto alto | Basso |
| Isolamento delle prestazioni | Medio. La velocità effettiva elevata potrebbe essere limitata, anche con molti insiemi di credenziali | Alto | Basso |
| Complessità della distribuzione | Medio-basso, a seconda del numero di tenant | Elevato. Il tenant deve concedere correttamente l'accesso al provider | Basso |
| Complessità operativa | Alto | Basso per il provider, maggiore per il tenant | 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
È possibile valutare la possibilità di distribuire un insieme di credenziali per ogni tenant all'interno della sottoscrizione di Azure (il 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 insiemi di credenziali, man mano che si aumenta il numero di tenant.
Non esiste alcun limite al numero di insiemi di credenziali che è possibile distribuire in una sottoscrizione di Azure. Tuttavia è consigliabile valutare i seguenti limiti:
- Esistono limiti a livello di sottoscrizione per il numero di richieste che è possibile effettuare entro un periodo di tempo. Questi limiti si applicano indipendentemente dal numero di insiemi di credenziali nella sottoscrizione. È quindi importante seguire le linee guida sulla limitazione, anche quando sono presenti insiemi di credenziali specifici del tenant.
- Esiste un limite al numero di assegnazioni di ruolo di Azure che è possibile creare all'interno di una sottoscrizione. Quando si distribuisce e si configura un numero elevato di insiemi di credenziali in una sottoscrizione, è possibile avvicinarsi a questi limiti.
Insieme di credenziali per tenant, nella sottoscrizione del tenant
In alcune situazioni, i tenant potrebbero creare insiemi di credenziali nelle proprie sottoscrizioni di Azure e potrebbero voler concedere all'applicazione l'accesso per lavorare con 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 nell'insieme di credenziali del tenant, il tenant deve fornire all'applicazione l'accesso all'insieme di credenziali. 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 tenant devono eseguire un processo di consenso una tantum. Prima di tutto registrano l'applicazione Microsoft Entra multi-tenant nel proprio tenant 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'entità servizio da usare per il servizio e di specificarne le 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 tenant configurano i controlli di accesso alla rete negli insiemi di credenziali, assicurarsi di poter accedere agli insiemi di credenziali. Progettare l'applicazione per gestire le situazioni in cui un tenant modifica i controlli di accesso alla rete e impedisce l'accesso agli insiemi di credenziali.
Insiemi di credenziali condivisi
È possibile scegliere di condividere i segreti dei tenant all'interno di un singolo insieme di credenziali. L'insieme di credenziali viene distribuito nella sottoscrizione di Azure (il provider di soluzioni) e si è responsabili della gestione. Questo approccio è più semplice, ma offre il minor isolamento dei dati e l'isolamento delle prestazioni.
È anche possibile scegliere di distribuire più insiemi di credenziali condivise. Ad esempio, se si segue lo schema Deployment Stamps, è probabile che si distribuirà un insieme di credenziali condiviso all'interno di ogni stamp. Analogamente, se si distribuisce una soluzione in più aree, è necessario distribuire insiemi di credenziali in ogni area per i motivi seguenti:
- Per evitare la latenza del traffico tra aree quando si lavora con i dati nell'insieme di credenziali.
- Per supportare i requisiti di residenza dei dati.
- Per abilitare l'uso di insiemi di credenziali a livello di area all'interno di altri servizi che richiedono distribuzioni della stessa area.
Quando si usa un insieme di credenziali condiviso, è importante considerare il numero di operazioni eseguite nell'insieme di credenziali. 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. Assicurarsi 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 procedure consigliate, è possibile eseguire soluzioni su larga scala in un singolo insieme di credenziali.
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 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:
- Integrare Azure Key Vault con Criteri di Azure
- Definizioni predefinite di Criteri di Azure per Key Vault
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:
- Come si decide se usare Azure Key Vault o HSM dedicato di Azure?
- HSM dedicato di Azure è la scelta giusta?
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- John Downs | Principal Software Engineer
Altri contributori:
- Jack Lichwa | Principal Product Manager, Azure Key Vault
- Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
Esaminare gli approcci di distribuzione e configurazione per la multi-tenancy.