Sécurisation des données : encrypter ses données en Drupal

Tout d’abord, répondons à la question de pourquoi encrypterait-on ses données ? Simplement car un utilisateur peut trouver une faille qui lui donnera accès en lecture sur votre base de données (par exemple via une injection SQL) sans accès au code. Cependant, si les données sont encryptées et qu’il ne dispose pas de la clé (pour faire simple, généralement une grosse chaîne de caractères localisée dans le code), il ne lira que des chaînes de caractères sans aucun intérêt. Sa pêche aux informations aura donc été vaine.

Si d’aventure vous ne seriez pas convaincu, je me dois de vous informer que à minima toutes les données personnelles de vos utilisateurs (e-mail, nom, etc.) doivent obligatoirement être encryptées (merci RGPD !).

À l’inverse, il n’est pas très pertinent d’encrypter toutes les données par défaut. En effet, l’opération est lourde et ralentit nécessairement l’applicatif à l’enregistrement comme à la lecture car encrypter et décrypter sont des opérations lourdes. Travailler ainsi sur une donnée de toutes les façons publique ne présente pas un intérêt majeur. Il convient donc bien de repérer les données à caractère sensible pour y concentrer nos efforts.

Passons désormais au comment, car Drupal n’a pas nativement mis en place ce système de cryptage des données et elles peuvent être localisées à divers endroits, nécessitant plusieurs modules : 

Le premier, base de la plupart des autres est le module Encrypt. En effet, c’est lui qui réalise l’encryptage grâce à divers algorithmes de cryptage disponible dans divers sous-modules disponibles (cf. la page du module pour la liste exhaustive et les divers algorithmes de cryptage utilisés). Seul, il ne fait donc aucune action et il faut lui adjoindre divers modules : 

• Field Encryption qui permet de configurer les champs à encrypter des « entités drupaliennes » (nœuds, c’est-à-dire contenus, utilisateurs, commentaires, etc.).
• Webform Encrypt fait de même avec les champs des formulaires fournis par le module Webform, couramment utilisé pour les formulaires de contact, réceptacle de données souvent sensibles.
• Database email encryption va s’occuper d’encrypter les adresses e-mails dans la table « user » de la base de données, i.e. les adresses e-mail rentrées lors de l’inscription, dans le champ e-mail par défaut des profils Drupal.  En effet Field Encryption ne gère pas encore les « base field », les champs qui n’ont pas été ajoutés dans l’interface.

Autre donnée souvent oubliée : les adresses IP sont également considérées comme des données sensibles , précise jusqu’à un pâté de maison, parfois plus encore. Or, les logs par défaut de Drupal enregistrent ces données automatiquement. Pas de panique, nous avons aussi un module pour cela : Cryptolog. Le module encrypte avec une clé dont la durée n’est que d’une journée seulement. Après 24h, il n’est plus possible de décrypter. Le module permet donc d’un côté de faire expirer la lecture des IP, mais conserve l’historique d’une attaque par déni de service, de tentatives de log ou autres, puisque la chaîne encryptée générée est identique par période de 24h. On perd cependant la capacité de comparaison sur des durées plus longues.