Mainframes : pourquoi l’IA et les menaces internes imposent une nouvelle sécurité
Longtemps considérés comme des forteresses informatiques, les mainframes restent pourtant exposés aux erreurs humaines, aux accès trop étendus et aux attaques assistées par l’IA. À l’heure de NIS2 et de DORA, les entreprises doivent renforcer les identités, la surveillance et la sécurité de leurs fournisseurs.

Les mainframes n’ont pas disparu avec l’essor du cloud, des applications mobiles et de l’intelligence artificielle. Dans de nombreuses grandes organisations, ils continuent de faire tourner des opérations vitales : traitements bancaires, contrats d’assurance, données clients, facturation, logistique ou gestion administrative. Cette centralité fait leur force, mais aussi leur fragilité : une compromission, une erreur de manipulation ou une indisponibilité peut affecter une activité entière.
Leur réputation de systèmes robustes est fondée sur des caractéristiques réelles : architectures éprouvées, contrôle rigoureux des traitements, environnements historiquement spécialisés. Elle peut toutefois conduire à une forme de confiance excessive. Un mainframe n’est pas isolé du reste du système d’information par nature. Dès lors qu’il échange des données avec des applications, des terminaux, des réseaux ou des prestataires, il entre dans le périmètre des risques contemporains.
En 2024, la CNIL a enregistré 5 629 violations de données personnelles, soit une hausse de 20 % par rapport à l’année précédente. Ce chiffre ne décrit pas uniquement les environnements mainframe, mais il rappelle l’ampleur du défi auquel sont confrontées les organisations qui conservent et traitent des données sensibles. Pour ces infrastructures souvent anciennes, le sujet n’est pas de remplacer brutalement ce qui fonctionne. Il est de renouveler les protections autour des accès, des usages et des dépendances techniques.
Pourquoi les mainframes restent-ils une cible critique ?
Un mainframe désigne un ordinateur central conçu pour traiter de très grands volumes de transactions avec une forte disponibilité. Il ne faut pas le confondre avec un simple serveur ancien. Ces systèmes sont capables d’exécuter des applications métier utilisées depuis des décennies, parfois enrichies et interconnectées au fil du temps.
Cette longévité pose un défi particulier. Les règles d’accès, les comptes techniques, les droits d’administration ou les méthodes de connexion ont pu s’accumuler. Certains dispositifs ont été conçus à une époque où les utilisateurs étaient essentiellement internes, les réseaux moins ouverts et les campagnes de phishing bien moins sophistiquées. Or un attaquant n’a pas nécessairement besoin de briser les protections fondamentales du système : obtenir les identifiants d’un utilisateur légitime ou exploiter un accès mal configuré peut suffire à pénétrer l’environnement.
Les conséquences peuvent être lourdes, car ces plateformes concentrent fréquemment des processus qu’il est difficile d’interrompre. Une attaque peut viser le vol de données, mais aussi la fraude, la modification de transactions, l’arrêt d’un service ou l’extorsion. La résilience ne consiste donc pas seulement à empêcher l’intrusion. Elle suppose de détecter rapidement une activité inhabituelle, de comprendre ce qui s’est produit et de maintenir les opérations essentielles.
Les menaces internes ne se limitent pas à la malveillance
L’expression « menace interne » recouvre deux réalités. La première est intentionnelle : un salarié, un sous-traitant ou un ancien collaborateur abuse d’un accès pour consulter, extraire ou altérer des informations. La seconde, plus fréquente, relève de l’erreur ou de la manipulation : un employé clique sur un lien frauduleux, communique un code de connexion, réutilise un mot de passe ou valide une demande apparemment urgente.
Dans un environnement mainframe, ces scénarios exigent une attention particulière. Les comptes disposant de privilèges étendus peuvent accéder à des données ou à des fonctions très sensibles. Plus l’accès est large, plus les conséquences d’un identifiant compromis sont importantes. Accorder des droits par habitude, conserver des comptes inutilisés ou partager des identifiants pour simplifier une opération revient à réduire la capacité de l’entreprise à attribuer précisément les actions effectuées.
Le principe à appliquer est celui du moindre privilège. Chaque personne, application ou compte de service ne devrait disposer que des autorisations indispensables à sa mission, pour une durée adaptée. Cette approche doit être accompagnée de revues régulières : départ d’un collaborateur, changement de poste, fin de contrat avec un prestataire, évolution d’une application ou création d’un accès d’urgence sont autant de moments où les droits doivent être vérifiés.
| Risque lié aux accès | Exemple concret | Mesure de réduction du risque |
|---|---|---|
| Compte trop privilégié | Un utilisateur accède à des données qui ne relèvent pas de sa fonction | Limiter les autorisations au strict nécessaire |
| Identifiant volé | Un salarié transmet son mot de passe après un faux courriel d’assistance | Déployer l’authentification multifactorielle |
| Compte oublié | Un accès de prestataire reste actif après la fin d’une mission | Désactiver et réviser régulièrement les comptes |
| Action non attribuable | Plusieurs personnes utilisent le même identifiant | Mettre en place des comptes nominatifs et des journaux d’audit |
| Connexion inhabituelle | Un compte se connecte à un horaire ou depuis un contexte inattendu | Détecter les écarts grâce à la surveillance comportementale |
Comment l’intelligence artificielle change-t-elle les attaques ?
L’IA ne crée pas à elle seule de nouvelles failles dans un mainframe. En revanche, elle augmente l’efficacité de certaines méthodes déjà connues, en particulier l’ingénierie sociale. Des outils capables de produire rapidement des textes crédibles peuvent aider des cybercriminels à concevoir des courriels frauduleux mieux rédigés, plus personnalisés et adaptés au vocabulaire d’une entreprise ou d’un métier.
Le phishing hyper-personnalisé est particulièrement préoccupant. Un message peut sembler venir d’un responsable, d’un fournisseur ou d’un service informatique. Il peut évoquer un projet réel, une demande de validation ou un incident supposé urgent. Les techniques de deepfake et les contenus trompeurs générés à grande échelle renforcent aussi le risque de manipulation. L’objectif reste souvent le même : récupérer un secret de connexion, obtenir une validation ou amener une personne à contourner une procédure de sécurité.
Les bots alimentés par l’IA peuvent également accélérer la production de contenus frauduleux et l’automatisation de certaines interactions. Face à cela, la formation des équipes demeure utile, mais elle ne peut pas être l’unique rempart. Faire porter toute la sécurité sur la vigilance humaine est insuffisant, surtout dans un contexte de pression, d’urgence et de multiplication des messages.
La réponse doit associer des protections techniques et des procédures claires. L’authentification multifactorielle réduit l’impact d’un mot de passe dérobé. Des mécanismes de détection peuvent signaler une connexion dans un contexte anormal. Enfin, les salariés doivent disposer d’un canal simple pour signaler un message suspect et vérifier une demande inhabituelle, notamment lorsqu’elle concerne un accès sensible ou un transfert de données.
Moderniser les accès sans déstabiliser les applications critiques
La modernisation d’un environnement mainframe ne signifie pas nécessairement réécrire toutes ses applications. Elle consiste d’abord à mettre à niveau les contrôles qui entourent les usages. Les méthodes d’accès anciennes doivent être examinées avec soin, en particulier lorsqu’elles reposent sur des mots de passe seuls, des interfaces peu intégrées aux outils de sécurité modernes ou des connexions insuffisamment protégées.
L’authentification multifactorielle, souvent appelée MFA, constitue l’une des mesures les plus utiles. Elle ajoute une preuve d’identité, par exemple un code ou une validation, au mot de passe. Ainsi, la connaissance d’un secret volé ne suffit plus en principe à se connecter. Lorsqu’elles sont compatibles avec l’environnement concerné, des connexions sécurisées par VPN et l’utilisation de protocoles récents, tels que TLS 1.3, contribuent également à protéger les échanges.
La gestion des identités et des accès, ou IAM, fournit un cadre pour créer, modifier, suspendre et auditer les droits. Bien intégrée, elle relie les accès aux fonctions professionnelles réelles et laisse une trace exploitable lors d’un contrôle ou d’une enquête. Elle doit aussi couvrir les comptes non humains, notamment les comptes de service utilisés par des applications, qui sont parfois moins surveillés alors qu’ils peuvent posséder de nombreux privilèges.
Sécurité mainframe : des protections historiques aux contrôles adaptés aux menaces actuelles
Approche héritée
- Mot de passe seul pour accéder aux fonctions sensibles
- Droits étendus accordés durablement aux utilisateurs
- Contrôles ponctuels des comptes et des journaux
- Confiance implicite dans les accès internes
- Suivi limité des accès des prestataires
Approche modernisée
- Authentification multifactorielle pour les accès sensibles
- Principe du moindre privilège et revues régulières
- Surveillance continue des comportements anormaux
- Comptes nominatifs et traçabilité exploitable
- Exigences de sécurité suivies avec les fournisseurs
La surveillance comportementale, un complément indispensable
Même une politique d’accès rigoureuse ne garantit pas qu’aucun compte ne sera compromis. La surveillance continue apporte donc une seconde ligne de défense. Son principe est simple : observer les connexions et les actions, puis repérer les écarts significatifs par rapport aux habitudes d’un compte ou d’un groupe d’utilisateurs.
Une activité anormale peut prendre plusieurs formes : connexion depuis un contexte inhabituel, consultation soudaine d’un volume très important de données, utilisation de commandes rarement exécutées, tentative répétée d’accéder à une ressource refusée ou élévation de privilèges non prévue. Aucun de ces signaux ne prouve à lui seul une attaque. Leur intérêt réside dans leur corrélation et dans la capacité des équipes à enquêter assez tôt.
La journalisation est ici essentielle. Les journaux d’audit doivent permettre de savoir qui a accédé à quoi, quand et avec quels droits. Cette traçabilité aide à détecter un incident, mais elle sert aussi à répondre aux obligations réglementaires et à démontrer que les contrôles existent réellement. Une organisation doit prévoir qui analyse les alertes, dans quels délais et selon quelle procédure d’escalade. Un tableau de bord sans équipe ni processus pour agir ne produit pas de sécurité effective.
NIS2 et DORA : la conformité concerne aussi les environnements historiques
La cybersécurité est devenue un sujet de gouvernance. La directive européenne NIS2 renforce les exigences applicables aux organisations relevant de secteurs considérés comme essentiels ou importants. Les États membres devaient la transposer dans leur droit national avant le 17 octobre 2024. Parmi les attentes figurent la gestion des risques, la sécurité de la chaîne d’approvisionnement, la gestion des incidents et la responsabilité des dirigeants.
Les sanctions prévues par NIS2 peuvent atteindre 2 % du chiffre d’affaires annuel mondial pour certaines entités essentielles, selon les règles applicables. Ces montants rappellent que la conformité ne peut pas être traitée uniquement comme une formalité documentaire. Les mesures annoncées doivent être déployées, testées et capables de produire des preuves : inventaires, règles d’accès, journaux, exercices de réponse aux incidents et évaluation des prestataires.
Le règlement européen DORA, applicable depuis le 17 janvier 2025, concerne quant à lui la résilience opérationnelle numérique du secteur financier. Il impose aux entités concernées de mieux gérer les risques liés aux technologies de l’information et de la communication, de tester leur résilience et de surveiller leurs prestataires critiques. Pour une banque ou un assureur qui s’appuie sur un mainframe, le système historique ne peut donc pas être considéré comme un angle mort : il doit entrer dans la cartographie des risques et les dispositifs de continuité.
| Texte | Organisations concernées | Enjeu pour les mainframes |
|---|---|---|
| NIS2 | Entités des secteurs essentiels ou importants entrant dans son périmètre | Cartographier les risques, sécuriser les accès, gérer les incidents et les fournisseurs |
| DORA | Entités financières et prestataires relevant de son champ d’application | Démontrer la résilience opérationnelle numérique, y compris pour les systèmes historiques critiques |
La sécurité des fournisseurs doit être vérifiée tout au long du cycle de vie
Un mainframe s’inscrit rarement dans un écosystème fermé. Les entreprises font appel à des éditeurs, intégrateurs, sociétés de maintenance, consultants et fournisseurs de logiciels. Chacun peut apporter une expertise indispensable, mais aussi introduire une dépendance ou un nouveau point d’entrée. Une vulnérabilité dans un composant logiciel, une mise à jour insuffisamment contrôlée ou un accès distant mal encadré peut exposer des opérations critiques.
La collaboration avec les fournisseurs doit donc reposer sur des exigences vérifiables. L’entreprise a intérêt à évaluer les pratiques de sécurité du prestataire, les modalités de gestion des vulnérabilités, les conditions d’accès aux environnements, la protection du code et les procédures d’alerte en cas d’incident. Ces exigences ne doivent pas disparaître après la signature d’un contrat. Elles doivent être réévaluées pendant toute la durée de la relation.
Il est également important d’éviter de confondre responsabilité contractuelle et maîtrise effective du risque. Même lorsqu’un tiers exploite ou maintient une partie d’un environnement, l’organisation qui traite les données et fournit le service reste directement exposée aux conséquences d’une défaillance. La visibilité sur les accès des prestataires, sur les versions logicielles et sur les correctifs appliqués est donc un impératif opérationnel.
Ce qu’il faut surveiller pour renforcer durablement la résilience
La priorité n’est pas de céder à l’idée que tous les mainframes seraient vulnérables, ni de les remplacer aveuglément. Elle est d’identifier précisément les scénarios réalistes de compromission et de traiter les faiblesses les plus importantes. Les organisations peuvent commencer par établir une cartographie claire des applications, données, comptes privilégiés, interconnexions et prestataires associés à leurs environnements critiques.
Elles doivent ensuite tester leurs dispositifs. Une authentification multifactorielle configurée mais contournable, des journaux conservés mais jamais consultés ou un plan de réponse aux incidents jamais exercé procurent une sécurité illusoire. Les exercices permettent de vérifier la coordination entre les équipes métier, informatiques, juridiques et de sécurité, ainsi que la capacité à restaurer un service indispensable.
Enfin, l’essor de l’IA oblige à réviser les réflexes de confiance. Un courriel impeccable, une voix crédible ou une demande apparemment envoyée par un supérieur ne sont plus des garanties d’authenticité. Dans les infrastructures les plus sensibles, la protection durable repose sur une combinaison de contrôles techniques, de droits limités, de surveillance continue, de fournisseurs responsables et de procédures humaines solides. C’est à ce prix que les mainframes pourront continuer de jouer leur rôle de socle opérationnel dans un paysage de menaces en évolution constante.
Questions fréquentes
Qu’est-ce qu’un mainframe et pourquoi faut-il le sécuriser ?
Un mainframe est un ordinateur central conçu pour exécuter un très grand nombre de traitements et de transactions de façon fiable. Il est encore utilisé pour des activités critiques, notamment dans la banque, l’assurance ou la gestion de grands volumes de données. Sa sécurité est essentielle, car une compromission peut affecter des informations sensibles et des services indispensables.
Quelles menaces internes peuvent viser un mainframe ?
Une menace interne peut venir d’un acte malveillant, mais aussi d’une erreur humaine. Un salarié peut cliquer sur un lien de phishing, transmettre son identifiant ou disposer de droits trop larges. Un prestataire ou un ancien collaborateur dont le compte reste actif représente également un risque. Les accès nominatifs et la révision régulière des droits limitent ces expositions.
Comment l’IA rend-elle le phishing plus dangereux ?
L’intelligence artificielle peut aider des cybercriminels à générer rapidement des messages plus crédibles et adaptés à leur cible. Un courriel frauduleux peut imiter le vocabulaire d’un service, évoquer un dossier réel ou créer un sentiment d’urgence. L’IA facilite aussi la production de contenus trompeurs à grande échelle. La MFA et la vérification des demandes sensibles restent des protections clés.
Comment moderniser les accès à un mainframe sans remplacer toutes les applications ?
La modernisation peut commencer par les couches d’accès, sans réécriture immédiate des applications métier. Il s’agit notamment de déployer l’authentification multifactorielle, de sécuriser les connexions par VPN lorsque cela est pertinent, d’utiliser des protocoles tels que TLS 1.3 et de centraliser les droits dans une gestion des identités et des accès. Les changements doivent être testés pour préserver la continuité des opérations.
Quelles obligations NIS2 et DORA peuvent concerner les mainframes ?
NIS2 impose, pour les organisations entrant dans son périmètre, une gestion renforcée des risques cyber, des incidents et de la chaîne d’approvisionnement. DORA, applicable au secteur financier depuis le 17 janvier 2025, vise la résilience opérationnelle numérique. Dans les deux cas, un mainframe critique doit être intégré à la cartographie des risques, aux contrôles d’accès, aux exercices et aux procédures de réponse aux incidents.
Sources
Références consultées pour la rédaction de cet article. Les adresses sont indiquées à titre informatif et ne sont pas des liens.
- CNIL, rapport annuel 2024 et chiffres des violations de données personnelleswww.cnil.fr/fr/rapport-annuel-2024
- Directive européenne NIS2, texte officiel sur EUR-Lexeur-lex.europa.eu/eli/dir/2022/2555/oj
- Règlement européen DORA, texte officiel sur EUR-Lexeur-lex.europa.eu/eli/reg/2022/2554/oj
- ANSSI, ressources sur la cybersécurité des organisationscyber.gouv.fr



