Salesforceセキュリティの習得：権限セットによるアクセス制御の徹底解説

背景と適用シナリオ

Salesforceプラットフォームにおけるセキュリティモデルは、多層的かつ堅牢に設計されています。その基盤となるのは、Organization-Wide Defaults (組織の共有設定)、Role Hierarchy (ロール階層)、Sharing Rules (共有ルール)、そしてProfile (プロファイル)です。これらが連携し、誰がどのデータにアクセスできるかを厳密に制御します。特にProfileは、ユーザの基本的な権限（オブジェクトへのアクセス権、項目レベルセキュリティ、システム権限など）を定義する中心的な役割を担います。

しかし、従来のProfileベースの権限管理には一つの大きな制約がありました。それは、「一人のユーザは一つのProfileしか持つことができない」という点です。これにより、ビジネス要件が複雑化するにつれて、わずかな権限の違いのために多数のProfileを作成・管理せざるを得ない「プロファイルの乱立」という問題が発生しがちでした。例えば、営業部門のユーザは全員同じ「営業担当」Profileに属していても、その中の一部のユーザにだけ「レポートのエクスポート」権限や、特定のカスタムオブジェクトへの編集権限を付与したい場合、新しいProfileを作成する必要がありました。これでは管理が煩雑になり、セキュリティリスクも増大します。

この課題を解決するために登場したのが、Permission Sets (権限セット)です。Permission Setsは、ユーザのProfileで定義された基本権限に追加で権限を付与するための、柔軟で再利用可能なコンポーネントです。ユーザは一つのProfileに加えて、複数のPermission Setsを割り当てることができます。これにより、「最小権限の原則」に基づいたスリムな基本Profileを作成し、必要に応じてPermission Setsで権限を拡張していくという、モダンで効率的な権限管理モデルを実現できます。

さらに、その進化形としてPermission Set Groups (権限セットグループ)も提供されています。これは複数のPermission Setsを一つのグループにまとめる機能で、職務や役割に基づいて権限をバンドル化し、ユーザへの割り当てをさらに簡素化します。

主な適用シナリオ

一時的な権限付与：プロジェクト期間中だけ特定のユーザに開発者コンソールへのアクセス権を付与するなど、期間限定のアクセス権を管理する。
特定機能へのアクセス許可：同じ部署・Profileのユーザの中で、一部のマネージャクラスのユーザにのみ「データローダを使用したエクスポート」や「設定の参照」といった特定のシステム権限を付与する。
インテグレーションユーザの権限管理：外部システムと連携するためのAPI専用ユーザに対し、必要最低限のオブジェクトや項目へのアクセス権をPermission Setで厳密に定義する。
新機能の段階的ロールアウト：新しいカスタムアプリケーションや機能を、まず一部のパイロットユーザにPermission Setを割り当てて公開し、フィードバックを得ながら対象を拡大していく。

原理説明

Permission Setsの基本原理は「加算的権限モデル」です。ユーザが最終的に持つ権限は、割り当てられたProfileの権限と、すべてのPermission Setsの権限を合算したものになります。数式で表すと以下のようになります。

ユーザの総権限 = Profileの権限 ∪ Permission Set Aの権限 ∪ Permission Set Bの権限 ...

重要なのは、Permission Setsは権限を追加することしかできず、Profileで許可されている権限を制限することはできないという点です。例えば、Profileで取引先オブジェクトへの参照アクセスが許可されていないユーザに、取引先への編集権限を含むPermission Setを割り当てても、そのユーザは取引先を参照・編集することはできません。まずProfileでベースとなる参照権限を許可する必要があります。

Permission Sets と Permission Set Groups

Permission Set (権限セット)

Permission Setは、特定のタスクや機能の実行に必要な権限の集合体です。以下のような多様な権限設定を含めることができます。

オブジェクト権限：標準オブジェクトやカスタムオブジェクトに対する参照、作成、編集、削除（CRUD）権限。
Field-Level Security (項目レベルセキュリティ)：特定の項目に対する参照アクセス権と編集アクセス権。
ユーザ権限：「APIの有効化」「レポートのエクスポート」「すべてのデータの参照」といったシステム全体に関わる広範な権限。
Apexクラスアクセス：特定のApexクラスの実行権限。
Visualforceページアクセス：特定のVisualforceページへのアクセス権。
カスタム権限：Apexやフローなどで参照できる、組織独自のカスタムアクセス権限。

Permission Set Group (権限セットグループ)

Permission Set Groupは、その名の通り、複数のPermission Setsを論理的に束ねるためのコンテナです。例えば、「営業マネージャ」という役割に必要な権限が「レポート管理」「契約承認」「目標設定」という3つのPermission Setsに分割されている場合、これらを「営業マネージャ権限グループ」という一つのPermission Set Groupにまとめることができます。管理者はユーザにこのグループを一つ割り当てるだけで、関連するすべての権限を一度に付与できます。

Permission Set Groupの最も強力な機能の一つにMuting (無効化)があります。グループに含めたPermission Set内の特定の権限を、そのグループ経由での割り当てに限り無効化することができます。これにより、既存のPermission Setを複製・変更することなく、特定の役割に合わせて権限を微調整することが可能になります。例えば、「全社共通レポート権限」というPermission Setに「レポートのエクスポート」権限が含まれているが、「インターン」向けのPermission Set Groupではこの権限を無効にしたい、といった場合に非常に有効です。

サンプルコード

Permission SetsやPermission Set Groupsの割り当ては、通常SalesforceのUIから行いますが、ユーザ作成プロセスの自動化や一括更新など、プログラムで制御したいケースも多くあります。ここではApexを使用してユーザにPermission Setを割り当てるコード例を紹介します。割り当てはPermissionSetAssignmentオブジェクトのレコードを作成することで実現します。

特定のPermission Setをユーザに割り当てる

この例では、API参照名が `Sales_Manager_Tools` のPermission Setを、特定のユーザに割り当てます。

// 割り当て対象のユーザとPermission Setを特定する
User targetUser = [SELECT Id FROM User WHERE Username = 'testuser@example.com' LIMIT 1];
PermissionSet ps = [SELECT Id FROM PermissionSet WHERE Name = 'Sales_Manager_Tools' LIMIT 1];

// PermissionSetAssignmentオブジェクトの新しいインスタンスを作成する
// AssigneeId にはユーザのIDを、PermissionSetIdには権限セットのIDを指定する
PermissionSetAssignment psa = new PermissionSetAssignment(
    AssigneeId = targetUser.Id,
    PermissionSetId = ps.Id
);

try {
    // DML操作を実行して割り当てを行う
    insert psa;
    System.debug('Permission Setの割り当てに成功しました。User ID: ' + targetUser.Id);
} catch (DmlException e) {
    // エラー処理：ユーザが非アクティブ、ライセンスの不一致、重複割り当てなどの場合に発生する可能性がある
    System.debug('Permission Setの割り当てに失敗しました。エラー: ' + e.getMessage());
}

複数のユーザにPermission Setを一括で割り当てる (Bulk処理)

ガバナ制限を遵守するため、複数のユーザに割り当てる際は必ずリストを使用して一括処理を行います。

// 一括割り当て対象のユーザのリストを取得
List<User> targetUsers = [SELECT Id FROM User WHERE IsActive = true AND Profile.Name = '営業担当'];
// 割り当てるPermission SetのIDを取得
Id permissionSetId = [SELECT Id FROM PermissionSet WHERE Name = 'Sales_Order_Management'].Id;

// 割り当て情報を格納するためのリストを初期化
List<PermissionSetAssignment> assignmentsToInsert = new List<PermissionSetAssignment>();

for (User u : targetUsers) {
    assignmentsToInsert.add(new PermissionSetAssignment(
        AssigneeId = u.Id,
        PermissionSetId = permissionSetId
    ));
}

// リストが空でないことを確認してからDML操作を実行
if (!assignmentsToInsert.isEmpty()) {
    try {
        // 1回のDMLコールで全ての割り当てを実行
        Database.SaveResult[] saveResults = Database.insert(assignmentsToInsert, false); // allOrNoneをfalseに設定

        // DMLの結果を1件ずつ確認
        for (Database.SaveResult sr : saveResults) {
            if (sr.isSuccess()) {
                System.debug('ID ' + sr.getId() + ' の割り当てに成功しました。');
            } else {
                // 失敗した割り当てのエラーをログに出力
                for (Database.Error err : sr.getErrors()) {
                    System.debug('割り当てに失敗しました。エラー: ' + err.getStatusCode() + ': ' + err.getMessage());
                    System.debug('対象項目: ' + err.getFields());
                }
            }
        }
    } catch (DmlException e) {
        System.debug('一括割り当て中に予期せぬエラーが発生しました。' + e.getMessage());
    }
}

注：PermissionSetAssignmentのPermissionSetId項目には、Permission SetのIDだけでなく、Permission Set GroupのIDも指定できます。したがって、Permission Set Groupを割り当てる場合も、上記のコードでPermissionSetをPermissionSetGroupに置き換えてクエリするだけで、同様のロジックを適用できます。

注意事項

権限 (Permissions)

Permission Setの割り当てや作成を行うには、実行ユーザ自身に「ユーザの管理」および「権限セットの割り当て」システム権限が必要です。これらの権限がないユーザがコードを実行しようとすると、セキュリティエラーが発生します。

API制限とガバナ制限 (API and Governor Limits)

Apex経由でPermissionSetAssignmentレコードを操作する際は、Salesforceのガバナ制限が適用されます。特に、トリガやバッチ処理内で大量のユーザに割り当てを行う場合は、SOQLクエリの発行回数（100回）やDMLステートメントの発行回数（150回）に注意が必要です。必ずサンプルコードで示したように、リストを使った一括処理（Bulkification）を徹底してください。

ライセンスに関する考慮事項 (License Considerations)

最も重要な注意点の一つです。各ユーザに割り当てられているUser License (ユーザライセンス)によって、利用可能な機能や権限の上限が定められています。例えば、「Salesforce」ライセンスを持つユーザと、「Salesforce Platform」ライセンスを持つユーザでは、利用できる標準オブジェクトやシステム権限が異なります。ユーザのライセンスがサポートしていない権限（例：「商談の参照」権限をPlatformライセンスユーザに付与しようとする）を含むPermission Setを割り当てようとすると、DMLエラー（FIELD_INTEGRITY_EXCEPTIONなど）が発生し、割り当ては失敗します。割り当てを自動化する際は、対象ユーザのライセンスタイプを事前に確認するロジックを組み込むことが推奨されます。

データアクセスとの違い (Difference from Data Access Control)

Permission Setは、あくまでオブジェクトや項目といった「メタデータ」レベルでのアクセス権を制御するものです。これに対して、個々の「レコード」に誰がアクセスできるかは、組織の共有設定（OWD）、ロール階層、共有ルールによって制御されます。例えば、あるユーザにPermission Setで取引先オブジェクトへの「編集」権限を付与しても、そのユーザがロール階層や共有ルールによってアクセスできない特定の取引先レコードを編集することはできません。権限設計を行う際は、この二つのセキュリティレイヤを区別して考えることが不可欠です。

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

Permission SetsとPermission Set Groupsは、Salesforceの権限管理を柔軟かつスケーラブルにするための強力なツールです。Profileの乱立を防ぎ、管理工数を削減しながら、セキュリティを強化することができます。

以下に、Permission Setsを効果的に活用するためのベストプラクティスを挙げます。

最小権限の原則 (Principle of Least Privilege) に従う：
Profileは、全社共通の最低限のアクセス権のみを持つように設計します。これを「ベースラインプロファイル」とし、追加の権限はすべてPermission Setsで付与するようにします。これにより、ユーザの職務に本当に必要な権限だけを正確に与えることができます。
Permission Set Groupsを積極的に活用する：
個々のPermission Setを直接ユーザに割り当てるのではなく、職務や役割（例：営業担当、マーケティングマネージャ、システム管理者補助）に基づいてPermission Set Groupを作成し、グループ単位で割り当てます。これにより、誰がどのような権限を持っているかが一目瞭然となり、管理が大幅に簡素化されます。
一貫性のある命名規則を設ける：
Permission SetやGroupには、その目的が明確にわかるような命名規則を適用します。例えば、[機能/オブジェクト]_[アクセスレベル]_[権限タイプ]（例：FSL_Dispatcher_CRUD_PS, Sales_Manager_Analytics_PSG）のような形式です。これにより、後から見返した際に権限の内容を推測しやすくなります。
割り当てプロセスを自動化する：
ユーザの役職や部署、特定のチェックボックスフィールドの値に基づいて、FlowやApexトリガを使い、Permission Set Groupの割り当て・解除を自動化します。これにより、手動での割り当てミスを防ぎ、入社・異動・退職時のプロビジョニングプロセスを効率化できます。
Muting機能を活用して重複を避ける：
似ているが少しだけ異なる権限セットが必要な場合、既存のPermission Setをコピーして新しいものを作るのではなく、共通のPermission SetをPermission Set Groupに入れ、Muting機能で不要な権限を無効化することを検討します。これにより、管理対象となるPermission Setの数を最小限に抑えることができます。

これらのベストプラクティスを実践することで、Salesforce組織のセキュリティを堅牢に保ちながら、変化し続けるビジネス要件に迅速に対応できる、持続可能な権限管理基盤を構築することが可能になります。

にゃんこのSalesforce日記

このブログを検索

Salesforceリード管理のマスター：アーキテクトのための技術ガイド