Chapitre 37. Maintenance, mises à jour et cycle de vie

Objectifs pédagogiques¶

Organiser la veille et décider si un avis concerne l'installation. Définir une politique de version et lire des notes de version pour ce qui compte. Conduire la mise à jour d'un cluster avec son plan de retour. Établir le calendrier consolidé des rotations. Articuler les revues périodiques en un calendrier unique. Décommissionner un objet, un moteur ou un cluster entier.

Prérequis¶

Chapitre 25 (la mise à jour glissante, dont ce chapitre reprend la mécanique), chapitre 6 (la rotation du keyring), chapitre 21 (le rekey), chapitres 17 à 19 et 28 (les objets qui tournent), chapitre 33 (la sauvegarde préalable).

Cours¶

37.1 La veille¶

Un logiciel de sécurité non tenu à jour finit par devenir le maillon faible du système qu'il protège, et le délai entre la publication d'un avis et son exploitation se compte désormais en jours.

La veille s'organise autour de trois sources et d'un rythme. Les notes de version, qui annoncent fonctionnalités, dépréciations et corrections. Les avis de sécurité, publiés par l'éditeur et repris par les bases publiques. Et les canaux d'écosystème : listes de diffusion, dépôts des plugins tiers utilisés, dépendances du système d'exploitation. Le rythme : une lecture hebdomadaire de trente minutes, plus un mécanisme de notification pour les avis critiques, qui n'attendent pas la revue.

La question difficile n'est pas de recevoir l'information, c'est de décider si elle nous concerne. Quatre filtres, dans cet ordre.

La version : l'avis vise-t-il une plage qui inclut la nôtre ? L'édition : plusieurs avis ne concernent qu'une édition. La fonctionnalité : une faille dans un moteur que l'installation n'active pas ne présente pas le même risque, ce qui suppose de connaître exactement ce qui est monté. Les conditions d'exploitation : certaines vulnérabilités exigent une authentification préalable, une configuration particulière ou un accès réseau que l'architecture ne donne pas.

Le résultat s'inscrit en une ligne au registre : concerné ou non, avec la justification, parce que la décision de ne pas agir doit être aussi tracée que la décision d'agir.

37.2 La politique de version¶

Une politique de version évite deux erreurs symétriques : courir après chaque publication, et prendre trois ans de retard. Celle d'Astrea tient en quatre règles.

Rester dans la plage supportée, c'est-à-dire dans les versions qui reçoivent encore des correctifs de sécurité : en sortir, c'est décider de ne plus être corrigé, ce qui se signe. L'éditeur désigne certaines versions comme bénéficiant d'un support étendu, ce qui allonge cette plage et espace les migrations obligatoires ; l'offre relève de l'édition Enterprise, et une organisation qui la souscrit calera sa politique dessus plutôt que sur le rythme des versions mineures. Ne pas installer une version le jour de sa parution en production, sauf faille exploitée : deux à six semaines de recul permettent aux problèmes de jeunesse d'apparaître chez d'autres. Ne pas accumuler plus de deux versions mineures de retard, parce que le coût d'une mise à jour croît plus vite que le nombre de versions sautées. Et traiter les correctifs de sécurité selon leur gravité et leur exploitabilité dans notre contexte.

La lecture des notes de version se concentre sur quatre points, le reste étant du confort : les changements de format de stockage, qui décident de la réversibilité ; les dépréciations et suppressions, qui cassent des configurations existantes ; les changements de comportement par défaut, la catégorie la plus traîtresse parce qu'elle ne produit aucune erreur ; et les étapes obligatoires entre certaines versions, qui interdisent un saut direct.

37.3 Mettre à jour un cluster¶

Le chapitre 25 a donné la valse : standbys d'abord, un nœud à la fois, santé constatée entre chaque, step-down puis l'actif en dernier. Trois éléments s'y ajoutent, qui relèvent de la politique plutôt que de la manœuvre.

La préproduction d'abord, quand elle existe : même version, même procédure, quelques jours d'observation. Astrea ne dispose pas d'un cluster de préproduction complet et utilise le cluster jetable des exercices de reprise, ce qui donne une couverture partielle, honnêtement consignée comme telle.

La sauvegarde préalable, prise et vérifiée juste avant le premier nœud. Elle sert de filet, et sa valeur dépend d'une contrainte qu'il faut énoncer clairement : une montée de version n'est en général pas réversible par un simple retour au binaire précédent. Les versions récentes peuvent migrer des formats internes, et un nœud rétrogradé se retrouve devant des données qu'il ne comprend pas. Le retour arrière réel passe par la restauration d'un snapshot antérieur sur une installation à l'ancienne version : une procédure lourde, qui explique pourquoi la fenêtre se prépare et pourquoi la lecture des notes précède tout.

L'ordre des composants, enfin : le gardien de seal se met à jour hors de la fenêtre du core, jamais en même temps, et les agents ou proxys applicatifs suivent le serveur plutôt qu'ils ne le précèdent.

37.4 Le calendrier des rotations¶

Le cursus a introduit des rotations dans une dizaine de chapitres, chacune avec sa logique. Les rassembler en un tableau unique est l'apport principal de ce chapitre : c'est ce document qui empêche qu'un objet tourne pendant trois ans et un autre jamais.

Objet	Mécanisme	Rythme retenu	Qui	Renvoi
Clés du keyring	`operator rotate`	Annuel, ou sur soupçon	Opérateur	ch. 6
Recovery keys du core	`rekey -target=recovery`	Départ d'un porteur, soupçon, revue annuelle	Cérémonie	ch. 21, 22
Parts du gardien	rekey	Idem	Cérémonie	ch. 21, 23
Tokens de seal des nœuds	Nouveau token, révocation de l'ancien	Trimestriel	Opérateur	ch. 23, 26
Certificats des nœuds	Émission interne, rechargement	Automatique à sept jours de l'échéance	Minuteur	ch. 28
Certificats de services	Émission interne	Automatique, durée courte	Agent	ch. 17, 40
Intermédiaire PKI	Multi-issuer, bascule sans coupure	À mi-vie	Opérateur	ch. 17
Racine PKI	Cross-signing, puis redistribution	Jamais, sauf compromission ou fin de validité	Cérémonie	ch. 17
Clé Transit applicative	`rotate`, `rewrap`, `min_decryption_version`	Trimestriel	Tâche et opérateur	ch. 16
Clé d'enveloppe du seal	Rotation possible, plancher jamais relevé	Sur événement uniquement	Opérateur	ch. 23
Compte racine des moteurs	`rotate-root`	Semestriel et sur soupçon	Opérateur	ch. 18, 19
Comptes statiques gérés	`rotation_period` ou `rotation_schedule`	Quotidien, automatique	Vault	ch. 19
`secret_id` d'AppRole	Réémission enveloppée	À chaque déploiement	CI	ch. 13
Clé de sauvegarde	Nouvelle paire, ancienne conservée	Annuel	Cérémonie	ch. 33
Secrets statiques restants	Rotation manuelle	Selon l'échéance en métadonnée	Propriétaire	ch. 9, 15

Certaines lignes réservent des pièges.

La clé de sauvegarde ne se remplace pas comme les autres : les snapshots déjà produits restent chiffrés par l'ancienne clé, dont la partie privée doit être conservée jusqu'à l'expiration de la rétention. Une rotation qui détruirait l'ancienne clé rendrait illisibles toutes les sauvegardes antérieures.

Le compte racine des moteurs exige la vérification préalable du compte de secours hors Vault, la rotation étant irréversible pour l'opérateur.

Et la clé d'enveloppe du seal obéit à une règle propre : son plancher de déchiffrement ne se relève jamais, sous peine de rendre indéchiffrable l'enveloppe de la clé racine.

Chaque exécution s'inscrit au registre. Le tableau lui-même se relit une fois l'an : un rythme qui n'a jamais été tenu n'est pas un rythme, c'est une intention, et mieux vaut l'ajuster que de le laisser mentir.

37.5 Le calendrier des revues¶

Le cursus a semé une quinzaine de revues, chacune utile et aucune tenable si elle est isolée. Le chapitre 36 en a donné le rythme d'exploitation ; voici la vue de gouvernance, celle qui s'affiche dans le plan annuel.

Au trimestre : la revue KV avec ses propriétaires, échéances et orphelins ; la revue anti-dérive du réel contre le dossier, refus testés ; un exercice sur table d'incident ; la rotation des tokens de seal.

Chaque année : la vérification des porteurs de parts, cérémonie de régénération à blanc comprise ; l'exercice de reprise complet sur le scénario du site ; la révision du modèle de menaces ; la relecture du dossier d'architecture et de ses risques résiduels signés ; la revue du tableau de rotations.

Une revue se solde par des lignes de registre et, quand elle produit des écarts, par des tickets avec propriétaire et date. Une revue sans trace n'a pas eu lieu, et c'est ce que l'auditeur vérifiera en premier.

37.6 Décommissionner¶

La fin de vie se prépare aussi mal que le reste quand personne ne l'a écrite. Trois échelles, trois procédures.

Un objet, secret, rôle ou policy : suppression selon le cycle de son moteur, révocation de ce qui en dépendait, retrait du dépôt versionné, ligne de registre. Le piège habituel est la policy orpheline, qui survit à l'application qu'elle servait et finit par être réutilisée par facilité.

Un moteur ou une méthode d'authentification : inventaire des dépendances, policies, clients et baux vivants ; révocation des baux du préfixe ; désactivation du montage en sachant qu'elle détruit sa vue de stockage ; mise à jour de la matrice de flux si des flux sortants disparaissent. La désactivation d'une méthode d'authentification révoque les tokens qu'elle avait émis, ce qui se planifie plutôt que de se découvrir.

Un cluster entier : la question centrale n'est pas d'éteindre les machines mais de décider du sort des copies. Snapshots dans le dépôt et hors site, disques des nœuds, sauvegarde du gardien, parts, clé de sauvegarde : chacun est une porte vers les secrets d'hier. La procédure consiste à établir l'inventaire par époque, à décider pour chaque élément entre conservation sous garde et destruction attestée, à exécuter, et à consigner.

Les secrets eux-mêmes ne disparaissent pas parce que Vault s'arrête : ceux qui restent en usage doivent être migrés ou tournés, faute de quoi l'organisation retrouve exactement l'état des lieux du chapitre 1, avec des valeurs qui traînent et plus aucun inventaire.

Exemple : l'avis publié un vendredi soir¶

Un avis de sécurité paraît en fin de journée : une vulnérabilité dans le traitement d'un moteur de secrets, corrigée dans la version parue le jour même, exploitable par un client authentifié disposant de droits limités.

Le tri. La procédure de veille se déroule comme prévue, et c'est son intérêt : personne n'improvise. Filtre version, l'installation est concernée. Filtre édition, la vulnérabilité touche les deux. Filtre fonctionnalité, le moteur en cause est monté. Filtre conditions, l'exploitation exige un token valide avec des droits sur ce moteur : la population concernée est celle des applications authentifiées, ce qui écarte l'attaquant externe mais pas le premier scénario du chapitre 31, où un token applicatif volé permettait précisément d'atteindre ce périmètre.

La décision est prise en trente-cinq minutes par l'astreinte avec le décideur : fenêtre d'urgence le lendemain matin plutôt qu'attente du cycle normal, sur le critère écrit dans la politique, à savoir une vulnérabilité exploitable dans notre configuration avec un privilège que nous accordons réellement.

L'exécution. Snapshot pris et vérifié. Notes de version lues à deux, avec attention aux quatre points : aucune migration de format, une dépréciation sans effet ici, un comportement par défaut modifié sur un paramètre que l'installation fixe explicitement. L'équipe note au passage qu'elle a eu de la chance et que la préproduction complète reste une dette. Mise à jour des deux standbys, contrôle de santé entre chaque, cession de la main, actif en dernier. Une heure vingt, aucune interruption perceptible, une bascule volontaire au compteur.

Deux enseignements. La décision a pris trente-cinq minutes parce que la politique de version, écrite six mois plus tôt, contenait déjà le critère ; sans elle, la discussion aurait duré la soirée et probablement abouti à attendre lundi. Et l'inventaire des montages a servi à quelque chose de concret pour la première fois : le filtre fonctionnalité ne se répond pas de mémoire un vendredi soir.

Sécurité : l'entretien comme surface¶

Le retard de version est une décision, pas un état. Chaque mois passé hors de la plage supportée s'accepte explicitement, comme un risque résiduel, avec son critère de révision. L'inertie n'est pas une politique.

La fenêtre de maintenance se réserve. La règle du chapitre 25 vaut ici comme politique : on ne met pas à jour pendant un incident, ni en même temps qu'une autre manœuvre risquée, parce que le nœud arrêté a déjà consommé la tolérance de panne.

Les rotations non tenues créent une illusion de sécurité. Un tableau affiché et jamais exécuté vaut moins qu'un tableau plus modeste et respecté, parce qu'il fait croire à des protections inexistantes.

Le décommissionnement laisse des portes. Snapshots, disques, parts, clés de sauvegarde : ce qui n'est pas détruit de façon attestée reste une copie du coffre d'hier, ouvrable par le matériel de son époque.

Erreurs fréquentes¶

Recevoir les avis sans procédure de tri. Tout devient urgent, donc plus rien ne l'est. Les quatre filtres produisent une décision tracée, y compris celle de ne pas agir (section 37.1).

Sauter plusieurs versions mineures. Le coût croît plus vite que le nombre de versions, et les étapes obligatoires se découvrent en pleine fenêtre (section 37.2).

Croire au retour arrière par simple bascule de binaire. Les migrations de format rendent la rétrogradation impossible (section 37.3).

Mettre à jour le gardien et le core dans la même fenêtre. L'un doit être stable quand l'autre bouge, sous peine de perdre à la fois le service et la capacité à le redémarrer (section 37.3).

Tourner ce qui est facile et oublier ce qui compte. Les certificats tournent tout seuls, les comptes racines des moteurs dorment depuis deux ans (section 37.4).

Détruire l'ancienne clé de sauvegarde en la remplaçant. Tous les snapshots antérieurs deviennent illisibles au moment même où l'on croyait améliorer la sécurité (section 37.4).

Éteindre un cluster sans traiter ses copies. Machines arrêtées, dossier clos, et des snapshots dans un dépôt que plus personne ne surveille (section 37.6).

Mise en pratique : tenir dans la durée¶

Sur papier ; réponses commentées en fin de partie.

Rédigez la fiche de décision pour un avis de sécurité : informations à collecter, les quatre filtres avec leur source, les trois niveaux de réponse possibles et leur critère de déclenchement.
Établissez le calendrier de rotation d'une année civile, mois par mois, en répartissant les charges pour éviter les collisions et en indiquant qui doit être disponible pour chaque opération.
Le service migre vers une autre solution dans six mois. Rédigez le plan de décommissionnement : ordre des opérations, sort de chaque copie, traitement des secrets encore en usage, et les deux points qui exigent une décision de direction.

Questions de compréhension¶

Quelles sont les trois sources de la veille et les quatre filtres qui décident si un avis nous concerne ?
Pourquoi la décision de ne pas agir doit-elle être tracée au même titre que la décision d'agir ?
Énoncez les quatre règles de la politique de version et les quatre points à chercher dans des notes de version.
Qu'est-ce qui rend une montée de version difficilement réversible, et en quoi cela change-t-il le plan de retour ?
Pourquoi le gardien et le core ne se mettent-ils pas à jour dans la même fenêtre ?
Citez six lignes du tableau des rotations avec leur rythme, et expliquez le piège de la clé de sauvegarde.
Pourquoi le plancher de déchiffrement de la clé d'enveloppe ne se relève-t-il jamais ?
Que contient le calendrier annuel des revues, et à quoi se reconnaît une revue qui a réellement eu lieu ?
Décrivez les trois échelles de décommissionnement et le piège propre à chacune.

Synthèse¶

Tenir un Vault dans la durée demande trois disciplines. La veille : trois sources, un rythme hebdomadaire, quatre filtres qui décident si un avis nous concerne, et une trace même lorsque la décision est de ne rien faire. La politique de version, qui évite de courir après chaque publication comme de sortir de la plage supportée, et qui oriente la lecture des notes vers ce qui compte ; la mise à jour reprend la valse du chapitre 25, augmentée d'une sauvegarde préalable et de la conscience qu'une montée de version ne se défait pas par simple retour de binaire. Le calendrier des rotations, enfin, rassemble en un tableau ce que quinze chapitres avaient dispersé, avec ses pièges propres. S'y ajoutent le calendrier des revues et la fin de vie, dont le vrai sujet n'est pas d'éteindre des machines mais de décider du sort des copies.