Skip to main content

Modello di Isolamento

Switchbord è una piattaforma multi-tenant in cui ogni organizzazione tenant opera come un workspace indipendente. La garanzia di isolamento è la seguente:
Un utente nel workspace A non può leggere, scrivere o agire sui dati appartenenti al workspace B — indipendentemente da come vengono costruite le chiamate API.
Questa garanzia è applicata lato server a livello di API, non tramite routing lato client o controlli dell’interfaccia utente da soli.

Risoluzione del Contesto del Workspace

resolveCallerWorkspaceFromSupabase(userId)

Ogni route API autenticata risolve il contesto del workspace interrogando la tabella workspace_members con l’ID dell’utente autenticato:
Proprietà principali:
  • Legge da workspace_members, non da variabili d’ambiente
  • Restituisce il workspace a cui l’utente appartiene effettivamente — non può essere sovrascritto dai parametri della richiesta
  • Genera immediatamente un’eccezione se l’utente non è membro di alcun workspace
  • Utilizzata come fondamento per tutti gli accessi ai dati con ambito workspace

requireSettingsAccess()

Tutte le 13 route API delle impostazioni utilizzano requireSettingsAccess() come prima operazione, che chiama resolveCallerWorkspaceFromSupabase e applica un livello di ruolo minimo prima che qualsiasi dato delle impostazioni venga letto o scritto:
Non passare mai workspaceId come parametro di query o campo del corpo della richiesta utilizzato per l’autorizzazione. Derivarlo sempre lato server dalla sessione autenticata.

Pattern Deprecato: readSingleWorkspace()

La funzione readSingleWorkspace() leggeva la configurazione del workspace da variabili d’ambiente, il che è incompatibile con la multi-tenancy. È stata deprecata e rimossa da tutti i percorsi di codice di produzione. Percorso di migrazione per qualsiasi codice che la referenzia ancora:

Threading delle Route delle Impostazioni

Tutte le 13 route API delle impostazioni fanno passare (thread) il workspaceId derivato da requireSettingsAccess() attraverso ogni query a valle. Nessuna route delle impostazioni legge dati del workspace senza prima stabilire il contesto del workspace del chiamante. Esempio di pattern per una route delle impostazioni:

Isolamento del Dispatch dei Messaggi

La funzione dispatchMessageViaMetaInSupabase legge le credenziali Meta dal workspace identificato da job.workspace_id — il workspace che possiede il job, non una configurazione globale:
Ciò significa che:
  • Il Workspace A non può causare l’invio di messaggi tramite il numero di telefono Meta del Workspace B
  • La fuoriuscita di credenziali tra tenant a livello di dispatch è strutturalmente impossibile
  • Ogni workspace configura e ruota il proprio token di accesso Meta in modo indipendente

Modello di Adesione Solo su Invito

Gli utenti possono aderire a un workspace solo tramite un invito esplicito da parte di un admin o owner esistente del workspace. Non esiste alcun flusso di scoperta o adesione self-service. Ciò garantisce che:
  • L’appartenenza al workspace sia sempre intenzionale
  • I nuovi membri ricevano solo il ruolo esplicitamente concesso dall’admin che invita
  • La rimozione di un membro revochi immediatamente tutti gli accessi, incluse le sessioni attive
Vedi Autenticazione e Controllo degli Accessi per i dettagli sulla revoca delle sessioni.

Ambito delle API Key

Le API key hanno ambito limitato al workspace che le ha create. Tutte le operazioni sulle API key (elenco, eliminazione, revoca) filtrano in base al workspace_id risolto del chiamante:

Isolamento dell’Assistente AI

L’endpoint /api/ai-assistant in precedenza non disponeva di un auth guard. Ora richiede l’autenticazione e risolve il contesto del workspace prima di elaborare qualsiasi richiesta. Il contesto AI ha ambito limitato ai contatti e alle conversazioni all’interno del solo workspace del chiamante.

Mappatura della Conformità

Per la mappatura completa dei controlli di conformità, vedi la Matrice di Conformità.