Claude Code और AWS IAM: न्यूनतम अनुमति नीति की व्यावहारिक गाइड

AWS IAM यह तय करता है कि कौन, किस AWS संसाधन पर, कौन सा काम कर सकता है। नीति केवल JSON जैसी दिखती है, लेकिन Action: "*" या Resource: "*" गलती से दे दिया तो Lambda, CI काम या मानवीय खाते को जरूरत से बहुत ज्यादा अनुमति मिल सकती है। Claude Code नीति का मसौदा बनाने और समीक्षा करने में उपयोगी है, पर इसे बिना जांच के अनुमति मंजूर करने वाला साधन नहीं बनाना चाहिए।

सुरक्षित तरीका यह है: पहले उपयोग स्थिति साफ लिखें, Claude Code से मसौदा बनवाएं, IAM Access Analyzer से मान्य कराएं, इंसान ARN और व्यवसायिक सीमा जांचे, CDK में कोड बनाएं, और अंत में अनुमति वाले तथा अस्वीकृत दोनों actions test करें। सरल भाषा में, नीति अनुमति का नियम है, भूमिका अस्थायी पहचान है जिसे कार्यभार ग्रहण करता है, और principal वह उपयोगकर्ता या सेवा है जो अनुमति इस्तेमाल करती है।

Masa ने यह प्रक्रिया तब अपनाई जब production Lambda में आपात सुधार के लिए दी गई व्यापक S3 अनुमति कई सप्ताह बाद भी लगी मिली। कोई data leak नहीं हुआ, पर सीख साफ थी: Claude Code मसौदा बनाने का समय घटाता है, जिम्मेदारी नहीं।

AWS आधिकारिक दस्तावेजों को आधार बनाएं

इस लेख की IAM सलाह इन 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

मुख्य बात यह है: लंबे समय वाली access key की जगह temporary credentials और roles इस्तेमाल करें, least privilege रखें, Access Analyzer से नीति मान्य करें, शर्तें सोच-समझकर लगाएं, और उपयोग में न आने वाले users, roles, permissions तथा credentials नियमित रूप से हटाएं।

flowchart LR
  A["उपयोग स्थिति लिखें"] --> B["Claude Code मसौदा"]
  B --> C["मानवीय ARN समीक्षा"]
  C --> D["IAM Access Analyzer"]
  D --> E["CDK implementation"]
  E --> F["Allowed और denied tests"]

पहले ठोस उपयोग स्थितियां तय करें

Claude Code को सिर्फ “IAM नीति बना दो” न कहें। कर्ता, संसाधन, अनुमति वाले काम और स्पष्ट रूप से रोके जाने वाले काम साथ दें।

उपयोग स्थिति	Principal	जरूरी अनुमतियां	साफ तौर पर बचना है
Thumbnail Lambda	Lambda execution role	एक S3 prefix पढ़ना, एक S3 prefix लिखना, एक DynamoDB table लिखना, एक SNS topic publish करना, logs लिखना	S3 delete, सभी buckets पढ़ना, IAM operations
प्रशासनिक upload सहायक	API Lambda role	एक S3 prefix पर PutObject, एक DynamoDB table पर GetItem	पूरे bucket का List, KMS key management
GitHub Actions deploy	OIDC CI role	एक CloudFormation stack और target Lambda update	AdministratorAccess, सभी regions में operations
घटना जांच read-only भूमिका	Federated human user	CloudWatch Logs search, X-Ray read, relevant table GetItem	Update, delete, secrets read

“बचना है” वाला स्तंभ बहुत जरूरी है। जनरेटिव साधन जरूरत वाली अनुमति तो निकाल लेते हैं, लेकिन मना की गई सीमा न लिखी हो तो जवाब अक्सर बहुत व्यापक हो जाता है।

कॉपी-पेस्ट योग्य Lambda नीति

यह नीति ऐसी Lambda के लिए है जो S3 से images पढ़ती है, thumbnails दूसरे S3 prefix में लिखती है, metadata DynamoDB में लिखती है, error पर SNS alert भेजती है, और CloudWatch Logs में log लिखती है। Log group को infrastructure code से पहले से बनाया गया माना गया है, इसलिए भूमिका को 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:*"
    }
  ]
}

इसे policy-lambda-image-worker.json के रूप में save करें और चलाएं:

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

फिर Claude Code से संरचित समीक्षा कराएं:

claude -p "policy-lambda-image-worker.json को AWS IAM least-privilege नीति की तरह review करें।
Context: Lambda S3 incoming/ पढ़ती है, thumbnails/ में लिखती है, DynamoDB image-metadata में लिखती है, SNS alert-topic publish करती है, और CloudWatch Logs में लिखती है।
Check: wildcards, delete permissions, broad Resource, Condition correctness, और log scope।
Output: Sid / जोखिम / कारण / सुरक्षित सुधार वाली तालिका।"

Access Analyzer grammar, ARN, action names, condition keys और security findings जांचता है। लेकिन व्यवसाय को सच में अनुमति चाहिए या नहीं, यह फैसला engineer को ही करना होगा।

भूमिका को CDK में रखें

Console में हाथ से अनुमति बदलने से समीक्षा की गई स्थिति खो जाती है। TypeScript CDK में role, log group और नीति एक ही code change में review हो सकते हैं।

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 में लंबे समय वाली key नहीं, OIDC इस्तेमाल करें

CI/CD में repository secrets के अंदर लंबे समय वाली AWS access keys रखना टालें। GitHub Actions OIDC के जरिए IAM role assume कर सकता है और temporary credentials पा सकता है।

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

यह trust policy है: कौन role assume कर सकता है, यह तय करती है। Permissions policy यह तय करती है कि role assume करने के बाद क्या किया जा सकता है। दोनों की अलग-अलग समीक्षा करें।

समीक्षा में पकड़ने वाली आम गलतियां

पहली गलती अस्थायी admin access को हटाना भूलना है। आपात स्थिति में व्यापक अनुमति देनी पड़े तो owner, expiry date, CloudTrail check और Access Analyzer rerun का ticket जरूर बनाएं।

दूसरी गलती S3 bucket ARN और object ARN मिलाना है। s3:ListBucket के लिए arn:aws:s3:::bucket-name होता है; s3:GetObject और s3:PutObject के लिए arn:aws:s3:::bucket-name/prefix/*।

तीसरी गलती Lambda role पर बिना सोचे IP condition लगाना है। aws:SourceIp human access या public API के लिए काम आ सकता है, पर AWS service-to-service calls में unexpected break ला सकता है।

चौथी गलती सिर्फ success test करना है। यह भी test करें कि s3:DeleteObject, unrelated buckets, unrelated DynamoDB tables और IAM actions deny हो रहे हैं।

संबंधित लेख और अगला कदम

Lambda role design के लिए AWS Lambda guide, S3 prefix design के लिए AWS S3 guide, log audit के लिए AWS CloudWatch guide और पूरी सुरक्षा समीक्षा के लिए Claude Code security best practices पढ़ें।

अगर आपकी team Claude Code, AWS IAM, CDK और CI permission review को standard बनाना चाहती है, तो training और consultation व्यावहारिक शुरुआत है। व्यक्तिगत सीखने के लिए free cheat sheet से शुरू करें और reusable templates के लिए products page देखें।

मैंने इस प्रक्रिया को नीति मसौदे, JSON validation और CDK review के साथ खुद test किया। सबसे बड़ा फायदा यह हुआ कि रोके जाने वाले actions पहले लिखने पर broad S3 permission और unnecessary log wildcards deployment से पहले ही दिख गए। Access Analyzer और denied-action tests ने review को सिर्फ भरोसे पर नहीं, evidence पर खड़ा किया।