L’isolamento dei tenant SaaS significa che un cliente può accedere soltanto ai record e alle operazioni che la sua organizzazione ha diritto di utilizzare. Un selettore di tenant nell’interfaccia non basta. Il confine deve reggere quando richieste, attività di background, cache e download di file raggiungono i sistemi sottostanti.
Testate l’isolamento usando organizzazioni separate, ruoli utente ordinari e tentativi deliberati di attraversarne i confini. Verificate letture, scritture, file, risposte in cache e lavoro di background rispetto alle stesse regole di accesso. Richiedete prove dal confine backend applicato prima di accogliere clienti con record sensibili o commercialmente importanti.
Immaginate un portale clienti in cui ogni organizzazione vede i propri ordini di acquisto. La schermata di elenco sembra corretta, ma un’esportazione scaricata contiene righe di un’altra organizzazione. È un errore di isolamento anche se login e normale percorso della pagina funzionano come previsto.
Questa guida aiuta un responsabile a definire verifica e correzione. Non afferma che una disposizione di database garantisca la sicurezza o che una checklist sostituisca una valutazione completa dell’applicazione.
Definire l’isolamento dei tenant SaaS prima dello storage
Identificate il significato di tenant nel prodotto. Può essere un’organizzazione cliente, un’entità legale o uno spazio di lavoro. Registrate come gli utenti entrano, escono e cambiano tenant, e quali ruoli di supporto possono agire tra loro. L’ambiguità di queste regole diventa ambiguità nei test.
La guida OWASP alla sicurezza multi-tenant descrive l’isolamento nei confini di database, cache, storage e calcolo. Distingue anche un selettore fornito dal client dall’autorità verificata dal server. Usate questa distinzione nella valutazione del percorso reale delle richieste.
Definite esplicitamente la proprietà dei dati. Un catalogo condiviso può essere intenzionalmente visibile a più clienti, mentre le note degli ordini appartengono al tenant. I test devono conoscere la differenza per identificare fughe senza classificare informazioni condivise deliberatamente come difetti.
Mappate l’eccezione amministrativa. Se il supporto può esaminare i record di un cliente, spiegate chi concede l’accesso, come viene delimitato e come se ne registra l’uso. Un percorso di supporto potente deve essere testato come capacità intenzionale, anziché nascosto fuori dal modello normale del tenant.
Seguire il contesto del tenant nella richiesta
Partite da un utente autenticato e verificate l’appartenenza attuale o l’autorità del servizio. Seguite il tenant selezionato nella logica aziendale e nell’accesso ai dati. Controllate che cambiare un header, un valore di percorso o il corpo della richiesta non possa sostituire l’autorità di un’altra organizzazione.
Identificativi apparentemente casuali possono rendere più difficile indovinare, ma non stabiliscono permessi. La guida OWASP all’autorizzazione raccomanda di verificare l’accesso a ogni richiesta. Testate un identificativo ottenuto legittimamente da un altro tenant, anziché basarvi sulla possibilità di indovinarlo.
| Confine | Tentativo illustrativo | Risultato accettato |
|---|---|---|
| Ricerca di record | Richiedere l’identificativo noto di un ordine di un altro tenant | Rifiuto senza divulgazione del record |
| Aggiornamento | Inviare l’identificativo di un altro tenant in un payload valido | Nessuna modifica non autorizzata |
| Cambio tenant | Selezionare un’organizzazione senza appartenenza | Il server respinge l’ambito richiesto |
| Endpoint in blocco | Includere identificativi di tenant diversi | Rifiuto definito senza fuga parziale |
| Azione di supporto | Usare un ruolo ordinario su un percorso privilegiato | Rifiuto e prove utili per l’indagine |
Ripetete questo ragionamento per ricerca, esportazioni e API alternative. La prima schermata di dettaglio corretta non dimostra che un rapporto in blocco, un endpoint mobile o un vecchio percorso di compatibilità applichi lo stesso confine.
Confrontare gli approcci database dai controlli reali
Database separati, schemi separati e tabelle condivise creano compromessi operativi diversi. Nessuno elimina la necessità di verificare credenziali, ruoli, query e percorsi amministrativi. La proposta deve identificare dove viene applicato il confine e cosa accadrebbe se il codice omettesse un filtro.
| Approccio | Confine da esaminare | Lavoro operativo da includere |
|---|---|---|
| Database separati | Autorità di connessioni e credenziali | Provisioning, migrazioni e separazione dei backup |
| Schemi separati | Ruoli database e selezione del namespace | Permessi, disciplina di migrazione e accesso amministrativo |
| Tabelle condivise | Proprietà del tenant e politiche di accesso applicate | Copertura delle query, ruoli delle richieste e test negativi |
| Ibrido | Regola documentata per ogni classe di dati | Instradamento chiaro e indagine coerente degli incidenti |
Evitate di trattare la migrazione a database separati come soluzione predefinita per ogni difetto. Un bug di autorizzazione circoscritto può avere una correzione mirata. Allo stesso modo, aggiungere un filtro in un controller non basta quando esportazioni, job e strumenti di supporto usano ancora accesso illimitato.
Testare il ruolo realmente usato dalle richieste in produzione
La documentazione PostgreSQL sulla sicurezza delle righe spiega eccezioni importanti, tra cui ruoli privilegiati e proprietà delle tabelle. Se il prodotto si basa su politiche delle righe, verificatele con il vero ruolo di richiesta vincolato. Un test eseguito come amministratore database non rappresenta il confine dell’applicazione ordinaria.
Includete gli account di distribuzione e migrazione nell’inventario. Possono legittimamente richiedere accesso più ampio, ma non devono diventare l’identità abituale delle richieste clienti. Documentate come il runtime ottiene l’autorità prevista e come questo assetto viene verificato dopo la distribuzione.
Controllare cache, file e output derivati
Esaminate le chiavi della cache e l’ambito dei risultati memorizzati. Una voce creata per un’organizzazione non deve diventare risposta per un’altra perché entrambe le richieste condividono un comodo percorso o filtro. Testate il secondo tenant dopo che il primo ha popolato la cache.
I file richiedono prove di accettazione proprie. Verificate proprietà degli upload, accesso alle anteprime, download e rapporti generati. Una pagina può rifiutare correttamente l’accesso mentre l’URL di un allegato rimane disponibile tramite un altro percorso. Includete link obsoleti e già emessi nell’ambito concordato.
Controllate dati derivati come indici di ricerca, raccomandazioni ed esportazioni analitiche. Stabilite se il sistema applica restrizioni del tenant durante il recupero, non soltanto l’inserimento. Le informazioni possono attraversare il confine mediante una sintesi anche quando l’endpoint del record sorgente è protetto.
Usate dati di test controllati appartenenti a organizzazioni distinte. Date a ciascuna contenuto riconoscibile sufficiente a identificare contaminazioni senza copiare veri documenti clienti nella valutazione. Così diventa più facile diagnosticare un risultato inatteso della cache o un’esportazione mista.
Esercitare job di background e cambi di appartenenza
Il lavoro di background deve trasportare il contesto verificato del tenant attraverso la coda fino all’operazione. Controllate cosa succede se un job viene ritardato, ritentato o preso da un altro worker. Un ambito valido nella richiesta web non dimostra che il job successivo lo conservi.
Testate i cambi di appartenenza. Un utente rimosso dall’organizzazione non deve mantenere accesso ordinario tramite sessione in cache, esportazione salvata o operazione in attesa contro la politica concordata. Definite il comportamento previsto per il lavoro già accettato prima della revoca.
Anche l’impersonificazione da parte del supporto e l’eliminazione del tenant meritano copertura deliberata. Spiegate come gli operatori escono da una sessione privilegiata e come vengono gestiti file residui, job e riferimenti. La politica di eliminazione corretta dipende dagli obblighi di conservazione del prodotto; la valutazione deve verificare la politica scelta, non inventarne una.
La nostra guida alla presa in carico di un progetto software è pertinente quando il team attuale non sa spiegare quei percorsi. Recuperare la responsabilità di distribuzione, accesso ai dati e documentazione operativa può contribuire a rendere il confine mantenibile.
Specificare un rapporto di verifica utile
Richiedete riscontri che mostrino attore, tenant, operazione ed effetto osservato. Includete prove pertinenti di richiesta e destinazione controllando adeguatamente i valori sensibili. Un riscontro etichettato controllo accessi senza percorso riproducibile è difficile da correggere e ritestare.
OWASP ASVS può sostenere i requisiti più ampi di sicurezza applicativa. Mantenete la matrice di accettazione specifica dei tenant accanto a quel lavoro, così il revisore può vedere organizzazioni, ruoli e tipi di risorse esercitati.
Separate i difetti confermati dai percorsi non testati. Se il valutatore non ha potuto esaminare un servizio di storage privato o un’esportazione amministrativa, dichiaratelo. Un limite di ambito onesto è più utile di una conclusione infondata secondo cui tutti i dati dei tenant sono isolati.
Dopo la correzione ripetete il caso originale difettoso e i casi legittimi vicini. Una riparazione che blocca ogni download può fermare la fuga ma danneggiare il prodotto. L’accettazione richiede sia il rifiuto dell’accesso non autorizzato sia la continuazione del lavoro consentito ai clienti.
Prevedere il costo del confine reale del prodotto
Definite la valutazione mediante tipi di risorse, ruoli e percorsi operativi anziché solo numero di pagine. Includete file esterni, cache, job di background e supporto quando possono esporre informazioni del tenant. Un piccolo portale può avere un confine più ampio di quanto suggerisca l’interfaccia.
| Pacchetto di lavoro | Risultato | Ipotesi da chiarire |
|---|---|---|
| Mappatura del confine | Modello di tenant e ruoli | Disponibilità di conoscenze architetturali |
| Verifica | Prove positive e negative di accesso | Account e ambienti controllati |
| Correzione | Applicazione corretta e controlli di regressione | Necessità di modifiche strutturali |
| Consegna | Test ripetibili ed esclusioni note | Responsabilità dopo l’onboarding |
Richiedete proposte in GBP distinguendo valutazione e correzione. Non accettate un’assicurazione universale basata soltanto su un test di login o una scansione automatica. Il risultato prezioso è la prova dei confini di accesso da cui dipenderanno i clienti.
Il nostro servizio di sicurezza applicativa offre un punto di partenza per questo ambito. Inviateci il modello dei tenant e la decisione di onboarding per discutere verifiche, correzioni mirate e prove necessarie prima di aprire il prossimo account cliente.
Domande frequenti
Che cos’è l’isolamento dei tenant SaaS? È la separazione applicata dei dati e delle operazioni consentite alle organizzazioni clienti. Il confine deve reggere tra richieste applicative, storage, cache, file e lavoro di background, comprese le eccezioni amministrative definite dal prodotto.
Database separati garantiscono l’isolamento? No. Credenziali, instradamento, strumenti di supporto, esportazioni e backup possono ancora attraversare i confini. Database separati possono essere parte del progetto, ma i percorsi di accesso reali richiedono test.
Bastano identificativi casuali dei record? No. Possono ridurre la facile enumerazione ma non sono controlli di permessi. Testate l’accesso con un identificativo reale di un altro tenant controllato e confermate che il server lo respinga.
Dobbiamo testare accessi consentiti oltre ai rifiuti? Sì. Una correzione che nega ogni richiesta può nascondere un prodotto rotto. Verificate che gli utenti ordinari mantengano le operazioni previste mentre i tentativi tra tenant sono respinti.
Perché le cache richiedono test separati? Possono restituire dati senza ripetere il percorso originale di accesso. Popolate una cache sotto un tenant ed esaminate il risultato sotto un altro. Confermate che l’ambito conservi l’autorità prevista anziché condividere semplicemente una chiave comoda.
Come deve funzionare l’accesso del supporto? Definite chi può ottenerlo, quale ambito concede, quanto dura e come vengono registrate le azioni. Testate ingresso, uso e uscita dal contesto privilegiato. Il progetto deve rendere l’eccezione esplicita e verificabile.
E se usiamo sicurezza a livello di riga? Testatela con il ruolo di richiesta reale dell’applicazione e includete operazioni che aggirano i controller ordinari. Ruoli database privilegiati e altri percorsi di accesso possono comportarsi diversamente. Le politiche delle righe sono un controllo da verificare, non un motivo per omettere la valutazione.
Cosa deve ricevere un fornitore prima del preventivo? Una descrizione di tenant e ruoli, tipi di risorse, storage esterno e operazioni di background. Identificate ambienti e account controllati disponibili per i test, insieme alla decisione che la valutazione deve sostenere.