Une attaque informatique ne commence pas toujours par l’exploitation spectaculaire d’une faille inconnue. Parfois, le pirate emprunte simplement une porte normalement réservée à une personne autorisée. Les accès illégitimes subis par la DGFiP en juin et juillet 2026 illustrent cette difficulté : les intrusions ont été repérées et interrompues, mais l’extraction de données n’a pas été identifiée immédiatement. Face à une telle attaque, le pentest, l’audit de sécurité et le SOC interviennent à des étapes différentes et remplissent chacun une fonction bien précise. Leur efficacité dépend surtout de la façon dont ils se complètent.

L’attaque de la DGFiP révèle plusieurs niveaux de détection

D’après les éléments rendus publics, des identifiants appartenant à un agent et à un tiers habilité ont été usurpés. Les accès obtenus ont permis de consulter et d’extraire des informations relatives à 678 000 particuliers et professionnels, parmi lesquelles figuraient des données fiscales, des coordonnées et certains renseignements cadastraux. Les espaces personnels des contribuables n’ont pas été compromis. Le détail de la méthode employée pour détourner les comptes n’étant pas connu, toute affirmation plus précise sur le point d’entrée resterait hypothétique.

L’incident met surtout en lumière la différence entre la détection d’un accès suspect et celle d’un vol de données. Une entreprise peut donc repérer un compte compromis sans mesurer immédiatement tout ce qu’il a réalisé. Pour évaluer ses propres angles morts, elle peut contacter une entreprise de cybersécurité comme Basom Consulting, qui examinera à la fois les protections préventives, les droits accordés aux utilisateurs et les moyens de surveillance. Cette analyse ne se limite pas à la manière dont un pirate pourrait entrer dans le système. Elle vérifie aussi jusqu’où un compte compromis donne accès aux données et si une activité inhabituelle serait repérée assez rapidement.

Le pentest teste les chemins qu’un attaquant pourrait emprunter

Un pentest, ou test d’intrusion, consiste à confier à des spécialistes la recherche encadrée de moyens permettant de pénétrer dans le système d’information. Ces professionnels se placent dans une situation proche de celle d’un pirate, avec des règles et un périmètre définis à l’avance. Ils essaient notamment de contourner un portail d’accès, d’exploiter une mauvaise configuration ou d’obtenir davantage de privilèges que prévu. Ce travail peut révéler qu’un compte ordinaire ouvre indirectement la voie vers une application sensible ou une base de données mal protégée.

Dans un scénario proche de celui de la DGFiP, le test devrait dépasser la simple recherche de vulnérabilités sur un site internet. Un pentest réalisé avec un compte d’agent ou de prestataire permettrait d’étudier ce qu’une personne malveillante peut accomplir après une connexion réussie. Peut-elle interroger des milliers de dossiers, exporter des fichiers ou passer d’une application à l’autre sans nouveau contrôle ? Le pentest pourrait faire apparaître ces possibilités. En revanche, il ne surveille pas le réseau toute l’année : il fournit une photographie offensive à un moment donné, sur le périmètre réellement testé.

L’audit de sécurité repère les faiblesses moins visibles

L’audit de sécurité couvre un champ plus large que le pentest. Il peut porter sur :

• l’architecture informatique ;
• la configuration des équipements ;
• le code d’une application ;
• la gestion des accès ;
• l’organisation interne.

Concrètement, les auditeurs cherchent à savoir si les protections annoncées existent réellement, si elles sont correctement réglées et si les équipes les appliquent. Une politique de sécurité peut, par exemple, exiger la suppression rapide des anciens comptes, alors que plusieurs accès de prestataires restent actifs après la fin de leur mission.

Ce contrôle aurait aussi examiné la séparation entre les services, les applications et les bases de données. Lorsqu’un compte compromis donne accès à un ensemble trop vaste d’informations, le risque ne vient pas uniquement du vol de l’identifiant. Il tient également aux autorisations attachées à ce compte. Un audit des habilitations aurait pu signaler des droits trop étendus, des contrôles insuffisants avant un export ou l’absence de révision périodique des accès. Il aurait également vérifié la conservation des journaux techniques, indispensables pour retracer les consultations et déterminer quelles données ont quitté le système.

Le contrôle des identités doit continuer après la connexion

La double authentification ajoute une preuve au mot de passe, par exemple un code temporaire ou une validation sur un appareil. Elle réduit fortement le risque lié au vol d’un identifiant, sans le faire disparaître. Un faux site peut intercepter une validation en temps réel, une session déjà ouverte peut être détournée et un utilisateur peut approuver une demande trompeuse. C’est pourquoi l’accès ne devrait pas devenir automatiquement fiable dès que les deux étapes ont été franchies. La connexion ne représente que le début du contrôle.

Une protection plus fine tient compte du contexte. Un compte qui se connecte depuis un nouvel appareil, à un horaire inhabituel ou depuis une zone géographique incohérente mérite une vérification supplémentaire. Il en va de même lorsque son comportement change soudainement : recherches répétées, consultation rapide de nombreux dossiers ou téléchargement sans rapport avec ses missions habituelles. Des sessions plus courtes, une nouvelle authentification avant les opérations sensibles et des facteurs résistants à l’hameçonnage compliquent aussi la tâche du pirate. L’objectif consiste à ne jamais confondre identité présentée et confiance définitive.

Le SOC observe les comportements suspects en continu

Le SOC, pour centre opérationnel de sécurité, réunit des analystes, des procédures et des outils chargés de surveiller l’activité informatique. Il reçoit des alertes issues des postes de travail, des serveurs, des applications, des équipements réseau et des services d’authentification. Son intérêt apparaît surtout lorsqu’un attaquant utilise des identifiants valides. Une connexion isolée peut sembler normale. Plusieurs signaux rapprochés peuvent toutefois dessiner un scénario inquiétant, que l’équipe doit reconnaître assez tôt pour limiter les conséquences.

Lors d’une attaque comme celle de la DGFiP, un SOC correctement renseigné aurait pu rechercher des écarts entre l’usage attendu d’un compte et son activité réelle. Un agent consulte habituellement quelques dossiers liés à son service ; son compte en interroge soudain des milliers, avec une cadence inhabituelle. Ce type d’écart doit déclencher une alerte, une suspension temporaire ou une demande de confirmation. Encore faut-il définir les bonnes règles : accumuler des notifications sans priorité finit par masquer les événements véritablement dangereux.

La corrélation des journaux aide à reconnaître une extraction

Chaque composant du système conserve des traces, couramment appelées journaux ou logs. Elles indiquent qui s’est connecté, quelle ressource a été consultée, à quel moment et parfois quelle quantité de données a circulé. Pris séparément, ces éléments paraissent souvent anodins. Une plateforme de corrélation, généralement nommée SIEM, les rassemble afin de faire ressortir des enchaînements suspects. Une authentification inhabituelle, suivie de requêtes nombreuses puis d’un transfert volumineux, devient ainsi plus visible qu’une série d’événements dispersés entre plusieurs applications.

La qualité de ces traces compte davantage que leur simple existence. Si une application enregistre seulement la réussite d’une connexion, l’équipe ne peut pas savoir quels dossiers ont ensuite été ouverts ou exportés. Les journaux doivent donc couvrir les recherches, les téléchargements, les changements de droits et les volumes transmis. Une surveillance du réseau peut compléter cette vue en repérant des flux sortants inhabituels. Des solutions de prévention contre la fuite de données peuvent, quant à elles, bloquer ou signaler le départ d’informations sensibles, même si la personne à l’origine de l’action possède un compte reconnu.

Les habilitations et les quotas réduisent l’ampleur du vol

La détection ne doit pas compenser des droits d’accès excessifs. Le principe du moindre privilège consiste à n’accorder à chaque personne que les autorisations nécessaires à son travail. Il suppose aussi une révision régulière, car les fonctions évoluent, les prestataires changent et certains accès finissent par ne plus avoir de justification. Si un pirate compromet un compte limité, il atteint moins de données et rencontre davantage d’obstacles. Cette réduction du périmètre constitue déjà une protection, même lorsque l’alerte tarde à apparaître.

Des quotas peuvent également encadrer le nombre de dossiers consultés ou exportés sur une période donnée. Leur seuil doit correspondre aux réalités du métier afin de ne pas bloquer les équipes lors d’un pic légitime. Au-delà d’une certaine limite, le système peut ralentir la requête, exiger une validation ou prévenir le SOC. Les applications sensibles gagnent aussi à distinguer la consultation unitaire de l’extraction en masse. Une personne autorisée à vérifier un dossier n’a pas nécessairement besoin de télécharger une base complète. Cette nuance réduit directement les possibilités offertes par un compte usurpé.

L’affaire de la DGFiP rappelle qu’un accès reconnu par le système peut tout de même cacher une activité malveillante. Le véritable enjeu ne consiste donc pas uniquement à empêcher la connexion initiale. Il faut aussi limiter ce que chaque compte peut atteindre, reconnaître les comportements anormaux et conserver assez de traces pour comprendre rapidement l’incident. Le pentest et l’audit préparent le terrain ; le SOC maintient la vigilance au quotidien. Des quotas, des habilitations précises et des journaux exploitables réduisent encore le délai de réaction. La sécurité devient réellement plus solide lorsque ces mesures fonctionnent ensemble et font l’objet de vérifications régulières.