La fin des mises à jour matérielles des GAB grâce à la virtualisation des systèmes d’exploitation

Télécharger le livre blanc au format PDF.

Résumé

En janvier 2020, le support de Windows 7 prendra fin, et le système d’exploitation devra être remplacé par Windows 10. Cette migration pose un problème majeur aux banques, tant par le coût que par la complexité de la mise à jour des logiciels et composants matériels de leurs guichets automatiques bancaires (GAB).

En 2014, la transition de Windows XP à Windows 7 avait coûté plusieurs milliards de dollars au secteur bancaire, car la mise à jour du système d’exploitation de leurs GAB impliquait également une mise à jour matérielle. Les banques s’apprêtent aujourd’hui à rencontrer le même problème, puisqu’elles vont devoir effectuer leur mise à jour vers Windows 10.

Toutefois, une solution existe. Son nom : la virtualisation des systèmes d’exploitation. Cette solution s’appuie sur une technologie appelée hyperviseur, séparant la carte mère matérielle du système d’exploitation de sorte que les pilotes logiciels non pris en charge sous Windows 10 puissent l’être par le logiciel d’hyperviseur à la place.

Grâce à la technologie d’hyperviseur, il n’est ainsi plus nécessaire de mettre à jour le matériel des GAB lors de leur transition vers Windows 10, protégeant ainsi les investissements logiciels et matériels réalisés par près de 20 000 banques à travers le monde, tout en assurant une conformité à la norme PCI.

Si cette technologie est importante lors de la migration vers Windows 10, elle devient essentielle lors de la gestion de futures versions logicielles du canal de maintenance à long terme (LTSC) sous Windows 10 qui pourraient nécessiter des mises à jour matérielles encore plus fréquentes.

Plus d’informations dans ce livre blanc.

Introduction

Si les guichets automatiques existent depuis plus de 50 ans, ils n’ont que peu évolué pendant une majeure partie de cette période.

Ainsi, au cours des 20 premières années, les architectures des GAB étaient la propriété de leurs fabricants, les composants matériels et logiciels provenant du même fournisseur. La première révolution eut lieu vers 1990 lorsque le système d’exploitation OS/2 d’IBM fit son apparition en tant que système d’exploitation pour les GAB, entrouvrant la boîte noire des guichets automatiques grâce à l’utilisation d’un système d’exploitation standard. Et alors qu’OS/2 déclinait progressivement, Windows prit la relève, devenant tout d’abord l’environnement d’exploitation standard avec Windows NT, suivi de Windows 2000, Windows XP, Windows 7 et désormais Windows 10. De nos jours, la plupart des GAB exploitent une forme ou une autre de Windows.

Une deuxième révolution débuta vers 2000 avec l’introduction de la norme XFS. Tous les périphériques matériels spécialisés contenus dans les GAB, tels que les distributeurs de billets et les lecteurs de carte, ont alors commencé à être dotés de pilotes logiciels standard, conçus selon la norme CEN/XFS. C’est ainsi que débuta l’ère des logiciels multifournisseurs, séparant les applications logicielles des composants matériels.

Nous sommes aujourd’hui à l’aube d’une nouvelle révolution. Il s’agit de la virtualisation des systèmes d’exploitation, une solution technologique venant résoudre un problème majeur pour le secteur.

Jusqu’à présent, dès que le système d’exploitation d’un GAB nécessitait une mise à jour majeure (par exemple de Windows XP à Windows 7 en 2014), une mise à jour matérielle était nécessaire. Et pour le secteur bancaire, cela avait un coût énorme, estimé à plusieurs milliards de dollars pour mettre à jour les millions de GAB à travers le monde.

Un nouveau cycle de mise à jour est prévu en 2020, date à laquelle la prise en charge de Windows 7 prendra fin, le système d’exploitation devant être remplacé par Windows 10. Et c’est donc sans surprise que les banques hésitent à investir une nouvelle fois dans la mise à jour de leurs GAB.

Le problème des mises à jour

L’année 2014 fut désastreuse pour les banques exploitant des GAB. Lorsque Microsoft a cessé le support de Windows XP, il est rapidement devenu évident que les banques n’avaient d’autre choix que de mettre à jour tous leurs GAB vers Windows 7.

Pour Microsoft, le secteur des GAB est presque insignifiant. En effet, face aux quelques deux milliards de PC, la plupart d’entre eux tournant sous Windows, les trois millions de GAB à travers le monde n’ont que très peu de poids. Si les utilisateurs d’ordinateurs ont toujours la possibilité de repousser la mise à jour de leurs PC ou d’acheter de nouvelles cartes mères à un coût relativement faible, les banques ne disposent pas de telles options pour leurs GAB. La mise à jour des cartes mères des GAB est coûteuse. Il faut ainsi compter jusqu’à 4 000 $ (près de 3 500 €) en cas de petits volumes, auxquels s’ajoutent 1 000 $ (870 €) de frais d’intervention d’un technicien qualifié sur place.

Et alors que les banques conservent leurs GAB pendant au moins 10 ans, bon nombre des modèles plus anciens ne peuvent même pas être mis à jour et doivent donc être tout bonnement remplacés. En outre, les nouveaux GAB peuvent coûter entre 10.000 et 30.000 $ (8.700 à 26.000€) en fonction de leurs capacités fonctionnelles, auxquels s’ajoutent les frais de remplacement physique, qui peuvent être exorbitants pour les GAB « muraux » installés dans des lieux très fréquentés comme le centre de Paris, Londres ou New York. Une mise à jour du système d’exploitation d’un GAB n’offre aucun avantage direct pour le client, mais représente un coût énorme pour une simple question de conformité.

Les GAB sont en effet soumis à différentes exigences réglementaires, notamment la norme PCI, qui insistent sur le fait que la chaîne des composants logiciels requis pour exploiter un GAB ne peut pas contenir d’éléments non couverts par un support technique. De nombreuses banques asiatiques ont ignoré ce risque. Les banques américaines et européennes ont, à juste titre, opté pour une autre manière de procéder et ainsi mis à jour leurs réseaux de GAB. Toutefois, nombre d’entre elles s’accordent à dire qu’il est aujourd’hui nécessaire de mettre un terme à ce cycle perpétuel de mises à jour.

Néanmoins, alors que 2020 approche à grands pas, les banques se retrouvent à nouveau confrontées à une situation des plus complexes. Microsoft cessera en effet de prendre en charge Windows 7, et les banques devront ainsi mettre à jour leurs réseaux de GAB vers Windows 10.

Et dans les faits, la situation pourrait empirer après Windows 10. Microsoft a en effet annoncé que Windows 10 serait le « dernier » Windows. Il n’y aura ainsi ni Windows 11 ni Windows 12. Cela signifie-t-il pour autant que la question des mises à jour ne se posera plus après Windows 10? Plusieurs journaux et magazines spécialisés ont en effet proclamé la fin des mises à jour. Toutefois, la réalité est tout autre.

La nouvelle stratégie de Microsoft consiste à effectuer des mises à jour et des améliorations de son système d’exploitation encore plus fréquemment qu’auparavant. Les mises à jour majeures arriveront sous la forme de packages LTSC, ou canaux de maintenance à long terme.

Microsoft prévoit également de lancer à l’avenir des LTSC tous les trois ans. Cela signifie-t-il que les composants matériels des GAB devront être mis à jour tous les trois ans ? Pour faire court, la réponse est probablement oui !

Comment en est-on arrivé là?

Nombreux sont ceux qui reprochent à Microsoft de mettre à jour son logiciel trop souvent ou de ne pas prendre en charge les systèmes d’exploitation suffisamment longtemps, mais réfléchissent également à l’évolution du secteur du logiciel.

Grâce le développement du concept de DevOps et les avancées en matière de tests automatisés, les cycles de publication des logiciels sont de plus en plus courts et par conséquent fréquents. En effet, les versions quotidiennes ne sont pas inhabituelles dans certaines parties du secteur du logiciel. Il est donc clair que Microsoft ne peut pas se permettre d’être bloqué dans un cycle de mise à jour de 7 ans pour Windows. Dans la pratique, le canal LTSC de W10 recommandé pour les GAB sera le cycle le plus long de Microsoft pour les versions de Windows. D’une manière générale, la version de Windows pour les entreprises est le SAC (canal semi-annuel), qui se met à jour beaucoup plus rapidement (tous les six mois), et Microsoft rend obligatoire le déploiement de ces mises à jour. Il est donc peu probable que le SAC convienne aux GAB.

Ces cycles de mise à jour plus courts entraînent une tension considérable sur l’écosystème Wintel. Si Microsoft s’engage à prendre en charge les anciens équipements lors de ses nouvelles mises à jour de système d’exploitation, l’inverse n’est pas vrai. Les fournisseurs de composants matériels ont peu intérêt à mettre à jour leurs anciens pilotes logiciels afin de prendre en charge les nouvelles versions de Windows bien après leur développement. (Remarque : Microsoft n’est en rien différent, et ne prendra pas non plus en charge le nouveau matériel avec ses anciens systèmes d’exploitation.)

C’est justement ce qui cause le problème de support lors des mises à jour de système d’exploitation. Les pilotes logiciels, tels que les pilotes de composants électroniques Intel, prennent uniquement en charge les versions de système d’exploitation disponibles au moment de leur publication, et non pas les nouveaux systèmes d’exploitation susceptibles d’être publiés bien après le développement pilote de composant électroniques.

Intel a annoncé qu’il prendrait en charge un maximum de deux LTSC pour tout puce. La durée de vie des composants matériels des GAB dépend donc de la fréquence de publication de nouveaux LTSC par Microsoft. En effet, lorsque Microsoft avait présenté pour la première fois les LTSC de Windows 10, il était prévu de les lancer tous les 12 à 18 mois, alors qu’Intel avait annoncé qu’il ne prendrait en charge qu’un seul LTSC par puce. La politique semble avoir changé depuis, avec le choix de Microsoft de publier des LTSC par cycle de trois ans, et Intel acceptant de prendre en charge deux LTSC par puce. Les LTSC publiés à ce jour sont les suivants : 1507, 1607, 1809 et 19H1. Ces noms font en réalité référence aux dates de sortie de Microsoft, à savoir juillet 2015, juillet 2016, septembre 2018 et le premier semestre 2019. Les LTSC ont donc été publiés beaucoup plus rapidement que la promesse future d’un cycle de trois ans.

Comme vous pouvez le constater, cette situation est très problématique pour le secteur des GAB. À l’avenir, le cycle de mise à jour semble pouvoir être de six ans, mais il pourrait facilement n’être que de 12 mois, en fonction de l’évolution des LTSC et de leur prise en charge. La raison à cela est que, à mesure que les cycles logiciels s’accélèrent, aucun des fournisseurs de matériel de la chaîne de support ne souhaite prendre en charge les nouvelles versions de système d’exploitation avec leurs anciens composants matériels et pilotes. Ils n’ont ainsi aucunement l’intention de relancer le développement d’anciens pilotes logiciels afin de les intégrer dans de futures versions de système d’exploitation.

Entre le marteau et l’enclume

Cela laisse peu de choix au secteur des GAB. D’une manière générale, les banques exploitent leurs GAB sur une période de 10 ans, et nombre d’entre elles les exploitent encore plus longtemps. Dans la pratique, la maintenance matérielle des GAB se rapproche davantage de celle des avions que de celle des PC. Les avions peuvent être exploités pendant plusieurs décennies, mais au cours de cette période, de nombreux composants matériels ont peut-être été changés plusieurs fois, de sorte que seule la cabine de l’appareil a peut-être 30 ans.

De même, un GAB de 15 ans a probablement connu de nombreux changements au cours de son existence, que ce soit son lecteur de carte, son distributeur de billets, mais aussi son ordinateur. Le problème, cependant, est le système d’exploitation. Si ce dernier doit être modifié au même rythme que Microsoft publie de nouvelles mises à jour, la carte mère devra également être changée en même temps que le système d’exploitation, ce qui représenterait un coût considérable pour la banque. La solution alternative consiste à exécuter un système d’exploitation non supporté et à prendre le risque de ne pas être en conformité avec la norme PCI, outre celui de s’exposer à diverses menaces en termes sécurité, par exemple par des logiciels malveillants (sans parler de l’impact que cela pourrait avoir sur l’image de marque de la société en cas de faille).

Y a-t-il une autre solution ? KAL étudie ce problème depuis 2014, en évaluant les options disponibles, en essayant d’en comprendre les causes profondes, et en déterminant quelles pourraient potentiellement être les solutions à long terme.

Quelle solution adopter?

Un GAB évolutif ? Non.

L’une des options que nous avons envisagées était de savoir si le PC d’un GAB pouvait être rendu plus évolutif.

Imaginez qu’il soit possible de mettre à jour les composants d’un GAB aussi facilement que de changer un DVD. Dans les faits, Intel prend en charge ce type de concept avec sa carte informatique. C’est un ordinateur de la taille d’une carte de crédit qui peut facilement être changé. Cependant, cela impliquerait de repenser la conception des GAB partout dans le monde, et le remplacement du matériel serait relativement coûteux, car cela nécessiterait une intervention sur site.

Ne pas mettre à jour les GAB? Non.

Un grand nombre de GAB de certaines banques asiatiques fonctionnent encore sous Windows XP. L’option consistant à simplement ne pas mettre à jour le système d’exploitation et à continuer à fonctionner sous Windows XP sur les GAB est clairement une stratégie à risque. Non seulement l’utilisation de logiciels non supportés n’est pas conforme à la norme PCI, mais cela expose également la banque et ses clients à des programmes malveillants et à des cyberattaques potentielles, les vulnérabilités de systèmes d’exploitation non supportés pouvant être exploitées par les cybercriminels. Voilà pourquoi cette option ne devrait pas être envisagée.

Toutefois, il existe une alternative à la « non-mise à jour » des GAB pouvant potentiellement fonctionner à l’avenir avec Windows 10 et les versions ultérieures de LTSC.

Supposons qu’une banque mette initialement à jour ses GAB vers Windows 10 comme requis. La version de Windows 10 en 2019 s’appelle Windows 10 LTSC 1809, et fonctionne avec une puce prenant en charge ce LTSC. Microsoft, Intel et les GAB prendront en charge cette combinaison pendant 10 ans. À première vue, cela peut donner l’impression de résoudre le problème, mais ce n’est pas le cas. Imaginez la situation suivante:

• Au fur et à mesure de leur publication, les nouveaux LTSC de Windows 10 ne peuvent pas être utilisés sur un GAB de 2019, c’est-à-dire pendant les 10 années au cours desquelles ce même GAB devrait exécuter le LTSC original.
• Examinons à présent le cycle annuel de remplacement des GAB. Par exemple, une grande banque disposant de 10 000 GAB remplacerait 10 % de son parc chaque année à mesure que les GAB vieillissent. Chaque année, la banque pourrait acheter 1 000 nouveaux GAB équipés du dernier LTSC de Microsoft et les puces actuelles d’Intel. Par exemple, en 2023, ils recevraient le LTSC 23XX. Bien que ces nouveaux automates fonctionnent sous LTSC 23XX, les anciens automates convertis en 2019 peuvent uniquement exécuter LTSC 1809. Après 10 ans, le réseau de GAB aurait potentiellement 10 combinaisons de LTSC et puces différentes, exécutant différentes versions de système d’exploitation et disposant de différentes fonctionnalités.
• Bien que chaque GAB soit doté d’un ensemble de logiciels supportés sur une période de 10 ans, cela impliquerait de ne pas mettre à jour le système d’exploitation au fur et à mesure de la publication de nouveaux LTSC, entraînant la fragmentation du réseau avec potentiellement de nombreuses versions de système d’exploitation à travers ce dernier. Cette situation serait intenable pour la plupart des banques.

Changer la stratégie de support d’Intel pour les GAB ? Non.

Aravinda Korala, PDG de KAL, et Mike Lee, PDG d’ATMIA, ont conjointement réalisé une série d’entretiens avec Intel afin de comprendre si la société américaine envisageait de mettre en place un régime de support spécial de ses pilotes de composants électroniques pour le secteur des GAB.

La conversation était dirigée par Oania Wei et Alec Gefrides, Directeur Général, Département Commerce Transactionnel chez Intel. Nous avons abordé différents concepts, tels que le support spécial payé à long terme pour les pilotes Intel pour le secteur des GAB, et l’octroi à l’ATMIA de licences du code source des anciens pilotes. Au final, il est apparu évident que, pour Intel, les guichets automatiques ne constituent qu’un petit secteur pour lequel aucune des options proposées n’était viable. Toutefois, Intel proposa d’envisager à nouveau le recours à Linux, et présenta à KAL Wind River, une société de distribution de Linux qui était également à l’époque une filiale d’Intel.

Migrer les GAB vers Linux ? Non.

Depuis très longtemps, Linux est une option pour les GAB. L’utilisation de Linux sur des GAB a connu un certain succès au Brésil, utilisant des équipements fabriqués dans ce pays, mais nulle part ailleurs.

Le secteur mondial des guichets automatiques est un marché relativement limité, avec seulement 3,5 millions de GAB à travers le monde. Le support d’un marché fragmenté sous Linux et Windows n’était pas réalisable d’un point de vue commercial pour les fournisseurs. Prenez en considération qu’il existe environ 20.000 banques dans le monde. Le choix du système d’exploitation utilisé sur GAB incombe aux banques, et non aux fournisseurs. Et les banques refuseront tout simplement qu’un système d’exploitation non couvert par leurs politiques soit connecté à leur réseau interne.

Combien de temps faudra-t-il pour convaincre ces 20.000 banques d’utiliser Linux comme système d’exploitation sur leurs GAB ? Vous pouvez deviner la réponse. La migration vers un ensemble de logiciels Linux intégrale devrait ainsi engendrer une très longue période de fragmentation du marché. Voilà pourquoi aucun des principaux fabricants de GAB n’a, à ce jour, décidé d’investir dans la prise en charge conjointe de Linux et Windows sur leurs appareils au cours d’une période de transition si longue. Dans la mesure où les pilotes XFS sont contrôlés par les fabricants, si ces derniers ne sont pas portés sous Linux, il est alors impossible pour un fournisseur de logiciels d’exécuter une application Linux sur un GAB, et ce quel que soit son budget de recherche et développement.

Pourquoi envisager Linux ? Linux possède une fonctionnalité particulièrement utile qui permet de sortir de cette impasse. Tous les pilotes logiciels Linux, y compris les pilotes de puce Intel, sont en code source ouvert sous Linux. Cela signifie que des sociétés telles que Wind River et Red Hat de l’écosystème Linux ont accès à ce code source, et peuvent ainsi assurer une prise en charge sur une base commerciale. Et cela permet aux banques de résoudre la question de conformité à la norme PCI.

Toutefois, cela ne résout pas le problème du coût de la migration de Windows à Linux de tous les logiciels des GAB des milliers de banques à travers le monde.

La solution – Une idée lumineuse

Si Linux peut résoudre le problème du support logiciel à long terme, il présente un désavantage de poids par rapport à Windows, en ce sens que les banques ont investi des milliards de dollars dans des logiciels de gestion de GAB fonctionnant sous Windows. Le coût de la migration serait considérable.

Outre cet obstacle financier, les banques font également face à un problème technique. Les GAB disposent de pilotes matériels utilisant le standard XFS uniquement implémentés sous Windows. Même si une banque souhaitait migrer l’ensemble de ses logiciels vers Linux, elle ne pourrait le faire que si le fournisseur des composants matériels était également à même de migrer ses pilotes XFS vers Linux. Les principaux fournisseurs de matériel sous Linux ne proposent actuellement aucun pilote pour les GAB.

Existe-t-il alors une solution permettant de combiner les avantages de Linux et de Windows ?

KAL étudie la question en collaboration avec Wind River depuis près de deux ans. L’équipe de KAL était dirigée par Aravinda Korala et Kit Patterson, tandis que Kevin Konkos et Davide Ricci encadraient celle de Wind River. Et la conclusion à laquelle nous sommes arrivés est d’utiliser un hyperviseur Linux pour héberger Windows 10.

Linux possède une technologie d’hyperviseur baptisée QEMU. QEMU fonctionne conjointement avec KVM afin d’exploiter l’accélération matérielle de virtualisation prise en charge sous Linux, et est capable de présenter une interface de Windows 10 pour fonctionner en tant que système d’exploitation invité sous Linux. Les pilotes matériels de la carte mère proviennent à présent du noyau Linux, mais l’environnement applicatif fonctionne sous Windows. La prise en charge de QEMU, KVM et des pilotes Linux est assurée par la communauté Linux et des entreprises telles que Red Hat et Wind River. La partie Linux peut donc être supportée pour n’importe quelle durée, sous réserve que les conditions commerciales soient acceptables pour les sociétés Linux.

Windows peut être installé en complément de Linux, et ainsi être mis à jour aussi souvent que Microsoft et les banques le souhaitent. D’autre part, tout ce processus peut être réalisé à distance, sans devoir recourir à une intervention sur site. Et cela permet de résoudre la question des mises à jour. Grâce à cette solution, il n’est plus nécessaire d’appliquer des mises à jour matérielles rendues obligatoires par les mises à jour ou LTSC de Windows, et les banques peuvent par conséquent garder leurs systèmes à jour et exécuter les dernières versions de tous les logiciels. En bref, cela leur permet de briser le cercle des mises à jour matérielles forcées.

Le principe de fonctionnement

Que sont les hyperviseurs et la virtualisation ?

La virtualisation n’est pas un concept nouveau. Dans les années soixantes, IBM avait déjà créé des machines virtuelles et des environnements virtualisés sur des ordinateurs centraux. Cette solution est à présent largement utilisée dans presque tous les centres de données de la planète.

Les hyperviseurs permettent à plusieurs systèmes d’exploitation d’être exécutés sur un même serveur matériel. L’hyperviseur de VMware est peut-être l’un des plus connus. Les centres de données de toute la planète utilisent les hyperviseurs de VMware ou encore Red Hat afin d’isoler les composants matériels de l’environnement d’exploitation.

Par exemple, il serait possible d’exécuter Windows XP et Windows 7 simultanément en tant que systèmes d’exploitation invités sur un système d’exploitation hôte VMware. Les hyperviseurs permettent également aux serveurs d’être contrôlés et gérés à distance. Un processus peut être interrompu en cours d’exécution, transféré vers un nouveau serveur matériel, et relancé depuis le point où il avait été stoppé, comme si rien ne s’était passé.

La virtualisation matérielle d’Intel et AMD

Les hyperviseurs logiciels s’appuient sur les solutions matérielles d’Intel et d’AMD.

À ses débuts, la virtualisation était uniquement une technique logicielle. Elle devait ainsi recourir à une émulation logicielle afin de permettre à un système d’exploitation invité de s’exécuter sur un système d’exploitation hôte. Toutefois, le processus d’émulation et de traduction des commandes d’accès matérielles d’un système d’exploitation à un autre était coûteux et ralentissait considérablement les systèmes.

Vers 2005, Intel et AMD dotèrent leurs nouveaux processeurs de la technologie de virtualisation assistée par matériel. Ces technologies, appelées Intel VT-x et AMD-V, permettent aux exécutables du système d’exploitation invité de s’exécuter de manière native sur le processeur, mais reçoivent les appels système afin de pouvoir être traités par le bon système d’exploitation. Résultat : le logiciel du système d’exploitation invité s’exécute comme s’il disposait de l’ensemble du processeur, sans impact perceptible sur les performances.

Lors des tests de KAL, l’impact sur les performances n’était que d’environ 2 % pour un GAB virtualisé exécutant à la fois Windows et Linux, par rapport à l’exécution native de Windows sur le même matériel sans virtualisation.

Le diagramme ci-dessous présente la nouvelle architecture logicielle d’un GAB doté de la technologie de virtualisation de système d’exploitation.

L’hyperviseur fonctionne sur l’ordinateur du GAB, Window 10 s’exécute en tant que système d’exploitation invité au-dessus de l’hyperviseur, et les applications ainsi que les Service Providers XFS du fournisseur de composants matériels s’exécutent dans une machine virtuelle Windows.

À quoi ressemble une solution de GAB virtualisée?

Au niveau conceptuel, une solution logicielle virtualisée ressemble exactement à l’ensemble des logiciels actuels, à la différence près qu’un hyperviseur est ajouté entre Windows et les composants matériels. Mais bien entendu, la mise en place d’une véritable solution n’est pas aussi simple que ça. Pour commencer, passons en revue les conditions préalables.

Conditions préalables à une solution de GAB virtualisée

Bien que les hyperviseurs puissent fonctionner sur des GAB n’offrant pas un support matériel pour la virtualisation intégrée via l’émulation logicielle, cette solution risque d’être trop lente. Voici donc une liste des conditions préalables à la virtualisation des GAB:

1. Première condition : les cartes mères Intel doivent être dotées la technologie VT-x et celles AMD de la technologie AMD-V. Dans la mesure où les processeurs dotés de ces capacités matérielles ont uniquement commencé à voir le jour vers 2006, les GAB plus anciens ne pourront pas prendre en charge la virtualisation sans impact significatif sur leurs performances. Il est également probable que des GAB dotés de ces fonction nalités n’aient commencé à être installés que bien après 2006, car les fournisseurs utilisaient souvent des stocks de processeurs plus anciens sur une longue période. Par conséquent, la transition eut lieu après 2006.
   
   
2. La fonctionnalité de virtualisation des processeurs compatibles avec cette technologie peut également être désactivée depuis le BIOS. La modification de ce paramètre nécessiterait donc une intervention sur site, ce qui augmenterait le coût global de la mise en oeuvre d’une solution d’hyperviseur. Toutefois, certains fournisseurs de composants matériels de GAB disposent d’outils de gestion du BIOS pouvant être utilisés à distance.KAL recommande cette option afin de tester dans un premier temps la configuration du BIOS, avant de la modifier à distance pour activer la virtualisation. Cette option devrait être activée par défaut sur les GAB plus récents.
   
   
3. Par la suite, les banques devront choisir un fournisseur d’hyperviseur. Trois sociétés ont déjà manifesté leur intérêt pour soutenir le secteur des GAB : Red Hat, VMware et Wind River. KAL a testé les hyperviseurs des trois sociétés et peut confirmer qu’ils fonctionnent tous. Microsoft possède également un hyperviseur appelé Hyper-V. Partie intégrante de Windows, il pourrait fonctionner en théorie, mais il souffre des mêmes défauts que Windows. Le code source du pilote n'étant pas disponible pour les pilotes de périphériques tiers sous Windows, les pilotes non supportés par Hyper-V ne le seront pas par Microsoft ou tout autre prestataire.
   
   
4. Enfin, les banques doivent également vérifier que leurs fournisseurs de matériels et de logiciels de GAB prennent en charge leurs applications et leurs pilotes au sein d’un environnement virtualisé. Par exemple, si leur fournisseur de logiciels de GAB est KAL, ils doivent s’assurer que KAL prendra en charge un environnement virtualisé - ce qui est le cas - et ensuite vérifier que leur fournisseur de GAB acceptera de mantenir ses Service Providers XFS dans un environnement virtualisé. Les banques doivent en outre veiller à ce que le support de la virtualisation soit intégrée dans leurs futurs appels d’offres. C’est ce qui s’est passé en 2000 avec la mise en place de la norme XFS. Les banques ont demandé à tous leurs fournisseurs d’assurer la prise en charge de XFS, ce qui eut pour conséquence de changer l’univers des GAB.

Une solution prête à être déployée?

À vrai dire, pas tout à fait. En effet, il ne suffit pas de remplir les conditions préalables, et les banques doivent également mener à bien un projet de mise en oeuvre:

1. La nouvelle solution d’hyperviseur doit être testée afin de s’assurer que tous les scripts de tests utilisés continueront de fonctionner lorsque le système d’exploitation sera virtualisé, ce qui, théoriquement, devrait être le cas.
2. Les banques doivent également repenser le système de sécurité de leurs GAB. Le nouvel environnement modifiant l’espace à sécuriser, elles doivent sécuriser l’hyperviseur ainsi que l’environnement Windows.
3. Les banques doivent passer en revue le système de surveillance de leurs GAB. Idéalement, le logiciel de l’hyperviseur devrait également être contrôlé, de même que le reste du système.
4. Les banques devront examiner le mécanisme de distribution des logiciels. Idéalement, cette transition devrait s’effectuer en totalité avec la télédiffusion de logiciels à distance, sans devoir recourir à une intervention sur site d’un technicien. Le système de distribution de logiciels doit pouvoir être capable de déployer les correctifs et mises à jour sur le logiciel d’hyperviseur, ainsi que sur Windows et l’application, le tout idéalement à distance (ou via DVD si cette option est la seule disponible).

Après avoir réalisé ces étapes, elles pourront passer à la mise en oeuvre.

KAL est prêt dès aujourd’hui.

Stratégie de support à long terme

L’ensemble des logiciels des GAB contient un composant supplémentaire, en l’occurrence l’hyperviseur, pour lequel les banques doivent désormais disposer d’un contrat de support. Nous avons dressé ci-dessous la liste des différentes exigences que doivent remplir leurs fournisseurs d’hyperviseurs :

• Engagement de supporter le matériel de GAB à long terme, pour une période d’au moins 10 ans.
• Support en charge des pilotes de périphériques de carte mère sous Linux afin que les pilotes logiciels tiers sous Windows de ce même matériel qui ne sont plus couverts par les nouveaux LTSC puissent être remplacés par des pilotes Linux open source via la virtualisation.
• Support des composants électronique AMD et Intel depuis aussi longtemps que les fournisseurs d’hyperviseurs peuvent l’assurer, afin que les anciens GAB de leurs réseaux puissent être supportés.
• Support des LTSC de Microsoft dès leur publication, en tenant compte des problèmes potentiels liés aux pilotes logiciels pour les anciens composants matériels, comme indiqué ci-dessus.

Idéalement, l’industrie des GAB a besoin d’une seule version globale de l’hyperviseur de chacun des fournisseurs pour supporter tous les modèles de carte mère GAB dans le monde entier.

Conclusion et perspectives d’avenir

La virtualisation résout un problème pour les déployeurs de GAB en brisant le lien entre mises à jour du système d’exploitation Windows et mises à jour des composants matériels de l’automate. Cette solution permet ainsi de mettre à jour le système d’exploitation et les périphériques de façon séparée, tout en évitant une perturbation des réseaux de GAB lors de la fin du support de Windows 7 en 2020.

La première banque de la planète à tester le concept de virtualisation aux côtés de KAL et de deux fournisseurs d’hyperviseurs était américaine. La capacité à exécuter l’ensemble de logiciels actuel de la banque dans un environnement virtualisé a ainsi été démontrée dans un PoC (preuve de concept) qui a duré quelques jours.

La première banque européenne à avoir testé le concept avec KAL fut Česká spořitelna, en République tchèque. Jiří Charousek a immédiatement apprécié la technologie et a réalisé les premiers tests. Nous étions inquiets par l’éventualité de devoir mettre à jour notre matériel si peu de temps après la transition de Windows XP à Windows 7, et nous sommes vraiment ravis que la virtualisation nous offre une option alternative.

La virtualisation des GAB était une idée totalement naturelle pour nous, dans la mesure où elle s’appuie sur un concept à long terme de Česká dans le domaine des infrastructures. Notre stratégie était déjà orientée vers la virtualisation et les GAB faisaient exception.

Ce concept est également une aubaine pour les fournisseurs de matériel informatique qui achètent souvent des cartes mères et composants électroniques en grande quantité avant de découvrir qu’une nouvelle mise à jour du système d’exploitation rend leur stock de matériels obsolète. La virtualisation rompant le lien entre cartes mères et systèmes d’exploitation, KAL considère que cela permettra également aux fabricants de GAB de réaliser des économies.

La virtualisation des systèmes d’exploitation constitue ainsi la solution afin d’éliminer le processus coûteux, long et fastidieux qui oblige les banques à mettre à jour en permanence leurs parcs de GAB afin de prendre en charge un nouveau système d’exploitation. Si cela ne supprime pas la nécessité de mettre à jour les composants matériels, cela permet toutefois de ne plus devoir mettre à jour les GAB à chaque mise à jour de leur système d’exploitation. Les banques devront toujours mettre à jour leurs GAB, soit parce qu’ils sont trop vieux ou trop lents, ou soit parce qu’elles souhaitent simplement utiliser les dernières capacités des processeurs afin de proposer de nouveaux services à leurs clients. Toutefois, les banques conviendront que c’est une bonne raison de mettre à jour leur matériel.

À ce stade, il est essentiel que les banques imposent la prise en charge de la virtualisation dans tous leurs appels d’offres de logiciels et périphériques de GAB.

Remerciements

De nombreuses personnes ont contribué à la conception de cette solution et à la démonstration de son efficacité. Toute l’équipe de KAL tient à les remercier chaleureusement.

• ATMIA : Mike Lee
• Citibank : Peter Kulik
• Česká : Jiří Charousek
• Intel : Oania Wei
• KAL : Kit Patterson, Andrea Vinci, Giuseppe Scardino
• Microsoft : Pat Telford
• Payment Redesign : Eric de Putter
• Red Hat : David Hutchison-Bird, Daniel Schaefer, Rich Feldman
• VMWare : Thomas Klouwer
• Wind River : Davide Ricci, Rick Anderson, Kevin Konkos
• Traduction : LogrusIT

Pour aller plus loin

Vos commentaires, questions et opinions sont les bienvenus. Rejoignez notre blog

Télécharger le livre blanc au format PDF.

Pour plus d’informations, contactez-nous par e-mail à l’adresse Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.