L’isolamento dei tenant è una disciplina di muri dentro i sistemi condivisi: controlli che tengono ogni tenant sigillato rispetto a tutti gli altri. Il punto che la maggior parte delle spiegazioni seppellisce merita il primo paragrafo: l’isolamento non è autenticazione né autorizzazione. Un utente perfettamente autenticato, con il ruolo giusto, può comunque leggere i dati di un concorrente se nulla limita la query al suo tenant – l’isolamento è il terzo livello, quello che decide nell’universo di chi avviene ogni operazione.
Punti chiave
| Domanda | Risposta |
|---|---|
| Che cos’è | Le garanzie che nessun tenant possa raggiungere dati o risorse di un altro |
| Da non confondere con | L’autenticazione (chi) e l’autorizzazione (che cosa) – l’isolamento è di chi |
| Dove vanno i muri | Righe del database, cache, code, archiviazione, token – ogni livello condiviso |
| La modalità di guasto | Una query, un job o una chiave di cache senza portata di tenant = fuga di dati fra tenant |
| Lo standard | Applicare nel livello dati; testare in modo avversariale; mai fidarsi degli ID di tenant inviati dal client |
Il bug, e il muro che gli sopravvive
-- Il bug a cui l'isolamento deve sopravvivere: una query che ha dimenticato il tenant
SELECT * FROM invoices WHERE id = $1; -- restituisce la fattura di chiunque
-- Con il muro nel livello dati, lo stesso bug non restituisce nulla:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_wall ON invoices
USING (tenant_id = current_setting('app.tenant')::uuid);Nei database documentali il muro si costruisce con i ruoli e il controllo degli accessi per oggetto – il tenant è un ruolo, e ogni riga gli viene sigillata al momento della scrittura:
// JavaScript / Node.js — Back4app JS SDK
// Provisioning a tenant boundary: a role is the tenant, membership is access
const tenantRole = new Parse.Role('tenant-acme', new Parse.ACL());
tenantRole.getUsers().add(adminUser);
await tenantRole.save();
// Every acme row from now on: readable and writable by the role only
const doc = new Parse.Object('Project', { name: 'Q3 Launch' });
const acl = new Parse.ACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// Flutter / Dart — Back4app Flutter SDK
// Every tenant row: readable and writable by the tenant role only
final acl = ParseACL();
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
final doc = ParseObject('Project')
..set('name', 'Q3 Launch')
..setACL(acl);
await doc.save(); // invisible to every other tenant, enforced server-side// iOS / Swift — Back4app Swift SDK
// Every tenant row: readable and writable by the tenant role only
var acl = ParseACL()
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
var doc = Project()
doc.name = "Q3 Launch"
doc.ACL = acl
doc.save { _ in } // invisible to every other tenant, enforced server-side// Android / Kotlin — Back4app Android SDK
// Every tenant row: readable and writable by the tenant role only
val acl = ParseACL().apply {
setRoleReadAccess("tenant-acme", true)
setRoleWriteAccess("tenant-acme", true)
}
val doc = ParseObject("Project").apply {
put("name", "Q3 Launch")
setACL(acl)
}
doc.saveInBackground() // invisible to every other tenant, enforced server-sideLo stack di applicazione delle regole
Ogni livello raccoglie ciò che quello sopra lascia cadere: il token stabilisce l’identità del tenant lato server, il codice applicativo limita la portata per abitudine, il livello dati fa rispettare la regola per policy, e l’infrastruttura mette sotto namespace tutto il resto di ciò che è condiviso. La cheat sheet di OWASP è la checklist di riferimento per l’intero stack.
Isolamento vs. autenticazione vs. autorizzazione
| Domanda a cui risponde | Meccanismo | Come si presenta il guasto |
|---|---|---|
| Chi è l’utente? (autenticazione) | Accesso, sessioni, token | Entra un impostore |
| Che cosa può fare? (autorizzazione) | Ruoli, permessi | Un utente eccede il proprio ruolo |
| Di chi sono questi dati? (isolamento) | Portata di tenant + muri nel livello dati | Un utente legittimo legge un altro tenant |
La terza riga è quella che finisce sui titoli dei giornali, perché passa tutti i test definiti dalle prime due: chi attacca accede in modo legittimo, usa operazioni consentite – e attraversa un muro mancante. Le vulnerabilità fra tenant emblematiche dell’era del cloud (la classe di risultati di ricerca nota come ChaosDB, dove un tenant poteva ricavare l’accesso ai database degli altri) erano tutte guasti della terza riga, in sistemi con prima e seconda riga impeccabili.
Da dove arrivano davvero le fughe di dati
- Il filtro dimenticato – una query senza la propria portata di tenant; il motivo per cui i muri appartengono al livello dati, non alla memoria di chi sviluppa.
- L’IDOR – ID sequenziali o indovinabili recuperati senza controlli sul tenant; basta scambiare un ID per leggere il record di uno sconosciuto.
- L’esecuzione fuori contesto – job in background, webhook, attività pianificate ed export di dati eseguiti con credenziali troppo ampie e senza contesto di tenant.
- I servizi condivisi senza portata – chiavi di cache, indici di ricerca e percorsi dei file senza il prefisso del tenant; il muro del database tiene mentre la cache perde.
- Le pipeline parallele – analytics e reporting che leggono direttamente il database, al di sotto di ogni controllo applicativo.
- Il tenant affidato al client – un ID di tenant accettato dal corpo della richiesta invece di essere derivato dalla sessione; il modo più cortese possibile di distribuire i dati degli altri tenant.
Isolamento di sicurezza vs. noisy neighbor
Stessa parola, due problemi. L’isolamento di sicurezza tiene il tenant A fuori dai dati del tenant B. L’isolamento di prestazioni – il problema del noisy neighbor, il vicino rumoroso – tiene l’import massivo del tenant A fuori dalla latenza del checkout del tenant B; si risolve con quote, rate limiting e partizionamento, ed è trattato sul lato architetturale di questo tema. Un sistema può essere a tenuta stagna e lasciare comunque che un tenant affami gli altri; conviene mettere a budget entrambi, e non lasciare che una discussione sulle quote si spacci per una revisione di sicurezza.
Come si testa l’isolamento dei tenant
La passata avversariale a due tenant, automatizzata in CI: si creano i tenant A e B, poi si tenta ogni incrocio – gli ID degli oggetti di B attraverso la sessione di A su ogni endpoint (la scansione IDOR), il token di A contro le risorse di B, le superfici fuori dal percorso principale (export, pannelli di amministrazione, job) con il contesto di ciascun tenant, e un’ispezione delle chiavi di cache, delle URL dei file e dei risultati di ricerca in cerca di una portata di tenant mancante. Va aggiunto il caso del contesto non impostato: nessun tenant nella sessione deve significare nessuna riga, mai tutte le righe. Un isolamento che non è stato attaccato in CI è un’ipotesi munita di un certificato di conformità.
Casi d’uso tipici
- SaaS B2B. Ogni workspace è un tenant; l’isolamento è la promessa di prodotto sotto ogni feature.
- Piattaforme che ospitano app dei clienti. Due altitudini insieme – la piattaforma isola le app l’una dall’altra, ogni app isola i propri tenant.
- Offerte enterprise e settori regolamentati. Requisiti contrattuali di isolamento tradotti in muri più solidi – chiavi per tenant, risorse dedicate – per gli account che ne hanno bisogno.
- Agenzie e prodotti in white label. Un solo deployment, molte organizzazioni clienti, ciascuna sigillata.
- Piattaforme interne multi-team. I reparti come tenant; modello di minaccia più clemente, meccanica identica.
Quanto isolamento? Matrice decisionale
| Modello pool + muri nel livello dati quando… | Separazione più forte quando… |
|---|---|
| Molti tenant piccoli, sensibilità standard | I contratti nominano requisiti di isolamento |
| Il costo per tenant deve restare vicino a zero | I dati di un tenant esigono chiavi o regione proprie |
| I muri sono applicati (RLS/ACL) e testati | Gli argomenti sul raggio d’impatto battono l’economia della densità |
| Un solo ciclo di aggiornamento deve coprire tutti | Il ripristino per singolo tenant è una feature promessa |
| Il team riesce a mantenere test avversariali | I revisori vogliono confini da poter indicare |
L’inquadramento onesto: un modello pool con muri applicati e testati è isolamento legittimo – su questo gira la maggior parte del settore. Conviene far salire i singoli tenant sulla scala della separazione quando lo chiedono i loro requisiti, non la moda.
Limiti e trade-off
- L’isolamento è trasversale per sempre. Ogni nuova feature – cache, coda, export, ricerca – ripone la domanda sul tenant; la disciplina non finisce mai.
- I muri nel livello dati hanno le loro clausole in piccolo operative. Contesto di sessione vs. pooling delle connessioni, ruoli di aggiramento delle policy e modalità di dump – la voce sulla sicurezza a livello di riga li raccoglie.
- Il raggio d’impatto condiviso sopravvive alla correttezza. Un isolamento logico perfetto condivide comunque i domini di guasto – un deployment sbagliato tocca ogni tenant; solo la separazione fisica cambia questo.
- I test sono il costo fuori budget. La suite a due tenant è ingegneria vera; saltarla riporta “applicato” al rango di “dato per scontato”.
- Muri più solidi costano densità. Chiavi per tenant, silo e risorse dedicate sacrificano tutti l’economia che rendeva attraente la condivisione – conviene spenderli sui tenant che ne hanno bisogno.
L’isolamento dei tenant su Back4app
Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. L’isolamento parte dal livello dati per costruzione: i ruoli definiscono il tenant, l’ACL di ogni oggetto lo sigilla su quel ruolo e i permessi di classe regolano lo schema – il tutto applicato lato server su ogni percorso, SDK, REST, GraphQL e dashboard compresi, così che il bug del filtro dimenticato non abbia nulla da dimenticare. La piattaforma stessa applica la medesima disciplina un livello più in alto, isolando il backend di ogni app da quello di tutte le altre – e l’approfondimento di ingegneria sulla sicurezza a livello di riga mostra l’intero pattern in pratica.
Domande frequenti
Che cos'è l'isolamento dei tenant?
L'insieme dei controlli architetturali che impediscono a un tenant di un sistema condiviso di raggiungere i dati o le risorse di un altro tenant – i muri fra gli appartamenti di uno stesso edificio. Copre ogni livello condiviso: righe del database, cache, code, archiviazione di file e calcolo, ciascuno con bisogno di un proprio confine limitato al tenant corrente.
In che cosa l'isolamento dei tenant differisce da autenticazione e autorizzazione?
Un utente può essere pienamente autenticato e correttamente autorizzato per il proprio ruolo – e raggiungere comunque i dati di un altro tenant se nulla limita la query al tenant giusto. L'autenticazione dimostra chi è chi; l'autorizzazione decide quali azioni sono consentite; l'isolamento garantisce in quale universo di tenant quelle azioni avvengono. È un livello a sé, e considerare sufficienti accesso più ruoli è la radice della maggior parte dei bug fra tenant.
Che cosa provoca le fughe di dati fra tenant?
Un elenco breve e stabile: query prive del filtro sul tenant; l'IDOR, cioè ID indovinabili recuperati senza limitazione al tenant; job in background, webhook ed export eseguiti fuori dal contesto del tenant; cache le cui chiavi non includono il tenant; pipeline di analytics e di reporting che aggirano i controlli applicativi; e la fiducia accordata a un identificatore di tenant fornito dal client invece di derivarlo dalla sessione lato server.
Il problema del noisy neighbor coincide con l'isolamento dei tenant?
Sono parenti, non lo stesso problema. L'isolamento di sicurezza impedisce a un tenant di accedere ai dati di un altro; l'isolamento di prestazioni – il problema del noisy neighbor, il vicino rumoroso – impedisce che il carico di un tenant degradi quello di tutti gli altri, e si risolve con quote, throttling e partizionamento. Le discussioni li confondono regolarmente; un sistema può essere perfettamente sicuro e lasciare comunque che un tenant affami gli altri.
Quale modello di isolamento richiedono i framework di conformità?
Nessuno dei grandi framework impone un'architettura: sono basati sui risultati e richiedono misure appropriate e dimostrabili. La separazione fisica è tipicamente richiesta dai grandi clienti e dai contratti, non dai regolatori. Ciò che gli audit premiano davvero: l'applicazione delle regole nel livello dati, confini documentati e la prova che l'isolamento viene testato invece che dato per scontato.
Come fa la sicurezza a livello di riga a far rispettare l'isolamento dei tenant?
Rendendo il confine del tenant una proprietà della tabella: le policy filtrano ogni query in base al contesto di tenant della sessione, così una query che dimentica il filtro non restituisce nulla invece di restituire tutto. L'equivalente nei database documentali è il controllo degli accessi per oggetto – ACL che nominano il ruolo del tenant – applicato dalla piattaforma a ogni richiesta. In entrambi i casi il muro tiene anche quando il codice applicativo inciampa.
Come si testa l'isolamento dei tenant?
In modo avversariale, con due tenant: si scambiano gli ID degli oggetti fra l'uno e l'altro su ogni endpoint (la sonda IDOR), si rigioca il token di un tenant contro le risorse dell'altro, si esercitano i percorsi che saltano l'applicazione principale – export, pannelli di amministrazione, job in background – e si ispezionano le chiavi di cache e le URL dei file in cerca di una portata di tenant mancante. I test negativi vanno automatizzati in CI; un isolamento che non viene testato è solo un'ipotesi.
Quali livelli hanno bisogno di isolamento oltre al database?
Tutto ciò che è condiviso: chiavi di cache prefissate con il tenant, topic delle code e consumer group limitati a ciascun tenant, archiviazione a oggetti sotto prefissi per tenant con le policy di accesso corrispondenti, chiavi di crittografia per tenant dove i contratti le esigono, e claim di tenant portati nei token e validati a ogni richiesta. Il muro del database è necessario, mai sufficiente.