Sécurité informatique : les constructeurs automobiles devraient également s’imposer des crash tests

Par Gonzague Dupont, Manager, DACH & Southern Europe chez Zerto
Pourquoi les constructeurs automobiles doivent améliorer leurs solutions de continuité/reprise d’activité après sinistre pour obtenir un meilleur niveau de résilience informatique.
En 2016, deux équipementiers automobiles se sont vus contraints d’interrompre brutalement l’approvisionnement de leur client Volkswagen, entrainant des retards importants sur les chaînes de production de Volkswagen et des pertes estimées à 100 millions d’euros. Cet événement, très médiatisé à l’époque, a montré à quel point la chaîne d’approvisionnement complexe du secteur automobile peut être vulnérable aux perturbations. Les applications informatiques deviennent des engrenages de plus en plus critiques dans ce système complexe, et les constructeurs automobiles se sont mis à vérifier si l’informatique de leurs fournisseurs est bien à jour et ne risque pas de subir des temps d’arrêt non planifiés. Cela place les stratégies de continuité/reprise d’activité après sinistre des équipementiers automobiles directement dans le collimateur de leurs principaux clients. Il est temps pour eux de vérifier si les stratégies actuelles sont à la hauteur et, si ce n’est pas le cas, de passer à une solution de pointe en matière de résilience informatique.

Les pannes de système : un risque majeur pour les constructeurs automobiles et les équipementiers

L’incident entre l’équipementier bosniaque Prevent et Volkswagen en 2017 a publiquement mis en évidence la dépendance des constructeurs automobiles envers leurs fournisseurs. Bien que cet épisode d’arrêt de la chaîne de production ait reposé sur un litige contractuel, les constructeurs automobiles examinent maintenant de plus près les diverses raisons possibles pour lesquelles leurs fournisseurs pourraient ne pas être en mesure de les livrer dans les délais requis. Parmi ces raisons figure un temps d’arrêt non planifié, dû à une défaillance des systèmes informatiques.

Les systèmes tombent souvent en panne pour diverses raisons. Si une entreprise est touchée, c’est un gros titre de choix, ce qui implique de grosses pertes de revenus. La construction automobile est un bon exemple d’une industrie fortement menacée par ce type de pannes car la chaîne d’approvisionnement pour la livraison de ces dizaines de milliers de pièces en temps réel à la chaîne de production est non seulement immensément complexe, mais également, dans une très large mesure, organisée par informatique. L’informatique aide les équipementiers, les constructeurs et les services logistiques à travailler main dans la main pour maintenir l’activité des chaînes de production.

Parmi les nombreuses raisons pour lesquelles les systèmes informatiques peuvent tomber en panne, deux constituent les plus gros risques pour l’industrie automobile : L’erreur humaine et les cyberattaques.

Sur le plan technique, les organisations ont déjà mis en place des stratégies pour empêcher théoriquement les pannes du système : les clusters étendus, associés aux snapshots et aux sauvegardes, sont censés garantir le fonctionnement sans interruption. Après la réussite d’attaques de ransomware, ainsi que des pannes de système aléatoires qui n’auraient théoriquement jamais dû se produire, de nombreuses organisations commencent à réaliser que leurs investissements dans la technologie de reprise après sinistre ne les protègent que contre des défaillances matérielles, et pas contre les erreurs logiques — comme le ransomware ou les erreurs humaines.

La norme actuelle en reprise d’activité après sinistre : une technologie de cluster étendu

Pour comprendre la cause des pannes, il faut examiner les fondations des stratégies actuelles de continuité et reprise d’activité. Pour obtenir un temps de fonctionnement optimal, les entreprises ont investi dans une technologie de cluster étendu afin de résister aux défaillances matérielles. Les snapshots et les sauvegardes régulières côté logiciel ont pour but de minimiser les RPO (Recovery Point Objective) et RTO (Recovery Time Objective). Le cluster étendu fournit, dans le meilleur des cas, un basculement transparent dans l’éventualité d’une défaillance matérielle, voire d’un sinistre plus grave affectant un site tout entier. Il existe toutefois des inconvénients à choisir un cluster étendu comme base de continuité/reprise d’activité après sinistre : son coût élevé, sa complexité et le fait souvent négligé qu’il ne protège pas contre les erreurs logiques ou la perte de données des applications. Une stratégie de continuité/reprise d’activité après sinistre qui comprend un cluster étendu côté matériel et des snapshots associés à une technologie de sauvegarde côté logiciel, ne permet à l’utilisateur de récupérer ses données qu’en fonction des intervalles paramétrés entre chaque snapshot ou chaque sauvegarde. De plus, la technologie elle-même affiche des besoins très élevés en espace de stockage.

Le degré de résilience informatique peut jouer un rôle dans le choix des fournisseurs

La qualité et le prix d’une pièce automobile sont évidemment des points importants pour un constructeur automobile. Toutefois, la capacité d’un fournisseur à livrer ces pièces est tout aussi importante. À l’heure et sans exception. « Désolé, nos systèmes sont déconnectés en raison d’une maintenance non planifiée », ne sera pas accepté comme excuse. « Ce n’est pas de notre faute, on s’est fait pirater par un ransomware », non plus. Les constructeurs automobiles commencent à faire preuve de diligence raisonnable et à vérifier la capacité de leurs partenaires commerciaux à résister aux pannes informatiques — en particulier dans l’industrie automobile qui dépend beaucoup des systèmes informatiques et d’une livraison ponctuelle.

Démontrer que leur informatique est résiliente et peut résister à n’importe quel sinistre, naturel ou humain, peut s’avérer plus difficile que de prouver la qualité d’une boîte à gants. Le PDG d’un équipementier se verra présenter à un moment donné l’exigence de prouver que son système informatique est également à la hauteur dans le contexte d’une chaîne d’approvisionnement complexe. Il est facile de démontrer ce point : un test de reprise après sinistre documenté, à effectuer régulièrement, peut démontrer la capacité de résistance des systèmes à une panne non planifiée et la possibilité de les remettre en service en très peu de temps. Malheureusement, la plupart des stratégies de continuité/reprise d’activité après sinistre utilisées aujourd’hui sont dépassées, car elles ne s’appuient que sur une technologie de cluster étendu qui garantit un temps de disponibilité uniquement au niveau matériel — et dans les contextes riches en données, il est très difficile de montrer précisément le degré de résilience informatique atteint par une entreprise.

Le nec plus ultra des systèmes de continuité/reprise d’activité : la résilience informatique.

La résilience informatique promet d’accroître la protection par rapport aux stratégies traditionnelles de la continuité d’activité, en améliorant la souplesse des infrastructures pour permettre aux IT d’éviter les pannes, qu’elles soient planifiées ou non. La base d’une plateforme de résilience informatique est la protection continue des données (Continuous Data Protection ou CDP). La CDP est l’état actuel de la technologie de sauvegarde. On l’appelle souvent sauvegarde continue ou sauvegarde en temps réel. La différence par rapport aux stratégies classiques de continuité/reprise d’activité, qui utilisent avec des sauvegardes complètes et des snapshots, est que la CDP enregistre automatiquement chaque modification de données au niveau des blocs. Cela signifie que la sauvegarde n’est plus stockée à intervalles réguliers, mais en continu, dans un journal.

Ce n’est qu’une question de temps avant que les constructeurs automobiles, désireux d’évaluer les risques posés par leurs fournisseurs demandent aux équipementiers de prouver leur capacité à résister aux pannes du système informatique. Tous les partenaires concernés doivent comprendre les lacunes des stratégies actuellement utilisées, qui ne protègent que contre les défaillances matérielles, mais pas contre les erreurs logiques. Afin de pouvoir résister à toutes les causes possibles des pannes système, qu’elles soient planifiées ou non, les fournisseurs doivent mettre à niveau leurs solutions de continuité/reprise d’activité pour améliorer leur degré de résilience informatique.

%d blogueurs aiment cette page :