Infrastructure
HA : High Availability, en français haute disponibilité. « Doubler ce qui ne doit pas tomber, en espérant que les deux ne tomberont pas ensemble », par analogie avec la ceinture et les bretelles, dispositif infaillible tant qu'on ne les attache pas au même bouton.
Principe : Plusieurs membres (serveurs, pare-feu, HSM…) forment un groupe : en mode actif-passif, un membre prend le relais quand l'autre tombe ; en mode actif-actif, tous servent en même temps et se répartissent la charge. L'objectif est mesuré par un taux de disponibilité, souvent inscrit dans un SLA.
Pour les HSM : Les membres d'un groupe HA partagent les mêmes clés, répliquées de façon chiffrée entre modules. Chaque membre doit donc être aussi protégé que le meilleur d'entre eux, et une mise à jour doit rester compatible entre versions, sans quoi la réplication échoue au moment précis où l'on comptait sur elle.
Ce que la HA ne couvre pas : Elle protège contre la panne d'un membre, pas contre l'erreur répliquée : une clé supprimée ou une configuration corrompue se propage fidèlement à tous les membres. Elle ne remplace ni les sauvegardes ni le PRA (plan de reprise d'activité), qui traitent la perte du site entier.
Ce qui arrive si on s'en passe
Une haute disponibilité jamais testée découvre ses défauts pendant la panne réelle : bascule qui ne se déclenche pas, membre de secours désynchronisé, versions incompatibles après une mise à jour partielle. Le service tombe alors malgré le matériel doublé, et parfois les deux membres se croient actifs et écrivent chacun de leur côté, ce qui corrompt les données plus sûrement qu'une panne franche. Les clés ou secrets répliqués sur un membre moins bien protégé ouvrent en outre une seconde porte d'entrée, que l'attaquant choisira évidemment.
Explication de la marmotte
La haute disponibilité consiste à installer plusieurs exemplaires d'un équipement important pour qu'un service continue de fonctionner si l'un d'eux tombe en panne. Les exemplaires se surveillent mutuellement et se partagent les informations nécessaires. Pour que cela marche le jour où l'on en a besoin, il faut régulièrement tester la bascule d'un exemplaire à l'autre.
Où ce terme est utilisé
- Vulnérabilités documentées des HSM certifiés (6 occurrences)
- Attestation matérielle HSM des clés générées (3 occurrences)
- Continuité, sauvegardes, PRA/PCA et haute disponibilité (3 occurrences)
- Migrer un fournisseur HSM sans interruption (3 occurrences)
- MSTP : spanning tree multiple pour réseaux industriels en anneau (3 occurrences)
- Comment détruire une clé pour effacer des données chiffrées (2 occurrences)
- Comment isoler les clés dans un HSM multi-tenant (2 occurrences)
- Dimensionner un cluster HSM à forte charge transactionnelle (2 occurrences)
- Dimensionner un HSM pour la migration post-quantique (2 occurrences)
- HSM cloud ou on-premise pour les clés critiques (2 occurrences)
