Comment sécuriser un mainframe qu’on n’ose plus toucher
Comment sécuriser un mainframe qu’on n’ose plus toucher
Section intitulée « Comment sécuriser un mainframe qu’on n’ose plus toucher »Un mainframe immobile n’est pas forcément stable : il peut surtout cacher des dépendances, des privilèges hérités et des mécanismes de reprise jamais vérifiés. Le compromis central est brutal : figer la plateforme préserve la disponibilité immédiate, mais augmente chaque année le coût, le risque et l’incertitude du prochain changement.
→ Lire l’explication complète de la marmotte
L’immobilisme z/OS crée une dette de sécurité
Section intitulée « L’immobilisme z/OS crée une dette de sécurité »Un environnement z/OS n’est pas dangereux parce qu’il est ancien. Il devient dangereux lorsqu’il sort du cycle normal de correction, d’inventaire et de tests de reprise. La conservation d’applications COBOL, de transactions historiques ou de terminaux 3270 n’est pas un défaut architectural en soi. L’absence de propriétaire, de documentation d’accès et de preuve de restauration l’est.
La recommandation est de ne pas lancer une modernisation générale avant de restaurer la capacité à changer. Remplacer une application critique sans inventaire des identités, des jeux de données, des interfaces et des dépendances de chiffrement transforme un risque connu en loterie coûteuse. Le bon premier chantier consiste à rendre chaque modification traçable, réversible et testable sur une partition logique distincte.
Une partition logique, ou LPAR (Logical Partition), isole matériellement des systèmes sur le même châssis. Une LPAR de test n’est utile que si ses données sont masquées, si ses certificats ne sont pas ceux de production et si ses interfaces sortantes sont filtrées. Copier une base de production complète dans un environnement moins surveillé est une exfiltration planifiée avec un budget projet. Le mainframe sait très bien faire cela, avec une régularité presque touchante.
Le socle d’autorisation repose généralement sur SAF (System Authorization Facility), une interface de contrôle, et sur RACF (Resource Access Control Facility), le produit de gestion des identités et droits le plus courant dans cet écosystème. Les contrôles doivent couvrir les identifiants humains, les comptes techniques, les tâches démarrées, les accès aux jeux de données, aux transactions et aux fonctions d’administration. Un identifiant partagé avec privilèges élevés retire toute possibilité d’attribution fiable, même si les journaux sont conservés pendant dix ans.
La première mesure est donc un inventaire des privilèges effectifs : utilisateurs avec attribut SPECIAL, OPERATIONS ou AUDITOR, groupes à droits universels, identifiants inactifs, tâches démarrées sans identité dédiée et profils avec accès universel. L’accès universel READ ou UPDATE sur une ressource métier sensible est rarement une nécessité technique. C’est souvent une exception devenue sédiment géologique.
Pour les principes d’identité et de fédération, les choix d’architecture doivent rester cohérents avec les mécanismes décrits dans la gestion des identités. Une fédération ne corrige pas des autorisations RACF trop larges. Elle ajoute un point d’entrée moderne à un modèle d’autorisation qui doit déjà tenir debout.
RACF, MFA et comptes techniques : le périmètre qui casse en premier
Section intitulée « RACF, MFA et comptes techniques : le périmètre qui casse en premier »L’authentification forte doit viser d’abord les accès d’administration : TSO, consoles, interfaces Web d’exploitation et accès distants. MFA (Multi-Factor Authentication), ou authentification à facteurs multiples, réduit le risque lié au vol de mot de passe, mais ne protège ni les sessions déjà ouvertes ni un compte de service compromis. Une révocation de certificat ou un retrait de groupe ne ferme pas magiquement les sessions établies : la durée de session, les jetons et les mécanismes de déconnexion doivent être définis séparément.
Les comptes techniques doivent être associés à une fonction précise, à une tâche démarrée précise et à un propriétaire identifié. Un compte générique utilisé par plusieurs batchs empêche de distinguer une erreur de traitement, une dérive de droit et une action malveillante. La règle est sèche : une identité technique ne doit recevoir que les profils nécessaires à son exécutable, ses jeux de données, ses files et ses appels réseau.
Les mots de passe stockés dans des membres de bibliothèques source, des paramètres de jobs ou des scripts d’administration restent un problème, même si le stockage principal est réputé inviolable. Le secret doit provenir d’un coffre dédié ou d’un mécanisme natif protégé, avec lecture limitée au processus qui l’utilise. Une rotation sans inventaire des consommateurs provoque une interruption. Une absence de rotation laisse un secret valide jusqu’à la prochaine fouille archéologique.
Les certificats Transport Layer Security, ou TLS, méritent le même traitement. Identifier les magasins de certificats, les chaînes de confiance, les dates d’expiration, les applications consommatrices et les autorités de certification acceptées. AT-TLS (Application Transparent Transport Layer Security) permet d’appliquer TLS au niveau réseau sans modifier certaines applications, mais il ne rend pas l’application authentifiée. Il chiffre un flux, il ne décide pas que son interlocuteur est autorisé à lire une transaction métier.
Les clés privées ne doivent pas sortir d’un HSM (Hardware Security Module), module matériel qui conserve les clés et réalise les opérations cryptographiques sans les exposer en mémoire applicative. ICSF (Integrated Cryptographic Service Facility) fournit sur z/OS les services d’accès aux fonctions cryptographiques. Le lien avec les modules cryptographiques matériels et PKCS#11 reste direct : le matériel protège l’extraction de clé, pas l’abus d’une opération de signature autorisée.
Surface d’attaque des interfaces mainframe
Section intitulée « Surface d’attaque des interfaces mainframe »Le terminal 3270 n’est pas une frontière de sécurité. Les interfaces exposées autour du mainframe le sont davantage : transfert de fichiers, passerelles Web, interfaces de programmation, administration distante, annuaire d’identités, impression, messagerie et outils de supervision. Une architecture qui surveille seulement le système central laisse les chemins latéraux faire le travail sale.
Les protocoles en clair doivent être supprimés ou encapsulés. Telnet, FTP non chiffré et authentification simple vers un annuaire exposent identifiants et données de session. Le chiffrement ne suffit pas lorsque le service accepte des comptes faibles ou des certificats clients non contrôlés. Les règles décrites pour désactiver LDAP simple bind en clair et anonymous bind s’appliquent aussi aux dépendances qui alimentent le mainframe : une identité compromise en amont reste une identité compromise.
La segmentation doit séparer les postes d’administration, les serveurs de rebond, les interfaces applicatives et les composants de stockage ou de sauvegarde. Un poste bureautique ne doit jamais atteindre directement les services d’administration z/OS. Un serveur de rebond durci, journalisé et réservé à cet usage réduit la surface d’exposition, à condition que ses comptes soient individuels et que les transferts de fichiers soient contrôlés.
Les attaques réalistes incluent le rejeu de sessions, le vol de secrets dans des jobs, l’abus d’un compte à privilèges, l’altération de bibliothèques de chargement et l’exfiltration par copie de jeux de données. Les contre-mesures sont connues : authentification forte, séparation des rôles, contrôle d’intégrité des bibliothèques, chiffrement en transit, revue des droits, journalisation centralisée et alertes sur les événements d’administration. Le vocabulaire change tous les trois ans, généralement après une conférence avec un logo fluorescent. Les mécanismes, eux, restent obstinément les mêmes.
Exemple RACF : créer un droit de changement isolé
Section intitulée « Exemple RACF : créer un droit de changement isolé »Toute modification de sécurité doit passer par une LPAR de test représentative, avec un plan de retour arrière et une validation par un identifiant non administrateur. L’exemple suivant crée un profil de test dans la classe FACILITY, accorde uniquement la lecture à un groupe d’opérateurs de changement, puis recharge la classe en mémoire.
/* TSO RACF : exécuter uniquement dans une LPAR de test */
/* Créer une ressource de contrôle sans accès universel */RDEFINE FACILITY TTCHG.TEST UACC(NONE)
/* Autoriser le groupe dédié, pas les comptes individuels partagés */PERMIT TTCHG.TEST CLASS(FACILITY) ID(TTCHGOP) ACCESS(READ)
/* Recharger les profils RACF déjà mis en cache */SETROPTS RACLIST(FACILITY) REFRESH
/* Vérifier le profil, ses permissions et l'absence d'accès universel */RLIST FACILITY TTCHG.TEST ALLLe groupe TTCHGOP doit être alimenté par un processus d’habilitation avec date de fin, propriétaire et revue périodique. Le profil doit ensuite être référencé par une procédure ou un composant qui vérifie réellement cette ressource. Créer un profil RACF sans point de contrôle applicatif revient à installer une serrure sur un dessin de porte.
Avant tout déploiement, exporter les définitions concernées, documenter la commande inverse et tester l’effet sur les tâches démarrées. Une modification de profil peut bloquer un batch critique au redémarrage suivant, pas forcément au moment de la commande. C’est le genre de détail qui transforme un vendredi calme en exercice de respiration.
Sauvegarde, journalisation et reprise mainframe
Section intitulée « Sauvegarde, journalisation et reprise mainframe »Les sauvegardes doivent couvrir les données, les bibliothèques de programmes, les définitions RACF, les configurations réseau, les certificats et les paramètres cryptographiques. Sauvegarder les données sans les profils de sécurité ne permet pas une reprise fidèle. Sauvegarder les profils sans les clés ou sans la procédure de récupération produit un système qui démarre mais ne traite plus ses échanges sécurisés.
SMF (System Management Facilities) enregistre les événements système et de sécurité. Les événements RACF, les changements de profils, les échecs d’authentification, les usages de privilèges et les événements réseau doivent être exportés vers une plateforme de corrélation indépendante. La rétention locale ne protège pas contre un administrateur compromis capable de modifier ou purger des journaux.
La supervision doit mesurer les échecs de connexions, les changements d’attributs privilégiés, les accès anormaux aux jeux de données, les expirations de certificats et les indisponibilités de services cryptographiques. Une alerte sans propriétaire ni procédure d’investigation n’est qu’un bruit numérique, très décoratif dans un tableau de bord.
La reprise doit être exercée avec des objectifs mesurables : délai maximal d’interruption, perte de données admissible, restauration des identités et validation des flux externes. Le mainframe garantit une disponibilité élevée lorsqu’il est conçu, opéré et testé pour cela. Il ne garantit pas qu’une sauvegarde est exploitable, qu’une clé est récupérable ou qu’une procédure écrite il y a huit ans correspond encore à la configuration actuelle. Pour structurer cette discipline, l’architecture cyber doit relier actifs, identités, flux, clés et scénarios de reprise, pas les traiter comme cinq projets décoratifs.
🐝 Ce qui arrive si on s’en passe
Section intitulée « 🐝 Ce qui arrive si on s’en passe »Sans inventaire des privilèges ni chantier de réversibilité, l’immobilisme se paie ailleurs que sur la disponibilité. Les départs, les réorganisations et les fins de contrat laissent des identifiants actifs que plus personne ne rattache à une fonction, et l’attribution d’une action devient impossible au moment précis où elle est demandée par un auditeur ou un juge. Les dépendances non cartographiées se révèlent lors d’une panne matérielle subie, pas lors d’un changement choisi : le délai de remise en service dépend alors de la mémoire de quelques personnes. Les compétences d’exploitation se raréfient sans transfert documenté, ce qui renchérit chaque intervention d’urgence. Enfin, un composant figé hors du cycle de correction accumule des vulnérabilités publiées dont l’exploitation ne demande plus de recherche, seulement un accès réseau mal segmenté.
🦫 Explication de la marmotte 🍫
Section intitulée « 🦫 Explication de la marmotte 🍫 »Un grand système informatique central traite souvent des opérations qui ne doivent pas s’arrêter : paiements, stocks, dossiers ou échanges entre applications. Son âge ne le rend pas automatiquement dangereux. Le danger apparaît quand personne ne sait précisément qui peut s’y connecter, quelles données chaque programme peut lire, quelles clés protègent les échanges et comment remettre le système en état après une panne.
La sécurité commence par recenser les comptes humains et les comptes utilisés par les programmes. Les droits doivent être limités : un programme de traitement ne doit pas pouvoir modifier des données qui ne lui servent pas. Les comptes d’administration doivent demander plusieurs preuves d’identité, car un mot de passe volé ne doit pas suffire.
Les échanges avec d’autres machines doivent être chiffrés et contrôlés. Chiffrer empêche surtout la lecture pendant le transport, mais ne remplace pas la vérification de l’identité de la machine qui se connecte. Les clés de chiffrement doivent rester dans un équipement conçu pour empêcher leur copie.
Chaque changement de droit doit être testé sur un environnement séparé, enregistré et réversible. En cas de panne ou d’attaque, il faut restaurer les données, les programmes, les règles d’accès et les clés dans le bon ordre. Si une seule de ces pièces manque, le système peut démarrer sans pouvoir travailler correctement.
À lire aussi
- Zero Trust pour les accès des prestatairesExiger et contrôler des accès Zero Trust pour les prestataires, des clauses contractuelles à la télémaintenance des environnements sensibles.
Pages voisines
La citent
Comment sécuriser un mainframe qu’on n’ose plus toucher
Elle cite