第 6 篇：访问控制与零信任策略

第 6 篇：访问控制与零信任策略

• • [1. 你的系统里，哪些入口最该先加 Zero Trust](#1. 你的系统里，哪些入口最该先加 Zero Trust)
  • [2. Cloudflare Access：把"认证 + 授权"前置到边缘](#2. Cloudflare Access：把“认证 + 授权”前置到边缘)
  • [3. 策略分层：人类入口 vs 机器入口](#3. 策略分层：人类入口 vs 机器入口)
  • • [3.1 人类入口（管理面板/控制台）：强认证 + 强条件](#3.1 人类入口（管理面板/控制台）：强认证 + 强条件)
    • [3.2 机器入口（Webhook/Worker Callback）：白名单 + Service Token](#3.2 机器入口（Webhook/Worker Callback）：白名单 + Service Token)
  • [4. dev / stage / prod：按环境切断风险半径](#4. dev / stage / prod：按环境切断风险半径)
  • [5. Policy 设计范式：允许谁访问、什么条件访问、如何按路径细分](#5. Policy 设计范式：允许谁访问、什么条件访问、如何按路径细分)
  • • [5.1 "允许谁访问"（Include）](#5.1 “允许谁访问”（Include）)
    • [5.2 "什么条件访问"（Require）](#5.2 “什么条件访问”（Require）)
    • [5.3 "如何按路径细分"（App Paths / Policy inheritance）](#5.3 “如何按路径细分”（App Paths / Policy inheritance）)
  • [6. 一张"可复制"的策略蓝图（建议你直接照抄落地）](#6. 一张“可复制”的策略蓝图（建议你直接照抄落地）)
  • • [6.1 资源分组](#6.1 资源分组)
    • [6.2 规则组（Rule Groups）](#6.2 规则组（Rule Groups）)
    • [6.3 环境矩阵](#6.3 环境矩阵)
  • [7. 你的"内容工厂"入口拓扑（建议作为文档开头的架构图）](#7. 你的“内容工厂”入口拓扑（建议作为文档开头的架构图）)
  • [8. 落地检查清单（上线前必须全部打勾）](#8. 落地检查清单（上线前必须全部打勾）)
  • • 管理面板永不裸奔
    • [Webhook 单独白名单](#Webhook 单独白名单)
    • 环境隔离
  • [9. 常见坑（你现在规避，后面少掉一半返工）](#9. 常见坑（你现在规避，后面少掉一半返工）)
  • 下一章

你的"商品视频工厂"一旦跑起来，最危险的不是模型效果，而是管理面板、内部 API、回调入口 暴露在公网后被撞库、被扫端口、被打穿。V1 阶段最正确的安全投资，就是把"谁能访问、在什么条件下访问、访问到什么路径"这三件事做成强约束，并且把 dev/stage/prod 的风险半径彻底隔离。

本篇给出一套可直接落地的 Cloudflare Zero Trust / Access 方案：管理面板永不裸奔；Webhook 单独白名单；策略按环境分层。

---

1. 你的系统里，哪些入口最该先加 Zero Trust

以"Mac 控制面 + RunPod 产能面"的架构为例，公网入口通常至少有四类：

1. 管理面板：Dify、Orchestrator Console、Grafana/Prometheus、MinIO Console
2. 内部 API ：/v1/video-factory/、/v1/kb/、/admin/*
3. Worker 回调入口：/callbacks/runpod、/callbacks/comfyui、/callbacks/webhook
4. Webhook（第三方/平台回调）：电商平台回调、小红书数据回流、支付/通知回调等

零信任的第一原则：管理面板永不对公网裸露 ；第二原则：Webhook 不走"人类登录"，走"机器信任（allowlist + token）"。

---

2. Cloudflare Access：把"认证 + 授权"前置到边缘

Cloudflare Access 的策略模型很适合做"精细化权限管理"，核心在 Include / Exclude / Require 三类规则：

• 所有 Access policy 必须包含 Include，定义初始可访问人群；
• Exclude 用于排除；
• Require 作为强制条件叠加（AND 逻辑），例如必须满足特定 MFA、设备姿态等。 (Cloudflare Docs)

你可以把它理解成一个可组合的逻辑表达式：

---

3. 策略分层：人类入口 vs 机器入口

3.1 人类入口（管理面板/控制台）：强认证 + 强条件

典型对象：

• console.xxx.com（工作室运营控制台）
• dify.xxx.com（Dify 编排）
• minio.xxx.com（对象存储管理）
• grafana.xxx.com（监控）

建议策略：

• Include：仅允许公司/团队 IdP 的特定组（Ops/Dev/Owner）
• Require：强制 MFA +（可选）设备姿态/证书/特定网络入口
• Exclude：排除个人邮箱域或临时账号

如果你尚未接入 IdP，Cloudflare 也支持用邮箱 One-time PIN (OTP) 的方式给外部协作方临时访问（注意：OTP 与 IdP 组评估的行为差异要明确管理）。 (Cloudflare Docs)

3.2 机器入口（Webhook/Worker Callback）：白名单 + Service Token

典型对象：

• api.xxx.com/callbacks/runpod（RunPod worker 回调）
• api.xxx.com/webhooks/platform/*（平台回调）

机器入口不要走"交互式登录"，而应采用：

• IP allowlist（仅允许来源 IP 段）
• Service Token / HMAC 签名（请求必须带可验证的凭证）
• 单独应用与单独策略（避免和人类入口混在一套 policy 里）

Cloudflare 文档明确：如果你的 webhook endpoint 有防火墙保护，需要 allowlist Cloudflare 的 IP ranges 才能接收通知类 webhook；同时也提供通过 API 获取 Cloudflare IP 列表的方式。 (Cloudflare Docs)

关键点：Webhook 的入口策略要"极窄"，宁可先拒绝再补白名单，也不要先放开再补安全。

---

4. dev / stage / prod：按环境切断风险半径

最推荐的做法不是在一套应用里"写很多 if"，而是按环境拆成不同的 Access Application，再复用 rule group 组合策略。

你可以这样规划域名与应用：

• dev-console.xxx.com / stage-console.xxx.com / console.xxx.com
• dev-api.xxx.com / stage-api.xxx.com / api.xxx.com
• dev-webhooks.xxx.com / stage-webhooks.xxx.com / webhooks.xxx.com

并把策略做到环境级差异化：

• dev：允许开发组访问，但仍要求基本 MFA；可放宽设备条件
• stage：接近 prod，要求更严格（例如必须公司设备或固定出口）
• prod：只允许最小必要人员（Owner/Ops），并要求最强条件

Cloudflare 支持把规则抽成 Rule groups ，一次配置，多处复用（可混合用户/IdP 组/服务令牌等）。 (Cloudflare Docs)

---

5. Policy 设计范式：允许谁访问、什么条件访问、如何按路径细分

5.1 "允许谁访问"（Include）

• Owners：全量访问（但仍需 Require）
• Ops：prod 管理入口 + 生产告警/监控
• Dev：dev/stage 管理入口 + stage API 调试
• Contractor：仅 dev，且有时间窗口（建议通过 OTP 或单独 IdP 组）

经验：让"人群"尽量稳定，别把条件写在 Include 里，把条件写在 Require 里。

5.2 "什么条件访问"（Require）

常用 Require 条件（按重要性排序）：

1. 强 MFA
2. 设备姿态（公司设备/合规状态）
3. 网络条件（必须走 WARP 或固定出口 IP）
4. 地理/时间窗口（必要时）

Require 是 AND 逻辑叠加，非常适合"在不改变人群的前提下加固"。 (Cloudflare Docs)

5.3 "如何按路径细分"（App Paths / Policy inheritance）

在同一域名下，你通常需要把 /admin、/internal、/debug 这些高危路径再加一道门。Cloudflare Zero Trust 支持基于 Application paths 做同根域下不同路径的独立规则，并具备 policy inheritance 的思路。 (Cloudflare Docs)

典型例子：

• api.xxx.com/：允许服务间调用（service token）
• api.xxx.com/admin：只允许 Ops/Owner（强 Require）
• api.xxx.com/webhooks/*：只允许 allowlist + token（不允许人类登录）

---

6. 一张"可复制"的策略蓝图（建议你直接照抄落地）

6.1 资源分组

• App-Console：所有管理 UI（Dify/Console/MinIO/Grafana）
• App-API：内部业务 API（/v1/*）
• App-Webhook ：回调入口（/webhooks/、/callbacks/）

6.2 规则组（Rule Groups）

• RG_OWNER：Owner 账号/组
• RG_OPS：Ops 账号/组
• RG_DEV：Dev 账号/组
• RG_M2M_TOKEN：Service Token（机器调用） (Cloudflare Docs)

6.3 环境矩阵

• dev：Console(DEV) = RG_DEV ∪ RG_OPS ∪ RG_OWNER，Require=MFA
• stage：Console(STAGE) = RG_OPS ∪ RG_OWNER，Require=MFA + 设备条件
• prod：Console(PROD) = RG_OPS ∪ RG_OWNER，Require=MFA + 设备条件 + 网络条件
• webhook：只允许 IP allowlist + Service Token（或 HMAC），拒绝交互登录

---

7. 你的"内容工厂"入口拓扑（建议作为文档开头的架构图）

Browser
Authenticated + Policy
Authenticated + Policy
Callback: allowlist + token
Webhook: allowlist + HMAC
Operator / Dev / Ops
Cloudflare Access
Console / Dify / Grafana
Orchestrator API
RunPod Workers
Platforms Webhook
Webhook Gateway
MinIO / S3 Artifacts
(Postgres)
(Redis Queue)

---

8. 落地检查清单（上线前必须全部打勾）

管理面板永不裸奔

• 所有管理域名都在 Cloudflare Access 后面
• 任何 /admin 路径都比普通路径更严格（路径级策略） (Cloudflare Docs)
• prod 管理入口只给最小必要人员（Owner/Ops）

Webhook 单独白名单

• webhook 独立子域/独立应用/独立策略
• 入站按 IP allowlist（必要时按 Cloudflare IP ranges 更新） (Cloudflare Docs)
• 请求必须带 HMAC 或 service token（无 token 一律 401）
• webhook 不复用管理入口的 session/登录逻辑

环境隔离

• dev/stage/prod 拆分为不同 Access Application 与策略
• rule groups 复用，环境差异通过 Require 强度体现 (Cloudflare Docs)
• stage 必须能"接近 prod"验证策略，不允许直接在 prod 试错

---

9. 常见坑（你现在规避，后面少掉一半返工）

1. 把 webhook 和管理入口放同一域名同一策略：后期很难收紧，且审计困难。
2. 只做登录，不做 Require ：Include 只是"谁可能访问"，真正的零信任在 Require 叠加条件。 (Cloudflare Docs)
3. 没有路径级策略 ：结果是 /admin 与普通 API 同等暴露，风险极高。 (Cloudflare Docs)
4. 没有 rule groups ：每个应用手工维护一套规则，半年后一定失控。 (Cloudflare Docs)
5. Webhook 不做 allowlist：被扫描到就会被打，且你很难靠"只验证 token"扛住垃圾流量。

下一章

《第 7 篇：ComfyUI 电商工作流骨架》