Tutoriel : L'Express, ou comment ne pas gérer une fuite de données

Aujourd'hui, c'est ZDNet qui révèle qu'un serveur de base de données MongoDB, géré par l'Express et contenant environ 700 000 documents, était ouvert aux quatre vents.

Jusque là, malheureusement rien d'exceptionnel — quoique cela soit fâcheux, la configuration par défaut de MongoDB est notoirement mauvaise. Les contrôles d'accès ne sont en effet pas activés par défaut. De plus, il aura fallu attendre mai 2017 et la version 3.5.7 du logiciel pour qu'il n'écoute plus sur toutes les interfaces réseau, mais uniquement sur le localhost. Autrement dit, avant cette date, un serveur fraîchement installé acceptait n'importe quelle connexion entrante sans aucune forme d'authentification.

D'après ZDNet, Mickey Dimov, le techos américain à l'origine de la découverte, a été contraint de contacter l'Express par « le biais d'un intermédiaire ». C'est un détail, mais cela signifie sans doute que le choix de l'interlocuteur n'était pas clair, que la langue était un problème, ou les deux. Afficher de manière lisible, en français et en anglais (la franca lingua en matière de sécurité informatique), le canal à utiliser (généralement une adresse email assortie d'une clé de chiffrement GPG) pour contacter l'interlocuteur ad hoc est une bonne pratique. Elle est malheureusement (très) peu répandue, alors qu'elle ne coûte pas grand chose.

Le signalement est par la suite resté lettre morte, pendant près d'un mois. En l'absence d'un point de contact dédié, l'absence de réponse efficace s'explique assez bien.

Le problème a été finalement corrigé, mais avant l'enquête de ZDNet, aucune communication n'a été semble-t-il envoyée aux personnes dont les données étaient présentes dans cette base de données. Pas plus que la CNIL n'a été mise dans la boucle.

L'Express, sollicité par la rédaction de ZDNet, a répondu par la voix d'Emma Defaud… La rédactrice en chef du magazine. Nouveau problème, la réponse vient de quelqu'un qui n'est ni compétent pour répondre à ce type de questions, ni responsable de la situation.

Les explications fournies ultérieurement par le magazine sont, quant à elles, exemplaires de ce qu'il ne faut pas faire dans ce genre de situation. Minimiser un problème est généralement le meilleur moyen pour instiller chez les gens le sentiment qu'on les prend pour des tanches.

Un serveur « inactif » mais joignable depuis Internet, « utilisé à des fins de test » mais hébergeant des données de production, s'assimile objectivement un serveur… De production. Dans ce genre de cas, il aurait sans doute fallu publier un « post-mortem » clair et honnête, décrivant précisément la fonction du serveur, la description des données dont on suspecte qu'elles sont dans la nature, les mesures de remédiation déjà effectives ou celles en cours de mise en œuvre, ainsi que l'éventuelle conduite à tenir pour les victimes de la fuite.

Plus que la recrudescence de fuites elle-même, c'est l'absence quasiment systématique d'une prise en charge sérieuse et transparente qui est devenue intolérable.