Skip to main content

概要

Jinba Toolboxは、組織ベースの隔離を中心とした多層的なセキュリティモデルを実装しています。ToolSet、Tool、Version、Run、APIキー、Webhookなど、すべてのリソースは組織に属し、ロールベースアクセス制御(RBAC)、認証済みセッションまたはAPIキー、データベースレベルのテナント隔離によって保護されます。

認証

Jinba Toolboxは、それぞれ異なるアクセスパターン向けに設計された2つの認証方法をサポートしています:

セッションベース(Web)

管理Webコンソールで使用されます。セッションCookieを使用したBetter Authで動作します。
  • Cookieベースのセッション管理
  • ToolSetを管理する人間のユーザー向け
  • 組織リソースへの完全なCRUDアクセス

APIキー(プログラム)

SDK、AIエージェント、外部統合で使用されます。Bearerトークンとして渡します。
  • Authorization: Bearer jtb_xxxxxxxxxxxx
  • 自動化およびプログラムアクセス向け
  • 単一の組織にスコープ

APIキーの管理

APIキーは組織にスコープされ、発行者を追跡します:
主なプロパティ:
  • デフォルトでは有効期限なし — キーは手動で削除するまで有効です。
  • 最終使用日時が各キーに記録されます。
  • 発行者の追跡 — キーを作成したメンバーが記録されます。
  • 監査ログ — キーの作成・削除イベントがログに記録されます。
キーを発行したメンバーが組織を離れても、統合の中断を避けるためキーはアクティブなまま維持されます。管理コンソールには警告が表示され、OwnerまたはAdminがキーを引き継いだり再生成したりできます。

APIキーエンドポイント

ロールベースアクセス制御(RBAC)

ロール階層

Jinba Toolboxは2つのレベルでロールを定義しています:

組織ロール

権限マトリックス

ロールのルール

  • 各組織には正確に1名のOwnerがいます。
  • オーナーシップは別のメンバーに移転できます(元のオーナーはAdminになります)。
  • OwnerとAdminのみが新しいメンバーを招待できます。
  • Memberは自分のAPIキーを管理できますが、他者が作成したキーを参照・削除することはできません。

組織ベースの隔離

Jinba Toolboxのすべてのリソースは組織にスコープされています。隔離は複数のレイヤーで強制されます:

アプリケーションレイヤー

APIサーバーは、リクエストを処理する前に、認証済みユーザーまたはAPIキーが対象の組織に属していることを検証します。これにより、データベースクエリに何らかの設定ミスがあったとしても、アプリケーションレイヤーが不正アクセスをブロックします。

データベースレイヤー(Row Level Security)

PostgreSQL Row Level Security(RLS)は、データベースレベルで追加のテナント隔離レイヤーを提供します:
動作の仕組み:
1

リクエストが到着する

APIサーバーがリクエストを認証し、組織IDを判定します。
2

セッション変数を設定する

クエリを実行する前に、サーバーがPostgreSQLのセッション変数を設定します:
3

RLSが行をフィルタリングする

PostgreSQLが自動的にすべてのクエリ結果をフィルタリングし、現在の組織に属する行のみを返します。
RLSで保護されるテーブル:
  • tool_set
  • tool
  • tool_set_version
  • run
  • apikey
  • webhook
  • audit_log
この多層的なアプローチ(アプリケーション + データベース)により多層防御を実現しています。アプリケーションチェックをバイパスするバグがあったとしても、データベース自体がクロステナントのデータアクセスを防止します。

監査ログ

組織内の重要なアクションは監査ログに記録されます: Toolの実行は、完全な入出力ログとともに runs テーブルで別途追跡されます。

監査ログのデータモデル

監査ログの閲覧

監査ログは、Webコンソールの /org/:orgId/settings/audit-logOwnerおよびAdminロールが閲覧可能です。ログは無期限で保持されます。

Sandboxの隔離

Toolの実行は、隔離されたSandbox環境(E2BまたはDaytona)で行われます。各実行は新規または再開されたSandboxインスタンスで実行され、以下の特性を持ちます:
  • プロセスの隔離 — 各Sandboxは個別のコンテナまたはVMです。
  • ネットワークの隔離 — SandboxはAPIサーバーの内部ネットワークにアクセスできません。
  • 設定可能な環境変数 — シークレットはToolSetごとに注入され、ToolSet間で共有されません。
  • 自動クリーンアップ — 実行完了またはタイムアウト後にSandboxは終了されます。

ベストプラクティス

  • 環境ごとに異なるAPIキーを使用する(本番、ステージング、CI/CD) — キーが漏洩した場合の影響範囲を限定するためです。
  • APIキーの使用状況を監査する — 最終使用日時を定期的に確認し、不要になったキーは削除してください。
  • 最小権限のロールを割り当てる — Toolの作成・編集のみが必要な開発者にはMemberを使用してください。
  • 監査ログを定期的に確認する — 予期しないアクセスパターンを検出するためです。
  • 組織間でAPIキーを共有しない — 各キーは単一の組織にスコープされています。

関連ドキュメント