ITSkillsCenter
Business Digital

IAM AWS : utilisateurs, rôles, policies, MFA pas-à-pas — tutoriel SAA-C03 2026

11 min de lecture

Maîtriser AWS IAM : users, groups, roles, policies (managed et inline), trust policies, identity federation (SAML, Cognito), Service Control Policies via Organizations, MFA, access keys, AWS STS et assume-role, IAM Access Analyzer.

📍 À lire d’abord : Pilier AWS SAA-C03 · Compte AWS Free Tier.

Introduction

IAM (Identity and Access Management) est la pierre angulaire de la sécurité AWS. Il pèse ~25 % du domaine 1 (Secure Architectures = 30 %) du SAA-C03, soit 7-8 questions à l’examen. Maîtriser IAM est non-négociable.

Prérequis

  • Compte AWS configuré.
  • AWS CLI fonctionnel.
  • Compréhension JSON.
  • Niveau intermédiaire.
  • Temps : 2 heures.

Étape 1 — Concepts fondamentaux

User       : identité humaine (1 personne = 1 user, jamais partagé)
Group      : collection de users ayant les mêmes permissions
Role       : identité assumable temporairement (par EC2, Lambda, autre AWS service, autre compte)
Policy     : document JSON listant Allow/Deny d'actions sur ressources

Différence critique : User = credentials longue durée (password + access keys). Role = credentials temporaires (STS, expirent).

Étape 2 — Anatomie d’une policy IAM

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadOnBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::diallo-lab-2026",
        "arn:aws:s3:::diallo-lab-2026/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Composants : Effect (Allow/Deny), Action (verbe API), Resource (ARN), Condition (contraintes).

Ordre d’évaluation : 1) Deny explicite l’emporte toujours, 2) Sinon Allow explicite, 3) Sinon deny implicite par défaut.

Étape 3 — Créer user, group, policies

# Créer un group
aws iam create-group --group-name developers

# Attacher policy AWS-managed au group
aws iam attach-group-policy --group-name developers --policy-arn arn:aws:iam::aws:policy/PowerUserAccess

# Créer user
aws iam create-user --user-name fatou-dev

# Ajouter user au group
aws iam add-user-to-group --user-name fatou-dev --group-name developers

# Créer login profile (password)
aws iam create-login-profile --user-name fatou-dev --password "TempPwd2026!" --password-reset-required

# Créer access key (CLI/SDK)
aws iam create-access-key --user-name fatou-dev
# Output : AccessKeyId + SecretAccessKey (à transmettre via canal sécurisé)

Étape 4 — Roles et trust policies

Un role a 2 policies :
Trust policy : qui peut assumer ce role
Permissions policy : que peut faire ce role une fois assumé

Trust policy pour role assumable par EC2 :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
# Créer role
aws iam create-role --role-name EC2-S3-ReadOnly --assume-role-policy-document file://trust-policy.json

# Attacher permissions
aws iam attach-role-policy --role-name EC2-S3-ReadOnly --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Créer instance profile (lien role → EC2)
aws iam create-instance-profile --instance-profile-name EC2-S3-ReadOnly
aws iam add-role-to-instance-profile --instance-profile-name EC2-S3-ReadOnly --role-name EC2-S3-ReadOnly

# Attacher à instance EC2
aws ec2 associate-iam-instance-profile --instance-id i-xxx --iam-instance-profile Name=EC2-S3-ReadOnly

L’instance peut désormais lire S3 sans access keys hardcodées. C’est la best practice — JAMAIS de keys sur EC2.

Étape 5 — STS et credentials temporaires

# Cross-account access via assume-role
aws sts assume-role --role-arn arn:aws:iam::123456789:role/CrossAccountRole --role-session-name fatou-session

# Output : AccessKeyId + SecretAccessKey + SessionToken (expire après 1h par défaut, max 12h)

Use cases :
– Accès cross-account (compte A user assume role dans compte B)
– Federation : user enterprise (AD) accède AWS via SAML/OIDC, reçoit creds STS
– Cognito Identity Pool : utilisateur app mobile reçoit creds STS pour accès limité

Étape 6 — MFA et CLI

# Configurer MFA sur user
aws iam create-virtual-mfa-device --virtual-mfa-device-name fatou-mfa --outfile QRCode.png --bootstrap-method QRCodePNG
aws iam enable-mfa-device --user-name fatou --serial-number arn:aws:iam::xxx:mfa/fatou-mfa --authentication-code1 123456 --authentication-code2 654321

# CLI avec MFA pour actions sensibles
aws sts get-session-token --serial-number arn:aws:iam::xxx:mfa/fatou-mfa --token-code 123456 --duration-seconds 28800
# Utiliser les creds retournés (8h validité)

À l’examen : MFA pour toutes les actions sensibles (delete S3, terminate EC2). Implémenter via condition aws:MultiFactorAuthPresent: true dans policies.

Étape 7 — IAM Identity Center (anciennement SSO)

Pour multi-comptes (Organizations) :

1. Active IAM Identity Center
2. Crée des "permission sets" (rôles préconfigurés : ReadOnly, PowerUser, Admin)
3. Assigne users/groups à comptes + permission sets
4. Users se connectent via portail SSO unique
5. CLI : aws sso login --profile mon-profil

Recommandé 2026 vs IAM users individuels par compte. Federation possible avec Okta, Microsoft Entra, Google Workspace.

Étape 8 — Service Control Policies (SCP)

Avec AWS Organizations, SCP permet de restreindre les permissions au niveau OU/comptes.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideEU",
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["eu-west-3", "eu-west-1"] }
    }
  }]
}

Cette SCP empêche tout déploiement hors UE — utile pour conformité GDPR.

Étape 9 — IAM Access Analyzer

Audit automatique des permissions trop permissives :

1. IAM > Access Analyzer > Create analyzer
2. AWS scanne tous les ressources et alerte sur :
   - S3 bucket public
   - IAM role assumable depuis compte externe
   - KMS key partagée
   - Lambda function publique
3. Findings classés par criticité, à remédier

Gratuit, à activer Day 1.

Étape 10 — Best practices IAM

1. Compte root MFA + jamais utilisé au quotidien
2. Tous les users IAM avec MFA
3. Pas d'access keys sur instances EC2 → IAM Roles
4. Password policy : 14+ chars, complexité, rotation 90 jours
5. Principe least privilege : commencer policy minimale, élargir si besoin
6. Auditer régulièrement avec IAM Access Analyzer + Credential Report
7. Rotation des access keys tous les 90 jours
8. CloudTrail activé partout pour audit
9. SCP au niveau Organizations pour guardrails
10. Federation IAM Identity Center pour multi-comptes

Erreurs fréquentes

Erreur Solution
AccessDenied malgré policy Vérifier deny explicite ailleurs ou bucket policy
Cross-account ne marche pas Trust policy compte A doit autoriser, permissions policy compte B doit permettre
Access keys committées Git Révoquer immédiatement, rotation, audit CloudTrail
User créé sans groupe Permissions vides — toujours via group ou policy attachée
Role EC2 ne fonctionne pas Vérifier instance profile attaché à l’instance, pas juste role créé

Adaptation au contexte ouest-africain

Banques : IAM Identity Center + federation Active Directory + SCP strictes pour conformité PCI DSS. Audit trimestriel obligatoire.

Startups : compte unique avec users IAM + MFA suffisant pour < 10 personnes. Migration vers Organizations + Identity Center quand l’équipe grandit.

ESN cloud : un compte AWS par client + SCP isolation + cross-account roles pour intervention. Architecture standard 2026.

FAQ

User IAM ou Identity Center ?

User IAM : compte unique, équipe < 5. Identity Center : multi-comptes, équipes > 10, federation entreprise.

Quelle durée max session role ?

1h par défaut, 12h max configurable.

Combien de policies par user ?

Soft limit 10 managed policies attachées par user. Préférer attacher au group qui contient le user.

Pour aller plus loin


Mots-clés : AWS IAM users groups roles, policy JSON, trust policy, IAM Identity Center SSO, Service Control Policies, AWS STS assume-role, MFA AWS, IAM Access Analyzer.


Approfondissement et cas pratiques

Études de cas réelles AWS en Afrique de l’Ouest

Cas 1 — Fintech mobile money, Dakar, 2025. Une fintech sénégalaise traite 4 millions de transactions/mois (Orange Money agrégé). Architecture AWS : ALB multi-AZ (eu-west-3) + ECS Fargate auto-scaling 8-50 tasks + Aurora Serverless v2 PostgreSQL (1-32 ACU) + DynamoDB pour ledger transactionnel + ElastiCache Redis pour sessions + S3 + CloudFront pour static. Coût mensuel 4 200 USD, soit 0.001 USD par transaction. Disponibilité mesurée 99,98 % sur 12 derniers mois. RTO 4 minutes via Multi-AZ failover Aurora.

Cas 2 — E-commerce panafricain, Abidjan/Dakar/Lagos, 2024. Plateforme avec 80 000 visiteurs/jour. Architecture multi-region active-active : eu-west-3 (Paris, principal pour AO/UE) + af-south-1 (Cape Town, secondaire pour Afrique australe) + Route 53 latency-based routing. Réplication Aurora Global Database, S3 Cross-Region Replication, DynamoDB Global Tables. CloudFront edge locations couvrant Lagos, Casablanca, Johannesburg. Coût 8 500 USD/mois, ROI prouvé par augmentation 23 % du taux conversion grâce à latence < 200ms partout en Afrique.

Cas 3 — Migration banque traditionnelle vers AWS, 2024-2025. Banque ivoirienne avec 18 ans d’historique on-prem (datacenter Plateau Abidjan + DR Yamoussoukro). Migration AWS lift-and-shift 80 % des workloads en 14 mois. Stack : VPC hub-and-spoke avec Transit Gateway, AWS Directory Service pour AD legacy, RDS pour Oracle SAP, EC2 dedicated hosts pour licences Microsoft, AWS Backup avec immutability pour conformité, AWS Control Tower pour gouvernance. Économie 40 % vs datacenter on-prem dès l’année 1, montée à 55 % en année 3.

Cinq scénarios SAA-C03 type examen détaillés

Scénario 1 : architecture e-commerce HA pour Black Friday. App attendue à 100x charge normale en 4h. Réponse : ALB + ASG avec scheduled scaling (lance 50 instances 30 min avant), CloudFront pour cache statique, Aurora Read Replicas pour scale read, ElastiCache Redis cluster mode pour sessions, SQS pour découpler order processing.

Scénario 2 : DR cross-region. Compagnie demande RTO 30 min, RPO 5 min. Réponse : Pilot Light pattern, primary eu-west-3, secondary eu-west-1 avec Aurora Global Database (lag < 1s) + AMI répliquées + Route 53 health checks failover automatique.

Scénario 3 : sécurisation données sensibles. Application stocke PII clients. Réponse : S3 SSE-KMS avec CMK, encryption EBS, RDS encrypted, KMS key rotation auto annuelle, IAM least privilege, CloudTrail logs vers S3 Object Lock immutable, GuardDuty actif, Macie pour découverte automatique PII.

Scénario 4 : optimisation coût legacy. Compte AWS avec 250 instances EC2 mostly idle nuit/weekend. Réponse : Instance Scheduler pour stop/start automatique, Reserved Instances 1 an pour baseline 24/7, Spot Instances pour batch processing, S3 Intelligent-Tiering, Compute Savings Plans 3 ans pour stack permanente. Économie attendue 65-75 %.

Scénario 5 : conformité PCI DSS. Architecture e-commerce processant cartes. Réponse : segmentation VPC stricte (CDE = Cardholder Data Environment isolé), AWS WAF + Shield Advanced, CloudHSM pour clés PCI, AWS Config rules pour conformité continue, AWS Inspector pour scan vuln, GuardDuty + Security Hub, CloudTrail multi-region, AWS Audit Manager pour rapports.

Architecture cloud-native moderne 2026

[Route 53 latency-based] → [CloudFront global edges]
                              ↓
                      [WAF + Shield Advanced]
                              ↓
              [API Gateway HTTP API ou Application Load Balancer]
                              ↓
       ┌────────────────────────┼────────────────────────┐
       ↓                        ↓                        ↓
  [Lambda functions]    [ECS Fargate tasks]     [EKS pods auto-scaled]
  pour serverless       pour containers         pour orchestration
       ↓                        ↓                        ↓
       └────────┬───────────────┴────────┬───────────────┘
                ↓                        ↓
         [Aurora Serverless v2]    [DynamoDB on-demand]
         pour relational           pour NoSQL haute scale
                ↓                        ↓
         [ElastiCache Redis cluster]
                ↓
         [S3 Intelligent-Tiering + Glacier lifecycle]
         pour archives
                ↓
[Observability : CloudWatch + X-Ray + EventBridge + Step Functions]
[Sécurité : IAM + KMS + Secrets Manager + GuardDuty + Security Hub]
[Gouvernance : Organizations + SCP + Control Tower + Config]

Cette architecture cloud-native moderne sert de référence pour les startups et scale-ups ouest-africaines qui veulent éviter le legacy ops.

Coûts détaillés en FCFA pour cas réel PME

PME 30 employés, 1 application web SaaS, 10 000 utilisateurs actifs/mois :

Service                                        Coût/mois
-------                                        ---------
EC2 t3.medium x2 (ALB + workers)              90 USD
RDS db.t3.micro Multi-AZ                      28 USD
S3 + CloudFront (50 Go transfer)              35 USD
ALB + Route 53                                25 USD
Backup + monitoring                           15 USD
NAT Gateway (alternative : NAT Instance)      32 USD (ou 8 USD)
                                              ---------
Total                                         225 USD/mois
                                              ≈ 135 000 FCFA/mois
                                              ≈ 1 620 000 FCFA/an

Vs hébergement OVH/Hetzner classique : ~80 USD/mois mais sans HA, sans CDN, sans backup automatisé. AWS premium justifié pour fiabilité + scaling.

Avec Reserved Instances 3 ans : 35 % économie → 145 USD/mois ≈ 87 000 FCFA/mois.

Plan de carrière post-AWS SAA détaillé

0-12 mois : décrocher poste cloud engineer junior dans ESN cloud (Smart Africa, ETRILABS, Kasi Insight, agences Microsoft/AWS partner) ou directement chez client final (banque, opérateur, fintech). Salaire 800 000-1 200 000 FCFA. Activités : provisioning Terraform, déploiement CI/CD, monitoring CloudWatch, support N1/N2.

12-30 mois : monter compétence DevOps + sécurité cloud. Certifications cibles : AWS DevOps Pro (DOP-C02) ou AWS Security Specialty (SCS-C02). Salaire 1 400 000-2 000 000 FCFA. Activités : automation IaC, optimisation coûts (FinOps), implémentation Zero Trust, gestion incidents production.

30-60 mois : positions architecte ou tech lead. Cert AWS Solutions Architect Professional (SAP-C02). Salaire 2 200 000-3 500 000 FCFA local, 4-7 millions FCFA en remote international.

60+ mois : Cloud Architect senior, Engineering Manager, Principal Engineer ou freelance/consulting. Plateformes remote : Toptal, Malt, A.Team, Andela. Tarifs day rate 400-800 USD pour profils seniors AWS+Kubernetes+AI/ML.

Outils et frameworks complémentaires

IaC : Terraform (cross-cloud, le plus utilisé en 2026), AWS CDK (Python/TypeScript), Pulumi (alternative moderne), CloudFormation (legacy mais utile pour AWS-specific).

CI/CD : GitHub Actions (le plus populaire), GitLab CI, AWS CodePipeline (intégré AWS), CircleCI, Jenkins (legacy).

Container orchestration : Amazon ECS (managed), Amazon EKS (Kubernetes), Fargate (serverless containers).

Observability : CloudWatch (de base), Datadog (premium SaaS), New Relic, Grafana Cloud avec Prometheus.

FinOps : AWS Cost Explorer + Budgets + Compute Optimizer, Vantage.sh (alternative), CloudHealth, Apptio Cloudability.

Security : Prowler (audit script open-source), Cloudsploit, AWS Security Hub, Wiz, Lacework.

Besoin d'un site web ?

Confiez-nous la Création de Votre Site Web

Site vitrine, e-commerce ou application web — nous transformons votre vision en réalité digitale. Accompagnement personnalisé de A à Z.

À partir de 250.000 FCFA
Parlons de Votre Projet
Publicité