Vai al contenuto

Verificare l’isolamento dei clienti in un’applicazione SaaS

Un piano di verifica concreto per accessi ai dati, esportazioni e job in background tra ambienti cliente separati.

Nora Henning2 min di lettura
Vassoio diviso con pile di schede rosa e verdi in scomparti separati.

Definisca prima l’ambiente cliente

Un tenant è un ambiente cliente separato nella Sua applicazione. Non coincide necessariamente con una persona né sempre con un’intera azienda. Definisca quali dati appartengono allo stesso ambito, chi può esserne membro e quali attività consente ogni ruolo. Un account può avere più appartenenze; l’accesso all’account da solo non seleziona un ambito dati autorizzato.

Microsoft distingue il tenant logico dal rilascio tecnico. Database dedicato e tabelle condivise comportano requisiti diversi di gestione e protezione degli accessi. Nessuna opzione sostituisce la verifica di tutti i percorsi previsti.

Un piano con due ambienti cliente inventati

Pianifichi questi casi con dati sintetici in un ambiente di prova separato. Sono risultati attesi, non un test di sicurezza eseguito. Gli ambienti si chiamano TA e TB. L’intervento SV-12 appartiene a TA, l’intervento SV-41 a TB. Ogni account di prova possiede i diritti previsti sugli interventi solo nel proprio ambiente.

Accesso verificato

Azione

Risultato atteso

Account autorizzato in TA

Leggere SV-12

Compaiono solo i propri dati dell’intervento consentiti a quel ruolo.

Stesso account in TA

Leggere o modificare direttamente SV-41, oppure recuperare l’allegato

Nessun dato di TB viene restituito o modificato.

Account in TA

Cercare ed esportare

Risultati e file non contengono dati di TB.

Prima account di TB, poi account di TA

Usare lo stesso percorso di accesso alla cache del server

TA non riceve risultati prima memorizzati per TB.

Account in TA

Accodare un’esportazione, revocare l’accesso prima dell’elaborazione

Il lavoro in background verifica di nuovo e viene rifiutato secondo questa regola di prova.

Verifichi dati e modifiche effettive sul server. Un pulsante nascosto non dimostra l’isolamento. Usi anche un identificativo noto di un oggetto altrui: un identificativo difficile da indovinare non deve essere l’unica barriera.

Mantenga il confine lungo tutto il flusso

OWASP richiede un contesto tenant verificato dal server e autorizzazione adeguata. Gli identificativi inviati dal client sono una selezione, non un permesso. Verifichi appartenenza attuale, azione consentita e appartenenza dell’oggetto. Se manca il contesto necessario, l’applicazione non deve ripiegare su una query senza limiti.

Includa allegati, chiavi di cache dipendenti dal tenant, esportazioni ed elaborazioni differite. I lavori in background richiedono trasmissione affidabile di contesto e autorizzazione e controlli adeguati all’elaborazione. Definisca come trattare diritti revocati nel frattempo.

I contenuti pubblici e globali non richiedono un tenant artificiale. Le attività di piattaforma tra ambienti richiedono invece un’identità espressamente autorizzata e accessi tracciabili. Registri separatamente risultato atteso, riscontro effettivo e correzione per ogni caso. Ripeta le verifiche interessate quando cambiano percorsi o ruoli.

Fonti

Scritto da

  • Nora HenningRedattrice per la sicurezza informaticaNora Henning cura per ASES i contenuti redazionali sulla sicurezza informatica. Scrive della sicurezza delle applicazioni e spiega il legame tra diritti di accesso e protezione dei dati aziendali.

Seguite ASES

Continuate a leggere

Tutti gli articoli

Sviluppo software con ASES

Software su misura, app web e mobile