Single point of failure : point de défaillance unique

Un point de défaillance unique (« single point of failure » ou SPOF en anglais) correspond à une vulnérabilité d’un système matérialisée par un seul et unique composant. Si le composant fait défaut, le système dans sa totalité échoue. Quels sont les différents types de SPOF et comment peut-on réduire le risque de voir des SPOF se produire ?

Un Single point of failure (SPOF) décrit un type de vulnérabilité au sein d’un système. On parle de SPOF lorsque la défaillance d’un seul composant provoque l’échec d’un système entier. Plusieurs modes d’échec existent. Ceux-ci se divisent en trois grandes catégories :

1. Talon d’Achille ou « maillon le plus faible de la chaîne » : la perte d’un seul composant entraîne l’arrêt du fonctionnement du système entier.
2. Réaction en chaîne ou « effet domino » : l’échec d’un composant entraîne l’échec consécutif d’autres composants, ce qui conduit à l’échec du système dans sa totalité.
3. Embouteillage : un composant agit comme un facteur limitant du système dans son ensemble. Si le composant limitant est détérioré, les performances du système sont réduites à la hauteur des capacités du composant.

Les SPOF ont fréquemment lieu au sein des systèmes complexes composés des composants interconnectés en plusieurs couches. En fonction de la structure du système, l’échec d’un composant critique provoque l’échec du système dans sa totalité. Le single point of failure prend la forme d’un composant critique.

La complexité d’un système à plusieurs couches peut rendre difficile le fait de détecter les SPOF. Il n’y a pas de manière simple d’identifier les interactions des composants individuels. Les défauts ou les problèmes sont difficiles à repérer. Par principe, chaque composant non-redondant critique pour le fonctionnement devrait être traité comme un single point of failure.

Prenez le corps humain, par exemple. Nous ne disposons que d’un seul cœur ou d’un seul cerveau ; les organes vitaux n’ont pas été conçus en plusieurs exemplaires. Si l’un de ces organes défaille, le corps dans son ensemble défaille. Le cœur et le cerveau sont des SPOF. Par contraste, les yeux, les oreilles, les poumons, et les reins existent en double. Si nécessaire, le corps compense la défaillance de l’un d’eux et continue à fonctionner avec une efficacité réduite.

Au sein d’un centre de données, tous les composants critiques pour le fonctionnement constituent des SPOF potentiels. Par conséquent, les serveurs sont en général équipés de connexions redondantes au réseau électrique. Le stockage de masse est fourni de manière redondante via des RAIDs ou des technologies similaires. Le but étant de garantir le fait que le système continue à fonctionner même si un seul composant critique fait défaut.

Il existe de nombreux types de single points of failures. Après tout, les SPOF affectent bien plus que les systèmes d’information. Jetons un œil à quelques exemples.

Dans la célèbre saga « Star Wars », un point de défaillance unique conduit à la destruction de la terrible « Étoile de la Mort ». L’unique missile à proton tiré par le héros atteint un point critique au sein du réacteur. L’explosion provoque une réaction en chaîne dévastatrice qui réduit l’Étoile de la Mort à néant.

En 2021, le porte-conteneurs « Ever Given » s’est retrouvé coincé dans le Canal de Suez. Le bateau s’est échoué à hauteur d’une section critique du canal qui se trouvait être la seule voie d’eau accessible à cet endroit. Le blocage a paralysé le trafic maritime le long du canal entier. Le single point of failure, dans ce cas, était la voie d’eau non redondante.

En 2018 et 2019, deux crashs aériens du « Boeing 737 MAX » ont eu lieu, ce qui a causé la perte de centaines de vies. La cause de ces crashs était un capteur unique qui envoyait des données erronées. Le système de pilotage automatique n’a pas fonctionné correctement, puisqu’il se basait sur les données du capteur, et a finalement conduit les avions à leur perte. Plusieurs erreurs y ont concouru, mais le point de défaillance unique était le capteur.

Même les systèmes conçus pour la haute disponibilité ne sont pas parfaitement protégés contre les SPOF. Ces dernières années, certains services de Cloud majeurs ont rencontré, à plusieurs reprises, de graves défaillances. La plupart du temps, le point de défaillance unique était humain. Les mauvaises données de configuration peuvent vite paralyser un système de production entier, même si ses composants sont conçus de manière redondante.

Votre appareil est connecté au Wi-Fi, mais le navigateur Web ne fonctionne pas. Puis l’horloge commence à régler le temps automatiquement. Ça vous dit quelque chose ? À ce stade, on peut déjà commencer à s’arracher les cheveux, mais l’explication est simple :

Le slogan « C’est toujours le DNS » peut faire sourire, mais il décrit sérieusement le potentiel d’erreur du DNS (Domain Name System). Après tout, lorsque les serveurs DNS ne répondent pas, les sites Internet et les services peuvent défaillir de plusieurs manières différentes. L’effet est le même que si on vous coupait la connexion Internet. Néanmoins, le trafic de paquets entre les adresses IP fonctionne toujours dans ce cas.

En général, les erreurs DNS se produisent côté utilisateur si les serveurs DNS stockés dans le système ne sont pas accessibles. Une bonne pratique consiste donc à stocker deux adresses de noms de serveurs. Si le premier serveur est indisponible, le second est utilisé. Ceci crée de la redondance et résout le point de défaillance unique.

Souvent, les deux serveurs DNS appartiennent à la même organisation. Si l’un d’eux échoue, il y a une forte probabilité pour que l’autre soit également affecté. Pour être tranquille, vous pouvez stocker les adresses de deux noms de serveurs issus de différentes organisations. On retrouve la combinaison populaire 1.1.1.1 et 9.9.9.9 de Cloudflare et Quad9, respectivement serveurs DNS primaire et secondaire.

Fin 2021, un grand nombre de services Web basés sur Java furent affectés par la vulnérabilité Log4Shell. Le single point of failure était une bibliothèque de journalisation intitulée Log4J. Le cas le plus grave eut lieu lorsqu’une attaque système conduisit à la prise de contrôle d’un système vulnérable dans sa totalité.

En général, pour éviter les SPOF, mieux vaut prévenir que guérir. Par définition, un single point of failure conduit un système dans sa totalité à cesser de fonctionner. Une fois que cela arrive, il est en général trop tard. La seule option qu’il vous reste est alors de limiter les dégâts.

C’est la raison pour laquelle les mesures préventives et le fait d’anticiper les urgences constituent une meilleure stratégie. Vous pouvez imaginer des scénarios d’échec crédibles et analyser les risques et les mesures de protection possibles. Différents types de points uniques de défaillance peuvent être évités par certaines fonctionnalités d’un système :

Les systèmes critiques bien préparés sont soumis à une supervision en continu pour détecter les erreurs le plus tôt possible et les corriger si nécessaire.

L’une des recommandations visant à contrecarrer les SPOF est de construire des redondances. Plusieurs instances d’un composant critique (par ex., l’alimentation en électricité, la connexion réseau, le serveur DNS) fonctionnent en parallèle. Si l’un deux fait défaut, le système continue à fonctionner sans perte de performance.

La redondance évite également de nombreux SPOF côté logiciel. On peut, par exemple, citer l’opposition entre microservices populaires d’un côté et logiciel monolithique de l’autre. Un système composé de microservices est découplé et moins complexe, ce qui le rend plus robuste contre les SPOF. Étant donné que les microservices sont lancés en tant que conteneurs, cela facilite la construction de redondances.

Mais de quelle manière la redondance protège-t-elle un système exactement ? Utilisons l’estimation de fiabilité d’un système, aussi connue sous le nom de « Loi de Lusser » pour l’illustrer. Voici un exemple de réflexion :

Considérons qu’un système dispose de deux connexions indépendantes et parallèles à une source d’électricité. Considérons également que la probabilité que la connexion échoue dans un laps donné est de 1%. Dès lors, la probabilité d’une défaillance complète du raccordement à l’électricité peut être calculée en tant que produit des deux probabilités :

1. Probabilité d’échec d’une instance :

1% = 1 / 100 = 1 / 10 ^ 2 = 0.01

1. Probabilité que deux instances fassent défaut l’une après l’autre :

1% * 1% = (1 / 10 ^ 2) ^ 2 = 1 / 10 ^ 4 = 0.0001

Comme vous pouvez le voir, la probabilité qu’un SPOF ait lieu n’est pas divisée par deux lorsque deux instances sont exécutées, mais réduite de deux puissances de 10. Il s’agit d’une amélioration considérable. Si trois instances sont exécutées en parallèle, une défaillance du système dans son ensemble devrait être quasi-impossible.

Malheureusement, la redondance n’est pas la panacée. On peut plutôt dire qu’elle protège un système contre les SPOF dans les limites de certaines hypothèses. Pour commencer, la probabilité qu’une instance fasse défaut doit être indépendante de la probabilité de défaillance de l’instance ou des instances redondantes. Ce n’est pas le cas lorsque l’échec est dû à un événement extérieur. Si un data center prend feu, les composants redondants échoueront ensemble.

Outre la redondance des composants déployés, la répartition de certains composants est critique pour atténuer les SPOF. La répartition géographique du stockage des données et des infrastructures informatiques protège de toute catastrophe naturelle. De plus, viser une certaine hétérogénéité ou diversité des composants critique d’un système s’avère souvent payant. La diversité réduit la probabilité que des instances redondantes fassent défaut.

Illustrons l’avantage de la diversité à l’aide de l’exemple de la cybersécurité. Imaginez un centre de données avec des répartiteurs de charge redondants conçus exactement sur le même modèle. Une vulnérabilité de sécurité dans l’un des répartiteurs de charge se présentera également dans les instances redondantes. Dans le pire des cas, une attaque paralysera toutes les instances. En utilisant différents modèles, le système dans son ensemble aura de meilleures chances de continuer à fonctionner à un niveau de performance réduit.

La redondance ne suffit pas toujours à éviter les SPOF. Et certains composants ne peuvent être élaborés de manière redondante. Lorsque l’option de créer de la redondance n’est pas disponible, d’autres stratégies peuvent être adoptées.

L’approche « défense en profondeur » est bien connue en cybersécurité. Celle-ci implique de tracer plusieurs cercles de protections indépendants autour d’un système. Ces derniers devront subir des brèches les uns après les autres avant que le système ne finisse par s’effondrer. Les probabilités qu’un système complet s’effondre à cause d’un seul composant s’en trouvent réduites.

En ce qui concerne les systèmes digitaux, il existe des langages de programmation dotés d’une tolérance aux pannes intégrée. L’exemple le plus connu est le langage « Erlang » développé à la fin des années 1980. Accompagné de l’environnement d’exécution associé, ce langage convient à la création de systèmes hautement disponibles et tolérants aux pannes.

Le triomphe du World Wide Web à l’échelle mondiale et la diffusion du développement Web ont fait émerger un nouveau défi. Les programmeurs ont été forcés de développer des sites Internet qui fonctionneraient sur un grand nombre d’appareils. L’approche de base utilisée dans ce processus est appelée « dégradation gracieuse ». Si un navigateur ou un appareil n’est pas compatible avec une technologie en particulier sur une page, celle-ci est rendue aussi bien que possible malgré tout. Il s’agit d’une approche de « panne douce » :

N’attendez pas que le système s’effondre pour identifier tout point de défaillance unique au sein de votre système. Vous devrez procéder de manière proactive dans le cadre d’une stratégie de gestion des risques. On utilisera des analyses tirées de l’ingénierie de la fiabilité telles que des arbres de défaillance et d’événements. Des analyses des modes de défaillance, de leurs effets et de leur criticité (AMDEC) seront menées pour identifier les sources de défaillance les plus critiques.

L’approche générale pour identifier les single points of failure dans l’informatique d’entreprise est de mener une estimation des risques des trois principales dimensions :

• Matérielle
• Logicielle / services / fournisseur
• Personnelle

Commencez par créer une check-list d’analyse SPOF pour exposer les domaines généraux nécessitant une analyse plus poussée. Puis, une analyse SPOF détaillée des domaines individuels sera effectuée :

• Les appareils non supervisés au sein du réseau
• Les systèmes logiciels ou matériels non-redondants
• Les employés et prestataires ne pouvant être remplacés en cas d’urgence
• Toutes données non incluses dans des sauvegardes

Pour chaque composant du système, l’effet négatif d’une défaillance est analysé. De plus, la probabilité approximative d’un échec catastrophique est estimée. Les résultats sont incorporés dans un plan global de « récupération en cas de désastre » pour assurer la sécurité du centre de données.

À titre de mesure de base pour éviter les SPOF, la redondance du stockage de données et des capacités informatiques devrait être assurée à trois niveaux :

• Au niveau serveur à travers des composants matériels redondants
• Au niveau du système à travers le clustering, càd l’utilisation de plusieurs serveurs
• Au niveau du centre de données en utilisant des sites d’exploitation répartis géographiquement