> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jinba.io/llms.txt
> Use this file to discover all available pages before exploring further.

# セキュリティとアクセス制御

> Jinba ToolboxにおけるRBAC、認証方法、組織ベースの隔離を理解する

## 概要

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

## 認証

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

<CardGroup cols={2}>
  <Card title="セッションベース（Web）" icon="browser">
    管理Webコンソールで使用されます。セッションCookieを使用した**Better Auth**で動作します。

    * Cookieベースのセッション管理
    * ToolSetを管理する人間のユーザー向け
    * 組織リソースへの完全なCRUDアクセス
  </Card>

  <Card title="APIキー（プログラム）" icon="key">
    SDK、AIエージェント、外部統合で使用されます。Bearerトークンとして渡します。

    * `Authorization: Bearer jtb_xxxxxxxxxxxx`
    * 自動化およびプログラムアクセス向け
    * 単一の組織にスコープ
  </Card>
</CardGroup>

### APIキーの管理

APIキーは組織にスコープされ、発行者を追跡します：

```
Organization
└── API Keys
    ├── production   (issued by: alice)   Last used: 2 hours ago
    ├── development  (issued by: bob)     Last used: 30 days ago
    └── ci-cd        (issued by: alice)   Last used: never
```

主なプロパティ：

* **デフォルトでは有効期限なし** -- キーは手動で削除するまで有効です。
* **最終使用日時**が各キーに記録されます。
* **発行者の追跡** -- キーを作成したメンバーが記録されます。
* **監査ログ** -- キーの作成・削除イベントがログに記録されます。

キーを発行したメンバーが組織を離れても、統合の中断を避けるためキーはアクティブなまま維持されます。管理コンソールには警告が表示され、OwnerまたはAdminがキーを引き継いだり再生成したりできます。

### APIキーエンドポイント

| メソッド   | エンドポイント                           | 説明         |
| ------ | --------------------------------- | ---------- |
| GET    | `/v1/orgs/:orgId/api-keys`        | APIキー一覧の取得 |
| POST   | `/v1/orgs/:orgId/api-keys`        | APIキーの作成   |
| DELETE | `/v1/orgs/:orgId/api-keys/:keyId` | APIキーの削除   |

## ロールベースアクセス制御（RBAC）

### ロール階層

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

```
Platform Level
└── super_admin          # サービス全体の管理

Organization Level
├── Owner                # 組織のオーナー（組織ごとに1名）
├── Admin                # 組織の管理者
└── Member               # 一般メンバー
```

### 組織ロール

| ロール        | 説明                                       |
| ---------- | ---------------------------------------- |
| **Owner**  | 移転や削除を含む組織の完全な制御権を持つ。組織ごとに1名のOwner。      |
| **Admin**  | メンバー、課金、すべての組織リソースを管理可能。組織の削除はできない。      |
| **Member** | ToolSetとToolの作成・管理が可能。他のメンバーや課金の管理はできない。 |

### 権限マトリックス

| リソース           | Owner | Admin     | Member |
| -------------- | ----- | --------- | ------ |
| 組織設定           | CRUD  | 読み取り / 更新 | 読み取り   |
| 組織の削除          | 可     | 不可        | 不可     |
| メンバー管理         | CRUD  | CRUD      | 読み取り   |
| メンバーの招待        | 可     | 可         | 不可     |
| ToolSet / Tool | CRUD  | CRUD      | CRUD   |
| APIキー（自分の）     | CRUD  | CRUD      | CRUD   |
| APIキー（他者の）     | CRUD  | CRUD      | 不可     |
| クレジット購入        | 可     | 可         | 不可     |
| クレジット残高の確認     | 可     | 可         | 読み取り   |
| 監査ログ           | 読み取り  | 読み取り      | 不可     |

### ロールのルール

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

## 組織ベースの隔離

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

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

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

### データベースレイヤー（Row Level Security）

PostgreSQL Row Level Security（RLS）は、データベースレベルで追加のテナント隔離レイヤーを提供します：

```sql theme={null}
ALTER TABLE tool_set ENABLE ROW LEVEL SECURITY;

CREATE POLICY tool_set_tenant_isolation ON tool_set
  USING (organization_id = current_setting('app.current_org_id'));
```

**動作の仕組み：**

<Steps>
  <Step title="リクエストが到着する">
    APIサーバーがリクエストを認証し、組織IDを判定します。
  </Step>

  <Step title="セッション変数を設定する">
    クエリを実行する前に、サーバーがPostgreSQLのセッション変数を設定します：

    ```sql theme={null}
    SET app.current_org_id = :orgId
    ```
  </Step>

  <Step title="RLSが行をフィルタリングする">
    PostgreSQLが自動的にすべてのクエリ結果をフィルタリングし、現在の組織に属する行のみを返します。
  </Step>
</Steps>

**RLSで保護されるテーブル：**

* `tool_set`
* `tool`
* `tool_set_version`
* `run`
* `apikey`
* `webhook`
* `audit_log`

この多層的なアプローチ（アプリケーション + データベース）により**多層防御**を実現しています。アプリケーションチェックをバイパスするバグがあったとしても、データベース自体がクロステナントのデータアクセスを防止します。

## 監査ログ

組織内の重要なアクションは監査ログに記録されます：

| カテゴリ    | イベント                 |
| ------- | -------------------- |
| APIキー   | 作成、削除                |
| メンバー    | 追加、削除、ロール変更          |
| ToolSet | 公開、公開Versionの変更      |
| 設定      | 組織設定の変更、Webhook設定の変更 |

Toolの実行は、完全な入出力ログとともに `runs` テーブルで別途追跡されます。

### 監査ログのデータモデル

```typescript theme={null}
interface AuditLog {
  id: string;
  orgId: string;
  userId: string;         // アクションを実行したユーザー
  action: string;         // 例: "member.added"
  targetType: string;     // 例: "member"
  targetId: string;       // 影響を受けたリソースのID
  details: object;        // 変更の詳細
  ipAddress: string;
  createdAt: Date;
}
```

### 監査ログの閲覧

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

## Sandboxの隔離

Toolの実行は、隔離されたSandbox環境（E2BまたはDaytona）で行われます。各実行は新規または再開されたSandboxインスタンスで実行され、以下の特性を持ちます：

* **プロセスの隔離** -- 各Sandboxは個別のコンテナまたはVMです。
* **ネットワークの隔離** -- SandboxはAPIサーバーの内部ネットワークにアクセスできません。
* **設定可能な環境変数** -- シークレットはToolSetごとに注入され、ToolSet間で共有されません。
* **自動クリーンアップ** -- 実行完了またはタイムアウト後にSandboxは終了されます。

## ベストプラクティス

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

## 関連ドキュメント

* [REST API](/ja/pages/toolbox/developer/api) -- 認証の詳細とエンドポイントリファレンス
* [Webhook](/ja/pages/toolbox/developer/webhooks) -- イベント通知のセキュリティ（署名検証）
* [Sandboxプロバイダー](/ja/pages/toolbox/advanced/sandbox) -- 実行環境の隔離