Multi-tenancy e File di Azure

File di Azure fornisce condivisioni file gestite che le soluzioni multi-tenant possono usare per archiviare i dati del tenant. Questo articolo descrive i modelli di isolamento e le funzionalità di File di Azure per le soluzioni multi-tenant. Fornisce collegamenti a linee guida che consentono di pianificare come isolare i file dei tenant e gestire l'accesso, la crittografia e l'utilizzo.

Modelli di isolamento

Quando si usa File di Azure in un sistema multi-tenant, determinare il livello di isolamento da applicare. È possibile condividere condivisioni file, creare condivisioni file per ogni tenant all'interno di un account di archiviazione o usare risorse dedicate per ogni tenant. Scegliere i controlli di accesso e i modelli di isolamento che corrispondono al protocollo e al provider di risorse usato. La tabella seguente riepiloga le differenze tra i principali modelli di isolamento della tenancy per le condivisioni di file all'interno degli account di archiviazione. Per un'alternativa che non richiede account di archiviazione, vedere Condivisioni file come risorse autonome.

Condivisioni di file condivisi

Quando si usano condivisioni file, è possibile usare una condivisione file condivisa che include percorsi di file per separare i dati per ogni tenant.

I percorsi dei file identificano i dati di ogni tenant, ma non garantiscono l'isolamento da soli. Prendere in considerazione gli approcci di isolamento in base al modo in cui le applicazioni accedono ai dati nella condivisione:

• Per l'accesso SMB (Server Message Block), applicare autorizzazioni a livello di condivisione e autorizzazioni di directory o file per limitare l'accesso di ogni tenant.
• Per l'accesso FileREST, rilasciare token di firma di accesso condiviso con ambito alle risorse appropriate o applicare l'isolamento nell'applicazione.
• Per l'accesso NFS, non fare affidamento sulle directory del tenant o sulle condivisioni separate all'interno di un account di archiviazione per isolare i client controllati dal tenant e reciprocamente non attendibili. NFS usa controlli di accesso a livello di rete anziché l'autenticazione basata sull'utente. Le condivisioni Classic condividono regole di rete a livello di account. Instradare l'accesso tramite un livello applicazione attendibile o usare account di archiviazione separati o condivisioni autonome con restrizioni di rete specifiche del tenant.

Quando si usano condivisioni file condivise, valutare se è necessario tenere traccia dei dati e dell'utilizzo per ogni tenant. Per altre informazioni, vedere Monitoraggio.

Condivisioni file per ogni tenant

È possibile creare singole condivisioni file per ogni tenant all'interno di un singolo account di archiviazione. Per questo scenario, usare il controllo di accesso di File di Azure per gestire l'accesso ai dati di ogni tenant. Scegliere l'autorizzazione basata sull'identità per SMB o l'accesso con ambito per FileREST. È anche possibile monitorare la capacità usata da ogni condivisione file.

Per le condivisioni file SSD, il modello v2 preallocato consente di effettuare il provisioning di risorse di archiviazione, operazioni di I/O al secondo e velocità effettiva in modo indipendente per ogni condivisione. Questa funzionalità migliora l'isolamento delle prestazioni tra i tenant perché l'attività di un tenant non consuma il throughput di cui si effettua il provisioning per la quota di un altro tenant. Supporta anche il rilevamento dei costi per tenant perché File di Azure fattura ogni condivisione per la capacità di cui è stato effettuato il provisioning.

Account di archiviazione per ogni tenant

Un account di archiviazione dedicato per ogni tenant isola le chiavi dell'account di archiviazione, che possono essere rigenerate a rotazione in modo indipendente. Consente anche di ridimensionare la soluzione oltre i limiti e le quote per ogni account di archiviazione. È tuttavia necessario considerare anche il numero massimo di account di archiviazione consentiti all'interno di una singola sottoscrizione di Azure.

Condivisioni file come risorse autonome

È possibile creare una condivisione file come risorsa di primo livello autonoma Azure usando il Microsoft.FileShares provider di risorse, che distribuisce una condivisione senza un account di archiviazione. Ogni condivisione ha le proprie impostazioni di prestazioni, ridondanza, rete e fatturazione, in modo da isolare i tenant senza gestire i limiti dell'account di archiviazione condiviso. Prendere in considerazione il numero di condivisioni file che è possibile distribuire per ogni sottoscrizione in ogni area quando si valuta questo modello.

Questo provider di risorse supporta attualmente solo condivisioni SSD NFS 4.1 che usano il modello di fatturazione provisioned v2 e non supporta il protocollo SMB. Se i tenant necessitano dell'accesso SMB, delle opzioni descritte in Controllo degli accessi in base all'identità o di archiviazione HDD, usa invece le condivisioni file all'interno di un account di archiviazione. Per l'elenco completo delle differenze, vedere Confronto tra i provider Microsoft.Storage e Microsoft.FileShares.

Funzionalità di File di Azure che supportano la multi-tenancy

Le funzionalità di File di Azure seguenti consentono di implementare e gestire il modello di isolamento scelto.

Firme di accesso condiviso

Quando si accede File di Azure tramite l'API FileREST, valutare se instradare le richieste client tramite il livello applicazione o consentire ai client di connettersi direttamente a una condivisione file. L'accesso client diretto può ridurre il carico sulle applicazioni back-end e il numero di hop di rete.

Una firma di accesso condiviso (SAS) consente di fornire alle applicazioni client l'accesso limitato alle condivisioni file o ai singoli file. È possibile limitare le operazioni che un client può eseguire e il periodo di tempo in cui è consentito l'accesso. L'autorizzazione sas si applica alle richieste FileREST, non all'accesso SMB o NFS.

Usare il modello Valet Key per rilasciare token SAS vincolati e con ambito dal tier applicazione. Autenticare il client usando il sistema di autenticazione dell'applicazione, determinare a quali file del tenant può accedere e rilasciare un token solo per le risorse e le operazioni necessarie.

I criteri di accesso memorizzati consentono di definire un singolo criterio da usare quando si rilasciano più token di firma di accesso condiviso del servizio. I criteri di accesso archiviati non si applicano ai token di firma di accesso condiviso della delega utente o ai token di firma di accesso condiviso dell'account.

Firma di accesso condiviso con delega utente

Un SAS del servizio o un SAS dell'account di archiviazione è firmato con una delle chiavi dell'account di archiviazione. Una firma di accesso condiviso (SAS) con delega utente è invece protetta con credenziali Microsoft Entra. Il livello applicazione richiede una chiave di delega utente usando la propria identità gestita, quindi firma i token con ambito limitato al tempo per ogni tenant. Non si distribuiscono o si archiviano le chiavi dell'account. Microsoft consiglia di usare una SAS di delega utente anziché una SAS con chiave dell'account quando la progettazione lo supporta.

Usare durate di token brevi e pianificare come revocare l'accesso se un token viene compromesso. Per correlare i log dell'applicazione con i log di File di Azure, impostare un ID richiesta client (x-ms-client-request-id) nelle richieste FileREST e registrarlo insieme all'ID tenant.

Controllo degli accessi in base all'identità

Quando l'applicazione comunica tramite il protocollo SMB, File di Azure supporta l'autorizzazione basata su identità sia a livello di condivisione che a livello di directory o file.

È possibile usare Active Directory Domain Services locale, Microsoft Entra Domain Services o Microsoft Entra Kerberos per le identità ibride e solo cloud. Usando Microsoft Entra Kerberos, le identità solo cloud possono accedere a una condivisione senza un controller di dominio, eliminando la dipendenza dall'ambiente locale quando si autorizzano gli utenti di ogni tenant. Ogni account di archiviazione supporta solo una di queste origini di identità e si applica a tutte le condivisioni file nell'account. Se i tenant richiedono provider di identità diversi, isolare i tenant in account di archiviazione separati.

Encryption

File di Azure crittografa i dati a riposo con chiavi gestite da Microsoft per impostazione predefinita. Per le condivisioni file all'interno di un account di archiviazione, è possibile usare chiavi gestite dal cliente. Se ogni tenant richiede una chiave di crittografia separata, usare account di archiviazione separati perché la chiave viene applicata a livello di account.

Le condivisioni file create tramite il Microsoft.FileShares provider di risorse usano chiavi gestite da Microsoft e non supportano le chiavi gestite dal cliente. Prendere in considerazione queste differenze quando si seleziona un modello di isolamento e si pianifica il ciclo di vita del tenant.

Monitoring

In una soluzione multi-tenant valutare se è necessario misurare il consumo per ogni tenant. Definire le metriche specifiche di cui tenere traccia, ad esempio la capacità di archiviazione usata da ogni tenant o il numero di operazioni eseguite per i file di ogni tenant. È anche possibile usare l'allocazione dei costi per tenere traccia del costo dell'utilizzo di ogni tenant e abilitare il chargeback tra più sottoscrizioni.

File di Azure offre funzionalità di monitoraggio predefinite. È possibile visualizzare la capacità per ogni condivisione, ma non per ogni cartella. Se i tenant condividono una condivisione file, pianificate come misurare l'utilizzo per ogni tenant.

È possibile raccogliere i log delle richieste, quindi aggregarli e analizzarli per ogni tenant. Verificare quali operazioni vengono registrate dal protocollo e dal provider di risorse. Nelle soluzioni che creano volumi elevati di richieste, valutare se il vantaggio giustifica il costo per acquisire ed elaborare tali log.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Altri contributori:

• Dr. Christian Geuer-Pollmann | Principal Customer Engineer, FastTrack per Azure
• Patrick Horn | Senior Customer Engineering Manager, FastTrack per Azure
• Ben Hummerstone | Principal Customer Engineer, FastTrack for Azure
• Vic Perdana | Cloud Solution Architect, Azure ISV
• Daniel Scott-Raynsford | Partner Solution Architect, Data & AI
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack per Azure

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

Risorse correlate

• Approcci di archiviazione e dati per la multi-tenancy
• Procedure consigliate per l'architettura per File di Azure
• Multi-tenancy e Archiviazione BLOB di Azure
• Multi-tenancy e archiviazione code di Azure
• Multi-tenancy e Archiviazione tabelle di Azure