Serverless与函数计算安全第03页：认证授权与函数身份治理

01 · 函数认证授权双闸口模型

函数安全的第一性问题是授权。与虚拟机"登录即一切"不同，函数存在两道相互独立的授权闸口，任何一道失守都构成完整攻击路径：

• 闸口一：调用授权（Who can invoke）——决定哪些主体可以触发函数。AWS侧的机制包括IAM签名请求（SigV4）、函数资源策略（Resource-based Policy）、函数URL的AuthType配置（NONE / IAM），以及API网关层的授权器（Cognito JWT授权器、Lambda授权器、IAM授权）；Azure侧默认使用Function Keys（主机密钥/函数密钥），官方文档明确推荐迁移至Microsoft Entra ID认证；GCP侧通过IAM成员绑定（如roles/run.invoker）；国内云以RAM策略与触发器鉴权为主。
• 闸口二：执行授权（What the function can do）——决定函数代码能访问哪些云资源。AWS使用执行角色（Execution Role）+ IAM策略；Azure使用托管标识（Managed Identity，分系统分配与用户分配）；GCP使用服务账号（Service Account）；阿里云函数计算使用服务角色（RAM Role）。

1.1 跨平台身份与授权机制对照

02 · 执行角色最小权限工程

2.1 反模式清单

2.2 最小权限策略示例（教学示意）

示例：一个仅被允许读取指定S3桶对象、写入指定DynamoDB表的处理函数执行角色策略（AWS IAM JSON，教学示例，非可直接部署模板）：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadSpecificBucketOnly",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:GetObjectVersion"],
      "Resource": "arn:aws:s3:::example-ingress-bucket/*"
    },
    {
      "Sid": "WriteSpecificTableOnly",
      "Effect": "Allow",
      "Action": ["dynamodb:PutItem", "dynamodb:UpdateItem"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/processed-records"
    }
  ]
}

该示例体现三个原则：动作最小集（只读所需两个S3动作）、资源精确到ARN（不含通配符）、无管理面权限（不含iam/kms/organizations类动作）。

2.3 权限治理的持续化

• 权限边界（Permissions Boundary）：为函数角色附加边界策略，即使开发者后续附加策略也无法越界（AWS官方机制）。
• 未使用权限回收：IAM Access Analyzer的未使用访问分析可枚举角色在分析期内未调用的权限，支撑"先收紧、误伤再放行"的收敛流程。
• 变更审计：AttachRolePolicy / PutRolePolicy / CreatePolicyVersion等事件纳入告警（第7页检测场景）。

03 · 凭证治理：从长期密钥到短期身份

3.1 函数内凭证的三种形态与风险序

3.2 CI/CD部署身份的OIDC联邦

函数部署流水线使用长期AK是凭证泄露的重灾区（Denonia的部署途径推测即为凭证泄露）。现代实践是OIDC联邦：GitHub Actions、GitLab CI、Azure DevOps等CI系统以平台OIDC身份令牌换取云角色临时凭证（如GitHub Actions经AssumeRoleWithWebIdentity对接AWS，官方文档可查），流水线全程无长期密钥；AssumeRole临时凭证有效期可在15分钟至12小时间配置（默认1小时）。这一机制同时带来精细授权可能——可按仓库、分支、环境限定可Assume的角色（第6页流水线专项）。

3.3 出站面的凭证防外泄

• 函数默认可访问互联网——对持有高价值数据的函数，出站目的地应经NAT网关白名单或VPC终端节点收敛（第5页）。
• 禁用对云元数据端点与内部控制面的不必要访问；自建服务若暴露内部凭证端点，应视同生产机密面管理。
• 在代码评审清单中加入"禁止将凭证写入日志/异常消息/响应体"（SAS-10：不当错误处理常与凭证回显伴生）。

04 · 密钥与令牌管理基线

4.1 环境变量≠密钥管理

Lambda环境变量在静态存储时默认使用AWS托管KMS密钥加密（官方文档明确该行为，可切换为客户管理密钥以获得密钥使用审计），这解决了"静态加密"却不解决"运行时暴露"：任何具备函数读取权限的角色（GetFunction / DescribeFunctionConfiguration）均可获取环境变量明文；函数异常栈、调试日志与配置导出也常以明文形式携带环境变量。结论：低敏感度配置可放环境变量；高价值密钥（数据库口令、第三方支付密钥、Webhook签名密钥）必须托管于Secrets Manager / Key Vault / Secret Manager类服务。

4.2 托管密钥访问的函数侧模式

4.3 Webhook验签基线

接收第三方回调的函数必须校验事件真实性：使用提供方签名字段（如HMAC-SHA256）对原始请求体重算摘要并比对，验签失败即拒绝；严禁以"来源IP白名单"作为唯一防线（IP可伪造或经代理变化，只能作为辅助信号）。验签密钥按提供方分函数隔离存放，泄露时可单点吊销。

05 · 常见认证失效模式

本节参考来源（第3页）

以下均为真实可查的权威来源，用于支撑本页事实性表述。