Aller au contenu

AWS Mis à jour le 2026-10-03

L'audit de sécurité IAM sur AWS : vieilles clés, utilisateurs surprivilégiés et les constats qui se répètent partout

Un audit de sécurité IAM sur AWS vérifie quelles personnes et quels programmes peuvent agir dans votre compte AWS, et s'ils ont encore besoin de cet accès. Menez-le vous-même dans un ordre qui fait ressortir d'abord les vieilles clés d'accès, les droits d'administrateur superflus et l'usage risqué de l'utilisateur racine.

Si vous gérez un compte AWS en service depuis quelques années, un audit de sécurité IAM est le moyen le plus rapide de repérer les accès qui ne devraient plus exister. IAM, pour Identity and Access Management (gestion des identités et des accès), est le service AWS qui détermine quelles personnes et quels programmes peuvent faire quoi dans votre compte. Avec le temps, des accès oubliés s’y accumulent. Les clés d’accès, ces identifiants permanents qu’utilisent les scripts et les outils, restent des années sans être remplacées. Certaines appartiennent à des gens partis depuis longtemps. Des utilisateurs détiennent AdministratorAccess, la politique intégrée qui autorise tout, parce que c’était plus rapide ce jour-là. Des politiques rédigées pendant un incident contiennent encore "Action": "*", c’est-à-dire n’importe quelle action. Et quelqu’un se connecte encore avec l’utilisateur racine, l’identifiant tout-puissant créé avec le compte, pour le travail courant. IAM fournit déjà les rapports nécessaires, alors l’essentiel du travail consiste à les lire et à agir sur ce qu’ils montrent. Les étapes qui suivent sont classées pour faire ressortir les constats les plus dangereux en premier.

Ce qui se passe

L’étalement IAM est le résultat par défaut du travail normal. Chaque intégration, chaque contractuel, chaque échéance ajoute un utilisateur, une clé ou une politique, et rien ne les retire jamais — supprimer un accès semble risqué et personne ne porte le suivi, alors les droits ne font que croître. Le résultat : un compte dont la surface d’attaque effective est définie par le plus vieux identifiant oublié, pas par le rôle le plus récent et le mieux cadré. Une clé d’accès fuitée d’une copie de portable en 2022 a aujourd’hui le même pouvoir qu’à sa création, et les clés statiques sont exactement ce qui ressort des attaques par bourrage d’identifiants et par balayage de dépôts.

L’audit renverse la logique : au lieu de demander « qui a besoin d’accès? », il demande « quels accès existent, servent-ils, et peut-on le prouver? »

AWS fournit trois sources de données qui rendent la question soluble :

  • le rapport d’identifiants (âge et dernière utilisation des mots de passe et clés de chaque utilisateur).
  • les données de dernier accès par service (quelles permissions un principal a réellement exercées).
  • IAM Access Analyzer (ce qui est joignable de l’extérieur du compte, et — avec l’analyse des accès inutilisés, une fonction payante — quelles permissions restent inexercées).

La référence pour les trois vit dans la documentation IAM.

Quoi vérifier en premier

  • L’hygiène de l’utilisateur racine. MFA activée, aucune clé d’accès sur la racine, et aucune connexion pour le travail courant. Une clé d’accès racine, c’est le constat numéro un, chaque fois.
  • Les clés d’accès de plus de 90 jours, et les clés jamais utilisées. Les deux sortent directement du rapport d’identifiants.
  • Utilisateurs contre rôles. Chaque utilisateur IAM permanent pour un humain est candidat à la retraite au profit du SSO; chaque clé codée dans une instance EC2 devrait être un profil d’instance.
  • Les attachements directs d’AdministratorAccess. Comptez-les; le nombre dépasse habituellement toutes les estimations.
  • Tout ce qui est public ou inter-compte. Constats Access Analyzer pour les compartiments S3, clés KMS, rôles faisant confiance à des comptes inconnus.

Comment vérifier

Commencez par le rapport d’identifiants — une commande donne l’état des identifiants de chaque utilisateur :

aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > cred-report.csv

Ouvrez le CSV et triez par access_key_1_last_rotated et access_key_1_last_used_date. Les clés jamais utilisées, ou inutilisées depuis des mois, forment votre liste de suppression. Le même rapport est dans la console sous IAM > Credential report.

Ensuite, retracez ce que font les clés spécifiques avant d’y toucher :

# À qui appartient cette clé, quand a-t-elle servi, et pour quel service?
aws iam get-access-key-last-used --access-key-id AKIAEXAMPLEKEYID

# Toutes les clés d'un utilisateur
aws iam list-access-keys --user-name legacy-deploy-user

Mesurez le privilège contre l’usage :

# Qu'est-ce que cet utilisateur a réellement touché? (retourne un JobId, puis récupérez-le)
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::111122223333:user/legacy-deploy-user
aws iam get-service-last-accessed-details --job-id <job-id-from-above>

Et vérifiez l’exposition externe via IAM > Access analyzer ou :

aws accessanalyzer list-analyzers
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:ca-central-1:111122223333:analyzer/account-analyzer \
  --filter '{"status":{"eq":["ACTIVE"]}}'

CloudTrail est le compagnon de tout ça — avant de supprimer un identifiant, quatre-vingt-dix jours d’historique CloudTrail disent s’il est vraiment mort ou s’il porte discrètement une charge. Si CloudTrail n’est pas actif, réglez ça d’abord; la base de référence CloudTrail et GuardDuty est le préalable à tout audit.

La marche à suivre

  1. Verrouillez la racine. Activez la MFA, supprimez toute clé d’accès racine, mettez le courriel racine sur une adresse d’entreprise surveillée, et créez une alarme basée sur CloudTrail pour les connexions racine. Rien d’autre sur cette liste ne compte autant.
  2. Supprimez les identifiants morts, désactivez les douteux. Clés jamais utilisées : suppression. Clés inutilisées depuis 90 jours et plus : désactivation (aws iam update-access-key --status Inactive), deux semaines d’attente pour entendre les cris, puis suppression. La désactivation se renverse en quelques secondes, ce qui la rend politiquement facile.
  3. Retirez les humains partis. Croisez la liste d’utilisateurs avec le registre RH. Les partants perdent l’accès console et leurs clés le jour même; ça appartient à la liste de départ pour de bon.
  4. Remplacez les clés codées en dur par des rôles. Les clés dans les instances EC2, les conteneurs ou les variables d’environnement Lambda deviennent des profils d’instance et des rôles d’exécution — le patron et ses pièges sont dans Rôles IAM sur EC2. Les clés dans les configurations SaaS tierces passent sur des utilisateurs minimaux dédiés avec rotation, ou mieux, sur la fédération OIDC quand le fournisseur la supporte.
  5. Réduisez le privilège à l’usage observé. Pour chaque détenteur d’AdministratorAccess, utilisez les données de dernier accès pour rédiger une politique couvrant ce qu’il a réellement utilisé en 90 jours, appliquez-la, et gardez l’admin derrière un rôle bris de glace distinct avec alerte.
  6. Passez les humains au SSO. IAM Identity Center (ou votre fournisseur d’identité fédéré) remplace les utilisateurs permanents par des sessions de courte durée. Nouvelle règle pour la suite : les humains reçoivent le SSO, les machines reçoivent des rôles, et tout nouvel utilisateur IAM exige une justification écrite.
  7. Écrivez les exceptions. Certaines clés statiques survivront à l’audit (surtout de vieilles intégrations de fournisseurs). Listez-les, nommez un responsable, fixez une date de rotation. Une exception avec un responsable est un risque géré; une exception non listée est le constat de l’an prochain.

Quand c’est la mauvaise approche

Si vous soupçonnez une compromission active — un utilisateur admin inconnu, des constats GuardDuty sur les identifiants, des ressources que vous n’avez pas créées — arrêtez l’audit et passez en réponse à incident : tourner les clés une à la fois avertit un attaquant qui en détient peut-être plusieurs. Si le compte doit être remplacé par une nouvelle landing zone dans quelques semaines, investissez l’effort dans un IAM propre à destination plutôt que de polir le compte condamné — mais tuez quand même les clés racine et les utilisateurs partis; c’est du triage, pas de l’audit. Et ne faites pas le ménage en un seul gros lot; supprimer quarante identifiants en un après-midi, c’est comme ça que les audits causent des pannes.

Erreurs courantes

  • Supprimer au lieu de désactiver. La désactivation offre un retour arrière instantané quand la clé « inutilisée » s’avère faire rouler la facturation de fin de mois.
  • Auditer les utilisateurs mais pas les rôles. Les politiques de confiance trop larges — "Principal": {"AWS": "*"} avec une condition faible, ou la confiance envers un compte que personne ne reconnaît — sont plus rares que les vieilles clés, mais bien pires.
  • Croire la description de la clé plutôt que ses données d’usage. La clé étiquetée « temporaire — pour tests » est en production depuis trois ans. Seuls le dernier accès et CloudTrail disent la vérité.
  • Faire l’audit une fois et crier victoire. Les droits repoussent immédiatement; un ménage unique sans cadence récurrente est une photographie, pas un contrôle.

Prévention

  • Mettez le rapport d’identifiants dans une case mensuelle du calendrier avec un responsable nommé; la revue prend quinze minutes quand elle est mensuelle.
  • Alarmez sur l’usage de la racine et sur iam:CreateAccessKey pour les utilisateurs privilégiés.
  • Imposez une politique d’âge des clés mécaniquement (script planifié ou règle Config qui désactive les clés passées 90 jours après avertissement).
  • Exigez le SSO pour les humains et des rôles pour les charges de travail dans vos standards de provisionnement, pour que l’audit cesse de trouver de nouvelles clés statiques.
  • Gardez Access Analyzer actif dans chaque région utilisée et traitez les nouveaux constats d’accès externe comme des billets, pas comme de la décoration de tableau de bord.

L’audit IAM est un travail de deux jours la première fois et une habitude mensuelle de quinze minutes ensuite — la difficulté n’a jamais été technique. 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.