7.2 权限、安全与环境隔离

7.2 权限、安全与环境隔离

安全三问：谁能用这个应用（应用访问权限三档）？谁能改这个应用（团队成员四种角色）？钥匙和变更怎么管（密钥轮换与双工作区）？三个问题答清楚，加上平台自带的沙箱隔离、出网控制与备份基线，自部署 Dify 的安全评审就有得写。

交付三动作的第二个：筑墙。7.1 把线接通了，本节保证这条线只放该进来的东西。IT 部门的安全评审清单，恰好就是本节的目录。

第一问：谁能用——应用访问权限三档

每个应用（含其 WebApp 与 API）有三档访问控制：公开（任何拿到链接或密钥的人可用）、指定成员（仅工作区内指定的人）、私密（仅创建者）。配置在应用设置的访问区域。小艺的发布策略分了阶段：内测期"指定成员"（拉客服组进来用），公测期转"公开"但 WebApp 挂私密码，正式上线才全公开。API 侧的对应物是密钥：密钥即权限，删掉密钥等于踢掉一个集成方——7.1 说的轮换处置就是在这里操作。

一个容易忽略的细节：访问权限管的是"用"，不管"看配置"。谁能改配置、谁能看提示词与知识库，是下一问的事。

第二问：谁能改——成员角色矩阵

工作区成员分四种角色，权限递增：普通成员（用应用、看日志）、编辑（改应用与知识库）、管理员（加成员、管全部应用）、所有者（工作区主权，转让需谨慎）。小艺团队的实际分工：

这张矩阵过了两道关：最小权限（运营只需要看，就不给改）与改动出口唯一（提示词与参数只有管理员和客服主管能碰——回想 3.2 与 3.3 的调优成果，如果任何人随手改温度，两周的调优记录就作废了）。把角色矩阵写进交接文档，人员变动时按表调整。

第三问：钥匙与变更怎么管

密钥管理三条纪律：密钥只存两处——平台密钥页（真身）与你的密钥管理系统（备份，含负责人与用途标注）；每把密钥有唯一负责人与用途（帮助中心一把、小程序一把、定时任务一把，绝不混用——出问题时按钥匙定位影响面）；轮换演练至少做一次（新建、替换、观察、删除四步，全程十分钟，7.1 已给流程）。

双工作区隔离是变更管理的核心手段。利用 1.3 提过的工作区机制，建两个工作区："试验田"与"正式"。试验田放开发中的副本（复制应用而来），接低限额的模型密钥，随便折腾；正式工作区只放稳定版，接正式密钥。发布流程随之固化：

变更发布流程 v1
1. 复制正式应用到试验田（或用 DSL 导入）
2. 试验田里改：提示词、参数、知识库、流程
3. 过回归：4.3 的召回测试集 + 3.3 的探针 + 5.3 的五十条例题
4. 通过后把改动落回正式应用（小改直接改，大改用 DSL 导入重建）
5. 正式区点更新发布，观察当日指标（7.3 的四指标）
6. 异常回滚：DSL 版本库取上一版导入，全程十分钟内
​

第 6 步是这套流程的价值所在：能回滚的变更才敢做。3.1 节养成的"DSL 导出入库"习惯，在这里兑现成回滚能力。

平台级安全基线

应用与团队之外，自部署平台本身有几道基线要过：沙箱隔离——代码节点的执行环境是独立容器（5.2 已遇），无网络、有超时，天然限制了恶意代码的破坏半径，评审时说明这一点能省很多解释；出网控制——模型流量走你配的供应商地址，内网闭环方案（Ollama 路线）下可做到完全不出网；数据备份——数据库与向量库的卷定期备份（2.1 埋的线，7.3 给节奏）；平台访问本身——控制台要有强密码与（如启用）双因子，管理员账号不共用。

安全评审自查单（对应 IT 的常见问题）
[ ] 应用访问权限按阶段设置，公测有私密码
[ ] 成员角色矩阵最小权限，改动出口唯一
[ ] 密钥有台账：负责人、用途、轮换记录
[ ] 双工作区隔离，变更走流程，可十分钟回滚
[ ] 模型密钥有消费上限（2.2 的闸门仍在）
[ ] 数据卷有备份且演练过恢复
[ ] 控制台强密码，沙箱与出网策略已说明
​

这张单子打印出来过了就是评审材料——它不深奥，贵在每条都真的做过。

问题：一人团队也要这么重的过程吗？

按规模裁剪，别按模板照抄。一个人的团队：双工作区可以退化成"一个工作区 + 复制应用当沙盒"，成员矩阵简化成"我一个人 + DSL 版本库"，但三件事不建议省——密钥台账（哪怕只有三行，泄露时你会感谢它）、DSL 版本库（回滚能力的最低配置）、备份演练（数据没了没有第二个人帮你回忆）。过程的价值不在于文档厚度，而在于出事那天你手里有什么。反过来，五人以上团队就别再靠"人肉记"了：角色矩阵、变更流程、周巡检从第一天制度化，成本远低于事后补救。

问题：把 Dify 暴露到公网，除了强密码还要什么？

自部署环境对公网开放前，至少补三道：网关层加 HTTPS（证书由你的反向代理或平台网关配置），没有加密的密钥传输等于明文递钥匙；控制台路径加访问控制或 IP 白名单——终端用户只需要 WebApp 与 API，控制台没必要对全网开放；模型供应商密钥设消费上限（2.2 的闸门）防止被刷。第四道是加分项：平台侧启用访问频控，配合你后端的按用户限流形成双层防线。这四道做完，常见攻击面就覆盖了七八成，剩下的交给日志巡检兜底。

⚠️ 常见坑一：所有人都是管理员。团队小时无所谓，人员一流动，"谁能改"就成了悬案——角色矩阵要趁小建。坑二：只有一套环境，改提示词直接在正式应用上试，改坏即事故。试验田不是多余，是变更纪律的物理载体。坑三：密钥一把用到天荒地老，且平台密钥页里躺着五个没人认领的"test"密钥——台账制度就是防这个的。

本节要点回顾

• 三档访问：公开、指定成员、私密，按发布阶段推进，密钥即 API 侧的权限；
• 四种角色：权限递增，最小授权加改动出口唯一，矩阵写进交接文档；
• 密钥三纪律：两处存放、一钥一责、定期轮换演练；
• 双工作区：试验田与正式分家，变更六步流程，十分钟可回滚；
• 平台基线：沙箱限破坏、出网可控、备份要演练、控制台要强密码；
• 自查单文化：安全评审答的是"做过什么"，不是"知道什么"。

墙筑好了。最后一节进入运营态：看什么指标、怎么从日志里挖改进、升级备份什么节奏——让小艺在数据喂养下越跑越好。