I livelli di sicurezza di Simmetric Chat: API key, webhook firmati e DLP

La sicurezza è uno stack, non un interruttore

Una piattaforma di chat che custodisce i documenti della vostra azienda deve guadagnarsi la fiducia a livelli: come le richieste si autenticano, come l'accesso programmatico viene emesso e conservato, come le integrazioni in background provano la propria legittimità e cosa accade ai contenuti sensibili mentre attraversano prompt e risposte. Simmetric Chat affronta ognuno di questi aspetti con un meccanismo nominato, e v0.22 ha chiuso alcune delle lacune più sottili - confronti di segreti timing-safe, login resistente all'enumerazione e un motore DLP che ora copre anche gli identificativi strutturati europei. Questo articolo percorre lo stack dalla porta d'ingresso verso l'interno.

Tre modi in cui le richieste si autenticano

Ogni endpoint sotto /api ricade in uno dei tre regimi di credenziali:

• JWT Bearer (primario). Gli utenti umani si autenticano tramite l'endpoint di login o registrazione e ricevono un JWT firmato. Ogni token porta un claim jti verificato contro una lista di revoca (facoltativamente appoggiata a Redis), così che la disconnessione o la revoca amministrativa abbiano effetto immediato, non alla scadenza. I token invalidi o scaduti ricevono un `401 pulito; il middleware risolve l'utente insieme a ruoli e permessi su ogni richiesta.
• API key (`X-Api-Key`). L'accesso programmatico - la superficie dell'account di servizio del widget e le chiavi create dagli utenti tramite gli endpoint API-key - usa chiavi con prefisso verificate contro un digest HMAC, descritte qui di seguito.
• Segreto condiviso del collector. Le chiamate servizio-a-servizio del collector di ingesting portano X-Collector-Secret, confrontato a tempo costante con una guardia di lunghezza. Questo era l'ultimo luogo in cui sopravviveva un confronto in chiaro di segreti sul server, e v0.22 l'ha chiuso: i callback di importazione archivi ora usano la stessa disciplina crypto.timingSafeEqual di ogni altra barriera ai segreti.

Sopra l'autenticazione si collocano le guardie RBAC trattate in un articolo separato - controlli sui permessi, barriere admin e prevenzione IDOR sull'accesso a workspace e progetti. L'autenticazione risponde a "chi sei"; l'RBAC risponde a "cosa puoi toccare".

API key: HMAC-SHA256, cifrate a riposo

Una API key è una credenziale portatore, quindi il modo in cui il server la conserva conta quanto il modo in cui la verifica. Simmetric Chat emette chiavi con un riconoscibile prefisso sk- - familiare agli ecosistemi di strumenti che la maggior parte degli sviluppatori usa già - e non conserva mai la chiave stessa. A riposo, ogni chiave esiste solo come digest HMAC-SHA256 calcolato sotto un segreto dedicato server-side, API_KEY_HMAC_SECRET:

sk-abc123… (emessa una volta, mostrata una volta al chiamante)
 │  HMAC-SHA256(API_KEY_HMAC_SECRET, chiave)
 ▼
key_hash conservato in api_keys - la chiave stessa è irrecuperabile

Il design ha due proprietà volute:

• Rotazione disaccoppiata. API_KEY_HMAC_SECRET è indipendente da JWT_SECRET e da ENCRYPTION_KEY. Ruotare la chiave di firma delle sessioni non invalida le API key, e ruotare la chiave di cifratura a riposo non rompe la verifica delle chiavi. Ogni segreto ha un solo compito.
• Verifica a tempo costante. La verifica è una ricerca del digest HMAC a chiave - O(1), senza limiti take su una scansione di candidati. È ciò che rende l'autenticazione con API key abbastanza economica da stare su ogni richiesta in un deployment multi-istanza.

Gli utenti gestiscono le proprie chiavi tramite gli endpoint API-key: creazione al bisogno, elencazione a richiesta, revoca a richiesta. La revoca elimina la capacità di ricostruire una credenziale valida; il digest non corrisponde più a nulla.

Webhook firmati e Web Push

Le integrazioni in uscita devono essere verificabili quanto quelle in entrata.

I webhook sono firmati con HMAC-SHA256. Il server calcola una firma sul payload usando il segreto del webhook, e il vostro servizio ricevente ricalcola il digest prima di fidarsi del corpo dell'evento. Un endpoint ricevente non deve mai fidarsi di un chiamante che dichiara di essere Simmetric Chat - può provarlo, byte per byte, con la propria copia del segreto. Un endpoint di eventi di prova vi permette di esercitare un ricevente senza generare attività reale sulla piattaforma.

Il Web Push usa il protocollo VAPID per le notifiche del browser. Il server detiene una coppia di chiavi VAPID; la chiave pubblica è esposta ai client autenticati tramite un endpoint di sistema, le sottoscrizioni sono gestite attraverso espliciti endpoint di subscribe/unsubscribe e gli amministratori possono inviare un push di prova per verificare la pipeline end-to-end. Entrambi i canali sono sempre attivi nel tier Community - firma e push sono comportamento di base della piattaforma, non funzionalità enterprise.

Rate limiting alla frontiera

Il rate limiting è stratificato per superficie, con i consueti header RateLimit-* emessi sulle rotte limitate:

• Limitatore API globale - 200 richieste al minuto per IP su tutte le rotte in produzione
• Limitatore di autenticazione - 10 richieste al minuto sugli endpoint di scrittura dell'autenticazione, la barriera più stretta perché gli endpoint delle credenziali sono i primi bersagli degli abusi
• Limitatore lead del widget - 3 richieste l'ora sulla cattura dei lead, perché un modulo pubblico è dove l'abuso automatizzato si concentra
• Limitatore di probe - 10 richieste al minuto sugli endpoint di probe della connettività, così che il test della procedura guidata di setup non possa essere trasformato in arma

Quando REDIS_URL è configurato, i contatori vivono in uno store Redis condiviso così che i limiti significhino la stessa cosa su ogni istanza; altrimenti ogni istanza mantiene il proprio store. Le richieste che portano un header del widget saltano il limitatore globale - il traffico dei widget è già throttled a monte dal limitatore per-chiave del servizio widget - e non esiste un limitatore dedicato alla chat, perché l'agente impone internamente concorrenza per utente, budget di token e timeout a muro di tempo.

DLP: redazione prima dell'esfiltrazione

La prevenzione della perdita di dati in Simmetric Chat è un plugin filtro che scandisce sia il prompt in entrata sia la risposta in uscita - inclusi i flush progressivi token per token dello streaming - e redige le corrispondenze prima che il contenuto lasci la vostra rete. Lo scanner riconosce 10 classi di pattern PII incorporate:

• Indirizzi email
• Numeri di carte di credito
• API key e chiavi private
• Più gli identificativi strutturati europei: Partita IVA italiana, codice fiscale e IBAN, aggiunti in v0.22 e seminati in modo idempotente

La configurazione dei pattern è appoggiata al database e gestita dagli admin: attivare o disattivare qualsiasi pattern per riga, aggiungere fino a 50 pattern personalizzati con validazione live della compilazione e un'anteprima di test, e ispezionare un pannello di cronologia delle corrispondenze DLP filtrabile per sorgente (chat o widget). Le espressioni regolari incorporate sono congelate - potete disattivare un pattern incorporato ma non riscriverlo - mentre i pattern personalizzati portano le vostre definizioni. Le scansioni che possono leggere i pattern configurati li usano attraverso una cache a breve TTL e ricadono sull'insieme incorporato se il database è irraggiungibile, così che un'interruzione del database non disattivi mai la redazione.

Due dettagli di governance completano il quadro. Un'impostazione DLP_BYPASS_ROLES permette agli admin di esentare ruoli specifici dalla scansione, e ogni bypass genera un evento di audit che registra chi ha bypassato e su quale superficie - mai il contenuto scansionato. Gli amministratori possono inoltre rivelare o nascondere di nuovo i testi corrispondenti attraverso una conversazione con un unico interruttore, con visibilità limitata alla sessione e nascosto per impostazione predefinita, così che la redazione resti reversibile per una revisione autorizzata ma non in silenzio.

Il rafforzamento più sottile in v0.22

I piccoli cambiamenti contano perché chiudono i canali che gli attaccanti sondano davvero:

• Confronti timing-safe ovunque. Ogni rimasto confronto in chiaro di segreti - le barriere del segreto del collector, il callback di importazione archivi, il controllo della chiave di cache-bust del widget - ora usa crypto.timingSafeEqual con una guardia di lunghezza e fallisce in modo chiuso quando il segreto atteso non è impostato.
• Login resistente all'enumerazione. Quando un nome utente non esiste, il login esegue comunque un confronto fittizio di hash prima di rispondere, così che il tempo di risposta non distingua più gli utenti esistenti da quelli inesistenti. I corpi invalidi restituiscono un 400 strutturato anziché un 401 che lasci filtrare gli interni di Zod.
• Misconfigurazioni che falliscono sonoramente. Una misconfigurazione HMAC lato server sulla verifica delle API key restituisce 500, per scelta - un segreto mal configurato non deve mai travestirsi da fallimento di autenticazione.
• Validazione strutturata. I corpi delle richieste sono validati con schemi Zod condivisi tramite safeParse; ogni errore è una busta uniforme con dettagli per campo, così che i client falliscano in modo prevedibile.

L'intera superficie API - tabelle degli endpoint, incorniciatura degli eventi SSE e requisiti di autenticazione per rotta - è documentata nel riferimento API, e un'interfaccia Swagger live è inclusa nel server.

Leggi la guida completa nella documentazione →