Fuites de données publiques : l’État face à ses accès trop ouverts

Les fuites de données publiques révélées au mois d’août ont un point commun : elles ne semblent pas avoir reposé sur une prouesse technique exceptionnelle. Des identifiants attribués à des utilisateurs autorisés auraient été détournés pour pénétrer dans des systèmes administratifs, puis consulter et extraire des volumes importants de données.

Les informations concernées touchent plusieurs fonctions régaliennes. Une première intrusion a porté sur les données fiscales d’environ 350 000 particuliers, ainsi que sur des listes d’échanges avec l’administration. Une autre a concerné les données cadastrales de 433 485 particuliers au maximum et de 1 082 professionnels. Des données successorales ont ensuite été exposées, avant qu’un accès ne soit interrompu. Le groupe Zerobytes a également revendiqué une opération visant le ministère de l’Éducation nationale, avec un périmètre potentiellement plus large encore.

Ces fuites de données publiques déplacent le centre de gravité du débat. La question n’est pas uniquement de savoir si un serveur était correctement protégé. Elle consiste à déterminer ce qu’un compte compromis pouvait faire une fois admis dans le réseau, et pourquoi cette admission lui ouvrait des chemins vers d’autres ressources.

Fuites de données publiques : le risque vient aussi de l’intérieur

Le scénario décrit par les autorités françaises est celui d’une identité numérique d’agent compromise, utilisée depuis un accès distant légitime, probablement un réseau privé virtuel — ou VPN. L’attaquant n’avait donc pas nécessairement besoin de forcer une porte : il lui suffisait de se présenter avec des éléments d’authentification acceptés par le système.

L’authentification multifacteur constitue une protection importante, mais elle ne transforme pas un compte volé en compte sûr. Un mot de passe complété par un code temporaire, une validation sur téléphone ou une clé physique réduit le risque d’usurpation. Il ne règle pas, en revanche, la question des privilèges accordés à l’utilisateur après sa connexion. Si le second facteur est contourné, récupéré par ingénierie sociale ou validé à la suite d’une compromission préalable, la barrière perd une grande partie de son efficacité.

Le problème devient plus sérieux lorsque les droits d’accès excèdent les besoins réels de la fonction. Dans une grande administration, un agent peut être autorisé à consulter plusieurs applications pour des raisons opérationnelles. Des relations de confiance entre annuaires, plateformes et prestataires peuvent alors créer une continuité invisible entre des environnements qui paraissent séparés.

L’authentification fédérée facilite cette circulation. Elle évite aux agents de se reconnecter à chaque service, mais elle agrège aussi une partie du risque autour d’une même identité. Lorsqu’un compte fédérateur est compromis, l’attaquant ne gagne pas seulement l’accès à une application : il peut bénéficier d’un ensemble de permissions héritées ou reconnues automatiquement par d’autres systèmes.

Le « zéro confiance » ne se résume pas à un nouvel outil

Les architectures dites de zero trust, ou « zéro confiance », partent d’un principe inverse de celui qui a longtemps structuré les réseaux internes : être entré ne signifie pas être digne de confiance. Chaque demande d’accès doit être réévaluée selon l’identité, le terminal utilisé, la localisation, l’horaire, le comportement observé et la sensibilité de la ressource demandée.

Le zéro confiance ne supprime pas les identifiants volés. Il limite leur portée. Un compte utilisé depuis un lieu inhabituel, à une heure atypique ou pour télécharger un volume de fichiers sans rapport avec son activité peut être soumis à une vérification supplémentaire, bloqué ou isolé. La détection ne repose plus uniquement sur l’origine de la connexion, mais sur la cohérence de l’action.

Le cadre du National Institute of Standards and Technology sur le zero trust formalise cette approche : les décisions d’accès doivent être dynamiques, granulaires et fondées sur les ressources. Le modèle intéresse directement les administrations françaises, même s’il ne constitue pas une recette prête à déployer. Il impose de cartographier les données, les dépendances applicatives et les responsabilités de chaque compte.

Pour les fuites de données publiques, l’enjeu est précisément là. Il faut pouvoir distinguer une consultation ponctuelle d’un fichier fiscal, une extraction massive de données cadastrales et un déplacement latéral vers une autre base. Cette distinction exige des journaux d’activité exploitables, une conservation suffisante des traces et des équipes capables de les analyser en temps réel.

Un chantier d’architecture avant d’être un chantier logiciel

La difficulté française tient à l’échelle du système. Les administrations gèrent des centaines de milliers de comptes, des applications conçues à des périodes différentes et des échanges permanents avec des collectivités, des opérateurs, des éditeurs et des sous-traitants. Certains services sont récents, d’autres reposent sur des composants anciens qu’il est impossible de remplacer rapidement sans interrompre une mission publique.

Déployer le zéro confiance dans ce contexte suppose d’abord une hiérarchie des priorités. Les bases contenant des données d’identité, de revenus, de patrimoine ou de parcours scolaire ne peuvent pas être traitées comme des applications ordinaires. Elles doivent être séparées, y compris lorsqu’elles partagent un même hébergement ou un même fournisseur d’identité.

La segmentation doit aussi être opérationnelle. Séparer logiquement les réseaux ne suffit pas si les comptes conservent des droits transversaux, si les interfaces de programmation permettent de contourner les contrôles ou si les prestataires disposent d’accès permanents. Chaque permission devrait être limitée dans le temps, attribuée à une tâche précise et réexaminée régulièrement.

Cette transformation a un coût humain autant que technique. Elle demande des administrateurs capables de maintenir des politiques d’accès détaillées, des équipes de sécurité suffisamment nombreuses et des procédures d’urgence testées. Elle peut également ralentir certains usages : un agent devra parfois confirmer son identité ou demander une autorisation supplémentaire pour accéder à une donnée sensible.

Le choix public porte donc sur un arbitrage concret. La fluidité obtenue par une connexion unique et des droits larges réduit les coûts immédiats de gestion. En contrepartie, elle augmente le rayon d’action d’une identité compromise. À l’inverse, une politique de zéro confiance renforce le contrôle mais impose des investissements, une gouvernance commune et une discipline quotidienne.

Les fuites de données publiques rendent visible ce que les audits techniques signalent depuis des années : la frontière entre l’intérieur et l’extérieur d’un réseau n’est plus une protection suffisante. La sécurité des administrations dépend désormais de la capacité de l’État à savoir, à chaque instant, qui accède à quelle donnée, depuis quel dispositif et pour quelle raison. C’est cette traçabilité — plus que l’empilement de logiciels — qui déterminera la portée de la prochaine compromission.