Architettura del Log di Audit
Switchbord mantiene una tabellaaudit_logs che registra le operazioni rilevanti per la sicurezza eseguite all’interno di ciascun workspace. La traccia di audit è progettata per rispondere alla domanda: chi ha fatto cosa, a quale oggetto, in quale workspace e quando.
Schema
workspace_id, garantendo che l’isolamento del workspace si estenda alla traccia di audit stessa.
Cosa Viene Registrato
Attualmente Implementato
Scrittura di una Registrazione nel Log di Audit
Le registrazioni nel log di audit vengono scritte in modo sincrono all’interno della stessa transazione del database dell’operazione che registrano, ove possibile. Ciò garantisce che la traccia di audit rifletta le operazioni effettivamente eseguite, non solo quelle tentate.
Miglioramenti Pianificati al Log di Audit
Logging degli Accessi in Lettura (BORD-168)
Attualmente, vengono registrate solo le operazioni di scrittura (mutazioni, eliminazioni). Il lavoro pianificato include la registrazione dell’accesso in lettura alle tabelle PII — in particolare il tracciamento di quali utenti hanno accesso a quali record di contatto e quando. Questo è richiesto per la piena conformità a HIPAA §164.312(b).Catena di Hash a Prova di Manomissione (BORD-168)
Ogni registrazione nel log di audit includerà un hash crittografico della voce precedente nella catena di log del workspace. Ciò crea una struttura a prova di manomissione in cui la modifica di una voce passata invalida tutti gli hash successivi. L’implementazione pianificata utilizza il chaining SHA-256.Esportazione Immutabile su Object Storage (BORD-168)
I log di audit verranno periodicamente esportati su object storage write-once (ad es. Supabase Storage con politica di bucket immutabile) per fornire un backup che non può essere modificato nemmeno dagli amministratori del database.Stack di Osservabilità
Monitoraggio degli Errori: Sentry
Switchbord si integra con Sentry per il monitoraggio degli errori in tempo reale su tutte le superfici applicative. Sentry rileva:- Eccezioni non gestite nelle route API
- Fallimenti dei job del worker
- Errori JavaScript lato frontend
packages/observability.
Aggregazione dei Log: Better Stack
I log applicativi da Vercel e Railway vengono aggregati in Better Stack (precedentemente Logtail). I log strutturati includono ID di richiesta per la correlazione tra i servizi.Monitoraggio dello Stato di Salute
Gli endpoint/api/health e /api/ready sono pubblicamente accessibili e monitorati da servizi di uptime per rilevare il degrado della disponibilità.
Avvisi sull’Account (BORD-189)
Switchbord fornisce avvisi in tempo reale a livello di account che segnalano agli operatori del workspace eventi operativi e rilevanti per la sicurezza:- Avvisi sullo stato di salute dell’API WhatsApp — notifiche quando l’API Meta restituisce tassi di errore elevati, risposte di rate-limit o fallimenti di consegna dei webhook per i numeri di telefono di un workspace
- Avvisi di scadenza dei segreti — avvertimenti quando token o API key memorizzati in Vault si stanno approssimando alla scadenza
- Avvisi sulla soglia di consenso — notifiche quando il tasso di opt-out di un workspace supera una soglia configurabile, indicando un potenziale rischio di conformità
- Avvisi di anomalia di utilizzo — segnalazioni per picchi anomali del volume di messaggi, operazioni massive sui contatti o pattern di utilizzo delle API key
audit_logs sotto il tipo di entità account_alert.
Pianificato: Rilevamento degli Incidenti di Sicurezza (BORD-166)
Le seguenti funzionalità sono pianificate come parte di BORD-166:- Rilevamento delle anomalie: segnalare pattern inusuali come esportazioni massive di contatti, volumi elevati di utilizzo delle API key o accessi da intervalli IP inattesi
- Monitoraggio degli eventi di sicurezza: avvisi dedicati per eventi rilevanti per la sicurezza (raffiche di autenticazioni fallite, anomalie di sessioni concorrenti, tentativi di escalation dei privilegi)
- Integrazione degli avvisi: avvisi basati su webhook verso Slack, PagerDuty o endpoint configurati dall’operatore
Pianificato: Workflow di Notifica delle Violazioni (BORD-166)
L’Art.33 GDPR richiede la notifica all’autorità di controllo entro 72 ore dalla presa di conoscenza di una violazione dei dati personali. L’Art.34 può richiedere la notifica agli interessati coinvolti. Funzionalità pianificate per supportare questo obbligo:- Trigger di rilevamento degli incidenti che creano un record dell’incidente con timestamp di rilevamento
- Workflow di valutazione della violazione — domande guidate per determinare l’ambito della notifica
- Generazione di bozze di notifica — modelli pre-popolati per la presentazione al DPA
- Timer di conto alla rovescia di 72 ore — visibile nell’interfaccia admin una volta dichiarato un incidente
- Determinazione dell’ambito di workspace e contatti coinvolti — identificare i dati di quali contatti potrebbero essere stati coinvolti
Conservazione dei Log di Audit
I log di audit sono conservati per il periododata_retention_days configurato dal workspace, con una conservazione minima di 365 giorni indipendentemente dall’impostazione del workspace. Ciò garantisce che le tracce di audit rimangano disponibili per le indagini post-incidente e gli audit di conformità.
Le richieste di cancellazione GDPR non eliminano le registrazioni nel log di audit. Le voci che registrano il fatto di una cancellazione vengono esse stesse conservate come prova di conformità.