Aller au contenu

AWS Mis à jour le 2026-07-04

Rôles IAM vs utilisateurs : quand chacun est le bon choix (et pourquoi les clés d'accès devraient être rares)

Rôles IAM vs utilisateurs, c'est réglé pour les charges de travail — les rôles gagnent. La vraie décision porte sur les humains et sur la poignée de cas où un utilisateur avec clés d'accès mérite encore sa place.

Pour tout ce qui roule à l’intérieur d’AWS — EC2, Lambda, ECS, CodeBuild — la réponse est un rôle, point final : les rôles émettent automatiquement des identifiants à courte durée de vie et il n’y a rien à fuiter, à faire tourner ou à oublier. Pour les humains, la réponse moderne est une session IAM Identity Center, pas un utilisateur IAM. Les utilisateurs IAM avec clés d’accès à longue durée sont l’option héritée, défendable seulement dans un ensemble de cas limites qui rétrécit, et chaque cadre d’audit traite maintenant chacun d’eux comme un constat à justifier.

Ce que vous décidez

La décision porte en réalité sur la durée de vie des identifiants. Un utilisateur IAM porte un mot de passe et jusqu’à deux clés d’accès qui vivent jusqu’à ce que quelqu’un les supprime — souvent des années, selon le rapport d’identifiants de presque n’importe quel compte mature. Un rôle n’a aucun identifiant propre; un principal de confiance l’assume et reçoit des identifiants STS qui expirent après une heure par défaut (jusqu’au maximum configuré sur le rôle). Tout le reste découle de cette différence : les clés finissent dans l’historique Git, les portables et les journaux de CI, tandis que les sessions de rôle expirent avant que la plupart des fuites soient exploitables, et chaque session dans CloudTrail porte un nom de session qui dit qui l’a assumée.

Le choix pratique ressemble donc à ceci. Charges de travail dans AWS : toujours un rôle — profils d’instance sur EC2 (le patron complet, incluant l’application d’IMDSv2, est dans notre guide des profils d’instance), rôles d’exécution sur Lambda et ECS. Charges de travail hors AWS : encore habituellement un rôle, atteint par une porte de fédération — GitHub Actions et GitLab s’authentifient en OIDC pour assumer un rôle, les serveurs sur site peuvent utiliser IAM Roles Anywhere avec des certificats X.509. Humains : Identity Center ou votre IdP existant fédéré vers des rôles. Ce qui reste aux utilisateurs IAM avec clés est réellement mince : un outil tiers qui n’accepte que des clés AWS statiques, des identifiants SMTP hérités pour SES dans des montages plus vieux, et des comptes transitoires en pleine migration. La documentation IAM elle-même éloigne maintenant chacun de ces publics des identifiants à long terme.

Quoi vérifier en premier

  • Comptez vos utilisateurs IAM. aws iam list-users — chaque entrée a besoin d’une histoire : humain (devrait être dans le SSO), machine (devrait être un rôle), ou exception documentée.
  • Comptez les clés d’accès et leur âge. Les clés de plus de 90 jours encore utilisées marquent les endroits où la migration va faire mal; les clés inutilisées depuis 90 jours peuvent simplement être retirées.
  • Vérifiez l’accès console. Les utilisateurs avec mot de passe sont des humains qui s’authentifient à l’ancienne.
  • Cherchez les utilisateurs partagés. Un utilisateur nommé deploy ou admin utilisé par plusieurs personnes veut dire que CloudTrail ne peut pas attribuer les actions — le pire des deux mondes.

Comment vérifier

# Chaque utilisateur, chaque clé, dernier usage — le portrait complet
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d > report.csv

# Âge et statut des clés par utilisateur
aws iam list-access-keys --user-name deploy-user

# Quand une clé a-t-elle servi pour la dernière fois, et pour quel service?
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

Chemin console : IAM > Users, tri par « Last activity », et IAM > Credential report pour le CSV. Un utilisateur dont password_last_used et les deux colonnes de dernier usage des clés sont vides ou anciennes est un candidat à la suppression, pas un débat.

L’approche

  1. Gelez d’abord le patron. Décidez, et écrivez, que les nouvelles charges de travail reçoivent des rôles et les nouveaux humains du SSO. Arrêter les nouveaux utilisateurs ne coûte rien et garde le ménage fini.
  2. Migrez les charges de travail dans AWS vers des rôles. Attachez profils d’instance, rôles de tâche et rôles d’exécution; supprimez les clés une fois que le dernier usage confirme le silence. C’est le lot au meilleur rendement pour le moins de friction.
  3. Migrez le CI/CD vers la fédération OIDC. GitHub Actions, GitLab et Bitbucket assument tous des rôles via OpenID Connect; le secret AWS entreposé disparaît complètement du coffre de CI.
  4. Migrez les humains vers Identity Center. Les ensembles de permissions remplacent les politiques par utilisateur, et le MFA s’applique à la source d’identité au lieu de contorsions de politiques.
  5. Documentez les survivants. Chaque utilisateur restant reçoit un responsable, une raison, un calendrier de rotation et une politique étroitement délimitée — une exception nommée, pas un restant.

Quand ce n’est pas la bonne approche

Ne supprimez pas une clé dès que le dernier usage montre une activité que vous ne pouvez pas situer — cette activité est une dépendance de production que vous n’avez pas encore trouvée; désactivez, attendez, écoutez. Et une migration forcée le jour même d’une intégration tierce critique qui ne supporte que des clés statiques échange un risque théorique contre une panne réelle : planifiez-la avec le fournisseur, et faites tourner la clé sur un calendrier d’ici là.

Erreurs fréquentes

  • Créer un utilisateur IAM « juste pour ce script » qui roule sur EC2 — le profil d’instance a toujours été la réponse.
  • Partager un utilisateur entre membres d’équipe, ce qui détruit l’attribution dans CloudTrail.
  • Traiter la rotation comme le remède pour des clés qui ne devraient pas exister — la rotation est le filet pour les exceptions, pas la stratégie.
  • Oublier l’utilisateur racine dans l’audit : le compte racine devrait avoir le MFA, aucune clé d’accès, et presque zéro connexion.

Garder le contrôle

  • Alertez sur les événements CreateAccessKey et CreateUser via CloudTrail pour que tout nouvel identifiant à longue durée soit une conversation, pas une surprise.
  • Produisez le rapport d’identifiants chaque mois; faites tendre le compte d’utilisateurs vers votre liste d’exceptions documentées.
  • Mettez en place une SCP ou une politique permanente refusant la création de clés pour les humains console-seulement quand c’est faisable.
  • Revérifiez les outils des fournisseurs chaque année — les intégrations qui exigeaient des clés statiques gagnent souvent le support des rôles.

La question rôle-vs-utilisateur est l’une des rares d’AWS avec une réponse nette, ce qui fait de l’étalement de clés persistant un problème de prise en charge plutôt qu’un problème 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.