网关权限控制
「网关权限」（Gateway Permission）是云开发资源访问控制的第一道防线。当你通过 HTTP API、开放 API 或托管域名 访问云开发资源（云函数、云托管、云存储、AI 能力等）时，请求首先到达网关层，由网关根据配置的策略决定：
- 放行（allow）：请求通过网关，进入资源层继续鉴权
- 拒绝（deny）：请求被网关拦截，不会到达资源层
鉴权顺序
网关鉴权 早于 资源鉴权。以云函数为例：
| 网关策略 | 执行情况 | 结果 |
|---|---|---|
| 未放行 | 网关直接拒绝（403/无权限） | 函数不会被执行 |
| 已放行 | 请求到达云函数 | 继续资源层/业务层鉴权 |
网关权限只控制"能否访问"，不控制"能做什么"。细粒度的数据权限应在资源层（如数据库安全规则）或业务层实现。
配置入口
进入 云开发平台/权限控制，选择目标角色 → 进入角色详情页 → 点击「添加自定义策略」→ 资源类型选择「网关」。
初始权限说明
环境初始化后，系统会自动配置默认的网关权限，你可以根据业务需求调整：
| 资源类型 | 管理员 | 组织成员 | 注册用户 | 匿名用户 |
|---|---|---|---|---|
| 云函数/云托管/云存储 | ✅ 全部可用 | ✅ 大部分可用 | ⚠️ 部分可用 | ❌ 默认不可用 |
| 国际存储链路 | 🔓 不鉴权（由资源层/业务层控制） | 🔓 不鉴权 | 🔓 不鉴权 | 🔓 不鉴权 |
匿名用户默认无法通过网关访问资源，避免未认证请求直接穿透到后端服务。
策略配置
网关权限支持两种策略配置方式：预设策略和自定义策略。
预设策略
系统提供常用的预设策略，开箱即用，适合大多数场景。
场景 1：开发测试阶段 - 管理员全权限
- 适用场景：个人开发、快速验证功能
- 推荐策略：
AdministratorAccess - 优势：无权限阻断，快速迭代
- 注意事项：⚠️ 生产环境不要将此策略绑定到面向公网的应用身份
场景 2：团队协作 - 按资源类型拆分
- 适用场景：多人协作开发，按资源域分工
- 推荐策略：
StoragesAccess：云存储访问权限FunctionsAccess：云函数访问权限CloudrunAccess：云托管访问权限
- 优势：按资源隔离权限，降低误操作风险
场景 3：对外服务 - HTTP 访问控制
- 适用场景：通过 HTTP API 对外提供服务
- 推荐策略：
FunctionsHttpApiAllow/FunctionsHttpServiceAllowCloudrunHttpApiAllowStoragesHttpServiceAllow
- 最佳实践：⚡ 先开放最小权限集合，再根据需求逐步扩展
自定义策略
当预设策略无法满足需求时，可以自定义策略实现精细化权限控制。
策略语法说明
策略 policy 由版本 version 和语句 statement 构成。每条语句 statement 包含以下字段：
| 字段 | 是否必填 | 说明 |
|---|---|---|
effect | 必填 | 策略效果：allow（允许）或 deny（拒绝） |
action | 必填 | 操作类型，格式为 功能类型:请求路径功能类型 参考下方功能列表 请求路径 为HTTP 访问服务的触发路径 示例： functions:*（所有云函数操作）、functions:/hello（访问 /hello 路径） |
resource | 必填 | 资源范围：固定填写 *（表示所有资源），细粒度控制通过 action 字段实现 |
功能列表
| 功能类型 | 标识 |
|---|---|
| 云存储 | storages |
| 云函数 | functions |
| 云托管 | cloudrun |
| 大模型 | ai |
| AI 智能体 | aibot |
| 元器 | yuanqi |
| SQL 模板 | sql |
| ChatDB | chatdb |
| APIS | apis |
| 数据模型 | model |
| 知识库 | knowledge |
| AnyService | anyservice |
策略结构示例(允许访问所有云函数)
{
"version": "1.0",
"statement": [
{
"effect": "allow",
"action": "functions:*",
"resource": "*",
}
]
}
策略优先级规则
当同一请求匹配多个策略时：
- ❌
deny优先于 ✅allow - 未匹配任何策略时，默认拒绝访问
当 allow 语句和 deny 语句同时存在时，遵循 deny 优先原则。
常见自定义策略示例
- 允许特定云函数
- 禁止危险操作
- 云存储访问
- 混合策略
允许通过 HTTP 访问路径为 /hello 的云函数：
{
"version": "1.0",
"statement": [
{
"effect": "allow",
"action": "functions:/hello",
"resource": "*"
}
]
}
禁止访问特定的敏感云函数：
{
"version": "1.0",
"statement": [
{
"effect": "deny",
"action": "functions:/dangerousFunction",
"resource": "*"
}
]
}
允许访问所有云存储资源：
{
"version": "1.0",
"statement": [
{
"effect": "allow",
"action": "storages:*",
"resource": "*"
}
]
}
允许访问所有云函数，但禁止访问特定敏感函数（deny 优先级更高）：
{
"version": "1.0",
"statement": [
{
"effect": "allow",
"action": "functions:*",
"resource": "*"
},
{
"effect": "deny",
"action": "functions:/admin",
"resource": "*"
}
]
}
最佳实践
最小权限原则
遵循「最小权限原则」（Least Privilege），按实际需要授权：
| 身份类型 | 推荐策略 | 说明 |
|---|---|---|
| 开发者/管理员 | AdministratorAccess | 开发阶段可使用高权限，提升效率 |
| 生产环境应用 | 自定义策略 | 仅授予必需的 action + resource |
| 自动化服务 | 最小权限集合 | CI/CD、定时任务等仅开放所需接口 |
分层防护策略
安全防护应该在多个层次实施，而非依赖单一机制：
┌─────────────────────────────────────────┐
│ 网关层（网关权限） │ ← 控制"能否访问"
│ • 决定请求能否进入资源层 │
│ • 基于角色/IP/时间等条件控制访问 │
└─────────────────────────────────────────┘
↓ 放行
┌─────────────────────────────────────────┐
│ 资源层（安全规则） │ ← 控制"能做什么"
│ • 数据库安全规则 │
│ • 云存储访问控制 │
│ • 云函数认证配置 │
└─────────────────────────────────────────┘
↓ 通过
┌─────────────────────────────────────────┐
│ 业务层（应用鉴权） │ ← 控制"细粒度权限"
│ • 用户角色校验 │
│ • 数据权限过滤 │
│ • 业务规则限制（额度、风控等） │
└─────────────────────────────────────────┘
策略配置建议
1. 优先使用预设策略
- ✅ 预设策略经过充分测试，更规范、不易出错
- ⚠️ 自定义策略需充分测试后再投入生产使用
2. 使用 deny 做全局兜底
当需要"全局禁止某类危险操作"时，使用 deny 策略（因为 deny 优先级高于 allow）：
{
"effect": "deny",
"action": "functions:*",
"resource": "*"
}
3. 定期审查权限配置
- 定期检查各角色的权限配置是否合理
- 及时回收不再需要的权限
- 关注异常访问日志，调整策略
故障排查路径
遇到权限问题时，按以下顺序排查：
| 现象 | 排查重点 | 处理方向 |
|---|---|---|
| 请求返回 403，资源日志无记录 | 网关策略 | 检查网关权限配置，确认策略是否放行 |
| 请求进入资源，但执行失败 | 资源层安全规则 | 检查数据库安全规则、云存储权限等 |
| 资源层通过，业务逻辑报错 | 业务层鉴权 | 检查应用代码中的权限校验逻辑 |
可以临时将角色策略改为 AdministratorAccess，如果问题消失，说明是网关权限配置问题；如果问题依然存在，则需要检查资源层或业务层。