Net-Point All articles
Cloud & Infrastruttura

Multi-tenancy nel cloud: come scegliere tra isolamento logico e segregazione fisica per tutelare i dati dei clienti

Net-Point
Multi-tenancy nel cloud: come scegliere tra isolamento logico e segregazione fisica per tutelare i dati dei clienti

La crescita dei modelli SaaS e delle piattaforme cloud condivise ha reso il concetto di multi-tenancy uno dei temi centrali nell'architettura delle infrastrutture digitali moderne. Eppure, nonostante la sua diffusione capillare, la scelta tra isolamento logico e segregazione fisica rimane una decisione strategica che molte aziende italiane affrontano con strumenti inadeguati o, peggio, senza una reale consapevolezza dei rischi connessi.

In questo articolo affrontiamo il problema da una prospettiva operativa: non si tratta di scegliere la soluzione «più sicura» in astratto, ma di identificare il modello più adatto al proprio contesto, bilanciando costi, requisiti normativi e profilo di rischio.


Che cosa si intende davvero per multi-tenancy

Nel mondo dell'infrastruttura cloud, il termine multi-tenancy descrive la capacità di un sistema di servire più clienti (tenant) distinti su una stessa piattaforma condivisa. Le risorse fisiche — server, storage, rete — vengono messe in comune, mentre meccanismi software garantiscono che ciascun tenant acceda esclusivamente ai propri dati e configurazioni.

Questa architettura è alla base di quasi tutti i servizi cloud pubblici e di molte applicazioni SaaS. Il vantaggio economico è evidente: la condivisione delle risorse riduce i costi operativi e consente economie di scala che i modelli dedicati non possono replicare.

Tuttavia, l'efficienza ha un prezzo: la sicurezza e la separazione dei dati dipendono interamente dalla solidità dei meccanismi di isolamento implementati.


Isolamento logico: flessibilità a costo di una fiducia implicita

L'isolamento logico è il modello predominante nei cloud pubblici e nelle architetture SaaS mature. I dati di tenant diversi risiedono sugli stessi sistemi fisici, ma vengono separati attraverso costrutti software: namespace, VLAN, policy IAM, database condivisi con row-level security, container orchestrati su cluster comuni.

I vantaggi sono concreti:

I rischi, tuttavia, non vanno sottovalutati. L'isolamento logico introduce una dipendenza critica dalla correttezza del software: un bug nel livello di autorizzazione, una misconfiguration nelle policy, un exploit nel runtime dei container — tutti questi vettori possono portare a fughe di dati tra tenant (tenant data leakage). Episodi di questo tipo non sono rari nella storia recente del cloud, e le conseguenze legali in ambito GDPR possono essere significative.

Per le aziende italiane che trattano dati personali di clienti o utenti finali, questo aspetto non è trascurabile: il Regolamento Europeo impone che i dati siano protetti «by design and by default», e un incidente di cross-tenant exposure può configurare una violazione grave con obbligo di notifica al Garante entro 72 ore.


Segregazione fisica: garanzie solide, oneri elevati

La segregazione fisica — o hard multi-tenancy — prevede che ciascun tenant disponga di risorse hardware dedicate: server propri, storage separato, segmenti di rete fisicamente distinti. In alcuni casi si parla di interi datacenter o zone geografiche riservate a un singolo cliente o categoria di clienti.

Questo modello è tipico dei cloud privati dedicati, delle offerte single-tenant dei principali provider (come AWS Dedicated Hosts o Azure Dedicated Hosts), e degli ambienti regolamentati in settori come quello finanziario, sanitario o della difesa.

I benefici in termini di sicurezza sono tangibili:

Il rovescio della medaglia è altrettanto evidente: i costi operativi aumentano in modo significativo, la scalabilità richiede tempi più lunghi, e la gestione di ambienti multipli e separati impone un carico ingegneristico non trascurabile.


Come decidere: una guida basata sul profilo di rischio

Non esiste una risposta universale. La scelta tra isolamento logico e segregazione fisica deve essere guidata da quattro variabili fondamentali.

1. Natura e sensibilità dei dati trattati

Dati sanitari, dati finanziari, informazioni legali o dati relativi a minori richiedono standard di protezione più elevati. In questi casi, la segregazione fisica — o quantomeno un isolamento logico rinforzato con cifratura per-tenant e gestione delle chiavi separata — è quasi sempre la scelta corretta.

2. Requisiti normativi e contrattuali

Se i clienti che si ospitano appartengono a settori regolamentati, è probabile che i loro contratti o i loro audit interni richiedano garanzie specifiche sull'isolamento. Prima di scegliere un'architettura, è opportuno raccogliere questi requisiti e verificarli con il proprio team legale e di compliance.

3. Modello di business e volume dei tenant

Una piattaforma SaaS con centinaia di micro-clienti non può permettersi la segregazione fisica per ogni account: i costi sarebbero proibitivi. In questo caso, un isolamento logico ben progettato, con penetration testing regolari e audit del codice, rappresenta il compromesso più ragionevole. Viceversa, un provider che gestisce pochi clienti enterprise con volumi di dati elevati può trovare nella segregazione fisica un argomento commerciale differenziante.

4. Capacità interna di gestione del rischio

Un isolamento logico sicuro richiede competenze specifiche: gestione delle policy IAM, hardening dei container, monitoraggio delle anomalie di accesso, revisione continua delle configurazioni. Se queste competenze non sono disponibili internamente, o se il team IT è sottodimensionato, affidarsi a un modello fisicamente segregato — magari gestito da un provider specializzato — può ridurre la superficie di rischio complessiva.


Il ruolo della cifratura come livello intermedio

Esiste una terza via che molte architetture moderne adottano come complemento all'isolamento logico: la cifratura per-tenant con gestione delle chiavi separata. In questo modello, i dati di ciascun tenant vengono cifrati con chiavi crittografiche distinte, gestite attraverso sistemi come AWS KMS, Azure Key Vault o HashiCorp Vault.

Anche in caso di accesso non autorizzato ai dati grezzi — per esempio a seguito di una misconfiguration — un attaccante si troverebbe di fronte a dati illeggibili senza le chiavi del tenant specifico. Questo approccio non elimina il rischio di cross-tenant exposure a livello applicativo, ma riduce drasticamente l'impatto di un eventuale incidente.

È una soluzione particolarmente adatta per chi vuole mantenere i vantaggi economici del multi-tenancy logico, aggiungendo uno strato di garanzia crittografica che può essere documentato e presentato ai clienti come misura di sicurezza concreta.


Conclusioni: la sicurezza si progetta, non si improvvisa

La multi-tenancy non è intrinsecamente sicura o insicura: è un'architettura che richiede scelte consapevoli, documentate e verificate nel tempo. Per le aziende italiane che operano come provider di servizi digitali — che si tratti di hosting, SaaS, piattaforme di gestione documentale o applicazioni verticali — la responsabilità verso i dati dei propri clienti è insieme un obbligo normativo e un elemento di reputazione commerciale.

Investire nella progettazione corretta dell'isolamento tra tenant, scegliere il modello giusto in base al contesto e documentare le scelte architetturali non è un esercizio teorico: è una delle fondamenta su cui costruire un'infrastruttura digitale affidabile e competitiva.

Se stai valutando come strutturare la tua infrastruttura multi-tenant o hai necessità di un'analisi del tuo ambiente attuale, il team di Net-Point è a disposizione per supportarti in ogni fase del percorso.

All Articles

Related Articles

Audit infrastrutturali nella PA: sfruttare i tool cloud nativi per automatizzare la conformità

Audit infrastrutturali nella PA: sfruttare i tool cloud nativi per automatizzare la conformità

Sprawl infrastrutturale: riconoscere il problema prima che il budget diventi ingestibile

Sprawl infrastrutturale: riconoscere il problema prima che il budget diventi ingestibile

Policy-as-Code: integrare la conformità normativa nel ciclo di vita dell'infrastruttura senza frenare l'innovazione

Policy-as-Code: integrare la conformità normativa nel ciclo di vita dell'infrastruttura senza frenare l'innovazione