多租户权限设计——工作空间分离、角色层次结构和 API 密钥范围实用指南

企业中的多租户设计并不是简单的“每个部门分离账户”。 如何隔离数据、如何共享模型、如何继承权限 ——回答这三个问题至关重要。

Dify 将工作区、团队成员和模型提供者设计为不同的管理层。除此之外，企业版还增加了组织管理、SSO联动、审计日志等治理功能。在本文中，我们将从实践层面解释日本公司在内部部署 Dify Enterprise 时使用的权限设计模式。

1. Dify 权限模型概述

1.1 整理基本概念

graph TB
    subgraph "プラットフォームレベル"
        A[System Admin]
        B[Model Providers]
        C[License 管理]
    end
    subgraph "Workspace レベル"
        D[Workspace A<br/>営業部]
        E[Workspace B<br/>カスタマーサポート部]
        F[Workspace C<br/>法務部]
    end
    subgraph "Workspace 内"
        G[Apps]
        H[Knowledge Base]
        I[Tools]
        J[Members & Roles]
    end
    A --> D
    A --> E
    A --> F
    B -.->|共有可能| D
    B -.->|共有可能| E
    B -.->|共有可能| F
    D --> G
    D --> H
    D --> I
    D --> J

1.2 角色层次结构

Dify 具有以下角色层次结构。

1.3 隔离边界

2.租户设计模式

2.1 模式A：强隔离模型（部门完全分离）

graph LR
    subgraph "法務部 Workspace"
        A1[契約書レビューApp]
        A2[法務ナレッジベース]
        A3[専用 Model Provider]
    end
    subgraph "人事部 Workspace"
        B1[採用FAQ App]
        B2[人事ナレッジベース]
        B3[専用 Model Provider]
    end
    A1 -.- A2
    B1 -.- B2

应用场景：法务、人力资源、财务、企业策划等处理高度机密数据的部门。

特点：

• 知识库是完全独立的
• 模型提供商还为每个部门单独设置（单独的 API 密钥并单独管理使用情况）
• 原则上禁止或尽量减少并发会员资格
• 定期审查审核日志

与values.yaml相关的设置：

# Workspace 間のデータ分離は Dify のアプリケーション層で実現
# インフラレベルでは以下を確認
enterprise:
  enabled: true
  # 監査ログの有効化
  auditLog:
    enabled: true
    retention: "365d"

2.2 模式B：共享基础设施+数据分离模型

graph TB
    subgraph "プラットフォーム共有層"
        M[共有 Model Provider<br/>GPT-4o / Claude]
        P[共有プラグイン]
    end
    subgraph "営業部 Workspace"
        C1[商談支援 App]
        C2[営業ナレッジベース]
    end
    subgraph "CS部 Workspace"
        D1[問合せ対応 App]
        D2[CS ナレッジベース]
    end
    M -->|利用| C1
    M -->|利用| D1
    C1 -.- C2
    D1 -.- D2

应用场景：销售、市场、客户支持等部门，共享基础模型效率较高。

特点：

• 模型提供商在平台级别集中管理（成本优化）
• 工作区中独立的知识库和应用程序
• 允许成员属于多个工作区
• 工具（网络搜索、计算器等）共享。

2.3 模式C：跨项目模型

graph TB
    subgraph "DX推進PJ Workspace"
        E1[業務分析 App]
        E2[PJナレッジベース]
    end
    subgraph "営業部 Workspace"
        F1[営業 App]
        F2[営業ナレッジベース]
    end
    U1[ユーザーA<br/>DX推進 + 営業] --> E1
    U1 --> F1
    U2[ユーザーB<br/>DX推進のみ] --> E1

应用场景：有跨部门项目的公司。同一用户属于多个具有不同角色的工作区。

3.权限设计的最佳实践

3.1 最小权限原则

System Admin は最小人数（2-3 名）に限定する
  └── 通常業務では Workspace Admin 以下のロールを使用
      └── アプリ利用のみのユーザーは Member ロールで十分

具体建议：

3.2 模型提供商管理政策

模型提供者设置对于成本控制和安全性都很重要。

推奨アプローチ:
1. System Admin がプラットフォームレベルで利用可能なモデルを設定
2. Workspace ごとに利用可能なモデルを制限（必要に応じて）
3. 各モデルの API キーは Secret Manager で一元管理
4. 月次でモデル利用量をレビュー

模型提供者配置示例（平台级别）：

3.3 知识库访问控制

4. API 密钥范围

4.1 API密钥颁发单位

Dify API 密钥是为每个应用程序颁发的。与外部系统协作时，应遵循以下原则。

1 つの API キー = 1 つのアプリケーション = 1 つのユースケース

反模式：跨多个系统重复使用一个 API 密钥。

4.2 API 密钥管理最佳实践

# 外部システムからの Dify API 呼び出し例
# 各システムごとに個別の API キーを発行する

# CRM システム → 商談要約 App
# API Key: app-xxxx1111 (CRM 専用)

# チャットボット → FAQ 回答 App
# API Key: app-xxxx2222 (チャットボット専用)

# 社内ポータル → ドキュメント検索 App
# API Key: app-xxxx3333 (ポータル専用)

4.3 API密钥生命周期管理

5. 通过 SSO 链接进行身份验证集成

5.1 推荐配置

在企业版中，可以使用 SAML 2.0/OIDC 进行 SSO。

sequenceDiagram
    participant User as ユーザー
    participant Dify as Dify Enterprise
    participant IdP as IdP (Azure AD / Okta)
    
    User->>Dify: ログイン要求
    Dify->>IdP: SAML AuthnRequest
    IdP->>User: 認証画面
    User->>IdP: 認証情報入力
    IdP->>Dify: SAML Response (属性付き)
    Dify->>Dify: Workspace / ロール自動割り当て
    Dify->>User: ダッシュボード表示

5.2 IdP 属性映射

5.3 实施SSO时的注意事项

• 预定义首次登录时自动分配工作区的规则
• 检查 IdP 端的组更改何时反映在 Dify 角色中
• 维护一个本地管理员帐户以应对紧急情况（以防 IdP 失败）
• 对齐 SSO 会话超时和 Dify 会话超时

6. 审计与合规

6.1 应记录在审核日志中的事件

6.2 进行定期审查

月次レビュー:
  - 各 Workspace のメンバー一覧と最終ログイン日を確認
  - 90 日以上ログインのないアカウントを無効化
  - API キーの棚卸し（不要なキーの失効）
  - Model 利用量のコスト確認

四半期レビュー:
  - ロール割り当ての妥当性確認
  - Workspace 構成の見直し
  - 監査ログの異常パターン確認
  - アクセス権限のレビュー（J-SOX 対応）

7. 典型组织结构示例

7.1 中型公司设计示例（500人，5个部门）

系统管理员角色将仅限于信息系统部门的两人，每个工作空间的所有者将是部门经理或人工智能推广负责人。

8. 总结

多租户权限设计的核心是“共享效率”和“数据边界”的平衡。我们将遵循以下五项原则：

1. 工作空间 = 租户边界：为每个部门或项目创建工作空间，隔离知识库和应用程序
2. 模型提供者可以共享：为了提高成本效率，底层模型在平台级别进行管理，并根据需要按工作空间进行限制。
3. 最小权限原则：系统管理员应限制在最少的人数，一般用户应被赋予最少的必要角色。
4. API密钥按用例分配：1 key = 1 app = 1 彻底遵循合作原则
5. 审计和定期审查：启用审计日志记录并每月盘点会员关键成本。

权威设计一旦决定并没有结束；必须有一个持续审查它以响应组织变化的操作流程。