Che cos’è l’isolamento dei dati per una applicazione SaaS in informatica

Isolamento dei dati

Nell’ambito informatico, per un’applicazione destinata ad un unico cliente i dati sono racchiusi nel medesimo database senza dover incorrere nei problemi del loro isolamento. Tuttavia un’importante differenza è che tale aspetto è la prima cosa da considerare nell’ottica dello sviluppo cloud. In questo caso il database può essere dislocato su una vasta rete formata da più computer. Per assicurare che tali database siano correttamente aggiornati esistono due processi, la replicazione e la duplicazione. La prima coinvolge l’utilizzo di software specializzati per controllare cambiamenti nei database distribuiti. Una volta che vengono identificati, il processo di replicazione rende uguali tutti i database. Tuttavia tutto questo può essere molto complicato e richiedere molto tempo d’esecuzione nel caso in cui sia molto alto il numero di tali database distribuiti. La duplicazione non è invece cos`ı complicata. Fondamentalmente identifica un database come master e successivamente lo duplica. Questo processo viene normalmente eseguito ad intervalli di tempo precisi, in modo tale da assicurare che ogni locazione distribuita abbia gli stessi dati. Inoltre, sono autorizzati cambiamenti solo al database master in modo tale da assicurare che i dati locali non siano sovrascritti.

A questo punto vi sono tre tipologie di salvataggio dei dati.

1. Self-Contained Database: questo schema prevede che ad ogni cliente sia associato un database. In questo caso l’isolamento dei dati viene assicurato nel miglior modo ed è sicuramente la modalità più sicura ma di conseguenza anche la più costosa. Il suo punto di forza è la semplificazione dell’estensioni al modello dei dati in modo tale da poter soddisfare i requisiti dei diversi clienti. In caso di guasti, recuperare i dati è relativamente semplice. Lo svantaggio sta invece nell’incrementare il numero di database da installare e quindi anche i costi di manutenzione crescono.
2. Shared Database: il secondo schema prevede la condivisione del database tra tutti gli utenti, i quali possiederanno al suo interno un loro specifico pattern di Il punto di forza di tale soluzione è di fornire un isolamento logico dei dati a quei clienti che richiedono un alto livello di sicurezza anche se non c’è isolamente completo. Viene inoltre supportata la partizione a livelli in modo tale che i dati possano essere distribuiti su diversi server in modo da evitare una penalizzazione in termini di performance quando viene effettuata la loro riconvergenza. I difetti risiedono invece nel recupero dei dati in caso di guasti, poichè questa operazione, inevitabilmente, coinvolge i dati di altri clienti. Inoltre se fosse necessario tracciare delle statistiche, per esempio di utilizzo, tra i vari clienti sarebbe anche questa un’operazione assai complicata.
3. Shared Database and Shared Data Structure: in questo terzo schema gli utenti condividono sia lo stesso database che lo stesso modello dei Di conseguenza in una tabella del database, attraverso un ID, si differenziano i vari clienti e i loro dati. Questo è, ovviamente, il modello con la più alta condivisione e il minor isolamento. Infatti in questo caso costi di acquisizione e manutenzione sono molto bassi, poichè ogni database supporterà già la possibilità di avere più utenti. Tuttavia presenta anche il livello di isolamento e di sicurezza più basso in assoluto quindi è necessario, in fase di sviluppo dell’applicazione, aumentare la sua affidabilità. Il recupero dei dati è assai difficoltoso, poichè la tabella va analizzata backup per backup in modo da poter tornare allo stato iniziale. Infatti a mano a mano che cresce il numero degli utenti, anche la tabella cresce di dimensioni e l’operazione di ricostruzione nel caso di guasti è sempre più problematica. Questa tipologia è la preferita se si vuole utilizzare un numero veramente minimo di server che verranno poi utilizzati da tutti i clienti, che dovranno però rinunciare all’isolamento dei dati in favore di una riduzione dei costi.

Sempre in riferimento a quest’ultima modalità diventa quindi importante modellare correttamente gli aspetti relativi alla sicurezza. Per fare questo bisogna operare in due ambiti:

1. Livello di sistema: vengono usati protocolli HTTPS e i dati vengono scambiati in SSL (Security Socket Layer) in modo tale da assicurare la sicurezza delle com Inoltre si può prevenire la distorsione dei processi di trasmissione sfruttando le firme digitali e backup automatici e frequenti dei dati importanti.
2. Livello di programma: si può utilizzare un sistema di autorizzazioni sui dati, validazione client-side in modo da prevenire attacchi JS, SQL injection, ecc. Inoltre è possibile inserire, come ulteriore controllo, la verifica di inserimento delle password e dei captcha.