Échec de la continuité d’activité : 4 exemples retentissants

FAA : l’effacement d’un fichier cloue au sol des milliers d’avions américains

Le 11 janvier 2023, des milliers de vols à travers les États-Unis ont été cloués au sol en raison d’une panne du système de la Federal Aviation Administration (FAA, l’agence américaine qui contrôle l’aviation civile). Cette panne a duré plusieurs heures et concernait la base de données des avis de missions aériennes, appelés NOTAM. Les NOTAM sont un système essentiel que les pilotes doivent consulter avant le décollage pour être informés des dangers et des fermetures de pistes.

Selon la FAA, l’origine de cette panne était la suppression inopinée d’un fichier. Dans ce cas précis, l’infrastructure de la base des NOTAM, très ancienne, ne supportait pas la haute disponibilité. C’est le fait d’écrire en Y sur deux infrastructures, pour qu’il y en ait toujours une opérationnelle si l’autre plante. Selon les experts, la durée de la panne aurait pu être considérablement réduite avec la haute disponibilité de systèmes plus récents.

Ici, la FFA avait toujours considéré que le remplacement d’un système de longue date, utilisé au niveau international, ne serait pas une mince affaire. Elle avait donc toujours repoussé sa mise à jour. Les entreprises réticentes à remplacer les systèmes existants peuvent tirer des leçons de cet échec en matière de continuité des activités. Les systèmes obsolètes qui empêchent la mise en œuvre des normes et des délais de récupération actuels rendent la continuité des activités plus difficile qu’elle ne l’est déjà.

Leçons à tirer : Les équipes IT des entreprises qui, pour quelque raison que ce soit, ne peuvent pas remplacer les systèmes obsolètes en place, devraient donner la priorité aux stratégies de continuité des activités. Il s’agit notamment de savoir comment tester des incidents sans interrompre les opérations, en mettant en place des processus de haute disponibilité et en vérifiant l’intégrité des sauvegardes. Elles peuvent également s’appuyer sur des incidents très médiatisés, comme cette panne du système de la FAA, pour justifier la nécessité d’un nouveau système.

Échouer à maintenir les activités en cas de sinistre est considéré comme un échec informatique, à la fois coûteux et qui peut nuire considérablement à la réputation d’une entreprise. 

Microsoft Azure et Office : un mauvais réglage bloque les utilisateurs européens

Toujours en janvier 2023, Microsoft a connu une panne majeure qui a touché les utilisateurs du monde entier, mais surtout en Europe.

Cette panne a empêché de nombreux utilisateurs, professionnels comme particuliers, d’accéder à leur courrier électronique ou à leurs fichiers et d’administrer et gérer leur infrastructure Azure. La cause principale finalement identifiée était une erreur de paramétrage au niveau de l’infrastructure de routage principale d’Azure. Erreur commise par les équipes de Microsoft elles-mêmes.

Leçons à tirer : Malheureusement, il n’existe pas de solution universelle quand le problème vient du cloud. Cependant, les grandes entreprises peuvent atténuer les pannes en utilisant plusieurs zones. Dans ce cas, chaque région dispose de plusieurs centres de données situés à des centaines de kilomètres les uns des autres et ne partageant aucune ressource ; de sorte que la perte d’une seule zone n’entraîne pas l’arrêt global de l’environnement.

Les petites entreprises peuvent estimer qu’il est plus simple d’utiliser des outils de reprise après sinistre (et non de continuité après sinistre), notamment ceux d’Azure. Ces outils épargnent la complexité et le coût d’une configuration multizone avec redondance. Ils permettent de mettre en place la bascule des traitements vers une infrastructure déployée pour l’occasion, ce qui rétablit assez rapidement une situation presque normale. Attention, cela nécessite une certaine planification au préalable, notamment pour préparer les processus automatiques de restauration et de routage du trafic.  

OVHcloud : l’incendie qui a détruit un datacenter et endommagé sa réputation

Même les plus grandes entreprises disposant de ressources illimitées ne peuvent empêcher les catastrophes naturelles de se produire. Résister à des conditions naturelles extrêmes est une question de préparation. Malheureusement, OVHcloud ne s’était pas assez préparé.

En mars 2021, l’un des centres de données du fournisseur de cloud a pris feu. On en ignore toujours officiellement la cause, même si un rapport confidentiel des pompiers, dévoilé à l’époque par erreur, pointait la proximité dangereuse des onduleurs – susceptibles de faire des étincelles – et des batteries, remplies de carburant.

Toujours est-il que les dispositifs d’extinction des incendies n’ont pas été à la hauteur. À leur réveil, des milliers de clients d’OVHcloud ont découvert que les serveurs qu’ils avaient loués étaient hors service. Pour ne rien arranger, l’une des baies de sauvegarde a été complètement détruite dans l’incendie, perdant ainsi des sauvegardes critiques que le fournisseur de services aurait pu utiliser pour récupérer les données de ses clients.

Cette crise n’a pas seulement affecté les activités commerciales : la réputation d’OVHcloud a souffert de la panne. L’hébergeur a fait l’objet d’un recours collectif de 10 millions d’euros de la part de plus de 140 de ses clients.

Leçons à tirer : L’échec de la continuité des activités d’OVHcloud illustre l’importance de la règle des 3-2-1 en matière de sauvegarde des données. Des sauvegardes multiples, sur du matériel différent et dans des lieux différents, constituent le moyen le plus sûr de garantir la sécurité des données en cas d’incendie ou de catastrophe naturelle. Ainsi, si le centre de données est détruit, il reste une sauvegarde de données ailleurs que le client peut restaurer pour que les services fonctionnent à nouveau.

Hôpitaux britanniques : paralysés par un ransomware

Au Royaume-Uni, le National Health Service (NHS), équivalent de la Sécurité sociale, administre tous les soins de santé publics. Les temps d’arrêt de ses systèmes coûtent cher et bloquent toutes les actions médicales du service public. Après une attaque par ransomware le 4 août 2022, le NHS a été incapable de maintenir la continuité de son activité. Et, ce, pendant des semaines.

L’attaque, qui visait un important fournisseur de logiciels pour le NHS, a pris plusieurs mois avant d’être entièrement corrigée. Au cours des premières phases, les centres de soin ont dû revenir au papier et au crayon et se contenter de traiter les dossiers qui n’étaient pas informatisés.

Le retard dans le rétablissement des services s’explique en partie par la nécessité de remettre en production de très nombreux systèmes. Mais aussi à cause de la présence de toute une flotte d’anciens systèmes, encore utilisés alors qu’ils échappaient aux dispositifs modernes de supervision.

Leçons à tirer : Les vieux systèmes conservés en production entraînent souvent des coûts d’administration plus élevés. De fait, ils sont plus susceptibles d’être négligés en ce qui concerne la maintenance et les mises à jour. Cela est certes plus facile à dire qu’à faire, mais l’un des moyens d’éviter ces problèmes est de retirer les vieux systèmes de la production.

Les entreprises doivent également disposer de politiques strictes en matière d’acquisition et de gestion des systèmes informatiques, logiciels compris. Tout achat doit faire l’objet d’une administration rigoureuse et être soumis à l’approbation de la DSI, car celle-ci est souvent au courant de problèmes que les directions métier, qui achètent des solutions d’appoint, ignorent.