Chapitre 38 / 39
Rotation de clés
Un identifiant qui ne change jamais est un identifiant qui finira par fuiter. Pas d’un coup, pas de façon spectaculaire — mais avec le temps, des ordinateurs se perdent, des prestataires passent, des captures d’écran atterrissent dans le mauvais canal. La défense n’est pas « ne jamais fuiter » (impossible) mais « tourner assez souvent pour qu’une fuite ait une courte durée de vie ». Ce chapitre est le manuel de rotation Sodimo : ce qui est renouvelé, quand, et comment.
Statut : Prévu — le calendrier de rotation s’active à la mise en ligne du coffre. Les procédures ci-dessous décrivent la forme que l’équipe adopte dès le premier jour.
Tout ce chapitre suppose que le coffre Vaultwarden (chapitre Le coffre de comptes, spécification complète dans le chapitre Le coffre) existe et est accessible à vault.sodimo.eu. Certaines rotations se font uniquement depuis l’interface Vaultwarden (saisir un nouveau mot de passe pour un SaaS) ; d’autres sont pilotées par Claude Code (renouveler un token API de bout en bout — générer, écrire dans le coffre, mettre à jour le service consommateur, vérifier, révoquer). Les procédures ci-dessous montrent chaque flux tel qu’il se déroule concrètement.
Chaque rotation produit une ligne dans run_ledger avec surface=vault_rotation — de sorte que le tableau de bord (chapitre Le launchpad) peut répondre à la question « quand a-t-on renouvelé X pour la dernière fois ? » sans interroger personne.
Le calendrier de rotation
Ce calendrier est officiel — le même rythme apparaît dans le chapitre Le coffre. Il ne faut pas en dériver. Si un rythme semble inadapté à un identifiant particulier, les deux chapitres sont mis à jour ensemble.
| Quoi | Cadence | Événements déclencheurs (en plus du calendrier) |
|---|---|---|
| Clés SSH (ordinateur personnel → harness) | 90 jours | Ordinateur perdu, volé ou retiré du service ; départ d’un collaborateur. |
| Mots de passe admin (Cloudflare, Google Workspace, organisation GitHub) | 180 jours, TOTP obligatoire | Départ d’un collaborateur avec rôle admin ; suspicion de compromission en amont. |
| Tokens de service (API Cloudflare, clés de déploiement GitHub, API Anthropic, tokens D1, tokens SaaS tiers) | 365 jours, et à chaque départ de collaborateur | Suspicion de fuite ; token visible dans une capture d’écran ou un commit ; service retiré. |
| Token administrateur Vaultwarden | 365 jours | Toute suspicion de compromission. |
| Éléments de secours (enveloppe de récupération papier, combinaison du coffre-fort, clés de récupération LUKS, clés de chiffrement des sauvegardes) | Jamais renouvelé automatiquement | Uniquement sur incident spécifique — la sécurité physique est ce qui protège ces éléments. |
Deux repères aident à retenir le calendrier :
- SSH est la mèche courte (90 jours). Les clés SSH protègent le harness lui-même — la machine qui contient tout le reste — de sorte que l’impact potentiel d’une clé SSH compromise, c’est l’ensemble du système. La cadence de 90 jours n’est pas de la paranoïa ; elle est proportionnée à ce que la clé déverrouille.
- La rotation annuelle des tokens de service est l’audit forcé. Une fois par an, chaque service d’automatisation se voit réémettre ses identifiants. L’objectif n’est pas seulement « l’ancien token est invalidé » ; c’est l’occasion annuelle de vérifier que chaque service existe encore, qu’il a toujours besoin du token qu’il détient, et que sa portée est toujours raisonnable.
Le départ d’un collaborateur est un déclencheur universel. Quand quelqu’un quitte l’équipe, tous les secrets auxquels il avait accès sont renouvelés dans la même session de travail — sans sélection. Le calendrier est le plancher, pas le plafond.
Comment se déroule la rotation d’un token de service (via Claude Code)
Les tokens de service — API Cloudflare, API Anthropic, D1, clés de déploiement GitHub — se renouvellent de bout en bout via Claude Code, parce que la rotation touche trois systèmes en séquence (l’émetteur, le coffre, le service consommateur). Ouvrez Claude Code :
Rotate the Cloudflare API token used by the ETL service.
Claude Code effectue ce qui suit, en montrant chaque étape :
- Lit les métadonnées du token actuel depuis Vaultwarden (quand il a été créé, qui l’utilise, quelle est sa portée).
- Génère un nouveau token dans Cloudflare avec la même portée (via l’API Cloudflare, pas par une connexion humaine).
- Écrit le nouveau token dans Vaultwarden, avec la date du jour et vos initiales dans les champs personnalisés de l’entrée.
- Met à jour le service qui consomme le token — dans ce cas, le service systemd
sodimo-etl— pour référencer la nouvelle entrée. - Redémarre le service.
- Vérifie que la prochaine exécution planifiée de l’ETL réussit avec le nouveau token.
- Révoque l’ancien token dans Cloudflare.
- Marque l’ancienne entrée Vaultwarden comme « révoqué YYYY-MM-DD » dans un champ de note plutôt que de la supprimer, afin que la piste d’audit subsiste.
- Écrit une ligne dans
run_ledgeravecsurface=vault_rotationet le nom court de l’identifiant renouvelé.
La séquence complète prend cinq minutes pour un identifiant bien délimité. Vous la regardez se dérouler ; Claude Code vous guide à chaque étape ; vous approuvez chaque action irréversible (écriture dans le coffre, révocation de l’ancien token) avant qu’elle n’ait lieu.
Comment se déroule la rotation d’un mot de passe admin (via l’interface Vaultwarden)
Les mots de passe admin des consoles SaaS — Cloudflare, Google Workspace, organisation GitHub, le registrar — se renouvellent directement dans l’interface du fournisseur et dans Vaultwarden. Pas besoin de Claude Code ; le navigateur est le seul outil.
- Ouvrez
vault.sodimo.eu, connectez-vous, trouvez l’entrée (par exemple « Cloudflare — admin »). - Ouvrez la console du fournisseur dans un autre onglet, accédez au flux de changement de mot de passe, générez un nouveau mot de passe (le générateur intégré de Vaultwarden convient ; 20 caractères ou plus, classes mixtes).
- Finalisez le changement chez le fournisseur. Re-authentifiez-vous avec le TOTP si demandé.
- Collez le nouveau mot de passe dans l’entrée Vaultwarden, enregistrez.
- Déconnectez-vous et reconnectez-vous chez le fournisseur pour confirmer que le nouveau mot de passe fonctionne.
- L’entrée Vaultwarden enregistre automatiquement l’événement de changement dans son historique.
Cinq minutes dans le navigateur, pas de terminal. C’est la forme que Paul ou Rani peut réaliser sans que Thomas soit en ligne.
Rotation des clés SSH (90 jours)
Les clés SSH se renouvellent tous les 90 jours parce qu’elles protègent le harness. Voir le chapitre compagnon (Les bases de SSH) pour la création depuis zéro — cette section suppose que vous avez déjà une clé dans Vaultwarden et que vous l’effectuez en rotation.
Ouvrez Claude Code :
Rotate my SSH key for the Framework Desktop.
La séquence :
- Claude Code génère une nouvelle paire de clés Ed25519 sur votre ordinateur (pas sur le serveur, jamais sur le serveur).
- La nouvelle clé publique est ajoutée au fichier
authorized_keysdu harness — ajoutée, pas remplacée, pour ne pas être bloqué si quelque chose tourne mal. - Testez SSH avec la nouvelle clé :
ssh harness.sodimo.eu— cela doit réussir sans invite de mot de passe. - Une fois la nouvelle clé vérifiée, l’ancienne clé publique est supprimée d’
authorized_keys. - La nouvelle clé privée est téléversée dans Vaultwarden (collection : clés SSH privées) ; l’ancienne entrée est marquée révoquée plutôt que supprimée.
- Une ligne
run_ledgeravecsurface=vault_rotationenregistre la rotation.
Si l’étape 3 échoue — la nouvelle clé n’a pas été prise en compte — l’ancienne clé est toujours sur le serveur, donc l’accès reste intact. Corrigez le problème (cause habituelle : la clé publique n’a pas été copiée correctement) et recommencez. Rien n’est destructif tant que l’ancienne clé n’a pas été supprimée.
Planifiez la prochaine rotation 90 jours plus tard. Vaultwarden affiche également l’âge de l’entrée dans l’interface, de sorte qu’un coup d’œil à la collection SSH indique quelles clés sont à renouveler.
Quand renouveler maintenant, hors calendrier
Quatre situations priment sur le calendrier et exigent une rotation immédiate :
- Un identifiant est visible quelque part de public. Un token dans une capture d’écran partagée sur WhatsApp, dans un commit git, dans un ticket de support. Même si le destinataire est de confiance, l’identifiant est compromis.
- Un ordinateur est perdu ou volé. Toutes les clés sur cet ordinateur sont compromises à partir de ce moment.
- Un collaborateur quitte l’entreprise. Tous les identifiants auxquels il avait accès sont renouvelés dans la même journée de travail.
- Activité inhabituelle. Un pic de facturation sur le compte Anthropic, un déploiement inattendu, un service qui frappe Cloudflare depuis une IP que personne ne reconnaît. Renouveler d’abord, enquêter ensuite.
Aucune de ces situations n’est rare. Prévoyez une rotation tous les deux mois environ, en dehors du calendrier, rien qu’à partir de la réalité opérationnelle.
Ce que la rotation ne répare pas
La rotation limite la durée de vie d’une fuite — elle n’annule pas la fuite. Si un token a fuité et a été utilisé de manière malveillante avant que vous ne le remarquiez, la rotation n’efface pas les appels malveillants. La réponse à une fuite confirmée est :
- Renouveler, immédiatement. (Ce chapitre.)
- Auditer les journaux du système que le token a atteint. Cloudflare dispose d’un journal d’audit ; D1 a des journaux de requêtes ; Anthropic a des journaux de requêtes. Chercher toute activité non reconnue.
- Contacter Thomas (pendant l’engagement) ou le responsable de permanence (après la passation). Ils décideront si l’audit justifie une réponse supplémentaire.
La rotation est la première étape de la réponse, pas la réponse entière.
La procédure de sortie (passation de Thomas)
À la fin de l’engagement, une session de rotation complète a lieu en une seule fois. Chaque identifiant que Thomas a jamais détenu est soit renouvelé vers un identifiant propriété de Sodimo, soit révoqué. La procédure se trouve dans le chapitre Le coffre — ce chapitre y renvoie pour qu’aucun collaborateur ne pense qu’elle est facultative.
La règle : le jour où Thomas remet le harness, aucun identifiant émis par Thomas ou connu de Thomas n’a d’accès actif à quoi que ce soit chez Sodimo. Le coffre a la même forme, l’outillage est le même, seules les clés ont changé.