Comment auditer les permissions iam aws d'une startup en 2 heures et éviter les escalades de privilèges

Quand on accompagne des startups, l'un des sujets qui revient sans cesse est la peur — souvent fondée — d'une mauvaise configuration IAM qui mène à une escalade de privilèges. J'ai appris à transformer cette crainte en un audit structuré et pragmatique que l'on peut réaliser en environ deux heures. Voici ma méthode, testée sur de petites architectures cloud : rapide, reproductible et focalisée sur les points qui comptent vraiment pour réduire les risques immédiats.

Préparation : ce qu'il vous faut en 5–10 minutes

Avant de lancer l'audit, assurez-vous d'avoir :

• Un compte disposant des droits nécessaires pour lister les entités IAM (utilisateurs, rôles, politiques, instances, comptes invités). Un rôle d'administrateur temporaire est pratique mais évitez de le laisser activé après l'audit.
• AWS CLI configuré avec ce compte, ou accès console pour lancer quelques outils (AWS IAM Access Analyzer, CloudTrail).
• Les identifiants des environnements (prod/staging) à examiner, et une estimation rapide du nombre d'entités IAM (pour ajuster la durée).
• Un canal de communication avec le CTO ou l'admin cloud pour poser des questions live si besoin — l'audit gagne en vitesse ainsi.

Étape 1 — Cartographier en 20 minutes : qui peut faire quoi

Objectif : obtenir une vue d'ensemble des utilisateurs, rôles et politiques. J'utilise une combinaison AWS CLI et la console.

• Lister les utilisateurs, rôles et politiques gérées : aws iam list-users, aws iam list-roles, aws iam list-policies --scope Local.
• Exporter les politiques attachées aux utilisateurs et aux rôles : aws iam list-attached-user-policies --user-name X et aws iam list-attached-role-policies --role-name Y.
• Vérifier les politiques inline (souvent sources de surprises) : aws iam list-user-policies, aws iam list-role-policies.
• Activer rapidement IAM Access Analyzer (console) pour détecter les ressources partagées en externe.

Je construis une feuille de route simple : nombre d'utilisateurs, rôles avec accès console, rôles de service (EC2, Lambda), politiques avec * ou actions sensibles (kms:*, iam:*, sts:AssumeRole).

Étape 2 — Trouver les chemins d'escalade en 30 minutes

Voici où se jouent généralement les escalades : rôles assumables sans restrictions, politiques larges, clés d'accès attachées à des comptes humains ou à des pipelines CI/CD. Je cible ces vecteurs :

• Rôles assumables : lister les rôles avec des trust policies permissives (Principal: "*", Service: "*", ou Account: "*"). Commande utile : aws iam get-role --role-name ROLENAME et inspecter AssumeRolePolicyDocument.
• Cross-account : repérer les rôles avec des Principals externes — bon indicateur d'exposition potentielle.
• Politiques trop larges : rechercher les policies contenant "Action": "*" ou des ressources "Resource": "*". Un grep sur les JSON exportés va vite.
• STS/AssumeRole non restreint : identifier les rôles qui peuvent être assumés par des utilisateurs internes non nécessaires.
• Clés d'accès actives : lister les access keys pour chaque utilisateur, vérifier leur âge et dernière utilisation (aws iam list-access-keys, aws iam get-access-key-last-used).

J'utilise aussi PMapper (outil open source) ou ScoutSuite pour avoir une carte des chemins d'escalade possible. En 30 minutes, ces outils montrent rapidement les relations utilisateur->rôle->service qui rendent une escalation possible.

Étape 3 — Vérifications rapides et remédiation immédiate (30 minutes)

Avec la cartographie et les chemins potentiels en tête, je priorise les remédiations qui prennent moins de 5–10 minutes et réduisent le risque drastiquement :

• Désactiver ou supprimer les clés d'accès orphelines ou inutilisées (sauf si nécessaire pour une CI active). Forcer la rotation des clés >90 jours.
• Restreindre les trust policies : remplacer les Principals "*" par des ARNs spécifiques, ajouter des conditions (SourceIp, ExternalId) pour les rôles cross-account.
• Attacher une permission boundary si un rôle ou utilisateur a un besoin temporaire d'admin : ça limite les actions possibles même si une politique plus permissive est attachée.
• Retirer les politiques inline excessives et remplacer par des politiques gérées plus contrôlées. Préférer des politiques gérées AWS ou des policies internes bien révisées.
• Activer MFA obligatoire pour les comptes consoles administratifs et exiger l'usage de sessions temporaires via STS pour l'accès sensible.

Étape 4 — Contrôles complémentaires en 20 minutes

Pour compléter l'audit et fournir des recommandations actionnables :

• Consulter CloudTrail pour détecter des AssumeRole récents ou des actions sensibles : filtrer les événements iam:CreateUser, iam:AttachUserPolicy, sts:AssumeRole.
• Vérifier les logs CloudWatch/GuardDuty pour activités anormales associées aux identifiants découverts.
• Activer ou revoir AWS Config rules (ex. iam-password-policy, iam-no-inline-policy) pour capter les régressions automatiquement.
• Vérifier si AWS Organizations est utilisé et s'il existe des SCP (Service Control Policies) limitant les actions à l'échelle du compte.

Checklist rapide à partager au CTO

Bonnes pratiques pour éviter les régressions

Après l'audit rapide, je recommande d'instaurer ces routines pour éviter de retomber dans une configuration dangereuse :

• Principle of Least Privilege dès la définition des rôles. Commencez restrictif et élargissez si besoin. Documentez chaque permission essentielle.
• Automatiser la détection : Config rules, Access Analyzer, GuardDuty. Les alertes permettent d'intervenir avant qu'une exploitation ne survienne.
• Gestion des identités machine : privilégier les rôles IAM pour EC2/Lambda au lieu d'embedder des clés dans le code ou variables d'environnement.
• Permissions boundaries et sessions temporaires : obligatoire pour les tâches d'administration réalisées par des humains ou des pipelines.
• Revue trimestrielle des accès et des rôles avec les responsables produit — surtout pour les comptes qui évoluent vite.

En deux heures, vous pouvez obtenir une photographie fiable des risques IAM et fermer les chemins d'escalade les plus évidents. L'objectif n'est pas d'atteindre la perfection en deux heures mais d'éliminer les vecteurs critiques et de mettre en place les garde-fous qui empêchent une bascule vers une compromission. Si vous voulez, je peux vous fournir un script AWS CLI prêt à l'emploi pour automatiser la première cartographie — dites-moi l'empreinte actuelle (nombre d'utilisateurs/roles) et je l'adapte.