Adversarial Review
Questa pagina documenta l’audit di sicurezza adversarial condotto sulla piattaforma Switchbord e il programma di remediation che ne è seguito. Il tracking dettagliato vive in Linear (BORD-149 fino a BORD-176). Per una tabella dello stato di implementazione in tempo reale, vedi Panoramica sulla Sicurezza.Audit sul Multi-Tenancy (BORD-149 – BORD-176)
È stata condotta una review adversarial strutturata rispetto alle dimensioni ISO 27001, GDPR, NIS2, HIPAA e SOC 2. L’audit si è concentrato su cinque aree di rischio:1. Isolamento del workspace e risoluzione del contesto
Riscontro: Diverse route API derivavano il contesto del workspace da variabili d’ambiente (readSingleWorkspace()) piuttosto che dalla sessione autenticata. Questo pattern è incompatibile con il multi-tenancy — un’assunzione single-tenant permetterebbe a una richiesta creata ad arte di agire come qualsiasi workspace.
Remediation: readSingleWorkspace() è stata deprecata e rimossa da tutti i percorsi di codice in produzione. Tutte le route ora chiamano resolveCallerWorkspaceFromSupabase(userId), che risolve il contesto del workspace da workspace_members lato server. Tutte le 13 route delle impostazioni sono state auditate e ricablate con requireSettingsAccess() come prima operazione.
Vedi Multi-Tenancy e Isolamento dei Workspace.
2. Gap di autenticazione dell’assistente AI
Riscontro: L’endpoint/api/ai-assistant era raggiungibile senza autenticazione. Qualsiasi chiamante non autenticato poteva inviare prompt elaborati con le credenziali LLM del workspace.
Remediation: È stata aggiunta una protezione di autenticazione (auth guard). L’endpoint ora richiede una sessione valida e risolve il contesto del workspace prima dell’elaborazione. Il contesto AI è limitato solo ai contatti e alle conversazioni all’interno del workspace del chiamante.
3. Storage dei segreti
Riscontro: I token di accesso Meta e i segreti di firma dei webhook venivano letti da variabili d’ambiente in alcuni percorsi, creando un’assunzione single-tenant e impedendo la rotazione dei segreti per singolo workspace. Remediation: Tutti i segreti dei provider (token Meta, segreti di firma dei webhook, chiavi API LLM) sono memorizzati in Supabase Vault con ambito per workspace, accessibili tramiteworkspace_secret_bindings. I fallback su variabili d’ambiente sono bloccati in produzione.
Vedi Gestione dei Segreti e Crittografia.
4. Ciclo di vita della sessione e dell’accesso
Riscontro: La rimozione di un membro non revocava le sessioni attive. Un membro rimosso poteva continuare a operare fino alla scadenza del proprio token. Remediation: La rimozione di un membro ora chiamasignOut per revocare immediatamente la sessione attiva. La policy di sessione applica un timeout assoluto di 8 ore e un timeout di inattività di 1 ora.
Vedi Autenticazione e Controllo Accessi.
5. Lacune di conformità GDPR
Riscontro: Non esistevano endpoint per i diritti dell’interessato (data subject rights). I dati personali (PII) dei contatti potevano essere esportati o eliminati solo tramite accesso diretto al database. Remediation: Sono stati implementati gli endpoint GDPR:GET /api/contacts/[id]/gdpr— esportazione strutturata (Art.15/20)DELETE /api/contacts/[id]/gdpr— anonimizzazione in-place (Art.17)
audit_logs. La policy di conservazione dei dati (data_retention_days) è configurabile per workspace.
Vedi Protezione dei Dati e GDPR.
Elementi Pianificati Rimanenti
I seguenti elementi dell’audit sono ancora in corso e vengono tracciati in Linear:Postura di Review Continua
Ogni PR di funzionalità importante deve includere:- una sezione di controlli adversarial nella descrizione della PR
- l’identificazione di eventuali nuovi percorsi di accesso ai dati e se sono limitati al workspace (workspace-scoped)
- l’identificazione di eventuali nuovi segreti o credenziali e se sono memorizzati in Vault
- una nota di rollback
planning/linear/BACKLOG.yaml e negli issue Linear sincronizzati. Non mantenere i riscontri aperti solo in questo documento.