Claude Code × AWS IAM Vollständiger Leitfaden | Minimale Berechtigungsrichtlinien automatisch generieren

IAM-Richtliniendesign ist „unscheinbar, aber bei Fehlern katastrophal”. Richtlinien mit Wildcard-Missbrauch (*) sind Brutstätten für Sicherheitsvorfälle. Andererseits kostet das Schreiben von Least-Privilege-Richtlinien von Grund auf viel Zeit.

Ich betreibe eine serverlose Architektur mit Lambda, S3, DynamoDB und CloudWatch in der Produktion. Durch die Übertragung von IAM-Richtliniendesign und -überprüfung an Claude Code habe ich die Arbeitszeit um ca. 70% reduziert. Dieser Artikel erklärt die praktischen Schritte.

---

IAM-Grundlagen in 3 Minuten

Richtlinienstruktur

{
  "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 (Erlauben) oder Deny (Verweigern)
• Action: Die zu erlaubenden/verweigernden API-Aktionen
• Resource: ARN der Zielressource (spezifischer = sicherer)
• Condition: Zusätzliche Bedingungen (IP-Einschränkungen, MFA erforderlich usw.)

Prinzip der minimalen Berechtigungen

„Erlaube nur die benötigten Operationen auf nur den benötigten Ressourcen” ist die goldene Regel von IAM.

❌ Gefährlich: Wildcard-Missbrauch
Action: "*"
Resource: "*"

✅ Sicher: Konkret angeben
Action: ["s3:GetObject", "s3:PutObject"]
Resource: "arn:aws:s3:::my-uploads-bucket/user-files/*"

---

Step 1: Anwendungsfall beschreiben und Richtlinie automatisch generieren

Richtlinie für Lambda generieren

claude -p "
Generiere die minimale erforderliche IAM-Richtlinie in JSON für folgende Lambda-Funktion.

[Lambda-Verarbeitung]
- Bilder aus S3-Bucket 'user-uploads-prod' lesen
- Verarbeitete Bilder in 'user-thumbnails-prod' speichern
- Ergebnisse in DynamoDB-Tabelle 'image-metadata' aufzeichnen
- SNS-Topic 'alert-topic' bei Fehler benachrichtigen
- Logs in CloudWatch Logs schreiben

[Einschränkungen]
- Löschoperationen werden nicht benötigt
- Verwende Konto-ID 123456789012, Region ap-northeast-1 für Ressource-ARNs
- Keine IP-Einschränkung per Condition (für Lambda nicht nötig)
"

Generiertes Beispiel:

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

---

Step 2: Sicherheitsüberprüfung bestehender Richtlinien

Lassen Sie Claude Code bestehende Richtlinien auf Probleme überprüfen.

claude -p "
Überprüfe die folgende IAM-Richtlinie aus einer Sicherheitsperspektive.
Identifiziere konkrete Probleme und gib spezifische Lösungsvorschläge.

$(cat policy.json)
"

Typische Probleme, die Claude Code meldet:

Problem 1: Resource: "*" gewährt vollständigen S3-Zugriff
  → Ziel-Buckets und Prefixes konkret angeben

Problem 2: s3:DeleteObject ist enthalten, aber nicht vom Prozess benötigt
  → Löschoperation entfernen

Problem 3: iam:PassRole mit Wildcard-Ressource erlaubt
  → PassRole nur auf spezifische Rollen-ARNs beschränken (Privilege-Escalation-Risiko)

Problem 4: CloudTrail-Aktivierung kann nicht bestätigt werden
  → Aktivierung der IAM-Operationsprotokollierung empfohlen

---

Step 3: Automatisierung des Rollendesigns

Rollendesign über mehrere Services hinweg

claude -p "
Entwirf alle notwendigen IAM-Rollen für folgende Architektur:

[Architektur]
- API Gateway → Lambda (Authentifizierung)
- Lambda → DynamoDB (Benutzerdaten lesen/schreiben)
- Lambda → S3 (Dateispeicherung)
- Lambda → SES (E-Mail-Versand)
- CloudWatch Events → Lambda (Batch-Verarbeitung)
- CodePipeline → S3, CodeBuild, Lambda (Deployment)

[Ausgabeformat]
- Name und Zweck jeder Rolle
- Trust Policy
- Access Policy
- Als AWS CDK TypeScript-Code ausgeben
"

CDK-Implementierung der Rollen

// 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);

    // Lambda-Ausführungsrolle (minimale Berechtigungen)
    const lambdaRole = new iam.Role(this, "ApiLambdaRole", {
      assumedBy: new iam.ServicePrincipal("lambda.amazonaws.com"),
      roleName: "api-lambda-role",
      description: "Least-Privilege-Rolle für API Lambda",
    });

    // DynamoDB Lese-/Schreibberechtigungen (nur spezifische Tabelle)
    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/*`,
        ],
      })
    );

    // S3-Schreibberechtigungen (nur spezifischer Bucket und Prefix)
    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/*`,
        ],
      })
    );

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

    // CloudWatch Logs Schreibberechtigungen
    lambdaRole.addManagedPolicy(
      iam.ManagedPolicy.fromAwsManagedPolicyName(
        "service-role/AWSLambdaBasicExecutionRole"
      )
    );
  }
}

---

Step 4: Überprüfung der IAM Access Analyzer-Ergebnisse

Lassen Sie Claude Code die IAM Access Analyzer-Ausgabe überprüfen.

# Access Analyzer-Ergebnisse abrufen
aws accessanalyzer list-findings --analyzer-arn arn:aws:access-analyzer:... \
  --output json > analyzer-findings.json

claude -p "
Lese die folgenden IAM Access Analyzer-Ergebnisse und:
1. Klassifiziere nach Schweregrad (HIGH/MEDIUM/LOW)
2. Identifiziere sofort zu behebende Elemente
3. Gib spezifische Behebungsschritte für jeden Punkt an

$(cat analyzer-findings.json)
"

---

Step 5: SCP-Design (Organisationsweite Leitplanken)

Bei Verwendung von AWS Organizations legen Sie mit SCPs (Service Control Policies) Leitplanken für gesamte Konten fest.

claude -p "
Entwirf eine SCP zur Anwendung auf Produktions-AWS-Konten.
Sie muss folgende Anforderungen erfüllen:

1. Alle Regionen außer ap-northeast-1 (Tokio) und us-east-1 (Virginia) deaktivieren
2. API-Operationen durch das Root-Konto verbieten
3. Deaktivieren oder Löschen von CloudTrail verbieten
4. Deaktivieren von GuardDuty verbieten
5. Änderungen an einer spezifischen IAM-Rolle ('OrganizationAdminRole') verbieten
"

{
  "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 häufige Fallstricke

1. Überprivilegiertes iam:PassRole

// ❌ Gefährlich: Jede Rolle kann weitergegeben werden
{
  "Action": "iam:PassRole",
  "Resource": "*"
}

// ✅ Sicher: Nur spezifische Rolle
{
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789:role/MyLambdaRole",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "lambda.amazonaws.com"
    }
  }
}

2. Übermäßige Nutzung von AWS Managed Policies

Managed Policies wie AmazonS3FullAccess sind praktisch, enthalten aber weit mehr Berechtigungen als nötig. Wenn Lambda nur aus S3 liest, verwenden Sie eine benutzerdefinierte Richtlinie mit nur s3:GetObject.

3. Mischung aus Inline-Richtlinien und benutzerdefinierten Managed Policies

Inline-Richtlinien können nicht wiederverwendet werden und sind schwer nachzuverfolgen. Standardisieren Sie auf Managed Policies und verwalten Sie sie versioniert.

4. Fehlende MFA-Anforderung über Conditions

Erzwingen Sie immer MFA beim Wechsel zu Admin-Rollen.

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

---

Zusammenfassung

Aufgabe	Beitrag von Claude Code
Richtliniengenerierung	Generiert Least-Privilege-Richtlinien aus einer Beschreibung
Sicherheitsüberprüfung	Identifiziert Probleme und schlägt Korrekturen vor
Rollendesign	Entwirft Rollenstruktur für die gesamte Architektur
CDK-Implementierung	Generiert TypeScript IAM-Code automatisch
SCP-Design	Generiert organisationsweite Guardrail-Richtlinien

IAM ist kein „einmal einrichten und vergessen” – regelmäßige Überprüfungen sind unerlässlich. Die Gewohnheit, Claude Code monatlich bestehende Richtlinien überprüfen zu lassen, ist ein einfacher Weg zur kontinuierlichen Reduzierung von Sicherheitsrisiken.

Verwandte Artikel

• Claude Code Sicherheits-Best-Practices Vollständiger Leitfaden
• Claude Code × AWS Lambda Vollständiger Leitfaden
• Claude Code × AWS DynamoDB Vollständiger Leitfaden

Referenzen

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