Politique de réponse aux incidents de sécurité
Qui répond
Le service est édité par GRT Ventures OÜ, société de droit estonien. Il est exploité par un seul opérateur, le représentant légal de la société, qui conduit la réponse aux incidents de bout en bout. Il est joignable à l'adresse support@hidemydrop.com, reprise en bas de page. Il n'y a pas d'équipe d'astreinte : cette page décrit ce qu'une seule personne fait, dans quel ordre et dans quels délais.
Ce que le service appelle un incident
Un incident de sécurité est tout événement, avéré ou soupçonné, qui entraîne la destruction, la perte, l'altération ou la divulgation non autorisée de données traitées par le service, ou un accès non autorisé à ces données ou aux comptes qui les détiennent. Entrent dans cette définition, sans que la liste soit limitative :
- un accès non autorisé à un compte marchand, au compte opérateur ou au serveur ;
- la divulgation d'un jeton d'accès, d'une clé d'API, d'un mot de passe ou d'une sauvegarde ;
- une faille du code ou d'une dépendance qui expose des données de commande à un tiers ;
- la perte ou l'altération de données, y compris par erreur de manipulation ;
- un incident chez un sous-traitant qui touche des données du service.
Données concernées
Côté marchand, le service détient l'adresse e-mail de contact, le mot de passe sous forme hachée, le domaine et le nom de la boutique, les clés d'API, le jeton d'accès Shopify, le plan souscrit avec ses données d'usage, ainsi que l'historique des connexions au compte. Côté acheteur, pour chaque commande transmise par la boutique, il détient l'adresse e-mail et le nom, le code pays de destination, le numéro, le montant et la devise de la commande, les numéros de suivi transporteur et l'identifiant de suivi masqué, et les événements de transport du colis. Le service ne reçoit ni ne stocke l'adresse postale de l'acheteur, ni son numéro de téléphone. Le détail de chaque catégorie et les durées de conservation figurent dans la politique de confidentialité.
Mesures en place
Les mesures ci-dessous existent dans le code et sur le serveur à la date indiquée en bas de page. Elles sont décrites telles qu'elles sont, sans certification ni audit externe.
- Transport : chaque hôte du service, y compris le domaine neutre des pages de suivi, est servi en TLS.
- Jeton d'accès Shopify : chiffré en base en AES-256-GCM, avec une clé conservée en dehors de la base de données. Sans cette clé, le jeton stocké est illisible.
- Mots de passe : hachés en bcrypt, jamais conservés en clair, huit caractères au minimum.
- Jetons de réinitialisation de mot de passe : seul leur condensé est stocké. Le jeton lui-même n'est jamais écrit en base.
- Sessions : cookie signé, inaccessible aux scripts, marqué Secure en production, qui expire après sept jours.
- Webhooks : chaque webhook Shopify (commandes, expéditions, désinstallation, abonnement, demandes RGPD) est vérifié par sa signature HMAC. Une signature absente ou fausse est refusée. Les webhooks entrants au format WooCommerce exigent une signature calculée avec le secret d'API du marchand, et les webhooks sortants configurés par le marchand sont signés avec un secret propre à cette intégration.
- Comptes marchands : second facteur au choix (code TOTP ou passkey), historique des connexions consultable dans le compte (date, méthode d'authentification, adresse IP, navigateur, succès ou échec), rotation de la clé et du secret d'API par le marchand lui-même, limite de tentatives de connexion par adresse IP.
- Accès opérateur : un seul compte opérateur. Un code TOTP est exigé à chaque connexion par mot de passe quand il est activé ; à défaut le compte doit porter une passkey, et l'existence de l'un ou l'autre est revérifiée en base à chaque requête du back-office. La consultation de la fiche d'un marchand, de son fil d'activité, d'un ticket ou d'une pièce jointe, et chaque modification de son compte par l'opérateur (plan, limites, mot de passe temporaire, réinitialisation du code TOTP, connexion à sa place, annulation d'une suppression), sont inscrites dans le journal des événements du compte concerné, avec l'identité de l'opérateur.
- Hébergement : base de données SQLite sur un serveur Hetzner situé dans l'Union européenne.
- Sauvegardes : copie quotidienne de la base sur le serveur, avec rotation. Une sauvegarde chiffrée est emportée hors du serveur trois fois par jour avec restic.
- Rétention : une tâche quotidienne purge le journal technique après 180 jours et l'historique des connexions après 365 jours, et inscrit chaque passage dans le journal du processus, même sans rien à effacer.
- Demandes RGPD transmises par Shopify : les webhooks customers/data_request, customers/redact et shop/redact sont reçus et traités après vérification de leur signature (export de la commande, anonymisation, effacement des données de la boutique).
- Minimisation : ni téléphone ni adresse postale, deux scopes Shopify en lecture seule (read_orders et read_fulfillments), et le numéro de suivi transporteur réel n'est jamais montré à l'acheteur.
Détection et signalement
Le service ne dispose pas d'un centre de supervision. La détection repose sur quatre sources : les journaux du service (journal technique, journal des événements de compte, historique des connexions), la lecture régulière du back-office par l'opérateur, les signalements reçus à support@hidemydrop.com, et les avis de l'hébergeur, de Shopify ou d'un sous-traitant.
Toute personne, marchand, acheteur ou tiers, qui constate un comportement anormal du service ou pense avoir trouvé une faille peut écrire à support@hidemydrop.com. Le message peut rester anonyme et il est lu par l'opérateur lui-même. Le service ne verse pas de prime de découverte. Il demande seulement de ne pas exploiter la faille et de ne pas diffuser les données qu'elle exposerait avant qu'elle soit corrigée.
Qualification sous 24 heures
Un signalement ou une anomalie est examiné dans les 24 heures qui suivent sa réception. L'examen répond à quatre questions : s'agit-il d'un incident au sens de cette page, quelles données et quels comptes sont touchés, depuis quand, et l'exposition est-elle encore en cours. Un dossier d'incident est ouvert dès cet examen, avec une référence, l'heure de prise de connaissance et la chronologie des faits connus. Un signalement qui se révèle sans suite est tout de même consigné, avec le motif.
Confinement
Le confinement vise d'abord à arrêter l'exposition, avant même d'en comprendre la cause. Selon le cas, l'opérateur :
- révoque les clés d'API et les jetons concernés, et remplace la clé de signature des sessions, ce qui déconnecte tous les comptes ;
- remplace les secrets du serveur : clé de chiffrement des jetons Shopify, secrets d'API, identifiants et second facteur du compte opérateur ;
- coupe une fonction, une intégration ou le service entier, si c'est le seul moyen d'arrêter la fuite ;
- restaure la base depuis la dernière sauvegarde saine quand des données ont été altérées ou perdues ;
- met de côté les journaux et les éléments utiles à l'analyse avant toute remise en service.
La remise en service passe par la correction de la cause, puis par une vérification que l'exposition a cessé.
Notification
Marchands. Quand un incident touche les données d'un marchand ou celles de ses acheteurs, le marchand en est informé à l'adresse e-mail de son compte au plus tard 72 heures après que le service en a pris connaissance, comme le prévoit la section 6 de l'accord de traitement des données. Le message décrit la nature de l'incident, les catégories de données et de personnes concernées, les conséquences probables, les mesures prises et celles que le marchand peut prendre de son côté. Pour les données de ses acheteurs, le marchand est responsable de traitement : c'est à lui qu'il revient de notifier son autorité de contrôle et, le cas échéant, les acheteurs. Le service lui fournit les éléments nécessaires.
Autorité de contrôle. Pour les données dont GRT Ventures OÜ est responsable de traitement, c'est-à-dire les données des comptes marchands, la violation est notifiée à l'autorité de contrôle compétente, l'Andmekaitse Inspektsioon, autorité estonienne de protection des données, dans les 72 heures qui suivent la prise de connaissance, conformément à l'article 33 du règlement général sur la protection des données, à moins que la violation ne soit pas susceptible d'engendrer un risque pour les personnes concernées. Si la notification ne peut pas être complète dans ce délai, elle est faite par étapes. Quand un risque élevé existe pour les personnes, elles sont informées directement, conformément à l'article 34 du même règlement.
Shopify. Quand des données obtenues par l'intermédiaire de Shopify sont concernées (données de boutique, données de commande ou jeton d'accès), Shopify est informé de toute violation, avérée ou soupçonnée, dans les 24 heures qui suivent la prise de connaissance, par un signalement à Shopify Support (formulaire partenaires), comme l'exige la section 6.2.10 des conditions d'utilisation de l'API Shopify.
Retour d'expérience et dossier d'incident
Une fois l'incident clos, l'opérateur rédige un compte rendu : chronologie, cause, données et comptes touchés, mesures de confinement, notifications faites, corrections apportées au code ou à l'exploitation, et ce qui aurait permis de détecter l'incident plus tôt. Ce compte rendu rejoint le dossier d'incident.
Le dossier est conservé par GRT Ventures OÜ, comme l'impose l'article 33, paragraphe 5, du règlement, qui demande de documenter toute violation, ses effets et les mesures prises. Il est tenu à la disposition de l'autorité de contrôle et, pour ce qui le concerne, du marchand.
Certifications et disponibilité
Le service ne détient aucune certification de sécurité et ne s'engage sur aucun taux de disponibilité chiffré. Les mesures décrites ici sont celles qui existent. Leur liste évolue avec le code, et la date en bas de page indique l'état décrit.
Modifications
Cette page peut évoluer avec le service. La date de dernière mise à jour figure en bas de page.