Cyberattaque d'un cabinet comptable : conséquences sur les données des clients

Cybermalveillance.gouv.fr décrit, dans sa fiche réflexe consacrée aux rançongiciels, un mode opératoire devenu courant : durant l'attaque, les cybercriminels cherchent souvent à détruire les sauvegardes de la victime, et à exfiltrer ses données pour la menacer de les rendre publiques. La même fiche donne les premiers gestes : couper les connexions à internet du réseau attaqué, déconnecter les machines touchées, alerter immédiatement le service ou le prestataire informatique, ne pas payer la rançon, et déposer plainte avant toute réinstallation.

L'incident Coaxis de décembre 2023, développé dans l'article sur la continuité, a illustré cette mécanique dans notre secteur : un hébergeur frappé par un rançongiciel, des cabinets privés plusieurs jours de leurs données et de leur messagerie, la confidentialité des données clients ayant été indiquée préservée par l'hébergeur. Mis bout à bout, ces éléments déplacent la question. Elle n'est pas « mon informatique est-elle sécurisée ? », formulation à laquelle personne ne peut répondre par oui sans mentir. Elle est plus concrète : quelles données resteraient accessibles après un incident, en combien de temps, et qui décide de la suite ?

Le sujet n'est donc pas tant l'outil que la préparation : savoir à l'avance ce qui resterait debout et qui fait quoi.

Ce qu'un cabinet concentre

Un cabinet d'expertise comptable n'héberge pas des documents interchangeables. Il concentre, en un seul endroit, les données de dizaines ou de centaines de clients : les comptes, les écritures, les liasses, les bulletins de paie, les pièces déposées, les données fiscales et sociales, parfois des informations personnelles sensibles. Tout cela vit dans votre logiciel de production, Cegid Loop, ACD, MyUnisoft, Sage ou Pennylane, dans la messagerie, sur le portail où vos clients déposent leurs pièces, et dans les sauvegardes.

Le secret professionnel de l'expert-comptable, prévu à l'article 21 de l'ordonnance du 19 septembre 1945 et sanctionné par l'article 226-13 du code pénal, ne s'arrête pas à la porte du serveur. En pratique, une donnée couverte par le secret sur un poste, dans une boîte mail ou sur une sauvegarde reste couverte par le secret. Un incident qui frappe ces données n'est donc pas seulement un problème technique, il touche l'obligation qui fonde votre relation avec vos clients.

Les risques concrets, nommés sans exagération

Une cyberattaque ne produit pas un seul dommage, mais plusieurs, qu'il vaut mieux distinguer pour savoir quoi surveiller.

• L'indisponibilité : vos dossiers, votre production comptable et votre messagerie deviennent inaccessibles, parfois au plus fort d'une campagne, comme l'a illustré l'incident Coaxis.
• La destruction des sauvegardes : Cybermalveillance rappelle que l'attaquant vise les sauvegardes qui lui sont accessibles. Une copie branchée en permanence sur le réseau est atteinte comme le reste.
• La divulgation : selon les cas, des données peuvent être copiées vers l'extérieur avant le chiffrement. Cette exfiltration n'est pas systématique, elle dépend de l'attaque, mais elle est possible, et c'est ce qui rend l'analyse a posteriori nécessaire.
• La perte de traçabilité : sans journaux fiables, vous ne pouvez pas établir ce qui a été touché ni ce qui a pu partir. Or c'est précisément cette information qui conditionne vos décisions et vos obligations.

Je ne vous dirai pas « vous êtes une cible ». C'est le genre d'affirmation absolue que je m'interdis. Ce que je constate, c'est un fait sourcé sur le mode opératoire, et un incident public réel. La bonne posture n'est pas la peur, c'est de savoir ce qui resterait debout.

La grille de vérification

Ces questions se posent à froid, avant tout incident. Leurs réponses valent mieux qu'un long audit.

• Une copie de vos données survivrait-elle à une attaque, parce qu'elle est réellement hors ligne et déconnectée du réseau ?
• Existe-t-il un document écrit qui dit qui isole, qui alerte, qui évalue ce qui a été touché, et qui communique ?
• Connaissez-vous le délai réaliste pour restaurer votre production comptable à partir d'une copie saine ?
• Le contact de votre prestataire informatique est-il joignable par un canal qui fonctionne encore si la messagerie est bloquée ?
• Disposez-vous de journaux permettant de contribuer à déterminer quels comptes, systèmes et fichiers ont été sollicités pendant l'incident ?
• La procédure de notification à la CNIL est-elle préparée côté cabinet, avec votre délégué à la protection des données le cas échéant ?
• Sauriez-vous dire quelles catégories de données clients ont pu être touchées si un poste était compromis ce soir ?

Si plusieurs réponses manquent, ce n'est pas un jugement. C'est simplement l'ordre des priorités qui apparaît.

Où s'arrête mon rôle, où commence le vôtre

C'est la limite la plus importante de cet article, et elle vous protège. Je mets en place les moyens techniques, et après un incident, je vous fournis les éléments factuels : ce qui s'est passé, quels systèmes ont été touchés, ce qui a pu être copié, dans quels délais. Cybermalveillance recommande d'isoler les systèmes atteints et d'alerter immédiatement le prestataire : c'est mon terrain, et je restaure depuis la copie isolée quand elle existe.

Ce qui reste le vôtre relève du métier et de la décision. Qualifier une violation de données, apprécier le risque pour les clients concernés, décider s'il faut notifier la CNIL et informer les clients, conduire la suite : cela relève du responsable de traitement concerné, conseillé par son délégué à la protection des données lorsqu'un DPO a été désigné. Selon la mission, le cabinet est responsable de traitement ou agit comme sous-traitant ; dans ce second cas, il alerte le responsable de traitement dans les meilleurs délais et lui transmet les éléments nécessaires. Lorsqu'une violation présente un risque pour les droits et libertés des personnes, elle doit être notifiée à la CNIL dans les meilleurs délais et, en principe, au plus tard dans les 72 heures suivant sa découverte. Toutes les violations doivent par ailleurs être documentées en interne. La communication aux personnes concernées, elle, n'est obligatoire qu'en cas de risque élevé pour leurs droits et libertés, sauf exceptions prévues par le règlement. Je vous donne la matière technique pour trancher, je ne tranche pas à votre place.

Ce qui change la sortie de crise

Deux choses techniques font, d'expérience, la différence entre un incident géré et un incident subi.

La première est la copie isolée. Une sauvegarde branchée en permanence sur le réseau est atteinte comme le reste, puisque le rançongiciel vise les sauvegardes accessibles. Une copie hors ligne, déconnectée, reste hors de portée : c'est elle qui permet de redémarrer sans dépendre de l'attaquant. Je détaille ce point dans l'article sur les sauvegardes réellement restaurables.

La seconde est le rôle écrit de chacun. Un incident se gère mieux quand quatre questions ont une réponse avant qu'il survienne : qui isole, qui alerte, qui évalue ce qui a été touché, qui communique. Ce document tient sur une page. Il évite les heures perdues à se demander qui appelle qui pendant que le chiffrement progresse.

Par où commencer

Commencez par préparer une fiche réflexe d'une page : je pose avec vous, noir sur blanc, qui isole, qui alerte, qui préserve les preuves et qui communique dans les premières heures, et je vérifie en parallèle qu'il existe une copie de vos données réellement hors ligne, testée. Vous ressortez avec un document que chacun peut suivre le jour venu, plutôt qu'une inquiétude vague : vous ne devenez pas invulnérable, mais vous passez d'un incident subi à un incident géré.