AWS IAM Access Control : Politiques, Rôles et Bonnes Pratiques

AWS Identity and Access Management (IAM) est le service qui régit l'authentification et l'autorisation de chaque appel API effectué vers votre environnement AWS. Il détermine qui peut se connecter, quelles actions sont autorisées et sur quelles ressources — pour chaque service AWS, dans chaque région, pour chaque compte. Bien configurer IAM n'est pas optionnel : selon les propres analyses post-incident d'AWS, les politiques IAM mal configurées sont impliquées dans la majorité des failles de sécurité cloud qui font l'objet d'une divulgation publique. Cet article couvre l'architecture d'IAM, sa logique d'évaluation des politiques, les patterns pratiques pour faire passer le contrôle d'accès à l'échelle et les erreurs opérationnelles que le SOC d'Opsio rencontre de manière récurrente sur des centaines de comptes AWS.

Points Clés

• AWS IAM est le service fondamental qui détermine qui peut faire quoi sur l'ensemble des ressources AWS, et sa mauvaise configuration constitue la cause première la plus fréquente des incidents de sécurité cloud.
• Un IAM efficace exige de superposer politiques d'identité, politiques de ressources, permission boundaries et Service Control Policies — et non pas simplement d'attacher des politiques managées à des utilisateurs.
• Les organisations soumises à NIS2, au RGPD ou à la DPDPA 2023 doivent traiter la configuration IAM comme un contrôle de conformité, et non comme un simple choix opérationnel.
• L'ABAC (contrôle d'accès basé sur les attributs) via les tags est désormais le modèle de mise à l'échelle recommandé pour les organisations disposant de plus d'une poignée de comptes, mais la plupart des équipes restent sur du RBAC par défaut.
• Les incidents IAM les plus graves investigués par le SOC d'Opsio ne sont pas des escalades de privilèges — ce sont des identifiants périmés et des rôles de service sur-permissionnés que personne n'audite.

Comment fonctionne AWS IAM : le modèle fondamental

IAM fonctionne selon un modèle de refus par défaut (default-deny). Chaque requête API AWS est évaluée par rapport à un ensemble de politiques, et à moins que l'évaluation ne produise un Allow explicite — sans aucun Deny qui le supplante — la requête est rejetée. Comprendre cette chaîne d'évaluation est le concept le plus important en matière de contrôle d'accès AWS.

Principaux, Actions, Ressources et Conditions

Chaque instruction de politique IAM comporte quatre composants :

• Principal — l'entité effectuant la requête (utilisateur IAM, rôle IAM, identité fédérée, service AWS)
• Action — l'opération API spécifique (s3:GetObject, ec2:RunInstances, iam:CreateUser)
• Resource — le ou les ARN auxquels l'action s'applique
• Condition — contraintes optionnelles (IP source, statut MFA, heure, tags de la ressource)

Une politique est un document JSON contenant une ou plusieurs instructions, chacune avec un Effect de type Allow ou Deny. La puissance — et la complexité — provient de la manière dont plusieurs politiques interagissent lors de l'évaluation.

La chaîne d'évaluation des politiques

Lorsqu'un principal effectue une requête au sein d'une AWS Organization, l'évaluation suit cet ordre :

1. Service Control Policies (SCP) — garde-fous au niveau de l'organisation qui définissent les permissions maximales pour les comptes membres

2. Politiques basées sur les ressources — attachées à la ressource elle-même (ex. : politiques de bucket S3, politiques de clé KMS)

3. Permission boundaries IAM — permissions maximales qu'une entité IAM peut avoir, indépendamment de ses politiques d'identité

4. Politiques de session — transmises lors de l'assomption d'un rôle, restreignant davantage la session

5. Politiques basées sur l'identité — les politiques attachées à l'utilisateur, au groupe ou au rôle IAM

Un Deny explicite à n'importe quel niveau prend le dessus sur toutes les instructions Allow. Ce modèle en couches permet d'appliquer des garde-fous à l'échelle de l'organisation (via les SCP) même si les administrateurs de comptes individuels tentent d'accorder des accès plus larges.

Comprendre cette chaîne n'est pas un exercice théorique — le NOC d'Opsio trace régulièrement des erreurs d'accès refusé jusqu'à des restrictions SCP dont les administrateurs au niveau compte ignoraient l'existence. Si vous déboguez un 403 sur un appel API alors que la politique d'identité indique clairement Allow, vérifiez d'abord les SCP.

Les briques de base IAM en pratique

Utilisateurs IAM vs. Rôles IAM vs. Identités fédérées

Les utilisateurs IAM sont des identités à long terme avec des identifiants permanents. Ils existent toujours et fonctionnent toujours, mais pour les opérateurs humains, ils doivent être considérés comme un héritage. La recommandation actuelle d'AWS — et la position opérationnelle d'Opsio — est de fédérer l'accès humain via IAM Identity Center (anciennement AWS SSO), qui délivre des identifiants temporaires via SAML 2.0 ou OIDC.

Les rôles IAM sont la cheville ouvrière de l'IAM AWS moderne. Un rôle n'a pas d'identifiants permanents ; à la place, les principaux assument le rôle et reçoivent des jetons de sécurité temporaires (via AWS STS). Les rôles sont utilisés pour :

• L'accès inter-comptes (une charge de travail du Compte A assume un rôle dans le Compte B)
• L'accès de service à service (un instance profile EC2, un rôle d'exécution Lambda)
• L'accès humain via fédération (assomption d'un rôle après authentification auprès de votre IdP)

Les identités fédérées s'authentifient auprès d'un fournisseur d'identité externe (Okta, Azure AD / Entra ID, Google Workspace) et assument des rôles IAM. C'est le pattern que toute organisation de plus de dix ingénieurs devrait utiliser pour l'accès console et CLI.

Politiques IAM : managées, inline et personnalisées

Les politiques managées AWS (ex. : ReadOnlyAccess, PowerUserAccess) sont maintenues par AWS et couvrent des cas d'usage courants. Elles sont pratiques mais souvent trop larges pour un usage en production. AdministratorAccess est la politique managée la plus fréquemment attachée que le SOC d'Opsio constate dans ses audits — et elle n'est presque jamais justifiée pour les opérations courantes.

Les politiques managées client sont le choix par défaut approprié. Rédigez-les vous-même, délimitez-les selon vos charges de travail réelles, versionnez-les dans Git et déployez-les via l'Infrastructure as Code (Terraform, CloudFormation ou CDK).

Les politiques inline sont intégrées directement à un utilisateur, un groupe ou un rôle. Elles ont une relation stricte 1:1. Utilisez-les uniquement lorsqu'une politique ne doit en aucun cas être accidentellement attachée à une autre entité — ce qui est rare.

Service Control Policies (SCP)

Les SCP constituent la couche la plus puissante — et la plus mal comprise — de la pile IAM. Elles n'accordent pas de permissions ; elles définissent la frontière maximale de ce que tout principal dans un compte membre peut faire. Une SCP qui interdit s3:DeleteBucket signifie que personne dans ce compte ne peut supprimer un bucket, même avec AdministratorAccess.

Patterns SCP concrets qu'Opsio déploie pour ses clients :

• Restriction régionale — refuser toutes les actions en dehors de eu-west-3, eu-west-1 et ap-south-1 (application de la souveraineté des données pour le RGPD et la DPDPA)
• SCP garde-fous — empêcher la désactivation de CloudTrail, la suppression des VPC flow logs ou la modification du rôle IAM d'audit
• Liste de services bloqués — bloquer les services non utilisés par l'organisation (ex. : Lightsail, GameLift) pour réduire la surface d'attaque

Garde-fous de sécurité AWS

RBAC vs. ABAC : choisir le bon modèle

RBAC (Contrôle d'accès basé sur les rôles)

Le RBAC dans AWS consiste à créer des rôles IAM distincts pour chaque fonction — DevOps-Engineer, Data-Analyst, Security-Auditor — et à attacher des politiques à ces rôles. C'est intuitif et cela fonctionne bien quand :

• Vous avez moins d'une vingtaine de rôles distincts
• Les équipes sont clairement séparées
• La prolifération de comptes reste limitée

L'inconvénient est l'explosion combinatoire. Si vous avez 5 fonctions, 4 environnements (dev/staging/prod/sandbox) et 3 projets, vous pourriez avoir besoin de 60 définitions de rôles — chacune avec des politiques distinctes.

ABAC (Contrôle d'accès basé sur les attributs)

L'ABAC utilise des tags sur les principaux et les ressources pour prendre des décisions d'autorisation. Au lieu de 60 rôles, vous rédigez un ensemble réduit de politiques avec des conditions telles que :

```json

"Condition": {

"StringEquals": {

"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",

"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"

}

}

```

Cela permet à un développeur tagué Project=payments, Environment=dev d'accéder uniquement aux ressources taguées de la même manière — sans créer de rôles spécifiques par projet ou par environnement.

La documentation IAM d'AWS recommande explicitement l'ABAC comme modèle préféré pour la mise à l'échelle. En pratique, la plupart des organisations gérées par Opsio utilisent un modèle hybride : RBAC pour la séparation large par fonction, ABAC pour le ciblage fin des ressources au sein de ces rôles.

Le piège opérationnel : l'ABAC ne fonctionne que si votre politique de tagging est rigoureuse. Si les équipes ne taguent pas les ressources de manière cohérente, les conditions échouent de façon ouverte ou fermée de manière imprévisible. Imposez le tagging avec des SCP et des règles AWS Config avant de miser sur l'ABAC.

Gouvernance des tags et FinOps

Bonnes pratiques IAM : ce qui compte réellement

Le pilier Sécurité du AWS Well-Architected Framework définit les bonnes pratiques IAM selon cinq axes. Voici ce que nous constatons comme véritablement important en production — au-delà de la théorie :

1. Éliminer les clés d'accès à long terme

Chaque clé d'accès est un identifiant susceptible d'être exfiltré. Le SOC d'Opsio a enquêté sur des incidents où des clés d'accès committées sur des dépôts GitHub publics étaient exploitées en quelques minutes par des scanners automatisés. La solution :

• Utiliser des rôles IAM avec des identifiants temporaires pour toutes les charges de travail (instance profiles EC2, rôles de tâche ECS, rôles d'exécution Lambda)
• Fédérer l'accès humain via IAM Identity Center
• Pour les rares cas où les clés d'accès sont inévitables (intégrations legacy), imposer la rotation via la règle AWS Config access-keys-rotated avec une durée maximale de 90 jours

2. Imposer le MFA — partout où cela compte

Le MFA sur le compte root est le strict minimum. Mais imposez également le MFA pour :

• Tous les utilisateurs IAM humains (si vous en avez encore)
• L'assomption de rôles sensibles (iam:AssumeRole avec Condition: { "Bool": { "aws:MultiFactorAuthPresent": "true" }})
• Le flux d'authentification IAM Identity Center (MFA par notification push, pas par SMS)

3. Appliquer le moindre privilège de manière itérative

Personne n'obtient le moindre privilège du premier coup. L'approche pragmatique :

1. Commencer avec des politiques managées AWS légèrement plus larges que nécessaire

2. Activer IAM Access Analyzer pour surveiller les permissions réellement utilisées

3. Après 30 à 90 jours, générer une politique de moindre privilège basée sur l'activité d'accès CloudTrail

4. Remplacer la politique large par la politique générée

5. Répéter trimestriellement

La fonctionnalité de génération de politiques d'IAM Access Analyzer est véritablement utile et sous-exploitée. Elle lit les journaux CloudTrail et produit une politique ciblée ne correspondant qu'aux actions et ressources effectivement invoquées.

4. Utiliser les permission boundaries pour l'administration déléguée

Si vous autorisez des développeurs ou des tech leads à créer des rôles IAM (ex. : pour des fonctions Lambda), définissez un permission boundary qui plafonne ce que ces rôles créés peuvent faire. Sans cela, un développeur peut créer un rôle avec AdministratorAccess — ce qui constitue un chemin d'escalade de privilèges.

5. Auditer en continu, pas une fois par an

Une revue IAM annuelle est un exercice de case à cocher. À la place :

• Exécuter IAM Access Analyzer en continu pour détecter les accès externes et inutilisés
• Surveiller les appels API IAM anormaux via CloudTrail + Amazon GuardDuty
• Utiliser les règles AWS Config pour signaler automatiquement les configurations IAM non conformes
• Alimenter les alertes dans un SIEM centralisé ou le pipeline d'alertes de votre SOC

Surveillance SOC 24/7

IAM dans une AWS Organization multi-comptes

Les environnements AWS mono-compte sont de plus en plus rares en production. AWS Organizations, combiné avec IAM Identity Center, est le pattern standard pour gérer l'accès sur des dizaines ou des centaines de comptes.

IAM Identity Center (anciennement AWS SSO)

IAM Identity Center fournit un point unique de gestion de l'accès humain sur l'ensemble des comptes de votre organisation. Les utilisateurs s'authentifient une seule fois (via votre IdP d'entreprise ou l'annuaire intégré) et reçoivent des identifiants temporaires pour le compte et le jeu de permissions de leur choix.

Les permission sets d'IAM Identity Center sont des abstractions qui créent des rôles IAM dans chaque compte cible. Vous les définissez une seule fois de manière centralisée et les assignez à des utilisateurs ou des groupes par compte. C'est considérablement plus simple que de gérer des rôles IAM indépendamment dans chaque compte.

Assomption de rôle inter-comptes

Pour l'accès de service à service entre comptes (ex. : un pipeline CI/CD dans le compte d'outillage déployant en production), le pattern est le suivant :

1. Créer un rôle dans le compte cible avec une politique de confiance autorisant le rôle du compte source

2. La charge de travail source appelle sts:AssumeRole pour obtenir des identifiants temporaires

3. Utiliser des external IDs pour prévenir les attaques de type confused deputy lorsque des tiers sont impliqués

Opsio configure l'accès inter-comptes selon un modèle en étoile (hub-and-spoke) : un compte sécurité central détient des rôles d'audit qui peuvent lire (mais pas écrire) dans tous les comptes membres. Cette conception supporte à la fois les opérations SOC et la collecte de preuves de conformité.

Stratégie multi-comptes

Dimensions réglementaires : NIS2, RGPD et DPDPA 2023

La configuration IAM est directement référencée dans chaque cadre réglementaire majeur auquel Opsio est confronté :

Directive NIS2 (UE) — L'article 21 exige des « politiques de contrôle d'accès » incluant la gestion des accès privilégiés. Les organisations classifiées comme entités essentielles ou importantes doivent démontrer que les contrôles IAM sont proportionnés aux risques, que les accès privilégiés sont surveillés et que des revues d'accès sont conduites régulièrement. Pour AWS, cela se traduit par des SCP, CloudTrail, IAM Access Analyzer et des procédures documentées de revue d'accès. En France, l'ANSSI, en tant qu'autorité compétente pour la transposition de NIS2, impose des exigences qui peuvent aller au-delà du socle européen, notamment via la qualification SecNumCloud pour les données sensibles hébergées sur des services cloud.

RGPD — L'article 32 impose « la capacité de garantir la confidentialité, l'intégrité, la disponibilité et la résilience constantes des systèmes et services de traitement », ce que les régulateurs — dont la CNIL en France — interprètent comme incluant la gestion des identités et des accès. Les responsables de traitement doivent démontrer que l'accès aux données personnelles est limité au personnel qui en a besoin — ce qui signifie des politiques IAM ciblées sur des tables DynamoDB, des préfixes S3 ou des instances RDS spécifiques contenant des données à caractère personnel.

DPDPA 2023 (Inde) — La section 8 impose aux data fiduciaries de mettre en œuvre des « mesures de sécurité raisonnables ». Pour les entreprises indiennes exécutant des charges de travail dans ap-south-1 (Mumbai) ou ap-south-2 (Hyderabad), cela signifie des contrôles IAM documentés, des pistes d'audit et la preuve de revues périodiques — similaires dans l'esprit aux exigences de l'article 32 du RGPD.

Le fil conducteur : les trois cadres exigent non seulement que les contrôles existent, mais qu'ils soient surveillés et réexaminés. Une configuration IAM sans journalisation CloudTrail et sans revue périodique des accès ne satisfait aucun d'entre eux.

Erreurs IAM courantes constatées par le SOC d'Opsio

Sur la base d'incidents réels et de résultats d'audit constatés sur nos comptes managés :

1. ARN de ressource avec wildcard dans les politiques de production — "Resource": "*" est acceptable en phase de prototypage. En production, cela signifie qu'un principal compromis peut accéder à chaque ressource de ce type dans le compte.

2. Rôles de service avec AdministratorAccess — Les fonctions Lambda et les tâches ECS doivent avoir des rôles d'exécution étroitement ciblés. Attacher un accès administrateur « parce que c'est plus simple » transforme chaque vulnérabilité applicative en compromission totale du compte.

3. Absence de SCP garde-fous sur les comptes membres — Sans SCP, tout administrateur de compte peut s'accorder n'importe quelle permission. Les SCP sont le seul mécanisme qui contraint même l'utilisateur root du compte (dans les comptes membres).

4. Utilisateurs IAM et clés d'accès périmés — Nous trouvons régulièrement des utilisateurs IAM correspondant à des collaborateurs ayant quitté l'organisation depuis des mois, voire des années. Utilisez la règle AWS Config iam-user-unused-credentials-check et configurez-la pour signaler les identifiants inutilisés depuis 45 jours.

5. Politiques basées sur les ressources ignorées — Les politiques de bucket S3, les politiques de clé KMS et les politiques de file SQS peuvent accorder un accès indépendamment des politiques d'identité. Un bucket S3 avec "Principal": "*" dans sa politique de bucket est accessible publiquement, quelle que soit la rigueur de vos rôles IAM.

Pour démarrer : une séquence pratique

Pour les organisations qui n'ont pas encore formalisé leur gouvernance IAM, voici l'ordre qui produit les résultats les plus rapides :

1. Activer CloudTrail dans tous les comptes, toutes les régions, avec journalisation vers un bucket S3 centralisé dans un compte d'archivage de logs

2. Activer IAM Access Analyzer dans chaque compte (c'est gratuit)

3. Migrer l'accès humain des utilisateurs IAM vers IAM Identity Center avec MFA

4. Déployer des SCP de base — refuser les régions non utilisées (n'autoriser que eu-west-3 Paris et les régions nécessaires), protéger l'infrastructure d'audit, imposer le chiffrement

5. Auditer les rôles et politiques IAM existants — utiliser les résultats d'Access Analyzer pour identifier les rôles inutilisés et les politiques sur-permissionnées

6. Implémenter l'Infrastructure as Code pour toutes les ressources IAM — plus de ClickOps dans la console IAM

Migration et modernisation cloud

Cette séquence fonctionne que vous ayez 2 comptes ou 200. La différence réside dans le temps nécessaire à l'étape 5.

Questions fréquentes

Qu'est-ce que les contrôles d'accès IAM ?

Les contrôles d'accès IAM sont les politiques, rôles et mécanismes au sein d'AWS Identity and Access Management qui déterminent quels principaux (utilisateurs, rôles, services) peuvent effectuer quelles actions sur quelles ressources. Ils fonctionnent selon un modèle de refus par défaut : sauf si une politique autorise explicitement une action, celle-ci est refusée. Ces contrôles comprennent les politiques basées sur l'identité, les politiques basées sur les ressources, les permission boundaries, les politiques de session et les Service Control Policies au niveau de l'organisation.

L'IAM est-il RBAC ou ABAC ?

AWS IAM supporte les deux approches. Le contrôle d'accès basé sur les rôles (RBAC) consiste à créer des rôles IAM avec des jeux de permissions spécifiques et à les attribuer à des utilisateurs ou des groupes. Le contrôle d'accès basé sur les attributs (ABAC) utilise des tags sur les principaux et les ressources pour prendre des décisions d'autorisation dynamiques. AWS recommande l'ABAC pour passer à l'échelle sur de nombreux comptes car il réduit le nombre de politiques distinctes à gérer. La plupart des environnements de production utilisent un modèle hybride des deux.

Qu'est-ce que l'accès IAM dans AWS ?

L'accès IAM dans AWS désigne la capacité authentifiée et autorisée pour un principal — un utilisateur IAM, une identité fédérée ou un rôle IAM — d'interagir avec les services et ressources AWS. Chaque appel API vers AWS est évalué par rapport aux politiques IAM. L'accès n'est accordé que lorsque les politiques applicables produisent un Allow explicite et qu'aucune politique applicable ne produit un Deny explicite.

Quels sont les 4 piliers de l'IAM ?

Les quatre piliers généralement mentionnés en gestion des identités sont : l'authentification (prouver qui vous êtes), l'autorisation (ce que vous avez le droit de faire), l'administration (gérer les identités et les politiques à grande échelle) et l'audit (journaliser et examiner l'activité d'accès). En termes AWS, ils correspondent respectivement aux mécanismes d'authentification IAM, aux politiques IAM, à AWS Organizations/IAM Identity Center et à AWS CloudTrail.

Quel est le lien entre AWS IAM et la conformité NIS2 ?

NIS2 impose aux entités essentielles et importantes de mettre en œuvre des politiques de contrôle d'accès proportionnées aux risques, de maintenir des capacités de réponse aux incidents et de démontrer la maîtrise des accès privilégiés. AWS IAM fournit les contrôles techniques — MFA, politiques de moindre privilège, SCP, journalisation CloudTrail — mais la conformité exige des processus documentés, des revues d'accès périodiques et la preuve que ces contrôles sont activement surveillés. Un SOC managé comble l'écart entre disposer des contrôles et prouver qu'ils fonctionnent.