Fuite de données après un piratage de site : constater avant de parler
Un site piraté n'est pas automatiquement une fuite. L'absence de rançon n'est pas une preuve qu'on n'a rien lu. Avant de parler aux clients, à la presse ou à la CNIL, il faut un constat — pas une impression de gérant rassuré.
Un site piraté n'implique pas automatiquement une fuite. Inversement, l'absence de rançon n'implique pas qu'aucune donnée n'ait été lue. Il faut un constat.
Ce qu'on confond trop vite
Défiguration, redirection mobile, spam SEO, page d'accueil sale : le visiteur voit un incident. La base clients, elle, a pu rester hors d'atteinte — ou être lue sans aucun signe visible. Les deux erreurs symétriques sont « on a été piratés donc tout a fuité » et « on ne nous a rien demandé donc rien n'est sorti ».
Une rançon n'est pas un thermomètre. Beaucoup d'intrusions volent silencieusement. Beaucoup de défacements ne touchent qu'un fichier `index`. Le guide fuite de données pose le cadre ; ici, on détaille le constat avant la phrase publique.
Le prestataire de nettoyage décrit ce qu'il a vu. Il ne « décide » pas à votre place qu'il n'y a pas violation. Vous restez responsable de traitement.
- Piratage visible ≠ exfiltration prouvée.
- Pas de rançon ≠ pas de lecture.
- Pas de preuve de lecture ≠ preuve d'absence — d'où le constat.
Figer avant de réinstaller
Journaux d'accès, erreurs PHP, FTP, auth admin, copie du site et de la base, horodatage. Réinstaller « pour se rassurer » est le geste qui rend le volet données impossible. Stockez hors du serveur concerné. Voir journaux pour la justice.
Notez ce que les clients ont vu, les emails d'abus, Search Console. Une injection en base se lit parfois dans des comptes nés à 4 h, pas dans la home. Ne jugez pas à l'écran d'accueil.
Si une boutique est en jeu, isolez le tunnel de paiement dès qu'un skimmer est suspect. C'est une urgence métier distincte du communiqué.
Ce qui constitue une lecture de données
Accès avéré à une table clients ou utilisateurs, dump dans un dossier public, requête massive dans les logs SQL, formulaire qui exfiltrait les saisies, skimmer, export téléchargé, base extraite. Un mot de passe en clair lu aggrave : la notification devient quasi certaine.
Une injection SQL peut extraire sans rien afficher sur le site. Le fichier PHP intact ne rassure pas. Les options réécrites et les admins fantômes sont des signes d'écriture ; la lecture seule laisse moins de traces — d'où l'honnêteté du constat : « exfiltration visible » vs « accès plausible ».
Les boîtes transférées (règles) sont une fuite de correspondance, parfois plus grave qu'un défacement, distincte de la table boutique.
Ce qui n'en est généralement pas une
Un index.html remplacé, un spam SEO sans accès base démontré, une alerte Chrome pour une redirection, un minage CPU : ce n'est en général pas une violation de données personnelles — encore faut-il pouvoir l'écrire, avec les logs. « Généralement » n'est pas « jamais » : un même attaquant fait les deux.
Un compte admin CMS créé n'implique pas la lecture de tous les clients. C'est un accès. On documente le périmètre des tables touchées, pas l'émotion.
Des emails d'usurpation avec votre domaine et un SPF ouvert ne prouvent pas que votre fichier a été volé. Ils prouvent qu'on parle en votre nom. Croisez avec les RUA et les journaux d'envoi.
La fenêtre de temps, pas le sentiment
Le constat date : première anomalie, première connexion étrange, dernier log utile. Le délai CNIL de 72 heures part de la confirmation d'une violation à risque, pas de la première rumeur Facebook. Voir notification 72 h.
Une fenêtre floue (« ça fait peut-être trois mois ») se dit comme telle. Inventer une date précise pour rassurer est pire si l'inverse sort ensuite.
Les sauvegardes aident à borner : une copie propre d'avril vs une sale de juin. Encore faut-il les avoir hors serveur.
Qui a le droit de conclure
Le technicien décrit : tables, fichiers, logs, limites de ce qu'on peut savoir. Le responsable de traitement (vous) décide d'informer et de notifier. Un avocat peut cadrer. Un « cleaner » automatique ne produit pas ce document.
N'achetez pas une phrase toute faite « aucune donnée n'a été compromise » pour la page d'accueil. Si l'analyse n'est pas close, cette phrase se retourne. Voir communication de crise.
Le contenu du constat est une liste courte : périmètre, temps, nature, volume, lecture vs exfiltration visible. C'est ce qui circule ensuite, pas un email alarmiste à l'équipe.
Parler trop tôt, se taire trop longtemps
Trop tôt : démenti public, puis découverte d'un dump. Trop longtemps : 72 h dépassées alors que le risque était déjà clair. L'entre-deux est un constat en cours, une phrase interne factuelle, pas de roman sur les réseaux.
Si le risque pour les personnes est élevé (accès comptes, mots de passe faibles, paiement), l'information ne attend pas un communiqué parfait. Un email daté, sans jargon, suffit souvent.
La politique de confidentialité n'est pas le communiqué d'incident. Ne la réécrivez pas à chaud pour « cacher ».
Enchaîner nettoyage et volet données
Refermer l'entrée (backdoor, mots de passe, sessions) et documenter la fuite sont le même dossier, deux livrables. Traiter seulement le SEO laisse le RGPD en plan. Traiter seulement un courrier CNIL laisse la porte ouverte.
Si la table users a été lue, forcer les mots de passe fait partie de la remédiation, pas d'un « on verra pour ne pas déranger ».
Vous pouvez créer un espace pour le nettoyage. Le constat données s'y appuie ; la déclaration CNIL reste la vôtre.
- Copie et logs hors serveur.
- Périmètre écrit (même « incertain »).
- Pas de phrase publique tant que le périmètre n'existe pas.