Sécurité et réponse aux incidents

Nous appelons incident de sécurité tout événement qui porte atteinte à la confidentialité, à l’intégrité ou à la disponibilité des données que nous détenons. Cela couvre notamment :

• Un accès non autorisé : quelqu’un consulte des données sans y avoir droit — compte compromis, clé d’accès dérobée, faille exploitée.
• Une perte de données : des données deviennent irrécupérables, par suppression accidentelle ou défaillance technique.
• Une altération : des données sont modifiées sans autorisation, ou de façon incontrôlée.
• Une divulgation : des données sont rendues visibles à des personnes qui n’auraient pas dû les voir.

Cela vaut pour les données des marchands qui utilisent LIORA comme pour celles de leurs propres clients, auxquelles l’application accède pour fonctionner.

Une interruption de service qui ne rend aucune donnée inaccessible, et qui ne l’expose ni ne l’altère, relève du support et non de la présente politique. En revanche, une panne qui empêche durablement d’accéder à vos données est bien une atteinte à leur disponibilité : elle est traitée ici.

Cette distinction commande tout ce qui suit, et notamment qui doit prévenir l’autorité de contrôle.

• Vos données de compte et de facturation : Hugo BILLAUX EI en est le responsable du traitement. Les obligations de notification lui incombent.
• Les données des clients de votre boutique : Hugo BILLAUX EI agit pour votre compte, en qualité de sous-traitant. Vous en restez le responsable du traitement, et c’est à vous qu’il revient de saisir l’autorité de contrôle si une violation l’exige. Notre rôle est de vous alerter et de vous aider.

Écrivez à direction@liora-eu.com, en décrivant ce que vous avez constaté et, si possible, comment le reproduire. Cette adresse est relevée en personne par l’entrepreneur qui exploite LIORA.

Nous accusons réception au plus tard le jour ouvré suivant la réception de votre message. Cet engagement porte sur l’accusé de réception, pas sur la résolution : le délai de correction dépend de la nature de l’incident, et nous ne fixons pas d’avance un délai que nous ne pourrions pas tenir.

Si vous êtes chercheur en sécurité, vous pouvez nous signaler une vulnérabilité à la même adresse. Nous ne proposons pas de programme de récompense, et nous n’engagerons aucune poursuite contre quiconque nous signale de bonne foi une faille sans l’avoir exploitée au-delà de ce qui est nécessaire pour la démontrer. Cet engagement n’engage que Hugo BILLAUX EI et ne saurait faire obstacle à l’action publique.

L’évaluation est faite par l’entrepreneur qui exploite LIORA, lequel assure également la responsabilité technique du service. Il n’y a pas d’équipe d’astreinte : c’est la conséquence de notre taille, et nous préférons l’écrire plutôt que de laisser croire à une organisation qui n’existe pas.

Nous engageons la qualification dès la prise de connaissance du signalement et la menons aussi vite que l’incident le permet. Nous ne fixons pas de délai : il dépend de ce qu’il y a à examiner. Trois critères la guident :

• La nature des données touchées : données de compte, données de facturation, données des clients d’un marchand.
• L’étendue : un compte, plusieurs, ou l’ensemble du service.
• Le risque pour les personnes : ce que quelqu’un pourrait faire des données concernées — usurpation, démarchage, préjudice financier.

Chaque incident est classé selon trois niveaux de gravité, qui commandent la priorité de la correction :

• Niveau 1 — critique : violation avérée ou fortement soupçonnée de données personnelles, compromission d’un accès d’administration ou d’un secret, ou atteinte à des données de boutique obtenues via Shopify. Confinement immédiat, toute autre tâche suspendue, et notifications dans les délais décrits plus bas.
• Niveau 2 — élevé : faille exploitable sans indice d’exploitation, ou panne qui empêche durablement l’accès aux données. Correction prioritaire, et recherche de tout signe d’exploitation, qui ferait passer l’incident au niveau 1.
• Niveau 3 — modéré : événement sans atteinte aux données — tentative bloquée, défaut de configuration sans exposition, vulnérabilité théorique. Correction planifiée.

Le niveau retenu est rehaussé dès que les faits l’exigent. Les notifications ne dépendent pas de lui mais des faits : un simple soupçon touchant des données obtenues via Shopify suffit à prévenir Shopify, quel que soit le niveau.

Dès qu’un incident est confirmé, et avant toute recherche de cause, nous cherchons à l’arrêter :

• Révocation des accès compromis : fermeture des sessions concernées, désactivation des comptes en cause.
• Rotation des secrets : renouvellement des clés d’accès et des jetons susceptibles d’avoir été exposés, y compris les identifiants dont nous disposons chez nos prestataires techniques.

Vient ensuite la correction, une fois l’hémorragie arrêtée :

• Correctif : la cause est identifiée, corrigée, puis déployée.
• Vérification : nous rejouons le scénario de l’incident pour vérifier qu’il ne fonctionne plus.

Couper un accès compromis passe toujours avant la continuité du service : s’il faut interrompre une fonctionnalité pour arrêter une fuite, nous l’interrompons.

Dès qu’un incident est soupçonné, et avant toute correction qui pourrait les effacer, nous préservons les éléments qui permettent d’établir les faits : journaux, horodatages, fichiers et messages en cause. Ils ne servent qu’à l’analyse de l’incident et à répondre aux autorités, et ne sont pas conservés plus longtemps que l’incident ne figure au registre.

Lorsque la violation porte sur des données dont Hugo BILLAUX EI est responsable — compte, facturation —, nous la notifions à la CNIL au plus tard 72 heures après en avoir pris connaissance, à moins qu’elle ne soit pas susceptible d’engendrer un risque pour les droits et libertés des personnes concernées (article 33 du RGPD). Si toutes les informations ne sont pas disponibles dans ce délai, nous notifions ce que nous savons et complétons ensuite.

Lorsque la violation porte sur les données des clients d’un marchand, nous informons ce marchand dans les meilleurs délais, conformément à l’article 33.2 du RGPD. C’est à lui, responsable du traitement, qu’il revient alors de décider de la notification à l’autorité de contrôle. Notre message indique la nature de la violation, les catégories de données touchées, les conséquences probables et les mesures déjà prises, afin qu’il puisse se déterminer.

Lorsque la violation est susceptible d’engendrer un risque élevé pour les personnes concernées, celles-ci en sont informées (article 34 du RGPD). Pour les données de compte, cette communication nous incombe. Pour les clients d’un marchand, elle incombe au marchand, seul responsable du traitement et seul en relation avec eux : nous lui fournissons les éléments nécessaires (article 28.3.f).

Lorsque l’incident touche, ou peut toucher, des données de boutique obtenues via Shopify, nous prévenons Shopify dans les 24 heures qui suivent le moment où nous en avons connaissance, dès le simple soupçon et sans attendre la fin de la qualification, comme l’exigent ses conditions d’utilisation de l’API.

Nous ne publions pas d’annonce publique sur un incident tant que la faille n’est pas corrigée, pour ne pas indiquer à d’autres comment l’exploiter. Cette réserve ne retarde ni la notification à l’autorité, ni l’information des marchands, ni celle des personnes concernées, ni celle de Shopify.

Chaque incident est consigné dans un registre interne, y compris lorsqu’il ne donne lieu à aucune notification. Le registre indique la date de découverte, les faits, les données concernées, la qualification retenue, les mesures prises et, le cas échéant, les notifications envoyées — à l’autorité, aux marchands, aux personnes concernées et à Shopify — avec leur date.

Ce registre est tenu au titre de l’article 33, paragraphe 5, du RGPD, qui impose de documenter toute violation afin que l’autorité de contrôle puisse vérifier le respect de ces obligations. Il lui est communiqué sur demande.

Une fois l’incident clos, nous cherchons ce qui l’a rendu possible, et non qui en est responsable. La question est toujours la même : qu’est-ce qui a permis que cela arrive, et qu’est-ce qui empêchera que cela se reproduise ?

La correction ne s’arrête donc pas au défaut lui-même : quand c’est possible, nous ajoutons un contrôle automatique qui échoue si le défaut réapparaît, de sorte que la même cause ne puisse pas produire deux fois le même incident.

Voici les mesures qui protègent vos données en permanence. Nous n’y mentionnons que ce qui est effectivement en place.

• Chiffrement en transit : toutes les connexions au site, à l’application et au service de connexion passent par HTTPS, que les navigateurs sont tenus d’employer (HSTS).
• Chiffrement au repos : la base de données de l’application, qui contient aussi les fichiers que vous y déposez, est chiffrée par son hébergeur ; les autres fichiers de l’application sont conservés dans des espaces de stockage privés et chiffrés. Les jetons d’accès aux boutiques Shopify sont en outre chiffrés par l’application elle-même (AES-256-GCM), avec une clé conservée hors de la base.
• Cloisonnement par entreprise : dans la base de l’application, chaque donnée appartient à une entreprise, et c’est la base elle-même qui refuse de montrer à une entreprise les données d’une autre (sécurité au niveau des lignes).
• Accès restreint : la base de données de l’application n’est joignable que depuis une liste d’adresses autorisées, et l’application s’y connecte avec un rôle aux droits limités, distinct de celui qui en modifie la structure.
• Mots de passe et connexion : les mots de passe sont conservés sous forme hachée ; la double authentification est proposée à chaque client et imposée à chaque membre de notre équipe ; les tentatives de connexion sont limitées en nombre ; réinitialiser son mot de passe ferme toutes les sessions ouvertes sur le site, mais pas une session déjà ouverte dans l’application, qui prend fin d’elle-même à son expiration.
• Journalisation : chaque action de notre équipe sur un compte client est enregistrée — auteur, action, date — et conservée trois ans ; dans l’application, le journal d’activité retrace qui a fait quoi, et chaque export de données personnelles y laisse une trace.
• Sauvegardes : la base de données de l’application est sauvegardée automatiquement chaque jour par son hébergeur, et ces sauvegardes sont chiffrées.
• Hébergement en Europe : l’application et ses données sont hébergées en France ; le site s’exécute à Paris et sa base de données se trouve à Francfort.
• Organisation : l’accès aux outils d’administration est réservé aux personnes habilitées, chacune limitée aux seuls onglets nécessaires à sa mission, et en lecture seule si elle n’a pas à agir ; ces personnes sont tenues à la confidentialité.

Les durées de conservation et le rôle de chacun de nos prestataires sont décrits dans notre Politique de confidentialité ; les engagements que nous prenons pour les données de vos clients, dans notre Accord de sous-traitance des données.

Une politique de sécurité vaut par ce qu’elle tient. Voici donc ce que Hugo BILLAUX EI n’a pas, aujourd’hui :

• Aucune astreinte 24 h/24 : un signalement envoyé un dimanche soir n’est lu qu’au jour ouvré suivant.
• Aucun centre de supervision : nous n’avons pas d’équipe qui surveille en permanence.
• Aucune certification : ni ISO 27001, ni SOC 2, ni équivalent. Nous n’en revendiquons aucune.
• Aucun programme de récompense : les signalements de vulnérabilité sont les bienvenus, mais ils ne sont pas rémunérés.
• Aucun taux de disponibilité garanti : nous sommes tenus d’une obligation de moyens, sans taux de disponibilité, comme le précisent nos Conditions générales de vente.

Ce qui est décrit plus haut, en revanche, est ce que nous faisons réellement. Cette page sera mise à jour si nos moyens changent.