Il multitenant è davvero la scelta giusta per gli IT Manager delle PMI?

In questo articolo

Per l’IT Manager di una PMI, il multitenant è una scelta corretta quando l’obiettivo è contenere i costi, semplificare gli aggiornamenti e scalare più velocemente senza moltiplicare le infrastrutture dedicate.
Per una PMI, il multitenant può essere una scelta molto efficiente, ma che non dovrebbe essere valutata solo sul fronte economico. Prima di adottare una soluzione di questo tipo, l’IT Manager deve capire come il vendor separa i dati dei clienti, gestisce gli accessi, monitora le performance, esegue i backup e garantisce la conformità alle normative.

Definizione di multitenant
Il multitenant permette a più aziende, utenti o business unit di condividere la stessa piattaforma applicativa, mantenendo separati dati, configurazioni e permessi. Per una PMI significa più efficienza, aggiornamenti centralizzati e costi minori. La vera domanda, però, è quale livello di isolamento serve: shared database, database per tenant, modello ibrido o istanza dedicata?

Multitenant significa che una stessa applicazione SaaS, infrastruttura cloud o piattaforma software serve più tenant, cioè più clienti, aziende, business unit o gruppi di utenti, mantenendo separati dati, configurazioni, identità e policy.

Per un IT Manager il tema è strategico perché incide su costi, scalabilità, SLA, RTO/RPO, compliance GDPR, gestione degli aggiornamenti e governance.
Per un vendor il multitenant consente di condividere risorse cloud, database, runtime applicativi, servizi IAM, logging, audit trail e monitoring ma senza creare un ambiente fisicamente dedicato per ogni cliente. Il vantaggio è evidente: meno infrastruttura da gestire, rollout più veloci, migliore utilizzo delle risorse e time-to-market più rapido. Il punto delicato per un vendor è l’isolamento: tenant ID, RBAC, policy, query scoping, cifratura e osservabilità devono essere progettati dall’inizio.

La differenza principale è il livello di condivisione delle risorse.

In un’architettura single tenant ogni cliente dispone di un ambiente dedicato: applicazione, database, infrastruttura o stack separato. È un modello più vicino al “silo”, con maggiore isolamento e una gestione più semplice di alcuni requisiti di audit, personalizzazione e data residency.

In un’architettura multitenant, invece, più clienti condividono una parte della piattaforma: lo stesso runtime, lo stesso database, lo stesso cluster o gli stessi servizi applicativi, con separazione logica tramite tenant ID, namespace, policy, schemi, RBAC o Row-Level Security.

Il single tenant privilegia controllo e isolamento, ma aumenta costi, provisioning, patching e overhead operativo. Il multitenant privilegia efficienza, scalabilità e aggiornamenti centralizzati, ma richiede più disciplina su sicurezza, monitoraggio e gestione dei workload. Il modello più maturo spesso è ibrido: tenant standard su pool condivisi, tenant premium o regolati su database o stack dedicati.

Sì, un ambiente multitenant può essere sicuro per i dati aziendali, ma solo se l’isolamento è progettato come requisito architetturale.

La sicurezza non dipende dal fatto che l’infrastruttura sia condivisa, ma da come vengono gestiti identità, autorizzazioni, segregazione dei dati, cifratura, logging, audit e backup. Un errore frequente è confondere le autorizzazioni con l’isolamento. Il fatto che un utente abbia i permessi corretti non garantisce automaticamente che query, cache, log o restore siano separati per tenant.

Per una PMI, i controlli minimi da verificare sono:

• tenant ID nei token o nel contesto applicativo
• policy RBAC o ABAC
• cifratura dei dati
• tracciamento tenant-aware
• separazione nei backup
• procedure di offboarding

Il vendor deve dimostrare come evita accessi cross-tenant e come testa l’isolamento.

La separazione dei dati in un sistema multitenant può avvenire a diversi livelli.

Il modello più economico è il database condiviso con schema condiviso, dove ogni record contiene un tenant ID e l’isolamento è garantito da logica applicativa, Row-Level Security o query scoping.

Un’altra tipologia di modello usa lo stesso database ma schemi o tabelle separate per tenant: è più leggibile e facilita alcune attività, ma complica aggiornamenti e versioning.

Un altro modello assegna un database a ciascun tenant, spesso dentro pool di risorse più elastici: costa di più, ma migliora il restore, l’auditing e l’isolamento dei dati.

Ci sono poi i tenant dedicati alle situazioni più critiche, che possono avere istanze o deployment stamp dedicati. Per le piccole e medie imprese, è necessario valutare il livello di separazione in base a rischio, budget, compliance e volumi.

Il vantaggio più immediato del multitenant è il costo marginale più basso per tenant. Condividendo infrastruttura, database, runtime, servizi di sicurezza e strumenti di monitoraggio, la piattaforma utilizza meglio le risorse e riduce sprechi tipici degli ambienti dedicati. In termini pratici, per una PMI significa sostenere un minor investimento iniziale, canoni più sostenibili e accesso a funzionalità enterprise senza dover gestire uno stack separato.

Per il vendor, sul fronte scalabilità, il multitenant consente di distribuire nuovi tenant più rapidamente, applicare autoscaling, gestire pool di risorse e spostare i clienti più pesanti verso tier superiori. Anche la manutenzione migliora grazie a patch, aggiornamenti, fix di sicurezza e nuove funzionalità rilasciati centralmente.
Il rovescio della medaglia è che serve governance: quote, rate limiting, osservabilità tenant-aware e controllo del noisy neighbor.

Una PMI può avere l’esigenza di gestire più tenant quando deve separare in modo netto ambienti, dati, utenti, configurazioni o policy. Va detto che non sempre “più tenant” significa maggiore efficienza e in molti casi è sufficiente un solo tenant ben organizzato, con ruoli, permessi e livelli di accesso correttamente configurati.

La scelta dipende quindi dal grado di separazione richiesto tra le diverse aree aziendali o operative.

Una PMI può valutare più tenant quando ha:

• più società o legal entity che devono mantenere dati, utenti e processi separati
• filiali estere con requisiti diversi di lingua, compliance, fiscalità o residenza del dato
• business unit molto autonome, con policy, workflow o responsabilità operative differenti
• brand, aziende acquisite o divisioni separate da gestire con configurazioni distinte
• ambienti separati per produzione, test, sviluppo o formazione, utili per evitare impatti sull’operatività quotidiana
• clienti finali da gestire separatamente, nel caso in cui la PMI eroghi a sua volta servizi digitali, software o piattaforme SaaS

Se l’obiettivo è solo distinguere reparti, sedi o gruppi di utenti, spesso bastano ruoli, permessi e policy ben configurate all’interno dello stesso tenant.

Il rischio più noto è il cross-tenant access, cioè la possibilità che dati, log, cache o backup di un tenant siano visibili a un altro per errore di configurazione, query o policy. Tra gli altri rischi ci può essere il noisy neighbor, ovvero un tenant con workload molto intenso può degradare le performance degli altri se non esistono quote, throttling e monitoraggio per tenant.

Poi ci sono altre criticità operative da verificare come restore granulare, audit, data residency, gestione delle chiavi, personalizzazioni e migrazioni tra modelli di isolamento. Per l’ IT Manager di una PMI, la domanda corretta al vendor è: “Come può essere dimostrato l’isolamento?”.
Servono prove come test automatici, logging tenant-aware, procedure di incident response, backup separabili e policy di accesso chiare.

Il multitenant va scelto con controlli e architettura adeguati.

Un IT Manager dovrebbe valutare una piattaforma multitenant con una checklist precisa con domande chiave come:

• come definite un tenant?
• dove viene gestito il tenant ID?
• i dati sono separati per riga, schema, database o istanza?
• esistono test automatici contro accessi cross-tenant?
• i log includono tenant ID, user ID, operation ID e outcome?
• è possibile fare restore per singolo tenant?
• come vengono gestiti noisy neighbor, quote e rate limiting?
• quali SLA, RTO e RPO sono garantiti per tenant o per piattaforma?
• dove risiedono i dati?
• sono disponibili customer-managed keys?
• come avvengono onboarding, offboarding e cancellazione dati?
• esiste un tenant catalog?
• è possibile migrare un tenant da shared a dedicated?

Conviene scegliere una soluzione multitenant quando l’obiettivo è ottimizzare costi, velocizzare onboarding, semplificare aggiornamenti, scalare in modo elastico e standardizzare processi su una platea di tenant con requisiti simili. È ideale per PMI che cercano efficienza, continuità e un modello SaaS sostenibile.

Conviene invece valutare single tenant o stack dedicati quando esistono requisiti stringenti di isolamento, audit, data residency, chiavi gestite dal cliente, workload molto irregolari, personalizzazioni profonde o vincoli di licensing. Un’altra soluzione è un approccio hybrid. Tenant standard su infrastruttura condivisa, tenant critici su database dedicati, tenant regolati su stamp o istanze separate.

Se la tua azienda sta valutando soluzioni SaaS, cloud o Microsoft 365 basate su modelli multitenant, possiamo aiutarti a scegliere correttamente.

In Infor affianchiamo le PMI nell’analisi degli ambienti IT, nella protezione delle identità, nella gestione dei backup, nel monitoraggio dei log e nella sicurezza dell’infrastruttura cloud. L’obiettivo è aiutare l’IT Manager a scegliere soluzioni efficienti, ma anche verificabili, sicure e coerenti con le esigenze dell’azienda e le normative in vigore.