RBAC vs Isolamento dei Tenant: Due Confini di Sicurezza Diversi

RBAC e isolamento dei tenant risolvono due problemi di sicurezza diversi nei sistemi multi-tenant. Il controllo degli accessi basato sui ruoli (RBAC) determina cosa è consentito fare a un principal autenticato, come leggere ordini, modificare prodotti o gestire utenti. L'isolamento dei tenant determina a quali dati, risorse e contesto di esecuzione di quale tenant quel principal è autorizzato ad accedere. Un utente può essere correttamente autenticato e correttamente assegnato a un ruolo RBAC e tuttavia subire un fallimento di sicurezza se l'applicazione consente a quel ruolo di operare sulle risorse di un altro tenant.

Cosa controlla realmente RBAC

RBAC è un modello di autorizzazione in cui i permessi sono associati ai ruoli e gli utenti sono assegnati a tali ruoli. Il ruolo funge da astrazione amministrativa tra identità e permessi.

Il lavoro classico di NIST su RBAC formalizza questo concetto attorno a utenti, ruoli, permessi, operazioni e oggetti. Il vantaggio pratico è che un'organizzazione può gestire l'autorizzazione attraverso ruoli relativamente stabili basati su mansioni o responsabilità, invece di collegare ogni permesso direttamente a ogni utente.

Un ruolo come EDITOR può quindi significare: può leggere contenuti, scrivere contenuti e pubblicare contenuti. Un ruolo come ACCOUNTANT può significare: può leggere dati di fatturazione, riconciliare fatture e approvare regolamenti.

Cosa controlla realmente l'isolamento dei tenant

L'isolamento dei tenant è l'insieme dei meccanismi che impediscono a un tenant di leggere, modificare, influenzare o ricevere accidentalmente le risorse di un altro tenant in un sistema condiviso.

Il confine protetto è più ampio delle righe del database. Lo stato specifico di un tenant può esistere in tabelle relazionali, object storage, indici vettoriali, cache, indici di ricerca, messaggi in coda, file, artefatti temporanei, job in background, analisi, limiti di velocità e risorse infrastrutturali.

Le linee guida AWS per SaaS rendono esplicita la distinzione: l'autorizzazione concede l'accesso alle risorse, mentre l'isolamento dei tenant garantisce che tali risorse non possano attraversare il confine del tenant sbagliato anche quando l'infrastruttura è condivisa.

L'esempio più semplice

Supponiamo che Alice sia un'amministratrice del Tenant A e Bob sia un amministratore del Tenant B. Entrambi gli utenti possiedono legittimamente lo stesso ruolo ADMIN.

RBAC può correttamente concludere che entrambi gli utenti possono eseguire un'operazione come users.read. Ma quando Alice richiede l'ID utente 847, l'applicazione deve comunque verificare che l'utente 847 appartenga al Tenant A.

Se l'API controlla solo "Alice ha ADMIN" e poi esegue SELECT * FROM users WHERE id = 847, RBAC ha avuto successo mentre l'isolamento dei tenant ha fallito.

Dove si ferma l'esempio semplice

I sistemi reali spesso contengono diverse classi di identità: utenti tenant, amministratori di piattaforma, worker in background, integrazioni, agenti e servizi operativi cross-tenant. Alcune di queste attraversano legittimamente i confini dei tenant.

Ciò non elimina la necessità di isolamento. Significa che l'autorità cross-tenant deve essere esplicita, ristretta e verificabile separatamente, invece di emergere accidentalmente da un ruolo globale o da una connessione al database senza scope.

L'isolamento dei tenant può anche variare a seconda del livello. Un prodotto può condividere i server applicativi separando i database, oppure utilizzare un database condiviso con policy a livello di riga, offrendo al contempo ai tenant premium storage o capacità di calcolo isolati. Non esiste un'unica topologia di isolamento universale.

RBAC vs isolamento dei tenant

Autenticazione, autorizzazione e isolamento sono tre controlli diversi

Questi controlli sono correlati ma non sostituibili. L'autenticazione può essere perfetta mentre l'autorizzazione fallisce. L'autorizzazione può essere corretta mentre l'isolamento dei tenant fallisce. Un percorso di richiesta SaaS sicuro necessita di tutti i confini applicabili.

I ruoli necessitano di uno scope

La parola ADMIN è incompleta senza scope. Può significare amministratore di piattaforma, amministratore di tenant, amministratore di progetto, amministratore di workspace o amministratore di un sottosistema.

Nei sistemi multi-tenant, l'assegnazione dei ruoli dovrebbe normalmente essere associata all'appartenenza al tenant o a un altro scope esplicito della risorsa. Lo stesso utente può legittimamente essere ADMIN nel Tenant A e VIEWER nel Tenant B.

Un modello di ruoli globale che ignora questa distinzione può creare una fuga di privilegi anche quando la mappa dei permessi stessa è corretta.

Il contesto del tenant deve provenire da un percorso attendibile

Un ID tenant fornito dal client è utile come selettore, ma non è prova di autorità. Il server deve derivare o verificare l'appartenenza al tenant rispetto all'identità autenticata e ai dati di autorizzazione correnti.

Le attuali linee guida multi-tenant di OWASP raccomandano di stabilire il contesto del tenant all'inizio del ciclo di vita della richiesta e mettono esplicitamente in guardia dal trattare header del client o parametri della richiesta come prova di autorizzazione.

Questo è importante perché una banale modifica della richiesta da tenant=A a tenant=B non deve essere sufficiente per superare il confine di isolamento.

Lo scope del tenant appartiene alla ricerca della risorsa

Un modello comune di isolamento a livello applicativo consiste nell'includere lo scope del tenant nella stessa query che risolve la risorsa.

Questo modello non è l'unico meccanismo di isolamento possibile, ma mantiene la proprietà del tenant vicina all'operazione di accesso ai dati e impedisce che un ID oggetto diventi una capability cross-tenant.

I controlli applicativi sono utili, ma l'isolamento non dovrebbe dipendere da un comportamento perfetto degli sviluppatori

Le linee guida sull'isolamento di AWS mettono esplicitamente in guardia dal lasciare l'applicazione dell'isolamento solo agli sviluppatori dei servizi. In una grande codebase, prima o poi una query, una chiave di cache o un percorso di un worker potrebbe omettere lo scope del tenant.

La difesa in profondità può quindi spostare l'isolamento in middleware condiviso, livelli repository/service, motori di policy, Row-Level Security del database, credenziali dedicate, schemi separati o database separati a seconda del rischio e dell'architettura.

Strategie di isolamento del database

L'attuale Multi-Tenant Security Cheat Sheet di OWASP elenca database separati, schemi separati, tabelle condivise con controlli a livello di riga e modelli ibridi. Il modello corretto dipende dal livello di minaccia, dalla conformità, dalle prestazioni e dal costo operativo.

PostgreSQL Row-Level Security può fornire difesa in profondità

Con tabelle condivise, PostgreSQL Row-Level Security può applicare un predicato tenant a livello di database, così le query ordinarie non possono vedere righe al di fuori della policy del tenant attivo.

Tuttavia, RLS non è magia. I superuser di PostgreSQL e i ruoli con BYPASSRLS possono bypassare le policy a livello di riga. OWASP raccomanda quindi di utilizzare un ruolo con privilegi minimi per il percorso di richiesta e di testare la stessa modalità di connessione/pooling usata in produzione.

Il riutilizzo delle connessioni è un altro caso limite importante: il contesto del tenant deve essere impostato e reimpostato in modo sicuro per ogni transazione/richiesta, così una connessione in pool non può far trapelare lo stato di un tenant precedente.

L'isolamento del tenant deve includere le cache

Una query al database può avere uno scope perfetto e comunque far trapelare dati attraverso una chiave di cache condivisa.

Se user:42 esiste sia nel Tenant A sia nel Tenant B, una chiave di cache globale può restituire il valore del tenant sbagliato. Le chiavi di cache sensibili al tenant dovrebbero includere ogni attributo che modifica la visibilità o la semantica del risultato, comunemente tenant, utente, locale, set di funzionalità o versione dei permessi.

La partizione della cache è difesa in profondità, non un sostituto dell'autorizzazione. La richiesta deve comunque essere autorizzata prima che venga restituito il contenuto protetto memorizzato in cache.

File e object storage necessitano di un proprio confine di tenant

L'object storage dovrebbe distinguere oggetti globali, con ambito tenant e con ambito utente. Un prefisso di cartella da solo è solo una convenzione di denominazione, a meno che la policy di accesso non vincoli effettivamente letture e scritture.

Progettazioni più robuste possono utilizzare chiavi oggetto tenant-aware, policy di bucket, bucket/account separati o chiavi di cifratura specifiche per tenant, laddove il rischio o la conformità richiedano un isolamento più forte.

Gli URL firmati devono essere autorizzati prima dell'emissione e limitati all'oggetto e all'operazione esatti. Il possesso di un identificatore di oggetto non dovrebbe di per sé concedere accesso cross-tenant.

I job in background e le code possono rompere l'isolamento

I job asincroni spesso abbandonano il contesto della richiesta HTTP originale, il che rende facile gestire male la propagazione del tenant. Un messaggio in coda che contiene tenantId non è prova sufficiente che il produttore fosse autorizzato.

Il worker dovrebbe portare un'identità di servizio/utente verificata o una busta di job attendibile, ristabilire il contesto del tenant e riautorizzare le operazioni consequenziali al confine del consumatore.

L'isolamento del tenant include anche la disponibilità. Un tenant non dovrebbe essere in grado di monopolizzare worker, code, pool di connessioni o risorse di calcolo condivise in modi che degradino materialmente gli altri tenant.

Ricerca e RAG necessitano di retrieval tenant-aware

L'AI multi-tenant introduce un'altra copia del problema di isolamento. I documenti possono essere suddivisi in chunk, incorporati e memorizzati in un indice vettoriale dopo l'ingestione.

L'attuale guida alla sicurezza RAG di OWASP afferma che il controllo degli accessi deve essere applicato al momento del retrieval e che i chunk del Tenant A non devono essere recuperati da query del Tenant B. Non si può semplicemente presumere che i permessi a livello di documento sopravvivano automaticamente alla suddivisione in chunk.

L'indice vettoriale necessita quindi di metadati di tenant/accesso o di collezioni fisicamente/logicamente separate in base al design di isolamento. I filtri di retrieval dovrebbero essere applicati prima che contenuti non autorizzati possano entrare nel contesto del modello.

I dati derivati ereditano la sensibilità del tenant

Embedding, indici di ricerca, miniature, riepiloghi generati, cache, righe di analytics e risposte AI derivano dai dati di origine. Il loro ambito di tenant dovrebbe seguire la fonte, a meno che una trasformazione esplicita crei un artefatto condiviso/globale legittimo.

La cancellazione e l'offboarding devono quindi propagarsi oltre la riga canonica. Rimuovere un documento del tenant lasciando chunk ricercabili o riepiloghi in cache può mantenere un'esposizione cross-tenant o successiva alla conservazione.

Non tutto appartiene a un tenant

Le piattaforme multi-tenant hanno spesso risorse intenzionalmente globali: tassonomie di prodotto, template pubblici, permessi di sistema, definizioni di funzionalità o contenuti pubblici.

Il modello più sicuro è la classificazione esplicita: globale, con ambito tenant, con ambito utente o esplicitamente cross-tenant. Le risorse ambigue sono il punto in cui inizia una fuga di dati accidentale.

Un oggetto condiviso intenzionalmente dovrebbe avere una motivazione documentata per essere globale, invece di mancare semplicemente di un'associazione a un tenant.

Gli amministratori della piattaforma richiedono un modello di autorità diverso

Un operatore della piattaforma potrebbe aver bisogno di ispezionare più tenant per supporto, conformità o operazioni infrastrutturali. Modellare questo come un normale ADMIN di tenant con accesso accidentale al database globale indebolisce sia la sicurezza che l'auditabilità.

Un design migliore utilizza un'identità di piattaforma distinta o un permesso cross-tenant esplicito, autenticazione più forte, limitazione dello scopo, audit dettagliato e, ove appropriato, controlli di approvazione o break-glass.

L'accesso cross-tenant dovrebbe quindi essere una capacità denominata, non l'assenza di un filtro tenant.

RBAC può essere combinato con gli attributi

Alcune decisioni dipendono da più del ruolo. L'appartenenza al tenant, la regione, il proprietario della risorsa, il livello di abbonamento, il tempo, l'appartenenza al progetto o la classificazione dei dati possono tutti influenzare l'accesso.

RBAC e ABAC non si escludono a vicenda. Le attuali linee guida di AWS sull'autorizzazione multi-tenant discutono modelli RBAC, ABAC e ibridi. Un ruolo può definire una responsabilità ampia mentre gli attributi limitano quale istanza concreta di risorsa può essere accessibile.

La regola architetturale chiave rimane: non codificare l'isolamento del tenant solo come un nome di ruolo incidentale se l'identità del tenant è un confine di risorsa di prima classe.

Le decisioni di autorizzazione sono almeno bidimensionali

Evidenza dell'implementazione originale: Aaasaasa AI CMS

Il servizio RBAC definisce codici di permesso tipizzati come cms.content.read, shop.orders.write, billing.reconcile e users.roles. I ruoli di sistema mappano quei permessi in insiemi di responsabilità denominati.

I record dei ruoli vengono creati e risolti con un tenantId. I ruoli di sistema vengono inseriti o aggiornati utilizzando un'identità composita tenant/codice, e l'elenco dei ruoli è filtrato per tenant.

L'aggiornamento e l'eliminazione dei ruoli risolvono prima il ruolo utilizzando sia l'ID del ruolo che l'ID del tenant. Anche le assegnazioni utente-ruolo vengono memorizzate e sostituite nel contesto del tenant corrente.

La risoluzione dei permessi legge le assegnazioni esplicite utente-ruolo con ambito sia tenantId che userId. Questo impedisce che l'assegnazione di ruolo di un tenant diventi automaticamente l'assegnazione di ruolo di un altro tenant.

A livello API, le route RBAC amministrative risolvono un contesto tenant prima di creare o modificare ruoli. Questa è la direzione corretta: l'amministrazione dei permessi stessa deve rispettare la tenancy.

Perché questa distinzione conta ancora di più per gli agenti AI

Gli agenti AI possono trasformare un errore di permesso in una sequenza di azioni. Se a un agente viene fornito uno strumento ampio orders.read senza applicazione con ambito tenant, un errore di ragionamento o di prompt-injection può causare letture cross-tenant alla velocità della macchina.

Le descrizioni degli strumenti dell'agente possono menzionare vincoli tenant, ma l'applicazione deve comunque avvenire nel runtime/servizio/strato dati attendibile. Le istruzioni in linguaggio naturale non sono un confine di autorizzazione.

Lo stesso vale per RAG: un agente può avere il permesso di usare lo strumento di ricerca mentre il backend di ricerca deve comunque impedire che la query del Tenant A restituisca i chunk del Tenant B.

Testare RBAC e isolamento tenant separatamente

La guida OWASP sui test di regressione dell'autorizzazione menziona specificamente i test sui confini cross-tenant perché modifiche al codice in caching, query o servizi condivisi possono rompere silenziosamente l'isolamento anche quando i test dei ruoli continuano a passare.

Modalità di errore comuni

Idee sbagliate comuni

Una sequenza di progettazione pratica

Checklist RBAC + isolamento tenant

Casi limite e limitazioni

Un utente può appartenere a più tenant. Il tenant corrente dovrebbe quindi essere un contesto di esecuzione esplicito, non dedotto permanentemente dall'account utente.

Alcune risorse sono intenzionalmente condivise tra tenant selezionati, come spazi di collaborazione o dati di consorzio. Ciò richiede un modello di condivisione esplicito; fingere che la risorsa appartenga a un tenant e aggiungere eccezioni in seguito di solito crea autorizzazioni ambigue.

L'isolamento da vicini rumorosi è correlato ma diverso dall'isolamento di riservatezza. Un tenant potrebbe non vedere mai i dati di un altro tenant e tuttavia esaurire CPU condivisa, capacità di coda o connessioni al database. I limiti di velocità e le quote di risorse possono quindi essere tenant-aware come confine di disponibilità.

L'isolamento fisico non è automaticamente sicuro se le credenziali del piano di controllo o i percorsi amministrativi possono attraversare i confini. L'isolamento logico non è automaticamente debole se le politiche sono applicate centralmente, con privilegi minimi e testate a fondo.

I requisiti di isolamento dei tenant possono differire per classe di dati. Dati di catalogo pubblici, record di fatturazione e documenti AI privati possono giustificare confini di archiviazione e crittografia diversi all'interno dello stesso prodotto SaaS.

Cosa cambierebbe questa risposta?

L'implementazione esatta cambia con l'architettura: API serverless, Kubernetes, PostgreSQL, object storage, database vettoriali e motori di policy espongono primitive di isolamento diverse.

La forza richiesta cambia anche con la regolamentazione, i contratti dei clienti, la sensibilità dei dati, il modello di minaccia e la scala operativa. Alcuni tenant possono giustificare database o infrastrutture siloed mentre altri condividono risorse in pool.

La distinzione concettuale non cambia: il permesso di eseguire un'operazione non è la stessa cosa del permesso di attraversare un confine di tenant.

Conoscenza canonica correlata

S01 è un prerequisito di confine di sicurezza per Enterprise AI Architecture e AI Governance. Una volta che strumenti AI, RAG o agenti operano su dati multi-tenant, l'identità del tenant deve viaggiare attraverso il recupero, l'esecuzione degli strumenti, la memoria, le cache e le tracce di audit.

Si collega anche direttamente ad Agentic AI: la capacità degli strumenti e il permesso del ruolo devono comunque essere vincolati dalla proprietà del tenant prima che un agente possa leggere o modificare risorse aziendali.

Per RAG, l'isolamento dei tenant deve essere applicato prima che i chunk protetti raggiungano il contesto del modello.

Domande frequenti

Glossario

Conclusione

RBAC e isolamento del tenant sono meccanismi di sicurezza complementari, non in competizione. RBAC struttura il permesso operativo; l'isolamento del tenant vincola il confine delle risorse entro cui tale permesso può essere applicato.

Una richiesta multi-tenant robusta necessita quindi di più di "l'utente ha il ruolo ADMIN". Richiede un principal verificato, un contesto tenant verificato, un'operazione consentita, un target con ambito tenant e l'applicazione a ogni livello di risorsa che può contenere dati di proprietà del tenant.

La regola affidabile più breve è: autorizza l'azione, poi isola l'ambito — e non presumere mai che una dimostri l'altra.

Fonti primarie e linee guida attuali

Le fonti seguenti supportano la definizione di RBAC e le linee guida attuali sull'isolamento del tenant. La sezione Aaasaasa AI CMS è una prova di implementazione originale ed è intenzionalmente limitata ai pattern di codice che sono stati verificati.