Architettura multi-tenant: perché è necessaria per i sistemi di composizione automatica dei numeri.

Se gestisci un'azienda di BPO, un'attività di rivendita o qualsiasi altra attività che serve più clienti sulla stessa piattaforma di composizione automatica, il multi-tenancy non è un optional, ma il fondamento su cui si basa tutto il resto.

Cosa significa realmente la multi-occupazione

Il multi-tenancy significa che più clienti indipendenti (tenant) condividono la stessa infrastruttura software, pur avendo dati, configurazioni e regole di conformità completamente isolati. Ogni tenant opera come se avesse un proprio sistema dedicato, ma la piattaforma sottostante è condivisa.

La parola chiave è isolationNon separazione. Non filtraggio. Isolamento.

Perché l'isolamento è importante

Protezione dei dati. I contatti, le registrazioni delle chiamate, i dati degli agenti e i risultati delle campagne del Cliente A devono essere invisibili al Cliente B. Non solo nascosti, ma dimostrabilmente inaccessibili. Se uno sviluppatore commette un errore in una query, il database deve comunque impedire l'accesso ai dati tra tenant diversi.

Indipendenza in materia di conformità. Il Cliente A potrebbe operare secondo le normative TDRA (Emirati Arabi Uniti). Il Cliente B secondo le normative CITC (Arabia Saudita). Il Cliente C secondo le normative TCPA (Stati Uniti). Ogni inquilino necessita di proprie regole di conformità, liste DNC (Do Not Call), orari di chiamata e tracciamento del consenso. Una violazione delle norme di conformità da parte di un inquilino non può pregiudicare gli altri.

Isolamento della registrazione. Le registrazioni delle chiamate sono i dati più sensibili in un contact center. Le registrazioni di ciascun cliente devono essere archiviate in percorsi di archiviazione isolati con controlli di accesso specifici per ogni cliente. Un URL firmato per la registrazione del Cliente A non deve mai funzionare per il Cliente B.

Isolamento della fatturazione. Ogni inquilino ha un proprio numero di agenti, metriche di utilizzo e ciclo di fatturazione. I dati di fatturazione devono essere accurati per ciascun inquilino, senza alcuna contaminazione incrociata.

Il metodo sbagliato: il filtraggio a livello di applicazione

Molti dialer implementano la "multi-tenancy" con un semplice DOVE tenant_id = ? Un filtro viene aggiunto al codice della loro applicazione. Ogni query aggiunge questo filtro. Funziona... finché qualcuno non se ne dimentica.

I problemi:

• Un filtro mancato = perdita di dati tra i tenant
• Le query complesse con join sono facili da sbagliare
• Le query di aggregazione (report, dashboard) sono particolarmente rischiose
• Non esiste alcuna rete di sicurezza quando l'applicazione commette un errore.

Il filtraggio a livello di applicazione non è isolamento. È un filtro che si basa sul principio del "meglio del meglio", che dipende dalla capacità di ogni sviluppatore, per ogni query e in ogni percorso del codice, di fare tutto correttamente al 100%. E questo non è sufficiente.

Il modo giusto: isolamento a livello di database

DialerBee utilizza la sicurezza a livello di riga (RLS) di PostgreSQL come livello di difesa multilivello. Ecco come funziona:

1. Ogni tavolo di proprietà dell'affittuario ha un tenant_id column
2. Le policy RLS sono abilitate e FORZATE su ogni tabella tenant
3. All'inizio di ogni transazione del database, impostiamo IMPOSTA LOCALE app.current_tenant_id = :tid
4. Il database stesso filtra ogni query — SELECT, INSERT, UPDATE, DELETE — per restituire solo le righe corrispondenti al tenant corrente
5. L'utente dell'applicazione non dispone dell'autorizzazione BYPASSRLS: nemmeno le query SQL grezze possono sfuggire al filtro.

Questo significa che anche se il codice dell'applicazione presenta un bug (una clausola WHERE mancante, un JOIN errato, un'aggregazione senza raggruppamento), il database impedisce l'accesso ai dati tra tenant diversi. Il filtro dell'applicazione è la difesa primaria. RLS è la rete di sicurezza.

Test di isolamento

Affermare che l'isolamento è sufficiente non basta. Bisogna dimostrarlo. DialerBee esegue test di isolamento del tenant avversari su ogni endpoint API:

1. L'inquilino A crea una risorsa (contatto, campagna, registrazione, ecc.).
2. Il tenant B tenta di ottenere, applicare patch e cancellare quella risorsa.
3. Ogni tentativo deve restituire 404 (non trovato), mai 403 (vietato).

Perché 404 invece di 403? Perché 403 ("non hai l'autorizzazione") conferma l'esistenza della risorsa. 404 ("non trovata") non rivela nulla. Il tenant B non dovrebbe nemmeno sapere che la risorsa esiste.

Questi test vengono eseguiti in CI a ogni modifica del codice. Se un test fallisce, il codice non viene unito.

Cosa dovrebbero pretendere i partner

Se stai valutando un dialer per un utilizzo white-label o come rivenditore, poniti queste domande:

• L'isolamento dei tenant viene applicato a livello di database o solo nel codice dell'applicazione?
• Potresti mostrarmi la suite di test per l'isolamento avversariale?
• Cosa succede se una query omette accidentalmente il filtro del tenant?
• Le registrazioni delle chiamate vengono memorizzate in percorsi isolati a livello di tenant?
• La violazione delle norme da parte di un inquilino può avere ripercussioni su un altro inquilino?
• Se creo un tenant tramite il portale partner, viene immediatamente isolato da tutti gli altri tenant?

Se la risposta a una qualsiasi di queste domande è vaga, continuate a cercare. Un sistema multi-tenant gestito male è peggio di non averne affatto, perché vi dà un falso senso di sicurezza.