Aller au contenu

AWS Mis à jour le 2026-07-04

Faire tourner et éliminer les clés d'accès IAM : trouver chaque endroit où une clé se cache

Comment faire tourner les clés d'accès IAM sans panne — et comment trouver d'abord chaque endroit où une clé se cache : secrets de CI, fichiers .env, conteneurs, tâches cron et outils tiers.

Faire tourner une clé d’accès IAM sans risque, c’est une danse en cinq temps — créer la deuxième clé, la déployer partout où vit l’ancienne, confirmer que l’ancienne est devenue silencieuse, la désactiver, puis la supprimer — et tout le risque tient dans le mot « partout ». Le côté AWS prend des minutes; trouver chaque fichier .env, secret de CI, image de conteneur et tâche cron oubliée qui détient l’ancienne clé, c’est le vrai travail. Mieux encore : la plupart des clés peuvent être éliminées plutôt que tournées, parce qu’un rôle peut habituellement prendre la place que la clé occupe aujourd’hui.

Ce qui se passe

Un utilisateur IAM peut détenir deux clés d’accès à la fois, ce qui existe précisément pour rendre possible la rotation sans interruption : les deux clés fonctionnent simultanément pendant l’échange. Les clés n’expirent pas — une clé créée en 2019 authentifie encore aujourd’hui si personne n’agit — la rotation est donc une pure discipline opérationnelle, et le standard de 90 jours de l’industrie existe parce que les clés fuitées sont typiquement exploitées en quelques heures, pas en quelques mois.

Ce qui rend la rotation risquée, c’est qu’AWS ne peut pas vous dire où une clé est entreposée, seulement d’où elle a servi pour la dernière fois. get-access-key-last-used révèle le service et la région du dernier appel, et CloudTrail enregistre l’IP source de chaque requête — ce sont vos outils de traçage. Les cachettes sont d’une constance déprimante d’un environnement à l’autre : portables de développeurs (~/.aws/credentials), historique de dépôts (un .env commité une fois en 2021 puis « retiré » est encore dans l’historique Git), coffres de secrets CI/CD, images de conteneurs qui ont cuit des identifiants au build, variables d’environnement Lambda, tâches cron et scripts de sauvegarde sur site, intégrations SaaS tierces (outils de surveillance, fournisseurs de sauvegarde, expéditeurs de courriel avec identifiants SMTP SES) et systèmes de gestion de configuration. Chacun de ces endroits est un lieu d’où l’ancienne clé continue de fonctionner jusqu’à ce que vous le trouviez — ou cesse de fonctionner, bruyamment, en production, quand vous désactivez la clé sans l’avoir trouvé.

Quoi vérifier en premier

  • Le rapport d’identifiants — un seul CSV avec chaque utilisateur, l’âge des clés et la date de dernier usage; les clés inutilisées depuis 90 jours et plus peuvent être désactivées immédiatement avec un risque presque nul.
  • D’où la clé appelle. Les IP sources dans CloudTrail vous disent si l’usage vient de votre VPC, de votre bureau, des plages d’un fournisseur de CI, ou d’un endroit que vous ne pouvez pas nommer.
  • Si la charge de travail pourrait utiliser un rôle à la place. Si l’appelant roule sur EC2, ECS, Lambda ou une plateforme de CI majeure, l’élimination bat la rotation — voir notre guide des profils d’instance.
  • L’historique Git. git log -p -S AKIA à travers vos dépôts trouve les clés commitées puis « supprimées » — ces clés sont brûlées et doivent tourner de toute façon.

Comment vérifier

# Inventaire complet : chaque utilisateur, âge des clés, dernier usage
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > creds.csv

# Où et quand cette clé précise a-t-elle servi pour la dernière fois?
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

# Depuis quelles IP la clé appelle-t-elle? (événements de gestion)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --max-results 50 \
  --query 'Events[].CloudTrailEvent' --output text | grep -o '"sourceIPAddress":"[^"]*"' | sort | uniq -c

Chemin console : IAM > Users > (user) > Security credentials montre les deux emplacements de clés, leur âge et le dernier usage. Notez que les données de dernier usage couvrent la plupart mais pas la totalité des appels de services AWS, et que l’historique d’événements CloudTrail conserve 90 jours d’événements de gestion — les appels du plan de données comme s3:GetObject demandent les événements de données activés pour être tracés.

Le runbook

  1. Essayez l’élimination avant la rotation. EC2 reçoit un profil d’instance, ECS un rôle de tâche, Lambda a déjà un rôle d’exécution, GitHub Actions passe à la fédération OIDC. Une clé remplacée par un rôle n’a plus jamais besoin de ce runbook.
  2. Créez la deuxième clé. aws iam create-access-key --user-name svc-backup. Si les deux emplacements sont pleins, la plus vieille clé inactive doit être supprimée d’abord — confirmez qu’elle est réellement morte avant de le faire.
  3. Déployez la nouvelle clé à chaque endroit de votre inventaire. Mettez à jour le coffre de secrets de CI, le fichier d’identifiants du serveur, le secret de l’application dans Secrets Manager ou Parameter Store (voir notre comparaison des deux) — et notez chaque endroit en le touchant; cette liste est l’actif dont hérite la prochaine rotation.
  4. Regardez l’ancienne clé devenir silencieuse. Donnez-lui un cycle d’affaires complet — une semaine au minimum, un mois si des traitements mensuels existent — en surveillant get-access-key-last-used.
  5. Désactivez, puis attendez encore. aws iam update-access-key --user-name svc-backup --access-key-id AKIA... --status Inactive. La désactivation se renverse en secondes; la suppression, non. Tout ce qui casse maintenant identifie un endroit que votre inventaire a manqué.
  6. Supprimez. aws iam delete-access-key --user-name svc-backup --access-key-id AKIA... une fois que le silence a tenu à travers la désactivation.

Quand ce n’est pas la bonne approche

Si la clé est présentement exposée — commitée dans un dépôt public, collée dans un billet, signalée par AWS ou GuardDuty — ne faites pas la danse gracieuse. Désactivez la clé immédiatement, acceptez le bris, passez CloudTrail en revue pour voir ce que la clé a fait, et impliquez le soutien AWS s’il y a des signes d’abus. La rotation gracieuse, c’est pour l’hygiène; l’exposition, c’est un incident.

Erreurs fréquentes

  • Supprimer au lieu de désactiver d’abord — la désactivation est la répétition générale réversible, la suppression est pour toujours.
  • Faire tourner la clé mais pas les identifiants SMTP SES qui en ont été dérivés.
  • Croire « last used: never » sur une fenêtre trop courte — les traitements trimestriels et annuels utilisent des clés aussi.
  • Nettoyer le code courant mais pas l’historique Git; une clé qui a déjà été commitée est compromise jusqu’à sa rotation.

Prévention

  • Alertez sur les événements CreateAccessKey pour que chaque nouvel identifiant à longue durée commence avec un responsable et une date de rotation.
  • Produisez le rapport d’identifiants chaque mois et alertez sur toute clé qui dépasse votre âge maximal.
  • Gardez l’inventaire où-vit-cette-clé à côté de chaque utilisateur restant; il transforme la prochaine rotation d’archéologie en liste de contrôle.
  • Réduisez la population de clés en continu — chaque migration vers des rôles ou l’OIDC retire une rotation du calendrier pour de bon.

Les équipes qui trouvent la rotation pénible sont celles qui repartent de zéro chaque fois; celles qui la trouvent ennuyante tiennent un inventaire et le font rétrécir. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.