Indice dei contenuti
Un gestionale nato per una singola attività può diventare un servizio utilizzato da decine di aziende. Ma per trasformarlo in SaaS non basta aggiungere una pagina di registrazione: bisogna garantire che ogni organizzazione possa accedere soltanto ai propri dati. 🏗️
Che cosa significa multi-tenant?
Un tenant è un’organizzazione che utilizza la piattaforma: per esempio un salone, uno studio o un’azienda. Più tenant condividono il software, ma i rispettivi dati devono restare separati. È un requisito di sicurezza e di correttezza applicativa, non soltanto una scelta commerciale.
Tre modelli di database
Database condiviso con tenant_id
Le organizzazioni condividono le tabelle, ma ogni record applicativo è associato a un tenant. È una soluzione pratica per molti MVP PHP e MariaDB. Richiede però che ogni query rispetti il contesto tenant.
Database separato per ogni tenant
Ogni organizzazione ha uno spazio dati distinto. Questo facilita alcuni aspetti dell’isolamento, ma rende più complessi provisioning, migrazioni, backup e monitoraggio.
Architettura ibrida
Alcuni dati restano condivisi, altri sono separati. Può essere utile quando esistono esigenze particolari, ma aumenta il numero di percorsi applicativi da mantenere.
Non fidarti del tenant inviato dal browser 🔐
Un parametro tenant_id modificabile dal client non è una prova di autorizzazione. Il server deve determinare quali organizzazioni sono accessibili all’utente autenticato e verificare i permessi prima di leggere o modificare risorse.
Se una persona collabora con più aziende, conviene usare una tabella di appartenenza che associ utenti, tenant e ruoli. Lo stesso utente può essere amministratore in un’organizzazione e collaboratore in un’altra.
Una query deve conoscere il tenant
Recuperare un appuntamento soltanto tramite il suo ID può essere rischioso. Un controllo più robusto vincola la risorsa al tenant autorizzato:
SELECT id, starts_at, customer_id
FROM appointments
WHERE id = :appointment_id
AND tenant_id = :tenant_id
LIMIT 1;Le query parametrizzate riducono il rischio di SQL injection, ma non sostituiscono i controlli di autorizzazione. Sono due misure complementari.
Indici e prestazioni ⚡
Se le query filtrano frequentemente per tenant, gli indici composti possono essere utili. La scelta va però verificata sui dati e sulle query reali, ad esempio utilizzando EXPLAIN. Anche alcuni vincoli di unicità devono essere definiti all’interno del tenant anziché globalmente.
File, cache e processi in background
L’isolamento non finisce nel database. Allegati accessibili con URL prevedibili, chiavi di cache condivise e job senza contesto tenant possono esporre dati tra organizzazioni. Occorre applicare le stesse regole ad API, esportazioni, email, webhook e attività pianificate.
Super admin e amministratori: due responsabilità diverse
Il gestore della piattaforma deve poter amministrare piani e configurazioni globali. Gli amministratori dei tenant devono invece operare soltanto all’interno della propria organizzazione. Gli interventi privilegiati meritano tracciabilità e controlli dedicati.
Come verificare l’isolamento 🧪
Crea due tenant con utenti e dati distinti. Accedi come utente del primo e prova a richiedere, modificare o esportare una risorsa del secondo. Ripeti il test per API, allegati, ricerca e processi asincroni. Controlla sia la risposta HTTP sia gli effetti sul database.
Serve un’architettura complessa?
Non necessariamente. Un monolite PHP ben strutturato può essere una base adeguata per un SaaS multi-tenant. Separare il sistema in microservizi non risolve automaticamente problemi di autorizzazione o qualità dei dati.
💡 In conclusione: il vero fondamento della multi-tenancy è applicare regole di isolamento coerenti in ogni punto del software, con test che dimostrino che funzionano.
FAQ
Un database condiviso è sempre insicuro?
No. Può essere una scelta valida se autorizzazioni e isolamento vengono implementati e verificati correttamente.
Posso convertire un gestionale esistente?
Sì, dopo un audit di schema, query, ruoli e flussi di accesso ai dati, preferibilmente lavorando prima su una copia.
Serve Kubernetes?
No. La multi-tenancy riguarda soprattutto applicazione, dati e autorizzazioni; l’orchestrazione è una decisione infrastrutturale distinta.
Approfondimenti correlati
Un progetto correlato: Casintesa: gestione immobili in comproprietà.