Perché i dati del workplace richiedono un database isolato

Quando un team IT o di sicurezza valuta uno strumento di prenotazione workplace, il questionario di solito chiede della crittografia, del single sign-on e di dove si trovano i server. Raramente pone la domanda che conta di più per questa categoria di dati: i dati della nostra organizzazione sono fisicamente separati da quelli di ogni altro cliente, o sono una colonna in una tabella condivisa?

La prenotazione delle scrivanie sembra un dato a basso rischio finché non elenchi cosa contiene: chi era in quale edificio in quale giorno, a quale scrivania, accanto a chi, con quali visitatori, e dove ha parcheggiato l'auto. È un registro degli spostamenti della tua forza lavoro. Merita lo stesso isolamento che pretenderesti per i dati HR o delle buste paga.

Questo articolo spiega i due modi in cui i fornitori SaaS archiviano i dati multi-tenant, perché Desk & Park dà a ogni organizzazione il proprio database isolato, e cosa significa quella decisione per le persone che approvano sicurezza, privacy e compliance.

Due architetture, un compromesso

Quasi ogni prodotto SaaS è multi-tenant: un'applicazione serve molti clienti. La domanda è dove vive il confine tra i clienti.

Database condiviso, colonna tenant

L'approccio comune. Le righe di ogni cliente stanno nelle stesse tabelle, e ogni riga porta un tenant_id. Ogni query deve filtrare su di esso. L'applicazione, non il database, è responsabile di tenere separati i clienti.

È popolare perché costa poco da gestire: un database, uno schema, una migrazione. È anche l'origine di un'intera classe di incidenti di sicurezza. Un solo WHERE tenant_id = ? mancante in una delle migliaia di query, un report che fa join tra tabelle senza il filtro, un bug di caching, e il cliente A vede i dati del cliente B. Questi bug non sono ipotetici; sono una categoria ricorrente di violazioni SaaS rese pubbliche, e sono difficili da trovare perché ogni singola query sembra corretta.

Database isolato per organizzazione

Ogni cliente ha il proprio database, con le proprie tabelle, le proprie credenziali e i propri backup. L'applicazione si connette al database giusto per l'organizzazione che effettua la richiesta. Non c'è nessun filtro tenant_id da dimenticare, perché non c'è nessun altro tenant nel database da cui far trapelare dati.

Costa al fornitore più disciplina operativa: provisioning, migrazione e monitoraggio di centinaia o migliaia di database invece di uno. Quel costo è il punto. Lo paga il fornitore, una volta, in ingegneria, invece del cliente, più tardi, in un incidente.

Come è costruito Desk & Park

Desk & Park utilizza un'architettura database-per-organizzazione. Concretamente:

Un control plane contiene solo ciò che serve per instradare e fatturare: nomi delle organizzazioni, piano, la mappatura da un'organizzazione al suo database, e l'audit trail della piattaforma stessa. Non contiene prenotazioni, planimetrie né directory dei dipendenti.
Un database PostgreSQL per organizzazione contiene tutto ciò che riguarda quell'organizzazione: utenti, ruoli, sedi, mappe, scrivanie, posti auto, sale, prenotazioni, check-in, visitatori, notifiche e l'audit log dell'organizzazione.
Credenziali per organizzazione. L'applicazione apre una connessione al database di un'organizzazione con credenziali limitate a quel database. Una richiesta dell'organizzazione A non può essere eseguita sul database dell'organizzazione B nemmeno per errore, perché non detiene mai una connessione ad esso.
Backup, ripristino e cancellazione per organizzazione. I backup vengono eseguiti per database. Ripristinare un'organizzazione allo stato di ieri non tocca nessun altro. Eliminare un'organizzazione alla fine di un contratto significa eliminare il suo database, che è una cancellazione verificabile e completa anziché un DELETE WHERE tenant_id che spera di aver trovato ogni riga.

Il codice dell'applicazione è condiviso; i dati no. Questo è il confine che un auditor può indicare.

Cosa compra l'isolamento per chi deve approvare

Per il CISO: un raggio d'impatto più piccolo

Una vulnerabilità in uno strato di query multi-tenant espone tutti i clienti contemporaneamente. Con database isolati, la stessa classe di bug non può attraversare il confine di un'organizzazione, perché il confine è imposto dal motore del database e dalle credenziali di connessione, non dalla logica applicativa. L'isolamento non rende un'applicazione immune ai bug; trasforma un bug in un punto in un problema di un singolo cliente invece che dell'intera piattaforma.

Per il DPO: risposte chiare alle domande GDPR

Le revisioni sulla protezione dei dati pongono domande prevedibili, e il database-per-organizzazione dà loro risposte brevi.

Domanda	Risposta con un database isolato
Dove sono i nostri dati?	Nel vostro database, nella regione UE della piattaforma, separati da tutti gli altri clienti.
Chi può accedervi?	L'applicazione, con credenziali limitate al vostro database, e il personale di reperibilità dell'operatore secondo la procedura di accesso documentata.
Potete dimostrare la cancellazione?	Sì: il vostro database viene eliminato e l'eliminazione è registrata nell'audit trail della piattaforma.
Potete ripristinare solo i nostri dati?	Sì: i backup sono per organizzazione.
Potete esportare tutto?	Sì: un'esportazione è un dump di un solo database, non un estratto filtrato.

Il diritto alla cancellazione e l'obbligo di limitare il trattamento diventano operazioni sul database con un ambito chiaro anziché funzionalità applicative da testare per completezza.

Per il responsabile compliance: un controllo difendibile

Framework come ISO 27001 e SOC 2 chiedono a un fornitore di dimostrare la separazione logica tra i clienti. "Ogni query filtra sul tenant" è un controllo che deve essere riverificato per ogni nuova query. "Ogni cliente ha il proprio database e le proprie credenziali" è un controllo verificato una volta, strutturalmente, e che regge man mano che il prodotto cresce. Il secondo è molto più facile da documentare, sia per il fornitore sia per l'audit interno del cliente.

Per il CIO: prestazioni e ciclo di vita prevedibili

Il report pesante di un'organizzazione non rallenta la corsa al check-in mattutino di un'altra, perché non condividono tabelle né indici. Le migrazioni vengono distribuite per database, così un problema può essere intercettato su un'organizzazione prima che raggiunga la successiva. L'offboarding è un'eliminazione, non un progetto di pulizia.

Il resto della storia sulla sicurezza

L'isolamento è la fondazione, non l'intero edificio. I controlli che i team IT si aspettano si appoggiano sopra, e vale la pena elencarli perché una buona architettura con un'autenticazione debole resta debole:

Single sign-on tramite OpenID Connect con il vostro identity provider, e provisioning SCIM così i nuovi assunti e chi lascia l'azienda vengono creati e disattivati dalla vostra directory, non a mano.
Autenticazione a due fattori (TOTP) e passkey (WebAuthn), con una policy a livello di organizzazione per rendere obbligatoria la MFA.
Policy di sicurezza per organizzazione: timeout di sessione, regole per le password, allowlist di IP.
Gestione delle sessioni attive così un amministratore può vedere e revocare le sessioni.
Un audit log per organizzazione che registra chi ha modificato cosa, nel database dell'organizzazione stessa.
Pagamenti tramite Stripe, così i dati delle carte non raggiungono mai la piattaforma.
Accesso basato sui ruoli: i dipendenti vedono e prenotano; gli amministratori configurano; i membri del consiglio e i manager ottengono report limitati ai loro team.

Nessuno di questi è insolito nel SaaS enterprise. Ciò che è insolito è combinarli con uno strato dati in cui il confine tra clienti è fisico.

Domande da porre a qualsiasi fornitore workplace

Se stai confrontando strumenti, queste cinque domande separano il marketing dall'architettura:

I nostri dati sono in un database dedicato, o in tabelle condivise con una colonna tenant?
Backup, ripristini e cancellazioni vengono eseguiti per cliente?
Quali credenziali usa l'applicazione per raggiungere i nostri dati, e sono limitate a noi?
Come documentate la separazione tra clienti ai vostri auditor?
Un bug in un report o in un'esportazione può mai restituire le righe di un altro cliente?

Un fornitore con un database isolato risponde a tutte e cinque con una frase ciascuna. Un fornitore con un database condiviso deve descrivere un processo di test.

L'isolamento dovrebbe essere lo standard

I dati del workplace sono dati personali sulla presenza fisica dei tuoi dipendenti. L'architettura più economica per il fornitore mette quei dati accanto a quelli di ogni altro cliente e si affida all'applicazione per tenerli separati. Desk & Park ha scelto quella più costosa, così che il confine tra organizzazioni sia un database, non un filtro.

Puoi leggere i dettagli tecnici nella sintesi dell'architettura nella pagina come funziona e nell'informativa sulla privacy della piattaforma. Per un rollout enterprise con single sign-on, SCIM e una revisione di sicurezza, la pagina dei prezzi ha il contatto Enterprise.