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