Aller au contenu

AWS Mis à jour le 2026-07-04

Exemples de politiques IAM : les 12 politiques dont chaque compte AWS finit par avoir besoin

Douze exemples de politiques IAM qu'on retrouve dans pratiquement chaque compte AWS de production — rôles applicatifs limités à un compartiment, verrouillage de régions, contrôle EC2 par étiquettes, application du MFA, avec du JSON fonctionnel.

Chaque compte AWS qui survit à sa première année converge vers à peu près la même douzaine de politiques IAM : un rôle applicatif limité à un compartiment, un auditeur en lecture seule, un verrouillage de régions, une politique EC2 par étiquettes pour les développeurs, une barrière MFA, et une poignée d’autres. Voici les douze qu’on finit par écrire dans presque chaque environnement, avec du JSON fonctionnel pour celles que les gens ratent le plus souvent. Copiez-les comme points de départ, puis resserrez les ressources vers vos ARN.

Ce qui se passe

Les politiques IAM échouent dans deux directions. Trop lâches, et le compte accumule des Action: "*" qui ne passent aucun audit et transforment n’importe quel identifiant fuité en compromission complète. Trop serrées, et chaque déploiement génère un billet Access Denied jusqu’à ce que quelqu’un « règle ça » avec un joker — pour arriver à trop lâche par un chemin plus long. La sortie, c’est une petite bibliothèque de formes éprouvées : des politiques où les actions, ressources et conditions sont déjà équilibrées, pour que chaque nouveau besoin soit une substitution de variables plutôt qu’un éditeur JSON vide. Les règles d’évaluation d’AWS récompensent ça — le deny explicite gagne toujours, les blocs Condition rendent les accès situationnels, et les ARN de ressources font le vrai travail de délimitation. La référence des politiques dans la documentation IAM couvre la grammaire; les formes ci-dessous couvrent la pratique.

Quoi vérifier en premier

Avant d’écrire quoi que ce soit de neuf, inventoriez l’existant — la plupart des comptes contiennent déjà trois demi-versions de chaque politique ci-dessous :

  • Comptez les politiques gérées par le client vs en ligne. Les politiques en ligne échappent à la réutilisation et à la revue; tout ce qui sert deux fois devrait être géré par le client.
  • Trouvez les jokers. Toute politique avec "Action": "*" sur "Resource": "*" hors du rôle admin est la première chose à remplacer.
  • Repérez les politiques gérées par AWS qui font un travail trop large pour elles. AmazonS3FullAccess sur un rôle applicatif est le classique.
  • Regardez ce qui est réellement utilisé. Les données de dernier accès vous disent quels accès sont du poids mort avant de tout redessiner.

Comment vérifier

# Inventorier les politiques gérées par le client et leurs attachements
aws iam list-policies --scope Local \
  --query 'Policies[].[PolicyName,AttachmentCount]' --output table

# Extraire la version par défaut courante d'une politique
aws iam get-policy-version \
  --policy-arn arn:aws:iam::111122223333:policy/app-s3-scoped \
  --version-id v1

# Trouver les politiques en ligne sur un rôle
aws iam list-role-policies --role-name app-role

Chemin console pour la revue des attachements : IAM > Policies > (policy) > Entities attached. Validez le nouveau JSON avec les vérifications intégrées à l’éditeur de la console — elles signalent les actions invalides et les ressources trop larges avant la sauvegarde.

Le runbook

  1. Rôle applicatif limité à un préfixe de compartiment — la politique la plus écrite d’AWS. Notez la séparation : ListBucket sur le compartiment, actions d’objets sur le préfixe.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::prod-assets",
      "Condition": {"StringLike": {"s3:prefix": ["uploads/*"]}}
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::prod-assets/uploads/*"
    }
  ]
}
  1. Deny de verrouillage de régions — empêche des ressources d’apparaître dans des régions que personne ne surveille. Exemptez les services globaux qui s’authentifient via us-east-1.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": ["iam:*", "sts:*", "organizations:*", "route53:*",
                    "cloudfront:*", "support:*", "budgets:*"],
      "Resource": "*",
      "Condition": {"StringNotEquals": {"aws:RequestedRegion": ["ca-central-1", "us-east-1"]}}
    }
  ]
}
  1. Démarrage/arrêt EC2 par étiquettes pour les développeurs — n’opérer que les instances étiquetées pour votre équipe, sans toucher à la production.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances", "ec2:RebootInstances"],
      "Resource": "arn:aws:ec2:*:111122223333:instance/*",
      "Condition": {"StringEquals": {"aws:ResourceTag/team": "platform"}}
    },
    {
      "Effect": "Allow",
      "Action": "ec2:DescribeInstances",
      "Resource": "*"
    }
  ]
}
  1. Auditeur en lecture seule — partez de la politique gérée AWS ReadOnlyAccess ou de la plus serrée SecurityAudit, puis ajoutez un deny sur les lectures du plan de données (s3:GetObject, dynamodb:GetItem) si l’auditeur doit voir la configuration mais pas les données des clients.
  2. Deny-sauf-MFA — le deny BoolIfExists qui rend le MFA réel plutôt que suggéré; la forme complète et ses pièges sont dans notre guide d’application du MFA.
  3. Identifiants en libre-service — permettre à chaque utilisateur IAM de gérer seulement son propre mot de passe, ses clés d’accès et son appareil MFA avec arn:aws:iam::*:user/${aws:username} comme ressource.
  4. Politique humaine assume-role-seulement — les humains reçoivent sts:AssumeRole sur des ARN de rôles nommés et rien d’autre; toutes les vraies permissions vivent sur les rôles.
  5. Lecture finances et facturation — ce:Get*, ce:Describe*, budgets:View*, cur:Describe* pour les gens qui posent des questions sur la facture, pour qu’ils arrêtent de les poser aux ingénieurs.
  6. Rôle de déploiement CI/CD — limité à un service : le service ECS ou les fonctions Lambda précises, le dépôt ECR précis, iam:PassRole restreint à l’ARN du seul rôle de tâche. PassRole sur * dans un pipeline, c’est une escalade de privilèges en attente.
  7. Politique de compartiment TLS-seulement — une politique de ressource avec "Effect": "Deny" quand "aws:SecureTransport": "false", exigée par la plupart des cadres de conformité.
  8. Usage KMS à clé unique — kms:Decrypt, kms:GenerateDataKey sur un seul ARN de clé, jumelé à une politique de clé qui accorde à la couche IAM du compte.
  9. Admin bris de glace — AdministratorAccess sur un rôle dédié avec une politique de confiance exigeant le MFA, dont chaque utilisation alerte quelqu’un via une alarme alimentée par CloudTrail.

Quand ce n’est pas la bonne approche

Écrire les douze à la main est une erreur si l’organisation s’apprête à adopter des garde-fous à l’échelle d’Organizations — le verrouillage de régions et plusieurs deny appartiennent aux SCP, une seule fois, plutôt qu’à chaque compte. Et si les humains s’authentifient encore comme utilisateurs IAM, les politiques 5 à 7 sont des rustines sur un modèle qui mérite d’être remplacé par Identity Center plutôt que perfectionné.

Erreurs fréquentes

  • Mettre s3:ListBucket sur bucket/* ou GetObject sur l’ARN nu du compartiment — chaque action se lie à une forme d’ARN précise.
  • Oublier les exemptions NotAction dans le deny de régions, ce qui barre tout le monde hors d’IAM et de la facturation.
  • Accorder iam:PassRole sur * aux rôles de CI — l’escalade de privilèges silencieuse de la plupart des pipelines.
  • Utiliser des politiques en ligne pour tout ce qui est réutilisé; elles ne peuvent être ni versionnées, ni partagées, ni revues à un seul endroit.

Garder le contrôle

  • Gardez les douze comme politiques gérées par le client dans l’infrastructure-en-code, pour que la dérive soit un diff, pas de l’archéologie.
  • Nommez les politiques par portée, pas par folklore d’équipe : app-prod-assets-rw, pas politique-steve-2.
  • Passez en revue AttachmentCount chaque trimestre et supprimez tout ce qui est à zéro.
  • Laissez les constats d’accès inutilisés guider l’élagage plutôt que l’intuition — les accès que personne n’a exercés en 90 jours méritent rarement de rester.

Douze formes couvrent l’essentiel des besoins d’un compte; tout ce qui dépasse devrait être une exception délibérée avec un responsable et une raison. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.