DigiCert : une migration réseau a exposé un système interne pendant plus d'un an, des pièces d'identité de clients consultées

· Par Edouard Schlumberger
👈 les autres actualités

L'autorité de certification DigiCert a confirmé le 19 octobre 2026 qu'un compte non autorisé avait consulté une partie de ses archives clients entre le 27 juin et le 2 juillet 2026. La porte d'entrée était ouverte depuis le 4 février 2025 : une migration réseau avait rendu accessible depuis Internet un système interne prévu pour n'être joignable que par VPN. Pour un DPO, l'incident tient en une phrase du rapport de DigiCert : la migration avait été traitée comme un changement d'infrastructure, pas comme un changement de sécurité.

Ce qui s'est passé

DigiCert a rendu l'incident public sur Bugzilla, l'outil de suivi de Mozilla, par un rapport préliminaire puis un rapport complet daté du 1er novembre 2026. Le système en cause archive les informations que les clients fournissent pour faire vérifier leur identité.

Le 4 février 2025, ce système est déplacé d'un segment réseau restreint par VPN vers une autre zone de disponibilité, exposée à Internet. Une fonction d'auto-inscription conçue pour d'autres usages, présente par erreur sur ce système, devient alors joignable de l'extérieur. Les comptes créés par ce biais échappent à l'authentification multifacteur et sont en lecture seule, mais ils ont accès aux données archivées.

Le 18 juin 2026, une équipe interne repère des comptes étrangers à DigiCert. Faute d'application rattachée à ces comptes, elle conclut qu'ils n'ont accès à aucune donnée. Le 21 juin, un signalement arrive par le programme de recherche en sécurité auquel l'entreprise participe. Un correctif d'autorisation part en production le 2 juillet. DigiCert indique qu'elle ignorait alors qu'une partie des archives avait déjà été consultée. Le soupçon naît le 12 octobre, la confirmation tombe le 19 : la fenêtre d'accès court du 27 juin au 2 juillet 2026.

Les données consultées sont surtout des coordonnées professionnelles : noms, adresses électroniques, numéros de téléphone et adresses. Pour une petite minorité de comptes, s'y ajoute un document fourni par le client, comme un permis de conduire, un passeport ou une facture. DigiCert affirme qu'aucun certificat n'a été émis, modifié ou révoqué, et n'a publié aucun chiffre de personnes concernées. Le 7 novembre, elle a indiqué avoir contacté les clients touchés et signalé l'incident aux forces de l'ordre.

Pourquoi c'est important

Le rapport isole trois facteurs : un changement d'accessibilité réseau sans revue de sécurité, une surveillance qui n'a pas été réévaluée après la migration, et un modèle d'autorisation qui confiait la protection des données à la position du système dans le réseau. DigiCert en tire elle-même la leçon : « Authorization for a business system must not be delegated to its network position ».

Le second enseignement est organisationnel. Selon DigiCert, l'incident a d'abord été traité comme un problème de création de comptes, et non comme un accès aux données. Pour une organisation soumise au RGPD, ce tri initial n'est pas un détail : le délai de 72 heures de l'article 33 court à partir du moment où le responsable du traitement prend connaissance de la violation, et toute violation doit être documentée, même sans notification. Le retour d'expérience du CERT-FR sur 196 exfiltrations montrait déjà des fuites obtenues souvent sans faille technique.

Le troisième tient à la sécurité du traitement. L'article 32 exige une procédure pour tester et évaluer régulièrement l'efficacité des mesures : un système déplacé sans revue en est la démonstration inverse.

Ce que ça change pour les organisations

  • Faire passer tout changement d'exposition réseau d'un outil interne (migration, nouvelle zone, nouveau nom d'hôte) par une validation sécurité, comme DigiCert l'impose désormais.
  • Vérifier que l'authentification multifacteur dépend du compte, pas de l'application à laquelle il est rattaché, et désactiver les fonctions d'inscription inutiles.
  • Réévaluer la surveillance à chaque migration : alertes sur la création de comptes inattendue et sur les volumes de requêtes.
  • Qualifier un événement de sécurité comme possible violation de données dès qu'un accès non prévu est constaté, puis le consigner dans le registre des violations.
  • Recenser où dorment les pièces d'identité collectées pour une vérification, et combien de temps elles y restent.

Pour la marche à suivre une fois l'incident constaté, notre guide violation de données : comment réagir détaille les étapes.

Ce que Leto en pense

DigiCert a fait un point utile : des journaux conservés lui ont permis de reconstituer la fenêtre d'accès et de prouver qu'aucune écriture n'avait eu lieu, et son rapport détaille treize actions correctives. L'incident se lit comme une leçon d'ISO/IEC 27001:2022 : les mesures 8.32 (gestion des changements), 8.22 (cloisonnement des réseaux), 8.16 (activités de surveillance) et 5.25 (appréciation des événements de sécurité) auraient pu fermer la porte plus tôt ou donner l'alerte avant l'accès. Leto tient déjà la partie RGPD de votre SMSI, registre, sous-traitants et questionnaires sécurité : voyons ensemble comment la relier à vos contrôles de sécurité.

Sources

Restez connecté(e).

Téléchargez notre application mobile de veille RGPD, Intelligence Artificielle et Cybersécurité. 
100% gratuite. 
Je télécharge

Discutons ensemble - et voyons comment Leto peut vous simplifier votre quotidien

Demander une démo