権限

ObjectOS は、エンタープライズソフトウェアで 20 年にわたって機能してきた定石から借りた、階層化されたアクセスモデルを持っています。アイデンティティ → ポジション → 権限セット → レコードアクセス → フィールドのセキュリティです。各層は異なる問いに答え、必要のない層は無視できます（ObjectStack 13 では、旧来の Roles と Profiles の概念がポジションに統合されました。ポジションを参照してください）。

1 枚の図で見るモデル

Authentication       Who is the caller?
        ↓
Identity             Which user/org/membership is active?
        ↓
Positions            Which job functions do they hold?
        ↓
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?

各層はセキュリティプラグインによって強制されます。シンプルなアプリでは権限セットだけ（ポジションも共有ルールもなし）を使い、要件が出てきたところで残りを追加できます。

第 1 層：アイデンティティ

アイデンティティのオブジェクトはプロジェクトのデータベースにあります。最も重要なもの：

マルチテナントのデプロイメントでは：

• ユーザーはプロジェクトのデータベースにスコープされます。
• セッションはプロジェクトのホスト名にスコープされます。
• 行レベルのチェックは、現在のユーザーの組織と権限を使います。
• コントロールプレーンのユーザーが自動的に業務ユーザーになることはありません。プラットフォーム SSO または明示的なプロビジョニングで対応付ける必要があります。

これらは実行時に Setup（/_console/）で作成 / 管理するか、新しい環境のために objectstack.config.ts で初期投入します。

第 2 層：ポジション

ポジションは職務（「Sales Manager」、「Support Agent」）をモデル化します。ポジションはフラットです。階層は事業単位のツリーにあるので、共有ルールやレポートは「レコードの所有者の単位とその下位の単位」のような言い方をします。初期投入される対象者のアンカー everyone（認証されたすべてのユーザー）を使えば、カスタムのフォールバックのロジックなしにベースラインの権限セットをバインドできます。その対になる guest（匿名の呼び出し元）は何も付与しません。匿名の訪問者がデータに届くのは、公開フォームや共有リンクのように、それを宣言した画面を通じてだけです。ポジションは職務ごとに権限セットを配布するのに使い、フラットなチームではカスタムのポジションを省略してください。

ポジションを参照してください。

第 3 層：権限セット

権限セットは、機能を付与する主な方法です。ユーザーに直接、またはポジションを通じて付けます。

何を付与するか

オブジェクトの権限フラグ

セキュリティプラグインがチェックする、正確なフラグの名前です。

viewAllRecords と modifyAllRecords は、そのオブジェクトについてのテナント全体のスーパーユーザーの付与です。明示的な管理用の権限セットのために取っておき、ユーザー向けのどのポジションにも含めないでください。

エクスポートは独立したオプトインの付与です。 allowExport が未設定なら拒否を意味します。allowRead から継承されることはなく、viewAllRecords / modifyAllRecords もそれを与えません。レコードを読むことと、テーブル全体の機械可読なコピーを取ることは別の行為であり、これはその 2 つを分ける職務分掌の軸です。エクスポートすべき人が持つすべてのセットで、オブジェクトのエントリ（またはワイルドカード '*'）に明示的に付与してください。Permission Sets を参照してください。

権限セットを参照してください。

第 4 層：レコードアクセス

viewAllRecords を持たないユーザーは、どの行を見られるのでしょうか。

このモデルは次のものをサポートします。

• 暗黙の所有（ユーザーが作成した、または所有している行）
• 共有ルール（宣言的。「チーム A はチーム A のレコードを見られる」）
• 明示的な共有（sys_record_share の行。ユーザー、ポジション、または単位とその配下に付与する一回限りの共有）
• 組織によるスコープ（行の organization_id がユーザーの組織と一致する）

ObjectStack 13 以降、所有者のフィールドを持つカスタムオブジェクトの共有モデルのデフォルトは非公開です。公開するには sharingModel を明示的に宣言してください。

レコードアクセスを参照してください。

第 5 層：フィールドのセキュリティ

ユーザーがレコードを見られる場合でも、個々のフィールドは次のようにできます。

• 非表示：フィールドは API と UI のレスポンスから取り除かれます。
• 読み取り専用：フィールドは返されますが、書き込みは拒否されます。
• マスク：呼び出し元がそのフィールドの要求する機能を持っていない限り、値の大部分が置き換えられて返されます（138****5678）（ObjectStack 17.1）。

非表示と読み取り専用はオブジェクトごと + 権限セットごとに設定し、マスクはフィールドそのものに宣言します。典型的な使い方：

• sys_user の salary を、人事以外の全員から隠す。
• external_account_id を、サポート担当者には読めるが編集できないようにする。
• 顧客の電話番号を、顧客に電話をかけるチーム以外の全員には 138****5678 と表示する。

これはオブジェクトの権限と同じ評価器で強制されるので、REST、ObjectQL、UI のすべてに一様に適用されます。フィールドレベルのセキュリティを参照してください。

どこから始めるか

診断と監査

• explain エンジン（explain(principal, object, operation)）は、必要な権限、オブジェクトの CRUD、フィールドのセキュリティ、OWD のベースライン、共有、行レベルセキュリティの各層の判定を順に、層ごとの帰属とともに報告します。Studio の Access の柱は、これを「Why can this user access?」パネルとして表示します。ほかのユーザーについて説明するには manage_users 機能が必要です。
• /_console/ は、任意のユーザーの実効的な権限を、評価されるとおりに表示します。
• 監査ログ（sys_audit_log）は、権限に関わる変更（付与、ロールの割り当て、権限セットの編集）を記録します。
• 拒否されたリクエストは失敗したルール（オブジェクトの権限か、レコードアクセスか、フィールドのセキュリティか）を記録するので、サポートは「なぜこれが見えないのか？」に素早く答えられます。