Claude Code und AWS IAM: Praxisleitfaden für Least-Privilege-Policies

AWS IAM legt fest, wer auf welche AWS-Ressource welche Aktion ausführen darf. Eine Policy sieht nur wie ein JSON-Dokument aus, aber ein unbedachtes Action: "*" oder Resource: "*" kann einer Lambda-Funktion, einem CI-Job oder einem menschlichen Konto deutlich mehr Rechte geben als nötig. Claude Code ist hilfreich für Entwurf und Review, darf aber kein ungeprüfter Policy-Generator werden.

Der sichere Ablauf ist klar: Anwendungsfall beschreiben, mit Claude Code einen Entwurf erstellen, mit IAM Access Analyzer validieren, ARN und fachliche Grenzen manuell prüfen, mit CDK versionieren und danach erlaubte sowie verbotene Aktionen testen. Für Einsteiger: Eine Policy ist die Berechtigungsregel, eine Rolle ist eine temporäre Identität für Workloads, und ein Principal ist der Benutzer oder Dienst, der die Berechtigung nutzt.

Masa hat diesen Ablauf eingeführt, nachdem eine temporär breite S3-Berechtigung an einer Produktions-Lambda mehrere Wochen länger blieb als geplant. Es gab keinen Datenabfluss, aber die Regel war danach eindeutig: Claude Code spart Schreibzeit, ersetzt aber keine Verantwortung.

AWS-Dokumentation als Grundlage

Dieser Artikel folgt den aktuellen AWS-Referenzen:

• 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

Die praktische Linie lautet: temporäre Anmeldedaten und Rollen bevorzugen, Least Privilege anwenden, mit Access Analyzer validieren, Bedingungen bewusst einsetzen und ungenutzte Benutzer, Rollen, Policies und Schlüssel regelmäßig entfernen.

flowchart LR
  A["Anwendungsfall schreiben"] --> B["Claude-Code-Entwurf"]
  B --> C["ARN manuell prüfen"]
  C --> D["IAM Access Analyzer"]
  D --> E["CDK-Implementierung"]
  E --> F["Erlaubt- und Verboten-Tests"]

Mit konkreten Anwendungsfällen starten

Bitten Sie Claude Code nicht nur um “eine IAM-Policy”. Nennen Sie Akteur, Ressourcen, erlaubte Aktionen und ausdrücklich verbotene Aktionen.

Anwendungsfall	Principal	Notwendige Berechtigungen	Ausdrücklich vermeiden
Thumbnail-Lambda	Lambda-Ausführungsrolle	Ein S3-Präfix lesen, ein S3-Präfix schreiben, eine DynamoDB-Tabelle schreiben, ein SNS-Thema publizieren, Logs schreiben	S3 löschen, alle Buckets lesen, IAM-Aktionen
Upload-Hilfe im Adminbereich	API-Lambda-Rolle	PutObject in ein S3-Präfix, GetItem auf eine DynamoDB-Tabelle	List für ganzen Bucket, KMS-Schlüsselverwaltung
Deployment aus GitHub Actions	OIDC-CI-Rolle	Einen CloudFormation-Stack und eine Ziel-Lambda aktualisieren	AdministratorAccess, Aktionen in allen Regionen
Read-only-Rolle für Incidents	Föderierter Benutzer	CloudWatch Logs durchsuchen, X-Ray lesen, GetItem auf relevante Tabelle	Updates, Deletes, Secrets lesen

Die Spalte mit Verboten ist wichtig. Generative Werkzeuge füllen fehlende Informationen sonst oft mit zu breiten Berechtigungen.

Kopierbare Lambda-Policy

Diese Policy gehört zu einer Lambda, die Bilder aus S3 liest, Thumbnails in ein anderes Präfix schreibt, Metadaten in DynamoDB speichert, SNS-Alerts publiziert und Logs schreibt. Die Loggruppe wird vorher per Infrastrukturcode erstellt, deshalb braucht die Rolle kein 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:*"
    }
  ]
}

Speichern Sie die Datei als policy-lambda-image-worker.json und führen Sie aus:

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

Danach kann Claude Code strukturiert prüfen:

claude -p "Prüfe policy-lambda-image-worker.json als AWS-IAM-Policy nach Least Privilege.
Kontext: Lambda liest S3 incoming/, schreibt thumbnails/, schreibt DynamoDB image-metadata, publiziert SNS alert-topic und schreibt CloudWatch Logs.
Prüfe: Wildcards, Löschrechte, zu breite Resource, sinnvolle Condition und Log-Umfang.
Gib eine Tabelle mit Sid, risk, reason und safer fix aus."

Access Analyzer prüft Grammatik, ARN, Aktionsnamen, Condition Keys und Sicherheitsmeldungen. Ob die Anwendung die Berechtigung wirklich braucht, muss weiterhin ein Mensch entscheiden.

Rolle mit CDK implementieren

Konsolenänderungen sind schwer nachvollziehbar. Mit TypeScript CDK bleiben Rolle, Loggruppe und Policy in derselben Codeänderung.

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 mit OIDC statt Langzeitschlüsseln

Für CI/CD sollten keine langfristigen AWS Access Keys in Repository-Secrets liegen. GitHub Actions kann per OIDC eine IAM-Rolle übernehmen und temporäre Anmeldedaten erhalten.

{
  "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"
        }
      }
    }
  ]
}

Das ist eine Trust Policy: Sie entscheidet, wer die Rolle übernehmen darf. Die Permissions Policy entscheidet, was danach erlaubt ist. Beide Dokumente sollten getrennt geprüft werden.

Häufige Fehler

Erstens bleiben temporäre Adminrechte liegen. Wenn eine Notlage breite Rechte erzwingt, braucht es Owner, Ablaufdatum, CloudTrail-Prüfung und erneute Access-Analyzer-Validierung.

Zweitens werden S3-Bucket- und Objekt-ARNs verwechselt. s3:ListBucket nutzt arn:aws:s3:::bucket-name; s3:GetObject und s3:PutObject nutzen arn:aws:s3:::bucket-name/prefix/*.

Drittens werden IP-Bedingungen unüberlegt an Lambda-Rollen gehängt. aws:SourceIp kann für Menschen oder öffentliche APIs sinnvoll sein, aber AWS-Service-zu-Service-Aufrufe stören.

Viertens wird nur Erfolg getestet. Prüfen Sie auch, dass s3:DeleteObject, fremde Buckets, fremde DynamoDB-Tabellen und IAM-Aktionen verweigert werden.

Weiterführende Artikel

Für Details lesen Sie den AWS-Lambda-Leitfaden, den AWS-S3-Leitfaden, den AWS-CloudWatch-Leitfaden und die Claude-Code-Sicherheitspraktiken.

Wenn Ihr Team Claude Code, AWS IAM, CDK und CI-Permissions standardisieren möchte, ist die Seite Training und Beratung der passende Einstieg. Einzelne Leser starten mit dem kostenlosen Spickzettel und den Vorlagen auf der Produktseite.

Ich habe den Ablauf praktisch getestet: Policy mit Claude Code entwerfen, JSON validieren und CDK gegen dieselbe Anwendungsfall-Tabelle prüfen. Der größte Effekt kam durch die vorher notierten verbotenen Aktionen; breite S3-Rechte und unnötige Log-Wildcards wurden vor dem Deployment sichtbar.