La fiducia in Squish

Squish è una piattaforma multi-servizio. Il sito rivolto ai clienti (squish.co) e il CRM interno (work.squish.co) girano su Cloudflare Workers / Pages. Cinque backend Node.js — squish-backend, squish-crm-backend, squish-provisioning, squish-email e squish-hosting — girano su Railway nella regione US-East. I dati dei clienti risiedono in Salesforce; lo stato transazionale, gli audit log e i metadati di provisioning risiedono in Google Firestore (regione US). I dati di pagamento sono custoditi da Stripe — Squish è fuori dall'ambito PCI per progettazione.

La registrazione dei domini è intermediata tramite NameSilo. L'hosting web condiviso gira su nodi Plesk ospitati su droplet DigitalOcean; i VPS Managed Cloud usano CyberPanel per impostazione predefinita, su un droplet dedicato. I siti ospitati sono serviti dietro CDN e WAF di Bunny. Le licenze Microsoft 365 sono intermediate tramite Pax8 (CSP).

• In transito: TLS 1.3 (minimo TLS 1.2) end-to-end tramite Cloudflare. HSTS applicato su ogni dominio rivolto ai clienti.
• A riposo: crittografia predefinita di Firestore (AES-256), crittografia della piattaforma Salesforce; Stripe gestisce tutti i dati delle carte con controlli PCI DSS Level 1.
• Segreti: tutte le chiavi API, le credenziali dei service account e le stringhe di connessione ai database risiedono nelle variabili d'ambiente di Railway e nei secret binding di Cloudflare — mai nel codice sorgente.
• Backup: point-in-time recovery di Firestore (finestra di 7 giorni). I dati clienti di Salesforce risiedono sulla piattaforma Salesforce con replica e disaster recovery integrati.

• Autenticazione clienti: Firebase Auth (email + password, più provider OAuth opzionali). JWT a breve durata (TTL di 1 ora).
• Autenticazione staff: Cloudflare Access davanti a ogni superficie interna. SSO + MFA obbligatori. Token di sessione con ambito per app.
• Da servizio a servizio: chiave API interna condivisa + controlli di ruolo per rotta (admin / support / sales).
• Impersonificazione: ogni sessione dello staff "agisci come cliente" viene registrata con motivazione, azioni end-to-end e timestamp di inizio/fine. Le azioni distruttive (modifiche ai metodi di pagamento, trasferimenti di registrar) sono bloccate durante l'impersonificazione da una denylist esplicita.

Ogni azione privilegiata finisce in una di queste raccolte Firestore append-only:

• security_events — errori di autenticazione, dinieghi RBAC, tentativi IDOR, superamenti di rate limit
• impersonation_sessions — sessioni staff-come-cliente con sotto-raccolta per azione
• billing_actions — emissione di rimborsi, motivazioni dei limiti per ruolo, catene di seconda approvazione
• email_log — ogni email in uscita con tipo, motivo di soppressione, stato di invio
• webhook_events — lease di idempotenza dei webhook Stripe / NameSilo / Pax8
• cron_runs — heartbeat di ogni job pianificato (così le esecuzioni mancate sono visibili)

I controlli di sicurezza non sono solo descritti in questa pagina — quelli critici sono asseriti nel codice, così il prossimo deploy non può indebolirli in silenzio.

• Gate CI sugli header di sicurezza delle risposte: ogni PR esegue uno smoke test vitest che fa fallire la build se gli header Content-Security-Policy, Cross-Origin-Resource-Policy, anti-clickjacking o referrer-policy si discostano dai valori previsti.
• Verifica dei permessi di terze parti all'avvio: il backend, all'avvio, verifica che la chiave API Stripe configurata abbia tutti gli ambiti da cui dipendono la dashboard e i flussi di checkout; un ambito mancante viene registrato in modo evidente al boot invece di manifestarsi come errore silenzioso lato cliente.
• Helper SOQL guidati dai tipi che rifiutano identificatori malformati nel punto di chiamata invece di convertirli silenziosamente in un valore che amplierebbe la query — difesa contro la SOQL injection lato integrazione.
• Manifest di prontezza delle variabili d'ambiente: ogni servizio dichiara tutte le variabili che utilizza, contrassegnate come obbligatorie o facoltative, e un endpoint interno segnala quali mancano sull'istanza in esecuzione — così un segreto assente emerge da un controllo deliberato dopo il deploy e non alla prima richiesta di un cliente che ne aveva bisogno.

I dati operativi vengono conservati per finestre brevi e giustificabili; i record finanziari vengono conservati per i 7 anni previsti dalla normativa fiscale statunitense. Le richieste di cancellazione dei clienti vengono evase entro 30 giorni per i dati non finanziari.

Fornitori che trattano i dati dei clienti per nostro conto. Ciascuno opera secondo il proprio programma di conformità — i link portano alle loro pagine trust pubbliche.

• Contatto sicurezza: security@squish.co — lo staff viene avvisato in tempo reale.
• Politica di divulgazione responsabile: /.well-known/security.txt
• SLA di prima risposta: entro un giorno lavorativo.
• Notifica ai clienti: entro 72 ore dalla conferma di una violazione che riguarda dati dei clienti, in linea con l'articolo 33 del GDPR.
• Stato del sistema in tempo reale: squish.co/status

Oggi: Squish gestisce un programma di sicurezza auto-attestato sostenuto dai controlli descritti sopra. La maggior parte dei controlli SOC 2 Type 1 (controllo degli accessi, crittografia, audit log, gestione dei fornitori, gestione dei cambiamenti) è già in atto; l'audit formale è in roadmap.

SOC 2 Type 1: in corso. Attestazione prevista entro fine anno.

SOC 2 Type 2: il periodo di osservazione inizia dopo l'ottenimento dell'attestazione Type 1.

Per i team di procurement: compiliamo volentieri un questionario di sicurezza (CAIQ-Lite, SIG-Lite o il vostro formato). Scriveteci a security@squish.co.

Accordo sul trattamento dei dati (DPA): il nostro DPA standard, allineato all'articolo 28 del GDPR e comprensivo delle Clausole Contrattuali Standard UE, è pubblicato su squish.co/dpa ed è incorporato automaticamente nei nostri Termini di servizio.