Développement e-Commerce Sécurité

Le RGPD / GDPR, c’est maintenant pour les e-commerçants !

« Encore un article sur la protection des données » me direz-vous ! A la différence des autres, celui-ci est pourvoyeur de solutions pour une frange importante des personnes qui font des affaires sur Internet : les e-commercants, et, promis, j’essaierais d’être concis 😉

Le RGPD / GDPR, c’est quoi ?

Pour ceux qui auraient loupé un épisode, l’UE planche depuis plusieurs années sur la protection numérique de la vie privée, et a adopté & promulgué une réglementation en avril 2016 qui vise à protéger les internautes. Cette réglementation s’appliquera à partir du 25 mai 2018.

En substance, cette réglementation consiste à une homogénéisation et à un nivellement par le haut des pratiques et mesures pour assurer la confidentialité des données utilisateurs, mais également le contrôle de l’utilisateur sur ses données. Par exemple, des pratiques appliquées pour le traitement de données santé, comme le chiffrement en base, sont désormais la règle. L’idée sous-jacente est que les systèmes doivent être conçus par défaut pour protéger les données personnelles (« Privacy by design« ).

De plus, la responsabilité n’est plus rejettée sur le prestataire quand on fait appel à un fournisseur, mais elle est dorénavant partagée, ce qui implique que les e-commerçants doivent dorénavant justifier de la protection des données même chez leurs prestataires. Par exemple, si vous utilisez un service de retargeting ou de profiling externe, vous avez dorénavant la responsabilité de vérifier que ce dernier soit conforme du point de vue de cette réglementation.

Et si on contrevient à ce règlement à partir de mai 2018 ? Eh bien, on risque tout simplement des amendes à partir de 2% et jusqu’à 4% du chiffre d’affaire mondial. Ça donne matière à réfléchir.

Et comment je fais ?

En tout premier lieu, il faut commencer maintenant, si ce n’est déjà fait. En effet, comme votre responsabilité est engagée, même pour des prestataires externes, et que l’échéance est fixée au 25 mai 2018, la démarche de changement doit être lancée chez tout le monde pour pouvoir aboutir dans les délais.

Ensuite, il convient de faire un inventaire des données personnelles que vous traitez. En règle générale, dans une solution de e-commerce, on va retrouver, le nom, le prénom, le courriel, l’adresse postale, le téléphone, mais il faut aussi considérer l’historique sur le site, ainsi que les devis et commandes passées. Le profilage est également considéré comme une donnée personnelle, que ce soit explicite (l’utilisateur qui cocherait des catégories de préférence) ou implicite (basé sur du big data).

Par la suite, il faut regarder au cas par cas ce qu’il faut en faire. Entre autres mesures techniques, il vous faudra :

  • faire du chiffrement en base de toutes les données nominatives (le nom, le prénom, le courriel, l’adresse postale, le numéro de téléphone) qui permettrait de remonter à l’utilisateur, que ce soit dans le compte, les devis ou les commandes
  • mettre des cases à cocher (en opt-in bien sûr) à la création et à l’édition du compte client pour demander si l’utilisateur accepte le profilage et s’il accepte la transmission à des tiers (notamment si vous faites du retargeting), puis filtrer les exports et autres traitements grâce à ces mêmes coches
  • permettre l’export des données personnelles et la suppression du compte
  • anonymiser les commentaires

Un point de détail concernant les commandes : même si l’utilisateur demande la suppression de ses données, il vous faut quand même garder la trace de la commande, car il s’agit d’une preuve légale, qui relève cette fois du droit des affaires. La commande n’est supprimable que quand le délai de prescription est dépassé, aujourd’hui fixé à 5 ans en France (article L110-4 du code du commerce).

A cela, il faut rajouter des mesures opérationnelles non techniques que vous devrez prendre :

  • nommer un délégué à la protection des données (même si ce n’est qu’un activité à temps partiel)
  • notifier & informer clairement les utilisateurs à chaque fuite de données
  • évaluation & audit réguliers, ainsi qu’à chaque évolution du sytème d’information concerné

Prenons un cas concret : Magento2, comment l’implémente-t-on ?

Le cas d’école de Magento 2 pris en exemple est à la fois un des plus courant, mais également un des plus complexes (on dira merci au passage au modèle EAV de Magento et à son pseudo « ORM »). Les autres solutions d’e-commerce (Prestashop, Magento 1, Sylius, ….) feront l’objet d’autres articles et d’autres modules.

Le chiffrement en base

Un des meilleurs moyens de se prémunir de l’exploitation de données via des canaux non autorisés (requêtes en base, injection SQL, malveillance, etc…) est de chiffrer (réversiblement) les données directement en base. Le cas idéal serait d’avoir un chiffrement avec des clés privées / publiques spécifiques pour chaque utilisateur, mais cela nécessiterait que l’utilisateur garde cette clé privée, ce qui en terme d’utilisabilité n’est pas la panacée. De plus, il faudrait que les données soient toujours chiffrées à destination d’une clé propre à la solution de e-commerce, ce qui limite l’intérêt d’un chiffrement spécifique à chaque utilisateur. Il conviendra d’opter alors pour un chiffrement avec une clé partagée pour l’ensemble de la solution mais accessible uniquement par celle-ci. Dans le cas de php (comme beaucoup de langages), on délègue cette opération à openssl :

method = 'aes-256-cbc';
$encrypted = openssl_encrypt( $string, $method, $key, 0, $initialisationVector );
$decrypted = openssl_decrypt( $encrypted, $method, $key, 0, $initialisationVector );

On notera au passage plusieurs points :

  • les variables $key & $initialisationVector doivent être intialisées une fois pour toutes, puis stockées dans un fichier accessible uniquement de la solution de e-commerce
  • la méthode de chiffrement utilisée « aes-256-cbc » est non seulement considérée comme fiable, mais elle est également accélérée matériellement par les processeurs actuels

Pour Magento 2, on profitera alors des « Setup/InstallSchema » et « Setup/InstallData » pour

  • générer les $key & $initialisationVector notamment avec la fonction « openssl_random_pseudo_bytes » puis les stocker dans un fichier php que l’on rend également inaccessible dans un sous répertoire du var/ (attention également au « directory listing » que beaucoup d’hébergeurs oublient de désactiver)
  • modifier les structures de données des champs concernés (firstname, lastname, middlename, street, email, telephone, fax, etc…) pour que ceux-ci soient suffisamment grands pour enregistrer la version chiffrée de la donnée (version en base64 donc qui prend ~33% de plus), ce qui est particulièrement nécessaire sur les champs des adresses de devis (quote) limités à la base à 20 caractères sous Magento 2

Ensuite, il faut qu’à chaque enregistrement et chaque lecture avec la base de données, cette étape de chiffrement / déchiffrement soit appliquée. Comme souvent avec Magento2 un grand nombre de solutions sont possibles :

  • changer le driver adapter en le surchargeant, mais cela implique une grosse réécriture pour pouvoir identifier les colonnes & les tables concernées, d’autant qu’il faudrait également surcharger les générateurs de requêtes « select »
  • surcharger les classes concernées :
    • \Magento\Customer\Model\Customer
    • \Magento\Customer\Model\Address
    • \Magento\Customer\Model\ResourceModel\Customer
    • \Magento\Customer\Model\ResourceModel\Address
    • \Magento\Customer\Model\ResourceModel\Customer\Collection
    • \Magento\Customer\Model\ResourceModel\Address\Collection
    • \Magento\Quote\Model\Quote
    • \Magento\Quote\Model\Quote\Address
    • \Magento\Quote\Model\ResourceModel\Quote
    • \Magento\Quote\Model\ResourceModel\Quote\Address
    • \Magento\Quote\Model\ResourceModel\Quote\Collection
    • \Magento\Quote\Model\ResourceModel\Quote\Address\Collection
    • \Magento\Sales\Model\Order
    • \Magento\Sales\Model\Order\Address
    • \Magento\Sales\Model\ResourceModel\Order
    • \Magento\Sales\Model\ResourceModel\Order\Address
    • \Magento\Sales\Model\ResourceModel\Order\Collection
    • \Magento\Sales\Model\ResourceModel\Order\Address\Collection

mais cela présente l’inconvénient que d’autres modules ne pourraient pas les surcharger

  • utiliser le système d’event listening de Magento 2, mais les events ne sont pas forcément situés tous au bon endroit
  • utiliser le nouveau système de plugin / interceptor de Magento 2, qui permet d’exécuter une modification du comportement des méthodes publiques d’une classe donnée pour peu que celle-ci utilise l’injection de dépendance pour s’instancier

Cette dernière solution permet d’encadrer les méthodes « load » « loadBy* » et « save » des classes sus-mentionnées en écrivant un minimum de code et en factorisant le plus possible.
Il faudra également surcharger la validation, qui va notamment intervenir dans la méthode « save », pour déchiffrer les données avant validation (méthode « isValid » de \Magento\Framework\Validator), mais aussi surcharger la recherche fulltext dans le back office (méthode « apply » de \Magento\Framework\View\Element\UiComponent\DataProvider\FulltextFilter). En effet, à cause des données illisibles directement en base, la recherche ne fonctionnera donc plus que sur une égalité parfaite avec le terme recherché. Pour retrouver un utilisateur par son email, il faudra donc le taper en entier. Deuxième bémol : la recherche sur les données des clients devient donc également sensible à la casse et nécessite la saisie de l’intégralité de la chaîne recherchée, d’où un formatage à mettre obligatoirement sur les entrées qui sont recherchées, notamment sur l’email dont on descendra la casse, et les noms / prénoms que l’on passera à des versions multibytes de ucwords :

$parts = [];
foreach( explode(' ', mb_strtolower($string)) as $part ) {
    $firstChar = mb_substr($part, 0, 1);
    $then = mb_substr($part, 1);
    $parts[] = mb_strtoupper($firstChar) . $then;
}
$ucWordString = implode(' ', $parts);

Les optin pour le profilage et la transmission à des tiers

Tout d’abord, on rajoutera dans « Setup/InstallData » 2 champs booléens à l’entité Customer :

/* @var $eavSetup \Magento\Eav\Setup\EavSetup */
/* @var $eavConfig \Magento\Eav\Model\Config */
$eavSetup->addAttribute(
    \Magento\Customer\Model\Customer::ENTITY,
    $field,
    [
        'label' => $label,
        'default' => 0,
        'group' => 'Privacy',
        'input' => 'boolean',
        'position' => 200,
        'required' => false,
        'sort_order' => 200,
        'source' => 'Magento\Eav\Model\Entity\Attribute\Source\Boolean',
        'system' => false,
        'used_in_forms', ['adminhtml_customer', 'customer_account_create'],
        'tab_group_code' => 'privacy',
        'type' => 'int',
    ]
);
$attribute = $eavConfig->getAttribute(\Magento\Customer\Model\Customer::ENTITY, $field);
$attribute->setData(
    'used_in_forms',
    ['adminhtml_customer', 'checkout_register', 'customer_account_create']
);
$attribute->save();

On notera au passage la déclaration de l’utilisation de ces valeurs dans les formulaires front & back. Il aurait été possible de faire également dans le formulaire « customer_account_edit », mais plutôt que de perdre ces options dans l’espace client, j’ai préféré le mettre en exergue dans un formulaire séparé dans le compte client. A noter également, dans la community edition de Magento 2, vous devez déclarer un block & un template à rajouter aux formulaires front pour voir apparaître ces champs.

Ne reste ensuite qu’à surcharger les exports dans le backoffice et les expositions via les API pour que les données personnelles n’apparaissent pas. Attention également à ce que tous les modules externes soient surchargés en conséquence pour prendre en compte ces coches.

L’export de données personnelles et la suppression du compte

Selon la réglementation, il s’agit de favoriser l’interopérabilité et la « portabilité » avec d’autres prestataires qui offrent des services similaires. Se pose alors la question du format sous lequel présenter les données de l’utilisateur. Dans ce cas de figure, il est possible d’opter pour un des nombreux format d’échanges de données EDI (Electronic Data Interchange), comme ANSI ASC X12, Edifact ou encore Rosettanet. Pour une implémentation php, les connecteurs edifact semblent être les plus nombreux, et il suffit donc de parcourir l’ensemble des devis, commandes et données personnelles que l’on exportera dans ce format.

Pour la suppression, outre les précautions d’usage pour éviter erreurs de la part de l’utilisateur (taper son mot de passe pour confirmation de la suppression du compte), il convient aussi de cascader les données non critiques. C’est là où Magento (1 comme 2) brille, car les données de commandes sont répliquées et figent dans le marbre à la date de commande la situation. La suppression du compte utilisateur n’entraine donc pas la suppression de ses commandes en cours ou passées. On profitera au passage pour effacer les devis qui comportent ses données personnelles.

L’anonymisation des commentaires

Enfin la partie la plus facile, il suffit juste de surcharger le template vendor/magento/module-review/view/frontend/templates/product/view/list.phtml associé au block \Magento\Review\Block\Product\View\ListView de façon à ne pas faire apparaître le nom et le prénom ou bien de faire un tirage au hasard parmi des prénoms (par exemple avec la dépendance php faker), ou encore de ne mettre que des initiales.

Et si je n’ai pas envie d’implémenter tout ça ?

Ca tombe bien, il vous suffit d’installer ce module et de suivre sa documentation. N’hésitez pas à l’éprouver et à nous faire vos retours ! Si vous avez besoin d’être accompagnés et/ou conseillés, n’hésitez pas non plus à faire appel à nos services !

Sources :
http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX%3A32016R0679
http://eur-lex.europa.eu/legal-content/FR/TXT/PDF/?uri=CELEX:32016R0679&from=FR
https://fr.wikipedia.org/wiki/R%C3%A8glement_g%C3%A9n%C3%A9ral_sur_la_protection_des_donn%C3%A9es
https://www.cnil.fr/fr/reglement-europeen-sur-la-protection-des-donnees-ce-qui-change-pour-les-professionnels
https://korben.info/rgpd-gdpr.html
http://www.zdnet.fr/dossier/rgpd-tout-comprendre-4000237620.htm
https://www.lesechos.fr/idees-debats/cercle/cercle-171284-le-reglement-europeen-sur-la-protection-des-donnees-rgpd-plus-quun-an-avant-lentree-en-vigueur-2096968.php
https://www.lesechos.fr/idees-debats/cercle/cercle-172492-gdpr-et-gestion-des-donnees-cinq-piliers-pour-reussir-2105553.php
https://www.legifrance.gouv.fr/affichCode.do?cidTexte=LEGITEXT000005634379
https://www.economie.gouv.fr/dgccrf/Publications/Vie-pratique/Fiches-pratiques/E-commerce-regles-applicables-au-commerce-electronique
https://fr.wikipedia.org/wiki/Advanced_Encryption_Standard
http://php.net/manual/fr/book.openssl.php
https://www.edibasics.com/edi-resources/document-standards/
https://fr.wikipedia.org/wiki/%C3%89change_de_donn%C3%A9es_informatis%C3%A9es_pour_l%27administration,_le_commerce_et_le_transport
https://packagist.org/packages/sabas/edifact
https://github.com/fzaninotto/Faker
https://github.com/AdfabConnect/magento2gdpr

21/09/2017 5 MIN READ TAGS: , , BY: Alexandre BEAURAIN 0 COMMENT
LIRE LA SUITE

Alexandre BEAURAIN