Introduction au mainframe
Les mainframes jouent un rôle central dans les opérations quotidiennes des plus grandes entreprises du monde. Ils dominent le paysage informatique des grandes entreprises dans les secteurs de la banque, de la finance, des soins de santé, des assurances, des services publics, du gouvernement et d’une multitude d’autres entreprises publiques et privées. Le sujet abordé dans cet article sera celui d’améliorer son niveau de cybersécurité afin de répondre au mieux aux exigences de la LPM.
Facteurs contribuant à l’utilisation des mainframes
Les raisons de l’utilisation des mainframes sont nombreuses, mais la plupart d’entre elles relèvent de l’une des catégories suivantes.
- RAS (Reliability, Availability, and Serviceability. En français : fiabilité, disponibilité et maintenabilité) : La conception des mainframes priorise la continuité du service. Le système intègre des fonctionnalités de prévention et de détection des erreurs. Il peut se remettre d’une défaillance de composant sans affecter le reste du système en fonctionnement et identifier la cause de la défaillance.
- Sécurité : Le mainframe offre un système sécurisé pour traiter un grand nombre d’applications hétérogènes pouvant accéder à des données critiques. Il garantit une protection inégalée en matière d’isolation des charges de travail, de protection des données et de communications sécurisées.
- Scalabilité : Un mainframe peut exécuter plusieurs copies du logiciel du système d’exploitation en tant qu’entité unique.
- Compatibilité continue : Le mainframe héberge des applications anciennes, qu’elles aient évolué ou non au fil des années, ainsi que des applications développées plus récemment. Il offre une compatibilité optimale à travers des décennies de changements et d’améliorations. En cas d’incompatibilité, les concepteurs préviennent généralement les utilisateurs au moins un an à l’avance pour leur permettre d’apporter les modifications nécessaires.
- Architecture en évolution : Depuis plus de quatre décennies, le mainframe est à la pointe de la technologie dans la gestion des données et des transactions. Chaque nouvelle génération combine les caractéristiques des mainframes passés avec de nouvelles fonctionnalités conçues autour du RAS.
- Extensibilité : La conception des mainframes se distingue par la réutilisation de leurs composants et de leur infrastructure (Architecture share-everything).
- Réduction du coût total de possession.
- Respect de l’environnement : Un nombre plus réduit de serveurs physiques fonctionnant à un niveau énergétique quasi constant peut héberger plusieurs serveurs virtuels. Cette configuration permet à une entreprise d’optimiser l’utilisation des ressources matérielles et de rationaliser l’infrastructure des serveurs physiques, en regroupant ces derniers sur un nombre réduit de serveurs hautes performances.
Systèmes matériels et haute disponibilité
Pour aborder le sujet du matériel utilisé par les mainframes, nous prendrons comme exemple les systèmes mainframes de la génération Z16, qui offrent :
- Une grande capacité de calcul (jusqu’à 200 processeurs1), garantissant un traitement rapide des tâches et la gestion de calculs complexes.
- Une capacité mémoire élevée (jusqu’à 40 To), permettant le stockage et la récupération rapide de vastes quantités de données.
- Une mémoire cache optimisant les performances.
- Une capacité de compression des données facilitant le stockage et la transmission efficace des données en réduisant leur taille.
- Des fonctionnalités de chiffrement pour sécuriser les transactions, offrant des mesures de sécurité robustes pour protéger les informations sensibles.
Malgré les évolutions constantes, les ordinateurs mainframes restent les plus stables, sécurisés et compatibles. Depuis le modèle client-serveur des années 1990 jusqu’à l’augmentation significative de la scalabilité, des performances et de la capacité que l’on connait aujourd’hui, les mainframes ont toujours su évoluer pour relever de nouveaux défis.
Évolution du mainframe et de ses composants
Les mainframes de la génération Z/16 sont des serveurs multiprocesseurs. Chaque processeur dispose d’une petite zone de mémoire privée qui lui est propre, appelée Prefix Storage Area (PSA). Un processeur peut accéder à la PSA d’un autre processeur via une programmation spécifique, bien que cela soit généralement réservé aux opérations de récupération en cas d’erreur.
Les disques des mainframes sont accessibles par le biais d’une unité de contrôle dédiée (Control Unit), pouvant intégrer jusqu’à quatre connexions fibre optique reliées à un ou plusieurs processeurs via un commutateur.
Contrôle du système et partitionnement
Il existe de nombreuses façons d’illustrer la structure interne d’un mainframe. Le schéma ci-dessous illustre plusieurs fonctions internes des mainframes. Les contrôleurs internes sont des microprocesseurs, mais ils sont généralement appelés contrôleurs pour éviter toute confusion avec les processeurs des mainframes.
Contrôle du système et partitionnement
Le mainframe peut être divisé en partitions logiques distinctes (Logical Partitions ou LPARs), où les ressources système (mémoire, processeurs et périphériques d’Entrée/Sortie) peuvent être réparties ou partagées entre elles sous le contrôle de l’hyperviseur LPAR (hyperviseur de type 1 / natif). Cet hyperviseur est fourni avec la fonctionnalité standard Processor Resource/Systems Manager (PR/SM) sur tous les mainframes.
Chaque LPAR prend en charge un système d’exploitation (OS) indépendant, chargé par une opération de démarrage initiale distincte (Initial Program Load ou IPL), et possède sa propre copie (bien que la plupart des bibliothèques système z/OS puissent être partagées).
Les machines actuelles peuvent être configurées avec jusqu’à 60 LPARs, chacune étant considérée comme un serveur distinct avec des environnements OS différents. L’administrateur système peut attribuer un ou plusieurs processeurs système à l’usage exclusif d’une LPAR via des fonctions de contrôle système (firmware).
Partition logique
Clustering
La plupart des installations z/OS utilisent aujourd’hui une ou plusieurs des techniques de clustering (partitionnement des données) suivantes :
- Basic Shared DASD (Direct Access Storage Devices) :
Un système Basic Shared DASD est généralement utilisé lorsque l’équipe d’exploitation contrôle quel job est affecté à quel système et veille à éviter les conflits, comme deux systèmes tentant de mettre à jour les mêmes données en même temps. Malgré cette limitation, un environnement Basic Shared DASD est utile pour les tests, la reconstruction et un équilibrage de charge précis.
Basic shared DASD3
- Fonctionnement en anneaux CTC :
Les anneaux CTC fonctionnent comme un périphérique d’entrée/sortie simulé, permettant à un programme de contrôle système (System Control Program ou SCP) de communiquer avec un autre SCP. Ils fournissent le chemin de transfert de données et la synchronisation nécessaire pour ce transfert.
z/OS peut utiliser l’anneau CTC pour transmettre des informations de contrôle entre tous les systèmes connectés à l’anneau. Ces informations peuvent inclure des données d’utilisation et de verrouillage pour les ensembles de données sur les disques, des informations sur les files d’attente des tâches, des contrôles de sécurité et des métadonnées des disques.
Basic sysplex3
L’aspect en anneau devient plus évident lorsque plus de deux systèmes sont impliqués.
- Parallel Sysplex:
Un système Sysplex est composé d’une ou plusieurs (jusqu’à 32 LPARs) images z/OS regroupées en une unité coopérative unique à l’aide de matériel et de logiciels spécialisés. Il utilise des services de messagerie uniques et peut partager des structures de fichiers spéciales contenues dans des ensembles de données de la Couple Facility (CF).
La Couple Facility (CF) est une partition logique qui fournit des fonctions de mise en cache à haute vitesse, de traitement de listes et de verrouillage pour le sysplex. Elle contient un ou plusieurs processeurs mainframe et un système d’exploitation intégré.
Un Parallel Sysplex est un sysplex symétrique utilisant une technologie de partage de données multi-systèmes. Il s’agit de la technologie de clustering des mainframes. Cette approche permet un accès simultané, direct en lecture/écriture aux données partagées par tous les serveurs de traitement dans la configuration, sans compromettre les performances ou l’intégrité des données. Chaque LPAR peut simultanément mettre en cache des données partagées dans la mémoire du processeur CF grâce à une assistance matérielle et à des contrôles de sérialisation et de cohérence à l’échelle du cluster.
Cette technique permet aux requêtes associées à une seule charge de travail de :
- Être équilibrées dynamiquement entre les systèmes tout en maintenant des performances élevées.
- Améliorer la disponibilité.
- Permettre une maintenance continue des systèmes et des applications.
- Offrir une charge de travail scalable.
- Considérer les environnements multi-systèmes comme une route logique unique.
- Synchroniser les horloges TOD (Time Of Day clock service) sur plusieurs serveurs, permettant ainsi de séquencer correctement dans le temps les événements se produisant sur différents serveurs.
Parallel Sysplex3
Sécurité du Mainframe
Les systèmes de sécurité des mainframe Z (contrôle d’accès, authentification, listes de contrôle d’accès…) sont centralisés dans un service unique appelé SAF (System Authorization Facility).
SAF ne nécessite aucun autre produit de sécurité, mais il est généralement complété par d’autres produits de sécurité appelés ESM (External Security Manager), tels que TSS et RACF.
- RACF :
RACF (Resource Access Control Facility) fait partie d’une offre globale d’IBM nommée z/OS Security Server, qui inclut un serveur LDAP, une technologie de pare-feu z/OS, un composant de mappage d’identités d’entreprise (Enterprise Identity Mapping), RACF, etc.
RACF fournit des fonctionnalités de contrôle d’accès discrétionnaire (DAC) et de contrôle d’accès basé sur les rôles (RBAC).
- TSS :
Le SAF (System Authorization Facility) du mainframe z/OS peut déléguer toutes les tâches de sécurité à Broadcom TSS (Top Secret Services).
TSS est un External Security Manager (ESM) développé par Broadcom. Il gère l’identification, l’authentification et le contrôle d’accès pour les ressources z/OS telles que les ensembles de données, les piles TCP/IP et les programmes.
Chaque processus a un propriétaire (UserID) qui, par défaut, n’a aucune autorisation. Un officier de sécurité TSS doit accorder les accès nécessaires aux ressources. L’isolation des applications est obtenue grâce à une gestion rigoureuse des autorisations accordées aux différentes ressources. De plus, un filtrage de pare-feu peut être appliqué au trafic entrant et sortant du mainframe.
Conformité des mainframes à la LPM
Qu’est-ce que la LPM ?
La LPM (Loi de Programmation Militaire) est un plan stratégique de défense français visant à assurer la sécurité des opérateurs d’importance vitale, des entreprises ou des organisations pour lesquelles l’interruption d’une ou plusieurs de leurs missions vitales aurait un impact sur la sécurité nationale.
Elle concerne la protection des Systèmes d’Information d’Importance Vitale (SIIV), sur lesquels reposent ces missions vitales, ainsi que des Points d’Importance Vitale (PIV), lieux abritant des systèmes d’information sensibles.
La LPM est relativement proche de la directive NIS (Network and Information Security) en ce qui concerne les exigences de sécurité applicables aux SIIV, mais elle intègre de nouvelles notions et obligations qui la rendent plus contraignante.
Pourquoi le mainframe est-il soumis à la LPM ?
Le mainframe z/OS (MFRz) joue un rôle clé dans l’activité bancaire pour plusieurs raisons :
- Sa capacité à gérer de grands volumes de transactions et de calculs.
- Sa modularité au sein d’un système centralisé.
- La scalabilité et l’ouverture du système.
- Des coûts attractifs.
Comment effectuer une segmentation dans le mainframe ?
Pour garantir l’isolation des ressources à l’intérieur du mainframe, trois scénarios possibles peuvent être identifiés : isolation complète, LPAR dédiée et isolation réseau.
Les scénarios suivants ne permettent cependant pas de réaliser une micro-segmentation entre les ressources situées dans le même VLAN ou partageant la même pile TCP/IP.
Isolation complète
Une instance de mainframe dédiée est réservée aux ressources SIIV. Toutes les communications avec des ressources externes sont filtrées par le pare-feu du mainframe. Cependant, cette solution entraîne un coût matériel élevé ainsi qu’un risque opérationnel important. Les ressources SIIV doivent toutes être migrées vers cette nouvelle instance de mainframe, et la mise en place de ce nouvel environnement nécessite des ressources humaines.
Exemple d’isolation complète
LPAR dédiée
Dans ce scénario d’isolation, une LPAR est dédiée aux ressources SIIV. Comme expliqué dans le chapitre « Contrôle du système et partitionnement », un mainframe peut être partitionné en PARtitions Logiques séparées (LPARs), où les ressources système sont allouées, et chaque LPAR prend en charge un système d’exploitation (OS) indépendant.
Exemples d’isolation LPAR
Isoler tous les SIIV dans une seule LPAR n’est pas faisable, car chaque ressource fonctionne sur un système d’exploitation différent (Linux, z/OS, etc.).
Une LPAR dédiée par système d’exploitation de SIIV peut être mise en place pour remédier à cela. Cependant, cette solution présente certaines faiblesses :
- Les ressources SIIV partagent le même serveur physique que les ressources non SIIV.
- L’ajout de ressources allouées à ces nouvelles LPAR entraînera une augmentation des coûts.
Isolation réseau
Les ressources peuvent être partitionnées logiquement via PR/SM (IBM Processor Resource / System Manager). Grâce à cette fonctionnalité, l’urbanisation du mainframe peut être conçue pour optimiser l’utilisation des ressources en dédiant des partitions par environnement ou par type de service. Chaque partition dispose de sa propre pile TCP/IP et d’une ou plusieurs cartes OSA (cartes réseau pouvant être partagées entre partitions).
Les mainframes peuvent être connectés à différents réseaux accessibles via ces diverses piles TCP/IP. Plusieurs piles peuvent fonctionner sur une même instance de mainframe, permettant à une partition z/OS de communiquer avec plusieurs réseaux simultanément. De plus, chaque pile n’est pas nécessairement active sur chaque partition z/OS.
Exemple d’isolation réseau
- Deux ressources partageant la même pile TCP/IP peuvent communiquer directement entre elles sans être filtrées par le pare-feu du mainframe (exemple : communication entre « ressource SIIV 1 » et « ressource SIIV 2 »).
- Deux ressources hébergées dans des LPAR différentes mais partageant le même VLAN peuvent communiquer directement entre elles sans être filtrées par le pare-feu du mainframe (exemple : communication entre « ressource SIIV 1 » et « ressource SIIV 3 »).
- Deux ressources hébergées dans des LPAR différentes et dans des VLAN différents voient leurs communications filtrées par le pare-feu du mainframe (exemple : communication entre « ressource SIIV 1 » et « autre ressource 4 »).
- Toute communication avec des ressources situées à l’extérieur du mainframe est filtrée par le pare-feu du mainframe.
Ce scénario d’isolation réseau permet d’isoler les ressources SIIV des ressources non SIIV à l’intérieur du mainframe, tout en préservant l’optimisation de ce dernier. Le risque opérationnel est faible, car les ressources SIIV ne sont pas déplacées en dehors du mainframe.
Synthèse des solutions
Les scénarios de segmentation sont-ils conformes aux exigences de sécurité de la LPM en matière de filtrage ?
Le scénario d’isolation complet répond entièrement aux exigences de partitionnement et de filtrage de la LPM, car le mainframe serait entièrement dédié aux SIIV, et les flux entrants et sortants seraient filtrés par le pare-feu du mainframe. Cependant, comme mentionné précédemment, cette solution présente plusieurs inconvénients, principalement liés au coût et au risque opérationnel de migrer tous les SIIV vers une autre machine physique.
Le scénario de LPAR dédiée offre une couche d’isolation logique. Les SIIV sont hébergés dans des LPAR dédiées, chacune disposant de ressources spécifiques à l’intérieur du mainframe. Toutefois, cette solution peut entraîner des problèmes de performances et des coûts matériels élevés.
Le scénario d’isolation réseau ajoute une couche supplémentaire d’isolation réseau en s’appuyant sur des piles TCP/IP. Cependant, les applications non SIIV hébergées sur le même réseau que les applications SIIV peuvent encore y accéder directement sans filtrage. Pour remédier à cela, les conditions suivantes doivent être respectées :
- Des zones SIIV dédiées doivent être définies dans les systèmes d’information (SI) où les applications de groupe seront hébergées.
- Des piles TCP/IP dédiées doivent être configurées dans le mainframe, auxquelles les SIIV seront connectés.
Dans ce scénario, les communications des ressources non critiques du groupe avec les SIIV seront forcées de passer par le filtrage du pare-feu.
Administration du mainframe
HMC
Les services de surveillance et de contrôle du matériel des systèmes IBM z sont effectués via une console dédiée (HMC : Hardware Management Console) située dans la zone d’exploitation, et une console Support Element (SE) intégrée dans le CEC (Central Electronic Complex – Boîtier du mainframe) qui est exclusivement utilisée par les opérateurs.
Le HMC est un ordinateur physique situé dans la zone d’exploitation et dédié à la gestion du matériel et des logiciels du mainframe. Il ne peut pas être utilisé à d’autres fins. IBM peut réaliser des actions de support via des connexions distantes RSF (Remote Support Facility) pour signaler et corriger les problèmes matériels. L’accès aux couches système d’exploitation et application ne peut pas se faire via ces consoles.
- Pour garantir la conformité avec la LPM, l’accès au HMC doit être protégé par un pare-feu et limité à un bastion.
Applications d’administration
Les systèmes IBM z intègrent plusieurs applications pour administrer le mainframe, comme TSO (Time Sharing Option) et ISPF (Interface System Productivity Facility). Ces interfaces en ligne de commande permettent aux utilisateurs d’exécuter des commandes, de soumettre des tâches en batch, de gérer les droits et d’effectuer diverses tâches administratives.
L’accès à ces applications est géré via RACF (Resource Access Control Facility), qui authentifie les utilisateurs et contrôle les autorisations en fonction des rôles et des droits d’accès attribués.
Pour restreindre l’accès à ces applications administratives, les mesures suivantes doivent être mises en place :
- Deux interfaces réseau doivent être configurées : une dédiée à l’administration du mainframe et une dédiée aux activités métiers.
- La protection RACF doit être activée sur ces interfaces pour restreindre l’accès en fonction des comptes. À cette fin, RACF doit être configuré pour vérifier la classe Terminal 4et accorder l’accès en fonction de son contenu :
-
- Les comptes d’administrateurs peuvent uniquement accéder à l’interface d’administration.
-
- Les comptes utilisateurs métiers peuvent uniquement accéder à l’interface métier.
Pour garantir la conformité avec la LPM, l’accès à l’interface d’administration doit être protégé par un pare-feu et limité à un bastion.
La segmentation des mainframes constitue un élément critique pour les organisations gérant des SIIV. Comme nous l’avons vu, l’architecture des mainframes fournit une base solide pour mettre en œuvre des stratégies de segmentation efficaces.
Les solutions d’isolation que nous avons examinées offrent chacune des avantages et des inconvénients. L’isolation complète utilisant des mainframes dédiés est entièrement conforme à la LPM, mais a un coût plus élevé, avec un risque opérationnel accru et une flexibilité réduite. L’isolation par LPAR engendre un coût opérationnel important et compromet l’optimisation du MFRz. L’isolation réseau utilisant TSS ou RACF pour dédier des piles TCP/IP offre une solution plus économique et flexible avec moins de risques opérationnels, mais cette solution est partiellement conforme à la LPM car le mainframe n’est pas physiquement dédié aux SIIV. Cependant, le mainframe fournit les outils nécessaires pour sécuriser ses interfaces d’administration et les séparer de la production.
Le choix entre ces solutions nécessite une analyse minutieuse des besoins spécifiques de l’organisation, des exigences de sécurité et des contraintes de ressources. Il est crucial de rappeler qu’il n’existe pas de solution applicable uniformément à tous les cas. L’approche optimale variera en fonction de la nature des SIIV et de l’infrastructure IT globale de l’organisation.
