mcpField
S
securing-aws-lambda-execution-roles

securing-aws-lambda-execution-roles

github.com/mukul975安全35.2k81 次安装8 周前更新
代码仓库

关于 securing-aws-lambda-execution-roles

面向 AWS Serverless 团队的安全指南,用于审计和收紧 Lambda 执行角色权限。它结合 CloudTrail 中的实际 API 使用情况、最小权限策略、权限边界和组织级限制。

主要功能

  1. 01审计 Lambda 执行角色权限
  2. 02依据 CloudTrail 使用情况确定权限
  3. 03创建资源范围最小权限策略
  4. 04设置权限边界
  5. 05使用 Access Analyzer 验证策略
  6. 06通过 SCP 执行角色标准

适用场景

  1. 01修复审计发现的过度授权角色
  2. 02为新 Lambda 函数定义权限
  3. 03为团队建立可复用的 IAM 模板
  4. 04降低共享 AdministratorAccess 角色风险

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill securing-aws-lambda-execution-roles

安装后在 Claude Code 中输入/securing-aws-lambda-execution-roles确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

LICENSE
references/
api-reference.md
scripts/
agent.py

详细介绍

保护 AWS Lambda 执行角色安全

适用场景

  • 部署新的 Lambda 函数并定义其 IAM 执行角色时
  • 修复安全审计中发现的权限过宽的 Lambda 角色时
  • 为无服务器架构实施最小权限访问模式时
  • 为跨团队的 Lambda 函数构建可复用的 IAM 模板时
  • Security Hub 或 Prowler 报告 Lambda 函数存在过度权限时

不适用于保护 Lambda 函数调用安全(应使用基于资源的策略和 API Gateway 授权方)、Lambda 代码安全(应使用 SAST 工具)或 Lambda 网络安全(应使用 VPC 配置和安全组)。

前置条件

  • 具备策略创建、角色修改和 Access Analyzer 操作的 IAM 权限
  • 账户中已启用 AWS IAM Access Analyzer
  • 已为 Lambda 启用 CloudTrail 数据事件以捕获实际 API 使用情况
  • 存在可供审计和权限范围界定的现有 Lambda 函数
  • 了解每个函数所需的 AWS 服务交互

工作流

步骤 1:审计当前 Lambda 执行角色权限

枚举所有 Lambda 函数及其关联的 IAM 角色,识别权限过高的函数。

# List all Lambda functions with their execution roles
aws lambda list-functions \
  --query 'Functions[*].[FunctionName,Role]' --output table

# For each function, analyze attached policies
for func in $(aws lambda list-functions --query 'Functions[*].FunctionName' --output text); do
  role_arn=$(aws lambda get-function-configuration --function-name "$func" --query 'Role' --output text)
  role_name=$(echo "$role_arn" | awk -F'/' '{print $NF}')
  echo "=== $func -> $role_name ==="

  # Check for AWS managed policies (often too broad)
  aws iam list-attached-role-policies --role-name "$role_name" \
    --query 'AttachedPolicies[*].[PolicyName,PolicyArn]' --output table

  # Check inline policies
  for policy in $(aws iam list-role-policies --role-name "$role_name" --query 'PolicyNames' --output text); do
    echo "  Inline: $policy"
    aws iam get-role-policy --role-name "$role_name" --policy-name "$policy" \
      --query 'PolicyDocument' --output json
  done
done
步骤 2:使用 CloudTrail 分析实际 API 使用情况

使用 CloudTrail 和 IAM Access Analyzer 确定函数实际使用的 API 操作。

# Query CloudTrail for actual API calls made by a Lambda execution role
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=LAMBDA_ROLE_NAME \
  --start-time 2026-01-23T00:00:00Z \
  --end-time 2026-02-23T00:00:00Z \
  --query 'Events[*].[EventTime,EventName,EventSource]' \
  --output table | sort -k2 | uniq -f1

# Use IAM Access Analyzer policy generation (based on CloudTrail activity)
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::ACCOUNT:role/lambda-execution-role",
    "cloudTrailDetails": {
      "trailArn": "arn:aws:cloudtrail:us-east-1:ACCOUNT:trail/management-trail",
      "startTime": "2026-01-23T00:00:00Z",
      "endTime": "2026-02-23T00:00:00Z"
    }
  }'

# Check the generated policy
aws accessanalyzer get-generated-policy \
  --job-id JOB_ID \
  --query 'generatedPolicyResult.generatedPolicies[*].policy'
步骤 3:创建最小权限执行策略

构建范围限定的 IAM 策略,仅授予每个函数所需的特定操作和资源。

# Example: Scoped policy for a function that reads from S3 and writes to DynamoDB
cat > lambda-scoped-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInputBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::input-data-bucket",
        "arn:aws:s3:::input-data-bucket/*"
      ]
    },
    {
      "Sid": "WriteDynamoDB",
      "Effect": "Allow",
      "Action": [
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:BatchWriteItem"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:ACCOUNT:table/results-table"
    },
    {
      "Sid": "CloudWatchLogs",
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:us-east-1:ACCOUNT:log-group:/aws/lambda/my-function:*"
    }
  ]
}
EOF

# Create the policy
aws iam create-policy \
  --policy-name lambda-my-function-policy \
  --policy-document file://lambda-scoped-policy.json

# Create execution role with scoped trust policy
cat > lambda-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "aws:SourceAccount": "ACCOUNT_ID"
      }
    }
  }]
}
EOF

aws iam create-role \
  --role-name lambda-my-function-role \
  --assume-role-policy-document file://lambda-trust-policy.json

aws iam attach-role-policy \
  --role-name lambda-my-function-role \
  --policy-arn arn:aws:iam::ACCOUNT:policy/lambda-my-function-policy
步骤 4:应用权限边界

实施权限边界,为 Lambda 执行角色设置最大权限。

# Create a permission boundary that caps Lambda role capabilities
cat > lambda-permission-boundary.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject", "s3:PutObject", "s3:ListBucket",
        "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query", "dynamodb:UpdateItem",
        "sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage",
        "sns:Publish",
        "secretsmanager:GetSecretValue",
        "kms:Decrypt", "kms:GenerateDataKey",
        "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents",
        "xray:PutTraceSegments", "xray:PutTelemetryRecords"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyPrivilegeEscalation",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser", "iam:CreateRole", "iam:CreatePolicy",
        "iam:AttachRolePolicy", "iam:AttachUserPolicy",
        "iam:PutRolePolicy", "iam:PutUserPolicy",
        "iam:CreateAccessKey", "iam:PassRole",
        "lambda:CreateFunction", "lambda:UpdateFunctionConfiguration",
        "sts:AssumeRole"
      ],
      "Resource": "*"
    }
  ]
}
EOF

# Create and apply the boundary
aws iam create-policy \
  --policy-name lambda-permission-boundary \
  --policy-document file://lambda-permission-boundary.json

aws iam put-role-permissions-boundary \
  --role-name lambda-my-function-role \
  --permissions-boundary arn:aws:iam::ACCOUNT:policy/lambda-permission-boundary
步骤 5:使用 IAM Access Analyzer 验证策略

使用 Access Analyzer 验证策略是否符合安全最佳实践。

# Validate the scoped policy
aws accessanalyzer validate-policy \
  --policy-document file://lambda-scoped-policy.json \
  --policy-type IDENTITY_POLICY \
  --query 'findings[*].[findingType,issueCode,learnMoreLink]' --output table

# Check for unused access
aws accessanalyzer check-no-new-access \
  --new-policy-document file://lambda-scoped-policy.json \
  --existing-policy-document file://old-broad-policy.json \
  --policy-type IDENTITY_POLICY

# Verify the permission boundary effectiveness
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT:role/lambda-my-function-role \
  --action-names iam:CreateUser iam:PassRole s3:GetObject dynamodb:PutItem \
  --query 'EvaluationResults[*].[EvalActionName,EvalDecision]' --output table
步骤 6:使用 SCP 强制执行角色标准

应用服务控制策略,防止 Lambda 函数使用权限过宽的角色。

# SCP to deny Lambda functions using AdministratorAccess
cat > scp-deny-lambda-admin.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyLambdaAdminRole",
    "Effect": "Deny",
    "Action": "lambda:CreateFunction",
    "Resource": "*",
    "Condition": {
      "ForAnyValue:StringLike": {
        "lambda:FunctionArn": "*"
      },
      "ArnLike": {
        "iam:PassedToService": "lambda.amazonaws.com"
      }
    }
  },
  {
    "Sid": "RequirePermissionBoundary",
    "Effect": "Deny",
    "Action": [
      "iam:CreateRole",
      "iam:AttachRolePolicy",
      "iam:PutRolePolicy"
    ],
    "Resource": "arn:aws:iam::*:role/lambda-*",
    "Condition": {
      "StringNotEquals": {
        "iam:PermissionsBoundary": "arn:aws:iam::*:policy/lambda-permission-boundary"
      }
    }
  }]
}
EOF

aws organizations create-policy \
  --name "lambda-role-guardrails" \
  --type SERVICE_CONTROL_POLICY \
  --content file://scp-deny-lambda-admin.json

关键概念

术语定义
执行角色Lambda 在函数执行期间代入的 IAM 角色,定义了函数可执行的所有 AWS API 操作
最小权限仅授予函数执行预期操作所需最低权限的安全原则
权限边界设置执行角色可拥有最大权限的 IAM 策略,即使身份策略授予了更广泛的访问权限
IAM Access Analyzer基于实际 CloudTrail 使用情况生成最小权限策略并验证策略安全问题的 AWS 服务
资源范围限定策略指定确切资源 ARN 而非通配符的 IAM 策略,将访问限制为仅所需的特定资源
混淆代理防范在信任策略中添加 aws:SourceAccount 或 aws:SourceArn 条件,防止跨账户角色代入攻击

工具与系统

  • IAM Access Analyzer:基于 CloudTrail 数据生成最小权限策略并验证策略安全性
  • IAM Policy Simulator:在部署前针对特定 API 操作测试角色的有效权限
  • CloudTrail:所有 API 调用的审计日志,用于确定函数的实际权限使用情况
  • Prowler:包含针对角色权限和配置的 Lambda 专项检查的安全工具
  • Checkov:验证 CloudFormation/Terraform 中 Lambda IAM 策略的基础设施即代码扫描器

常见场景

场景:将 Lambda 函数从 AdministratorAccess 缩减到最小权限

背景:一次安全审计发现 12 个 Lambda 函数使用共享执行角色,并带有 AdministratorAccess。团队需要在不断生产环境的前提下,将每个函数的权限限定为所需的最小权限。

方法:

  1. 为 Lambda 启用 CloudTrail 数据事件,以捕获每个函数的实际 API 使用情况
  2. 等待 30 天,收集具有代表性的 API 调用样本
  3. 针对每个函数的角色使用情况,使用 IAM Access Analyzer 策略生成
  4. 根据实际 API 使用情况,为每个函数创建单独的范围限定策略
  5. 应用权限边界,以限制最大权限
  6. 将范围限定的角色部署到预发布环境并运行集成测试
  7. 通过金丝雀部署和回滚计划逐步发布到生产环境
  8. 在移除旧的宽泛角色之前,使用 IAM Policy Simulator 进行验证

陷阱:某些 Lambda 函数可能包含很少执行的代码路径,这些路径仅在每月触发(批处理作业、错误处理程序)。30 天的观察窗口可能会遗漏罕见的 API 调用。请结合函数代码和 CloudTrail 数据一起审查,以识别所有可能的 API 调用。使用 Access Analyzer 的策略验证,而不是仅依赖生成的策略。

输出格式

Lambda Execution Role Security Report
========================================
Account: 123456789012
Review Date: 2026-02-23
Functions Audited: 34

ROLE PERMISSION SUMMARY:
  Functions with AdministratorAccess:    3 (CRITICAL)
  Functions with PowerUserAccess:        5 (HIGH)
  Functions with wildcard actions:      12 (MEDIUM)
  Functions with scoped policies:       14 (OK)

REMEDIATION PROGRESS:
  [x] payment-processor: Scoped to DynamoDB + S3 + KMS (3 actions)
  [x] order-notification: Scoped to SNS + SES (2 actions)
  [ ] data-pipeline: Generating policy from 30-day CloudTrail data
  [ ] image-resizer: Awaiting staging validation

PERMISSION BOUNDARY STATUS:
  Functions with boundary applied:  14 / 34
  Functions without boundary:       20 / 34

POLICY VALIDATION RESULTS:
  Policies with security warnings:   4
  Policies with errors:              0
  Policies with suggestions:        12

评论

支持 Markdown