Experience Cloud 開発者ガイド
jセキュリティモデルの決定
使用事例ごとに、カスタムアクセスコントロールモデルを実装するのか、宣言型プラットフォームアクセスコントロールモデルを使用するのかを決定します。可能な場合はプラットフォーム宣言型アクセスコントロールモデルを使用することをお勧めします。ただし、カスタムアクセスコントロールモデルが必要な場合もあります。
カスタムアクセスコントロールモデルが必要な場合:
- コントローラがアクセスするオブジェクトに対する宣言型データ権限 (作成、参照、更新、削除 (CRUD)、項目レベルセキュリティ (FLS)、共有など) を該当するユーザプロファイルおよび権限セットから削除します。共有を使用せずにコントローラを宣言します。
- 共有を使用せずにコントローラに手続き型アクセスコントロールを実装します。営業を受けるコントローラごとに、セキュリティポリシーで必要な手続き型アクセスコントロールロジックを実装します。
プラットフォームの宣言型アクセスコントロールモデルを使用できる場合:
- 共有を使用してコントローラを宣言する場合、プロファイルおよび権限セットごとに共有、オブジェクトの CRUD 権限、FLS を適切に設定します。
コントローラのセキュリティモデルの選択: 例
リードを作成するコントローラを考えます。カスタムアクセスコントロールの例は次のとおりです。
- リードの作成前に CAPTCHA を要求する。
- リードの作成前に紹介コードを要求する。
- リードの作成前のライセンス契約に同意するようにユーザに要求する。
これらの各例では、該当するポリシーで宣言型の共有、CRUD 権限、FLS では適用できない手続き型ステップが必要になります。これらのケースでは、Apex コントローラでカスタムロジックを作成して手続き型ルールを適用します。コントローラを呼び出して、ユーザが基盤となるデータにのみアクセスできるようにするには、宣言型アクセス権 (リードオブジェクトに対する CRUD、FLS、共有など) を削除する必要があります。
ただし、セキュリティポリシーをプラットフォームの CRUD 権限、FLS、共有ロジックに対応付けることができる場合、適切な共有設定およびオブジェクトの CRUD 権限を設定してそのロジックを実装します。その後、共有を使用してコントローラを宣言します。
宣言型アクセス権を削除して、共有を使用しない手続き型ロジックルールを使用することには一定のリスクがあることに注意してください。
- 手続き型 Apex コードを介して組織のセキュリティロジックを実装します。適切なプロファイル、レコード、ステートフルアクセスチェックを正しく実装できない場合、実装エラーとなり、データの不正アクセスにつながります。
- セキュリティポリシーでステートフルロジックが求められている場合、カスタムセッション管理ロジックを実装して要求間で状態を保持します。
- 手続き型アクセスコントロールロジックを作成する場合、組織のシステム管理者がすばやく管理および変更することが困難になります。
ユーザが必ず標準コントローラではなく独自のコントローラを使用して基盤となるオブジェクトにアクセスするようにするには、CRUD 権限および FLS アクセス権を削除する必要があります。プラットフォームでは、認証されていないゲストユーザを区別できないため、ほとんどの場合、カスタムアクセスコントロールを実装し、ゲストユーザによるすべてのオブジェクトへの宣言型アクセスを拒否することが必要になります。