securing-serverless-functions

保护无服务器函数安全

何时使用

• 在部署可访问敏感数据或云 API 的 Lambda 函数或 Azure Functions 时
• 在审计现有无服务器工作负载中权限过大的 IAM 角色时
• 在将无服务器函数集成到具备自动化安全扫描的 DevSecOps 流水线中时
• 在函数代码中发现硬编码密钥或存在漏洞的依赖项时
• 在为无服务器工作负载建立运行时监控以检测注入或凭据窃取时

请勿使用于基于容器的计算安全（参见 securing-kubernetes-on-cloud）、API Gateway 配置（参见 implementing-cloud-waf-rules），或无服务器架构设计决策。

前置条件

• 具备部署访问权限的 AWS Lambda、Azure Functions 或 GCP Cloud Functions
• 配备依赖扫描工具（npm audit、Snyk、Dependabot）的 CI/CD 流水线
• 用于密钥管理的 AWS Secrets Manager、Azure Key Vault 或 HashiCorp Vault
• 用于函数监控的 CloudWatch、Application Insights 或 Cloud Logging

工作流

步骤 1：实施最小权限 IAM 角色

为每个 Lambda 函数分配专用 IAM 角色，其权限范围仅限于该函数访问的特定资源。切勿跨函数共享 IAM 角色。

# Create a least-privilege role for a specific Lambda function
aws iam create-role \
  --role-name order-processor-lambda-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Attach a scoped policy (not AmazonDynamoDBFullAccess)
aws iam put-role-policy \
  --role-name order-processor-lambda-role \
  --policy-name order-processor-policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": ["dynamodb:PutItem", "dynamodb:GetItem"],
        "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
      },
      {
        "Effect": "Allow",
        "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
        "Resource": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/lambda/order-processor:*"
      },
      {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue"],
        "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:order-api-key-*"
      }
    ]
  }'

步骤 2：消除硬编码密钥

将环境变量中的明文凭据替换为对密钥管理服务的引用。使用 Lambda 扩展或 SDK 调用在运行时获取密钥。

# INSECURE: Hardcoded credentials in environment variable
# DB_PASSWORD = os.environ['DB_PASSWORD']  # Stored as plaintext in Lambda config

# SECURE: Retrieve from AWS Secrets Manager with caching
import boto3
from botocore.exceptions import ClientError
import json

_secret_cache = {}

def get_secret(secret_name):
    if secret_name in _secret_cache:
        return _secret_cache[secret_name]

    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId=secret_name)
    secret = json.loads(response['SecretString'])
    _secret_cache[secret_name] = secret
    return secret

def lambda_handler(event, context):
    db_creds = get_secret('production/database/credentials')
    db_host = db_creds['host']
    db_password = db_creds['password']
    # Use credentials securely

# Enable encryption at rest for Lambda environment variables
aws lambda update-function-configuration \
  --function-name order-processor \
  --kms-key-arn arn:aws:kms:us-east-1:123456789012:key/key-id

步骤 3：扫描依赖项中的漏洞

将自动化依赖扫描集成到 CI/CD 流水线中，以便在部署前捕获存在漏洞的包。

# npm audit for Node.js Lambda functions
cd lambda-function/
npm audit --audit-level=high
npm audit fix

# Snyk scanning in CI/CD pipeline
snyk test --severity-threshold=high
snyk monitor --project-name=order-processor-lambda

# pip-audit for Python Lambda functions
pip-audit -r requirements.txt --desc on --fix

# Scan Lambda deployment package with Trivy
trivy fs --severity HIGH,CRITICAL ./lambda-package/

# GitHub Actions CI/CD security scanning
name: Lambda Security Scan
on: [push, pull_request]
jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Run npm audit
        run: npm audit --audit-level=high
      - name: Snyk vulnerability scan
        uses: snyk/actions/node@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      - name: Scan with Semgrep for code vulnerabilities
        uses: returntocorp/semgrep-action@v1
        with:
          config: p/owasp-top-ten

步骤 4：实施输入验证

验证并清理所有事件输入数据，以防止通过 Lambda 事件源进行的注入攻击，包括 SQL 注入、命令注入和 NoSQL 注入。

import re
import json
from jsonschema import validate, ValidationError

# Define expected input schema
ORDER_SCHEMA = {
    "type": "object",
    "properties": {
        "orderId": {"type": "string", "pattern": "^[a-zA-Z0-9-]{1,36}$"},
        "customerId": {"type": "string", "pattern": "^[a-zA-Z0-9]{1,20}$"},
        "amount": {"type": "number", "minimum": 0.01, "maximum": 999999.99},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]}
    },
    "required": ["orderId", "customerId", "amount", "currency"],
    "additionalProperties": False
}

def lambda_handler(event, context):
    # Validate API Gateway event body
    try:
        body = json.loads(event.get('body', '{}'))
        validate(instance=body, schema=ORDER_SCHEMA)
    except (json.JSONDecodeError, ValidationError) as e:
        return {
            'statusCode': 400,
            'body': json.dumps({'error': 'Invalid input', 'details': str(e)})
        }

    # Safe to proceed with validated input
    order_id = body['orderId']
    # Use parameterized queries for database operations

步骤 5：配置函数 URL 和 API Gateway 身份验证

使用适当的身份验证保护函数调用端点。切勿在未启用 IAM 或 Cognito 身份验证的情况下暴露 Lambda 函数 URL。

# Secure Lambda function URL with IAM auth (not NONE)
aws lambda create-function-url-config \
  --function-name order-processor \
  --auth-type AWS_IAM \
  --cors '{
    "AllowOrigins": ["https://app.company.com"],
    "AllowMethods": ["POST"],
    "AllowHeaders": ["Content-Type", "Authorization"],
    "MaxAge": 3600
  }'

# API Gateway with Cognito authorizer
aws apigateway create-authorizer \
  --rest-api-id abc123 \
  --name CognitoAuth \
  --type COGNITO_USER_POOLS \
  --provider-arns "arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_EXAMPLE"

步骤 6：启用运行时监控和日志记录

配置 GuardDuty Lambda 网络活动监控和 CloudWatch 结构化日志记录，以检测异常函数行为。

# Enable GuardDuty Lambda protection
aws guardduty update-detector \
  --detector-id <detector-id> \
  --features '[{"Name": "LAMBDA_NETWORK_ACTIVITY_LOGS", "Status": "ENABLED"}]'

# Configure Lambda to use structured logging
aws lambda update-function-configuration \
  --function-name order-processor \
  --logging-config '{"LogFormat": "JSON", "ApplicationLogLevel": "INFO", "SystemLogLevel": "WARN"}'

关键概念

术语	定义
冷启动	包含容器预置的首次函数调用，会增加延迟并产生一个缓存密钥可能不可用的窗口期
事件注入	将恶意输入嵌入来自 API Gateway、S3、SQS 或其他事件源的 Lambda 事件数据中以利用函数的攻击
执行角色	Lambda 在执行期间代入的 IAM 角色，定义该函数可使用的所有云 API 权限
函数 URL	Lambda 函数的直接 HTTPS 端点，可配置 IAM 身份验证或无身份验证（NONE 不安全）
层	包含共享代码或依赖项的 Lambda 部署包，应独立扫描其漏洞
预留并发	函数的最大并发执行数，可用于防止资源耗尽攻击
预置并发	预先初始化的函数实例，可减少冷启动延迟并确保密钥被缓存

工具与系统

• AWS Lambda Power Tuning：用于优化 Lambda 内存与超时设置、在安全性与性能之间取得平衡的开源工具
• Snyk：SCA 工具，扫描 Lambda 依赖项中的已知漏洞，并自动提供修复建议
• Semgrep：SAST 工具，具备针对无服务器场景的专用规则，可检测注入漏洞、硬编码密钥和不安全配置
• GuardDuty Lambda Protection：AWS 服务，监控 Lambda 网络活动，检测与恶意端点的连接
• AWS X-Ray：分布式追踪服务，用于检测 Lambda 调用中的可疑外部连接和延迟异常

常见场景

场景：经由 API Gateway 到 Lambda 再到 RDS 的 SQL 注入

背景：某个 Lambda 函数从 API Gateway 接收用户输入，并通过字符串拼接针对 RDS PostgreSQL 数据库构造 SQL 查询。攻击者通过 API 注入 SQL 载荷。

方法：

1. 审计 Lambda 函数代码中 SQL 查询里的字符串拼接
2. 使用数据库驱动将所有字符串格式化查询替换为参数化查询
3. 在任何数据库操作之前，使用 JSON Schema 实现输入校验
4. 在 API Gateway 上添加 WAF 规则，以拦截常见的 SQL 注入模式
5. 在 CI/CD 流水线中部署 Semgrep，并使用 python.django.security.injection.sql 规则集
6. 启用 GuardDuty Lambda protection，以检测异常的数据库连接模式

陷阱：仅依赖 WAF 规则而不修复底层代码漏洞，会允许攻击者通过编码技巧绕过。错误使用 ORM 方法（原生查询）仍会允许注入。

输出格式

Serverless Security Assessment Report
=======================================
Account: 123456789012
Functions Assessed: 47
Assessment Date: 2025-02-23

CRITICAL FINDINGS:
  [SLS-001] order-processor: SQL injection via string concatenation
    Language: Python 3.12 | Runtime: Lambda
    Vulnerable Code: f"SELECT * FROM orders WHERE id = '{order_id}'"
    Remediation: Use parameterized queries with psycopg2

  [SLS-002] payment-handler: Hardcoded Stripe API key in environment variable
    Key: sk_live_XXXX... (unencrypted)
    Remediation: Migrate to AWS Secrets Manager with KMS encryption

HIGH FINDINGS:
  [SLS-003] 12 functions share the same IAM execution role with s3:*
  [SLS-004] 8 functions have function URLs with AuthType: NONE
  [SLS-005] 23 functions have dependencies with known HIGH CVEs

DEPENDENCY VULNERABILITIES:
  [email protected]:         CVE-2023-45857 (HIGH) - 5 functions affected
  [email protected]:   CVE-2022-23529 (CRITICAL) - 3 functions affected
  [email protected]:       CVE-2021-23337 (HIGH) - 11 functions affected

SUMMARY:
  Critical: 2 | High: 5 | Medium: 12 | Low: 8
  Functions with Least Privilege: 14/47 (30%)
  Functions with Secrets Manager: 19/47 (40%)
  Functions with Input Validation: 22/47 (47%)