Architettura multi-tenant SaaS: modelli, rischi e come sceglierla

Tenant

Il cliente di un SaaS inteso come unità di isolamento: un'organizzazione con i suoi utenti, dati e impostazioni. Nel B2B di solito è un'azienda; nel B2C può essere una persona, una famiglia o un gruppo, come nota la guida di Microsoft ai modelli di tenancy.

Cos'è un'architettura multi-tenant, in pratica?

In pratica è un'applicazione sola che sa sempre per conto di quale cliente sta lavorando. Ogni richiesta porta con sé l'identità del tenant, e ogni lettura o scrittura di dati è limitata a quel tenant.

Il contrario è il single-tenant: un'installazione separata per ogni cliente. È più facile da capire, ma ogni nuovo cliente è un'altra copia da aggiornare, monitorare e pagare. La guida di Microsoft lo riassume così: se un tenant richiede un certo costo di infrastruttura, cento tenant probabilmente costano cento volte tanto.

Quali sono i modelli di architettura multi-tenant?

I modelli sono tre, silo, pool e bridge, secondo la terminologia della SaaS Lens di AWS. Cambia quanto condividono i clienti, e con questo costi, isolamento e complessità operativa.

AWS sottolinea un punto che spesso si perde: anche nel modello silo identità, onboarding e gestione restano condivisi. È questo che distingue un SaaS da un servizio gestito con un'installazione diversa, e un processo diverso, per ogni cliente.

Come si isolano i dati tra un cliente e l'altro?

Si isolano a più livelli insieme: nel codice, nel database e nei test. Nessun livello da solo basta, perché ognuno può contenere un errore.

Nel codice

Ogni tabella con dati di clienti ha una colonna con l'identificativo del tenant, e il tenant della richiesta lo stabilisce il server a partire dall'utente autenticato, mai un parametro che arriva dal browser. Le query passano da un unico punto che aggiunge sempre il filtro, invece di affidarsi alla memoria di chi scrive ciascuna query.

Nel database

PostgreSQL permette una seconda rete di sicurezza con le politiche di sicurezza a livello di riga (Row-Level Security): è il database stesso a restituire solo le righe del tenant corrente. Un dettaglio della documentazione da non perdere: superuser e ruoli con l'attributo BYPASSRLS le ignorano sempre, e anche il proprietario della tabella di norma le scavalca, a meno di attivare FORCE ROW LEVEL SECURITY.

Nei test

Per ogni operazione sensibile serve un test automatico che provi a leggere o modificare i dati di un altro tenant e verifichi che fallisca. La guida Microsoft è esplicita: qualunque modello scegli, va verificato che i dati di un cliente non finiscano per sbaglio a un altro.

Tra gli esempi che OWASP descrive c'è proprio il caso tipico del multi-tenant fatto male: vedere o modificare l'account di qualcun altro cambiando un identificativo nella richiesta. Per questo l'isolamento non si affida a un'unica riga di codice.

Cos'è il problema del vicino rumoroso?

È quando un cliente consuma così tante risorse da rallentare gli altri che le condividono. Succede soprattutto nel modello pool: un'esportazione enorme, un'integrazione che chiama l'API migliaia di volte, una query pesante nell'ora di punta.

Le difese sono note: limiti di utilizzo per tenant, code per i lavori lunghi, indici pensati per le query filtrate per cliente e la possibilità di spostare un cliente pesante su risorse dedicate, cioè passare al modello bridge solo per lui. Può diventare anche un'offerta: Microsoft nota che si può far pagare di più chi vuole risorse isolate, tema che riprendiamo nella guida al pricing SaaS.

Quale modello scegliere per un SaaS early stage?

Per quasi tutti i SaaS early stage la scelta sensata è il pool, con isolamento rigoroso e la porta aperta al bridge. Costa meno, si gestisce come un unico ambiente e ti lascia imparare in fretta dai clienti.

Il silo ha senso dall'inizio solo se i clienti lo chiedono per contratto, per esempio in settori regolati, o se sono pochi e molto grandi. Come scrive Microsoft, scegliere il modello non è solo una decisione tecnica ma anche commerciale. Le basi tecniche, dal database al framework, sono nella guida allo stack tecnologico per startup.

Cosa cambia con il GDPR in un SaaS multi-tenant?

Nei principi cambia poco, nella pratica molto: se tratti dati personali per conto dei clienti, devi poter dimostrare che i dati di uno non sono accessibili agli altri. L'articolo 32 del Regolamento (UE) 2016/679 chiede misure di sicurezza adeguate al rischio, inclusa la capacità di ripristinare dati e accesso dopo un incidente; l'articolo 28 regola il contratto con chi tratta dati per conto di altri.

In concreto, un buon design multi-tenant rende facili tre richieste tipiche: esportare tutti i dati di un cliente, cancellarli alla fine del contratto, dire dove sono ospitati. Per gli aspetti legali del tuo caso serve un consulente privacy.

Come verifichi che l'isolamento tra clienti regga?

Lo verifichi con una lista di controlli da ripetere a ogni modifica importante. Questa è la nostra, pensata per un modello pool su database relazionale.

1. Ogni tabella con dati di clienti ha l'identificativo del tenant, indicizzato.
2. Il tenant lo determina il server dalla sessione, mai il client.
3. Le query passano da un livello di accesso ai dati che aggiunge sempre il filtro.
4. Le tabelle più sensibili hanno una seconda difesa nel database, per esempio Row-Level Security.
5. Test automatici provano ad accedere ai dati di un altro tenant, e devono fallire.
6. File, code di lavori, cache e log sono separati per tenant, non solo il database.
7. Ci sono limiti di utilizzo per tenant contro i vicini rumorosi.
8. Esportazione e cancellazione dei dati di un singolo cliente sono state provate davvero.
9. Backup e ripristino sono provati, e sai cosa vuol dire ripristinare un solo cliente.

Se stai ancora definendo il prodotto, questa lista si inserisce nelle fondamenta descritte in come creare un SaaS.