3. Serverless 控制面架构：控制面组件与策略执行点分布
Serverless 平台的控制面是 RBAC 策略生效的核心战场。与数据面（函数运行时、事件数据流）不同，控制面负责管理函数生命周期、事件路由、权限校验和资源配额。理解控制面各组件的职责以及策略执行点（PEP）的分布，是后续分析命中率与误报率的基础。
3.1 控制面三大核心组件
典型的 Serverless 控制面由以下三个关键组件构成，它们各自承载不同的 RBAC 策略校验逻辑：
| 组件 | 核心职责 | RBAC 策略关联 |
|---|---|---|
| API Gateway | 统一入口，接收用户/服务发起的 REST/gRPC 请求，完成身份认证与初步鉴权 | 校验调用者是否有权访问特定 API 路径、HTTP 方法；触发策略命中率统计的起点 |
| Function Controller | 管理函数 CRUD、版本、别名、触发器绑定；维护函数状态机 | 校验对函数资源的创建、更新、删除、调用权限；是误报高发区（如别名权限继承） |
| Event Broker | 接收事件源（对象存储、消息队列、定时器），按规则路由到目标函数 | 校验事件源到函数之间的订阅/触发权限；跨命名空间场景下易产生误报 |
关键认知： 三个组件并非独立鉴权。一个请求可能依次经过 API Gateway → Function Controller → Event Broker，形成链式策略校验。链式校验中任一环节拒绝，都会导致最终请求失败，但审计日志中可能只记录最后一个拒绝点，造成误报。
3.2 策略执行点（PEP）分布
策略执行点（Policy Enforcement Point）是 RBAC 策略实际被评估和执行的逻辑位置。在 Serverless 控制面中，PEP 分布在以下三个层级：
- 入口 PEP（API Gateway 层）：对每个入站请求进行身份令牌验证、路径匹配、方法校验。此层通常使用粗粒度策略（如“是否允许访问 /v1/functions/*”），命中率高但误报率低。
- 资源 PEP（Function Controller 层）：在函数资源变更时触发，校验主体对特定函数、版本、别名的操作权限。此层策略粒度细，涉及资源标签、命名空间隔离，误报率较高。
- 事件 PEP（Event Broker 层）：在事件路由时校验源到目标的绑定关系。此层常涉及跨服务、跨账号授权，策略上下文复杂，是误报复核的重点区域。
常见陷阱： 许多团队只关注 API Gateway 层的 PEP 日志，忽略了 Function Controller 和 Event Broker 层的策略校验。这会导致 RBAC 策略命中率统计严重失真——实际拒绝发生在下游，但审计日志却显示“API 层通过”。
3.3 控制面架构与策略流（SVG 图）
下图展示了 Serverless 控制面三大组件及其策略执行点的分布，以及一次典型请求的策略流路径：
3.4 策略执行点对比：粒度与误报倾向
不同 PEP 的策略粒度、评估上下文和误报倾向存在显著差异。下表总结了三个 PEP 的关键特征：
| 特征维度 | 入口 PEP（API Gateway） | 资源 PEP（Function Controller） | 事件 PEP（Event Broker） |
|---|---|---|---|
| 策略粒度 | API 路径 + HTTP 方法 | 函数资源 + 版本 + 别名 | 事件源 + 目标函数 + 事件类型 |
| 评估上下文 | 请求头、令牌、路径参数 | 资源标签、命名空间、所有权 | 事件元数据、源账号、目标账号 |
| 命中率典型值 | 高（80-95%） | 中（60-80%） | 低（40-60%） |
| 误报率倾向 | 低（策略简单，边界清晰） | 中（别名继承、标签匹配歧义） | 高（跨账号、事件类型模糊匹配） |
| 审计日志完整性 | 完整记录每次请求 | 仅记录变更操作 | 可能缺失事件路由失败日志 |
实践建议： 在复核 RBAC 策略误报时，优先排查 Event Broker 层的 PEP 日志。该层策略上下文最复杂，且日志完整性最差，是误报的“重灾区”。建议在 Event Broker 侧增加显式的策略评估日志，记录每次事件路由的授权决策。
3.5 策略执行点分布图（SVG 图）
下图从另一个视角展示了三个 PEP 在控制面中的逻辑位置，以及它们与策略存储（Policy Store）和审计日志系统的关系：
架构洞察： 三个 PEP 共享同一个策略存储，但各自缓存策略的快照。当策略更新时，缓存不一致会导致不同 PEP 对同一请求做出不同决策——这是误报的另一个重要来源。建议在策略存储层增加版本号机制，每次策略变更后强制刷新所有 PEP 的缓存。