skip to content

Recherche

Syspirit
FR

AWS IAM

Utilisateurs, rôles, policies et Organizations : les permissions AWS expliquées !

AWS
Publié le
Karl Certa

AWS IAM (Identity and Access Management) est le service qui contrôle qui peut s’authentifier sur un compte AWS et quelles actions chaque identité peut effectuer sur quelles ressources.

🧱 Les briques IAM

📌 Élément🎯 Rôle📊 Exemple
👑 Utilisateur rootIdentité créée avec le compte, accès complet à tout, facturation compriseAdresse e-mail du compte
👤 Utilisateur IAMIdentité avec des identifiants longue durée (mot de passe, access keys)Outil tiers qui ne sait pas assumer un rôle
👥 GroupeEnsemble d’utilisateurs IAM qui reçoivent les mêmes policiesAdmins, Ops
🎭 RôleIdentité sans identifiant permanent, assumée à la demande avec des identifiants temporairesApplication sur AWS, compte partenaire
📄 PolicyDocument JSON (JavaScript Object Notation) qui autorise ou refuse des actionsReadOnlyAccess
🧩 PrincipalEntité authentifiée qui émet la requête : root, utilisateur, rôle, service AWSRôle Audit d’un autre compte
  • IAM est un service global : une identité ou une policy s’applique dans toutes les Régions du compte.
  • Un groupe ne contient que des utilisateurs : pas de groupe imbriqué, et un groupe ne peut pas servir de Principal dans une policy, car il porte des permissions sans jamais s’authentifier.
  • Un rôle assumé remplace les droits : pendant la session, l’appelant abandonne ses propres permissions et ne dispose que de celles du rôle.

🤔 Quelle identité pour quel besoin

📌 Besoin🔐 Mécanisme à utiliser💡 Pourquoi
👨‍💻 Humains sur plusieurs comptesIAM Identity Center + permission setsIdentifiants temporaires, gestion centralisée
🖥️ Application qui tourne sur AWSRôle attaché à la ressourceAWS fournit des identifiants temporaires, aucune clé à stocker
🔁 Accès d’un compte AWS à un autreRôle assumé via STS (Security Token Service)Accès court, révocable, tracé
🤝 Prestataire externeRôle cross-account + External IDAucune clé partagée avec le tiers
🗄️ Ouvrir une seule ressource à un autre compteResource-based policy sur la ressourcePas de rôle à assumer
🧰 Outil tiers incompatible avec les rôlesUtilisateur IAM + access keysCas où AWS admet des identifiants longue durée
🚨 Accès d’urgence si le fournisseur d’identité tombeUtilisateur IAM de secours sous MFA (Multi-Factor Authentication)Plan de reprise, identifiants très contrôlés
🧑‍🔧 Laisser une équipe créer ses propres rôlesPermissions boundaryPlafonne les droits que ces rôles peuvent obtenir

👑 Compte root et bonnes pratiques

📌 Règle🧭 Mécanique et conséquence
🔒 MFA sur le rootSecond facteur en plus du mot de passe ; AWS l’exige pour tous les types de comptes, avec 35 jours de grâce après la première connexion
🚫 Aucune access key rootLe root a accès à tout, facturation comprise : une clé qui fuit livre le compte entier
🧑‍💼 Pas de root au quotidienRéservé aux rares tâches qui l’exigent ; un utilisateur administratif fait le reste
📧 Adresse e-mail de groupeSi AWS contacte le propriétaire, la réponse ne dépend pas d’une seule personne
🏢 Comptes membres d’une organisationLes identifiants root (mot de passe, clés, MFA) peuvent être supprimés de façon centralisée
🎯 Moindre privilègeN’accorder que les actions utiles sur les ressources utiles ; partir des policies AWS puis resserrer avec IAM Access Analyzer
🧹 Revue régulièreLes données de dernier accès montrent les utilisateurs, rôles et clés inutilisés à supprimer

📄 Structure d’une policy JSON

📌 Élément🎯 Rôle📊 Valeurs
VersionVersion du langage de policy"2012-10-17"
StatementUne ou plusieurs règlesObjet ou tableau
SidLibellé optionnel de la règle"LectureBucketBureau"
EffectAutoriser ou refuserAllow, Deny
ActionAppels d’API (Application Programming Interface) visés, préfixés par le services3:GetObject, ec2:Describe*
ResourceARN (Amazon Resource Name) des ressources viséesarn:aws:s3:::amzn-s3-demo-bucket/*
ConditionContexte exigé pour que la règle s’appliqueIP (Internet Protocol) source, Région, tag, MFA
PrincipalQui est visé ; uniquement dans une resource-based policy ou une trust policyCompte, rôle, service AWS

Identity-based policy qui autorise la lecture des objets d’un bucket S3 (Simple Storage Service), uniquement depuis une plage d’adresses IP publiques :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "LectureBucketBureau",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*",
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Aucun Principal ici : dans une identity-based policy, le principal est implicitement l’identité qui porte la policy. La clé aws:SourceIp ne fonctionne qu’avec des adresses IP publiques.

🆚 Identity-based vs resource-based

📌 Critère👤 Identity-based policy🗄️ Resource-based policy
S’attache àUtilisateur, groupe ou rôleRessource : bucket S3, clé KMS (Key Management Service), file SQS (Simple Queue Service), rôle
Question poséeQue peut faire cette identité ?Qui peut agir sur cette ressource ?
Champ PrincipalInterditObligatoire
ExemplesAdministratorAccess, policy maisonBucket policy, key policy, trust policy d’un rôle
📌 Type d’identity-based policy🛠️ Géré par🔁 Réutilisable💡 Usage
AWS managedAWS, qui la met à jourOui, non modifiablePoint de départ, souvent trop large
Customer managedVousOui, sur plusieurs identitésCas standard, ajusté au besoin
InlineVousNon, liée à une seule identité et supprimée avec elleRelation stricte un pour un

⚖️ Logique d’évaluation

Règles appliquées à chaque requête dans un même compte. Ordre documenté : deny explicite, RCP (Resource Control Policy), SCP (Service Control Policy), resource-based, identity-based, permissions boundary, session policy.

📌 Règle🧭 Mécanique
🚫 Deny implicite par défautSans Allow applicable, la requête est refusée (seul le root a un accès complet par défaut)
⛔ Deny explicite prioritaireUn seul Deny applicable, dans n’importe quel type de policy, l’emporte sur tous les Allow
🏢 SCP et RCPIl faut un Allow à chaque niveau de l’organisation, sinon refus même avec AdministratorAccess
➕ Identity-based et resource-basedUnion : un Allow dans l’une ou l’autre suffit (sauf trust policy et key policy KMS, qui doivent autoriser explicitement)
✂️ Permissions boundaryIntersection avec les identity-based policies : l’action doit être autorisée des deux côtés
🎫 Session policyFiltre passé lors de l’AssumeRole ; la session ne dépasse jamais les droits du rôle

Requête cross-account : un principal du compte A (trusted) accède à une ressource du compte B (trusting).

📌 Côté évalué🔍 Policies vérifiées📊 Condition
Compte A, d’où part la requêteIdentity-based policy du principal et ce qui la limite (boundary, SCP)Doit donner Allow
Compte B, propriétaire de la ressourceResource-based policy qui nomme le principal de A et ce qui la limite (RCP)Doit donner Allow
Décision finaleLes deux évaluationsAllow seulement si les deux côtés autorisent

🎭 Rôles et STS

📌 Élément🎯 Rôle
Trust policyResource-based policy du rôle : qui a le droit de l’assumer
Permissions policyIdentity-based policy du rôle : ce que la session pourra faire
sts:AssumeRoleRenvoie une access key, une secret key et un token de session temporaires
Service roleRôle qu’un service AWS assume pour agir en votre nom, modifiable par l’admin
Service-linked roleRôle lié à un service et possédé par lui : permissions visibles mais non modifiables
Role chainingAssumer un second rôle avec la session du premier
📌 Durée de session AssumeRole📊 Valeur
Par défaut1 heure (3600 s)
Minimum15 minutes (900 s)
Maximum réglable sur le rôleDe 1 à 12 heures
En role chaining1 heure maximum, quel que soit le réglage du rôle
  • Cross-account par rôle : la trust policy du compte B nomme le compte A, et l’identité de A a besoin d’une policy qui autorise sts:AssumeRole sur l’ARN du rôle.
  • External ID : identifiant fourni par le prestataire et exigé par la condition sts:ExternalId de la trust policy, pour qu’un autre de ses clients ne puisse pas lui faire assumer votre rôle (problème du « confused deputy »).

🏢 AWS Organizations

📌 Élément🎯 Rôle
Compte de gestionCrée l’organisation, paie la facture, attache les policies ; impossible à changer ensuite
Compte membreAppartient à une seule organisation à la fois
RootConteneur au sommet de la hiérarchie, créé automatiquement (sans lien avec l’utilisateur root)
OU (Organizational Unit)Groupe de comptes ou d’OU, jusqu’à 5 niveaux sous la root ; les policies sont héritées
Administrateur déléguéCompte membre qui gère un service ou les policies à la place du compte de gestion
📌 Critère👤 SCP🗄️ RCP
Ce qui est plafonnéDroits des utilisateurs et rôles des comptes membres, root membre comprisDroits sur les ressources des comptes membres, quel que soit l’appelant, même externe
Cas typiqueInterdire les Régions non autoriséesBloquer l’accès aux ressources depuis l’extérieur de l’organisation
Services couvertsTous, à quelques exceptions documentées prèsUne liste définie : S3, STS, KMS, SQS, Secrets Manager, etc.
Policy par défautFullAWSAccess, remplaçableRCPFullAWSAccess, non détachable
Maximum attaché par root, OU ou compte105
Date cléLangage IAM complet depuis septembre 2025Lancées en novembre 2024

🔑 IAM Identity Center

Successeur d’AWS SSO (Single Sign-On), renommé en juillet 2022 : un portail unique donne aux humains l’accès à leurs comptes et applications, depuis une seule source d’identité par organisation (annuaire intégré, Active Directory ou fournisseur externe comme Okta ou Microsoft Entra ID).

Un permission set est un modèle de policies : à l’affectation, Identity Center crée le rôle IAM correspondant dans chaque compte cible. La session dure 1 heure par défaut, 12 heures au maximum.

Articles liés