Claude Code et AWS IAM : guide pratique des politiques de moindre privilège

AWS IAM décide qui peut faire quoi sur quelles ressources AWS. Une politique ressemble à un simple document JSON, mais un Action: "*" ou un Resource: "*" peut donner à une Lambda, à un job CI ou à un compte humain beaucoup plus de droits que nécessaire. Claude Code est utile pour rédiger et relire, mais il ne doit jamais devenir un générateur de permissions approuvées automatiquement.

La méthode fiable est progressive : décrire le cas d’usage, demander un brouillon à Claude Code, valider avec IAM Access Analyzer, relire les ARN et les limites métier, figer le tout avec CDK, puis tester les actions autorisées et refusées. Pour débuter, retenez ceci : une politique est une règle de permission, un rôle est une identité temporaire assumée par une charge de travail, et un principal est l’utilisateur ou le service qui utilise la permission.

Masa a changé sa pratique après avoir retrouvé une permission S3 trop large sur une Lambda de production, plusieurs semaines après un correctif urgent. Il n’y a pas eu de fuite, mais la leçon est restée : Claude Code réduit le temps de rédaction, pas la responsabilité de vérification.

Utiliser les documents AWS comme référence

Cette version suit les recommandations officielles AWS :

• Security best practices in IAM
• IAM JSON policy element reference
• Validate policies with IAM Access Analyzer
• Temporary security credentials in IAM
• Permissions boundaries for IAM entities

Le message opérationnel est clair : privilégier les identifiants temporaires et les rôles, appliquer le moindre privilège, valider avec Access Analyzer, utiliser les conditions avec prudence et supprimer régulièrement les permissions inutilisées.

flowchart LR
  A["Décrire le cas d'usage"] --> B["Brouillon Claude Code"]
  B --> C["Relecture humaine des ARN"]
  C --> D["IAM Access Analyzer"]
  D --> E["Implémentation CDK"]
  E --> F["Tests autorisés et refusés"]

Commencer par des cas d’usage concrets

Ne demandez pas seulement “écris une politique IAM”. Donnez l’acteur, les ressources, les actions autorisées et les actions qui doivent rester interdites.

Cas d’usage	Principal	Permissions nécessaires	À éviter explicitement
Lambda de miniatures	Rôle d’exécution Lambda	Lire un préfixe S3, écrire un préfixe S3, écrire une table DynamoDB, publier un sujet SNS, écrire les logs	Suppression S3, lecture de tous les buckets, actions IAM
Aide d’upload d’administration	Rôle Lambda d’API	PutObject vers un préfixe S3, GetItem sur une table DynamoDB	List sur tout le bucket, gestion des clés KMS
Déploiement GitHub Actions	Rôle CI OIDC	Mettre à jour un stack CloudFormation et la Lambda cible	AdministratorAccess, opérations toutes régions
Rôle lecture seule d’incident	Utilisateur fédéré	Rechercher CloudWatch Logs, consulter X-Ray, GetItem sur la table utile	Mise à jour, suppression, lecture des secrets

La colonne “à éviter” est essentielle. Sans limite négative, un outil génératif compense souvent les inconnues par des permissions trop larges.

Politique Lambda prête à copier

Cette politique concerne une Lambda qui lit des images dans S3, écrit des miniatures dans un autre préfixe, écrit les métadonnées dans DynamoDB, publie une alerte SNS et écrit dans CloudWatch Logs. Le groupe de logs est créé par le code d’infrastructure, donc le rôle n’a pas besoin de logs:CreateLogGroup.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSourceImages",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::user-uploads-prod/incoming/*"
    },
    {
      "Sid": "WriteThumbnails",
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::user-thumbnails-prod/thumbnails/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "AES256"
        }
      }
    },
    {
      "Sid": "WriteMetadata",
      "Effect": "Allow",
      "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/image-metadata"
    },
    {
      "Sid": "PublishAlerts",
      "Effect": "Allow",
      "Action": ["sns:Publish"],
      "Resource": "arn:aws:sns:ap-northeast-1:123456789012:alert-topic"
    },
    {
      "Sid": "WriteLambdaLogs",
      "Effect": "Allow",
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/lambda/image-worker-prod:*"
    }
  ]
}

Enregistrez le fichier sous policy-lambda-image-worker.json, puis exécutez :

aws accessanalyzer validate-policy \
  --policy-document file://policy-lambda-image-worker.json \
  --policy-type IDENTITY_POLICY \
  --query "findings[?findingType!='SUGGESTION']"

Demandez ensuite une relecture structurée :

claude -p "Relis policy-lambda-image-worker.json comme politique AWS IAM de moindre privilège.
Contexte : Lambda lit S3 incoming/, écrit thumbnails/, écrit DynamoDB image-metadata, publie SNS alert-topic et écrit CloudWatch Logs.
Vérifie : jokers, permissions de suppression, Resource trop large, Condition correcte et portée des logs.
Retourne un tableau Sid / risque / raison / correction plus sûre."

Access Analyzer vérifie la grammaire, les ARN, les noms d’action, les clés de condition et les alertes de sécurité. Il ne sait pas si votre produit a réellement besoin d’une permission. Ce jugement reste humain.

Implémenter le rôle avec CDK

Ne laissez pas une permission relue uniquement dans la console. Avec TypeScript CDK, le rôle, le groupe de logs et les politiques restent dans la même demande de changement.

import * as cdk from "aws-cdk-lib";
import { Stack, StackProps, aws_iam as iam, aws_logs as logs } from "aws-cdk-lib";
import { Construct } from "constructs";

export class ImageWorkerIamStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const account = Stack.of(this).account;
    const region = Stack.of(this).region;

    new logs.LogGroup(this, "ImageWorkerLogGroup", {
      logGroupName: "/aws/lambda/image-worker-prod",
      retention: logs.RetentionDays.ONE_MONTH,
      removalPolicy: cdk.RemovalPolicy.RETAIN,
    });

    const role = new iam.Role(this, "ImageWorkerRole", {
      assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
      description: "Execution role for image-worker-prod Lambda",
    });

    role.addToPolicy(new iam.PolicyStatement({
      sid: "ReadSourceImages",
      actions: ["s3:GetObject"],
      resources: ["arn:aws:s3:::user-uploads-prod/incoming/*"],
    }));

    role.addToPolicy(new iam.PolicyStatement({
      sid: "WriteThumbnails",
      actions: ["s3:PutObject"],
      resources: ["arn:aws:s3:::user-thumbnails-prod/thumbnails/*"],
      conditions: {
        StringEquals: {
          "s3:x-amz-server-side-encryption": "AES256",
        },
      },
    }));

    role.addToPolicy(new iam.PolicyStatement({
      sid: "WriteMetadataAndAlerts",
      actions: ["dynamodb:PutItem", "dynamodb:UpdateItem", "sns:Publish"],
      resources: [
        `arn:aws:dynamodb:${region}:${account}:table/image-metadata`,
        `arn:aws:sns:${region}:${account}:alert-topic`,
      ],
    }));

    role.addToPolicy(new iam.PolicyStatement({
      sid: "WriteLambdaLogs",
      actions: ["logs:CreateLogStream", "logs:PutLogEvents"],
      resources: [
        `arn:aws:logs:${region}:${account}:log-group:/aws/lambda/image-worker-prod:*`,
      ],
    }));
  }
}

CI avec OIDC, pas avec des clés longues

Pour CI/CD, évitez de stocker des clés AWS longues dans les secrets du dépôt. GitHub Actions peut assumer un rôle IAM via OIDC et recevoir des identifiants temporaires.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:example-org/example-repo:ref:refs/heads/main"
        }
      }
    }
  ]
}

Ceci est une politique de confiance : elle décide qui peut assumer le rôle. La politique de permissions décide ce que le rôle peut faire ensuite. Relisez-les séparément.

Pièges fréquents

Le premier piège est l’accès administrateur temporaire qui reste en place. Si une urgence l’impose, ajoutez un responsable, une date d’expiration, une vérification CloudTrail et une nouvelle validation Access Analyzer.

Le deuxième est la confusion entre ARN de bucket et ARN d’objet S3. s3:ListBucket utilise arn:aws:s3:::bucket-name; s3:GetObject et s3:PutObject utilisent arn:aws:s3:::bucket-name/prefix/*.

Le troisième est l’ajout naïf de conditions IP à un rôle Lambda. aws:SourceIp peut aider pour des humains ou une API publique, mais peut casser des appels entre services AWS.

Le quatrième est de ne tester que le succès. Vérifiez aussi que s3:DeleteObject, les buckets non liés, les tables non liées et les actions IAM sont refusés.

Lectures liées et suite

Pour continuer, lisez le guide AWS Lambda, le guide AWS S3, le guide AWS CloudWatch et les bonnes pratiques de sécurité Claude Code.

Si votre équipe veut standardiser Claude Code, AWS IAM, CDK et la revue des permissions CI, commencez par la page formation et consultation. En individuel, utilisez la fiche gratuite puis les modèles de la page produits.

J’ai testé ce flux en faisant rédiger la politique par Claude Code, en validant le JSON et en relisant le CDK avec la même table de cas d’usage. Le gain le plus net vient de l’écriture préalable des actions interdites : les permissions S3 trop larges et les jokers de logs inutiles apparaissent avant le déploiement.