Salesforce トランザクションセキュリティポリシー：リアルタイムイベント監視と保護の徹底解説

背景と適用シナリオ

Salesforceは、企業の最も重要なデータである顧客情報を管理するためのプラットフォームです。データのセキュリティを確保することは、あらゆる組織にとって最優先事項です。Salesforceは多層的なセキュリティ機能を提供していますが、その中でも特に動的でリアルタイムな脅威に対応するための強力なツールが Transaction Security Policies (トランザクションセキュリティポリシー) です。

Transaction Security Policiesは、Real-Time Event Monitoring (リアルタイムイベント監視) の一部であり、Salesforce組織内での特定のユーザーイベントをリアルタイムで監視し、定義された条件に基づいてアクション（アクセスのブロックや多要素認証の要求など）を自動的に実行するフレームワークです。これにより、データ漏洩の防止、コンプライアンス要件の遵守、異常なユーザー行動の検知などが可能になります。

具体的な適用シナリオとしては、以下のようなケースが考えられます。

大量データのエクスポート防止: あるユーザーが一度に1,000件を超えるリードデータをレポートからエクスポートしようとした場合に、その操作をブロックする。
API経由のデータ漏洩対策: 短時間に大量のAPIクエリを実行する異常な行動を検知し、セッションを強制的に終了させる。
機密情報へのアクセス制御: 特定の機密性の高いレポート（例：財務レポート）にアクセスしようとした際に、追加の認証として多要素認証（MFA）を要求する。
信頼できないIPからのアクセス制限: 企業のIPアドレス範囲外からログインしたユーザーが、特定のオブジェクトにアクセスしようとした場合に操作をブロックする。
リストビューからのエクスポート制御: 取引先責任者のリストビューからデータをエクスポートする操作を禁止する。

これらのシナリオは、静的なプロファイルや権限セットだけでは対応が難しい、ユーザーの「行動」に基づいたセキュリティ制御を実現します。Transaction Security Policiesは、こうした動的なセキュリティ要件に応えるための重要なソリューションです。

原理説明

Transaction Security Policiesの動作原理は、「イベント」「ポリシー」「アクション」の3つの主要なコンポーネントに基づいています。

1. イベント (Event):
ユーザーがSalesforce内でレポートを実行したり、APIクエリを投げたり、データをエクスポートしたりすると、Salesforceプラットフォームは対応するイベントを生成します。これらのイベントは Real-Time Event Monitoring (リアルタイムイベント監視) オブジェクトとして表現されます。例えば、以下のようなイベントオブジェクトがあります。

ReportEvent: ユーザーがレポートを実行、またはエクスポートした際に発生。
ApiEvent: SOAP, REST, Bulk APIなど、API経由でレコードが照会された際に発生。
ListViewEvent: リストビューでデータを表示、またはエクスポートした際に発生。
LoginEvent: ユーザーがログインした際に発生。

2. ポリシー (Policy):
ポリシーは、特定のイベントが発生した際に実行されるルールの集合です。各ポリシーは特定のイベントに紐づけられます。ポリシーの評価ロジックは、2つの方法で実装できます。

標準ポリシー (Standard Policies): Salesforceが提供するCondition Builderを使い、コーディングなしでクリック操作のみでポリシーを作成できます。シンプルな条件（例：「レポートからエクスポートされた行数が500を超える」など）に適しています。
Apexベースのカスタムポリシー (Custom Policies via Apex): より複雑で動的な条件を評価するために、Apexクラスを作成します。このApexクラスは TxnSecurity.PolicyCondition インターフェースを実装する必要があり、組織の独自のビジネスロジックに基づいて詳細な制御が可能になります。本記事では、このApexベースのポリシーに焦点を当てます。

3. アクション (Action):
ポリシーの条件が満たされた（Apexクラスがtrueを返した）場合、事前に定義されたアクションが実行されます。主なアクションは以下の通りです。

Block: 該当するイベント（操作）を完全にブロックします。ユーザーにはエラーメッセージが表示され、操作は完了しません。
TwoFactorAuthentication: ユーザーに追加の認証（多要素認証）を要求します。認証に成功すれば、操作は続行できます。これは、通常はMFAを要求しないセッションでも、特定の重要な操作に対してセキュリティを強化したい場合に有効です。
NoAction (Allow): 条件が満たされなかった場合、何もアクションは実行されず、ユーザーの操作は通常通り許可されます。

この「イベント発生 → ポリシー評価 → アクション実行」という一連の流れにより、Salesforceはリアルタイムでユーザーの行動を監視し、セキュリティリスクを未然に防ぐことができるのです。

実装例

ここでは、最も一般的なシナリオの一つである「リードオブジェクトに対する大量のレポートエクスポートをブロックする」というカスタムポリシーをApexで実装する例を紹介します。このポリシーは、一度に2,000件を超えるリード、または合計で10,000件を超えるデータをエクスポートしようとした場合に操作をブロックします。

このコードはSalesforceの公式ドキュメントで提供されているサンプルに基づいています。

Apexクラスの作成

まず、ポリシーのロジックを実装するApexクラスを作成します。このクラスは TxnSecurity.PolicyCondition インターフェースを実装する必要があります。

global class LeadDataExportCondition implements TxnSecurity.PolicyCondition {

    /**
     * このメソッドは、トランザクションセキュリティポリシーがトリガーされるたびに呼び出されます。
     * @param event SObject型。どのイベントが発生したかに関する情報が含まれています。
     *              この例では、ReportEventオブジェクトの情報を期待しています。
     * @return Boolean。trueを返すとポリシーで定義されたアクション（例：ブロック）が実行されます。
     *                 falseを返すと何も実行されません。
     */
    public boolean evaluate(SObject event) {
        // イベントのタイプをチェックします。このポリシーはReportEventにのみ適用されます。
        if (event instanceof ReportEvent) {
            ReportEvent reportEvent = (ReportEvent) event;

            // SOQLクエリを使用して、このレポートエクスポートに関連するポリシーの詳細を取得します。
            // これにより、しきい値などをカスタム設定やカスタムメタデータで管理できるようになります。
            // ここでは簡潔にするため、ハードコードされた値を使用します。
            Profile p = [SELECT Name FROM Profile WHERE Id = :reportEvent.UserId];

            // システム管理者プロファイルの場合は、このポリシーの評価をスキップします。
            if (p.Name == 'System Administrator') {
                return false;
            }

            // ReportEventのQueriedEntitiesフィールドをチェックし、
            // レポートにLeadオブジェクトが含まれているかどうかを確認します。
            // 含まれていない場合は、ポリシーの対象外です。
            if (reportEvent.QueriedEntities.contains('Lead')) {
                // RowsProcessedフィールドは、エクスポートまたは表示された行数を示します。
                // この値が定義したしきい値を超えているか評価します。
                if (reportEvent.RowsProcessed > 2000) {
                    // しきい値を超えているため、trueを返し、ポリシーのアクション（ブロック）をトリガーします。
                    return true;
                }
            }
        }
        
        // 上記のどの条件にも一致しない場合は、操作を許可します。
        return false;
    }
}

ポリシーの有効化

Apexクラスを作成した後、Salesforceの設定画面でポリシーを有効化する必要があります。

[設定] から、[クイック検索] ボックスに「トランザクションセキュリティ」と入力し、[トランザクションセキュリティポリシー] を選択します。
[新規] ボタンをクリックします。
[Apex] を選択し、[次へ] をクリックします。
以下の情報を入力します。
- ポリシー名: リードの大量エクスポートをブロック
- Apex クラス: 上記で作成した `LeadDataExportCondition` を選択します。
- イベント: `レポートイベント` を選択します。
- アクション: `ブロック` を選択します。
- 有効: このチェックボックスをオンにします。
[保存] をクリックします。

これで、システム管理者以外のユーザーが2,000件を超えるリードを含むレポートを実行またはエクスポートしようとすると、操作が自動的にブロックされるようになります。

注意事項

Transaction Security Policiesを実装・運用する際には、いくつかの重要な点に注意する必要があります。

権限

ポリシーを作成および管理するには、「アプリケーションのカスタマイズ」および「すべてのデータの参照」権限が必要です。また、この機能を有効化するためには、システム管理者が「トランザクションセキュリティポリシーを管理」のユーザー権限を持っている必要があります。

ガバナ制限とパフォーマンス

Apexベースのポリシーは、標準のApexガバナ制限（SOQLクエリの数、CPU時間など）の中で実行されます。ポリシーの評価ロジックは、イベントが発生するたびに同期的に実行されるため、非常に効率的で軽量である必要があります。複雑なSOQLクエリやDML操作、コールアウトなどをポリシー評価ロジック内に含めることは避けるべきです。パフォーマンスの低いコードは、ユーザーの操作に遅延を引き起こし、ユーザーエクスペリエンスを損なう可能性があります。

サポートされるイベント

Transaction Security Policiesが監視できるイベントは限られています。すべてのユーザー操作がイベントを生成するわけではありません。どのイベントが利用可能かについては、Salesforceの公式ドキュメントである Real-Time Event Monitoring Developer Guide を常に確認してください。要件に合うイベントが存在しない場合、この機能は利用できません。

エラーハンドリング

Apexクラス内でハンドルされない例外が発生した場合、ポリシーはフェイルセーフとして動作し、デフォルトでイベントをブロックします。これは、セキュリティ上の脆弱性を防ぐための仕様ですが、バグのあるコードが本番環境にデプロイされると、意図せず広範囲のユーザー操作をブロックしてしまう危険性があります。そのため、Apexクラス内では必ず `try-catch` ブロックを使用して例外を適切に処理し、予期せぬブロックを避けるように実装することが強く推奨されます。

テスト

本番環境にデプロイする前に、必ずSandbox環境でポリシーを徹底的にテストしてください。様々なユーザープロファイルやシナリオでテストを行い、正当な業務操作を誤ってブロックしないことを確認することが不可欠です。特に、システムインテグレーションやデータローディングなど、APIを多用するプロセスに影響を与えないかどうかの確認は重要です。

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

Salesforce Transaction Security Policiesは、組織のセキュリティ体制をプロアクティブに強化し、コンプライアンス要件を満たすための非常に強力なツールです。リアルタイムでユーザーの行動を監視し、脅威となりうる操作を自動的に阻止することで、データ漏洩のリスクを大幅に低減させることができます。

この機能を最大限に活用するためのベストプラクティスを以下に示します。

小さく始める: 最初から複雑なポリシーを構築するのではなく、まずは一つのシンプルなユースケース（例：特定のレポートからのエクスポートブロック）から始め、徐々に対象を拡大していくことをお勧めします。
効率的なApexコードを記述する: ポリシーのパフォーマンスはユーザーエクスペリエンスに直結します。Apexロジックは可能な限りシンプルに保ち、データベースへのアクセスを最小限に抑えてください。しきい値などの設定値は、ハードコードするのではなく、カスタムメタデータやカスタム設定に格納することで、コードを変更せずにポリシーの挙動を調整できるようになります。
管理者への通知を実装する: ポリシーがトリガーされた（ユーザーがブロックされた）際に、カスタム通知やEmailアラートなどを利用してセキュリティ管理者に通知する仕組みを構築することで、インシデントの早期発見と対応が可能になります。
定期的なレビューと棚卸し: ビジネス要件や組織のセキュリティポリシーは変化します。作成したTransaction Security Policiesが現状に適合しているか、定期的に見直しを行い、不要になったポリシーは無効化・削除してください。
他のセキュリティ機能との組み合わせ: Transaction Security Policiesは万能ではありません。Salesforce Shield Platform Encryptionによる保存データの暗号化、Field Audit Trailによるデータ変更履歴の長期保存、Identity Verification (MFA)によるログインセキュリティの強化など、他のセキュリティ機能と組み合わせることで、多層的な防御を実現できます。

Transaction Security Policiesを正しく理解し、計画的に導入することで、Salesforceプラットフォームをさらに安全かつ信頼性の高いものにすることが可能です。

にゃんこのSalesforce日記

このブログを検索

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