Quando più clienti utilizzano la stessa istanza di un software, un fornitore SaaS deve rispondere a una domanda fondamentale: come vengono separati i dati dei singoli clienti (tenant)? La risposta più diffusa nel settore è un database condiviso in cui ogni tabella ha una colonna aggiuntiva come “tenant_id”, usata per filtrare ogni interrogazione. Funziona, ma dipende interamente dal fatto che questo filtro sia implementato correttamente in ogni singolo punto del codice. 1Tool segue una strada strutturalmente diversa.
Un database dedicato per cliente invece di una tabella condivisa
In 1Tool ogni cliente dispone di un proprio database, fisicamente separato. Il collegamento avviene dinamicamente in fase di esecuzione: quando un utente effettua l'accesso, il sistema sa con quale database del cliente deve comunicare e stabilisce la connessione di conseguenza. La separazione quindi non avviene a livello applicativo tramite una condizione di filtro, ma già a livello di infrastruttura. Un errore di programmazione che, con un database condiviso, potrebbe in teoria far dimenticare la condizione di filtro e rendere visibili i dati di un altro cliente è escluso fin dall'inizio con un'architettura rigorosa “un database per cliente”: semplicemente non esiste una tabella condivisa da cui si possano leggere per errore troppi dati.
Server dedicati per i grandi clienti, cache separata per tutti
Se necessario, questa separazione può essere spinta ancora più in là. Per i clienti particolarmente grandi, 1Tool può persino assegnare un server di database completamente dedicato – con host e credenziali propri – invece di far girare il database sulla stessa infrastruttura di server condivisa con altri clienti. In questo modo l'isolamento passa dal livello logico a quello fisico dell'infrastruttura, quando ciò è sensato per un cliente per motivi di sicurezza o di prestazioni. Inoltre 1Tool gestisce anche la cache per singolo cliente: anche i dati memorizzati nella cache vengono tenuti separati per ogni cliente, così che nemmeno a questo livello possa verificarsi alcuna commistione tra clienti.
Autorizzazioni granulari all'interno del cliente
La separazione tra clienti è solo uno dei livelli del controllo degli accessi. All'interno di un singolo cliente, un sistema di autorizzazioni con decine di regole di filtro specializzate – i cosiddetti scope – stabilisce inoltre quali singoli record un determinato utente può effettivamente vedere. Si può così fare in modo, ad esempio, che un commerciale veda solo i propri contatti, mentre un dirigente ha una panoramica completa – il tutto all'interno dello stesso database, già isolato per cliente. Per le aziende con requisiti elevati in materia di protezione e sicurezza dei dati, questa combinazione è un argomento rilevante nella scelta del fornitore. Un database condiviso con colonne tenant_id è più economico da scalare in esercizio, ma richiede che ogni singola interrogazione dell'intero sistema sia filtrata correttamente – per anni e attraverso molte generazioni di sviluppatori. Una vera architettura “un database per cliente” sposta questa garanzia dalla logica applicativa all'infrastruttura stessa.
Domande frequenti
Un database per cliente significa che i dati sono archiviati fisicamente separati?
Sì, ogni cliente dispone di un proprio database separato invece di tabelle condivise con un identificativo del cliente come colonna di filtro.
È possibile gestire singoli clienti su un server completamente dedicato?
Per i clienti particolarmente grandi è possibile, con host e credenziali propri, separati dall'infrastruttura di server condivisa.
Come si stabilisce, all'interno di un cliente, chi vede quali record?
Se ne occupa un sistema di autorizzazioni con numerose regole di filtro specializzate, che si aggiungono alla separazione dei database e limitano l'accesso ai singoli record per ciascun utente.
Quanto è importante un vero isolamento dei database per i requisiti di protezione dei dati della vostra azienda?
Continua a leggere
- Notificare altri sistemi: richieste HTTP direttamente dal workflow di automazione
- Webhook in entrata: portare dati esterni nel CRM in modo strutturato