Aller au contenu

Langue

Confiance

Sécurité

Cette traduction est fournie à titre indicatif. En cas de divergence avec la version anglaise, la version anglaise prévaut.

Les enregistrements de consentement sont des preuves. S’ils peuvent être perdus, modifiés ou divulgués, ils ne vous protègent pas lors d’un audit. Cette page décrit comment Cookiesh assure la sécurité du service et de vos données. Les clients Enterprise peuvent demander une documentation plus détaillée et des questionnaires de sécurité complétés à security@cookiesh.eu.

Infrastructure

  • La plateforme Cookiesh fonctionne sur Amazon Web Services à Francfort, en Allemagne, répartie sur plusieurs zones de disponibilité.
  • Le script de consentement est servi depuis le réseau edge mondial de Cloudflare, qui absorbe aussi les attaques par déni de service.
  • Les environnements de production, de préproduction et de développement sont entièrement séparés. Les données clients ne sont jamais utilisées pour les tests.
  • L’infrastructure est définie sous forme de code, relue comme le code applicatif et déployée automatiquement.

Protection des données

  • Chiffrement en transit. Tout le trafic utilise TLS 1.2 ou une version ultérieure, avec HSTS sur chaque domaine Cookiesh.
  • Chiffrement au repos. Les bases de données, sauvegardes et exports sont chiffrés en AES-256, avec des clés gérées dans AWS Key Management Service.
  • Minimisation des données. Les enregistrements de consentement contiennent un identifiant pseudonyme, jamais d’adresse IP brute. Les identifiants utilisateur transmis à identify() ne sont stockés que sous forme d’empreintes salées.
  • Hébergement dans l’UE. Les enregistrements de consentement sont stockés et traités dans l’UE. Notre page des sous-traitants ultérieurs liste chaque prestataire qui traite des données personnelles.

Enregistrements de consentement infalsifiables

Les enregistrements de consentement sont en ajout seul. Chaque enregistrement inclut une empreinte SHA-256 de son propre contenu et de l’enregistrement précédent, ce qui forme une chaîne par site. Modifier ou supprimer un enregistrement casse toutes les empreintes suivantes : toute falsification est donc détectable.

Nous vérifions automatiquement chaque chaîne tous les jours. Les clients Enterprise peuvent exporter les preuves de chaînage et les vérifier de manière indépendante.

Sécurité applicative

  • Toute modification du code est relue par un pair avant d’être fusionnée.
  • Des contrôles automatisés analysent chaque modification à la recherche de dépendances vulnérables, de secrets exposés et de failles de sécurité courantes.
  • Un cabinet indépendant teste la plateforme au moins une fois par an pour en détecter les faiblesses, et nous corrigeons les constats par ordre de gravité.
  • Le tableau de bord prend en charge l’authentification unique via SAML 2.0 et impose l’authentification multifacteur pour les connexions par mot de passe.

Intégrité du script

Le script de consentement s’exécute sur les sites web de nos clients : nous le traitons donc avec un soin particulier.

  • Les versions sont construites dans un pipeline isolé et doivent être approuvées par deux ingénieurs.
  • Les URL de script versionnées prennent en charge les empreintes Subresource Integrity (SRI) : les navigateurs refusent ainsi tout fichier modifié.
  • Le script fonctionne avec une Content Security Policy stricte. Il prend en charge les nonces et n’utilise pas eval().
  • Le script ne dépose aucun autre cookie que cookiesh_consent et n’envoie aucune donnée à des tiers.

Contrôle des accès

  • Les employés n’ont accès aux systèmes de production que si leur rôle l’exige, et chaque accès est journalisé.
  • L’accès à la production nécessite une authentification unique avec une authentification multifacteur par clé matérielle.
  • Nous revoyons les droits d’accès chaque trimestre et les retirons le jour même où une personne change de rôle ou quitte l’entreprise.
  • Les employés suivent une formation à la sécurité et à la vie privée à leur arrivée, puis chaque année.

Disponibilité et sauvegardes

  • Les bases de données sont sauvegardées en continu, avec une restauration à un instant donné sur les 30 derniers jours.
  • Nous testons la restauration des sauvegardes chaque trimestre.
  • Si le service de consentement est injoignable, le script se rabat sur le choix enregistré du visiteur ou, pour les nouveaux visiteurs, sur la valeur par défaut la plus protectrice de la région. Il ne laisse jamais tout passer en cas de panne.
  • Les offres Enterprise incluent un SLA de disponibilité de 99,99 %.

Réponse aux incidents

Nous disposons d’un plan de réponse aux incidents documenté, avec des ingénieurs d’astreinte 24 heures sur 24. Si un incident de sécurité affecte vos données, nous vous en informons dans les meilleurs délais, et au plus tard 48 heures après en avoir pris connaissance, comme l’exige notre accord de traitement des données. Nous vous tenons ensuite informé jusqu’à la résolution de l’incident.

Divulgation responsable

Si vous pensez avoir découvert une vulnérabilité de sécurité dans Cookiesh, écrivez à security@cookiesh.eu en décrivant le problème et les étapes pour le reproduire. Nous accuserons réception de votre signalement sous deux jours ouvrés et vous tiendrons informé pendant la correction.

Nous n’engagerons aucune poursuite contre les chercheurs qui agissent de bonne foi. Cela signifie que vous n’accédez pas aux données d’autres personnes et ne les modifiez pas, que vous ne dégradez pas le service, et que vous nous laissez un délai raisonnable pour corriger le problème avant de le divulguer.