Architettura Multi-Tenant per il Software della PA: cosa significa e perché conviene

Le tre architetture a confronto

Single-instance

Ogni cliente ha la sua installazione dedicata: server, applicazione, database. È il modello classico dell'on-premise e dell'hosted tradizionale. Massimo isolamento, costi massimi, aggiornamenti gestiti uno a uno.

Single-tenant in cloud

Stessa applicazione, ma ogni cliente ha una propria istanza isolata sull'infrastruttura cloud del fornitore. Aggiornamenti rilasciati per istanza, costi intermedi, buon isolamento.

Multi-tenant

Una sola istanza dell'applicazione serve molti clienti (tenant) che condividono l'infrastruttura ma i cui dati sono logicamente segregati. Aggiornamenti rilasciati una volta per tutti, costi minimi, isolamento garantito a livello applicativo e di database.

I modelli di isolamento dei dati

All'interno del paradigma multi-tenant esistono tre principali modalità con cui i dati vengono separati a livello di database:

1. Database separati (database-per-tenant)

Ogni tenant ha un proprio database fisicamente distinto, anche se gestito dallo stesso motore. Massimo isolamento, semplicità nelle operazioni di backup e ripristino del singolo cliente, possibilità di portare via i dati di un tenant senza toccare gli altri. Costi infrastrutturali più alti.

2. Schema separati (schema-per-tenant)

Un unico database, ma ciascun tenant ha uno schema logico distinto. Buon compromesso tra isolamento e costi, gestione operativa più semplice di N database. È un modello molto usato in PostgreSQL e SQL Server.

3. Tabelle condivise (shared schema)

Tutti i tenant condividono le stesse tabelle, distinte da una colonna tenant_id. Massima efficienza infrastrutturale, costi minimi, ma l'isolamento dipende interamente dalla qualità del codice applicativo. Richiede policy di sicurezza (per esempio le Row Level Security di PostgreSQL) per evitare che un bug esponga dati di un cliente a un altro.

Una piattaforma multi-tenant ben progettata può adottare modelli misti: shared schema per i dati di basso rischio (configurazioni, metadati), database-per-tenant per i dati personali e per i contenuti delle pratiche.

Multi-tenant e GDPR

Il principale dubbio di un ente che valuta una piattaforma SaaS multi-tenant riguarda il trattamento dei dati personali. Il GDPR non vieta architetture multi-tenant: richiede che il titolare del trattamento (l'ente) garantisca, anche tramite il responsabile (il fornitore del software), misure tecniche e organizzative adeguate.

In pratica, un'architettura multi-tenant è conforme al GDPR quando:

• l'isolamento dei dati è garantito a livello applicativo e di database;
• esistono cifrature in transito (TLS) e a riposo (encryption at rest);
• i log accessi consentono di ricostruire chi ha letto cosa e quando;
• il contratto tra ente e fornitore (DPA, Data Processing Agreement) descrive ruoli, sub-responsabili, tempi di conservazione, procedure di portabilità e cancellazione;
• i dati restano nello Spazio Economico Europeo, su infrastrutture qualificate ACN per il livello adeguato di criticità.

Una soluzione URP multi-tenant progettata fin dall'inizio per la PA italiana risolve questi requisiti in modo nativo, senza richiedere all'ente di vigilare su dettagli infrastrutturali.

Configurazioni indipendenti per ente

Un equivoco frequente è pensare che multi-tenant significhi "tutti vedono la stessa cosa". Non è così. Ogni tenant può avere:

• branding proprio (logo, colori, font, dominio personalizzato);
• flussi di lavoro diversi (categorie di segnalazione, stati delle pratiche, regole di assegnazione);
• ruoli e permessi propri, con organigramma interno modellabile;
• moduli funzionali attivati o disattivati in base alle esigenze;
• integrazioni verso sistemi locali diversi (protocollo, gestionali, anagrafe).

La configurazione vive nella base dati del tenant e viene applicata a runtime dall'applicazione. Un Comune di 5.000 abitanti e un'ASL di 500.000 utenti usano lo stesso codice ma vivono due esperienze profondamente diverse.

Sicurezza e perché multi-tenant non è meno sicuro

L'obiezione tradizionale al multi-tenant è la sicurezza: "se i dati condividono l'infrastruttura, il rischio aumenta". È un'obiezione che merita di essere sfatata. Le piattaforme multi-tenant mature di livello enterprise adottano:

• controlli di accesso a più livelli (rete, applicazione, database);
• cifrature end-to-end con chiavi separate per tenant;
• monitoraggio continuo (SIEM) con alerting automatico;
• audit log immutabili;
• penetration test periodici e bug bounty;
• processi di vulnerability management con SLA di patching definiti.

Un ente piccolo o medio difficilmente potrebbe permettersi internamente questo livello di postura di sicurezza su un'installazione on-premise. Paradossalmente, un multi-tenant cloud ben gestito è spesso più sicuro di un on-premise gestito con risorse limitate.

Vantaggi economici e operativi

Il vantaggio economico del multi-tenant deriva dall'economia di scala: i costi fissi dell'infrastruttura, della cybersecurity, degli aggiornamenti normativi sono spalmati su molti enti. Il singolo ente paga un canone che, in valore assoluto, è una frazione del TCO che sosterrebbe se gestisse tutto da solo.

Sul piano operativo, un aggiornamento normativo (per esempio l'adeguamento a una nuova Linea Guida AgID) viene rilasciato una volta sola e diventa immediatamente disponibile a tutti gli enti. Lo stesso vale per le nuove funzionalità: ciò che oggi viene sviluppato per le esigenze di un ente, domani arricchisce la piattaforma per tutti.

Take-away: 5 punti chiave

• Il multi-tenant è il modello architetturale standard del software SaaS moderno, inclusi i gestionali per la PA.
• L'isolamento dei dati può avvenire a livello di database, schema o tabella: ogni modello ha trade-off precisi.
• Il GDPR non vieta il multi-tenant: richiede misure tecniche e contrattuali adeguate.
• Ogni tenant resta configurabile in modo indipendente: branding, flussi, ruoli, moduli, integrazioni.
• Economia di scala e aggiornamenti centralizzati rendono il multi-tenant il modello con il miglior rapporto costo/sicurezza per la PA.