Redondance réseau : ce qui tient vraiment le jour où ça tombe

La disponibilité est une composante de la sécurité, au même titre que la confidentialité. L’article 32 du RGPD l’impose explicitement, et l’article 21 de NIS 2 place la continuité parmi les mesures exigées.

Pourtant, la plupart des architectures dites redondantes comportent des points de défaillance uniques que personne n’a identifiés — jusqu’au jour où ils tombent.

La redondance en trompe-l’œil

Voici les cas que nous retrouvons le plus souvent en audit.

Deux liens, un seul opérateur. Deux accès Internet chez le même fournisseur, empruntant le même point de présence. Une panne de l’opérateur emporte les deux.

Deux chemins, une seule gaine. Deux fibres qui sortent du bâtiment par le même fourreau. Une pelleteuse suffit.

Deux équipements, une seule alimentation. Deux pare-feux en grappe branchés sur le même onduleur, ou sur la même arrivée électrique.

Deux serveurs, un seul hyperviseur. Redondance applicative parfaite, machines virtuelles hébergées sur le même hôte physique.

Deux sites, un seul cœur. Deux salles séparées dont le trafic converge vers un unique équipement d’interconnexion.

Le point commun : la redondance a été pensée au niveau du composant, pas de la chaîne. Or c’est la chaîne complète qui rend le service.

La méthode : remonter la chaîne

Prenez un service critique et suivez son chemin de bout en bout : poste utilisateur, réseau local, distribution, cœur, pare-feu, serveur, hyperviseur, stockage, alimentation, climatisation, lien opérateur.

À chaque étape, une seule question : si ce composant tombe, le service continue-t-il ? Et si la réponse est oui, deuxième question : la bascule est-elle automatique, et a-t-elle été testée ?

Cet exercice prend une demi-journée par service. Il révèle systématiquement deux ou trois points de défaillance que personne n’avait vus, souvent dans les couches basses — électricité, climatisation, câblage — que les équipes réseau ne regardent pas.

Le problème de la bascule

Une redondance non testée est une hypothèse. Trois défaillances classiques :

La bascule ne se déclenche pas. Configuration incomplète, licence manquante sur le nœud secondaire, mécanisme de détection mal réglé.

Elle se déclenche mais le secondaire n’est pas à jour. Configuration divergente, règles de filtrage ajoutées sur le primaire seulement, certificat expiré sur le secondaire. C’est le cas le plus fréquent, et il découle directement de l’absence de gestion de configuration.

Elle se déclenche à tort. Un mécanisme trop sensible provoque des bascules intempestives, parfois des allers-retours qui dégradent plus qu’une panne franche.

Le test doit donc porter sur la bascule réelle — débrancher, éteindre — pas sur une simulation logicielle. Et il doit être répété après chaque changement significatif.

Ce que la redondance ne couvre pas

C’est le point que les architectures les plus soignées manquent.

L’erreur de configuration. Une règle erronée poussée simultanément sur les deux équipements d’une grappe provoque une double panne. La redondance protège contre la défaillance matérielle, pas contre l’erreur humaine propagée.

La parade n’est pas technique : c’est une procédure de changement avec validation, fenêtre, et surtout retour arrière testé.

La compromission. Un attaquant qui obtient les droits d’administration contrôle les deux nœuds. La redondance ne protège de rien — c’est le cloisonnement des comptes à privilèges qui joue ce rôle.

Le rançongiciel. Deux copies synchrones sont deux copies chiffrées. Seule une sauvegarde hors de portée protège. Confondre haute disponibilité et sauvegarde est l’une des confusions les plus coûteuses du domaine.

Dimensionner par le besoin, pas par principe

Tout redonder coûte cher et n’a pas de sens. Le dimensionnement se déduit du bilan d’impact sur l’activité — voir PCA, PRA et gestion de crise.

Une question simple par service : combien de temps peut-on tenir sans lui, et que coûte chaque heure d’arrêt ?

Un service dont l’indisponibilité coûte peu et qui peut attendre une journée n’a pas besoin d’une redondance active. Un service dont l’arrêt bloque la production justifie un investissement bien supérieur.

Cette hiérarchisation évite le travers inverse, tout aussi fréquent : redonder ce qui est facile à redonder plutôt que ce qui compte.

Les dépendances externes

Deux points souvent oubliés dans les architectures modernes.

La résolution de noms. Si votre résolution DNS repose sur un point unique, son indisponibilité rend tout inaccessible, même si l’infrastructure fonctionne.

L’authentification. Une architecture parfaitement redondée dont le service d’authentification est unique s’arrête quand celui-ci tombe. C’est aujourd’hui l’un des points de défaillance les plus critiques, et l’un des moins traités.

Ajoutons les dépendances contractuelles : un service hébergé chez un prestataire dépend de sa disponibilité, ce qui relève de la gestion des fournisseurs et, pour le secteur financier, des exigences de DORA sur les prestataires critiques.

Les sept vérifications

1. Les deux liens opérateurs empruntent-ils réellement des chemins physiques distincts ?
2. Les équipements redondés sont-ils sur des alimentations séparées ?
3. Les machines virtuelles d’un même service sont-elles sur des hôtes différents ?
4. La configuration du nœud secondaire est-elle identique et à jour ?
5. Quand la bascule a-t-elle été testée en conditions réelles, et combien de temps a-t-elle pris ?
6. Le service d’authentification et la résolution de noms sont-ils redondés ?
7. Une erreur de configuration peut-elle être propagée simultanément aux deux nœuds ?

La cinquième et la septième sont celles qui mettent le plus souvent en difficulté.

Sources

• ISO 22301:2019 — continuité d’activité, exercices et tests
• ISO/IEC 27002:2022, mesures 5.30, 7.11, 8.6 et 8.14
• Règlement (UE) 2016/679 (RGPD), article 32
• Directive (UE) 2022/2555 (NIS 2), article 21

Aller plus loin

La conception et la revue de ces architectures relèvent de nos missions de sécurité réseau. Le dimensionnement par le besoin métier se traite en gouvernance et continuité.