Ogni controllo descritto in questa pagina esiste oggi nel sistema in esecuzione.
Dove un controllo copre una parte della piattaforma e non un'altra, questa pagina
dice quale. Dove non abbiamo nulla, lo dice altrettanto chiaramente.
Che cosa è in atto
I controlli, e che cosa coprono esattamente
Autenticazione
Le password sono sottoposte ad hashing con Argon2 e non vengono mai memorizzate in chiaro. L'autenticazione primaria è delegata a Stytch, che detiene la credenziale. L'autenticazione a due fattori è disponibile su ogni account, tramite codice temporaneo o passkey WebAuthn.
Ruoli applicati a partire dal token
Quattro ruoli di dashboard (owner, admin, member, viewer) più un ruolo auditor separato. L'applicazione legge i ruoli dal token di sessione verificato anziché da una colonna nel nostro database, e il rifiuto avviene a livello di richiesta invece di essere semplicemente nascosto dall'interfaccia. Il ruolo auditor viene rifiutato su ogni metodo HTTP di modifica, senza eccezioni. Il ruolo viewer viene rifiutato su ogni metodo di modifica tranne la presa in carico e la risoluzione di un incident, che gli è deliberatamente consentita. I ruoli valgono per le sessioni interattive: una chiave API o un token machine-to-machine non porta alcun ruolo ed è governato dai suoi scope.
Chiavi API che non possiamo rileggere
Una chiave è composta da 96 caratteri esadecimali di output crittograficamente casuale. Ne memorizziamo il digest SHA-256 su un indice univoco, più i primi otto e gli ultimi quattro caratteri perché tu possa riconoscerla in un elenco. Il segreto in sé non viene mai scritto nel nostro database: una chiave smarrita può essere revocata e riemessa, ma mai recuperata, né da noi né da chi arrivasse a quella riga.
Isolamento dei tenant, e le sue due eccezioni
Ogni lettura sul data plane è vincolata a un identificativo di account prima di raggiungere lo storage, come UUID tipizzato. In una richiesta ordinaria quell'identificativo proviene dalla sessione verificata e non può essere fornito da chi chiama. Esistono due eccezioni deliberate, entrambe verificate per proprietà prima dell'uso: un partner può indicare uno dei propri account cliente gestiti in un header X-SQ-Account, che viene rifiutato a meno che quell'account non sia un account figlio attivo di quello stesso partner; e la nostra interfaccia interna di staff indirizza un account per id nell'URL, dietro le barriere descritte più sotto.
Come sono costruite le nostre query
L'accesso a PostgreSQL usa statement parametrizzati con bind parameter. Su quel percorso non esiste da nessuna parte SQL concatenato da stringhe. Quasi tutto viene inoltre verificato in fase di compilazione contro lo schema reale dalle nostre macro di query; un piccolo numero di statement usa la forma a runtime, che continua a effettuare il bind di ogni parametro ma non viene verificata contro lo schema durante la build.
Cifratura in transito, su ogni connessione che apri
Ogni connessione fra te e Site Qwality è HTTPS. Tutti gli otto hostname API pubblici impongono TLS 1.2 come minimo, e lo fa anche questo sito di marketing. Cinque delle nostre sei distribuzioni di content delivery impongono la policy TLS 1.2 (2021) e reindirizzano HTTP verso HTTPS. La sesta serve loghi e immagini delle status page da un indirizzo CloudFront anziché da un hostname nostro, e accetta ancora TLS 1.0: alzarla è lavoro già pianificato, e preferiamo dirlo invece di nasconderlo dietro una qualificazione.
Cifratura a riposo, negli archivi che nominiamo
Tutti e dieci i nostri bucket di object storage sono cifrati lato server con AES-256 e portano il blocco completo dell'accesso pubblico su tutte e quattro le impostazioni, quindi nulla al loro interno può diventare leggibile pubblicamente per una ACL accidentale o una bucket policy pubblica. Due di quei bucket contengono materiale deliberatamente pubblico, pubblicato tramite la nostra CDN e non direttamente dal bucket: lo script RUM, e i loghi e le immagini che carichi per una status page pubblica. Il volume che contiene log, metriche, tracce, dati RUM e l'indice dei session replay di ogni account è cifrato a riposo. La cifratura a riposo non è ancora universale su ogni archivio che gestiamo: vedi "Che cosa non dichiariamo" più sotto.
Corpi delle risposte salvati solo in caso di fallimento
Un check HTTP riuscito non salva alcun corpo della risposta. Quando un check fallisce conserviamo uno snippet di 8 KB inline, così l'elenco dei risultati si visualizza senza una seconda richiesta, e il corpo completo in object storage cifrato. Un fallimento resta diagnosticabile senza che noi conserviamo una copia di ogni pagina di un sito che funziona.
Un audit log che puoi leggere
Ogni richiesta autenticata che tu o i tuoi utenti effettuate e che modifica qualcosa nel vostro account viene registrata con l'attore, l'azione, il metodo e il percorso HTTP, lo stato della risposta, l'IP della richiesta e lo user agent. Anche una richiesta rifiutata viene registrata, con il suo 403. Due endpoint che usano un metodo di modifica solo per trasportare una query di lettura sono esclusi. La scrittura è deliberatamente "best effort", così un errore di registrazione non può mai far fallire la tua richiesta; questo significa anche che un guasto dell'archivio dei log può lasciare un buco. Gli ultimi 90 giorni sono leggibili nella dashboard da un admin dell'account, dal ruolo auditor o dall'utente principale dell'account.
Che cosa il tuo audit log non contiene
Le azioni amministrative compiute dallo staff di Site Qwality finiscono in un log interno separato, non nel tuo. Riguardano modifiche di piano e limiti, assegnazione di crediti SMS, sospensione, riattivazione ed eliminazione, e l'avvio del reset password di un membro. C'è un'eccezione, ed è voluta: un membro dello staff che agisce come uno dei tuoi utenti tramite impersonation compare nel tuo log, attribuito alla persona dello staff che lo ha fatto.
Come il nostro staff raggiunge la produzione
L'interfaccia amministrativa interna sta dietro quattro barriere, tutte eseguite prima di qualsiasi handler. Tre possiamo mostrarle nel codice: una allowlist di IP applicata al bordo della CDN, un token di origine iniettato da quel bordo e verificato lato server con un confronto a tempo costante, e un controllo del ruolo di staff sul token di sessione. Ognuna di quelle richieste viene scritta in un audit log di staff separato. La quarta è l'autenticazione a più fattori obbligatoria sulla nostra organizzazione di identità dello staff, ed è attiva. È una policy del nostro provider di identità senza alcun riscontro in nessun repository, quindi viene applicata al momento dell'accesso e non dal nostro codice: è l'unica delle quattro che non possiamo mostrarti in un file.
L'impersonation è esplicita e limitata
Un membro dello staff può aprire il tuo account come uno dei tuoi utenti solo attraverso un endpoint che registra chi lo ha fatto, quale utente è stato preso di mira e una motivazione scritta. La sessione può essere emessa in sola lettura, e in quel caso ogni metodo di modifica viene rifiutato. Scade dopo 60 minuti e non può essere prolungata.
I dati della carta non arrivano mai a noi
I dati della carta vengono digitati in un elemento di pagamento servito dall'origin di Stripe. Un numero di carta non tocca mai un server, un database o un log di Site Qwality. Ciò che memorizziamo è un identificativo cliente Stripe e gli identificativi dell'abbonamento.
Email di alert che non vengono riscritte
Le email di alert in uscita passano da Amazon SES con firma DKIM, un dominio MAIL FROM dedicato, SPF e DMARC. Il tracciamento delle interazioni è deliberatamente disattivato, quindi un link dentro un alert di disservizio non viene mai riscritto per passare da un redirector di terze parti. I riscontri di bounce e reclamo vengono consumati e registrati, così un indirizzo di alert che un provider ha silenziosamente soppresso diventa visibile invece di fallire in silenzio.
Parliamo chiaro
Che cosa non dichiariamo
Una pagina sulla fiducia non vale nulla se non puoi capire quali frasi sono state
verificate. Queste sono le cose che un questionario di sicurezza chiede di solito e a cui
non possiamo rispondere di sì.
Nessuna certificazione nostra. Amazon Web Services detiene SOC 2,
ISO 27001 e altre certificazioni per l'infrastruttura su cui giriamo. Site Qwality
non ne detiene nessuna. Una versione precedente di questa pagina era scritta in modo da
confondere le due cose, ed è stato un nostro errore.
Nessun penetration test di terze parti e nessun programma di vulnerability
scanning. Oggi non facciamo né l'uno né l'altro. L'indirizzo per la divulgazione
responsabile qui sotto è la strada che esiste davvero, e la leggiamo.
La cifratura a riposo non è universale. Gli archivi nominati sopra sono
cifrati. Non tutti quelli che gestiamo lo sono, e allineare i rimanenti è lavoro
pianificato, non lavoro concluso.
Non tutto ciò che conserviamo scade secondo un calendario. Le
registrazioni dei session replay e la copia ricercabile di log, metriche e tracce vengono
eliminate automaticamente alla fine della loro finestra. Una seconda copia di archivio
delle righe di log acquisite viene scritta in object storage e oggi non ha alcun piano di
eliminazione, quindi sopravvive alla finestra che governa la copia ricercabile. Anche
diversi record operativi non hanno una finestra di eliminazione applicata. Preferiamo
dirlo piuttosto che lasciar intendere una regola uniforme. La nostra
pagina Conservazione dei dati indica, categoria per
categoria, la finestra che i nostri sistemi applicano oppure la dichiarazione esplicita
che oggi nulla la cancella.
La nostra infrastruttura è negli Stati Uniti. Tutta
l'archiviazione e tutto il calcolo avvengono nella regione AWS us-east-1.
Ogni server, ogni database e ogni object store che contiene i tuoi dati gira lì, e anche i
check di monitoring vengono eseguiti da lì. Non offriamo un'opzione di residenza dei dati
nell'UE o nel Regno Unito. Questa frase è volutamente limitata alla nostra
infrastruttura: alcuni dei fornitori da cui dipendiamo gestiscono reti globali, e la
nostra pagina Sub-responsabili del trattamento indica per
ciascuno il luogo di trattamento e dice chiaramente quali restano da chiarire.
La nostra rete di content delivery termina le connessioni fuori dalla regione,
e non riguarda solo gli asset pubblici. Gestiamo sei distribuzioni e tutte e sei
usano una classe di prezzo che include edge location europee, quindi una richiesta
proveniente dall'Europa viene terminata in Europa e non in Virginia. Due delle sei
servono solo file pubblici: lo script RUM e i loghi delle status page. Due servono status
page, una nostra e una sul dominio di un cliente. Due stanno davanti al nostro portale
interno di staff, e una di queste inoltra le richieste dello staff alla nostra API,
quindi anche il traffico di staff che trasporta dati degli account dei clienti viene
terminato su un edge. Nessuna delle sei ha il logging degli accessi abilitato, quindi
sull'edge non conserviamo alcuna registrazione di chi ha richiesto cosa. Una versione
precedente di questa pagina definiva la CDN "l'unica cosa che esce dalla regione" e la
descriveva come cache di asset pubblici. Ne nominava due su sei ed era sbagliato.
Se stai compilando una valutazione fornitori e una risposta qui non è abbastanza dettagliata,
scrivi all'indirizzo qui sotto e chiedi. Preferiamo mandarti una risposta precisa piuttosto
che lasciarti dedurre una generosa.
Divulgazione responsabile
Hai trovato una vulnerabilità?
Prendiamo sul serio ogni segnalazione di sicurezza. Non esiste un programma di bug bounty né
un impegno formale sui tempi di risposta, ma la casella è letta da un engineer e lavoreremo
con te a una risoluzione responsabile.