Ethical Hacking Academy · Leçon

Mauvaises configurations IAM

Rôles trop permissifs

Leçon 2 sur 413 étapes

Mauvaises configurations IAM est une leçon Ethical Hacking Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Ethical Hacking Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Ethical Hacking Academy comprend 4 leçons au total.

Pourquoi IAM est le véritable périmètre

Dans le cloud, l’identité est le nouveau périmètre. IAM (gestion des identités et des accès) détermine qui peut faire quoi. Une faille dans IAM permet à un attaquant de passer d’un point d’appui faiblement privilégié au contrôle complet du compte.

Les utilisateurs, les rôles et les comptes de service sont des identités
Les politiques définissent les autorisations
Les politiques mal configurées constituent le principal risque lié au cloud

La plupart des escalades de privilèges dans le cloud sont liées à IAM.

Utilisateurs, rôles et politiques

AWS IAM comporte trois éléments fondamentaux que vous devez comprendre :

Utilisateurs — identités à longue durée de vie disposant de clés d’accès
Rôles — identités temporaires qui peuvent être assumées par des utilisateurs ou des services
Politiques — documents JSON qui autorisent ou refusent des actions sur des ressources

Une politique associée de manière trop large est à l’origine de l’attribution excessive d’autorisations.

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*"
}

Le danger des caractères génériques

Le schéma IAM le plus dangereux est la politique utilisant un caractère générique. Elle accorde toutes les actions sur toutes les ressources.

Si un attaquant compromet une identité associée à cette politique, il prend le contrôle de l’intégralité du compte.

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

# Action:* Resource:* = full administrative control.
# Flag this everywhere it appears outside a break-glass admin role.

Énumérer ses propres autorisations

Une fois en possession d’un identifiant, dressez la liste de ce qu’il permet de faire. IAM dispose d’API de lecture qui révèlent les politiques associées.

Certains comptes accordent même iam:Get* et iam:List* aux utilisateurs ordinaires, vous fournissant ainsi gratuitement une cartographie.

# List policies attached to a user
aws iam list-attached-user-policies --user-name devuser

# Get the JSON of a managed policy version
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess \
  --version-id v1

Escalade de privilèges via iam:PassRole

Un scénario d’escalade classique : un utilisateur dispose de iam:PassRole ainsi que d’une autorisation de création de services. Il peut lancer une ressource qui assume un rôle hautement privilégié et en hérite les accès.

L’utilisateur possède ec2:RunInstances + iam:PassRole
Il lance une instance EC2 à laquelle est associé un rôle d’administrateur
L’instance détient alors des identifiants d’administrateur, qu’il récupère

L’utilisateur ne disposait jamais directement des privilèges d’administrateur, mais il les a obtenus par escalade.

Combinaisons d’autorisations dangereuses

Des autorisations individuelles peuvent être inoffensives, mais devenir des chemins d’escalade lorsqu’elles sont combinées. Parmi les combinaisons connues comme risquées :

iam:CreatePolicyVersion — réécrire une politique existante pour accorder les privilèges d’administrateur
iam:AttachUserPolicy — vous associer AdministratorAccess
iam:CreateAccessKey sur un autre utilisateur — usurper son identité
sts:AssumeRole sur un rôle qui accorde une confiance excessive

Les outils énumèrent automatiquement ces possibilités.

Politiques de confiance et AssumeRole

Les rôles disposent d’une politique de confiance qui définit qui peut les assumer. Une politique de confiance trop permissive constitue une porte dérobée.

Si un rôle fait confiance à l’ensemble du compte, voire par erreur à un compte externe, un attaquant peut l’assumer.

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

# Trusting the entire account root means ANY identity in it can assume the role.

Automatiser la découverte des escalades

Vérifier manuellement toutes les combinaisons de politiques est fastidieux. Les outils cartographient les chemins d’escalade pour vous.

Pacu — cadre d’exploitation AWS avec des modules d’escalade de privilèges
PMapper — représente les relations IAM sous forme de graphe et trouve les liens d’escalade de privilèges
enumerate-iam — teste systématiquement les appels d’API qu’une clé peut effectuer

# Run Pacu's IAM privilege escalation enumeration
pacu
# > run iam__privesc_scan

# Build an IAM access graph and query it
pmapper graph create
pmapper query 'preset privesc *'

Politiques intégrées et gérées

Les autorisations peuvent être accordées de deux façons, et les attaquants vérifient les deux :

Politiques gérées — réutilisables et associées à plusieurs identités
Politiques intégrées — intégrées directement à un utilisateur ou à un rôle

Les politiques intégrées sont faciles à manquer lors des audits ; elles dissimulent donc souvent des autorisations excessives. Énumérez toujours les deux types lors de l’évaluation d’une identité.

# Inline policies are listed separately from attached ones
aws iam list-user-policies --user-name devuser
aws iam get-user-policy --user-name devuser --policy-name custom-inline

Renforcement : moindre privilège

La solution aux mauvaises configurations IAM est le moindre privilège : n’accorder que les autorisations strictement nécessaires.

Remplacez les caractères génériques par des actions explicites et des ARN de ressources
Utilisez des rôles avec des identifiants à courte durée de vie plutôt que des clés à longue durée de vie
Vérifiez les autorisations inutilisées avec Access Analyzer
Imposez MFA aux identités privilégiées

Votre rapport doit associer chaque constat à une mesure corrective fondée sur le moindre privilège.

Respecter l’autorisation

Les tests d’escalade de privilèges modifient activement l’état du compte. Soyez prudent :

La création de politiques, de clés ou de rôles est intrusive ; obtenez une autorisation écrite
Documentez chaque modification afin de pouvoir l’annuler
Privilégiez l’énumération en lecture seule pour démontrer un chemin avant de l’exploiter

Démontrer qu’un chemin d’escalade de privilèges existe suffit souvent ; vous n’avez pas toujours besoin de l’exploiter complètement.

Vérification rapide

Quelle combinaison d’autorisations constitue un chemin classique d’escalade de privilèges AWS ?

Réponds-y dans la leçon interactive

Récapitulatif : mauvaises configurations IAM

Vous avez appris pourquoi IAM est le véritable périmètre du cloud et comment les attaquants l’exploitent.

Les politiques utilisant Action:* Resource:* sont catastrophiques
iam:PassRole + création de services permet l’escalade de privilèges
Les politiques de confiance trop permissives permettent aux attaquants d’assumer des rôles
Des outils comme Pacu et PMapper automatisent la découverte des chemins
La correction repose toujours sur le moindre privilège

Nous examinerons ensuite S3 et l’exposition du stockage.

Gratuit pour commencer

Apprends Ethical Hacking Academy avec un tuteur IA — gratuit

Écris et exécute du vrai code dans ton navigateur, obtiens de l'aide instantanée d'un tuteur IA disponible 24h/24, et reprends là où tu t'es arrêté sur le web ou dans l'app.

Cours: 31
Leçons: 111

Commencer gratuitement Voir le cours complet

Questions Fréquemment Posées

La leçon « Mauvaises configurations IAM » est-elle gratuite ?

Oui — le texte complet de « Mauvaises configurations IAM » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Ethical Hacking Academy, passe à CoddyKit PRO. Le cours Ethical Hacking Academy comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Mauvaises configurations IAM » ?

Rôles trop permissifs Tu pratiques Ethical Hacking Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Ethical Hacking Academy ?

Aucune expérience préalable n'est requise. Ethical Hacking Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Mauvaises configurations IAM » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Ethical Hacking Academy ?

Oui. Chaque leçon Ethical Hacking Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

← Retour à Ethical Hacking Academy