Cyber : vols de données à l’Éducation nationale et à l’Enseignement catholique
Illustration : Flock
Alexandre Laurent
Le 24 mars à 08h55
Le secteur de l’éducation vient de faire l’objet de deux intrusions distinctes ayant permis un vol de données personnelles. Au sein du ministère de l’Éducation nationale, c’est le portail RH Compas qui a exposé les informations de quelque 243 000 agents et stagiaires. Le Secrétariat général de l’Enseignement catholique reconnait quant à lui une attaque ayant entraîné un accès non autorisé à des données administratives et personnelles de plus de 1,5 million d’élèves, familles et enseignants.
Cyber : vols de données à l’Éducation nationale et à l’Enseignement catholique
Illustration : Flock
Le secteur de l’éducation vient de faire l’objet de deux intrusions distinctes ayant permis un vol de données personnelles. Au sein du ministère de l’Éducation nationale, c’est le portail RH Compas qui a exposé les informations de quelque 243 000 agents et stagiaires. Le Secrétariat général de l’Enseignement catholique reconnait quant à lui une attaque ayant entraîné un accès non autorisé à des données administratives et personnelles de plus de 1,5 million d’élèves, familles et enseignants.
Sécurité
Sécurité
4 min
Après les fédérations sportives, place au monde de l’éducation ? Deux incidents de sécurité impliquant une extraction de données personnelles ont été signalés dans le secteur.
243 000 comptes d’agents et de stagiaires exposés
Le plus récent concerne le ministère de l’Éducation nationale, qui a confirmé, mardi matin, avoir été alerté d’un accès frauduleux à la base de données alimentant le système COMPAS, dédié à la gestion des stagiaires des premier et second degrés. « L’accès frauduleux aurait été réalisé le 15 mars 2026 à la suite de l’usurpation d’un compte externe », indique le ministère :
« Les premières investigations indiquent qu’un volume de données concernant environ 243 000 agents, stagiaires ou titulaires, a été exfiltré. Elles concernent des éléments d’identité, des coordonnées (adresse et numéro de téléphone), des périodes d’absence (sans information de santé), ainsi que l’identité et les numéros de téléphone professionnels des tuteurs. »
Le Centre opérationnel de sécurité des systèmes d’information du ministère aurait alerté de cet incident le 19 mars au soir, vraisemblablement suite à la publication d’une annonce présentant un échantillon de ces données sur un forum dédié.
« Dès la détection de l’incident, une cellule de crise a été activée. L’accès externe au système concerné a été suspendu et des vérifications sont en cours sur l’ensemble des systèmes d’information du ministère afin de prévenir tout risque de propagation », promet le ministère. Le système d’information COMPAS était effectivement inaccessible mardi matin d’après nos constatations.
L’Éducation nationale appelle dans ce contexte l’ensemble de ses agents à faire preuve d’une attention particulière face aux tentatives de fraude.
L’enseignement catholique lui aussi visé, élèves et familles exposés
Quelques jours plus tôt, c’est le Secrétariat général de l’Enseignement catholique qui a tenu une communication du même acabit. Dans un communiqué daté du 21 mars (PDF), l’association a indiqué avoir subi « une attaque informatique ciblant l’application de gestion de ses établissements du premier degré ». Cette fois, l’hémorragie ne se limite pas aux personnels encadrants : « l’attaque a entraîné un accès non autorisé aux données relatives à l’identification des utilisateurs de cette application et aux coordonnées des élèves, de leurs familles et des enseignants ».
L’Enseignement catholique affirme avoir dûment sécurisé ses systèmes et répondu à ses obligations légales de signalement.
« Parallèlement, une communication proactive a été établie avec l’ensemble des chefs d’établissement, des enseignants et des parents d’élèves concernés pour les informer des mesures mises en place pour assurer la sécurisation des systèmes et transmettre des recommandations de vigilance, notamment relatives à la modification des accès et à l’usage de mots de passe complexes. »
Un message d’information a également été envoyé aux parents d’élève (PDF). Dans sa communication, l’association ne précise pas le périmètre exposé, mais celui-ci serait significatif : la fuite toucherait ainsi « 1,5 million de personnes, soit les 800 000 élèves du premier degré (écoles maternelles et élémentaires, ndlr), leurs familles, et 40 000 professeurs » d’après Stéphane Gouraud, secrétaire général adjoint de l’Enseignement catholique, cité par l’AFP.
L’association promet par ailleurs s’être entourée d’experts pour « limiter les conséquences potentielles de cet incident ». La combinaison d’informations personnelles liées aux familles, aux enfants et aux conditions d’accueil scolaire crée en effet un cocktail particulièrement efficace en matière d’ingénierie sociale…
Commentaires (17)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousLe 24 mars à 09h58
Je vais finir par faire une page dédiée avec toutes mes données personnelles en clair, ça sera plus simple pour tout le monde...
Le 24 mars à 10h30
Le 24 mars à 11h46
Le 24 mars à 20h38
Le 24 mars à 11h53
L'école associative de mes n'enfants utilise aussi un prestataire (y a pas vraiment le choix) pour le soft de gestion administrative (gestion, paie, base élèves, etc...) et c'est pas comme si y avait 42 fournisseurs de ce genre pour les établissements scolaires privés sous contrat.
Le 24 mars à 12h11
Le 24 mars à 17h19
Le 25 mars à 09h00
A priori développé par une agence (NetSTIM) pour le compte de l'enseignement catholique
Le 24 mars à 12h55
Le 24 mars à 17h46
En gros, il faudrait faire des statisques de nombre de requetes par IP ou par login, sur la durée. Mais est-ce que les libs d'accès aux base de données permettent toute de le faire? quel base on met en place pour maintenir ces seuils? comment on intègre ca suffisament bas niveau ou au niveau de la bdd pour ne pas qu'un attaquant sur le front ne bypass ces règles? comment on fait arriver au niveau de la BDD l'ip et le login de l'appelant? bref... c'est compliqué.
Modifié le 24 mars à 20h48
Beaucoup de choses peuvent se faire et certaines assez simplement:
Dès lors que le login à la base de données se fait via les identifiants utilisateurs et non par un compte de middleware, aucun secret n'est stocké sur le serveur du middleware et pas mal de vérifications peuvent être envisagées directement dans la base.
Il reste aussi la possibilité de mettre en place un 2FA, ce qui devrait en fait être obligatoire, à minima pour tous ceux qui ont des comptes privilégiés.
Enfin, il est possible de journaliser les adresse IPv4 ou les préfixes IPv6 utilisés pour la connexion, via le middleware et restreindre les pays et ASN autorisés via un pare-feux.
Le 25 mars à 08h52
Dans la vraie vie de notre asso:
Le 25 mars à 08h53
Bon on spécule mais si ça se trouve le logiciel avait les gardes fous, volontairement désactivé par un humain, on en voit des vertes et des pas mûres :
Le 25 mars à 08h54
@ForceRouge Oui, c'est compliqué. Mais moins que d'aller récupérer la donnée quand elle a été volée
Cela implique en effet de former ses utilisateurs à accepter certaines contraintes (autorisation par un administrateur d'une action large).
Modifié le 25 mars à 09h30
Contre l'extraction de donnée massif, ça doit se passer au niveau de la base de donnée. Car t'as beau mettre toutes les sécurités que tu veux sur le processing en amont, s'il est troué et que l'attaquant peut faire les requêtes qu'il veut en base, c'est perdu. Maintenant, comment tu ramènes de façon certaine l'IP de la connexion TCP du client sur le load balancer en entrée, au niveau de la base de donnée? Tu peux remplacer toutes tes requêtes par des procédures stockées limitantes (bonjour la charge de travail), mais comment tu fait faire des statistiques sur le nombre de ligne renvoyé au global sur la seconde? la minute? l'heure? la journée? comment tu définis les patterns normal et anormal? La on parle de 200000 comptes. Si des requetes sur 1000 compte sont "normales" sur une journée (ex: de la facturation), bah tu vas mettre une limite à 2000 pour ne pas atteindre cette limite, bon bah 10j suffit pour tout dumper.
Tu te protèges comment d'un vol de donnée de l'intérieur d'un salarié malintentionné?
Si je prends le domaine du paiement en Europe, que je connais un peu, on n'a jamais (à ma connaissance, sinon très rarement) de vol de donnée bancaire critique (numéro de CB, crypto, date d'expiration, code PIN, etc...). Pourquoi? parce que ce secteur est soumis à des normes ultra strict de sécurisation des données, et de "séparation des pouvoir" pour que même quelqu'un de malintentionné en interne ne puisse pas tout dumper.
Dans ce domaine, le champ Nom/Prénom n'est pas sécurisé de la même façon que le numéro de CB, qui est sécurisé encore d'une autre façon que le PIN.
Entrer dans ce niveau de détail, avec tout le matériel de chiffrement, ainsi que les procédures d'accès et de modification de ce matériel, etc... (je simplifie énormément) ca nécessite une quantité de temps et d'argent dont tu n'as probablement pas idée.
Est-ce qu'on a les moyens de sécuriser 200.000 comptes des stagiaires de l'éducation national qui n'ont quasiment aucune valeur (nom, prénom, age, relevé d'absence...) comme on sécurise un paiement? pas sure.
Le 26 mars à 08h38
Concernant la partie IP dont j'ai parlé, c'est le travail d'un bastion de filtrer les accès externes par ASN et pays. Cela permet par exemple de bloquer ce qui ne vient pas de France et ce qui arrive d'un VPN qui aurait francisé un accès, si tu considère que l'outil ne doit pas être accédé hors de France.
En interne, pour éviter l'écoute sur le réseau, il est possible d'imposer la connexion chiffrée entre les clients (serveur web ou client lourd), et la base de données. Avec Mysql et Mariadb, c'est certain et je pense que cela est possible également avec Postgre SQL, Oracle et MS sqlserver.
Toujours sur la base de données, pour les sauvegardes et les réparations des données, un accès non root à l'OS et à la base est à privilégier : un utilisateur n'ayant pas les droits root sur le serveur et pas les droits root sur le serveur de base de données. Uniquement un accès total ou presque, à la base. Cet accès doit être limité à certaines adresses IP, en bloquant localhost pour cet utilisateur spécial si l'administration de la base se fait depuis une autre machine locale.
Il est toujours possible de créer un utilisateur spécial pour les sauvegardes, un utilisateur qui soit le seul à avoir le droit de faire un dump ou une restauration de la base, mais qui n'ait que les droits strictement nécessaires pour ce travail.
Concernant les accès, à l'outil, avant la base de données, il y a des moyens d'agir:
Et on en revient toujours au 2FA pour tous les accès privilégiés au frontend de l'outil. Le 2FA peut n'être mis en place que pour une population donnée. C'est ce que je fait par exemple avec Nextcloud.
Et je ne parle pas là de tout ce qui peut être fait dans la conception de l'outil et du modèle de données pour, par exemple, limiter les accès d'un utilisateur aux données qui le concernent. Exemple: la limitation géographique des accès d'un conseiller pôle emplois aux candidats de son agence ou de son bassin d'emplois.
Il y a déjà le cloisonnement des accès et c'est pratiqué dans beaucoup d'entreprises. Les salariés n'accèdent qu'aux données dont ils ont besoin. Et cela peut varier dans le temps quand il s'agit de données projet.
Au niveau comptabilité:
Si les données sont stockées chiffrées, un administrateur système peut faire ses sauvegardes et restaurations sans pouvoir y accéder. Il est aussi possible de chiffrer la sortie d'un dump sql.
Globalement, avec un salarié mal intentionné comme avec un pirate, on ne peut que limiter la casse en cas d'attaque.
Beaucoup de problèmes de ces outils sont liés à leur défauts de conception. Sans même chercher à atteindre les niveaux de sécurité du monde bancaire, il y a largement de quoi faire mieux.
Comme cela a déjà été dit, le simple fait de purger les données trop anciennes ou les mettre en archives froides pendant le temps légal de conservation aurait permis de limiter l'impact de l'attaque.
Une simple politique d'archivage. C'est si compliqué à mettre en place ?
Le 24 mars à 18h03
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?