Aller au contenu

AWS Mis à jour le 2026-07-04

IAM Identity Center (SSO) : sortir les humains des utilisateurs IAM

Comment configurer IAM Identity Center (AWS SSO) et migrer l'accès humain hors des utilisateurs IAM : ensembles de permissions, fournisseurs d'identité externes, aws configure sso, et le runbook de migration qui ne casse personne.

IAM Identity Center (le service anciennement nommé AWS SSO) est la façon dont les humains devraient atteindre AWS aujourd’hui : un seul portail de connexion, des sessions de rôle à courte durée dans chaque compte, le MFA imposé à l’annuaire, et aucune clé d’accès nulle part. Il exige AWS Organizations, fonctionne sans frais additionnels, et remplace les utilisateurs IAM par compte et le chiffrier de mots de passe qui a poussé autour. La migration est sans éclat mais mécanique : monter Identity Center, refléter les accès existants en ensembles de permissions, faire rouler les deux chemins brièvement, puis retirer les utilisateurs IAM.

Ce qui se passe

Identity Center siège au niveau de l’organisation et fait trois choses. Il détient ou connecte la source d’identité — son annuaire intégré, ou mieux, l’annuaire que vous exploitez déjà (Microsoft Entra ID, Google Workspace, Okta) via SAML pour l’authentification et SCIM pour le provisionnement automatique des utilisateurs et des groupes. Il définit des ensembles de permissions — des gabarits réutilisables comme ReadOnly, PowerUser, BillingOnly. Et il gère l’assignation : l’utilisateur ou le groupe X reçoit l’ensemble Y dans le compte Z. En coulisses, chaque assignation se matérialise en un rôle IAM nommé AWSReservedSSO_<permission-set>_<random> dans le compte cible; les connexions frappent des sessions courtes de ces rôles, alors chaque action dans CloudTrail porte l’identité de la personne au lieu d’un utilisateur partagé.

Opérationnellement, ça change trois choses d’un coup. Le vol d’identifiants perd son gain — les sessions expirent en heures (1 à 12, configurable par ensemble de permissions) au lieu de clés qui vivent des années. Le départ d’un employé devient une action à la source d’identité au lieu d’une chasse à travers les comptes. Et l’usage CLI se nettoie : la CLI AWS v2 supporte aws configure sso, qui ouvre une connexion navigateur et met en cache des identifiants rafraîchissables — aucun secret n’atterrit dans ~/.aws/credentials. Deux contraintes à planifier : Identity Center exige une organisation (l’instance au niveau de l’organisation est celle que vous voulez; les instances de compte existent pour des cas applicatifs étroits mais ne font pas l’accès multi-comptes), et il se déploie dans une région d’attache à choisir délibérément. Les détails de configuration sont dans la documentation d’Identity Center.

Quoi vérifier en premier

  • Le statut d’Organizations. Pas d’organisation veut dire qu’on la crée d’abord; si vous utilisez déjà Control Tower, Identity Center est présent — notre article sur Control Tower couvre ce chemin.
  • Où les identités devraient vivre. Si Entra ID, Google Workspace ou Okta existe déjà, connectez-le; un deuxième îlot d’identités dans l’annuaire intégré est un dernier recours.
  • La population humaine actuelle. Rapport d’identifiants par compte : qui a un mot de passe console, qui a des clés, quelles clés sont des humains-en-CLI versus de la vraie automatisation.
  • L’outillage qui suppose des clés statiques. Les vieilles installations CLI v1 et les scripts qui lisent ~/.aws/credentials directement doivent passer aux profils SSO.

Comment vérifier

# Une instance Identity Center est-elle en place?
aws sso-admin list-instances

# Configurer un profil CLI contre le portail (interactif, CLI v2)
aws configure sso

# Après connexion : prouver que vous détenez une session de rôle frappée par le SSO
aws sts get-caller-identity
# attendu : arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_PowerUser_ab12cd34/jsmith

Chemin console : IAM Identity Center > Settings montre la source d’identité et la configuration MFA; IAM Identity Center > Permission sets liste les gabarits; les rôles par compte apparaissent sous IAM > Roles avec le préfixe AWSReservedSSO_. Un test de connexion par l’URL du portail d’accès plus un get-caller-identity en CLI prouve toute la chaîne.

Le runbook

  1. Activez Identity Center dans le compte de gestion, dans une région d’attache choisie délibérément. Activez-le depuis la console; l’instance d’organisation couvre tous les comptes.
  2. Connectez la vraie source d’identité. Configurez SAML avec Entra ID / Google Workspace / Okta et activez le provisionnement SCIM pour que les arrivées et départs se synchronisent automatiquement. Annuaire intégré? Réglez le MFA à obligatoire à la première connexion et l’invite en permanence.
  3. Créez des ensembles de permissions qui reflètent l’accès d’aujourd’hui — ni mieux, ni pire. Le jour de la migration est le mauvais jour pour redessiner les permissions; partez des politiques gérées AWS comme ReadOnlyAccess et PowerUserAccess, réglez la durée de session (4 heures est un défaut interactif sain), et raffinez plus tard.
  4. Assignez des groupes, pas des individus, aux comptes. L’assignation par groupe est ce qui garde 30 personnes fois 12 comptes gérable.
  5. Faites rouler la période parallèle. Annoncez le portail, aidez tout le monde à configurer aws configure sso, et regardez l’activité des utilisateurs IAM tomber dans le rapport d’identifiants. Deux à quatre semaines est typique.
  6. Retirez les utilisateurs IAM par étapes. Désactivez les mots de passe console d’abord, désactivez les clés d’accès humaines ensuite, supprimez les utilisateurs après un mois tranquille. Gardez un utilisateur IAM bris-de-glace documenté ou comptez sur racine-avec-MFA selon votre politique — jamais zéro chemin d’urgence, sinon une panne de la source d’identité barre tout le monde dehors.

Quand ce n’est pas la bonne approche

Un seul compte autonome avec deux personnes dedans peut défendablement rester sur des utilisateurs IAM avec MFA et sans clés — la cérémonie d’Organizations plus Identity Center rapporte peu là, jusqu’à ce que la croissance arrive. Et les charges de travail ne migrent jamais vers Identity Center : les services continuent d’utiliser des rôles (profils d’instance, rôles de tâche, fédération OIDC); Identity Center est pour les humains seulement.

Erreurs fréquentes

  • Créer des utilisateurs à la main dans l’annuaire intégré quand un IdP d’entreprise existe — le départ d’un employé exige alors de se souvenir de deux systèmes.
  • Assigner des ensembles de permissions à des individus plutôt qu’à des groupes, recréant l’étalement par personne un étage plus haut.
  • Supprimer tous les utilisateurs IAM sans chemin bris-de-glace, transformant une panne d’IdP en verrouillage AWS.
  • Laisser de vieilles clés d’accès actives « temporairement » après la mise en service du portail — la migration n’est pas finie tant que le rapport d’identifiants ne le dit pas.

Garder le contrôle

  • Passez les assignations en revue chaque trimestre : groupes contre comptes contre ensembles de permissions, avec la même rigueur que des règles de pare-feu.
  • Gardez les ensembles de permissions dans l’infrastructure-en-code pour que les changements d’accès soient des pull requests, pas des clics de console.
  • Alertez sur toute création d’utilisateur IAM après la migration; le bon rythme en régime permanent est zéro.
  • Surveillez la dérive des durées de session — des sessions de 12 heures partout rebâtissent en douce le problème des identifiants longs que vous venez de quitter.

Déplacer les humains vers Identity Center est le projet IAM au meilleur rendement que la plupart des organisations ont sous la main : une migration, et des classes entières de constats — utilisateurs périmés, mots de passe partagés, clés humaines jamais tournées — cessent d’exister. 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.