2026.07.08

セールスフォース

Salesforce

Salesforce セキュリティ：不審な挙動をブロック＆検知！

近年、企業のデジタルトランスフォーメーション（DX）が加速し、AIを最大限活用するべく、Salesforceは単なる顧客管理の枠を超え、全社のデータが集約される最重要プラットフォームへと進化しています。
一方で、システムへの攻撃手法も高度化しており、セキュリティ対策は企業の信頼性を左右する死活問題となっています。

Salesforceには「IPアドレスによるログイン制限」や「ログイン時の多要素認証（MFA）」など、セキュリティを強化する設定が多く備わっています。
では、以下のようなケースを考えてみてください。

VPNの脆弱性を突いて社内ネットワークに侵入されたら？
アカウントを持つユーザーが悪意を持ってデータを持ち出したら？

このようなケースでは、従来のセキュリティ設定のみでは不十分な可能性があります。
気が付いたらデータが持ち出された後だった、なんてことになりかねません。
不審な動きを検知し、阻止するにはどうしたらいいでしょうか？

Salesforceには、大量のデータの抽出など、特定の操作を検知・ブロックできる「トランザクションセキュリティポリシー」という機能があるのをご存じですか？

本記事では、トランザクションセキュリティポリシーの概要や設定方法、すぐに使えるユースケースをいくつか紹介したいと思います。

トランザクションセキュリティポリシーとは？

トランザクションセキュリティポリシー（Transaction Security Policy）とは、ユーザーがSalesforce内で何らかのアクション（ログイン、レポートの実行・エクスポート、APIの呼び出し、データの閲覧など）を行った際、その「トランザクション（処理）」が事前に定義した「ポリシー（ルール）」に合致するかどうかをリアルタイムに評価します。
そして、ポリシーに一致した場合に予め指定したアクション（ブロック、通知、多要素認証の強制など）を実行します。

トランザクションセキュリティポリシーはイベントモニタリングの一機能として提供されており、使用するには以下のいずれかのアドオンライセンスが必要です。

Salesforce Shield
Event Monitoring（イベントモニタリング）

以前はトランザクションセキュリティポリシーを使用するには有効化する必要がありましたが、セキュリティコントロール要件の強化に伴い、2026年7月13日にすべての組織で有効化されます。

トランザクションセキュリティポリシーを管理（作成、更新、削除など）をするには以下の権限が必要です。

アプリケーションのカスタマイズ権限
トランザクションセキュリティポリシーの変更

設定したポリシーはすべてのユーザーに適用されます。
ポリシーの適用はシステム管理者であっても例外ではありません。
そのため、必要以上に操作ができなくならないよう、ポリシーの要件はしっかりと考慮し、実装する必要があります。

権限セットなどの他のセキュリティ設定との違い

プロファイル、権限セットなどの設定では、特定のオブジェクトが参照できるかどうか、レポートを実行できるかといった権限の有無のみの設定しかできません。
一方、トランザクションセキュリティポリシーではいつ、どこで（どのIPアドレスから）、どのような操作を行うかといった細かいポリシーの設定が可能です。
例えば、「社内ではレポートを参照したいが、許容したIPアドレス以外ではレポートの閲覧をブロックしたい」など、細かい要件を実現できます。

AIエージェントの行動も制限できる

昨今はHeadless化が提唱され、SalesforceのUI上からではなく、Slack botなどのAIエージェント経由でデータを参照することも少なくありません。
トランザクションセキュリティポリシーはこれらのAIエージェントによるAPIトランザクションに対しても有効です。

例えば、Slack botを接続している場合、使用するユーザーの権限で実行されます。そのため、基本的にはUI上で操作するのと変わらない一方で、レポートの閲覧権限がなくても簡単に大量のレコードのCSVを作成できてしまいます。
この場合も、ポリシーを設定しておけば、1,000行を超えるクエリを実行した場合でもリアルタイム検知し、通知を受け取り、ブロックできます。

トランザクションセキュリティポリシーの設定方法

トランザクションセキュリティポリシーの設定は、ノンプログラミングで構築できる「条件ビルダー（UI設定）」と、複雑な要件に対応できる「Apexによる記述」の2種類が用意されています。

UIで設定できる「条件ビルダー」

条件ビルダーを使用すれば、マウス操作だけで簡単に強力なポリシーを作成できます。設定の流れは以下の4ステップです。

イベントの選択：

監視対象とするユーザーのアクション（イベント）を選択します。例えば、「ログイン」「レポートイベント」「APIイベント」などから選びます。

条件の定義：

どのような場合にポリシーをトリガーするかを定義します。画面上に「条件」「演算子」「値」を設定する行が表示されます。

例：[処理行] [次の値以上] [2000]
例：[アクセス元IP] [次の値に含まれない] [（社内のIP範囲）]

アクションの指定：

条件に合致した際のシステムの振る舞いを選びます。[ブロック]、[多要素認証]、または[なし]から選択します。
※なしは通知のみを受け取りたい場合に設定します。

通知の設定：

ポリシーがトリガーされた際、システム管理者に通知を飛ばすかどうかを設定します。通知方法はメール通知かアプリケーション内通知から選択できます。

※画像はデフォルトで提供されているポリシーです

条件ビルダーは直感的に設定できるため、一般的なセキュリティ要件（大量ダウンロードの禁止や、特定IP以外からのアクセス制限など）の多くは、このUI設定だけで完結させることができます。

より複雑な設定ができる「Apex」での記述方法

「条件ビルダーの標準機能だけでは、自社の複雑なビジネスルールを表現できない」という場合には、Apexコードを使用したポリシー（拡張トランザクションセキュリティ：Enhanced Transaction Security）を記述できます。
Apexを使用する場合、Salesforceが提供する TxnSecurity.PolicyCondition インターフェースを実装したカスタムクラスを作成します。


global class CustomSecurityPolicy implements TxnSecurity.PolicyCondition {
    global Boolean evaluate(SObject event) {
        // 以下に判定ロジックを記述する
        // イベントを具体的な型（ReportEventなど）にキャスト
        ReportEvent reportEvent = (ReportEvent)event;
        
        // ユーザーのプロファイルや所属部署、現在の時間帯、カスタムオブジェクトのデータをクエリして総合的に判断
        if (reportEvent.RowsProcessed > 1000) {
            // 特定のカスタム条件に合致する場合は true（ポリシー発動）を返す
            return true; 
        }
        return false; // 安全と判断した場合は false
    }
}

Apexによるポリシー作成では、以下のような高度な判定が可能になります。

関連データの動的参照： ログインしようとしているユーザーの「所属部署」をカスタムオブジェクトからリアルタイムに取得し、その部署ごとに定義された「許可時間帯」や「アクセス許可エリア」と照らし合わせて合致しているかを判定する。
外部システムとの連携（コールアウト）： ユーザーがデータにアクセスした際、外部システムにAPIで問い合わせ、そのユーザーのリスクスコアをリアルタイムに取得してブロックの有無を決定する。
複数条件の複雑な組み合わせ： 「AオブジェクトのBフィールドの値が◯◯で、かつ過去1時間にそのユーザーが実行したAPI回数が合計◯回を超えている場合」といった、時間経過や複数条件が絡み合う複雑なロジックの実装。

Apexでクラスを作成した後は、トランザクションセキュリティポリシーの設定画面で、条件の指定方法として「Apex」を選択し、作成したクラスを紐付けるだけで適用できます。
開発のハードルは上がりますが、企業の詳細なセキュリティ要件に100%フィットできる極めて強力なアプローチです。

実務で使える！具体的な活用ユースケース

ここからは、実際の業務でも使えるトランザクションセキュリティポリシーの具体的なユースケースと設定方法をふたつ紹介します。

ケース1：未許可のブラウザや不審なIPからのログイン時に多要素認証（MFA）の強制

許可されたIPアドレス以外や許可されていないブラウザからログインを確認した際にブロックします。

ポリシーの定義方法：条件ビルダー
対象イベント：ログインイベント（LoginEvent）
トリガー条件：
- 「アクセス元IP」次の文字列と一致しない「会社のIPアドレス」　AND
- 「ブラウザ」次の文字列と一致しない「会社で許可しているブラウザ」

アクション： [多要素認証]
名前：ポリシー名を入力（先頭を英字にして、英数字、1つのアンダースコア、およびスペースのみを使用し、末尾を英数字にする必要があります）
通知：通知を希望する場合は通知方法と通知先を設定します

ケース2：特定のカスタム権限を付与されたユーザーのみ在宅作業を許可したい

ケース1のように、基本的には許可されたIPやブラウザ以外での作業を許可したくないが、一部ユーザーのみを在宅での作業（ログイン）を許可したい場合などは、カスタム権限と組み合わせで実装が可能です。しかし、権限の有無は条件ビルダーの条件として使用できないため、Apexで実装します。


global class LoginRestrictionPolicyCondition implements TxnSecurity.EventCondition {

    global Boolean evaluate(SObject event) {
        // 発生したイベントをLoginEventにキャスト
        LoginEvent loginEvent = (LoginEvent) event;

        Id userId = loginEvent.UserId;

        // 1. カスタム権限「Bypass_IP_Restriction」を持っているユーザーは許可
        if (hasCustomPermission(userId, 'Bypass_IP_Restriction')) {
            return false; // false = ポリシーをトリガーしない（ログインを許可）
        }

        // 2. 接続元のIPアドレスとブラウザをチェック
        String allowedIp = '100.100.1.100'; // 会社の許可IP（例）
        String allowedBrowser = 'Chrome';   // 会社の許可ブラウザ（例）

        String sourceIp = loginEvent.SourceIp;
        String browser = loginEvent.Browser;

        // 許可されたIP、かつ、許可されたブラウザからのアクセスか確認
        if (sourceIp == allowedIp && browser == allowedBrowser) {
            return false; // false = ポリシーをトリガーしない（ログインを許可）
        }

        // 「許可外の環境」からのアクセスは検知
        return true; // true = ポリシーをトリガー（ブロックまたは通知を実行）
    }

    /**
     * 特定のユーザーが指定されたカスタム権限を持っているか判定するメソッド
     */
 	private Boolean hasCustomPermission(Id userId,String permissionDeveloperName) {
        // 指定されたカスタム権限自体のレコードIDを取得
        List customPrivs = [SELECT Id FROM CustomPermission WHERE DeveloperName = :permissionDeveloperName LIMIT 1];
        if (customPrivs.isEmpty()) {
            return false; // カスタム権限自体が存在しない場合はfalse
        }
        Id customPermissionId = customPrivs[0].Id;

        // そのカスタム権限が紐付いている「権限セット」のIDをすべて取得
        List setups = [
            SELECT ParentId 
            FROM SetupEntityAccess 
            WHERE SetupEntityType = 'CustomPermission' 
            AND SetupEntityId = :customPermissionId
        ];
        if (setups.isEmpty()) {
            return false; // どの権限セットにも紐付いていない場合はfalse
        }

        // 権限セットのIDをコレクションに詰める
        Set permissionSetIds = new Set();
        for (SetupEntityAccess sea : setups) {
            permissionSetIds.add(sea.ParentId);
        }

        // ステップ3: 対象のユーザーに、それらの権限セットが割り当てられているか最終確認
        List assignments = [
            SELECT Id 
            FROM PermissionSetAssignment 
            WHERE AssigneeId = :userId 
            AND PermissionSetId IN :permissionSetIds
        ];
        
        return !assignments.isEmpty();
    }
}

まとめ

運用のベストプラクティスと注意点

トランザクションセキュリティポリシーは、操作をリアルタイムで検知し、ブロックできる非常に強力なツールです。
ただし、実際に実務で運用するにあたっては、いくつかの注意点とベストプラクティスがあります。

必ず「Sandbox（テスト環境）」で検証する

ポリシーの設定ミス（例：条件のロジックが広すぎるなど）があると、一般ユーザーの通常の業務や、夜間のバッチ処理、データローダによる一括インポート作業まで意図せずブロックしてしまう危険性があります。まずはSandbox環境で十分にテストを行ってください。

最初は「通知のみ」で様子を見る

新しいポリシーを本番環境に適用する際は、いきなり「ブロック」アクションにするのではなく、まずは「何もしない（通知のみ）」で有効化することをおすすめします。
数週間運用してログを確認し、一般的な通常業務が誤って検知されていないかを確認した上で、アクションを「ブロック」や「MFA要求」に切り替えるのが安全な運用の鉄則です。

セキュリティの大切さ：事件が起きる前に

サイバーセキュリティや内部不正対策における鉄則は、「事件が起きてからでは遅すぎる」ということです。

特にクラウドサービス上のデータは、一度外部に流出してしまえば、回収することは不可能です。企業のブランドイメージの失墜、顧客への損害賠償、社会的な信用の喪失など、目に見えない損失は計り知れません。
Salesforceに保存されているデータは、会社にとっての貴重な資産であり、競争力の源泉そのものです。
その資産を守るために、ガードマンの役割をする「トランザクションセキュリティポリシー」の使用を検討してみてはいかがでしょうか。
まずは、最もリスクが高いと感じる「レポートの大量ダウンロード対策」など、小さなステップから導入を検討してみることを強くお勧めします。自社のデータを正しく守り、安心・安全なSalesforce運用を実現していきましょう。

◆Salesforceノウハウ共有ツール「KnowhowBase」は‘ノウハウを作る、探す、活用する’をコンセプトに、Salesforceプラットフォーム上で利用できる便利な機能をご提供しています。また、「Salesforce導入サービス」「Salesforce伴走・開発支援サービス」により、Salesforceを新規導入される方、Salesforceの定着・活用や運用保守・開発を要望される方に合ったサービスもご提案しております。ご興味のある方は、お気軽にお問い合わせください。

★当サイトでノウハウ共有やSalesforceの定着促進・保守運用・開発を検討している方へ、様々なダウンロード資料をご用意しております。ぜひ資料をダウンロードいただき、ご活用ください。

Dreamforce 2025 速報！Salesforce 最前線の新発表とは？

情報共有を効率化する３つのポイント

contact

ご相談・ご質問等ございましたら、お気軽にお問い合わせください。

お問い合わせ