This is who IAM

AWS Identity and Access Management (IAM) est un service fondamental qui permet de contrôler de manière granulaire l'accès aux ressources AWS. Bien configuré, IAM garantit la sécurité, la conformité et la productivité dans l’utilisation du cloud.

I. IAM : Composants et concepts de base  

IAM repose sur des entités et des stratégies.

Entités IAM  

• Utilisateurs : Représentent des personnes ou des applications. Ex : un développeur nommé “alice”.
• Groupes : Collections d’utilisateurs partageant les mêmes autorisations.
• Rôles : Entités IAM que d’autres entités peuvent assumer temporairement. Idéal pour les cas de fédération ou les services comme EC2 ou Lambda.
• Politiques (Policies) : Fichiers JSON qui définissent les autorisations attachées à une entité.

Exemple de politique JSON  

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example_bucket"
    }
  ]
}

Cette politique IAM permet à une entité AWS (utilisateur, rôle ou groupe) de lister les objets contenus dans un bucket S3 spécifique nommé example_bucket. Elle utilise la version standard du langage de politique (2012-10-17) et applique un effet “Allow” à l’action “s3:ListBucket” sur la ressource identifiée par son ARN (arn:aws:s3:::example_bucket). Cela signifie que l’entité pourra voir la liste des objets dans ce bucket (noms, tailles, métadonnées), mais ne pourra ni lire, ni modifier les fichiers eux-mêmes, sauf si d’autres permissions sont ajoutées. C’est une politique minimale, souvent utilisée dans des scénarios d’inventaire ou de navigation dans un bucket via l’API ou la console AWS.

II. Gestion des permissions : du principe de moindre privilège à la délégation  

IAM repose sur la règle du Least Privilege : chaque entité ne reçoit que les permissions strictement nécessaires.

Contrôle d’accès basé sur les ressources  

Certaines ressources AWS permettent un contrôle fin des accès. Ex :

• S3 : autorisations au niveau du bucket et des objets.
• Lambda : autorisations sur l’invocation, la gestion et les logs.
• DynamoDB : accès aux tables, items ou opérations précises.

Tableau comparatif : stratégie vs contrôle au niveau du service  

III. Cas d’usage concrets : IAM en action  

1. Application web avec utilisateurs externes  

Utilisation de Cognito pour gérer l’authentification, puis IAM attribue des rôles temporaires via des identifiants JWT pour accéder à S3 ou DynamoDB.

2. Déploiement sécurisé avec IAM Roles for Service Accounts (IRSA)  

Dans un cluster EKS, on associe un rôle IAM à un service Kubernetes pour limiter ses accès aux seuls buckets S3 nécessaires.

3. Audit et conformité  

IAM s’intègre avec AWS CloudTrail pour tracer chaque appel d’API, utile pour :

• les audits de sécurité,
• la détection d’anomalies,
• le respect des réglementations (RGPD, HIPAA…).

IV. Bonnes pratiques et recommandations  

• Éviter l’utilisation de l’utilisateur root sauf pour des opérations critiques.
• Activer l’authentification multifactorielle (MFA) pour les utilisateurs humains.
• Segmenter les permissions à l’aide de rôles par projet, par environnement (dev, staging, prod).
• Analyser régulièrement les permissions à l’aide d’AWS IAM Access Analyzer.
• Utiliser des permissions conditionnelles pour ajouter des contraintes (heure, IP, tag, etc.).

V. Point sur les politiques conditionnelles IAM  

A. Introduction  

Les politiques conditionnelles IAM permettent d’ajouter des règles dynamiques et contextuelles aux autorisations. Elles sont clés pour limiter les accès selon :

• L’adresse IP,
• L’heure,
• Les tags sur les ressources,
• L’état de l’authentification MFA, etc.

B. Structure d’une condition dans IAM  

Une clause Condition s’ajoute dans un bloc Statement JSON. Exemple :

{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

Cette politique IAM autorise toutes les actions (“s3:”) sur toutes les ressources S3 (“Resource”: “”) uniquement si la requête provient d’une adresse IP incluse dans le bloc 203.0.113.0/24. La clause Condition permet ici d’ajouter une règle contextuelle : elle restreint l’accès en fonction de l’adresse IP source (aws:SourceIp). Ce type de condition renforce la sécurité en limitant l’usage des permissions à un périmètre réseau spécifique, souvent celui d’un bureau ou d’un VPN d’entreprise.

C. Types courants de conditions  

D. Études de cas  

Cas 1 : Accès uniquement pendant les heures ouvrées  

"Condition": {
  "DateGreaterThan": { "aws:CurrentTime": "2025-04-09T08:00:00Z" },
  "DateLessThan": { "aws:CurrentTime": "2025-04-09T18:00:00Z" }
}

Cas 2 : Refus d’accès sans MFA  

"Condition": {
  "BoolIfExists": {
    "aws:MultiFactorAuthPresent": "true"
  }
}

Cas 3 : Autorisation basée sur les tags  

"Condition": {
  "StringEquals": {
    "aws:RequestTag/Environment": "prod"
  }
}

E. Bonnes pratiques  

• Toujours tester avec IAM Policy Simulator.
• Privilégier des politiques courtes et modulaires.
• Utiliser les conditions pour restreindre au maximum les accès temporaires.
• Combiner avec AWS Organizations et SCP pour un contrôle total.

VI. Combiner IAM et AWS Organizations  

A. Pourquoi utiliser une architecture multi-compte  

Une structure multi-compte AWS offre :

• Isolation des environnements (prod, dev, test),
• Limitation de la surface d’attaque,
• Séparation des responsabilités entre équipes,
• Contrôle granulaire des coûts.

Mais cela complexifie la gestion des permissions, d’où l’utilité d’AWS Organizations.

B. Présentation d’AWS Organizations  

AWS Organizations permet de :

• Créer une hiérarchie logique de comptes via des organizational units (OU),
• Appliquer des Service Control Policies (SCP) globales,
• Centraliser la gestion budgétaire et de la facturation.

Les SCP définissent ce qu’un compte peut ou ne peut pas faire, indépendamment des stratégies IAM internes.

C. Comment fonctionnent les Service Control Policies (SCP)  

Les SCP s’appliquent au niveau du compte ou de l’OU. Elles filtrent les permissions effectives.

🔐 Important : une stratégie IAM ne peut jamais outrepasser une SCP.

D. Mise en œuvre : exemple d’organisation  

1. Créez une organisation avec AWS Organizations.
2. Ajoutez des OUs : prod, dev, sandbox.
3. Attachez une SCP restrictive à sandbox :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "ec2:*",
      "Resource": "*"
    }
  ]
}

4. Donnez des permissions plus permissives via IAM dans dev.

E. Cross-account avec IAM  

Pour permettre à un rôle ou utilisateur d’un compte A d’agir sur les ressources du compte B :

• Créez un rôle IAM dans le compte B, accessible par le compte A.
• Utilisez une stratégie AssumeRole.

Exemple dans le compte B :

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
  "Action": "sts:AssumeRole"
}

Conclusion  

AWS IAM est un pilier central de toute stratégie de sécurité cloud. Bien que sa configuration initiale puisse sembler complexe, elle est essentielle pour garantir un environnement AWS sûr, structuré et évolutif. En maîtrisant ses concepts et en appliquant les bonnes pratiques, vous construisez des fondations robustes pour vos projets cloud.

🔗 Ressource utile  

• Présentation officielle AWS IAM