Claude Code × AWS IAM Guide Complet | Générez des Politiques de Moindre Privilège Automatiquement

La conception des politiques IAM est “discrète mais catastrophique quand elle est mal faite”. Les politiques avec abus de caractères génériques (*) sont des foyers d’incidents de sécurité. Pourtant, écrire des politiques de moindre privilège depuis zéro prend du temps.

J’opère une architecture serverless combinant Lambda, S3, DynamoDB et CloudWatch en production. En déléguant la conception et la révision des politiques IAM à Claude Code, j’ai réduit le temps de travail d’environ 70%. Cet article explique les étapes pratiques.

---

Les bases d’IAM en 3 minutes

Structure d’une politique

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:prefix": ["uploads/"]
        }
      }
    }
  ]
}

• Effect: Allow (Autoriser) ou Deny (Refuser)
• Action: Les actions API à autoriser/refuser
• Resource: ARN de la ressource cible (plus spécifique = plus sécurisé)
• Condition: Conditions supplémentaires (restrictions IP, MFA requis, etc.)

Principe du moindre privilège

“Autoriser uniquement les opérations nécessaires, sur uniquement les ressources nécessaires” est la règle d’or d’IAM.

❌ Dangereux : Abus de caractères génériques
Action: "*"
Resource: "*"

✅ Sécurisé : Spécifier concrètement
Action: ["s3:GetObject", "s3:PutObject"]
Resource: "arn:aws:s3:::my-uploads-bucket/user-files/*"

---

Étape 1 : Décrire le cas d’usage et générer automatiquement une politique

Génération d’une politique pour Lambda

claude -p "
Génère la politique IAM minimale requise en JSON pour la fonction Lambda suivante.

[Traitement Lambda]
- Lire des images depuis le bucket S3 'user-uploads-prod'
- Sauvegarder les images traitées dans 'user-thumbnails-prod'
- Enregistrer les résultats dans la table DynamoDB 'image-metadata'
- Notifier le topic SNS 'alert-topic' en cas d'erreur
- Écrire des logs dans CloudWatch Logs

[Contraintes]
- Les opérations de suppression ne sont pas nécessaires
- Utiliser l'ID de compte 123456789012, région ap-northeast-1 pour les ARNs de ressources
- Pas de restriction IP via Condition (non nécessaire pour Lambda)
"

Exemple généré :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3ReadSourceBucket",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::user-uploads-prod/*"
    },
    {
      "Sid": "S3WriteThumbnailBucket",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::user-thumbnails-prod/*"
    },
    {
      "Sid": "DynamoDBWriteMetadata",
      "Effect": "Allow",
      "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/image-metadata"
    },
    {
      "Sid": "SNSPublishAlert",
      "Effect": "Allow",
      "Action": ["sns:Publish"],
      "Resource": "arn:aws:sns:ap-northeast-1:123456789012:alert-topic"
    },
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/lambda/*"
    }
  ]
}

---

Étape 2 : Audit de sécurité des politiques existantes

Demandez à Claude Code de réviser les politiques existantes pour détecter des problèmes.

claude -p "
Révise la politique IAM suivante d'un point de vue sécurité.
Identifie les problèmes spécifiques et propose des solutions concrètes.

$(cat policy.json)
"

Problèmes typiques signalés par Claude Code :

Problème 1 : Resource: "*" accorde un accès complet à S3
  → Spécifier explicitement les buckets cibles et les préfixes

Problème 2 : s3:DeleteObject est inclus mais non requis par le processus
  → Supprimer l'opération de suppression

Problème 3 : iam:PassRole est autorisé avec une ressource générique
  → Restreindre PassRole à des ARNs de rôles spécifiques uniquement (risque d'escalade de privilèges)

Problème 4 : L'activation de CloudTrail ne peut pas être confirmée
  → Recommander l'activation de la journalisation des opérations IAM

---

Étape 3 : Automatisation de la conception des rôles

Conception de rôles couvrant plusieurs services

claude -p "
Conçois tous les rôles IAM nécessaires pour l'architecture suivante :

[Architecture]
- API Gateway → Lambda (authentification)
- Lambda → DynamoDB (lecture/écriture données utilisateur)
- Lambda → S3 (stockage de fichiers)
- Lambda → SES (envoi d'emails)
- CloudWatch Events → Lambda (traitement par lots)
- CodePipeline → S3, CodeBuild, Lambda (déploiement)

[Format de sortie]
- Nom et objectif de chaque rôle
- Trust Policy
- Access Policy
- Sortie en code TypeScript AWS CDK
"

Implémentation CDK des rôles

// lib/iam-stack.ts
import * as cdk from "aws-cdk-lib";
import * as iam from "aws-cdk-lib/aws-iam";
import * as lambda from "aws-cdk-lib/aws-lambda";

export class IamStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // Rôle d'exécution Lambda (moindre privilège)
    const lambdaRole = new iam.Role(this, "ApiLambdaRole", {
      assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
      roleName: "api-lambda-role",
      description: "Rôle de moindre privilège pour API Lambda",
    });

    // Permissions de lecture/écriture DynamoDB (table spécifique uniquement)
    lambdaRole.addToPolicy(
      new iam.PolicyStatement({
        sid: "DynamoDBAccess",
        effect: iam.Effect.ALLOW,
        actions: [
          "dynamodb:GetItem",
          "dynamodb:PutItem",
          "dynamodb:UpdateItem",
          "dynamodb:Query",
        ],
        resources: [
          `arn:aws:dynamodb:${this.region}:${this.account}:table/users`,
          `arn:aws:dynamodb:${this.region}:${this.account}:table/users/index/*`,
        ],
      })
    );

    // Permissions d'écriture S3 (bucket et préfixe spécifiques uniquement)
    lambdaRole.addToPolicy(
      new iam.PolicyStatement({
        sid: "S3FileUpload",
        effect: iam.Effect.ALLOW,
        actions: ["s3:PutObject", "s3:GetObject"],
        resources: [
          `arn:aws:s3:::user-files-${this.account}/uploads/*`,
        ],
      })
    );

    // Permissions d'envoi d'email SES
    lambdaRole.addToPolicy(
      new iam.PolicyStatement({
        sid: "SESSendEmail",
        effect: iam.Effect.ALLOW,
        actions: ["ses:SendEmail", "ses:SendRawEmail"],
        resources: ["*"],
        conditions: {
          StringEquals: {
            "ses:FromAddress": "[email protected]",
          },
        },
      })
    );

    // Permissions d'écriture dans CloudWatch Logs
    lambdaRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        "service-role/AWSLambdaBasicExecutionRole"
      )
    );
  }
}

---

Étape 4 : Révision des résultats d’IAM Access Analyzer

Demandez à Claude Code de réviser la sortie d’IAM Access Analyzer.

# Récupérer les résultats d'Access Analyzer
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:... \
  --output json > analyzer-findings.json

claude -p "
Lis les résultats suivants d'IAM Access Analyzer et :
1. Classe par sévérité (HIGH/MEDIUM/LOW)
2. Identifie les éléments nécessitant une remédiation immédiate
3. Fournis des étapes de remédiation spécifiques pour chacun

$(cat analyzer-findings.json)
"

---

Étape 5 : Conception des SCPs (Garde-fous au niveau organisationnel)

Lors de l’utilisation d’AWS Organizations, utilisez les SCPs (Service Control Policies) pour établir des garde-fous pour des comptes entiers.

claude -p "
Conçois un SCP à appliquer aux comptes AWS de production.
Il doit satisfaire les exigences suivantes :

1. Désactiver toutes les régions sauf ap-northeast-1 (Tokyo) et us-east-1 (Virginie)
2. Interdire les opérations API par le compte root
3. Interdire la désactivation ou suppression de CloudTrail
4. Interdire la désactivation de GuardDuty
5. Interdire les modifications d'un rôle IAM spécifique ('OrganizationAdminRole')
"

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnsupportedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": [
            "arn:aws:iam::*:role/OrganizationAdminRole"
          ]
        }
      }
    },
    {
      "Sid": "DenyCloudTrailModification",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    }
  ]
}

---

4 pièges courants

1. iam:PassRole avec trop de privilèges

// ❌ Dangereux : n'importe quel rôle peut être passé
{
  "Action": "iam:PassRole",
  "Resource": "*"
}

// ✅ Sécurisé : rôle spécifique uniquement
{
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789:role/MyLambdaRole",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

2. Surexploitation des politiques gérées par AWS

Les politiques gérées comme AmazonS3FullAccess sont pratiques mais incluent bien plus de permissions que nécessaire. Si Lambda ne lit que depuis S3, utilisez une politique personnalisée avec uniquement s3:GetObject.

3. Mélange de politiques inline et de politiques gérées personnalisées

Les politiques inline ne peuvent pas être réutilisées et sont difficiles à suivre. Standardisez sur les politiques gérées et gérez les versions.

4. Exigence MFA manquante via les Conditions

Exigez toujours le MFA lors du passage à des rôles d’administrateur.

{
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

---

Résumé

Tâche	Contribution de Claude Code
Génération de politiques	Génère des politiques de moindre privilège à partir d’une description
Audit de sécurité	Identifie les problèmes et suggère des corrections pour les politiques existantes
Conception des rôles	Conçoit la structure des rôles pour toute l’architecture
Implémentation CDK	Génère automatiquement le code TypeScript IAM
Conception SCP	Génère des politiques guardrail à l’échelle organisationnelle

IAM n’est pas “configurer et oublier”—des révisions régulières sont essentielles. Prendre l’habitude de faire réviser les politiques existantes par Claude Code mensuellement est un moyen simple de réduire continuellement les risques de sécurité.

Articles connexes

• Guide complet des meilleures pratiques de sécurité Claude Code
• Claude Code × AWS Lambda Guide complet
• Claude Code × AWS DynamoDB Guide complet

Références

• AWS IAM Best Practices
• IAM Access Analyzer
• AWS CDK IAM Module