La clé EIM qui est morte un samedi

Samedi, 03h14. PagerDuty vous réveille. La production tourne, mais le pipeline de backup nocturne a planté à minuit. Vous vous connectez, regardez les logs :

OperationNotPermitted: invalid access key id

La clé EIM utilisée par votre automation de backup a expiré à 00h00. Personne ne le savait. Personne ne pouvait le savoir — Outscale n'envoie pas d'email d'avertissement, n'affiche pas de bannière, n'affiche rien. La clé arrête de marcher, point.

C'est le problème de l'expiration silencieuse, et tous les comptes Outscale l'ont.

Comment se comportent vraiment les clés EIM

Chaque compte Outscale a des utilisateurs EIM (anciennement IAM), chacun avec une ou plusieurs paires de clés d'accès. Ces clés, c'est ce qu'utilisent votre CLI, Terraform, vos DAGs Airflow, vos agents de monitoring, et tout ce qui n'est pas humain pour parler à l'API.

Outscale fait expirer les clés. La durée de vie par défaut dépend de la configuration du compte mais c'est généralement 90 jours. Après quoi la clé est rejetée — pas d'avertissement, pas d'email, rien de visible dans la console Cockpit sauf si vous allez chercher. Vous avez entre cinq et cinquante clés selon la maturité de votre plateforme. Chacune expire à une date différente.

Ce qui casse quand une clé expire

Les dégâts dépendent du niveau d'attention que reçoit la chose :

• Usage CLI interactif — vous voyez tout de suite. Cinq minutes perdues.
• Pipelines CI/CD — le prochain déploiement plante. Vous voyez en quelques heures. Une matinée.
• Automation planifiée (backups, snapshots, scaling) — plante en silence. Vous voyez quand quelque chose en aval casse. Plusieurs jours.
• Ingestion de données de coût — les dashboards arrêtent de se mettre à jour mais s'affichent toujours. Vous voyez le lundi matin. Une semaine.
• Collecte de preuves de conformité — vous le découvrez quand l'auditeur demande où sont les 30 derniers jours de logs.

Le pattern : plus l'automation est critique, plus longtemps il faut pour s'apercevoir qu'elle est morte. Les choses critiques pour la prod ont tendance à être non surveillées ; les choses non surveillées plantent en silence ; les pannes silencieuses se cumulent.

La règle des 30 jours

La solution est simple sur le principe. Chaque clé du compte déclenche une alerte à T-30 jours avant expiration, un rappel à T-7, et une dernière à T-0 si la clé est encore utilisée.

30 jours, c'est la bonne marge extérieure parce qu'effectuer la rotation d'une clé pour une automation non triviale demande : régénérer, l'injecter dans votre gestionnaire de secrets, redéployer tout ce qui la consommait, vérifier que le bascule a marché, révoquer l'ancienne clé. Un projet d'une semaine dans le meilleur des cas, plus si Bob qui possède le DAG Airflow est en vacances.

7 jours, c'est le mode panique. Si vous n'avez pas commencé, c'est aujourd'hui obligatoire.

T-0, c'est le "est-ce que quelqu'un a vraiment fait quelque chose". Les alertes à T-30 et T-7 ont peut-être été ignorées, perdues dans Slack, ou envoyées à un canal que personne ne regarde. L'alerte du jour J, c'est votre dernière chance.

Par clé, pas par compte

La tentation, c'est d'écrire une seule alerte : "n'importe quelle clé du compte qui expire bientôt". Mauvaise idée. Vous recevez une notification listant cinq clés, dont quatre déjà remplacées la semaine dernière. Vous acquittez, ignorez, et passez à côté de celle qui compte vraiment.

Les alertes par clé sont plus bruyantes mais actionables. Chaque alerte, c'est un item : tournez cette clé spécifique avant cette date. Vous écartez celles qui sont déjà gérées et le dashboard reflète la vérité.

Cadence de rotation : n'attendez pas l'alerte

Le système d'alerte ci-dessus vous protège de l'oubli. Si vous recevez des alertes toutes les semaines, votre cadence est trop serrée. Deux pressions opposées :

• Durées plus courtes réduisent le rayon d'impact si une clé fuite. 90 jours par défaut ; certaines équipes forcent 30.
• Durées plus longues réduisent la charge de rotation. Certaines équipes vont à 180 ou 365 quand leur politique sécurité le permet.

La bonne réponse dépend de ce à quoi la clé a accès. Une clé en lecture seule pour ingérer des données de coût peut vivre plus longtemps qu'une clé avec des droits admin. Une clé utilisée par un runner CI peut tourner toutes les semaines avec de l'automation ; une clé enfouie dans une intégration SaaS tierce probablement ne peut pas du tout sans coordination.

Règle pragmatique : scopez vos clés étroitement pour pouvoir les tourner agressivement. Une clé avec une permission utilisée par un service est bien plus sûre à tourner (et bien moins impactante quand elle expire) que la über-clé que tout le monde utilise.

L'angle audit

Au-delà du fait que ça maintient les choses en marche, l'expiration des clés est un signal de conformité. SOC 2, ISO 27001 et SecNumCloud demandent tous de la rotation d'identifiants. "On tourne nos clés tous les 90 jours parce qu'Outscale nous y oblige" est techniquement une politique, mais une politique faible. "On tourne nos clés tous les 60 jours, alertés à T-30, avec un propriétaire documenté par clé" est nettement plus solide.

Le journal d'audit Vextnd capture chaque création, rotation et révocation de clé, avec l'acteur et la raison. Quand l'auditeur demande "montrez-moi les 6 derniers mois de cycle de vie des identifiants", la réponse est en un clic.

Si vous ne faites qu'une chose

Mettez en place des alertes T-30 sur chaque clé EIM de chaque compte, aujourd'hui. Vous n'avez pas besoin d'automatisation de rotation, ni de gestionnaire de secrets sophistiqué, ni de document de procédure. Juste une alerte qui se déclenche avant que la chose ne meure. Le reste découle de ça.