Dify 企业权限管理应该怎么配置？

Dify 的团队协作和权限管理，核心是用工作空间隔离资源，用角色控制操作范围，再用 API Key、日志和审计手段约束生产访问。回答这类问题时，不能只列 Owner、Admin、Editor、Viewer，还要说明企业里怎么分组、怎么管知识库、怎么防止误改生产应用。比较稳的配置思路是：按业务或环境划分工作空间，按职责分配最小权限，生产应用限制编辑入口，外部系统统一使用专用 API Key，不用个人账号长期集成。

追问

Dify 常见角色应该怎么分配？

Owner 通常只给平台负责人或少数管理员，负责工作空间生命周期、关键配置和最终兜底。Admin 可以管理成员、模型、应用和资源，但不建议给太多人，否则权限边界会失控。Editor 适合应用构建者、提示词工程师和知识库维护人员，Viewer 适合业务评审、测试和只需要查看效果的人。取舍是协作效率和安全之间的平衡：权限给少了会拖慢迭代，给多了容易误删应用、泄露日志或改坏生产配置。

企业里应该按团队还是按环境划分工作空间？

如果公司业务线很多，优先按业务线或部门划分工作空间，能让知识库、应用和成员关系更清楚。如果生产安全要求高，可以再把测试和生产拆开，至少保证生产应用只有少数人能编辑。边界是工作空间拆得太细会带来重复配置，比如模型供应商、通用知识库和成员管理都要维护多份。比较实用的做法是核心生产应用单独隔离，普通实验应用放在团队空间里，并用命名规范标明 dev、test、prod。

API Key 权限管理有哪些坑？

最大的坑是用个人账号生成的 Key 接入生产系统，员工离职、换岗或误删时会影响线上服务。更好的方式是为应用或系统单独创建集成用 Key，记录用途、负责人、创建时间和轮换周期。还要避免把 Key 写死在前端、文档截图或日志里，必要时通过环境变量、密钥管理服务或 CI/CD Secret 注入。取舍在于轮换越频繁越安全，但也会增加运维成本，所以至少要对生产 Key 建立定期检查和泄露应急流程。

知识库和应用权限应该怎么管？

知识库通常比应用更敏感，因为里面可能有合同、客户资料、内部制度或产品路线图。配置时要明确谁能上传、删除、重新索引和绑定知识库，避免普通编辑者把测试资料接到生产应用。应用权限则要区分查看、调试、编辑、发布和调用，尤其是带外部工具的工作流，错误配置可能触发真实业务操作。踩坑是只管页面编辑权限，不管知识库数据来源和工具调用权限，结果模型回答泄露了不该看的内容。

如何做审计和日常权限复查？

企业级配置不能只在上线当天做一次，至少要按月或按季度复查成员、角色、API Key 和应用访问日志。操作上可以导出成员清单，与组织架构或 IAM 系统比对，清理离职、转岗和临时项目成员。对高风险应用，要关注谁修改了提示词、知识库、模型参数和工具配置，并保留变更记录。Dify 自带能力能覆盖一部分协作和日志需求，但如果要满足合规审计，最好接入公司统一身份认证、网关日志和集中审计平台。