Salesforceで最小権限の原則を実装する方法
オリジナル記事
How to Implement the Principle of Least Privilege in Salesforce
最小権限の原則（PoLP）は、情報セキュリティで最も幅広く適用されている概念の1つです。Salesforceアーキテクトには、権限のレベルを常に最小限に抑えながら、ユーザのニーズに合ったデータアクセス制御を設計するという責任があります。
Salesforceプラットフォームには、ユーザとプロセスが職務を実行するために必要な情報とリソースのみにアクセスできるようにするために使用できるツールが豊富に用意されています。
この記事では、PoLPを設計する際に考慮する必要があるいくつかの要素について説明します。
- まず、厳重なデータアクセス制御を設計するために使用できる主なプラットフォーム機能を確認します。ユーザコンテキストとシステムコンテキストの比較、およびその他の実行コンテキストについて説明します。
- 次に、Salesforceデータアクセスパラダイムとデータアクセス制御にとっての意味を見ていきます。
- 最後に、例と関連するセキュリティリスクを確認し、考えられる修正アプローチについて説明します。
データアクセス制御を管理するためのSalesforce機能
Salesforceのデータアクセス制御は、主に2つのレベルで管理されます。
- オブジェクト（またはテーブル）とその項目（または列）へのアクセスのレベルを定義するためのプロファイル、権限セット、権限セットグループ。可能な場合は、プロファイルよりも権限セットと権限セットグループを使用することをお勧めします。どのような場合にどの方法を使用するかについて詳しくは、How to Build a User Security Model（ユーザセキュリティモデルの構築方法）を参照してください。
- 特定のオブジェクトの特定のレコード（または行）へのアクセスを定義するための共有ルールと共有セット。レコードベースの共有も、グループ、チーム、テリトリー、Apex共有などの他の高度な機能によって提供されます。
車に例えてみましょう。
- プロファイルと権限セットは運転免許です。運転免許は運転できる車種を指定します。
- レコードレベルのアクセスは車のキーによって提供されます。特定の車を運転するには、免許だけでは不十分です。車のキーも必要です。
効果的な運転免許を設計し、車のキーを保護する方法について詳しくは、概要に関するこのTrailheadモジュールを確認し、より詳しい情報についてはSalesforceセキュリティガイドを参照してください。
コンポーネントに適用されるアクセス制御
ほとんどのデフォルトコンポーネントで、プロファイル/権限セットとレコードレベルのアクセス権の両方が適用されます。この例には、標準Lightning Components、標準APIがあります。
プロセスビルダーのように、プロファイル/権限セットおよびレコードレベルのアクセス権が常にバイパスされるケースもあります。
その他のケースでは、実行コンテキストはさまざまです。
たとえば、Apexはデフォルトで、オブジェクトレベルのセキュリティおよび項目レベルのセキュリティをバイパスして動作します。このルールの例外は、executeAnonymous呼び出しによって実行されるApexコードとApex内のChatterだけです。共有キーワードが指定されていない場合、このクラスが@AuraEnabled Apexコントローラーでない限り、共有ルールも無視されます。
Apexには、Security.stripInaccessibleやwith security_enforcedなど、Apexコードでの項目およびオブジェクトレベルのセキュリティの適用を支援するツールが用意されています。つまり、一部の（ただし全部ではありません）アクセスについてアクセスチェックを混在させることができます。キーワードwith sharing、without sharing、またはwith inherited sharingを使用して共有アクセスを指定することもお勧めします。
これらの機能の詳細情報は、Apexセキュリティと共有ドキュメントで確認できます。
実行コンテキストが異なるもう1つの例は、フローです。ここでも、共有ルール、オブジェクトレベルのセキュリティ、項目レベルのセキュリティがバイパスされ、フローの実行コンテキストが変更される可能性があります。
ご覧のように、Salesforceプラットフォームには、Salesforceアーキテクトがコンポーネントの実行コンテキストを柔軟に制御できるオプションが数多く用意されています。これらのオプションは4つの主なカテゴリに分類できます。
- 右上のセルでは、コードはシステムコンテキストで実行されます。
- 左下のセルでは、コードはユーザコンテキストで実行されます。（これがデフォルトのオプションになるはずです。）
- それ以外はすべて、中間に位置します。
ユーザコンテキストとシステムコンテキストを比較して説明するときは、コンテキストがオブジェクト/項目レベルのアクセスに関連するか、レコードレベルのアクセスに関連するか、または両方に関連するかを明確にしてください。通常、権限バイパスの有無、共有の有無とともに使用すると、より明確になります。
データアクセス — Salesforceパラダイム
Salesforceのデータアクセス制御はシンプルなパラダイムに従っています。特定のユーザのデータアクセスは、データをアクセスするために使用されるチャネルにかかわらず同じです。
このパラダイムは、ほとんどの場合、問題ありません。ユーザが特定のレコードへのアクセスを必要とする場合は、アクセスを付与するだけです。しかし、ユーザが特定の条件下でのみレコードにアクセスできるようにしたい場合があります。ユーザにレコードに一切アクセスさせず、ユーザに代わって操作を実行したい場合もあります。
たとえば、買い物かごへの書き込みアクセス権を持つユーザは、マルチステップのショッピングジャーニーに従って、ユーザインターフェースから買い物かごを更新できます。しかし、買い物かごへの書き込みアクセス権があるため、ガイド付きのフローの外部で、標準レコードページから、またはAPI経由で直接、更新することもできます。
ユーザがデフォルトで使用できる複数のチャネルがあります。主なものは次のとおりです。
- LightningおよびClassicユーザインターフェース — 標準およびカスタムページ
- コミュニティ — 標準の動的（レコード詳細、レコードリスト、関連レコードリスト）および静的レコードページ、およびカスタムページ
- レポートとダッシュボード
- リストビュー
- グローバル検索
- API — 接続されたアプリケーション経由でのアクセスを含む
- ブラウザーから直接呼び出すことができる、公開されたXHR（XML HTTP要求）エンドポイント注：AuraおよびLightning Webコンポーネントは、SPA（シングルページアプリケーション）アーキテクチャをベースとしています。XHRは、コンポーネントがクライアント側とサーバー側の間でデータを転送する方法です。
リスクは何か？
プロファイル、権限セット、または共有ルールがあまりに緩い場合、ユーザは実際に必要なもの以外にもアクセスできます。内部ユーザが偶発的にデータを破壊する可能性があります。しかし、主なリスクは外部アクセスにあります。攻撃者はこれらの脆弱性を悪用して、機密情報にアクセスする（たとえば、完全な商品価格表をダウンロードする）、または不正操作を実行する（たとえば、買い物かごに追加した商品の価格を変更する）ことができます。
購入ジャーニーの例
例を詳しく見てみましょう。
以下は、データアクセス制御と各オブジェクトカテゴリに必要な関連アクセスレベルを含む、標準的な購入ジャーニーの主なステップです。この例は純粋に仮定のものであり、上記のリスクを説明することが目的です。以下の表に示すアクセスレベルは、推奨されるベストプラクティスではありません。
また、以下の例はB2Cシナリオにもとづいていますが、リスクはすべてのオンプラットフォームアプリケーションに関連することにも注意してください。
推奨されるアプローチ
最小権限の原則に沿って上記のリスクを低減するための方法は複数あります。
オプション1：ユーザ権限をバイパスするか、共有なしでコードを実行する
最適な方法は、オブジェクト/項目/レコードアクセスを付与せず、データへの直接アクセスを防止することです。その後、権限またはレコードレベルのアクセスをバイパスし、プログラムによってアクセスレベルを定義することができます。
このアプローチにより、開発者は完全に制御し、データアクセスをPoLPに沿うように適切に調整できます。
これには、適切なタイミングで適切な制御を実装するための高度なスキルが必要です。実装が不適切な場合、セキュリティ侵害のリスクはさらに高まる可能性があります。データアクセスをバイパスするとき、開発者は任意のオブジェクトから任意のレコードへのアクセスをコードから付与できます。
そのため、複数のレベルで徹底したセキュリティテストを実行することが重要です。
- セキュリティ重視のユニットテスト：さまざまなアクセス権を持つテストユーザを使ってユニットテストを実行し（runAsを使用）、ユーザが閲覧および実行できる内容がユーザが権限を持っている内容と合っていることを確認します。必ず、アクセス権なしのユーザの動作を確認するテストを含めます。
- 機能テスト：肯定的と否定的の両方のテストを実行します。
- ブラックボックスおよびホワイトボックス侵入テスト：以前のフェーズで特定されていない未解決のギャップを発見します。
権限またはレコードレベルのアクセスをバイパスできない場合は、他のオプションを検討する必要があります。
オプション2：すべてのチャネルをブロックする
制御されていない方法（ガイド付きのフローの外部など）でデータにアクセスできるチャネルをユーザが使用できないようにします。
一部のチャネルは容易にブロックできます。ユーザのグループに対してAPIアクセスを削除し、リストビューを制限し、レポートへのアクセスを削除することができます。ただし、これにより、本来ならこれらのユーザがすぐに使える機能が大幅に制限されます。たとえば、APIアクセスがないと、ユーザは一部のサードパーティアプリケーションを利用できない場合があります。外部ユーザの場合、コミュニティユーザインターフェースを完全にカスタマイズする必要があります。また、グローバル検索などの一部のチャネルは、完全に非アクティブ化することができません。
オプション3：ユーザセッションベースの権限セット
セッションベースの権限セットを使用すると、セッションの期間中ユーザに付与される権限を一時的にアクティブ化できます。
このアプローチは、内部ユーザのオブジェクトおよび項目へのアクセス権を昇格させる場合に適切なオプションです。ただし、ユーザエクスペリエンスへの影響により、外部向けのアプリケーションでは使用することが困難です。また、レコードレベルのアクセスはやはり個別に対処する必要があります。
オプション4：追加の制御を実装する
検証ルール、トリガなどの自動化を追加して、不正なデータ変更を防止します。
このアプローチはSalesforceのデータアクセス原則に沿っていますが、すべての否定的なユースケース（ユーザがデータにアクセスできるべきではない状況）に適切に対応するには大量の作業が必要になることがあります。さらに、これはユーザエクスペリエンスに悪影響を及ぼす可能性があり、ユーザが操作を実行しようとしても、完了できないことが後で通知されるだけとなります。また、これでは、ユーザがデータへの読み取りアクセス権を持つことを防げません。
まとめ
SalesforceアーキテクトがPoLPに沿ったソリューションを設計するために使用できるツールは数多くあります。セキュリティモデルを指定するときは、データがアクセスされるべきコンテキストを理解することが重要です。重要な質問は次のとおりです。
- 通過するチャネルを問わずユーザがレコードにアクセスできることは適切か？レコードは特定の条件下でのみアクセスされるべきか？
- ユーザがレコードへのアクセス権を実際に持つことは受け入れ可能か、それとも操作をユーザに代わって実行すべきか？
また、プロファイルと権限セットは、通常すべてのコンポーネントに適用される、データ関連以外の特権へのアクセスを付与する場合にも使用されることに注意してください。
リソース
- Salesforceデータの保護（Trailhead）
- Salesforceセキュリティガイド
- ユーザ権限およびアクセス（プロファイルと権限セット）
- Apexセキュリティと共有
- オブジェクト権限と項目権限の適用
- Blog: field Level Security in Apex（ブログ：Apexの項目レベルのセキュリティ）（Salesforce開発者）
- フローが実行されるコンテキスト
- Sharing and Security best practices for Experience Cloud（Experience Cloudの共有とセキュリティに関するベストプラクティス）
著者紹介
Sandrine Hiestは、Salesforceのプログラムアーキテクトディレクターです。2017年の入社以来、Salesforceの最も複雑なエンタープライズのお客様の信頼できるアドバイザー、テクニカルリーダー、プラットフォームエキスパートを務めてきました。Sandrineは、セキュリティおよび拡張性のトピックに関するお客様のエンパワーメントと他のアーキテクトのコーチングに情熱を注いでいます。
