Sicurezza

Come vengono protetti i tuoi dati

• Crittografati in transito e a riposo. TLS 1.2+ ovunque; archiviazione crittografata a livello di piattaforma.
• Isolamento dei workspace. Ogni record porta un identificativo del workspace e ogni query è limitata a quel workspace, compresi gli endpoint che agiscono su un singolo record: così un identificativo indovinato da un account non può raggiungere i dati di un altro.
• Gestione delle password. Le password vengono sottoposte a hashing con scrypt con i parametri raccomandati da OWASP – N=131072, r=8, p=1 – ciascuna con il proprio salt casuale, e non vengono mai archiviate né registrate in una forma recuperabile. La verifica avviene a tempo costante, imponiamo un minimo di 10 caratteri e rifiutiamo le password presenti in raccolte note di dati violati. scrypt è ad alto consumo di memoria: ogni tentativo richiede 128 MB di memoria oltre al tempo, ed è questo che lo rende costoso da attaccare con le schede grafiche che rendono economico il normale cracking delle password. Gli account creati con il nostro schema precedente vengono aggiornati automaticamente al successivo accesso del titolare.
• Il tuo account non esiste finché non dimostri che l’indirizzo è tuo. La registrazione salva una richiesta in sospeso e ti invia un link via email; account, workspace e sessione vengono creati quando lo clicchi. Questo elimina un’intera classe di attacchi invece di difendersi da essa: nessuno può registrare un account con il tuo indirizzo email, impostarci una password e aspettare che tu ti registri e lo adotti.
• I tentativi di accesso automatizzati vengono messi alla prova. Accesso, registrazione, reimpostazione della password e modulo di contatto sono protetti da una verifica anti-bot rispettosa della privacy oltre che da limiti di frequenza, così scorrere una lista di password trafugate costa più di quanto renda. I limiti si applicano a ciascun account preso di mira, oltre che all’indirizzo da cui arrivano i tentativi, perché un attaccante con un insieme di indirizzi aggira un limite basato solo sull’indirizzo cambiando indirizzo; e i tentativi falliti ripetuti su un account vengono rallentati progressivamente invece di essere bloccati, per minuti, mai in modo permanente. La reimpostazione della password viene conteggiata separatamente dall’accesso, quindi chi esaurisce di proposito i tuoi tentativi di accesso non può chiuderti anche la strada che useresti per rientrare.
• Autenticazione a due fattori. Tre opzioni: passkey (Face ID, Touch ID, Windows Hello o una chiave hardware), un’app di autenticazione o un codice inviato via email. Le passkey sono le più sicure e le uniche resistenti al phishing, perché la firma è legata a closerev.com. I codici via email sono i più deboli (chi accede alla tua casella di posta accede anche al codice) e lo diciamo dove li attivi. I codici di recupero monouso coprono il caso di un dispositivo perso. Una volta attivo un qualsiasi fattore, vale per ogni accesso all’account, compreso “Accedi con Google”: un secondo percorso di accesso non è un modo per aggirarlo. Il proprietario di un workspace può anche rendere obbligatoria la verifica in due passaggi per tutti i membri, così nessuno raggiunge i dati con la sola password. Per aggiungere un metodo ne serve uno che hai già, e ti inviamo un’email quando ne viene aggiunto uno. Altrimenti chi si impossessasse di un dispositivo su cui hai effettuato l’accesso potrebbe aggiungere la propria app di autenticazione e mantenere l’accesso anche dopo che hai cambiato la password. L’avviso arriva al tuo indirizzo e non sullo schermo di chi l’ha fatto, e contiene un link che disconnette ogni dispositivo, compreso il suo. I metodi si possono aggiungere ma non rimuovere. Altrimenti chi si impossessasse di un dispositivo su cui hai effettuato l’accesso rimuoverebbe i metodi che non ha e terrebbe quello che ha, lasciando il tuo account protetto proprio da ciò che ti ha rubato. Hai perso un dispositivo? Cambia la password, così tutte le altre sessioni vengono subito disconnesse, poi scrivici: verifichiamo la tua identità e rimuoviamo il metodo, e quel ripristino viene registrato nel log a prova di manomissione descritto più sotto.
• Le azioni più rischiose chiedono una nuova conferma. Chiudere l’account, cambiare la password, esportare tutto o modificare un’impostazione di sicurezza valida per l’intero workspace richiede di dimostrare che sei ancora tu: con il codice dell’app di autenticazione se ne hai una, altrimenti con la password. Un cookie di sessione dice che qualcuno ha effettuato l’accesso; non dice che la persona alla tastiera sei ancora tu, e per queste poche azioni è proprio questa la differenza che conta. Per la maggior parte di esse la conferma vale 30 minuti, quindi una serie di operazioni amministrative la chiede una volta sola. Attivare o disattivare un obbligo valido per tutto il workspace (verifica in due passaggi, single sign-on) la chiede ogni volta, in entrambe le direzioni: un’impostazione che abbassa ciò che serve per raggiungere i tuoi dati non dovrebbe mai basarsi su una conferma data per qualcos’altro.
• Single sign-on. I workspace Enterprise e Agency possono obbligare tutti ad accedere tramite il proprio provider di identità con OpenID Connect. Un dominio deve essere verificato nel DNS prima di poter essere usato, quindi nessuno può configurare il single sign-on per un dominio che non controlla. Una volta reso obbligatorio, password e accesso con Google smettono di funzionare per quel dominio, con un’eccezione voluta: il proprietario del workspace, così un provider configurato male non può chiudere un’azienda fuori dai propri dati. Le sessioni create in questo modo durano una settimana invece di un mese, perché il single sign-on da solo non revoca l’accesso quando qualcuno se ne va. Il client secret che ci fornisci viene crittografato prima di essere archiviato.
• Sessioni. Token opachi e con scadenza in cookie httpOnly, Secure e SameSite con il prefisso __Host-, che impedisce a qualsiasi altro sito su un dominio vicino di scrivere un cookie che i nostri server leggerebbero come tuo. Sono revocabili lato server, e cambiare la password invalida subito tutte le altre sessioni. Le richieste che modificano qualcosa devono partire da CloseRev stesso; un modulo su un altro sito che invia dati al nostro viene rifiutato prima di raggiungere i tuoi dati. I token di sessione vengono archiviati solo come hash, quindi una copia del nostro database non permetterebbe di accedere al posto di nessuno. Una sessione termina dopo 30 giorni, o dopo 7 giorni di inattività. E quando il tuo account accede da un browser che non abbiamo mai visto, ti inviamo un’email, con un link che disconnette ogni dispositivo se non sei stato tu.
• Link via email. I link di verifica e di reimpostazione sono monouso e hanno una scadenza, e di ogni token conserviamo solo un hash SHA-256: una fuga di dati dal database non produrrebbe link funzionanti. L’uso singolo è garantito dal database in un unico passaggio, quindi due clic che arrivano nello stesso istante non possono andare a buon fine entrambi.
• Pagamenti. I dati della carta vanno direttamente a Stripe e non raggiungono mai i nostri server, così restiamo fuori dall’ambito del trattamento dei dati delle carte.
• Log di audit. Caricamenti, abbinamenti, modifiche manuali in fase di verifica, esportazioni ed eliminazioni vengono registrati per workspace. Inoltre, ogni volta che qualcuno di CloseRev apre una console interna che può vedere il tuo account, viene registrato anche questo: chi, cosa ha guardato e quando. Conserviamo questo registro per 24 mesi nel nostro database, e una copia fatta ogni notte viene conservata fino a 6 anni in un archivio non modificabile, così alla domanda “qualcuno ha guardato questo?” si può rispondere più a lungo di quanto qualsiasi piano conservi i tuoi dati. Le voci sono concatenate: ognuna è sigillata con un hash che copre la voce precedente, e il database si rifiuta di modificare o risigillare una voce sigillata. Rimuovere o modificare una voce a posteriori spezza la catena in quel punto, e un controllo eseguito ogni notte segnala dove. Ogni notte, inoltre, una copia del sigillo più recente della catena viene scritta in un archivio protetto da credenziali separate, così il log e la sua stessa traccia non si possono riscrivere insieme.
• Eliminazione reale. Eliminare un’importazione ne rimuove i record, i risultati degli abbinamenti e il file originale caricato dall’archivio, non si limita a contrassegnare una riga.
• Le esportazioni si aprono in sicurezza. Un foglio di calcolo tratta una cella che inizia con =, +, - o @ come una formula da eseguire, quindi un valore inserito da qualcuno in un CSV che hai caricato potrebbe diventare un comando sul computer di chi apre la tua esportazione. Neutralizziamo quelle celle in un modo che resiste al salvataggio e alla riapertura del file, e lasciamo intatti i numeri normali e gli importi negativi.

Minimizzazione dei dati

L’abbinamento richiede un numero di telefono o un indirizzo email, e un importo. Sei tu a scegliere quali colonne mappare, e preferiamo che tu ne carichi meno. I dati appartenenti a categorie particolari sono del tutto esclusi: vedi la Politica di utilizzo accettabile.

Non firmiamo business associate agreement (BAA) ai sensi dell’HIPAA, quindi non caricare informazioni sanitarie protette: una diagnosi, un trattamento, dati assicurativi o un appuntamento legato a un paziente. Un record di vendita con nome, numero di telefono, indirizzo email, importo e data per un servizio che non dice nulla sulla salute di nessuno va bene; se sei un operatore sanitario, escludi tutto ciò che rivela lo stato di salute di una persona.

Cosa non abbiamo ancora fatto

Preferiamo dirlo chiaramente piuttosto che lasciare che una pagina sulla sicurezza lasci intendere più del vero:

• Nessuna certificazione SOC 2 o ISO 27001. Siamo un prodotto nelle prime fasi e non abbiamo ancora affrontato un audit.
• Nessuna residenza dei dati configurabile dal cliente. La regione di archiviazione è al momento quella predefinita della piattaforma.

Se uno di questi punti blocca il tuo processo di acquisto, diccelo: ci è utile sapere da quale cominciare.

Chi in CloseRev può vedere i tuoi dati

• Nessuno, in condizioni normali. Il prodotto è self-service e l’assistenza non richiede di leggere i tuoi record. Non esiste una funzione “accedi come questo cliente” né alcuna forma di impersonificazione, per scelta: nel momento in cui esistesse, diventerebbe la strada più breve verso i dati di ogni cliente.
• La console interna non può leggere in alcun modo i record che carichi. Mostra le informazioni sull’account e sulla fatturazione e il conteggio di ciò che hai elaborato. Non ha accesso ai record di vendita o dei lead.
• Registriamo le letture, non solo le modifiche. Tutto ciò che un amministratore consulta viene registrato con chi, cosa, quando e da dove. Se un giorno chiedi chi in CloseRev ha guardato il tuo account, la risposta viene da un registro e non dalla memoria di qualcuno.
• L’accesso richiede il single sign-on con autenticazione a più fattori. La console è protetta da Cloudflare Access e in più confronta l’identità verificata con una lista di autorizzati, quindi non esiste una nostra password che si possa sottrarre con il phishing per entrarci.
• Le email che ci invii. Un’email a support@ diventa un caso nella nostra console, e i suoi allegati vengono conservati con il caso nel nostro archivio ed eliminati insieme a esso dopo 24 mesi. La casella del nostro team riceve una copia del mittente, dell’oggetto e del testo di ogni messaggio inviato a un indirizzo closerev.com, mai gli allegati.

Come testiamo ciò che rilasciamo

Quattro controlli vengono eseguiti sul codice a ogni modifica, perché ragionare sull’isolamento non equivale a verificarlo:

• Ogni query che tocca i dati dei clienti viene elencata e rivista. Un controllo estrae ogni istruzione e mantiene una base di riferimento già rivista, così una query nuova o riscritta che non è limitata a un workspace deve essere esaminata invece di passare inosservata.
• L’isolamento viene testato con richieste HTTP reali, non solo ragionato. Vengono creati tre workspace separati in una copia reale del nostro runtime, e a ogni endpoint che accetta un identificativo vengono chiesti i dati di un altro workspace, attraverso lo stesso codice che esegue il sito, con gli stessi binding di database, archiviazione e sessione. Un test che non può fallire non vale nulla, quindi ognuno di essi viene eseguito insieme a un controllo che dimostra che il legittimo proprietario riceve ancora i propri dati.
• Le pagine vengono misurate in un browser, non giudicate a occhio – le nostre pagine pubbliche, in tema chiaro e scuro, a larghezza desktop e smartphone, per overflow, tagli e contrasto, automaticamente ogni volta che una modifica tocca ciò che mostrano; le pagine riservate agli utenti registrati allo stesso modo, quando eseguiamo l’audit con un account di prova.
• Le modifiche al database vengono applicate da uno strumento che tiene un registro, e che si rifiuta di applicare qualcosa due volte, fuori ordine o quando la cronologia registrata e il codice non concordano più.

Una revisione di sicurezza scritta che copre isolamento dei tenant, autenticazione, caricamenti, fatturazione, token pubblici e ciclo di vita dei dati è una condizione per la disponibilità generale. È stata eseguita più volte, l’ultima con due passaggi dedicati prima del lancio, compreso un controllo in sola lettura della configurazione dei pagamenti in produzione, e all’interno di una copia reale del runtime su cui eseguiamo il deploy. Entrambi i report registrano ciò che non è stato dimostrato con la stessa chiarezza di ciò che lo è stato.

Backup e ciclo di vita dei dati

• Sei tu a decidere il periodo di conservazione per ogni workspace, entro quanto previsto dal tuo piano. Un processo notturno elimina le importazioni che lo superano (i record, i risultati degli abbinamenti e i CSV originali nell’object storage) e registra ciò che ha fatto nel log delle attività del tuo workspace.
• Eliminare significa eliminare. Rimuovere un’importazione ne rimuove i record e i file. Chiudere l’account rimuove l’account e, se ne sei il proprietario, il workspace e ogni file che gli appartiene. Le fatture vengono conservate solo dove la normativa fiscale lo richiede.
• I backup sono quelli della piattaforma, con ripristino point-in-time che copre gli ultimi 30 giorni del database. Servono a riprenderci da un nostro guasto, non sono una seconda copia che puoi interrogare.
• Un ripristino non può annullare in silenzio un’eliminazione. È l’unico punto in cui “eliminare significa eliminare” ha richiesto più di una semplice eliminazione: riportare indietro il database per rimediare a un guasto qualsiasi farebbe altrimenti ricomparire tutto ciò che è stato rimosso nel frattempo, senza che nessuno se ne accorga. Per questo ogni eliminazione viene registrata (cosa è stato rimosso, per quale workspace, quando e perché, senza nessuno dei dati stessi) e riapplicare quelle registrazioni è un passaggio della nostra procedura di ripristino, non qualcosa da ricordare. I file caricati non rientrano affatto in quel ripristino: una volta eliminato dall’object storage, un file non c’è più.

Se qualcosa va storto

• Violazioni dei dati personali: informiamo i clienti coinvolti senza ingiustificato ritardo ed entro 72 ore da quando ne veniamo a conoscenza, con ciò che sappiamo e ciò che stiamo facendo. È un impegno contrattuale: è scritto nel DPA, non solo qui.
• Interruzioni che riguardano l’integrità dei dati o l’accesso: inviamo un’email ai proprietari dei workspace invece di aspettare che qualcuno controlli una pagina, e un’altra quando il problema è risolto. Lo stato dei componenti è pubblicato sulla nostra pagina di stato, che effettua misurazioni reali invece di essere aggiornata a mano.

Perché è così precisa

Indicare l’algoritmo e i suoi parametri di costo è una scelta voluta, ed è ciò che gli standard di sicurezza chiedono, non qualcosa che ci concediamo. Un sistema dovrebbe essere sicuro anche quando tutto ciò che lo riguarda, tranne le chiavi, è pubblico: è un principio più vecchio del settore stesso, ed è il motivo per cui il NIST pubblica apertamente i suoi standard crittografici invece di descriverli in modo vago. Un progetto che regge solo finché nessuno sa come funziona non è un progetto che regge.

Quello che qui non troverai è qualcosa di davvero segreto: niente versioni del software o livelli di patch, niente nomi host interni o struttura della rete, niente materiale crittografico e niente soglie su cui un attaccante potrebbe tarare i propri tentativi, come quanti tentativi fanno scattare un blocco o quanto dura un limite di frequenza. I numeri su questa pagina sono impegni che prendiamo con te, non impostazioni da prendere di mira.

Se ci stai valutando e qualcosa qui non è abbastanza preciso da rispondere alla tua domanda, chiedi. Preferiamo metterlo per iscritto piuttosto che lasciarti tirare a indovinare.

Segnalare una vulnerabilità

Email security@closerev.com, oppure leggi la versione leggibile dalle macchine su /.well-known/security.txt. Confermiamo la ricezione entro 2 giorni lavorativi, ti diciamo se siamo riusciti a riprodurla entro 10 giorni lavorativie ti teniamo aggiornato finché non viene chiusa. Chiediamo 90 giorni prima della divulgazione pubblica, o meno se la correzione viene rilasciata prima.

Ti chiediamo di non accedere, modificare o conservare dati che non sono tuoi, di non eseguire scansioni automatiche che degradano il servizio per i clienti e di non usare tecniche di ingegneria sociale sul nostro personale o sui nostri fornitori. Entro questi limiti non intraprenderemo azioni contro chi fa ricerca in buona fede, e ti citeremo se lo desideri.

Documenti correlati

Informativa sulla privacy · Accordo sul trattamento dei dati · Sub-responsabili