Salesforce 項目レベルセキュリティを究める：データ保護のための管理者ガイド

背景と応用シーン

現代のビジネス環境において、企業は大量の機密データを扱っており、その保護は最優先事項です。Salesforce は、顧客関係管理（CRM - Customer Relationship Management）のための強力なプラットフォームとして、このデータ保護のニーズに応えるための堅牢なセキュリティモデルを提供しています。その中でも特に重要なのが、項目レベルセキュリティ (FLS - Field-Level Security) です。FLS は、特定のユーザーが特定のオブジェクト (Object - オブジェクト) の項目 (Field - 項目) を参照したり編集したりする権限を、最も詳細な粒度で制御するためのメカニズムです。

FLS の主な目的は、データプライバシーの確保、規制要件（例: GDPR、HIPAA）への準拠、そして組織内の異なる役割を持つユーザーに適切な情報アクセスを提供することです。想像してみてください。営業担当者が顧客の基本的な連絡先情報にアクセスする必要がある一方で、財務担当者のみが与信情報や請求書詳細を参照・更新できるべきです。また、人事部門のユーザーだけが従業員の給与情報にアクセスでき、他の部門のユーザーには表示されないようにする必要があるかもしれません。このようなシナリオにおいて、FLS は不可欠な役割を果たします。

具体的な応用シーンとしては、以下のようなものが挙げられます。

機密データの保護: 顧客の社会保障番号、クレジットカード情報、従業員の給与、健康データなど、特定の個人情報や機密性の高いビジネス情報を、許可されたユーザーのみが参照または編集できるように制限します。
役割ベースのアクセス制御: 営業マネージャーには部下の商談の特定の項目へのアクセスを許可し、一般の営業担当者には許可しない、といった階層的なアクセス制御を実装します。
規制遵守: 業界固有のデータプライバシー規制や政府のデータ保護法規に準拠するために、特定のデータ項目へのアクセスを厳格に管理します。
データ品質と整合性の維持: 誤ったデータ入力や不正な変更を防ぐために、一部の項目を特定ユーザーに対して参照のみに設定したり、完全に非表示にしたりします。

原理説明

Salesforce のセキュリティモデルは、組織全体から項目レベルまで、複数の階層で機能します。FLS はこの階層の最下層、すなわち最も詳細な粒度で機能するセキュリティ層です。組織の共有設定 (OWD - Organization-Wide Defaults)、ロール階層 (Role Hierarchy)、共有ルール (Sharing Rules) がオブジェクトへのアクセスを制御するのに対し、FLS はそのオブジェクト内の個々の項目へのアクセスを制御します。

FLS の設定方法

Salesforce 管理者として、FLS は主に以下の二つの方法で設定します。

プロファイル (Profile): プロファイルは、ユーザーが実行できる操作とアクセスできるデータを定義する基本セットです。各ユーザーは一つのプロファイルに割り当てられます。プロファイル設定内で、個々のオブジェクトの各項目に対し、以下の FLD 設定が可能です。
- 参照可能 (Visible): 項目が表示されます。
- 参照のみ (Read-Only): 項目が表示されますが、編集はできません。
- 非表示 (Hidden): 項目は表示されません。
新しいカスタム項目 (Custom Field - カスタム項目) を作成する際にも、ウィザードの最終ステップで各プロファイルに対する FLS を設定できます。
権限セット (Permission Set): 権限セットは、プロファイルで付与された権限に加えて、特定のユーザーに追加の権限を付与するために使用されます。権限セットはプロファイルを「拡張」するものであり、プロファイルで付与されたアクセスを制限することはできませんが、追加のアクセスを許可することはできます。例えば、プロファイルが項目を「参照のみ」に設定していても、権限セットでその項目を「編集可能」に設定することで、その権限セットを持つユーザーはその項目を編集できるようになります。権限セットは柔軟性が高く、複数の権限セットをユーザーに割り当てることが可能です。これにより、特定の機能やデータへのアクセスを、プロファイルを変更することなく、特定のユーザーグループに付与できます。

FLS と他のセキュリティモデルとの関係

FLS は、Salesforce の他のセキュリティ設定と連携して機能します。例えば、オブジェクトへのアクセスが組織の共有設定や共有ルールによって制限されている場合、そのオブジェクトの項目への FLS が許可されていても、ユーザーはその項目にアクセスできません。FLS は、オブジェクトレベルのアクセスが許可された上で、さらに項目レベルでの詳細なアクセス制御を提供するものです。

FLS が影響を与える範囲

FLS は、Salesforce プラットフォーム上の様々な場所でデータの表示と操作に影響を与えます。

ユーザーインターフェース (UI - User Interface): レコード詳細ページ、編集ページ、レポート、リストビューなど、標準の Salesforce UI 上で項目が表示されるか、編集可能であるかを制御します。
API (Application Programming Interface): SOQL クエリや Apex コードを通じて項目にアクセスしようとする場合、FLS は適用されます。適切な権限がない場合、API 経由での項目の参照や更新は失敗します。
レポート (Report) とダッシュボード (Dashboard): FLS によって非表示に設定された項目は、レポートビルダーでも参照できず、レポートやダッシュボードの出力にも含まれません。
検索 (Search): 非表示に設定された項目は、グローバル検索やサイドバー検索の検索結果にも表示されません。

サンプルコード

Salesforce 管理者として FLD を設定する主な方法は宣言的ですが、Apex コードが FLD の影響をどのように受けるかを理解することは、管理者にとっても重要です。特に、カスタム開発された機能が期待通りに動作しない場合、FLD が原因であることが多いため、その影響を認識しておくべきです。

Salesforce の Apex はデフォルトでシステムコンテキスト (System Context - システムコンテキスト) で実行されます。これは、Apex コードがユーザーのオブジェクトレベルおよび項目レベルセキュリティをバイパスして、すべてのデータにアクセスできることを意味します。しかし、セキュリティとデータ整合性を確保するために、開発者はコード内で明示的にユーザーの権限を適用することが推奨されています。これは、特に Lightning コンポーネント (Lightning Component - Lightning コンポーネント) や Visualforce ページ (Visualforce Page - Visualforce ページ) のコントローラーなどで重要になります。

Apex での項目アクセス権の確認

Apex では、Schema.DescribeFieldResult クラスのメソッドを使用して、ユーザーが特定の項目にアクセスできるか、作成できるか、更新できるかを確認できます。これは、ユーザーインターフェースに表示する項目を動的に制御したり、データの操作を実行する前に権限を確認したりする際に役立ちます。

public class FieldSecurityChecker {
    public static void checkAccountFieldAccess() {
        // Account オブジェクトの Name 項目に関する情報取得
        Schema.DescribeFieldResult nameFieldDesc = Account.Name.getDescribe();
        // Account オブジェクトの AnnualRevenue 項目に関する情報取得
        Schema.DescribeFieldResult annualRevenueFieldDesc = Account.AnnualRevenue.getDescribe();

        // 現在のユーザーが Name 項目にアクセスできるかを確認
        if (nameFieldDesc.isAccessible()) {
            System.debug('Account.Name 項目は参照可能です。');
        } else {
            System.debug('Account.Name 項目は参照不可能です。');
        }

        // 現在のユーザーが Name 項目を更新できるかを確認
        if (nameFieldDesc.isUpdateable()) {
            System.debug('Account.Name 項目は更新可能です。');
        } else {
            System.debug('Account.Name 項目は更新不可能です。');
        }

        // 現在のユーザーが AnnualRevenue 項目にアクセスできるかを確認
        if (annualRevenueFieldDesc.isAccessible()) {
            System.debug('Account.AnnualRevenue 項目は参照可能です。');
        } else {
            System.debug('Account.AnnualRevenue 項目は参照不可能です。');
        }

        // 現在のユーザーが AnnualRevenue 項目を更新できるかを確認
        if (annualRevenueFieldDesc.isUpdateable()) {
            System.debug('Account.AnnualRevenue 項目は更新可能です。');
        } else {
            System.debug('Account.AnnualRevenue 項目は更新不可能です。');
        }

        // 新規レコード作成時に AnnualRevenue 項目を設定できるかを確認
        if (annualRevenueFieldDesc.isCreateable()) {
            System.debug('Account.AnnualRevenue 項目は新規作成時に設定可能です。');
        } else {
            System.debug('Account.AnnualRevenue 項目は新規作成時に設定不可能です。');
        }
    }
}

上記のコードは、現在のユーザーが Account.Name や Account.AnnualRevenue 項目に対して参照、更新、作成の権限を持っているかをチェックします。これにより、開発者はユーザーの FLS に基づいて、例えば特定のボタンを表示するかどうかを決定したり、データの更新処理を実行する前に権限エラーを防いだりすることができます。

SOQL クエリでのセキュリティ強化 (WITH SECURITY_ENFORCED)

Spring '20 リリース以降、SOQL (Salesforce Object Query Language) クエリに WITH SECURITY_ENFORCED 句を追加することで、クエリレベルでオブジェクトレベルおよび項目レベルセキュリティを強制できるようになりました。これにより、開発者は明示的な FLS チェックコードを記述することなく、SOQL クエリが自動的に現在のユーザーの権限を尊重するように設定できます。

public class AccountQueryWithSecurity {
    public static List<Account> getSecureAccounts() {
        try {
            // WITH SECURITY_ENFORCED を使用して、現在のユーザーの権限に基づき Account レコードをクエリ
            // ユーザーが Name または AnnualRevenue 項目にアクセスできない場合、エラーが発生するか、その項目が結果に含まれない
            List<Account> accounts = [
                SELECT Id, Name, AnnualRevenue, Industry
                FROM Account
                WITH SECURITY_ENFORCED
                LIMIT 10
            ];
            System.debug('取得されたアカウント数: ' + accounts.size());
            for (Account acc : accounts) {
                System.debug('アカウント名: ' + acc.Name + ', 年間収益: ' + acc.AnnualRevenue);
            }
            return accounts;
        } catch (QueryException e) {
            // ユーザーに項目へのアクセス権がない場合、QueryException が発生する
            System.debug('セキュリティ例外が発生しました: ' + e.getMessage());
            return new List<Account>();
        }
    }
}

この WITH SECURITY_ENFORCED 句を使用すると、クエリが実行される前に Salesforce が自動的に現在のユーザーのオブジェクトおよび項目レベルセキュリティをチェックします。もしユーザーがクエリ内のいずれかの項目、またはクエリ対象のオブジェクトにアクセスする権限を持っていない場合、QueryException がスローされます。これは、安全なデータアクセスを保証するための強力なツールです。

注意事項

FLS は強力なツールですが、適切に管理しないと予期せぬ問題を引き起こす可能性があります。以下に、管理者が注意すべき点を挙げます。

権限セットとプロファイルの適切な使用:
- 最小権限の原則 (Principle of Least Privilege - 最小権限の原則): ユーザーには、その職務を遂行するために必要な最小限のアクセス権のみを付与するべきです。
- プロファイルはベースラインの権限を提供し、権限セットは追加の権限を付与するために使用するのがベストプラクティスです。プロファイルを多数作成し、それぞれで詳細な FLS を管理するよりも、少数の汎用的なプロファイルと複数の権限セットを組み合わせる方が、管理が容易で柔軟性が高まります。
Apex と API 連携における FLS:
- 前述の通り、Apex はデフォルトでシステムコンテキストで実行されるため、FLS をバイパスする可能性があります。これは、開発者が明示的に isAccessible(), isUpdateable(), isCreateable() メソッドや WITH SECURITY_ENFORCED 句を使用してセキュリティを強制しない限り、意図しないデータ漏洩や変更のリスクを生み出すことがあります。
- インテグレーションユーザー (Integration User - インテグレーションユーザー) が使用するプロファイルや権限セットは、システム連携に必要なすべての項目に対してアクセス権を持っていることを確認してください。そうでなければ、API 経由でのデータ操作が失敗します。
データインポートとエクスポート:
- データローダ (Data Loader - データローダ) や他のデータインポート/エクスポートツールを使用する際、実行するユーザー（または統合ユーザー）の FLS が、操作対象のすべての項目に対して適切に設定されていることを確認してください。権限がない場合、データの挿入、更新、エクスポートが期待通りに行われないか、エラーが発生します。
レポートとダッシュボード:
- レポートやダッシュボードの作成者が、表示したい項目に対して適切な FLS を持っていることを確認してください。FLS によって隠された項目は、レポートビルダーには表示されません。
- 共有されたレポートやダッシュボードを参照するユーザーも、同様にその項目への FLS を持っている必要があります。FLS のないユーザーにとっては、一部の項目が空で表示されたり、完全に非表示になったりします。
既存のプロファイル/権限セットの変更影響:
- 既存のプロファイルや権限セットの FLS を変更すると、その設定が適用されているすべてのユーザーに即座に影響が及びます。変更前に十分なテストを行い、影響範囲を理解することが不可欠です。
トラブルシューティング:
- ユーザーが特定の項目にアクセスできない場合、まずそのユーザーのプロファイルと割り当てられている権限セットの FLS 設定を確認します。Salesforce の「設定」→「ユーザー」→「ユーザーの項目アクセス権の表示」ツールは、特定のユーザーが特定のオブジェクトのどの項目にアクセスできるかを一覧で確認できるため、トラブルシューティングに非常に役立ちます。

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

項目レベルセキュリティ (FLS) は、Salesforce 環境におけるデータ保護の基盤であり、特に機密情報の管理において不可欠な要素です。管理者として FLS を効果的に管理することは、データプライバシーの確保、コンプライアンスの維持、そしてユーザーエクスペリエンスの最適化に直結します。

まとめ

FLS は、オブジェクト内の個々の項目に対する参照および編集アクセスを制御する、最も詳細なセキュリティ層です。
プロファイルと権限セットを通じて設定され、ユーザーインターフェース、API、レポートなど、プラットフォーム全体に影響を与えます。
Apex コードはデフォルトでシステムコンテキストで実行されるため、開発者は明示的に FLS を強制する必要があります（例: isAccessible(), WITH SECURITY_ENFORCED）。

ベストプラクティス

最小権限の原則を徹底する: ユーザーには、その職務に必要な最小限の項目アクセス権のみを付与します。不要なアクセス権は、セキュリティリスクを高めます。
プロファイルと権限セットを戦略的に使用する:
- プロファイルは、ユーザータイプごとの基本的なアクセス権（例: 営業、サポート）を設定するために使用します。
- 権限セットは、特定の機能やプロジェクト、または一時的なアクセスなど、プロファイルで定義されたアクセス権を「追加」するために使用し、柔軟性と管理の容易さを高めます。
- 可能であれば、カスタムプロファイルの数を減らし、権限セットを多用することで、管理が簡素化されます。
定期的に FLD 設定をレビューする: 組織のニーズや規制が変化するにつれて、FLS 設定も古くなる可能性があります。定期的な監査を通じて、設定が現状とセキュリティ要件に合致していることを確認します。
開発者との連携を密にする: カスタム開発を行う際、Apex コードが適切に FLS を尊重しているかを確認するため、開発者と積極的にコミュニケーションを取りましょう。特にカスタムコンポーネントやインテグレーションでは、FLS の適用が非常に重要です。
テストと検証を怠らない: FLS 設定の変更は、本番環境に適用する前にサンドボックス環境で徹底的にテストし、異なるユーザープロファイルや権限セットを持つユーザーが期待通りにデータにアクセスできるか、またはできないかを確認します。
ユーザーに情報を提供し、教育する: データセキュリティの重要性と、なぜ特定の項目が非表示になったり編集できなかったりするのかについて、ユーザーに理解を促します。

Salesforce 管理者として FLS を深く理解し、これらのベストプラクティスを適用することで、組織のデータを安全に保ち、ユーザーが効率的に作業できる環境を構築することができます。データは現代ビジネスの生命線であり、その保護は私たちの共通の責任です。

にゃんこのSalesforce日記

このブログを検索