ObjectOS権限
アイデンティティ、ロール、権限セット、レコードアクセス、フィールドセキュリティ — アクセスモデル全体を1ページにまとめて解説します。
権限
ObjectOS は、エンタープライズソフトウェアで20年間にわたり実績を重ねてきた手法を取り入れた、階層型のアクセスモデルを備えています。アイデンティティ → ロール → 権限セット → レコードアクセス → フィールドセキュリティという構成です。各レイヤーはそれぞれ異なる問いに答えるものであり、必要のないレイヤーは無視して構いません。
モデルを1つの図で
Authentication Who is the caller?
↓
Identity Which user/org/membership is active?
↓
Roles Where do they sit in the hierarchy?
↓
Permission sets What CAN they do — apps, objects, fields, system?
↓
Record access WHICH records can they touch?
↓
Field security For those records, which FIELDS are readable / writable?各レイヤーは security プラグインによって適用されます。シンプルなアプリでは権限セットだけ（ロールやシェアルールなし）を使い、必要が生じた時点で残りを追加できます。
レイヤー 1 — アイデンティティ
アイデンティティオブジェクトは、プロジェクトのデータベースに存在します。最も重要なものは次のとおりです。
| オブジェクト | 表すもの |
|---|---|
sys_user | 認証可能な個人またはサービスアカウント |
sys_organization | テナント / ワークスペースの境界（マルチテナントアプリ向け） |
sys_member | 組織におけるユーザーのメンバーシップ（ロールはメンバーシップごとに割り当てられる） |
sys_department、sys_team | シェアルール向けの任意の組織構造 |
sys_invitation | 承諾待ちの保留中の招待 |
sys_session | アクティブな認証済みセッション |
sys_api_key | ユーザーに紐づく長期間有効なプログラム用の認証情報 |
マルチテナントのデプロイメントでは次のようになります。
- ユーザーはプロジェクトのデータベースにスコープされます。
- セッションはプロジェクトのホスト名にスコープされます。
- 行レベルのチェックには、現在のユーザーの組織と権限が使用されます。
- コントロールプレーンのユーザーは自動的にビジネスユーザーにはなりません。プラットフォームの SSO 経由でマッピングするか、明示的にプロビジョニングする必要があります。
これらは実行時に Console（/_console/）から作成・管理するか、新しい環境向けに objectstack.config.ts でシードします。
レイヤー 2 — ロール
ロールは組織図（CFO → 財務マネージャー → アナリスト）をモデル化します。これらが存在する主な目的は、シェアルールやレポートで「レコード所有者のマネージャー」といった表現を可能にすることです。階層的なアクセスが必要な場合はロールを使い、フラットなチームでは省略してください。
ロールを参照してください。
レイヤー 3 — 権限セット
権限セットは、機能を付与するための主要な手段です。ユーザーに直接、またはロール経由でアタッチされます。
付与する内容
| 種類 | 例 |
|---|---|
| アプリケーションアクセス | CRM を開く、サポートポータルを開く |
| オブジェクト権限 | オブジェクトのレコードの作成 / 読み取り / 更新 / 削除 |
| フィールド権限 | 特定のフィールドの読み取りまたは更新 |
| システム権限 | Console へのアクセス、レポートの実行、データのエクスポート、監査ログの閲覧 |
| 連携権限 | API キーの使用、Webhook の設定、管理アクションの実行 |
オブジェクト権限フラグ
これらは security プラグインがチェックする正確なフラグ名です。
| フラグ | 意味 |
|---|---|
allowRead | レコードアクセスを通じてユーザーが閲覧できるレコードを読み取る |
allowCreate | 新しいレコードを作成する |
allowEdit | ユーザーが閲覧できるレコードを更新する |
allowDelete | ユーザーが閲覧できるレコードを削除する |
viewAllRecords | レコードアクセスルールを無視して、そのオブジェクトのすべてのレコードを読み取る |
modifyAllRecords | すべてのレコードを更新 / 削除する。viewAllRecords を含意する |
viewAllRecords と modifyAllRecords は、そのオブジェクトに対するテナント全体のスーパーユーザー権限です。明示的な管理用の権限セットに限定し、ユーザー向けのロールには含めないでください。
権限セットを参照してください。
レイヤー 4 — レコードアクセス
viewAllRecords を持たないユーザーが閲覧できる行はどれでしょうか。
このモデルは次をサポートします。
- 暗黙的な所有権（ユーザーが作成または所有する行）
- シェアルール（宣言的 — 「チーム A はチーム A のレコードを閲覧できる」）
- 明示的な共有（
sys_record_shareの行 — 個別の共有） - 組織スコープ（行の
organization_idがユーザーの組織に一致する）
レコードアクセスを参照してください。
レイヤー 5 — フィールドセキュリティ
ユーザーがレコードを閲覧できる場合でも、個々のフィールドは次のように設定できます。
- 非表示 — フィールドは API および UI のレスポンスから除外されます。
- 読み取り専用 — フィールドは返されますが、書き込みは拒否されます。
フィールドセキュリティは、オブジェクトごと + 権限セットごとに設定します。代表的な用途は次のとおりです。
- HR 以外のユーザーから
sys_userのsalaryを非表示にする。 - サポート担当者に対して
external_account_idを読み取り可能だが編集不可にする。
これはオブジェクト権限と同じエバリュエーターで適用されるため、REST、ObjectQL、Console 全体に一貫して適用されます。
どこから始めるか
| 構築しているのが … | 使うもの |
|---|---|
| 単一チームの社内ツール | 権限セットのみ |
| マネージャーがレポートを閲覧するマルチチームアプリ | ロール + 権限セット |
| マルチテナントの SaaS 型アプリ | 組織スコープ + 権限セット |
| PII を扱う規制対象アプリ | 上記にフィールドセキュリティを追加 |
| 複雑な CRM 型アプリ | フルスタック |
診断と監査
/_console/は、任意のユーザーの実効権限を評価された状態で表示します。- 監査ログ（
sys_audit_log）は、権限に関わる変更 — 付与、ロールの割り当て、権限セットの編集 — を記録します。 - 拒否されたリクエストは、失敗したルール（オブジェクト権限 / レコードアクセス / フィールドセキュリティ）をログに残すため、サポートは「なぜこれが見えないのか」という問い合わせに迅速に答えられます。