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 角色。

```bash
# 为特定 Lambda 函数创建最小权限角色
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"
    }]
  }'

# 附加范围化策略（而非 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 调用在运行时获取密钥。

```python
# 不安全的做法：硬编码凭证存储在环境变量中
# DB_PASSWORD = os.environ['DB_PASSWORD']  # 以明文存储在 Lambda 配置中

# 安全的做法：从 AWS Secrets Manager 获取并缓存
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']
    # 安全地使用凭证
```

```bash
# 为 Lambda 环境变量启用静态加密
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 流水线中集成自动化依赖扫描，在部署前发现存在漏洞的包。

```bash
# 针对 Node.js Lambda 函数的 npm audit
cd lambda-function/
npm audit --audit-level=high
npm audit fix

# CI/CD 流水线中的 Snyk 扫描
snyk test --severity-threshold=high
snyk monitor --project-name=order-processor-lambda

# 针对 Python Lambda 函数的 pip-audit
pip-audit -r requirements.txt --desc on --fix

# 使用 Trivy 扫描 Lambda 部署包
trivy fs --severity HIGH,CRITICAL ./lambda-package/
```

```yaml
# GitHub Actions CI/CD 安全扫描
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 注入攻击。

```python
import re
import json
from jsonschema import validate, ValidationError

# 定义预期的输入 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):
    # 验证 API Gateway 事件 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': '输入无效', 'details': str(e)})
        }

    # 验证通过后可安全继续
    order_id = body['orderId']
    # 对数据库操作使用参数化查询
```

### 步骤 5：配置函数 URL 和 API Gateway 认证

为函数调用端点配置适当的认证。切勿在没有 IAM 或 Cognito 认证的情况下暴露 Lambda 函数 URL。

```bash
# 使用 IAM 认证保护 Lambda 函数 URL（不使用 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
  }'

# 带 Cognito 授权器的 API Gateway
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 结构化日志，检测函数异常行为。

```bash
# 启用 GuardDuty Lambda 保护
aws guardduty update-detector \
  --detector-id <detector-id> \
  --features '[{"Name": "LAMBDA_NETWORK_ACTIVITY_LOGS", "Status": "ENABLED"}]'

# 配置 Lambda 使用结构化日志
aws lambda update-function-configuration \
  --function-name order-processor \
  --logging-config '{"LogFormat": "JSON", "ApplicationLogLevel": "INFO", "SystemLogLevel": "WARN"}'
```

## 核心概念

| 术语 | 定义 |
|------|------|
| 冷启动（Cold Start） | 包含容器预配的初次函数调用，会增加延迟，并产生缓存密钥可能尚不可用的窗口期 |
| 事件注入（Event Injection） | 在来自 API Gateway、S3、SQS 或其他事件源的 Lambda 事件数据中嵌入恶意输入以利用函数的攻击方式 |
| 执行角色（Execution Role） | Lambda 在执行期间承担的 IAM 角色，定义函数可以使用的所有云 API 权限 |
| 函数 URL（Function URL） | Lambda 函数的直接 HTTPS 端点，可配置 IAM 认证或无认证（NONE 不安全） |
| 层（Layer） | 包含共享代码或依赖项的 Lambda 部署包，应独立进行漏洞扫描 |
| 预留并发（Reserved Concurrency） | 函数的最大并发执行数，用于防止资源耗尽攻击 |
| 预置并发（Provisioned Concurrency） | 预初始化的函数实例，降低冷启动延迟并确保密钥已缓存 |

## 工具与系统

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

## 常见场景

### 场景：通过 API Gateway -> Lambda -> RDS 进行 SQL 注入

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

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

**常见陷阱**：仅依赖 WAF 规则而不修复底层代码漏洞，攻击者可通过编码技巧绕过。不正确地使用 ORM 方法（原始查询）仍然允许注入攻击。

## 输出格式

```
无服务器安全评估报告
=======================================
账户: 123456789012
已评估函数数: 47
评估日期: 2025-02-23

严重发现:
  [SLS-001] order-processor: 通过字符串拼接实施的 SQL 注入
    语言: Python 3.12 | 运行时: Lambda
    漏洞代码: f"SELECT * FROM orders WHERE id = '{order_id}'"
    修复建议: 使用 psycopg2 的参数化查询

  [SLS-002] payment-handler: 环境变量中硬编码的 Stripe API 密钥
    密钥: sk_live_XXXX...（未加密）
    修复建议: 迁移到使用 KMS 加密的 AWS Secrets Manager

高危发现:
  [SLS-003] 12 个函数共享同一个具有 s3:* 权限的 IAM 执行角色
  [SLS-004] 8 个函数的函数 URL AuthType 为 NONE
  [SLS-005] 23 个函数包含已知高危 CVE 的依赖项

依赖漏洞:
  axios@0.21.1:         CVE-2023-45857（高危）- 影响 5 个函数
  jsonwebtoken@8.5.1:   CVE-2022-23529（严重）- 影响 3 个函数
  lodash@4.17.15:       CVE-2021-23337（高危）- 影响 11 个函数

摘要:
  严重: 2 | 高危: 5 | 中危: 12 | 低危: 8
  具有最小权限的函数: 14/47 (30%)
  使用 Secrets Manager 的函数: 19/47 (40%)
  具有输入验证的函数: 22/47 (47%)
```