トランザクションセキュリティポリシーによる組織のセキュリティ強化：アーキテクト向けガイド

背景と適用シナリオ

Salesforceアーキテクトとして、我々の責務は単に機能的なソリューションを設計するだけでなく、組織のデータとプロセスを保護するための堅牢なセキュリティフレームワークを構築することにあります。Salesforceが提供する多層的なセキュリティモデルの中で、Transaction Security Policies (トランザクションセキュリティポリシー) は、リアルタイムでの脅威検知と防止を実現するための極めて強力なツールです。

従来のアクセス制御（プロファイル、権限セット、共有ルールなど）が「誰が何にアクセスできるか」という静的な権限を定義するのに対し、トランザクションセキュリティポリシーは「誰が、いつ、どこで、どのようにデータにアクセスしているか」という動的なコンテキストを監視し、ポリシー違反の可能性がある操作をリアルタイムで阻止します。これは、内部脅威やアカウントの乗っ取りなど、従来の静的制御だけでは防ぎきれないリスクに対処する上で不可欠です。

この機能は、Salesforce Shield の一部である Real-Time Event Monitoring (リアルタイムイベントモニタリング) を基盤としています。特定のユーザーイベントが発生した瞬間にそれを捕捉し、定義されたポリシーに基づいて即座にアクションを実行します。

具体的な適用シナリオ

大量データのエクスポート防止: 悪意のある、あるいは不注意なユーザーが、一度に1,000件以上のリードや取引先責任者を含むレポートをエクスポートしようとした場合に、その操作をブロックする。
機密データへのAPIアクセス監視: カスタムオブジェクト `Financial_Data__c` のような機密情報を含むオブジェクトに対して、予期せぬユーザーやアプリケーションがAPI経由でクエリを実行しようとした場合に、管理者に通知を送信し、必要であればセッションを終了させる。
代理ログインの制御: システム管理者が他のユーザーとしてログイン (LoginAs) する操作を特定のプロファイルに限定し、それ以外の管理者が試みた場合はブロックする。
セッションハイジャックの検知: ユーザーのセッション情報（IPアドレスなど）に不審な変更が検知された場合に、多要素認証 (MFA) を要求するか、強制的にセッションを終了させる。

これらのシナリオは、データ漏洩のリスクを最小限に抑え、コンプライアンス要件を遵守し、組織全体のセキュリティ体制を強化するために、アーキテクトが設計に組み込むべき重要な要素です。

原理説明

トランザクションセキュリティポリシーのアーキテクチャは、3つの主要なコンポーネントで構成されています。

Event (イベント): ユーザーまたはシステムがSalesforce内で行う特定のアクションです。例えば、`ReportEvent` (レポート実行・エクスポート)、`ApiEvent` (APIクエリ)、`LoginEvent` (ログイン試行) などがこれにあたります。これらのイベントはリアルタイムイベントモニタリングストリームを通じて捕捉されます。
Policy (ポリシー): 捕捉されたイベントを評価するためのロジックや条件の集合です。ポリシーがトリガーされると、イベントの詳細情報（実行したユーザー、対象オブジェクト、クエリされたレコード数など）を分析し、それがセキュリティ上の脅威に該当するかどうかを判断します。
Action (アクション): ポリシーの条件が満たされた場合に実行される処理です。主なアクションには以下のものがあります。
- Block: イベントの実行を完全に阻止します。
- TwoFactorAuthentication: ユーザーに追加の認証（MFA）を要求します。操作を続行するには、認証を完了させる必要があります。
- FreezeUser: ユーザーアカウントを凍結します。
- EndSession: ユーザーの現在のセッションを強制的に終了させます。
- (通知): アクションは実行せず、管理者にメールやChatterで通知のみ行います。

ポリシーの実装方法には、宣言的なアプローチとプログラム的なアプローチの2種類があります。

宣言的ポリシー (Condition Builder)

Condition Builder (条件ビルダー) を使用して、コードを書かずにポリシーを作成する方法です。特定のイベントを選択し、GUIを通じて条件（例：「レポートからエクスポートされた行数が1000を超える」かつ「ユーザープロファイルが 'System Administrator' ではない」）を定義します。シンプルでメンテナンスが容易なため、アーキテクトとしては、まずこの方法で要件を満たせないかを検討すべきです。

Apexベースのカスタムポリシー

より複雑で動的なロジックが必要な場合、Apexを使用してカスタムポリシーを作成します。これにより、最大限の柔軟性が得られます。例えば、関連オブジェクトの情報をクエリしたり、カスタムメタデータに基づいて閾値を動的に変更したり、特定のビジネスロジックに基づいてアクションを決定したりすることが可能です。

Apexでカスタムポリシーを作成するには、`TxnSecurity.EventCondition` インターフェースを実装したグローバルなApexクラスを作成します。このクラスには `handleEvent` というメソッドを実装する必要があり、このメソッドがイベント発生のたびに呼び出されます。`handleEvent` メソッドは、イベントのデータを評価し、ポリシーに違反するかどうかを判断して `TxnSecurity.PolicyCondition` オブジェクトを返します。

サンプルコード

ここでは、最も一般的なシナリオの一つである「レポートからの大量データエクスポートのブロック」を実装するApexベースのカスタムポリシーの例を示します。このポリシーは、一度のエクスポートで2,000件を超えるレコード、または一度のレポート実行で10,000件を超えるレコードが返された場合に操作をブロックします。

このコードはSalesforceの公式ドキュメントに基づいています。

Apexクラス: LargeReportExportCondition.cls

global class LargeReportExportCondition implements TxnSecurity.EventCondition {

    public TxnSecurity.PolicyCondition evaluate(SObject event) {
        // handleEventメソッドは非推奨のため、新しいevaluateメソッドを使用します。
        // イベントの具体的な型に応じて処理を分岐します。
        switch on event {
            // ReportEvent (レポートイベント) の場合
            when ReportEvent reportEvent {
                // Profile オブジェクトと User オブジェクトをクエリして、
                // イベントを実行したユーザーが CEO かどうかを確認します。
                Profile p = [SELECT Name FROM Profile WHERE Name = 'System Administrator'];
                User u = [SELECT ProfileId FROM User WHERE Id = :reportEvent.UserId];

                // ユーザーがシステム管理者プロファイルの場合、ポリシーはトリガーされません。
                // CEOや特定の権限を持つユーザーは大量エクスポートを許可するなどの例外処理を実装します。
                if (u.ProfileId == p.Id) {
                    return new TxnSecurity.PolicyCondition(false, 'Not a bad guy, just a sysadmin');
                }

                // イベントがレポートのエクスポートであり、かつエクスポートされた行数が2000を超える場合
                if (reportEvent.Operation == 'Export' && reportEvent.NumberOfRows > 2000) {
                    // ポリシーの条件が満たされたため、true を返してアクション（ブロック）を実行します。
                    return new TxnSecurity.PolicyCondition(true, 'Really big report export');
                }

                // レポートの実行（エクスポートではない）で、返された行数が10000を超える場合
                if (reportEvent.NumberOfRows > 10000) {
                    // ポリシーの条件が満たされたため、true を返してアクション（ブロック）を実行します。
                    return new TxnSecurity.PolicyCondition(true, 'Really big report run');
                }
            }
            // その他のイベントタイプの場合は何もしない
            when null {
                // null チェック
                return new TxnSecurity.PolicyCondition(false, 'Event is null');
            }
            when else {
                // ReportEvent 以外は無視
                return new TxnSecurity.PolicyCondition(false, 'Not a report event');
            }
        }
        // 上記のどの条件にも一致しない場合は、ポリシーをトリガーしません。
        return new TxnSecurity.PolicyCondition(false, 'Looks good');
    }
}

コードの解説

`global class ... implements TxnSecurity.EventCondition`: トランザクションセキュリティポリシーとして認識されるために、このインターフェースを実装する必要があります。
`evaluate(SObject event)`: このメソッドがポリシーの心臓部です。イベントが発生するたびにSalesforceによって同期的に呼び出されます。引数の `SObject` には、`ReportEvent` や `ApiEvent` などのイベントオブジェクトが渡されます。
`switch on event`: `event` の具体的な型に応じて処理を分岐させています。これにより、一つのクラスで複数のイベントタイプに対応可能です。ここでは `ReportEvent` のみを処理しています。
`Profile p = [SELECT ...]`: Apexコード内ではSOQLクエリを実行できます。ただし、パフォーマンスへの影響を最小限に抑えるため、非常にシンプルかつ効率的なクエリに限定すべきです。ここでは、特定のプロファイル（この例ではシステム管理者）をポリシーの対象外とするためのロジックを実装しています。
`reportEvent.Operation == 'Export'`: `ReportEvent` オブジェクトの `Operation` 項目をチェックすることで、ユーザーがレポートを閲覧しただけなのか、それともデータをエクスポートしたのかを区別できます。
`reportEvent.NumberOfRows > 2000`: イベントオブジェクトのプロパティ（この場合はエクスポートされた行数）を評価し、定義した閾値と比較します。
`return new TxnSecurity.PolicyCondition(true, '...');`: `PolicyCondition` の最初の引数が `true` の場合、ポリシーがトリガーされ、設定されたアクション（例：ブロック）が実行されます。`false` の場合は何も起こりません。2番目の引数はデバッグ用のメッセージです。

このApexクラスを作成した後、[設定] > [トランザクションセキュリティポリシー] に移動し、新しいポリシーを作成してこのApexクラスを関連付けることで、ポリシーが有効になります。

注意事項

トランザクションセキュリティポリシーは強力な機能ですが、アーキテクトとしてその影響と制約を深く理解しておく必要があります。

権限

ポリシーを作成・管理するには、「トランザクションセキュリティの管理」権限が必要です。また、ポリシー内のApexコードが他のオブジェクトのデータにアクセスする場合、実行コンテキストのユーザーがそのデータにアクセスするための「すべてのデータの参照」権限を持っているか、慎重な検討が必要です。

パフォーマンスへの影響

最も重要な注意点です。トランザクションセキュリティポリシーは、対象となるすべてのイベントに対して同期的に実行されます。つまり、ポリシーのApexコードの実行が完了するまで、ユーザーの操作（レポートのエクスポートなど）は待機状態になります。

非効率なApexコード（複雑なSOQLクエリ、ループ内のクエリ、コールアウトなど）を実装すると、組織全体のパフォーマンスが著しく低下し、ユーザーエクスペリエンスを損なう原因となります。CPUガバナ制限も通常のApexトランザクションより厳しく設定されています。したがって、Apexコードは極めて軽量かつ高速に実行されるように設計しなければなりません。

エラー処理

Apexポリシー内でハンドルされない例外が発生した場合、Salesforceはフェイルセーフの原則に基づき、デフォルトでそのイベントをブロックします。これは、セキュリティ上の脆弱性を防ぐための仕様ですが、コードのバグが原因で正規のユーザー操作が意図せずブロックされてしまうリスクを意味します。堅牢な `try-catch` ブロックを実装し、例外発生時にも意図した通りの動作（例えば、デフォルトで許可するなど）を保証することが不可欠です。

ライセンス

トランザクションセキュリティポリシーのフレームワーク自体は多くのSalesforce Editionで利用可能ですが、ポリシーが依存するリアルタイムイベントの多くは、Salesforce Shield または Real-Time Event Monitoring のアドオンライセンスが必要です。特に `ApiEvent` や `ReportEvent` などの価値の高いイベントはライセンス対象となります。ソリューションを設計する際には、必要なライセンスがクライアントに存在するかを必ず確認してください。

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

トランザクションセキュリティポリシーは、Salesforce組織のセキュリティを事後対応からリアルタイムの予防へとシフトさせるための、アーキテクトにとっての重要な設計要素です。正しく実装すれば、データ漏洩のリスクを大幅に低減し、コンプライアンスを強化することができます。

アーキテクトとしてのベストプラクティス

宣言的なアプローチを優先する: 要件が許す限り、Condition Builderを使用してください。メンテナンス性が高く、パフォーマンスリスクも低減できます。Apexは、宣言的な方法では実現不可能な複雑なロジックが必要な場合にのみ使用します。
Apexポリシーのコードを最適化する: Apexコードは、単一責任の原則に従い、シンプルかつ軽量に保ちます。DML操作や外部コールアウトは絶対に避け、SOQLクエリは最小限かつセレクティブなものにします。
段階的な展開: 新しいポリシーをいきなり全社に展開するのではなく、まずは特定のプロファイルやサンドボックス環境で十分にテストします。ポリシーが意図した通りに動作し、パフォーマンスに悪影響を与えないことを確認してから、段階的に対象を拡大します。
明確なユーザーコミュニケーション: ユーザーの操作がブロックされた際に表示されるメッセージをカスタマイズし、「なぜブロックされたのか」「次に何をすべきか」を明確に伝えます。これにより、ヘルプデスクへの問い合わせを削減し、ユーザーの混乱を防ぎます。
ポリシーの実行を監視する: `TransactionSecurityPolicy` イベント自体もイベントモニタリングの対象です。定期的にログを確認し、どのポリシーが、いつ、どれくらいの頻度でトリガーされているかを監視し、チューニングの必要性を判断します。
多層防御の一部として位置づける: トランザクションセキュリティポリシーは万能ではありません。プロファイル、権限セット、暗号化 (Shield Platform Encryption)、イベントモニタリングなどの他のセキュリティ機能と組み合わせ、多層的な防御戦略の一部として設計に組み込むことが重要です。

これらの原則に従うことで、Salesforceアーキテクトは、パフォーマンスとユーザーエクスペリエンスを犠牲にすることなく、組織のセキュリティを次のレベルへと引き上げることができます。

にゃんこのSalesforce日記

このブログを検索