> ## 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.
# Panoramica sulla Sicurezza
> L'architettura security-first di Switchbord per le operazioni WhatsApp enterprise — ISO 27001, GDPR, NIS2, HIPAA-ready e allineata a SOC 2.
## Architettura Security-First
Switchbord è una piattaforma multi-tenant per le operazioni WhatsApp che elabora PII di clienti organizzativi su larga scala. La sicurezza non è un ripensamento — è integrata nell'architettura a ogni livello: dal modo in cui il contesto del workspace viene risolto a ogni chiamata API, a come vengono memorizzati i segreti, a come le PII vengono gestite prima di raggiungere qualsiasi modello AI.
È stato condotto un audit di sicurezza in modalità adversarial lungo le dimensioni ISO 27001, GDPR, NIS2, HIPAA e SOC 2. I risultati hanno guidato un programma di remediation strutturato (da BORD-149 a BORD-176) attualmente in corso.
Questa documentazione riflette lo stato dei controlli di sicurezza alla release corrente. Gli elementi contrassegnati come **Pianificato** sono tracciati in Linear e verranno implementati negli sprint futuri.
## Obiettivi di Conformità
Controlli del sistema di gestione della sicurezza delle informazioni. Controlli dell'Annex A mappati su controllo degli accessi, crittografia, sicurezza operativa e rapporti con i fornitori.
Piena conformità alla normativa UE sulla protezione dei dati. Diritti degli interessati (Art.15, 17, 20), base giuridica, DPA con sub-processor, privacy by design (Art.25).
Direttiva UE sulla sicurezza delle reti e dei sistemi informativi. Misure di gestione del rischio (Art.21), obblighi di segnalazione degli incidenti (Art.23).
Salvaguardie tecniche allineate a HIPAA §164.312. Controlli di accesso, controlli di audit, controlli di integrità e sicurezza della trasmissione. Non è un covered entity per impostazione predefinita — consultare il proprio responsabile della conformità.
Mappatura dei Trust Service Criteria su CC1–CC9. Controlli di accesso logico, gestione dei cambiamenti, monitoraggio e disponibilità documentati e parzialmente implementati.
## Pilastri dell'Architettura
### Isolamento per Workspace
Ogni tenant opera in un workspace completamente isolato. Il contesto del workspace viene risolto lato server dal record `workspace_members` dell'utente autenticato — mai da variabili d'ambiente o header forniti dal client. Un utente nel workspace A non può accedere, modificare o inviare messaggi per conto del workspace B.
Vedi [Multi-Tenancy e Isolamento dei Workspace](/it/security/multi-tenancy).
### Supabase Vault per i Segreti
I segreti dei tenant — token di accesso Meta, segreti di firma dei webhook, chiavi API LLM — sono memorizzati in Supabase Vault, con ambito (scope) per workspace. Nessun segreto risiede in tabelle dello schema pubblico. I fallback tramite variabili d'ambiente sono consentiti solo in ambienti non di produzione.
Vedi [Gestione dei Segreti e Crittografia](/it/security/secrets-and-encryption).
### Controllo degli Accessi Basato sui Ruoli
Quattro ruoli sono applicati su ogni route API: **owner**, **admin**, **developer** e **operator**. I controlli sui ruoli vengono eseguiti dopo la risoluzione del contesto del workspace, prima che venga eseguita qualsiasi logica di business.
Vedi [Autenticazione e Controllo degli Accessi](/it/security/authentication).
### Diritti GDPR sui Dati
I contatti hanno diritto di accesso ai propri dati (Art.15/20) e diritto alla cancellazione (Art.17). Entrambi sono implementati come endpoint API che esportano o anonimizzano le PII in-place, con registrazioni nel log di audit per ogni operazione.
Vedi [Protezione dei Dati e GDPR](/it/security/data-protection).
### Pseudonimizzazione delle PII per l'AI
Prima che qualsiasi dato di contatto raggiunga un modello AI, il redattore PII sostituisce numeri di telefono, email e (opzionalmente) nomi con token reversibili. I token vengono ripristinati nella risposta dell'LLM prima del salvataggio. La disattivazione della pseudonimizzazione è consentita solo quando è configurato un provider AI self-hosted.
Vedi [Protezione dei Dati e GDPR](/it/security/data-protection).
## Stato dell'Implementazione
| Area di Controllo | Stato | Dettagli |
| ---------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------- |
| Isolamento multi-tenant | ✅ Implementato | Risoluzione basata su workspace\_members, applicata su tutte le route |
| Auth guard su tutti gli endpoint | ✅ Implementato | ai-assistant, API key, impostazioni tutte protette |
| Confronto dei segreti timing-safe | ✅ Implementato | `crypto.timingSafeEqual` |
| Gestione delle sessioni | ✅ Implementato | Timebox di 8h, inattività di 1h, revoca alla rimozione |
| Header di sicurezza | ✅ Implementato | CSP, HSTS, X-Frame-Options, Permissions-Policy |
| CORS | ✅ Implementato | Basato su allowlist, solo origini note |
| Segreti in Vault | ✅ Implementato | Vault per workspace, nessun fallback su env di produzione |
| Esportazione dati GDPR (Art.15/20) | ✅ Implementato | `GET /api/contacts/[id]/gdpr` |
| Diritto alla cancellazione GDPR (Art.17) | ✅ Implementato | `DELETE /api/contacts/[id]/gdpr` |
| Politica di conservazione dei dati GDPR | ✅ Implementato | `data_retention_days` per workspace |
| Pseudonimizzazione PII per l'AI | ✅ Implementato | `pii-redactor.ts`, opzione attivabile per workspace |
| Protezione da open redirect | ✅ Implementato | `isSafeRedirect()` nel callback di autenticazione |
| Validazione degli input | ✅ Implementato | Zod su tutte le route principali |
| Revoca delle sessioni | ✅ Implementato | `signOut` alla rimozione di un membro |
| RBAC | ✅ Implementato | 4 ruoli applicati su tutte le route |
| Ambito delle API key | ✅ Implementato | Filtro workspace\_id su tutte le operazioni sulle chiavi (BORD-154) |
| Audit logging (operazioni di scrittura) | ✅ Implementato | Tabella `audit_logs` con ambito workspace, modifiche membri, cancellazioni GDPR, aggiornamenti segreti (BORD-158) |
| Registro dei consensi | ✅ Implementato | Tracciamento del consenso per contatto con storico opt-in/opt-out (BORD-193) |
| Isolamento dei webhook | 📋 Pianificato | BORD-157: tabella di routing per phone\_number\_id |
| Claim di workspace nel JWT | 📋 Pianificato | BORD-155 |
| Autenticazione edge middleware | 📋 Pianificato | BORD-156 |
| Audit logging degli accessi in lettura | 📋 Pianificato | BORD-168 |
| Log di audit a prova di manomissione | 📋 Pianificato | BORD-168 |
| Rate limiting per workspace | 📋 Pianificato | BORD-162 |
| Scansione delle dipendenze (SBOM) | 📋 Pianificato | BORD-170 |
| Crittografia PII a livello di colonna | 📋 Pianificato | BORD-171 |
| Rilevamento degli incidenti | 📋 Pianificato | BORD-166 |
| Workflow di notifica delle violazioni | 📋 Pianificato | BORD-166 |
| Applicazione obbligatoria dell'MFA | 📋 Pianificato | Supabase TOTP disponibile |
## Documentazione Dettagliata
Modello di isolamento dei workspace, risoluzione del contesto e isolamento del dispatch dei messaggi.
Gestione delle sessioni, RBAC, API key, politica delle password e MFA.
Gestione delle PII, diritti degli interessati, pseudonimizzazione e sub-processor.
Supabase Vault, header di sicurezza, TLS e crittografia a riposo.
Traccia di audit, osservabilità e notifica delle violazioni pianificata.
Mappatura completa dei controlli su ISO 27001, GDPR, NIS2, HIPAA e SOC 2.