Continuité — survivre quand tout le reste a échoué¶

La prévention, la détection et la réponse peuvent toutes échouer. Ce qui reste, alors, c'est de pouvoir repartir. La question de cette page n'est donc pas « la sauvegarde a-t-elle tourné ? » mais « pourrai-je repartir, et en combien de temps ? » — deux questions qui n'ont pas la même réponse.

Les termes techniques renvoient au glossaire.

Quatre niveaux de sauvegarde¶

flowchart LR
    classDef src fill:#3f3f46,stroke:#3f3f46,color:#fff
    classDef bk fill:#1e40af,stroke:#1e40af,color:#fff
    classDef off fill:#0f766e,stroke:#0f766e,color:#fff

    subgraph hotes["Hôtes du parc"]
        h["Hôtes de conteneurs · machines virtuelles<br/>hôte GPU · serveur hors site"]:::src
    end

    cli["Client de sauvegarde par hôte<br/>restic · chiffré AVANT l'envoi"]:::bk
    rest["Serveur de dépôt, sur le NAS<br/>ajout seul : aucune suppression<br/>depuis les hôtes"]:::bk
    snap["Instantanés du NAS"]:::bk
    rep["Réplication hors site"]:::off
    o1["Fournisseur hors site n° 1"]:::off
    o2["Fournisseur hors site n° 2"]:::off
    git["Configuration et décisions<br/>git, deux dépôts distants"]:::off

    h --> cli --> rest
    rest --> snap
    snap --> rep
    rep --> o1
    rep --> o2
    h --> git

Niveau	Contre quoi il protège
1 · Dépôt chiffré par hôte	La perte d'un hôte, une suppression, une corruption applicative
2 · Instantanés du NAS	Une erreur humaine sur le stockage, une corruption du dépôt lui-même
3 · Deux copies hors site, chez deux fournisseurs distincts	La perte du site entier — sinistre, vol, rançongiciel qui atteint le NAS
4 · git sur deux dépôts distants	La perte de la configuration, des fichiers de composition, des décisions

Le chiffrement est fait par le client, avant l'envoi : aucun des serveurs de sauvegarde ne détient les clés des données qu'il garde. Chaque hôte a son client, son dépôt et son plan de rétention ; la vérification d'intégrité des dépôts est planifiée.

L'immuabilité — la question du rançongiciel¶

Un rançongiciel moderne ne se contente pas de chiffrer les données : il cherche les sauvegardes, avec les accès qu'il trouve sur la machine compromise. La question qui compte est donc :

Celui qui prend un hôte peut-il aussi détruire ses sauvegardes ?

La propriété visée s'appelle l'immuabilité : une sauvegarde qu'on ne peut ni modifier ni supprimer depuis l'hôte sauvegardé.

Le serveur de dépôt fonctionne en ajout seul. Un client peut écrire de nouveaux instantanés ; il ne peut ni en supprimer ni en réécrire. La purge des anciens instantanés se fait d'ailleurs, avec d'autres accès.
Hors site, l'immuabilité est portée par le fournisseur lui-même — un verrouillage d'objet, ou des instantanés que les accès de réplication ne peuvent pas atteindre.

Comment on le vérifie : en essayant

L'immuabilité ne se lit pas dans une configuration. Elle se constate : avec les accès dont dispose réellement l'hôte, on tente une suppression, et on attend un refus. Une sonde refait ce geste régulièrement. Une réponse positive — la suppression a réussi — est un échec du contrôle, pas une réussite du test.

Pourquoi « fraîche » ne suffit pas

Les surveillances de fraîcheur répondent à « la sauvegarde a-t-elle tourné ? ». Un rançongiciel produit des sauvegardes fraîches — d'un contenu chiffré, à l'heure, sans une seule erreur. Seules l'immuabilité et un exercice de restauration daté répondent à « pourrai-je repartir ? ».

Restaurer pour de vrai — l'exercice chronométré¶

Une sauvegarde qu'on n'a jamais restaurée est une hypothèse. L'exercice de restauration la transforme en mesure :

choisir un stack représentatif — une base de données, des fichiers, un cache ;
créer une machine virtuelle neuve et jetable, qui n'a jamais vu le stack ;
restaurer depuis les sauvegardes seules, sans rien copier de la machine d'origine ;
chronométrer jusqu'à ce que l'API de l'application réponde normalement ;
relever l'âge des données retrouvées ;
détruire la machine.

Le premier exercice a donné un RTO de l'ordre de trois minutes, et un RPO d'environ une journée — près de deux dans le pire cas, selon le moment de la panne par rapport à la dernière sauvegarde. Ce sont des chiffres mesurés, pas des objectifs recopiés d'un plan.

Chaque exercice est consigné dans un registre. Une sonde passe au rouge si le dernier date de plus de 90 jours : une restauration éprouvée il y a un an ne dit rien des sauvegardes d'aujourd'hui.

Le RTO mesuré est un plancher, pas celui d'un sinistre

Les variables d'environnement d'un stack ne sont jamais écrites en clair : elles sont chiffrées dans le dépôt, et déchiffrées en mémoire au démarrage. Restaurées depuis la sauvegarde, elles reviennent donc sous forme d'un lien vers un fichier qui n'existe plus.

Restaurer un stack exige par conséquent deux choses de plus que la sauvegarde : le coffre de secrets, et la clé qui déchiffre. L'exercice a été mené avec la clé disponible. Son chiffre vaut pour un incident ordinaire ; il ne vaut pas pour un sinistre où la clé aurait disparu avec le reste. D'où la section suivante.

La clé maîtresse — le seul scénario de perte totale¶

Tous les secrets des stacks sont chiffrés pour une seule clé age. Perdre sa partie privée, c'est perdre tous les secrets — y compris dans l'historique git, où les versions chiffrées restent pour toujours et deviennent illisibles pour toujours.

Et la dépendance est circulaire : le coffre de secrets est lui-même un stack du parc. Récupérer la clé depuis un coffre qu'on ne peut plus démarrer faute de clé est une boucle fermée.

La réponse est une copie hors ligne : sur papier, conservée hors du parc, sans aucun lien réseau.

Une copie jamais relue ne vaut pas mieux qu'une absence de copie. Mais relire une clé privée, c'est l'exposer. Le kit de vérification résout les deux :

un secret de test, chiffré pour la clé maîtresse et versionné ;
un script qui lit la clé sur l'entrée standard — jamais en argument, jamais à l'écran, jamais dans un fichier — tente de déchiffrer le secret de test, et rend pass ou fail ;
éprouvé dans les deux sens : une clé fausse rend fail, la vraie rend pass, y compris saisie à la main depuis le papier.

L'exercice complet se fait sur un système démarré depuis une clé USB, réseau coupé, depuis la feuille elle-même. Il est attesté, daté, et l'attestation expire : une sonde le rappelle quand elle manque.

Ce que ces choix ont en commun¶

Tester la propriété, pas la configuration. L'immuabilité se constate en tentant de supprimer ; la restauration se constate en restaurant.
Chiffrer au plus près de la donnée. Le client chiffre ; les serveurs gardent des octets qu'ils ne savent pas lire.
Chercher les dépendances circulaires avant le sinistre. La clé dans le coffre, le coffre dans le parc, le parc derrière la clé : c'est le genre de boucle qu'on ne découvre qu'en essayant de repartir de rien.