6つのロール、26の権限、部門スコーピング：JieGouのRBACの仕組み

JieGou has evolved.

Since this post was published, JieGou has pivoted from an AI automation platform to an AI-powered operations company delivering managed marketing and operations services. Learn about our managed services →

AI自動化プラットフォームは機密データと重要なworkflowを扱います。顧客レコードがrecipeのステップを流れます。財務レポートが生成され配布されます。社内コミュニケーションが起草され送信されます。アクセス制御モデルは、そのリスクに見合ったものである必要があります。

「管理者かユーザーか」では不十分です。監査ログは読めるが何も実行できないコンプライアンスオフィサーが必要です。自チームの自動化を管理するが他の部門には触れない部門リーダーが必要です。フラットなバイナリトグルではなく、組織図にマッピングされる明確な境界が必要です。

この記事では、JieGouのRBACシステム——6つのロール階層、26の詳細な権限、部門スコープのオーバーライド、そしてすべてのAPI呼び出しで実行される適用メカニズム——について解説します。

6つのロール階層

JieGouのすべてのユーザーにはグローバルロールがあります——アカウント全体でのベースライン権限を決定する単一の数値レベルです。

| ロール | レベル | 目的 | |---|---|---| | Owner | 50 | アカウント作成者。アカウント削除を含む完全なアクセス権。 | | Admin | 40 | 完全な管理：請求、ユーザー、APIキー、部門横断分析。 | | Dept Lead | 30 | 部門リーダー。所属部門のコンテンツを編集・削除。パックのインストール。workflowの昇格。 | | Member | 20 | 標準ユーザー。コンテンツ作成、自分のコンテンツ編集、recipe/workflow実行、スケジュール管理。 | | Auditor | 15 | 監査ログ、分析、ガバナンスへの読み取り専用アクセス。作成や実行は不可。 | | Viewer | 10 | コンテンツへの読み取り専用アクセス。何も実行不可。 |

数値レベルは任意ではありません。O(1)の権限チェックを可能にします——ロールリストを反復する代わりに、システムは2つの整数を比較します。権限には最小レベルが必要で、ユーザーがそれを満たすか満たさないかです。

Auditorロール

Auditorは最も新しく追加されたロールで、コンプライアンス向けに特別に設計されています。Viewer（10）とMember（20）の間のレベル15に位置します。

Viewerとの主な違い：AuditorはAuditorはaudit:read権限を持ちます。監査ログ、分析ダッシュボード、ガバナンスレポートにアクセスできます。Viewerはできません。

Memberとの主な違い：Auditorはコンテンツの作成、recipeの実行、workflowの実行、スケジュールの管理ができません。観察と報告のみです。それ以上のことはできません。

これは規制産業にとって重要です。コンプライアンスオフィサーは、workflowがポリシーに従っているか、データ処理が要件を満たしているか、ユーザー活動がガバナンスフレームワークに沿っているかを検証する必要があります。何かを変更したり実行したりする能力は必要ではなく、持つべきでもありません。

AuditorはSSOグループ対ロールマッピングで利用可能なため、IdPからコンプライアンスオフィサーを自動プロビジョニングできます。compliance-teamやinternal-auditグループをAuditorロールにマッピングすれば、それらのグループの新入社員は初回ログイン時に適切なアクセス権を取得します。手動のロール割り当ては不要です。

8カテゴリにわたる26の権限

ロールは略記です。実際にチェックされるのは権限です。JieGouは8カテゴリに整理された26の詳細な権限を定義しています：

アカウント（4権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | account:delete | Owner | アカウント全体の削除 | | account:admin | Admin | 管理アクション（SSO設定、アカウント設定） | | account:settings | Admin | アカウントレベルの設定管理 | | account:billing | Admin | 請求とサブスクリプションの管理 |

ユーザー（2権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | users:manage | Admin | アカウント全体のすべてのユーザーを管理 | | users:manage-department | Dept Lead | 所属部門内のユーザーを管理 |

コンテンツ（6権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | content:create | Member | 新しいrecipe、workflow、ドキュメントの作成 | | content:edit-own | Member | 自分が作成したコンテンツの編集 | | content:edit | Dept Lead | 所属部門のコンテンツの編集 | | content:edit-any | Admin | すべての部門のコンテンツの編集 | | content:delete-any | Admin | すべての部門のコンテンツの削除 | | content:read | Viewer | コンテンツ（recipe、workflow、ドキュメント）の閲覧 |

実行（3権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | execution:run | Member | recipeとworkflowの実行 | | execution:schedules | Member | スケジュール実行の作成と管理 | | execution:triggers | Member | イベント駆動トリガーの設定 |

分析（2権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | analytics:read-department | Auditor | 所属部門の分析の閲覧 | | analytics:read-all | Admin | すべての部門の分析の閲覧 |

機能（4権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | features:chat | Member | AIチャットインターフェースの使用 | | features:documents | Member | ナレッジベースドキュメントの管理 | | features:packs | Dept Lead | 部門パックのインストールと管理 | | features:connectors | Admin | MCPコネクタとインテグレーションの設定 |

ガバナンス（3権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | governance:audit | Auditor | 監査ログとガバナンスレポートの閲覧 | | governance:environments | Dept Lead | デプロイ環境の管理 | | governance:promote | Dept Lead | 環境間のworkflowの昇格 |

セキュリティ（2権限）

| 権限 | 最小ロール | 説明 | |---|---|---| | security:byok | Admin | Bring Your Own Key APIキーの管理 | | security:embedded-api | Admin | 組み込みAPIの設定 |

ロールから権限へのマッピングは静的です。Dept Lead（レベル30）は、最小ロールが30以下のすべての権限を自動的に持ちます。ユーザーごとの権限オーバーライドやカスタムロール定義はありません。これによりモデルは監査可能になります——ユーザーのロールを見るだけで、何ができて何ができないかが正確に分かります。

部門スコープのロールオーバーライド

グローバルロールはどこにでも適用されます。しかし、組織はフラットではありません。プロダクトマネージャーはグローバルにはMemberアクセスが必要ですが、Product部門ではチームの自動化を管理するためにDept Leadアクセスが必要かもしれません。

部門スコープのオーバーライドがこれを解決します。ユーザーは1つのグローバルロールに加えて、0個以上の部門固有のロールオーバーライドを持ちます。

例：SarahはグローバルではMemberです。Sales部門ではDept Leadのオーバーライドを持っています。Salesでは、あらゆるコンテンツの編集、パックのインストール、workflowの昇格が可能です。Engineeringでは、標準的なMember——自分のコンテンツのみ編集できます。

重要な設計原則：オーバーライドは昇格のみ可能で、降格はできません。グローバルAdminがEngineering部門でViewerオーバーライドを持っている場合、Engineeringでの実効ロールは依然としてAdminです。オーバーライドはアクセスを低下させるため無視されます。これにより、誤って設定されたオーバーライドが、アクセスすべき部門からユーザーをロックアウトすることを防ぎます。

実効ロールの解決

システムが特定の部門でユーザーが何をできるかを判断する必要がある場合、以下の解決プロセスを実行します：

この部門でこのユーザーの部門オーバーライドが存在するか確認
オーバーライドが存在する場合、グローバルロールとオーバーライドの高い方を返す
オーバーライドが存在しない場合、グローバルロールを返す

疑似コード：

effectiveRole(user, department):
  override = getDepartmentOverride(user, department)
  if override exists:
    return max(user.globalRole, override.role)
  return user.globalRole

部門スコープの権限チェックではこの実効ロールを使用します。SarahがSalesでパックをインストールしようとすると、システムはSalesでの実効ロール（Dept Lead、レベル30）を解決し、features:packsの最小レベル（30）を確認し、アクセスを許可します。Engineeringで同じことを試みると、実効ロールはMember（20）であり、必要なレベルを下回ります。

エスカレーション防止ルール

ロール変更はシステムで最もセキュリティ上重要な操作です。4つのルールが権限エスカレーションを防止します：

**自分のロールは変更できません。**自己昇格は不可能です。Ownerになりたい管理者は、別のOwnerに変更してもらう必要があります。
**Ownerロールは割り当てできません。**Ownerの移転は、独自のセーフガードを持つ別の慎重な操作です。標準のロール変更APIでは実行されません。
自分と同等以上のロールは割り当てできません（Ownerを除く）。Admin（40）はDept Lead（30）、Member（20）、Auditor（15）、Viewer（10）を割り当てられます。Admin（40）やOwner（50）は割り当てられません。他のAdminを作成できるのはOwnerだけです。
自分と同等以上のロールを持つ人のロールは変更できません（Ownerを除く）。Adminは別のAdminのロールを変更できません。Dept LeadはAdminのロールを変更できません。階層は上方向に厳格に適用されます。

これらのルールはきれいに組み合わさります。組み合わせることで、どのユーザーも自分の権限や同僚の権限をエスカレートできないことが保証されます——Ownerだけがこの制約の外にいます。

権限の適用方法

JieGouのすべてのAPIルートは、ビジネスロジックを実行する前に3ステップの認証ガードを通過します：

**ステップ1：セッションCookieの検証。**HTTPCookieのセッショントークンがFirebase Authに対して検証されます。結果は5分のTTLでRedisにキャッシュされるため、同じセッションからの繰り返しリクエストは毎回Firebase Authにアクセスする必要がありません。

**ステップ2：AccountUserレコードの検索。**ユーザーのアカウントメンバーシップ——グローバルロールと部門オーバーライドを含む——がFirestoreから取得されます。これも5分のTTLでRedisにキャッシュされます。

**ステップ3：ロール階層に対する権限チェック。必要な権限がその最小ロールレベルにマッピングされます。ユーザーの実効ロール（チェックが部門スコープの場合は部門オーバーライドを考慮）がそれと比較されます。これはO(1)**です——最小レベルを見つけるための単一のハッシュ検索と、数値比較です。

権限チェック時のデータベースクエリはありません。権限リストの反復もありません。2つのキャッシュされた検索と1つの整数比較です。

リソースレベルのチェック

ロールベースの権限に加えて、個々のリソース（recipe、workflow、ドキュメント）には所有権ベースのアクセスルールがあります：

Owner、Admin、Dept Lead — スコープ内のあらゆるリソースを変更可能
Member — 自分が作成したリソースのみ変更可能
Auditor、Viewer — リソースの変更不可

これはロールレベルの権限と組み合わされます。content:edit-ownを持つMemberは、resource.createdBy === user.idのリソースのみ編集できます。content:editを持つDept Leadは、誰が作成したかに関係なく、所属部門のあらゆるリソースを編集できます。

プラットフォーム機能との統合

RBACは独立しているわけではなく、すべての主要なプラットフォームサブシステムに接続されています：

**承認ゲート。**承認の適格性はロール階層を尊重します。承認ステップに最小ロールを要求するよう設定できます——例えば、Dept Lead以上のみがworkflowの出力を本番環境に移行する前に承認できるようにすることができます。

**実行の可視性。**workflowの実行には4つの可視性スコープがあります：private（実行者のみ）、department（同じ部門の誰でも）、group（指定されたグループ）、account（全員）。RBACが実行結果を誰が見られて誰が見られないかを決定します。

**環境の昇格。**異なる環境（開発、ステージング、本番）は異なる最小ロールを要求できます。開発はMemberレベルの昇格を許可するかもしれません。本番はAdminを要求するかもしれません。RBACが各遷移をゲートします。

**ガバナンスレポート。**ガバナンスダッシュボードはアカウント全体のロール分布、ユーザーごとのアクセス可能なリソース数、権限の利用状況を表示します。Auditorはこのデータをレビューして、アクセスパターンがポリシーに一致しているかを確認できます。

提供状況

RBACはすべてのプランでご利用いただけます。すべてのJieGouアカウントで完全な6つのロール階層と26の権限が利用可能です。部門スコープのオーバーライドとAuditorロールはTeamおよびEnterpriseプランでご利用いただけます。すべての機能を見るか、無料トライアルを開始することができます。