IAM Policy AWS

cloud

Définition

Une IAM Policy AWS est un document JSON qui définit les permissions accordées ou refusées à des identités (utilisateurs, groupes, rôles) ou des ressources AWS. Les politiques IAM sont le mécanisme fondamental de contrôle d'accès dans AWS : sans politique explicite accordant une permission, tout accès est refusé par défaut. Il existe plusieurs types de politiques IAM. Les politiques d'identité (Identity-based policies) sont attachées à des utilisateurs, groupes ou rôles IAM. Les politiques de ressources (Resource-based policies) sont attachées directement aux ressources AWS (bucket S3, rôle IAM trust policy, clé KMS, queue SQS). Les SCPs (Service Control Policies) définissent les guardrails d'organisation dans AWS Organizations. Les politiques de permissions boundary limitent les permissions maximales d'une entité IAM. Les politiques de session contrôlent les permissions lors de l'usage de sts:AssumeRole. La syntaxe d'une politique IAM comprend les éléments : Version (toujours "2012-10-17"), Statement (liste d'instructions), Effect (Allow ou Deny), Action (liste d'API AWS ou wildcard), Resource (ARN des ressources cibles), et Condition (conditions facultatives comme aws:SourceIp, aws:MfaPresent, aws:RequestedRegion). La logique d'évaluation IAM suit une hiérarchie précise : un Deny explicite dans une SCP, politique de boundary ou politique de session prévaut sur tout Allow. L'accès est refusé implicitement si aucun Allow ne s'applique. La compréhension de cette hiérarchie est fondamentale pour éviter les configurations contre-intuitives. Les bonnes pratiques de rédaction des politiques IAM incluent : utiliser des politiques managées AWS pour les cas d'usage standards (AmazonS3ReadOnlyAccess, AmazonDynamoDBFullAccess) plutôt que de réinventer la roue, créer des politiques inline pour les cas spécifiques nécessitant un contrôle fin, ajouter des conditions Condition pour restreindre davantage (MFA requis, région spécifique, IP source), et utiliser IAM Access Analyzer pour valider les politiques avant déploiement.

Wildcards et scope des politiques

Évitez les wildcards ouverts dans Action ("Action": "*") et Resource ("Resource": "*"). Préférez des actions spécifiques et des ARN de ressources précis. Utilisez des variables de politique comme ${aws:username} pour créer des politiques dynamiques limitant chaque utilisateur à ses propres ressources (ex: un bucket S3 nommé avec son username). Le Service Last Accessed dans IAM Access Advisor indique les services réellement utilisés pour affiner les permissions.

Politiques de boundary et délégation sécurisée

Les Permissions Boundaries permettent de déléguer la création de politiques IAM à des sous-équipes sans risque d'escalade de privilèges : une boundary définit le plafond maximum des permissions qu'un administrateur délégué peut accorder, même s'il essaie d'attacher AdministratorAccess. Ce pattern est essentiel dans les grandes organisations où plusieurs équipes gèrent des comptes AWS autonomes.

Audit et validation des politiques

Utilisez IAM Access Analyzer policy validator (gratuit, intégré AWS Console) pour détecter les problèmes courants dans vos politiques. L'outil Policy Simulator teste les politiques contre des scénarios d'accès avant déploiement. Cloudsplaining analyse toutes les politiques IAM d'un compte pour détecter les chemins d'escalade de privilèges, les wildcards dangereux et les politiques trop permissives.

Articles liés

Expert en cybersécurité offensive et intelligence artificielle. Pentest, audit et développement IA sur-mesure.

Services

Ressources

Projets & Outils

Contact

Nous contacter

Mentions légales Confidentialité Politique éditoriale Plan du site ⭐ Source préférée

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis