Vai al contenuto

Lingua

Affidabilità

Sicurezza

Questa traduzione è fornita per comodità. In caso di discrepanze con la versione inglese, prevale la versione inglese.

I record di consenso sono prove. Se possono essere persi, alterati o divulgati, non possono tutelare il cliente in caso di audit. Questa pagina descrive come Cookiesh protegge il servizio e i dati dei clienti. I clienti Enterprise possono richiedere documentazione più dettagliata e questionari di sicurezza compilati scrivendo a security@cookiesh.eu.

Infrastruttura

  • La piattaforma Cookiesh funziona su Amazon Web Services a Francoforte, in Germania, distribuita su più zone di disponibilità.
  • Lo script di consenso è distribuito dalla rete edge globale di Cloudflare, che assorbe anche gli attacchi denial-of-service.
  • Gli ambienti di produzione, staging e sviluppo sono completamente separati. I dati dei clienti non vengono mai usati nei test.
  • L’infrastruttura è definita come codice, revisionata come il codice applicativo e distribuita in automatico.

Protezione dei dati

  • Cifratura in transito. Tutto il traffico usa TLS 1.2 o versioni successive, con HSTS su ogni dominio di Cookiesh.
  • Cifratura a riposo. Database, backup ed esportazioni sono cifrati con AES-256, con chiavi gestite in AWS Key Management Service.
  • Minimizzazione dei dati. I record di consenso contengono un ID pseudonimo, mai un indirizzo IP in chiaro. Gli ID utente passati a identify() sono conservati solo come hash con salt.
  • Residenza nell’UE. I record di consenso sono conservati e trattati nell’UE. La nostra pagina dei sub-responsabili elenca tutti i fornitori che trattano dati personali.

Record di consenso a prova di manomissione

I record di consenso possono essere solo aggiunti. Ogni record include un hash SHA-256 del proprio contenuto e del record precedente, formando una catena per ogni sito. Modificare o eliminare un record invalida tutti gli hash successivi, quindi qualsiasi manomissione è rilevabile.

Verifichiamo ogni catena in automatico ogni giorno. I clienti Enterprise possono esportare le prove della catena e verificarle in modo indipendente.

Sicurezza delle applicazioni

  • Ogni modifica al codice viene revisionata da un altro ingegnere prima del merge.
  • Controlli automatici analizzano ogni modifica alla ricerca di dipendenze vulnerabili, segreti esposti e vulnerabilità comuni.
  • Una società indipendente verifica le vulnerabilità della piattaforma almeno una volta l’anno e correggiamo quanto emerso in ordine di gravità.
  • La dashboard supporta il single sign-on con SAML 2.0 e impone l’autenticazione a più fattori per gli accessi con password.

Integrità dello script

Lo script di consenso viene eseguito sui siti web dei nostri clienti, quindi lo trattiamo con particolare attenzione:

  • Le release vengono generate in una pipeline isolata e richiedono l’approvazione di due ingegneri.
  • Gli URL dello script con versione supportano gli hash Subresource Integrity (SRI), così i browser rifiutano un file modificato.
  • Lo script funziona con una Content Security Policy rigorosa. Supporta i nonce e non usa eval().
  • Lo script non imposta altri cookie oltre a cookiesh_consent e non invia dati a terze parti.

Controllo degli accessi

  • I dipendenti accedono ai sistemi di produzione solo se il loro ruolo lo richiede e ogni accesso viene registrato.
  • L’accesso alla produzione richiede il single sign-on con autenticazione a più fattori basata su hardware.
  • Rivediamo i diritti di accesso ogni trimestre e li revochiamo il giorno stesso in cui una persona cambia ruolo o lascia l’azienda.
  • I dipendenti seguono una formazione su sicurezza e privacy al momento dell’assunzione e poi ogni anno.

Disponibilità e backup

  • I database vengono sottoposti a backup continuo, con ripristino point-in-time per gli ultimi 30 giorni.
  • Testiamo il ripristino dai backup ogni trimestre.
  • Se il servizio di consenso non è raggiungibile, lo script ricorre alla scelta salvata del visitatore o, per i nuovi visitatori, all’impostazione predefinita più protettiva della regione. Non consente mai il tracciamento per errore.
  • I piani Enterprise includono uno SLA di uptime del 99,99%.

Risposta agli incidenti

Disponiamo di un piano documentato di risposta agli incidenti, con ingegneri reperibili 24 ore su 24. Se un incidente di sicurezza riguarda i dati di un cliente, lo informiamo senza ingiustificato ritardo e comunque entro 48 ore dal momento in cui ne veniamo a conoscenza, come previsto dal nostro accordo sul trattamento dei dati. Lo teniamo poi aggiornato fino alla risoluzione dell’incidente.

Divulgazione responsabile

Chi ritiene di aver individuato una vulnerabilità di sicurezza in Cookiesh può scrivere a security@cookiesh.eu indicando i dettagli e i passaggi per riprodurla. Confermeremo la ricezione della segnalazione entro due giorni lavorativi e terremo informato chi l’ha inviata durante la correzione.

Non intraprenderemo azioni legali contro i ricercatori che agiscono in buona fede. Ciò significa non accedere ai dati di altre persone né modificarli, non degradare il servizio e concederci un tempo ragionevole per risolvere il problema prima di renderlo pubblico.