Salesforce項目レベルセキュリティ：管理者向け完全ガイド

日付:

背景と応用シナリオ

Salesforce管理者として、私たちは日々、組織のデータを保護し、適切なユーザーが適切な情報にのみアクセスできるようにする責任を負っています。新人の営業担当者が、経験豊富なマネージャーしか見るべきでない割引率の項目を編集できてしまったり、サポート担当者が顧客の機密性の高い個人情報にアクセスできてしまったりする状況を想像してみてください。このような事態は、データインテリティーの低下、コンプライアンス違反、そしてビジネス上のリスクに直結します。

ここで重要な役割を果たすのが、Field-Level Security (FLS)、日本語では項目レベルセキュリティと呼ばれるSalesforceの基本的なセキュリティ機能です。FLSは、特定のプロファイルや権限セットを持つユーザーに対して、オブジェクトの個々の項目（フィールド）を「表示可能」にするか、「編集可能」にするか、あるいは「完全に非表示」にするかを制御する仕組みです。これは、Salesforceのセキュリティモデルにおける非常に重要な階層であり、オブジェクトレベルのアクセス権をさらに細かく調整する強力なツールです。

具体的な応用シナリオは多岐にわたります：

  • 人事部門：従業員オブジェクトの「給与」や「評価」といった項目は、人事担当者と役員プロファイルにのみ表示し、他の全従業員からは非表示にする。
  • 営業部門：商談オブジェクトの「承認済み割引率」項目は、営業マネージャーのみが編集可能とし、一般の営業担当者にはRead-Only（参照のみ）で表示する。
  • サービス部門：ケースオブジェクトにある「顧客のクレジットカード番号（下4桁）」のような機密項目は、支払い処理を専門とする特定のチームに割り当てられた権限セットを持つユーザーのみが表示できるようにする。
  • コンプライアンス：GDPRや個人情報保護法などの規制に対応するため、個人を特定できる情報（PII）へのアクセスを、業務上必要な最小限のユーザーに限定する。

このように、FLSを適切に設定することで、組織はデータの可視性をきめ細かく制御し、データ漏洩のリスクを最小限に抑え、業務プロセスを円滑に進めることができるのです。

原理説明

Field-Level Securityの仕組みを理解するためには、Salesforceのセキュリティ設定がどのように連携して機能するかを知ることが重要です。FLSは単独で存在するのではなく、他のセキュリティ設定と連動して、最終的なデータアクセス権を決定します。

アクセスレベル

FLSには基本的に2つのアクセスレベルがあります：

  • Visible（参照可能）：ユーザーがその項目の値を表示できます。チェックボックスがオンになっている状態です。
  • Read-Only（参照のみ）：ユーザーは項目値を表示できますが、編集はできません。「参照可能」がオンで、「参照のみ」もオンになっている状態です。もし「参照可能」がオフであれば、この設定は意味を持ちません。

ユーザーが項目を編集するためには、「参照可能」がオンで、かつ「参照のみ」がオフである必要があります。

設定の適用場所

FLSは、主に2つの場所で設定されます。

1. Profile（プロファイル）：プロファイルは、ユーザーがSalesforce内で何を見て、何ができるかを定義する設定の集合体です。伝統的に、FLSはプロファイル単位で設定されてきました。例えば、「営業担当」プロファイルには商談のほとんどの項目への編集アクセスを許可し、「マーケティング」プロファイルには参照アクセスのみを許可する、といった設定が可能です。

2. Permission Set（権限セット）：権限セットは、特定のツールや機能へのアクセス権をユーザーに付与するための設定の集合です。現代のSalesforce管理におけるベストプラクティスは、プロファイルを最小限の権限のベースラインとして維持し、追加の権限を権限セットで付与することです。例えば、「割引承認者」という権限セットを作成し、商談の「承認済み割引率」項目への編集権限をその権限セットに含め、特定のマネージャーユーザーに割り当てることができます。これにより、プロファイルを無数に作成・管理する手間が省け、より柔軟でスケーラブルな権限管理が実現します。

セキュリティルールの優先順位

Salesforceのセキュリティは、常に最も制限の厳しい設定が優先されるという原則に基づいています。FLSも例外ではありません。

例えば、あるユーザーに割り当てられたプロファイルでは項目Aが「参照のみ」に設定されていても、同時に割り当てられた権限セットで項目Aが「編集可能」に設定されていれば、そのユーザーは項目Aを編集できます。逆に、プロファイルで項目Aが非表示に設定されている場合、権限セットで編集可能になっていても、そのユーザーは項目Aを見ることも編集することもできません。実際には、プロファイルと権限セットの組み合わせで許可が与えられる形になります。

また、FLSとPage Layouts（ページレイアウト）の関係を理解することも非常に重要です。ページレイアウトは、レコード詳細ページのUI（ユーザーインターフェース）上で項目をどのように表示するかを制御します。ページレイアウトで項目を非表示にしても、それはあくまでUI上の表示を隠しているに過ぎません。そのユーザーがFLSでその項目へのアクセス権を持っていれば、レポート、検索、API経由では依然としてデータにアクセスできてしまいます。真のセキュリティはFLSによって担保され、ページレイアウトはUIの利便性のために使用されると覚えておくことが重要です。

示例コード

管理者として、私たちは主に設定画面（UI）でFLSを操作しますが、開発者がApexコードを書く際に、私たちが設定したFLSを正しく尊重することが不可欠です。もし開発者がFLSを無視したコードを書いてしまうと、セキュリティ設定がバイパスされ、データ漏洩につながる可能性があります。そのため、管理者は開発者がどのようにFLSをコード内でチェックすべきかを理解しておくことが、協力体制を築く上で非常に役立ちます。

以下は、Salesforceの公式ドキュメントで推奨されている、Apexで項目のアクセス権を確認するためのコード例です。このコードは、現在のユーザーが取引先（Account）オブジェクトの「AnnualRevenue（年間売上）」項目に対して参照アクセス権と更新アクセス権を持っているかを確認してから、DML（データ操作言語）操作を実行します。

// このコードは、現在のユーザーの権限に基づいて項目へのアクセスを動的にチェックします。
// まず、チェックしたいオブジェクトと項目のスキーマ情報を取得します。
// Schema.SObjectType.Account は取引先オブジェクトの定義を表します。
// .getDescribe() メソッドでオブジェクトの詳細な情報を取得します。
Schema.DescribeSObjectResult R = Account.SObjectType.getDescribe();

// オブジェクトの全項目のマップを取得します。キーはAPI名（小文字）です。
Map<String, Schema.SObjectField> M = R.fields.getMap();

// AnnualRevenue 項目の詳細なスキーマ情報を取得します。
Schema.DescribeFieldResult F = M.get('AnnualRevenue').getDescribe();

// isAccessible() メソッドを使用して、現在のユーザーがこの項目を参照できるか（表示できるか）をチェックします。
// これは、管理者が設定したFLSの「参照可能」設定を反映します。
boolean isAccessible = F.isAccessible();

// isUpdateable() メソッドを使用して、現在のユーザーがこの項目を更新できるか（編集できるか）をチェックします。
// これは、FLSの「参照可能」がオンで、かつ「参照のみ」がオフの状態を反映します。
boolean isUpdateable = F.isUpdateable();

// アクセス権のチェック結果をデバッグログに出力します。管理者は開発者ツールでこれを確認できます。
System.debug('AnnualRevenue is accessible? ' + isAccessible);
System.debug('AnnualRevenue is updateable? ' + isUpdateable);

// もし項目が参照可能かつ更新可能な場合にのみ、DML操作を実行します。
// このチェックを行わないと、ユーザーが権限を持っていない項目をコード経由で
// 更新しようとした際に、SecurityException が発生する可能性があります。
if (isAccessible && isUpdateable) {
    try {
        // 例として、特定の取引先を更新します。
        // 実際のコードでは、トリガーのコンテキスト変数などからレコードを取得します。
        Account acc = [SELECT Id, AnnualRevenue FROM Account WHERE Name = 'Example Corp' LIMIT 1];
        acc.AnnualRevenue = 1000000;
        update acc;
        System.debug('AnnualRevenue updated successfully.');
    } catch (DmlException e) {
        // DML操作中にエラーが発生した場合の処理
        System.debug('An error occurred during DML operation: ' + e.getMessage());
    }
} else {
    // ユーザーが必要な権限を持っていない場合の処理
    System.debug('Current user does not have sufficient permissions to update AnnualRevenue.');
}

このコードスニペットは、開発者がセキュリティのベストプラクティスを遵守するための基本形です。管理者は、開発チームと協力し、このようなアクセス権チェックがカスタムコードに適切に実装されていることを確認するべきです。

注意事項

FLSを効果的に運用するためには、いくつかの重要な注意点を理解しておく必要があります。

権限の優位性

「すべてのデータの参照」および「すべてのデータの変更」という強力なシステム権限を持つユーザー（通常はシステム管理者プロファイル）は、FLSの設定をバイパスします。つまり、これらの権限を持つユーザーは、FLSで非表示に設定されている項目であっても、すべてのデータを表示・編集できてしまいます。この権限の割り当ては慎重に行う必要があります。

APIアクセスへの影響

FLSは、SalesforceのUIだけでなく、API（REST API, SOAP API, Bulk API 등）を介したすべてのデータアクセスに対しても強制されます。これにより、外部システム連携やデータローダーを使用する際にも、設定したセキュリティが維持されます。これはFLSの非常に強力な点です。

レポートと検索

ユーザーが某个項目の参照権限を持っていない場合、その項目はレポートビルダーの項目リストに表示されず、既存のレポートからもその列は表示されません。同様に、グローバル検索の結果にもその項目の内容は含まれません。

数式項目と積み上げ集計項目

数式項目が、ユーザーがアクセスできない項目を参照している場合、その数式項目自体が表示されないことがあります。ただし、画像を表示する数式項目など、一部の例外も存在します。積み上げ集計項目も同様に、参照先の項目へのアクセス権がない場合、計算結果が正しく表示されないことがあります。

項目の暗号化との関係

FLSはアクセス制御を行いますが、Shield Platform Encryptionなどの暗号化は、保存されているデータ（at rest）を保護するものです。これらは異なる目的を持つセキュリティ機能であり、組み合わせて使用することで、より強固なデータ保護が実現できます。

まとめとベストプラクティス

Field-Level Securityは、Salesforceプラットフォームのデータセキュリティを支える根幹的な機能です。管理者としてFLSをマスターすることは、組織のデータを保護し、ユーザーが必要な情報にのみ効率的にアクセスできる環境を構築するために不可欠です。

最後に、FLSを運用する上でのベストプラクティスをいくつか紹介します。

  1. 最小権限の原則（Principle of Least Privilege）：ユーザーには、業務遂行に必要な最小限の権限のみを付与することを基本とします。最初からすべてを許可するのではなく、デフォルトでは非表示・参照のみに設定し、必要に応じて権限セットでアクセスを許可していくアプローチが安全です。
  2. 権限セットを積極的に活用する：プロファイルは、組織全体の基本的なアクセス権限のテンプレートとして利用し、部署や役職、特定のプロジェクトに応じた追加の権限は、権限セットおよび権限セットグループを使用して付与します。この方法により、管理が簡素化され、将来的な変更にも柔軟に対応できます。
  3. 定期的な棚卸しと監査：組織の成長や変化に伴い、権限設定が現状と乖離することがあります。四半期に一度など、定期的にプロファイルと権限セットのFLS設定を見直し、不要なアクセス権が付与されていないかを確認することが重要です。設定変更履歴（Setup Audit Trail）を活用して、誰がいつFLSを変更したかを追跡することも有効です。
  4. ドキュメンテーションの徹底：なぜ特定のプロファイルや権限セットにこのFLSが設定されているのか、その理由を文書化しておきましょう。これにより、将来の管理者が設定の意図を理解しやすくなり、誤った変更を防ぐことができます。
  5. 開発チームとの連携：カスタム開発を行う際は、開発者がApexやVisualforce、Lightningコンポーネント内でFLSを正しくチェックするように徹底させましょう。セキュアコーディングのガイドラインを共有し、コードレビューのプロセスにセキュリティチェックを組み込むことが理想的です。

これらのベストプラクティスを実践することで、あなたはSalesforce管理者として、組織の最も貴重な資産であるデータを確実に保護し、信頼性の高いプラットフォーム運用を実現できるでしょう。

コメント

コメントを投稿