Erreurs IAM critiques sur AWS

L'IAM est le centre de gravité de la sécurité sur AWS : qui peut faire quoi, sur quoi, et dans quelles conditions. Lors des audits IAM que nous réalisons, les mêmes erreurs reviennent quelle que soit la taille de l'organisation - startups, ETI, grands comptes. Ce sont ces configurations qui ouvrent les chemins d'abus les plus critiques.

1. Politiques avec wildcard sur les actions (Action: "*")

C'est l'erreur la plus fréquente et la plus sous-estimée. Une politique avec "Action": "*" accorde l'ensemble des actions AWS à l'identité concernée - y compris créer des utilisateurs, modifier des politiques, ou exfiltrer des données depuis n'importe quel service.

Politique trop large - à ne pas utiliser

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Le problème dépasse l'administrateur déclaré : on retrouve régulièrement ce pattern sur des rôles d'exécution Lambda, des rôles de pipeline CI/CD, ou des rôles de monitoring - des identités censées faire des opérations très circonscrites, mais dotées de tous les droits AWS faute de temps pour définir un périmètre précis.

Principe de moindre privilège - rôle Lambda limité à S3 et CloudWatch

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:PutObject"
  ],
  "Resource": "arn:aws:s3:::mon-bucket-prod/*"
},
{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "arn:aws:logs:eu-west-1:123456789012:log-group:/aws/lambda/ma-fonction:*"
}

Remédiation. Identifier toutes les politiques contenant "Action": "*" avec IAM Access Analyzer ou CloudSplaining. Remplacer par des listes d'actions explicites, service par service. Les pipelines CI/CD et les rôles Lambda sont les premières cibles.

2. Compte root sans MFA et avec clés d'accès actives

Le compte root AWS est le seul compte qui ne peut pas être restreint par des politiques IAM ou des SCP. Toute compromission du root est une compromission totale et irréversible du compte - sans garde-fou possible.

Deux configurations critiques à corriger en priorité :

• MFA absent sur le root : le compte root ne devrait jamais être accessible sans un second facteur matériel. Si l'email de récupération est compromis, le compte l'est aussi.
• Clés d'accès actives sur le root : ces clés permettent un accès programmatique au root sans aucune restriction. Elles ne devraient pas exister. AWS le signale lui-même dans Security Hub sous IAM.4.

Remédiation. Activer MFA matériel (clé FIDO2) sur le compte root. Supprimer toutes les access keys root existantes. Stocker les credentials root dans un coffre-fort hors ligne, avec accès tracé et nécessitant deux personnes (two-man rule).

3. Clés d'accès longue durée pour des humains

Les access keys (AKIA...) sont des credentials statiques : elles ne s'invalident pas d'elles-mêmes, peuvent être copiées, et circulent facilement dans des endroits non prévus - fichier ~/.aws/credentials committé, variable d'environnement dans une image Docker, log de CI/CD, fichier de configuration partagé.

En audit, on les retrouve régulièrement avec une ancienneté de 2 à 4 ans sans rotation, parfois attachées à des utilisateurs qui ont quitté l'organisation mais dont le compte IAM n'a pas été désactivé.

Lister les clés non utilisées depuis plus de 90 jours (AWS CLI)

aws iam generate-credential-report
aws iam get-credential-report --output text --query Content \
  | base64 -d \
  | awk -F, 'NR>1 && $9 != "N/A" {
      cmd="date -d \""$9"\" +%s"
      cmd | getline ts; close(cmd)
      age=int((systime()-ts)/86400)
      if(age>90) print $1, "clé non utilisée depuis", age, "jours"
    }'

Remédiation. Migrer vers des rôles IAM et des credentials temporaires (STS AssumeRole) pour les humains et les services. Pour les cas où des clés statiques sont inévitables (intégrations tierces sans support STS), implémenter une rotation automatique via AWS Secrets Manager. Désactiver toute clé inactive depuis plus de 90 jours.

4. Rôles EC2 et Lambda sur-permissifs (instance profiles)

Les rôles attachés aux instances EC2 et aux fonctions Lambda sont souvent surdimensionnés. La raison est prosaïque : au moment du développement, on attache un rôle large pour que « ça marche », et on ne revient jamais le réduire.

C'est un vecteur d'escalade majeur : ces instances se retrouvent souvent parmi les ressources orphelines du shadow cloud - lancées pour un test, jamais éteintes. Si l'application hébergée sur l'EC2 est compromise (injection, RCE), l'attaquant récupère les credentials du rôle via le metadata service (http://169.254.169.254/latest/meta-data/iam/security-credentials/) et peut agir avec toutes les permissions du rôle, depuis l'intérieur du VPC.

Récupération des credentials depuis le metadata service - ce qu'un attaquant fait en 10 secondes

# Depuis une instance EC2 compromise
ROLE=$(curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/)
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE
# Retourne AccessKeyId, SecretAccessKey, Token valides jusqu'à expiration

Remédiation. Activer IMDSv2 (obligatoire depuis 2023 sur les nouvelles instances) pour bloquer les accès non authentifiés au metadata service. Auditer les rôles d'instance avec aws iam simulate-principal-policy ou CloudSplaining. Appliquer le moindre privilège service par service.

5. Trust policies trop ouvertes sur les rôles cross-account

Les rôles assumés entre comptes (sts:AssumeRole) sont essentiels dans une landing zone multi-comptes. Mais leur trust policy - qui définit qui peut assumer le rôle - est souvent rédigée trop largement, parfois avec "AWS": "*" ou avec uniquement le compte comme condition, sans restreindre à un rôle ou un utilisateur précis.

Trust policy trop large - tout principal du compte 111122223333 peut assumer ce rôle

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

Trust policy resserrée - uniquement le rôle de déploiement CI/CD

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/github-actions-deploy"
  },
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "sts:ExternalId": "mon-external-id-unique"
    }
  }
}

Remédiation. Restreindre chaque trust policy au rôle ou à l'utilisateur précis qui a besoin d'assumer le rôle. Ajouter une condition ExternalId pour les rôles ouverts à des tiers. Auditer régulièrement avec IAM Access Analyzer, qui détecte les rôles accessibles depuis l'extérieur de l'organisation.

6. Chemins d'escalade via PassRole, CreateRole et CreatePolicy

C'est la famille d'erreurs la plus sous-estimée parce qu'elle n'est pas visible directement : une identité sans droits administrateurs peut néanmoins s'en attribuer via une combinaison d'actions IAM.

Quelques chemins classiques :

• iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction : créer une fonction Lambda avec un rôle admin, l'invoquer pour exécuter des actions en tant que ce rôle.
• iam:CreatePolicyVersion : si une identité peut créer de nouvelles versions d'une politique existante, elle peut en modifier le contenu - y compris pour s'accorder des droits supplémentaires.
• iam:AttachUserPolicy ou iam:AttachRolePolicy : attacher une politique plus permissive (ex. AdministratorAccess) à son propre utilisateur ou rôle.

Ces chemins sont difficiles à détecter manuellement. Des outils comme Pacu (module iam__privesc_scan) ou PMapper les identifient automatiquement en analysant le graphe des permissions.

Remédiation. Restreindre iam:PassRole à des rôles spécifiques via la condition iam:PassedToService. Ne jamais accorder iam:* en dehors des comptes d'administration dédiés. Scanner régulièrement les chemins d'escalade avec PMapper.

7. Absence de Service Control Policies (SCP) dans AWS Organizations

Les SCP sont les garde-fous organisationnels d'AWS : elles définissent le périmètre maximal des actions possibles dans un OU ou un compte, indépendamment des politiques IAM locales. Sans SCP, une mauvaise configuration dans n'importe quel compte membre peut avoir des conséquences non bornées.

Exemples de SCP défensives fondamentales :

• Bloquer la désactivation de CloudTrail (cloudtrail:StopLogging, cloudtrail:DeleteTrail).
• Bloquer la création de ressources hors des régions autorisées.
• Bloquer la suppression des buckets S3 de logs centraux.
• Exiger MFA pour toute action sur le compte root des comptes membres.

SCP - empêcher la désactivation de CloudTrail dans tous les comptes membres

{
  "Effect": "Deny",
  "Action": [
    "cloudtrail:StopLogging",
    "cloudtrail:DeleteTrail",
    "cloudtrail:UpdateTrail"
  ],
  "Resource": "*"
}

Remédiation. Définir une baseline SCP à appliquer à l'OU racine : blocage des régions non utilisées, protection des logs, restriction du root. Traiter les SCP comme du code (versionné, reviewé, testé en staging avant déploiement).

---

Comment détecter ces erreurs sur votre compte

Plusieurs outils permettent d'automatiser la détection avant un audit formel :

• IAM Access Analyzer (natif AWS, gratuit) : détecte les ressources accessibles depuis l'extérieur du compte ou de l'organisation - buckets S3, rôles IAM, clés KMS.
• AWS Security Hub avec le standard AWS Foundational Security Best Practices : remonte les contrôles IAM échoués (root MFA absent, clés non tournées, politiques trop larges).
• CloudSplaining (open source) : analyse les politiques IAM et génère un rapport HTML des violations de moindre privilège, classées par identité.
• PMapper (open source) : construit le graphe des permissions et identifie tous les chemins d'escalade de privilèges possibles dans votre account.
• Pacu (framework de pentest AWS) : simule les chemins d'abus en conditions réelles - voir notre article sur Pacu et CloudSplaining en audit IAM.

Vous préparez un durcissement IAM ou un contrôle régulier ? L'offre audit IAM AWS s'adapte à votre landing zone - interventions possibles partout en France, avec ateliers sur site si besoin (ex. Toulouse, Occitanie).