Un guide complet pour comprendre, configurer et sécuriser les identités, les permissions et les accès dans AWS grâce à IAM, avec une approche progressive, des cas complexes et les meilleures pratiques.
AWS Identity and Access Management (IAM) est le service d'AWS permettant de gérer de manière fine qui peut accéder à quelles ressources dans un environnement cloud. IAM est un service centralisé et global, ce qui signifie qu'il ne dépend pas d'une région spécifique. Il permet aux administrateurs de contrôler de manière granulaire les permissions accordées aux utilisateurs, services et applications.
Avec IAM, vous pouvez :
IAM est un pilier fondamental de la sécurité dans AWS. Il permet de mettre en place des politiques de moindre privilège, de cloisonner les responsabilités, et de garantir que chaque entité ne dispose que des accès nécessaires à son fonctionnement.
Un utilisateur IAM représente une entité humaine ou une application nécessitant un accès direct à AWS (via la console ou les API). Chaque utilisateur peut se voir attribuer des identifiants (nom d'utilisateur/mot de passe, clés d'accès API) et un ensemble de permissions.
Un groupe IAM est une collection d'utilisateurs partageant les mêmes permissions. Il permet de gérer efficacement les autorisations pour plusieurs utilisateurs en appliquant une politique unique au groupe. Exemple : un groupe "Développeurs" avec accès à CodeCommit et Lambda.
Les rôles IAM sont des identités sans identifiants permanents, conçues pour être assumées temporairement. Ils sont utilisés par des services AWS, des utilisateurs d'autres comptes ou des applications externes pour effectuer des actions autorisées. Un rôle dispose de deux politiques :
Exemples :
Les politiques sont des documents JSON qui définissent les permissions. Elles peuvent être :
Chaque politique précise :
Allow ou Denys3:PutObject, ec2:StartInstances, etc.)Contrôle d'accès pour les développeurs et administrateurs
Permissions aux services AWS
Délégation d'accès entre comptes AWS
Accès temporaire à des ressources sensibles
Mise en œuvre de la politique de moindre privilège
Audits et conformité
IAM est omniprésent dans toute stratégie de sécurité AWS : chaque service, chaque architecture microservices ou chaque environnement multi-comptes repose sur une configuration rigoureuse et adaptée des identités et permissions via IAM.
Un utilisateur IAM est une entité représentant une personne ou une application qui interagit directement avec AWS. La création d’un utilisateur permet de lui attribuer un identifiant unique et de configurer ses moyens d’authentification :
Définir le nom d’utilisateur unique
Choisir les types d’accès : console, programme ou les deux
DĂ©finir les permissions initiales :
Activer ou non le mot de passe temporaire et l'obligation de le changer à la première connexion
Activer des métadonnées comme les tags pour une meilleure traçabilité
Les utilisateurs peuvent être ensuite modifiés à tout moment : réinitialisation du mot de passe, ajout de clés, révocation d'autorisations, etc. Il est recommandé de ne jamais utiliser l’utilisateur root sauf en cas d’absolue nécessité.
Les groupes IAM sont un mécanisme logique permettant d’associer des permissions à plusieurs utilisateurs simultanément. Chaque groupe peut avoir une ou plusieurs politiques d’autorisation. Les utilisateurs membres héritent automatiquement des permissions associées au groupe.
Developpeurs: accès à AWS Lambda, S3, CloudWatch LogsDevOps: accès étendu à EC2, IAM (en lecture seule), CloudFormationAudit: lecture seule sur toutes les ressourcesL'utilisation des groupes permet :
IAM ne permet pas de créer des sous-groupes (hiérarchie). Cependant, on peut combiner des groupes ou ajouter plusieurs politiques pour moduler les droits.
L’ajout d’un second facteur (généralement un token TOTP) est essentiel pour sécuriser les comptes sensibles, en particulier :
AWS propose l’utilisation d’applications comme Google Authenticator, Duo, ou encore des dispositifs matériels (YubiKey).
L'utilisateur root dispose de tous les droits, sans aucune restriction. Il ne doit être utilisé que pour les actions indispensables comme :
Dans tous les autres cas, il est préférable de créer un utilisateur IAM avec des droits d’administrateur.
Les clés d'accès statiques exposent un risque important si elles sont compromises. AWS recommande :
AWS fournit des outils (IAM Access Analyzer, Last Accessed) permettant d’identifier :
Cela permet d’ajuster les politiques au plus proche du besoin réel (principe du moindre privilège).
Il est recommandé d’utiliser les balises (tags) pour :
Exemples de tags : team=analytics, environment=prod, owner=jdoe
Pour des organisations de grande taille, il est préférable d’éviter de gérer des centaines d’utilisateurs IAM manuellement. On peut utiliser :
Cela permet de :
La gestion fine des identités et des accès via IAM constitue un levier essentiel de sécurité, de conformité et d’automatisation dans AWS. La combinaison rigoureuse d’utilisateurs, de groupes, de rôles et de politiques bien structurées garantit une gouvernance optimale des environnements cloud.
Les politiques IAM sont des documents en JSON décrivant les permissions. Chaque politique suit une structure bien définie, composée de blocs appelés "statements" (déclarations). Voici un exemple de base :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::mon-bucket/*" } ] }
Version : version du langage des politiques (toujours "2012-10-17")
Statement : tableau de blocs de permission (il peut y en avoir plusieurs)
Chaque bloc contient :
Effect : Allow ou DenyAction : une ou plusieurs actions AWS (ex : ec2:StartInstances, s3:GetObject)Resource : une ou plusieurs ressources AWS identifiées par leur ARNCondition (facultatif) : contraintes conditionnellesEffectDétermine si la déclaration autorise (Allow) ou refuse (Deny) l’accès. Par défaut, tout est refusé si non explicitement autorisé.
Deny explicite prime toujours sur une AllowActionSpécifie les opérations AWS ciblées. Il peut s’agir :
s3:PutObjects3:* pour toutes les actions S3ResourceIdentifie les ressources AWS auxquelles s’applique la permission. On utilise des ARN (Amazon Resource Name), comme :
arn:aws:s3:::mon-bucket (bucket S3)arn:aws:lambda:us-east-1:123456789012:function:MaFonctionOn peut aussi utiliser * pour toutes les ressources, mais cela est à éviter sauf si justifié.
ConditionPermet de restreindre ou de spécifier les conditions sous lesquelles la politique s’applique. Syntaxe :
"Condition": { "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}, "StringEquals": {"s3:x-amz-acl": "public-read"} }
Principaux opérateurs :
StringEquals, StringLike, IpAddress, DateGreaterThan, etc.aws:username, aws:MultiFactorAuthPresent, aws:PrincipalTag, etc.IAM permet l’utilisation de variables dynamiques, avec la syntaxe ${}. Cela permet d’écrire des politiques plus générales, adaptées dynamiquement à l’identité de l’utilisateur, du rôle, ou des tags associés.
Exemples :
"Resource": "arn:aws:s3:::logs-${aws:username}/*"
Cette ressource pointera vers un dossier personnalisé pour chaque utilisateur.
Autres exemples utiles :
${aws:PrincipalTag/Department}${aws:RequestTag/Project}Ces variables permettent de combiner IAM avec les balises (tags) pour créer des politiques contextuelles puissantes.
AmazonS3ReadOnlyAccess)Avantages :
Utilisées pour des cas très spécifiques et limités dans le temps. Leur usage est à limiter sauf nécessité (contrôle fin ou temporaire).
IAM permet de sécuriser l’accès à tous les services AWS, mais chaque service peut avoir ses particularités. Quelques exemples de stratégies adaptées :
"Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-xxxxxxxxxx" } }
lambda:InvokeFunction pour autoriser un autre service à invoquer une fonctiondynamodb:GetItem, PutItem, etc.logs:PutLogEvents) pour les services produisant des logsChaque service possède sa propre sémantique, ses actions et ses contraintes spécifiques. Une maîtrise approfondie de ces différences est essentielle pour définir des politiques robustes et cohérentes à l’échelle de l’infrastructure AWS.
Les politiques IAM sont l’outil le plus puissant (et potentiellement dangereux) de l’arsenal de sécurité AWS. Leur bonne compréhension et leur utilisation rigoureuse permettent de construire des environnements cloud sûrs, auditables et évolutifs.
Un rôle IAM est une entité IAM que l'on peut assumer temporairement pour effectuer des actions sur AWS. Contrairement aux utilisateurs, les rôles n'ont pas de login ni de clés d'accès permanentes. Les rôles sont essentiels pour :
La trust policy contrôle qui a le droit d'assumer le rôle. Elle s’applique à l’entité appelante (principal) :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole" } ] }
Ici, le rôle peut être assumé par une instance EC2. Le champ Principal peut aussi spécifier un ARN utilisateur ou un ID de compte AWS.
Les permission policies attachées au rôle définissent les actions autorisées par ce rôle. Ce sont les mêmes politiques que celles utilisées pour les utilisateurs ou groupes IAM.
Ces deux politiques sont complémentaires :
Le mécanisme d’assume role repose sur AWS STS (Security Token Service). Lorsqu’un utilisateur ou un service assume un rôle, AWS génère des identifiants temporaires (AccessKeyId, SecretAccessKey, SessionToken).
Exemple d'appel API avec AWS CLI :
aws sts assume-role \ --role-arn arn:aws:iam::123456789012:role/RoleAudit \ --role-session-name audit-session
Pour permettre à un utilisateur ou un rôle d’un compte A d’assumer un rôle dans un compte B, il faut :
arn:aws:iam::[ID_compte_A]:user/NomUtilisateursts:AssumeRole sur ce rôleCe schéma est couramment utilisé pour :
Les instance profiles permettent d’attacher un rôle IAM à une instance EC2. Ce rôle est automatiquement utilisé par les applications s'exécutant sur l’instance, sans besoin de stocker des clés.
Exemple : un rôle EC2 avec permission s3:PutObject permet à un script de sauvegarde de déposer des fichiers dans un bucket S3.
Chaque fonction Lambda doit avoir un rôle d’exécution (execution role) qui lui permet d’accéder aux services nécessaires :
Exemple de rĂ´le Lambda :
{ "Effect": "Allow", "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"], "Resource": "*" }
Les tâches ECS peuvent être associées à des IAM Task Roles, permettant à chaque tâche d’avoir des permissions propres. Cela évite de partager des identifiants sensibles entre conteneurs.
Cas typique : une tâche ECS qui publie des événements sur un topic SNS ou qui écrit dans DynamoDB.
Les rôles IAM sont un outil indispensable pour sécuriser, compartimenter et automatiser les accès dans AWS. Leur usage rigoureux permet de remplacer les identifiants statiques par des accès temporaires, auditables et spécifiques aux besoins réels.
Dans AWS IAM, plusieurs politiques peuvent s’appliquer à une même entité (utilisateur, groupe, rôle). Lorsque ces politiques contiennent des instructions contradictoires (par exemple, une autorisation dans une politique et un refus explicite dans une autre), AWS applique les règles suivantes :
Un utilisateur est membre d’un groupe avec une politique Allow sur S3, mais a une politique personnelle Deny sur le même service. Résultat : l'accès est refusé.
Cela permet d’utiliser des politiques restrictives comme garde-fous supplémentaires, en cas d’erreur de configuration dans les politiques autorisantes.
Les permissions boundaries sont un mécanisme avancé permettant de limiter ce qu’un rôle ou utilisateur peut potentiellement faire, même si ses politiques l’autorisent.
Un utilisateur a une politique Allow: "ec2:*", mais une permission boundary qui ne permet que "ec2:Describe*". L’utilisateur ne pourra pas démarrer d’instances, même si sa politique personnelle l’y autorise.
Utilisation typique :
Permissions boundaries sont très utiles dans les environnements décentralisés ou multi-comptes.
Il existe deux grands types de politiques IAM :
Exemple : permettre Ă un utilisateur d'Ă©crire dans un bucket S3.
Exemple : une politique sur un bucket S3 autorisant uniquement des utilisateurs d’un compte externe à lire les objets.
| Caractéristique | Politique basée sur l'identité | Politique basée sur la ressource |
|---|---|---|
| Supportée par | Tous les services AWS | Services spécifiques |
| Contrôle | Ce que l'identité peut faire | Qui peut agir sur la ressource |
| Scope | Centré sur l’utilisateur | Centré sur la ressource |
Les conditions IAM permettent de définir des règles contextuelles très précises. Elles s’utilisent dans les blocs Condition des politiques IAM et peuvent s’appliquer à :
StringEquals, StringLike, IpAddress, Bool, DateGreaterThan, etc.aws:SourceIp : filtre sur l’adresse IPaws:MultiFactorAuthPresent : vérifie si MFA est activéaws:TagKeys ou aws:PrincipalTag/Project : logique basée sur des tagss3:prefix, kms:ViaService, ec2:InstanceType : spécifiques à un service"Condition": { "IpAddress": {"aws:SourceIp": "192.168.1.0/24"} }
"Condition": { "StringEquals": { "aws:PrincipalTag/Project": "ML-Pipeline" } }
"Condition": { "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" } }
Les conditions permettent de transposer des politiques de sécurité organisationnelles en contraintes techniques robustes, dynamiques et adaptables.
La gestion des permissions complexes dans IAM est un art qui exige rigueur, anticipation et compréhension profonde des mécanismes sous-jacents. C’est une compétence clé pour sécuriser des infrastructures AWS dynamiques, partagées et critiques, tout en évitant les pièges classiques liés aux permissions trop larges ou contradictoires.
La sécurité d’IAM ne repose pas uniquement sur la définition des permissions : elle nécessite également une surveillance active des activités. AWS fournit deux outils complémentaires pour ce besoin : CloudTrail et CloudWatch.
CloudTrail enregistre chaque appel API effectué dans votre compte AWS, qu’il provienne de la console, de l’interface CLI ou d’un SDK.
Pour IAM, cela permet de tracer :
Exemple d'événement CloudTrail :
{ "eventName": "CreateUser", "userIdentity": { "type": "IAMUser", "userName": "admin" }, "requestParameters": { "userName": "john.doe" } }
Vous pouvez créer des trails multi-régions, stocker les logs dans S3, et configurer des alertes automatiques en cas d’activité suspecte.
CloudWatch collecte des métriques et permet la création de logs personnalisés, notamment via CloudTrail ou AWS Config. Il peut être utilisé pour :
Dans des environnements complexes, il devient difficile de comprendre ce qu’un utilisateur ou rôle peut réellement faire. IAM fournit plusieurs outils pour analyser ces permissions effectives.
Permet de tester les politiques attachées à une entité IAM pour une action et une ressource données.
Utilisation typique :
IAM fournit pour chaque entité une section "Last Accessed" montrant :
Cela permet de supprimer les permissions non utilisées.
Intégré à l’interface IAM, il affiche les services auxquels une entité a accès et ceux qu’elle a réellement utilisés.
Ces outils aident à affiner les permissions pour se conformer au principe du moindre privilège.
IAM Access Analyzer est un outil avancé de détection d’accès non intentionnels ou trop larges à vos ressources AWS.
Exemples :
Access Analyzer est essentiel dans les environnements partagés, multi-comptes ou orientés sécurité.
Une mauvaise configuration IAM peut permettre à un utilisateur de s’octroyer davantage de privilèges qu’initialement prévu — c’est l’escalade de privilèges.
iam:PassRole (souvent utilisées pour détourner des rôles à privilèges)La sécurité IAM ne repose pas uniquement sur les définitions de politique. Elle implique une analyse constante, une supervision active, et des mécanismes de défense en profondeur pour garantir que chaque permission est justifiée, contrôlée et traçable. Une architecture IAM bien surveillée est un pilier incontournable de toute stratégie cloud sécurisée.
Dans des architectures complexes, il est courant d’utiliser plusieurs comptes AWS pour isoler les environnements, répartir les responsabilités ou respecter des exigences réglementaires. AWS Organizations permet de regrouper, gérer et sécuriser plusieurs comptes à partir d’un compte central appelé "compte maître" (ou compte de gestion).
Les SCP permettent de restreindre les permissions disponibles dans les comptes membres, indépendamment des politiques IAM locales. Une SCP ne donne jamais de permissions, elle limite le périmètre de ce qu’IAM peut accorder dans un compte.
Exemple de SCP :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:*", "Resource": "*" } ] }
Cette SCP interdit l’usage de S3 dans toute unité organisationnelle ciblée, même si une politique IAM essaie de l’autoriser.
Cas d’usage :
iam:CreateUser dans des comptes non administratifsec2:* uniquement aux régions autoriséesLa gestion d’IAM dans un environnement multi-comptes peut rapidement devenir difficile sans centralisation. Plusieurs approches permettent d’avoir un contrôle global et cohérent :
Exemple : un utilisateur admin@organisation-principale peut assumer un rĂ´le ReadOnly dans les comptes secondaires via sts:AssumeRole.
Avantages :
Project=Fintech, Environment=Prod)Dans les environnements cloud professionnels, la séparation des rôles est essentielle pour :
Chaque compte a un rôle bien défini et des contrôles croisés empêchent qu’un seul compte puisse à la fois modifier les politiques et effacer les preuves d’activité.
Même dans un seul compte AWS, on peut séparer les rôles :
Une architecture IAM multi-comptes bien conçue renforce drastiquement la sécurité et la gouvernance cloud. Grâce à AWS Organizations, SCP, et à une politique stricte de séparation des responsabilités, il est possible de maintenir un environnement hautement sécurisé, modulable et conforme, même à grande échelle.
L’automatisation de la gestion des identités et des permissions est cruciale pour assurer la cohérence, la reproductibilité et la sécurité dans un environnement AWS à grande échelle. L’Infrastructure as Code (IaC) permet de définir les rôles, les utilisateurs, les politiques et les stratégies IAM via du code versionné et déployable automatiquement.
AWS CloudFormation permet de décrire toute l’infrastructure IAM en YAML ou JSON. Cela inclut :
AWS::IAM::User)AWS::IAM::Role)AWS::IAM::Policy, AWS::IAM::ManagedPolicy)AWS::IAM::Group)Resources: MyLambdaRole: Type: AWS::IAM::Role Properties: RoleName: my-lambda-role AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: lambda.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: LambdaLogs PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: "*"
Avantages de CloudFormation pour IAM :
Terraform est un outil IaC très utilisé dans les environnements multi-clouds. Il dispose de providers puissants pour gérer IAM dans AWS.
resource "aws_iam_role" "lambda_exec" { name = "lambda_exec_role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Principal = { Service = "lambda.amazonaws.com" } Action = "sts:AssumeRole" } ] }) }
Pour industrialiser les déploiements IAM :
module "developer_role" { source = "./modules/iam-role" role_name = "dev-role" policy_actions = ["s3:ListBucket", "ec2:DescribeInstances"] resource_arns = ["*"] }
Terraform facilite aussi :
terraform plan)La rotation régulière des clés d’accès et des rôles temporaires est essentielle pour limiter la durée d’exposition d’un secret compromis.
EventBridge déclenche une règle quotidienne
Lambda vérifie la date de création des clés avec list-access-keys
Si une clé dépasse le seuil :
create-access-key)delete-access-key)import boto3 from datetime import datetime, timezone, timedelta iam = boto3.client('iam') response = iam.list_users() for user in response['Users']: keys = iam.list_access_keys(UserName=user['UserName']) for key in keys['AccessKeyMetadata']: age = datetime.now(timezone.utc) - key['CreateDate'] if age > timedelta(days=90): iam.delete_access_key(UserName=user['UserName'], AccessKeyId=key['AccessKeyId'])
sts:AssumeRole) aux clés statiquesL’automatisation de la gestion IAM via des outils IaC comme CloudFormation et Terraform, combinée à la rotation proactive des identifiants, est une démarche incontournable pour maintenir une posture de sécurité efficace, auditable et scalable dans le cloud AWS. Elle garantit une gouvernance robuste, tout en réduisant les risques liés aux erreurs humaines et aux mauvaises configurations.
Le modèle Zero Trust repose sur le principe suivant : ne jamais faire confiance par défaut, même à l’intérieur du périmètre réseau. Dans AWS, IAM est un pilier central pour mettre en œuvre une architecture Zero Trust.
aws:TagKeys, aws:PrincipalTag, etc.).Cette architecture impose une discipline stricte dans la gestion des politiques et une automatisation continue de la supervision.
AWS Security Token Service (STS) permet d’établir des sessions temporaires entre comptes. C’est une alternative sécurisée à l’utilisation de comptes IAM multiples, et un composant clé des architectures multi-comptes modernes.
{ "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:root" }, "Action": "sts:AssumeRole" }
aws:SourceIp, aws:PrincipalTag, etc.)Cette approche élimine les accès permanents, renforce la traçabilité et réduit la surface d’attaque.
AWS propose plusieurs mécanismes pour contrôler les accès à des APIs déployées via API Gateway, Lambda, Load Balancer, etc. IAM permet d'intégrer des politiques d’accès granulaires dans ces architectures.
ConditionEnvironment=ProdLes cas complexes montrent la puissance et la flexibilité d’IAM, dès lors qu’on l’intègre pleinement dans la stratégie d’architecture, de gouvernance et de sécurité. Que ce soit dans un cadre Zero Trust, inter-comptes ou d’expositions d’API, IAM est l’élément de contrôle fondamental assurant l’isolation, la traçabilité et la conformité de toutes les interactions dans AWS.
Une mauvaise configuration IAM peut avoir des conséquences graves : exfiltration de données, compromission d’infrastructure, ou destruction accidentelle. Voici un condensé des erreurs fréquemment observées :
*)Action: "*", Resource: "*"Une checklist de sécurité IAM permet d’anticiper les incidents et de s’assurer que la configuration reste conforme aux bonnes pratiques.
Deny) sur les ressources critiquesAmazonS3ReadOnlyAccess, ViewOnlyAccess"Bool": { "aws:MultiFactorAuthPresent": "true" }iam:PassRoleCondition -> arnEqualsrole-appname-environment-purposeLa maintenance des politiques IAM est un processus continu :
Script Lambda ou cron Terraform pour :
Une politique IAM bien pensée n’est pas figée. Elle évolue avec les besoins de l’organisation, les nouveaux services AWS, et les menaces de sécurité émergentes. Maintenir une culture d’audit, de rigueur, et d’automatisation autour d’IAM est l’assurance d’un socle sécurisé, durable et adaptable dans le temps.
La majorité des services AWS sont intégrés à IAM, mais certains ont des particularités importantes à connaître :
DescribeDBInstances), mais pas pour les accès SQL (gérés par l’engine).Documentation officielle IAM par service :
L’écosystème open source propose plusieurs outils de sécurité et d’audit IAM très complets :
iam:PassRole, sts:AssumeRole, ec2:*)Les sources officielles AWS sont extrêmement détaillées et constituent la référence incontournable pour toute implémentation ou audit IAM.
Ces ressources permettent de rester à jour avec les évolutions du service, les bonnes pratiques et les scénarios avancés.