Utilisateurs, rôles, policies et Organizations : les permissions AWS expliquées !
AWS
Publié le
Karl Certa Admin systèmes & réseaux5 ans dans l'IT, passé par le support puis l'admin sys, aujourd'hui Ops. J'apprends le cloud et je pose tout au propre ici. Focus sur l'IaC & le cloud AWS SAA, prochaine étape Kubernetes LinkedIn karlcerta.fr GitHub 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 root
Identité créée avec le compte, accès complet à tout, facturation comprise
Adresse e-mail du compte
👤 Utilisateur IAM
Identité avec des identifiants longue durée (mot de passe, access keys)
Outil tiers qui ne sait pas assumer un rôle
👥 Groupe
Ensemble d’utilisateurs IAM qui reçoivent les mêmes policies
Admins, Ops
🎭 Rôle
Identité sans identifiant permanent, assumée à la demande avec des identifiants temporaires
Application sur AWS, compte partenaire
📄 Policy
Document JSON (JavaScript Object Notation) qui autorise ou refuse des actions
ReadOnlyAccess
🧩 Principal
Entité authentifiée qui émet la requête : root, utilisateur, rôle, service AWS
Rô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 comptes
IAM Identity Center + permission sets
Identifiants temporaires, gestion centralisée
🖥️ Application qui tourne sur AWS
Rôle attaché à la ressource
AWS fournit des identifiants temporaires, aucune clé à stocker
🔁 Accès d’un compte AWS à un autre
Rôle assumé via STS (Security Token Service)
Accès court, révocable, tracé
🤝 Prestataire externe
Rôle cross-account + External ID
Aucune clé partagée avec le tiers
🗄️ Ouvrir une seule ressource à un autre compte
Resource-based policy sur la ressource
Pas de rôle à assumer
🧰 Outil tiers incompatible avec les rôles
Utilisateur IAM + access keys
Cas où AWS admet des identifiants longue durée
🚨 Accès d’urgence si le fournisseur d’identité tombe
Utilisateur 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ôles
Permissions boundary
Plafonne les droits que ces rôles peuvent obtenir
👑 Compte root et bonnes pratiques
📌 Règle
🧭 Mécanique et conséquence
🔒 MFA sur le root
Second 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 root
Le root a accès à tout, facturation comprise : une clé qui fuit livre le compte entier
🧑💼 Pas de root au quotidien
Réservé aux rares tâches qui l’exigent ; un utilisateur administratif fait le reste
📧 Adresse e-mail de groupe
Si AWS contacte le propriétaire, la réponse ne dépend pas d’une seule personne
🏢 Comptes membres d’une organisation
Les identifiants root (mot de passe, clés, MFA) peuvent être supprimés de façon centralisée
🎯 Moindre privilège
N’accorder que les actions utiles sur les ressources utiles ; partir des policies AWS puis resserrer avec IAM Access Analyzer
🧹 Revue régulière
Les 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
Version
Version du langage de policy
"2012-10-17"
Statement
Une ou plusieurs règles
Objet ou tableau
Sid
Libellé optionnel de la règle
"LectureBucketBureau"
Effect
Autoriser ou refuser
Allow, Deny
Action
Appels d’API (Application Programming Interface) visés, préfixés par le service
s3:GetObject, ec2:Describe*
Resource
ARN (Amazon Resource Name) des ressources visées
arn:aws:s3:::amzn-s3-demo-bucket/*
Condition
Contexte exigé pour que la règle s’applique
IP (Internet Protocol) source, Région, tag, MFA
Principal
Qui est visé ; uniquement dans une resource-based policy ou une trust policy
Compte, 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 :
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.
Non, liée à une seule identité et supprimée avec elle
Relation 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éfaut
Sans Allow applicable, la requête est refusée (seul le root a un accès complet par défaut)
⛔ Deny explicite prioritaire
Un seul Deny applicable, dans n’importe quel type de policy, l’emporte sur tous les Allow
🏢 SCP et RCP
Il faut un Allow à chaque niveau de l’organisation, sinon refus même avec AdministratorAccess
➕ Identity-based et resource-based
Union : un Allow dans l’une ou l’autre suffit (sauf trust policy et key policy KMS, qui doivent autoriser explicitement)
✂️ Permissions boundary
Intersection avec les identity-based policies : l’action doit être autorisée des deux côtés
🎫 Session policy
Filtre 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ête
Identity-based policy du principal et ce qui la limite (boundary, SCP)
Doit donner Allow
Compte B, propriétaire de la ressource
Resource-based policy qui nomme le principal de A et ce qui la limite (RCP)
Doit donner Allow
Décision finale
Les deux évaluations
Allow seulement si les deux côtés autorisent
🎭 Rôles et STS
📌 Élément
🎯 Rôle
Trust policy
Resource-based policy du rôle : qui a le droit de l’assumer
Permissions policy
Identity-based policy du rôle : ce que la session pourra faire
sts:AssumeRole
Renvoie une access key, une secret key et un token de session temporaires
Service role
Rôle qu’un service AWS assume pour agir en votre nom, modifiable par l’admin
Service-linked role
Rôle lié à un service et possédé par lui : permissions visibles mais non modifiables
Role chaining
Assumer un second rôle avec la session du premier
📌 Durée de session AssumeRole
📊 Valeur
Par défaut
1 heure (3600 s)
Minimum
15 minutes (900 s)
Maximum réglable sur le rôle
De 1 à 12 heures
En role chaining
1 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 gestion
Crée l’organisation, paie la facture, attache les policies ; impossible à changer ensuite
Compte membre
Appartient à une seule organisation à la fois
Root
Conteneur 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 compris
Droits sur les ressources des comptes membres, quel que soit l’appelant, même externe
Cas typique
Interdire les Régions non autorisées
Bloquer l’accès aux ressources depuis l’extérieur de l’organisation
Services couverts
Tous, à quelques exceptions documentées près
Une liste définie : S3, STS, KMS, SQS, Secrets Manager, etc.
Policy par défaut
FullAWSAccess, remplaçable
RCPFullAWSAccess, non détachable
Maximum attaché par root, OU ou compte
10
5
Date clé
Langage IAM complet depuis septembre 2025
Lancé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.