Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi.

TL;DR — Groupes IAM vs. Politiques Directes

Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM
Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs
Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit
Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit
Conformité (moindre privilège) Difficile à maintenir uniformément Appliqué de façon cohérente par construction
Limite de politiques attachées 10 politiques gérées par utilisateur 10 politiques gérées par groupe

Comment Fonctionnent les Groupes IAM

Un groupe IAM n'est pas une identité — il ne peut pas s'authentifier, il ne peut pas assumer un rôle, et il n'apparaît pas dans une politique de confiance. C'est un conteneur logique qui propage ses politiques attachées à tous ses membres au moment de l'évaluation des permissions.

Quand un utilisateur IAM appartient à un groupe, AWS évalue ses permissions effectives en agrégeant toutes les politiques attachées directement à l'utilisateur et toutes les politiques attachées à chacun de ses groupes. Un utilisateur peut appartenir à plusieurs groupes simultanément — les permissions s'additionnent, sous réserve qu'aucun Explicit Deny ne les annule.

graph LR Alice["Utilisateur: alice"] --> GDev["Groupe: Developers"] Alice --> GRO["Groupe: ReadOnly"] Bob["Utilisateur: bob"] --> GDev GDev --> PDev["Politique: DeveloperCustomPolicy"] GDev --> PEC2["Politique: AmazonEC2ReadOnlyAccess"] GRO --> PRO["Politique: ReadOnlyAccess"] PDev --> Eval["Évaluation IAM
Agrégation des permissions"] PEC2 --> Eval PRO --> Eval Eval --> Decision{"Décision finale"} Decision -->|"Allow trouvé,
pas de Deny explicite"| Allow["✅ Accès autorisé"] Decision -->|"Deny explicite
ou pas d'Allow"| Deny["❌ Accès refusé"]
  1. Utilisateur IAM : l'identité qui s'authentifie. Peut appartenir à zéro ou plusieurs groupes.
  2. Groupe 'Developers' : reçoit la politique DeveloperPolicy. Tous ses membres héritent de cette politique.
  3. Groupe 'ReadOnly' : un utilisateur peut appartenir aux deux groupes — les permissions s'agrègent.
  4. Évaluation IAM : AWS collecte toutes les politiques applicables (utilisateur + groupes) avant de statuer sur la requête.
  5. Explicit Deny : si une politique quelconque contient un Deny explicite, il l'emporte sur tous les Allow, quelle que soit leur source.

Pourquoi les Politiques Directes sur les Utilisateurs Deviennent un Problème

L'approche 'une politique par utilisateur' semble raisonnable pour deux ou trois comptes. Le vrai coût apparaît lors des audits de sécurité ou des départs d'employés.

Imaginez un audit SOC 2 : l'auditeur demande 'qui a accès à quoi ?' Si chaque utilisateur porte ses propres politiques, la réponse nécessite d'inspecter chaque compte individuellement. Avec des groupes, la réponse est immédiate : 'le groupe Developers a cette politique, voici ses membres.'

Penser les permissions IAM utilisateur par utilisateur, c'est comme gérer les droits d'accès d'un immeuble en changeant la serrure de chaque appartement plutôt qu'en contrôlant l'accès à l'étage. Ça fonctionne jusqu'au jour où vous avez cent appartements.

Le problème le plus fréquent en production : l'offboarding incomplet. Un utilisateur quitte l'entreprise, son compte est désactivé — mais les politiques directement attachées restent en place. Si le compte est réactivé par erreur (ça arrive), les permissions sont toujours là. Avec un groupe, retirer l'utilisateur du groupe suffit, indépendamment de l'état du compte.

Créer un Groupe IAM et Attacher une Politique — Procédure Complète

Voici la séquence complète pour créer un groupe Developers, lui attacher une politique gérée AWS, et y ajouter un utilisateur existant.

Étape 1 — Créer le groupe IAM

Cette étape crée le conteneur logique. Sans groupe, chaque utilisateur doit être géré individuellement — c'est précisément ce qu'on cherche à éviter.

aws iam create-group \
  --group-name Developers

Étape 2 — Attacher une politique gérée au groupe

On attache la politique au groupe, pas à l'utilisateur. Tous les membres actuels et futurs du groupe hériteront automatiquement de cette politique — c'est le point central de l'approche.

aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Étape 3 — Ajouter un utilisateur au groupe

L'utilisateur hérite immédiatement des permissions du groupe dès son ajout. Aucune modification de politique individuelle n'est nécessaire.

aws iam add-user-to-group \
  --group-name Developers \
  --user-name alice

Étape 4 — Vérifier les permissions effectives de l'utilisateur

Après ajout, vérifiez que les politiques du groupe sont bien visibles sur l'utilisateur. Cette commande liste les politiques attachées aux groupes dont l'utilisateur est membre — c'est différent des politiques directement attachées à l'utilisateur.

aws iam list-groups-for-user \
  --user-name alice
aws iam list-attached-group-policies \
  --group-name Developers

Étape 5 — Auditer les politiques directement attachées à l'utilisateur

Si vous migrez depuis une configuration existante avec des politiques directes, identifiez et retirez les politiques redondantes sur les utilisateurs. Des permissions dupliquées entre l'utilisateur et son groupe ne causent pas d'erreur, mais compliquent l'audit et violent le principe de moindre privilège par accumulation non intentionnelle.

aws iam list-attached-user-policies \
  --user-name alice
# Si une politique doit être retirée de l'utilisateur après migration vers le groupe :
aws iam detach-user-policy \
  --user-name alice \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Créer une Politique Personnalisée et l'Attacher au Groupe

Les politiques gérées AWS couvrent des cas génériques. En production, vous aurez souvent besoin de politiques personnalisées — par exemple, limiter l'accès à un bucket S3 spécifique ou à une région particulière.

🔽 Exemple : Politique personnalisée pour le groupe Developers (cliquer pour développer) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3BucketAccess",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::mon-bucket-dev",
        "arn:aws:s3:::mon-bucket-dev/*"
      ]
    },
    {
      "Sid": "AllowEC2Describe",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*"
      ],
      "Resource": "*"
    }
  ]
}
# Créer la politique personnalisée
aws iam create-policy \
  --policy-name DeveloperCustomPolicy \
  --policy-document file://developer-policy.json
# Attacher la politique personnalisée au groupe
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::123456789012:policy/DeveloperCustomPolicy

Notez la différence d'ARN : les politiques gérées AWS utilisent arn:aws:iam::aws:policy/... (sans identifiant de compte), tandis que les politiques personnalisées utilisent arn:aws:iam::123456789012:policy/... avec votre identifiant de compte.

Le Piège Classique : Symptôme, Mauvais Diagnostic, Cause Réelle

Scénario réel : un développeur signale qu'il ne peut plus lister les objets d'un bucket S3 alors qu'il le pouvait hier. Vous vérifiez la politique du groupe Developers — elle est correcte, s3:ListBucket est bien présent. Vous vérifiez la politique du bucket — rien d'anormal.

Mauvais réflexe : supposer que la politique du groupe ne s'applique pas correctement et ajouter une politique directe sur l'utilisateur 'pour débloquer rapidement'.

Cause réelle : l'utilisateur avait une politique directement attachée contenant un Deny explicite sur s3:*, résidu d'une configuration temporaire jamais nettoyée. Un Explicit Deny dans n'importe quelle politique applicable à l'utilisateur annule tous les Allow, y compris ceux du groupe.

La commande qui révèle le problème :

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/alice \
  --action-names s3:ListBucket \
  --resource-arns arn:aws:s3:::mon-bucket-dev

Le résultat implicitDeny ou explicitDeny dans la réponse indique exactement quelle politique bloque l'accès et pourquoi. C'est l'outil de diagnostic à utiliser en premier, pas en dernier.

graph TD Req["Requête API utilisateur"] --> Collect["Collecte des politiques
Directes + Groupes"] Collect --> CheckDeny{"Explicit Deny
présent ?"} CheckDeny -->|"Oui"| ForceDeny["❌ Refus immédiat
Explicit Deny"] CheckDeny -->|"Non"| CheckAllow{"Allow correspondant
trouvé ?"} CheckAllow -->|"Oui"| Grant["✅ Accès accordé"] CheckAllow -->|"Non"| ImplicitDeny["❌ Refus par défaut
Implicit Deny"]
  1. Requête API : l'utilisateur tente s3:ListBucket.
  2. Collecte des politiques : IAM agrège toutes les politiques — directes sur l'utilisateur, et celles de chaque groupe dont il est membre.
  3. Vérification Explicit Deny : si un Deny explicite est trouvé dans n'importe quelle politique, la décision est immédiatement Deny, sans évaluation des Allow.
  4. Vérification Allow : si aucun Deny explicite, IAM cherche un Allow correspondant dans l'ensemble des politiques collectées.
  5. Implicit Deny par défaut : si aucun Allow n'est trouvé, la requête est refusée par défaut.

Bonnes Pratiques Opérationnelles pour les Groupes IAM

Quelques points qui ne sont pas évidents à la lecture de la documentation :

  • Un utilisateur peut appartenir à plusieurs groupes — les permissions s'additionnent. Utilisez cela pour composer des accès : un groupe BaseAccess pour tous, un groupe S3WriteAccess pour ceux qui en ont besoin.
  • Les groupes ne peuvent pas être imbriqués — un groupe ne peut pas être membre d'un autre groupe. Si vous avez besoin de hiérarchies de permissions, composez via l'appartenance multiple à des groupes.
  • Nommez les groupes par fonction, pas par équipe organisationnelle — les équipes changent, les fonctions techniques sont plus stables. S3ReadOnly survivra à trois réorganisations, EquipeAlpha non.
  • Auditez régulièrement les membres des groupes — un groupe sans membres actifs avec des politiques puissantes est un risque latent.
# Lister tous les membres d'un groupe
aws iam get-group \
  --group-name Developers \
  --query 'Users[*].UserName' \
  --output table
# Lister tous les groupes et leurs politiques attachées
aws iam list-groups

Politique IAM Minimale pour Gérer les Groupes

Si vous déléguez la gestion des groupes IAM à un administrateur junior ou à un outil d'automatisation, voici la politique minimale requise. Notez que les actions List et Get sur IAM requièrent généralement Resource: "*" — vérifiez la Service Authorization Reference pour chaque action avant de restreindre.

🔽 Politique IAM pour la gestion des groupes (cliquer pour développer) 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ManageIAMGroups",
      "Effect": "Allow",
      "Action": [
        "iam:CreateGroup",
        "iam:DeleteGroup",
        "iam:GetGroup",
        "iam:ListGroups",
        "iam:AddUserToGroup",
        "iam:RemoveUserFromGroup",
        "iam:AttachGroupPolicy",
        "iam:DetachGroupPolicy",
        "iam:ListAttachedGroupPolicies",
        "iam:ListGroupsForUser"
      ],
      "Resource": "*"
    }
  ]
}

Conclusion — Groupes IAM : La Bonne Unité de Gestion des Permissions

Attacher des politiques directement aux utilisateurs IAM est une dette technique qui s'accumule silencieusement. Les groupes IAM ne sont pas une fonctionnalité avancée — c'est le modèle de base pour toute gestion d'accès sérieuse. Dès que vous avez plus d'un utilisateur avec des besoins similaires, le groupe est la bonne unité d'organisation.

Pour aller plus loin, explorez les rôles IAM pour les accès inter-services et inter-comptes, et AWS IAM Identity Center (anciennement SSO) pour la gestion centralisée des accès à grande échelle.

Glossaire

Terme Définition
Groupe IAM Conteneur logique d'utilisateurs IAM permettant de propager des politiques à tous ses membres. Ne peut pas s'authentifier ni assumer un rôle.
Politique gérée AWS Politique prédéfinie et maintenue par AWS, réutilisable sur plusieurs identités. Identifiée par un ARN sans identifiant de compte.
Politique personnalisée Politique créée et maintenue par le client dans son compte AWS. L'ARN inclut l'identifiant de compte.
Explicit Deny Instruction Deny dans une politique IAM qui annule tout Allow applicable, quelle que soit sa source.
Moindre privilège Principe de sécurité consistant à n'accorder que les permissions strictement nécessaires à l'accomplissement d'une tâche.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite