Scegliere come archiviare i dati di ciascun cliente è una decisione architetturale con conseguenze sulla sicurezza, sulle operazioni e sull’evoluzione del prodotto. In un SaaS multi-tenant, non basta che ogni utente visualizzi un’interfaccia diversa: il sistema deve controllare quali dati ogni cliente può consultare e modificare, anche in caso di errori nel codice, processi in background o modifiche alla configurazione.
Non esiste un modello universalmente migliore. Un database condiviso può semplificare la gestione, mentre un database dedicato può agevolare determinati requisiti di isolamento, ma moltiplica anche le attività e i costi operativi. La scelta giusta dipende dal rischio che si intende ridurre, dagli impegni assunti con i clienti e dalla capacità effettiva del team di gestire l’architettura.
Cosa significa isolare i dati per cliente
L’isolamento dei dati, o multi-tenancy, consiste nel separare logicamente le informazioni di ogni organizzazione all’interno di un servizio condiviso. Il tenant è di solito un’azienda cliente, anche se il modello di business può definire un’unità diversa. L’applicazione deve associare ogni richiesta, processo e dato a un tenant autorizzato e far rispettare questa relazione in modo coerente.
Separare l’archiviazione non elimina automaticamente tutti i rischi. Un’autorizzazione errata può consentire a un utente di accedere alle funzioni di un altro cliente; un registro esportato o un sistema di analisi può esporre dati anche se il database principale è correttamente segmentato. È inoltre necessario considerare backup, log, cache, file, integrazioni e ambienti di supporto.
Perciò, la domanda utile non è soltanto dove archiviare i dati, ma quali controlli impediscono l’accesso incrociato e come verificare che funzionino. L’architettura di archiviazione è uno strato di questa strategia, non sostituisce l’autenticazione, l’autorizzazione, la revisione del codice o la gestione sicura delle operazioni.
Tre modelli di archiviazione comuni
Database condiviso
Tutti i clienti usano lo stesso database e, spesso, le stesse tabelle. Ogni record include un identificativo del tenant e le query devono filtrare in base a esso. Questo modello tende a ridurre la complessità del provisioning e semplifica l’applicazione delle modifiche allo schema una sola volta. È una scelta ragionevole quando il prodotto è agli inizi, i requisiti dei clienti sono simili e il team è in grado di definire controlli affidabili.
Il rischio principale è che una query o un processo dimentichi il filtro. La conseguenza può essere la lettura o la modifica dei dati di un altro cliente. Inoltre, i clienti condividono le risorse: un carico intenso generato da un’azienda può avere ripercussioni sugli altri se la capacità non viene gestita.
Schema separato per cliente
Un database ospita più schemi, uno per cliente, con tabelle simili. La separazione può rendere più visibile il confine tra i diversi insiemi di dati e consentire alcune operazioni per cliente. Tuttavia, non elimina il rischio di errori nell’instradamento e non garantisce l’isolamento delle risorse. Le migrazioni e gli strumenti devono gestire gli schemi in modo coerente; con molti clienti, amministrare le versioni e le eccezioni può diventare difficile.
Database dedicato
Ogni cliente, o un piccolo gruppo di clienti, dispone di un proprio database. Questo può facilitare la localizzazione dei dati, i ripristini selettivi e il rispetto di requisiti contrattuali che impongano risorse o limiti di accesso distinti. A seconda di come sono distribuiti i servizi, può anche ridurre l’impatto del carico o di un incidente sugli altri clienti.
Il costo è operativo: predisporre, aggiornare, monitorare, sottoporre a backup e testare molti database richiede automazione e risorse del team. Un database dedicato non protegge comunque da autorizzazioni eccessive, credenziali compromesse o errori nell’applicazione. È necessario verificare quale isolamento offra davvero la piattaforma scelta.
Criteri per decidere
Valuta i modelli in base ai requisiti concreti del prodotto, non a una preferenza astratta per la separazione. Documenta sia le esigenze attuali sia gli impegni che potrebbero incidere sull’evoluzione futura.
- Rischio di accesso incrociato: individua quali dati sono sensibili, quali soggetti vi accedono e in quali punti si può perdere il contesto del tenant. Definisci controlli preventivi e test negativi che tentino di accedere ai dati altrui.
- Requisiti dei clienti: verifica gli obblighi contrattuali e le esigenze di residenza, conservazione, ripristino o audit. Non considerare una richiesta di “database dedicato” un requisito legale senza averla convalidata con le funzioni responsabili.
- Gestione operativa: stima il lavoro necessario per distribuzioni, backup, ripristini, osservabilità, supporto e gestione degli incidenti. Valuta se il team può automatizzare queste attività in modo ripetibile.
- Variabilità del prodotto: clienti con versioni, estensioni o criteri molto diversi potrebbero richiedere confini più netti. Tuttavia, evitare una piattaforma comune può generare divergenze difficili da mantenere.
- Costo del cambiamento: chiediti come sposteresti un cliente, come convalideresti i dati trasferiti e quanto potrebbe durare la transizione. Una decisione iniziale semplice è più sicura se non preclude alternative future.
Una matrice decisionale aiuta a rendere espliciti i compromessi. Assegna un punteggio a ogni opzione rispetto a requisiti verificabili e distingui i criteri obbligatori da quelli desiderabili. Se un cliente richiede una condizione che il modello condiviso non può soddisfare, tale vincolo deve pesare più di una generica preferenza per la semplicità.
Controlli per un modello condiviso
Se scegli un database condiviso, considera l’identificativo del tenant una componente essenziale del progetto. Deve derivare da un’identità e da un contesto convalidati dal server, non da un valore arbitrario inviato dal browser. I livelli di accesso ai dati devono ricevere tale contesto in modo coerente ed evitare query prive di un ambito specifico per tenant.
Quando la tecnologia lo consente, definisci controlli su più livelli: vincoli del database, autorizzazioni limitate, criteri di accesso e verifiche nell’applicazione. Non considerarli intercambiabili: verifica quali si applicano nei tuoi processi, nelle connessioni e nelle attività amministrative. Per processi asincroni, code e attività pianificate, trasmetti e convalida esplicitamente il tenant.
Includi test automatici che creino almeno due tenant e verifichino letture, scritture, ricerche, esportazioni e operazioni di supporto. Aggiungi controlli per le nuove query e monitora indicatori come gli errori di autorizzazione, le query prive di contesto e le attività non riuscite. I log devono essere utili per indagare sugli incidenti, senza esporre inutilmente dati sensibili.
Quando adottare un approccio ibrido
Un modello ibrido abbina un database condiviso per la maggior parte dei clienti ad archivi separati per quelli che ne hanno una motivazione concreta. Può essere utile quando esistono differenze comprovate in termini di requisiti, volume, residenza o isolamento. Consente inoltre di iniziare con una gestione comune e riservare risorse specifiche ai casi in cui offrono un vantaggio.
Definisci le regole di assegnazione prima di introdurre eccezioni: quale requisito giustifica un database dedicato, chi approva la modifica, come si calcola il costo e quale supporto viene offerto. Mantieni un meccanismo comune per identificare la posizione di ogni tenant ed evita che la logica di business dipenda dai nomi o dagli indirizzi dei database. Senza criteri chiari, il modello ibrido diventa un insieme di casi speciali.
Progettare la migrazione e prendere una decisione rivedibile
Fin dall’inizio, separa l’identità del tenant dalla sua posizione fisica. Usa un livello di accesso che possa indirizzare le operazioni all’archivio corretto e automatizza il provisioning e le migrazioni. Quando possibile, mantieni le modifiche allo schema compatibili durante le transizioni e definisci come verificare conteggi, integrità e autorizzazioni prima di attivare la destinazione.
Una migrazione può richiedere di copiare i dati, interrompere le scritture oppure sincronizzare le modifiche e aggiornare l’instradamento. La procedura dipende dalla tecnologia e dai requisiti di continuità: provala, definisci una strategia di ripristino e comunica l’impatto previsto. Non dare per scontato che spostare un database dedicato sia sempre più semplice: volume, dipendenze e coerenza determinano la difficoltà.
Prima di concludere la decisione, rispondi per iscritto a queste domande:
- Quale unità rappresenta un tenant e da dove proviene il relativo contesto?
- Quali requisiti sono obbligatori e quali sono preferenze negoziabili?
- Quali controlli individuano e bloccano gli accessi tra clienti?
- Chi gestisce backup, ripristini, distribuzioni ed eccezioni?
- Quali indicatori giustificherebbero un cambio di modello e come verrebbe eseguita la migrazione?
Scegli il modello che soddisfa i requisiti con un livello operativo che il team sia in grado di sostenere. Rivedi la decisione quando cambiano i clienti, i rischi o le capacità della piattaforma. L’isolamento adeguato non è quello più complesso: è quello che offre controlli verificabili e può essere gestito in modo coerente.