Module PrestaShop santé : stockage chiffré, hébergement HDS et traçabilité

Table des matières :

1. Quand un module PrestaShop devient « santé » : périmètre, menace, contraintes
2. Stockage chiffré dans PrestaShop : chiffrement de champ (AEAD) plutôt que « crypto maison »
3. Gestion des clés : KMS/Vault, séparation des rôles, rotation et sauvegardes
4. Hébergement HDS : ce que ça change pour l’architecture PrestaShop (et ce que ça ne change pas)
5. Traçabilité : journaliser l’accès aux données sensibles sans créer un nouvel angle mort
6. Validation, tests et exploitation : rendre la conformité démontrable (et durable)

Quand un module PrestaShop devient « santé » : périmètre, menace, contraintes

Un module PrestaShop santé n’est pas une catégorie fonctionnelle (« je vends des compléments ») mais un périmètre de données : dès que votre boutique manipule des informations révélant l’état de santé d’une personne (questionnaires, ordonnances, tailles médicales, pathologies, dispositif médical personnalisé), vous sortez de la zone de confort du cœur PrestaShop. En pratique, même un historique de commandes peut devenir sensible si la nature des produits révèle une information de santé (cas typique : parapharmacie spécialisée, matériel d’incontinence, bas de contention, etc.). Le résultat : la base, les sauvegardes, les logs, et les flux d’intégration (ERP/WMS, support, BI) peuvent devenir « dans le scope ».

Pour cadrer sans vous tromper de débat, raisonnez “données” avant “fonctionnalités” :

• Donnée explicitement santé : ordonnance, compte rendu, symptôme, réponse à un questionnaire, document médical, NIR/numéro dossier patient (selon contexte), etc.
• Donnée implicitement santé : achat récurrent d’un produit très spécifique, configuration d’un dispositif personnalisé (ex. orthèse sur mesure), commentaire support (“je suis diabétique, je veux…”).
• Donnée technique corrélable : identifiant client + logs d’accès + timestamp + panier (même si le champ “santé” n’existe pas, la corrélation peut révéler).

Mini-scénario (fréquent) : une boutique vend des articles standards + un configurateur “sur-mesure” pour un dispositif médical. Le configurateur collecte taille/poids + une information du type “pathologie” pour choisir la bonne variante. Même si la commande est ensuite traitée dans un ERP, le simple fait que le back-office, les e-mails transactionnels, le CRM et les exports CSV transportent ces champs suffit à étendre le périmètre de conformité.

Côté conformité, il faut arrêter d’espérer que « SSL + mot de passe fort » suffise. Le RGPD est explicite sur les mesures techniques : l’article 32 cite « la pseudonymisation et le chiffrement des données à caractère personnel » comme moyens possibles d’assurer un niveau de sécurité adapté au risque (source : RGPD, art. 32, EUR-Lex). Ça ne prescrit pas un algorithme, mais ça place la barre : chiffrement correctement implémenté, contrôle d’accès, journalisation, et capacité à prouver.

Concrètement, dès qu’il y a données de santé, vous avez intérêt à vous poser 4 questions très tôt (sinon vous les paierez en refonte) :

1. Où ces données existent-elles (DB, fichiers, e-mails, tickets support, cache, exports) ?
2. Qui y accède (rôles BO, prestataires, service client, flux API, jobs) ?
3. Combien de temps en avez-vous réellement besoin (minimisation/rétention) ?
4. Comment démontrer l’accès et l’intégrité (audit trail + procédures) ?

Enfin, il faut parler menace. PrestaShop expose un back-office, une surface API (Webservice legacy, API admin PrestaShop 9), des modules tiers et des overrides : c’est une accumulation d’entrées qui rend les erreurs probables. Les attaques les plus réalistes ne sont pas « crypto cassée » mais contrôle d’accès cassé (IDOR, élévation de privilèges) et fuite via sauvegardes/logs. Sur ce point, vous pouvez recouper avec l’article interne sur les patterns IDOR et escalade : Broken access control : prévenir IDOR et élévation de privilèges.

Stockage chiffré dans PrestaShop : chiffrement de champ (AEAD) plutôt que « crypto maison »

Le « stockage chiffré » utile dans un module PrestaShop santé, c’est rarement le chiffrement disque (LUKS, chiffrage volume cloud) : ça protège surtout contre le vol de disque, pas contre un dump SQL, un accès admin, une injection SQL ou un export métier. Ce qui compte, c’est le chiffrement applicatif de champs (field-level), idéalement en AEAD (Authenticated Encryption with Associated Data) pour garantir confidentialité et intégrité. Concrètement, vous chiffrez certaines colonnes (ou blobs) avec un algorithme moderne et vous liez cryptographiquement le contexte (shop, customer_id) comme « associated data ».

Ce choix a deux conséquences positives (souvent sous-estimées) :

• Vous pouvez réduire le “blast radius” : une fuite SQL ne donne pas directement le contenu médical, même si les identifiants clients sont exposés.
• Vous forcez un chemin de lecture contrôlé : si le seul code capable de déchiffrer passe par un service/une classe dédiée, vous pouvez y brancher audit, rate limiting, et règles d’accès.

Évitez la crypto « artisanale ». En PHP 8.2/8.3, libsodium (extension sodium, standard) est le meilleur point d’entrée : primitives haut niveau, AEAD, gestion robuste des nonces. Documentation : libsodium documentation.

Exemple minimal (module compatible PrestaShop 8.1+ / 9.x, PHP 8.2+) avec sodium_crypto_aead_xchacha20poly1305_ietf_encrypt. On stocke nonce + ciphertext en base. Le secret n’est pas dans le code : il vient d’une variable d’environnement (ou mieux : d’un KMS/Vault, section suivante).

final class HealthCrypto
{
    public function __construct(private string $keyB64) {}

    private function key(): string
    {
        $key = sodium_base642bin($this->keyB64, SODIUM_BASE64_VARIANT_URLSAFE_NO_PADDING);
        if (strlen($key) !== SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_KEYBYTES) {
            throw new RuntimeException('Bad key length');
        }
        return $key;
    }

    /** @return array{nonce:string,ciphertext:string} */
    public function encrypt(string $plaintext, string $aad): array
    {
        $nonce = random_bytes(SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES);
        $ct = sodium_crypto_aead_xchacha20poly1305_ietf_encrypt($plaintext, $aad, $nonce, $this->key());
        return [
            'nonce' => sodium_bin2base64($nonce, SODIUM_BASE64_VARIANT_URLSAFE_NO_PADDING),
            'ciphertext' => sodium_bin2base64($ct, SODIUM_BASE64_VARIANT_URLSAFE_NO_PADDING),
        ];
    }

    public function decrypt(string $nonceB64, string $ctB64, string $aad): string
    {
        $nonce = sodium_base642bin($nonceB64, SODIUM_BASE64_VARIANT_URLSAFE_NO_PADDING);
        $ct = sodium_base642bin($ctB64, SODIUM_BASE64_VARIANT_URLSAFE_NO_PADDING);
        $pt = sodium_crypto_aead_xchacha20poly1305_ietf_decrypt($ct, $aad, $nonce, $this->key());
        if ($pt === false) {
            throw new RuntimeException('Decryption failed (tampered or wrong key/aad)');
        }
        return $pt;
    }
}

Points non négociables : 1) un nonce unique par chiffrement (ici random_bytes), 2) un AAD stable (ex. shopId:customerId:fieldName) pour éviter qu’un ciphertext soit rejoué dans un autre contexte, 3) des colonnes base64 URL-safe pour éviter les surprises d’encodage.

Deux compléments pratiques, côté “vraie vie PrestaShop” :

• Dimensionnement DB : base64 augmente la taille (≈ +33%). Pour des champs volumineux (questionnaire long, notes), utilisez des types TEXT/LONGTEXT (ou BLOB) adaptés, et documentez ce choix dans votre schéma.
• Fichiers (ordonnances, pièces jointes) : si vous autorisez l’upload, le risque fuit via le storage et via les URLs. Dans l’idéal : stockage objet privé + URLs signées courtes + chiffrement côté application (même logique AEAD), plutôt que “fichier accessible si on devine le chemin”.

Si vous chiffrez des champs recherchables (ex. numéro de dossier), ce n’est pas « compatible SQL » : il faut accepter de perdre la recherche directe ou mettre en place une stratégie de tokenization / index secondaire (hash + sel côté serveur), avec analyse de risques. Dans ce cas, une matrice simple aide à arbitrer :

Besoin métier	Exemple	Stratégie recommandée	Point d’attention
Lecture ponctuelle	ordonnance, réponse questionnaire	chiffrement AEAD	accès strict + audit
Filtrage/tri	statut de traitement (oui/non)	champ non sensible en clair	minimiser les libellés
Recherche exacte	identifiant dossier interne	index secondaire (hash salé)	éviter l’énumération/absence de sel
Recherche “texte libre”	symptômes décrits	éviter / externaliser	sinon, risque très élevé

Gestion des clés : KMS/Vault, séparation des rôles, rotation et sauvegardes

Le chiffrement applicatif n’a de valeur que si la gestion de clés est sérieuse. Opérationnellement : ne mettez pas la clé dans config/settings.inc.php, ni dans un module, ni dans un dépôt Git, ni dans un outil d’admin type cPanel. Préférez : variable d’environnement injectée par le runtime, ou service de gestion de secrets (HashiCorp Vault, AWS KMS, GCP KMS, Azure Key Vault) avec contrôle d’accès et audit.

Pour un module PrestaShop santé, une approche robuste est l’envelope encryption : une clé maître (KMS/HSM) chiffre des clés de données (DEK) utilisées pour chiffrer les champs. Vous stockez en base : dek_encrypted + nonce + ciphertext + key_id. Avantages : rotation de la clé maître sans ré-encrypter toutes les données, granularité par shop/tenant, et révocation plus propre. Inconvénient : complexité (latence KMS, cache mémoire, gestion du cycle de vie).

Trois règles d’architecture qui évitent les “fausses bonnes idées” :

• Séparation prod/préprod : jamais la même clé (ni le même key_id). La préprod est souvent moins surveillée, mais elle reçoit des dumps “pour déboguer”.
• Séparation des rôles : l’équipe support ne doit pas pouvoir “se donner” la clé. Même objectif côté prestataires : accès temporaire, nominatif, tracé.
• Plan “break-glass” : si le KMS tombe ou si une rotation se passe mal, qui a le droit d’agir, comment, et comment vous prouvez a posteriori ce qui a été fait.

La rotation et les sauvegardes sont le piège classique : vous aurez des dumps SQL, des snapshots, des exports support, parfois chez des prestataires. Si vous faites des sauvegardes chiffrées, vous devez aussi chiffrer et versionner les clés (ou au moins leur capacité de déchiffrement) et documenter une procédure de restauration testée. Un bon point de départ côté exploitation est l’article interne : Maintenance PrestaShop : managed services, sécurité serveur, sauvegardes chiffrées. Attention : toute opération de rotation de clés ou de changement de schéma implique un risque de perte de données ; faites-le sur une copie, avec sauvegarde hors-ligne, et un plan de rollback.

Checklist courte (utile en revue de design) :

• [ ] Où est stockée la clé (KMS/Vault/env) et qui peut la lire ?
• [ ] Les clés sont-elles différentes par environnement et par boutique (si multi-store) ?
• [ ] Avez-vous un key_id stocké avec les données pour gérer les rotations ?
• [ ] Avez-vous testé une restauration complète (DB + fichiers + secrets) sur un environnement isolé ?
• [ ] Vos dumps/exports sont-ils contrôlés (procédure, chiffrement, durée de conservation) ?

Hébergement HDS : ce que ça change pour l’architecture PrestaShop (et ce que ça ne change pas)

L’HDS (Hébergement de Données de Santé), en France, n’est pas un « niveau de chiffrement ». C’est une certification et un cadre organisationnel/contractuel qui impose des exigences (process, traçabilité, gestion des incidents, maîtrise de la sous-traitance, etc.) au fournisseur d’hébergement. Si votre module PrestaShop santé stocke des données de santé (au sens réglementaire), l’hébergement doit être opéré par un prestataire certifié HDS pour les activités concernées. Référence officielle : ANS (Agence du Numérique en Santé) : esante.gouv.fr.

Ce que ça change techniquement : votre architecture doit être compatible avec une exploitation « auditée ». Exemple concret : séparation claire des environnements (prod/preprod), gestion stricte des accès (MFA, bastion, comptes nominatifs), inventaire des flux, et supervision. Vous aurez aussi à justifier des briques réseau (reverse proxy, terminaison TLS, filtrage), du patch management et de la journalisation. Sur la partie reverse proxy/TLS et contrôle de débit, l’article HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus est un bon socle.

Concrètement, dans un projet e-commerce, l’angle mort est souvent la chaîne de sous-traitance : CDN, outil de monitoring, support externalisé, solution d’emailing, stockage objet, outil de BI… Si l’un de ces maillons reçoit (même temporairement) des données de santé à caractère personnel, vous devez vérifier qu’il est compatible avec votre cadre (contractuel et technique). C’est là qu’un inventaire de flux (simple tableau “source → destination → type de données → base légale / finalité → chiffrement → rétention”) vous fait gagner des semaines.

Ce que ça ne change pas : PrestaShop n’est pas magiquement conforme parce que vous êtes chez un hébergeur HDS. Les bugs applicatifs (IDOR, injection, XSS, dépendances vulnérables, modules douteux) restent votre problème. Si vous exposez l’API (Webservice legacy ou API admin), vous devez la durcir : authentification, rate limiting, rotation de secrets, scope minimal. Voir : API : sécuriser apikey, limiter le débit et renforcer la conformité et, pour PrestaShop 9, API d’administration PrestaShop 9 : OAuth, API Platform v3, endpoints CQRS.

Point d’arbitrage important : HDS vous aide à encadrer l’infrastructure, mais la conformité “santé” se joue aussi dans le fonctionnel (minimisation des champs, écrans BO, exports, gestion des droits, tickets support). Autrement dit : l’hébergement HDS ne compense pas un module qui stocke trop, trop longtemps, et trop accessible.

Traçabilité : journaliser l’accès aux données sensibles sans créer un nouvel angle mort

La traçabilité ne se résume pas à « activer les logs ». Dans un module PrestaShop santé, l’objectif est de pouvoir répondre à : qui a accédé à quoi, quand, depuis où, via quel chemin (BO, API, job), et avec quel résultat. Et il faut le faire sans logguer le contenu en clair (sinon vos logs deviennent un second data lake sensible).

Pour éviter les logs “inexploitables” (ou dangereux), définissez un périmètre d’événements :

• Lecture d’un enregistrement santé (vue BO, endpoint API, export)
• Création/modification/suppression
• Déchiffrement réussi / déchiffrement refusé (droits) / déchiffrement échoué (AAD faux, clé invalide)
• Exports (qui, quel filtre, combien de lignes)
• Actions d’administration sur les clés (rotation, changement de key_id, révocation)

Implémentation praticable (PS 8.1+/9.x) : un canal Monolog dédié (health_audit), expédié vers syslog/ELK, avec corrélation par request_id, employee_id (ou customer_id), IP, user-agent, et un identifiant de ressource (ex. health_record_id). Vous pouvez aussi stocker une table d’audit applicative pour requêtes internes, mais évitez de faire de MySQL votre système de logs principal. Pour la mise en place de journaux d’audit et la logique de moindre privilège dans les automatisations, l’article Automatisation PrestaShop : sécurité RGPD, moindre privilège et journaux d’audit détaille une méthodologie exploitable.

Une règle simple qui marche bien : logguer les métadonnées, pas le contenu. Exemple : logguer resource_id, action, result et éventuellement la taille (payload_bytes) plutôt que le texte médical. Si vous devez conserver une trace d’un champ (pour prouver qu’un export contenait tel contenu), préférez une empreinte (hash) calculée côté application, plutôt que le contenu en clair.

Si vous devez garantir une non-altération (tamper-evidence), vous pouvez chaîner les événements par hash (type « log chain »). Exemple simple en SQL (à adapter, et à tester sur une base volumineuse) :

CREATE TABLE ps_health_audit (
  id_health_audit BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  created_at DATETIME(6) NOT NULL,
  actor_type ENUM('employee','customer','system') NOT NULL,
  actor_id BIGINT UNSIGNED NULL,
  action VARCHAR(64) NOT NULL,
  resource_type VARCHAR(64) NOT NULL,
  resource_id VARCHAR(128) NOT NULL,
  request_id CHAR(36) NOT NULL,
  ip VARBINARY(16) NULL,
  ua_hash BINARY(32) NULL,
  prev_hash BINARY(32) NULL,
  row_hash BINARY(32) NOT NULL,
  INDEX idx_created_at(created_at),
  INDEX idx_actor(actor_type, actor_id),
  INDEX idx_resource(resource_type, resource_id)
) ENGINE=InnoDB;

Le row_hash est calculé côté app (SHA-256 sur un concat canonique des champs + prev_hash). Ce n’est pas une blockchain, mais ça rend la suppression/modification détectable si vous exportez régulièrement les hashes vers un stockage WORM/immutabilité (objet storage avec rétention, coffre-fort numérique).

Attention : les logs sont aussi des données personnelles (IP, identifiants). Il faut une politique de rétention, et une capacité d’extraction en cas d’exercice de droits.

Validation, tests et exploitation : rendre la conformité démontrable (et durable)

Le vrai différentiel entre « on a chiffré » et « on tient en audit », c’est la preuve. Documentez la matrice : données → lieu de stockage → chiffrement (au repos/en transit) → clé (où, qui, rotation) → accès (rôles, contrôles) → logs (quoi, rétention). Cette matrice sert à la fois à la sécurité, aux équipes produit (“pourquoi on ne peut pas faire une recherche texte”), et à l’exploitation (“quoi restaurer, comment”).

Côté tests, ajoutez des tests automatisés : 1) un test qui vérifie qu’aucune donnée sensible n’est persistée en clair (assert sur DB), 2) un test de non-régression sur l’AAD (changement de contexte doit faire échouer le decrypt), 3) un test d’accès (un rôle ne doit pas lire ce qu’il ne possède pas). Pour les erreurs et leur observabilité, voir : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail.

Ajoutez aussi des validations “exploitation” (souvent oubliées alors qu’elles sont auditables) :

• Revue des rôles BO : un compte “service client” voit-il le strict nécessaire ? Les accès prestataires sont-ils temporaires ?
• Procédure d’export : qui peut exporter, avec quelle justification, et comment l’export est protégé (chiffrement, durée, canal) ?
• Test de restauration : pas juste “le backup existe”, mais “on peut restaurer et déchiffrer”.
• Gestion d’incident : capacité à identifier rapidement “quels enregistrements ont été consultés/exportés” grâce aux journaux d’audit.

Sur la surface web, ne négligez pas les contrôles « boring but effective » : en-têtes de sécurité (CSP, HSTS), durcissement TLS, WAF ajusté au checkout et aux endpoints sensibles. Les WAF mal configurés cassent le métier ; ceux bien réglés réduisent la probabilité d’exploitation opportuniste. Références internes utiles : HTTP Security Headers en PHP : guide CSP, HSTS, X-Frame-Options et WAF PrestaShop : réduire les faux positifs et sécuriser le checkout.

Dernier point : la conformité est une propriété d’exploitation, pas un commit Git. Mettez en place un processus de mise à jour (core + modules), un inventaire SBOM si possible, et une CI qui refuse un module qui manipule des données santé sans passer par vos services de chiffrement/audit (ex. analyse statique sur appels interdits, ou tests d’intégration). La sécurité applicative se dégrade souvent via des modules tiers ou des overrides « rapides » ; si vous êtes en phase de migration, faites-le avec une checklist sécurité et un plan de rollback (cf. Migration PrestaShop 9 : sécurité, tests et plan de rollback). Pour choisir l’infra (mutualisé vs dédié vs cloud managé) en tenant compte de contraintes fortes (HDS, supervision, HA), basez-vous aussi sur : Hébergement e-commerce : mutualisé, VPS, cloud ou SaaS comparés et Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité.

Une façon simple de rendre tout cela “durable” : constituez un petit dossier d’évidence (même en PME) que vous savez ressortir à tout moment :

• Schéma de données + liste des champs santé chiffrés
• Politique de clés (où, rotation, accès)
• Extrait anonymisé de logs d’audit (structure, exemples d’événements)
• Compte rendu de test de restauration + résultat de tests d’accès
• Inventaire des flux (incluant prestataires / sous-traitants)

C’est rarement “parfait” au départ, mais c’est ce socle qui permet de tenir dans le temps — et d’éviter que le prochain module “urgent” ne réintroduise du stockage en clair, un export sauvage, ou un accès trop large.