Quand on parle d'AWS et d'identités, je vois souvent la même inquiétude revenir : avons-nous laissé une porte ouverte à une escalade de privilèges ? En tant que rédactrice et accompagnatrice d'équipes produit, j'ai appris à transformer cette anxiété en routine pragmatique. Voici ma méthode pour auditer les permissions IAM d'un compte AWS en 30 minutes — une checklist priorisée, actionnable et pensée pour produire des résultats immédiats sans sacrifier la qualité.
Approche générale : pourquoi 30 minutes et comment les utiliser
Trente minutes, ce n'est pas censé remplacer un audit complet. C'est un "sprint" de réduction de risque : identifier et corriger les vecteurs d'escalade les plus probables. J'organise ces 30 minutes en trois types d'actions simultanées et itératives : collecter les données rapides, exécuter une série de tests prioritaires, et appliquer corrections immédiates ou plans d'action.
Avant de commencer, assurez-vous d'avoir un rôle avec droits d'observation suffisants (ou le support d'un admin) et d'ouvrir deux onglets : AWS Console (IAM, CloudTrail, IAM Access Analyzer) et votre terminal avec AWS CLI configuré.
Checklist priorisée (30 minutes)
Ci-dessous la liste que j'exécute systématiquement. Chaque item indique une action, pourquoi elle est critique et ce qu'il faut faire si la vérification échoue.
- 0-3 min — Rapport d'identifiants : Générer le rapport d'identifiants (Credential Report). Commande : aws iam get-credential-report --output text. Pourquoi : il révèle les clés actives, la date de création et l'état des mots de passe. Si des clés âgées ou non rotatives apparaissent : marquer pour rotation immédiate et désactivation si inutilisées.
- 3-8 min — CloudTrail & logs : Vérifier que CloudTrail est activé pour tous les régions et envoie vers un bucket centralisé. Pourquoi : sans trace, impossible d'enquêter sur une escalade. Action : Activer CloudTrail multi-région et vérifier que le bucket a des ACLs et bloc_public_access. Si absent : créer et configurer.
- 8-12 min — Policies avec wildcard et actions critiques : Rechercher les policies (managed & inline) contenant "*" ou actions sensibles (iam:PassRole, sts:AssumeRole, iam:CreateUser, iam:DeleteRole). Pourquoi : ces patterns sont fréquemment exploités. Commande utile : aws iam list-policies --scope Local et analyser les documents policies. Si trouvé : restreindre ces policies ou remplacer par policies plus fines.
- 12-16 min — Roles trust policies cross-account : Lister les roles avec trust relationships externes. Commande : aws iam list-roles puis inspecter trust policy. Pourquoi : un trust mal restreint permet à un acteur externe d'assumer un rôle. Si trust à 0.0.0.0/ANY ou * présent : restreindre au compte ou aux principals nécessaires.
- 16-20 min — Vérifier les user & access keys actives : À l'aide du Credential Report et aws iam list-access-keys, détecter clés non utilisées ou anciennes. Pourquoi : clés perpétuelles sont un risque majeur. Action : désactiver et planifier suppression, forcer rotation avec automation (Secrets Manager).
- 20-24 min — MFA et root : Vérifier que le compte root a MFA activé et qu'il n'est pas utilisé pour des opérations régulières. Pourquoi : root compromet l'ensemble du compte. Action : activer MFA si absent, stocker credentials root en coffre fort et documenter procédure d'accès d'urgence.
- 24-28 min — IAM Access Analyzer & AWS Config : Lancer ou consulter IAM Access Analyzer pour les ressources partagées et vérifier les findings d'AWS Config (rules sur IAM). Pourquoi : outils natifs qui signalent exposés ou policy trop permissifs. Action : corriger findings critiques et activer rules manquantes (minimum: iam-user-unused-credentials-check, iam-password-policy).
- 28-30 min — Résumé & actions immédiates : Documenter 3 actions prioritaires (par ex. révoquer une clé non utilisée, restreindre une trust policy, activer MFA) et assigner responsabilités et délais (24-48h). Pourquoi : sans suivi, les correctifs n'arrivent pas.
Commandes et requêtes pratiques
Quelques commandes que j'utilise fréquemment pour aller vite :
- aws iam get-credential-report --output text | base64 -d — pour obtenir et lire le credential report.
- aws iam list-roles --query 'Roles[?AssumeRolePolicyDocument.Statement[?Principal.AWS!=null]].{RoleName:RoleName,Assume:AssumeRolePolicyDocument}' — repérer roles avec trust externes.
- aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/Alice --action-names iam:PassRole — tester si une entité peut exécuter une action critique.
Pièges fréquents et comment les éviter
Dans mes interventions, voici les patterns d'erreur que je vois le plus souvent, et mes recommandations concrètes :
- Utiliser des clés long-terme au lieu d'IAM Roles pour services : Remplacer les clés par des rôles attachés aux instances (EC2) ou aux tâches (ECS, Lambda) via IAM Role. Utiliser AWS STS pour tokens temporaires.
- Policies trop larges pour accélérer un déploiement : Ne pas garder "AdministratorAccess" par commodité. Créer des policies basées sur les actions réellement nécessaires, utiliser des managed policies organisationnelles et des permission boundaries pour les équipes.
- Confiance inter-comptes mal restreinte : Préférer des conditions (sts:ExternalId, aws:PrincipalOrgID) plutôt que "*" dans la trust policy.
- Absence d'audit continu : Intégrer IAM Access Analyzer, AWS Config et alerting (SNS, Okta/DSA) pour détecter les dérives.
Tableau synthétique : actions rapides et impact
| Action | Temps | Impact | Priorité |
|---|---|---|---|
| Générer Credential Report | 2 min | Identifie clés & mots de passe | Haute |
| Vérifier CloudTrail multi-région | 3 min | Auditabilité | Haute |
| Révoquer clés inutilisées | 5 min | Réduit exposition immédiate | Haute |
| Restreindre trust policies publiques | 5-7 min | Bloque escalade cross-account | Critique |
| Activer IAM Access Analyzer | 3 min | Détecte partages excessifs | Haute |
Quelques bonnes pratiques à inscrire dans le temps
Après ce sprint, je propose systématiquement de lancer des actions structurelles :
- Mettre en place une politique de rotation automatique des clés via AWS Secrets Manager ou HashiCorp Vault.
- Adopter des permission boundaries pour les équipes et des policies basées sur les rôles métiers (RBAC).
- Automatiser des contrôles quotidiens (Lambda ou AWS Config Remediation) pour détecter et corriger des dérives.
- Documenter les rôles et policies critiques dans un référentiel accessible et auditable.
Si vous avez 30 minutes devant vous, suivez cette checklist et vous éliminerez la plupart des chemins d'escalade immédiats. Si vous voulez, je peux vous fournir un playbook AWS CLI/Console à exécuter pas à pas (avec scripts) pour automatiser complètement ces vérifications — dites-moi le niveau de détail souhaité.