> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Adversarial Review

> Risultati dell'audit di sicurezza, stato della remediation e hardening continuo per la piattaforma Switchbord.

# 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](/it/security/overview).

## 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](/it/security/multi-tenancy).

### 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 tramite `workspace_secret_bindings`. I fallback su variabili d'ambiente sono bloccati in produzione.

Vedi [Gestione dei Segreti e Crittografia](/it/security/secrets-and-encryption).

### 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 chiama `signOut` 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](/it/security/authentication).

### 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)

Entrambe le operazioni scrivono su `audit_logs`. La policy di conservazione dei dati (`data_retention_days`) è configurabile per workspace.

Vedi [Protezione dei Dati e GDPR](/it/security/data-protection).

## Elementi Pianificati Rimanenti

I seguenti elementi dell'audit sono ancora in corso e vengono tracciati in Linear:

| Elemento                                                                | Ticket   |
| ----------------------------------------------------------------------- | -------- |
| Instradamento webhook con ambito phone\_number\_id                      | BORD-157 |
| Claim workspace JWT nell'auth Supabase                                  | BORD-155 |
| Applicazione dell'autenticazione tramite edge middleware                | BORD-156 |
| Rate limiting per workspace                                             | BORD-162 |
| Audit logging degli accessi in lettura + catena a prova di manomissione | BORD-168 |
| Crittografia PII a livello di colonna                                   | BORD-171 |
| Rilevamento incidenti e notifica delle violazioni                       | BORD-166 |
| SBOM e dependency scanning                                              | BORD-170 |

## 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

I problemi di hardening sono tracciati in `planning/linear/BACKLOG.yaml` e negli issue Linear sincronizzati. Non mantenere i riscontri aperti solo in questo documento.