その目立たなさこそが、リスクが真剣に受け止められない理由の一部です。また、それこそが実際のコストが常に過小評価される理由でもあります。目に見えるインシデントが存在しないことは、リスクが低いことの証拠ではありません。インシデントが発生した際、そのコストが事後報告書の単一の行には決して現れないような形で組織全体に分散していることの証拠なのです。

データ消失は実際にはどのようにして起こるのでしょうか？

そのシナリオは至って平凡なものであり、それこそが重要なポイントです。

• 開発者が誤った環境に対してデータローダー操作を実行し、アカウントレコードを大量に上書きしてしまう。
• ワークフロールールによってトリガーされた一括削除が、意図した範囲を超えて連鎖的に波及する。
• 退職する従業員が、アクセス権限が取り消される前にレコードを削除する。
• サードパーティの統合機能が、誰にも気づかれないまま破損したデータを一括でプッシュする。
• 機能上必要な範囲よりも広範な権限が付与された統合またはAPIユーザーが（故意か過失かを問わず）悪用され、本来の想定範囲を大幅に超えるレコードの表示、修正、または一括削除が行われる。

これらはいずれも、高度な攻撃者や異例のシステム障害を必要としません。これらは、大規模なSalesforce組織における通常の運用上の複雑さから生じる成果物です。また、十分な頻度で発生しているため、成熟したSalesforce環境を持つほとんどの組織は、それをデータ消失イベントと分類したかどうかに関わらず、少なくとも一度は意味のあるデータ消失イベントを経験しています。

「過剰な権限付与は、Salesforceのデータ消失の大部分における構造的な根本原因です。アクセスの大部分は、Salesforce自身のベストプラクティスモデルとは正反対に、権限セットではなくプロファイルを通じて依然として管理されています」と、Cloud Protection by WithSecureのSalesforceアーキテクトであるTapas Tripathiは述べています。

これこそが、Cloud ProtectionのIdentity Protectionが解消する正確なギャップです。権限セットおよびプロファイルの割り当てを継続的にスキャンし、データ消失や露出に結びつく特定のリスクある権限を浮き彫りにし、管理者に対して次のインシデントとなる前に修正すべき過剰な権限を持つユーザーの優先順位付き実行可能リストを提供します。

直接的コスト

データ消失が発生し、復旧が可能な場合でも、それが迅速かつ安価に済むことはめったにありません。Salesforceの標準復旧オプション（ごみ箱、データエクスポート、およびデータ復旧サービス）には、プレッシャーがかかる状況下で致命的となる制限がそれぞれ存在します。ごみ箱の保管期間は15日間です。データエクスポートは特定時点のスナップショットであり、被害が発生する前の状態である可能性があります。データ復旧サービス（利用可能な場合）は数週間かかることがあり、歴史的に対応範囲が限定されていました。

多くの組織にとって、手動による再構築が最終手段となります。これは、ITおよびSalesforce管理者チームがログ、CSV、および断片化されたレコードを調査して、失われたものを復元することを意味します。データのボリュームと複雑さによっては、これには数週間のエンジニアリング時間が費やされる可能性があります。複雑なSalesforce構成を持つ大規模エンタープライズにとって、重大なデータ消失イベントは、ほとんどのセキュリティインシデントよりも多くの内部リソースを消費する可能性があります。

すぐには表れないコスト

直接的な復旧コストは目に見える部分に過ぎません。定量化がより困難なコストはバックグラウンドで蓄積され、インシデントが正式に終了した後も長く影響を及ぼす傾向があります。

収益への影響が最も重大です。パイプラインデータが消失または破損すると、案件の可視性が低下します。セールスマネージャーは不完全な予測に基づいて作業することになります。アカウントエグゼクティブは、次の交渉に活用すべき関係性の履歴を失います。更新マネージャーは、今後の商談についての明確な見通しを持てなくなります。CRMツールとしての有用性が低下し、収益パフォーマンスに対するダウンストリームへの影響（特に複雑で長期にわたるエンタープライズ営業において）は相当なものとなり、数ヶ月間持続する可能性があります。

顧客の信頼もその一つです。データ消失がサービスの低下につながる場合（アカウント履歴のないサポート担当者、重要な文脈を欠いた更新交渉など）、顧客はそれに気づきます。彼らは理由を知らないかもしれませんが、その体験は回復が困難な形で信頼を損ないます。

さらに、法的・規制上の影響も増大しています。失われたデータに個人情報が含まれる場合、インシデントはGDPR、CCPA、または同等のフレームワークに基づく通知義務を発生させる可能性があります。規制対応、法的レビュー、および潜在的な執行措置のコストは、技術的な復旧コストを小さく見せるほど巨大になる可能性があります。

例えば、2025年〜2026年のShinyHunters/Scattered Spiderによるボイスフィッシングキャンペーンでは、攻撃者がITサポートを装ってSalesforceユーザーに偽のData Loader接続アプリケーションを承認させ、そのアクセス権を使用してCRMデータを外部に送信（エクスフィルトレーション）し、複数のエンタープライズ組織にわたってその削除を脅迫しました。これは、上記の「ランサムウェアに類似した」シナリオの現実世界での実例です。

まとめ

Salesforceのデータ保護に関するビジネスケースは複雑ではありません。インシデントのコストとそれを防止するためのコストの比較に帰結します。エンタープライズスケールにおいて、計算上常に防止策側が有利になります。

防止策に必要なのは、粒度の細かい復元機能を備えた継続的かつ自動化されたバックアップです。つまり、最小限の許容範囲を超える重大な局面に至ってから制限が明らかになる標準ツールに依存することなく、特定のレコード、関連性、および設定を既知の時点に復元できる能力です。

また、過剰な権限付与のギャップを解消することも意味します。どのユーザーや統合がリスクのある権限を保持しているかを正確に把握し、それが損失イベントに変わる「後」ではなく「前」に、そのアクセス権を修正できるようにすることです。

Salesforceのデータ保護をコストセンターとして扱う組織は、インシデントが発生した後にその価値に気づくことになります。それを事業継続性への投資として扱う組織には、そのような教訓を語るような事態は訪れません。

連載の詳細を読む：

Salesforce におけるリスクは単一の種類にとどまらないことを理解することが重要です。

機密性の高い顧客データへの不正アクセスはリスクの1つであり、ケースの添付ファイルを介してアップロードされるマルウェアも同様にリスクです。営業担当者がフィッシングリンクをクリックすることもあれば、パートナーアカウントが漏洩したパスワードを使用することもまったく異なるリスクとなります。

これらのリスクには、それぞれ異なるセキュリティコントロールが必要となります。現代のセキュリティは単一の製品を中心に構築されるのではなく、異なる種類のリスクを低減するようにそれぞれ設計された複数のレイヤーによって構成されます。

Salesforce Shield は、Salesforce 内部に既に存在するデータのガバナンスと保護に重点を置いています。一方、Cloud Protection for Salesforce は、ファイル、リンク、および侵害されたアイデンティティを経由して侵入しようとするアクティブな脅威の防止に重点を置いています。

両者はそれぞれ異なる役割を担っていますが、同じ目標の達成に貢献しています。

あらゆる Salesforce 環境は、同じリスクの2つの側面を抱えています。それは「内部に存在するデータ」と、「そこを通過・動くコンテンツおよびアイデンティティ」です。Shield は、保存データ、誰が閲覧可能か、保存期間、暗号化の有無などを統制・保護します。Cloud Protection for Salesforce は、侵入して被害を発生させようとする悪意のあるファイル、リンク、侵害されたログイン情報などのアクティブな脅威の側面を保護します。これらを組み合わせて使用することで、脅威の両面を保護し、完全な Salesforce セキュリティポスチャを実現します。

現実世界の例で例えるなら、空港を想像してください。Salesforce Shield は、防犯カメラ、アクセスログ、セキュリティ記録のようなものです。誰が入場したか、何が起きたかを記録し、事後調査において調査員を支援します。

Cloud Protection for Salesforce は、危険な物品がそもそも持ち込まれないようにスキャンして防止する「手荷物検査場（セキュリティチェックポイント）」に相当します。

金融サービスやヘルスケアなどの規制の厳しい業界でビジネスを行う場合、Shield 自体が不可欠となることがよくあります。GDPR、HIPAA、および同様の規制では、保存データの暗号化を想定される保護対策として扱い、誰がアクセスまたは変更したかを正確に証明することが求められます。Cloud Protection for Salesforce はその要件を代替するものではなく、別の攻撃対象領域 – つまり、Shield が検知するように設計されていないマルウェア、フィッシング、および資格情報の脅威 – を保護します。それぞれの役割を理解することが、真に安全な Salesforce 環境を構築するための第一歩です。

Salesforce Shield が保護するもの

Shieldは、「プラットフォーム暗号化」、「フィールド監査証跡」、「イベント監視」、「データ検出」という4つの柱を基盤としています。これらを組み合わせることで、保存中の機密フィールドやファイルを暗号化し、誰がいつどのデータを変更したかを（最大10年間）追跡し、50種類以上のイベントタイプにわたる詳細なユーザーおよびシステムのアクティビティを監視し、組織全体にわたる機密データを検出・分類することが可能になります。これは、規制対象組織がデータに対する管理体制を証明するために頼る、ガバナンスおよび監査の基盤となるものです。

Cloud Protection for Salesforce が保護するもの

Cloud Protection for Salesforce は、Salesforce をリアルタイムで通過・移動するコンテンツとアイデンティティに重点を置いています：

•  リアルタイムのマルウェアおよびランサムウェア対策: アップロードまたはダウンロードされる最大 800 MB までのすべてのファイルを、マルチエンジンアンチマルウェアおよび振る舞いサンドボックスを使用してスキャンし、ゼロデイ脅威、パスワード保護されたアーカイブ、およびファイルタイプの偽装を検知します。

•  フィッシングおよび悪意ある URL 防御: 投稿時およびクリック時の双方で、短縮リンクや悪意ある QR コードを含む悪意あるリンクをリアルタイムでブロックします。

•  アイデンティティ脅威保護: 通常の IT 部門の視界外になりがちなコミュニティユーザーやポータルユーザーを含め、Salesforce ユーザーの資格情報（ログイン情報）をダークウェブの漏洩インテリジェンスと照合・確認し、攻撃者に悪用される前に侵害されたアカウントを検知します。また、アイデンティティ保護機能は、リスクのある権限セットや Cloud Protection for Salesforce ライセンスが付与されていないユーザーのフラグ付けも行います。

両者が重複・共通する領域

どちらのソリューションも Salesforce の組み込みセキュリティを拡張し、企業が GDPR、HIPAA、SOC 2 / ISAE 3000 などのコンプライアンス義務を満たすのを支援します。どちらも外部統合によって後付けされたものではなく、Salesforce プラットフォーム向けにネイティブ構築されており、セキュリティチームが対応・アクション可能なログ、レポート、ダッシュボードを通じて管理者に可視性を提供します。

なぜこれが重要なのか：現実のシナリオ

適切な保護対策が講じられていない場合：サービス担当者がケースを開き、一見すると通常の顧客からのメッセージのように見える内容を確認して、リンクをクリックしてしまいます。ほんの数秒で、その担当者の企業認証情報が盗み出されてしまいます。これにより、稼働中のCRM環境内で有効な認証情報を手にした攻撃者は、顧客レコード、未解決のケース、パートナーポータルデータ、および社内ワークフローにアクセスできるようになります。Shieldのイベントモニタリング機能は、最終的にそのアカウントにおける不審なログイン活動やセッションの挙動を検知しますが、これは調査が開始された際に貴重なフォレンジック情報となります。しかし、その時点で被害はすでに発生してしまっています。2026年2月に発行された当社の「2026年度版 Salesforce 脅威ランドスケープレポート 」に記載されているように、Salesforce環境での情報漏洩に関連するリークサイトに、40社近くの主要企業が掲載されています。これはまさに、同レポートがSalesforce環境における主要な攻撃経路として指摘している、URLを悪用した攻撃の一例です。

Cloud Protection for Salesforceを導入すると、リンクが投稿された瞬間にスキャンが行われ、クリックされた時点でも再度スキャンされます。ページが読み込まれる前に、悪意のあるリンク先が特定され、ブロックされます。これにより、認証情報の窃取は発生せず、インシデントは未然に防がれます。Cloud Protection for Salesforce のレポート機能ではブロックされたクリックが記録され、Shieldの監査証跡レポートでは、侵害が成功したとして記録されるのではなく、クリックの試みが阻止されたことが確認されます。

Shieldは、セキュリティ侵害の発生を検知・記録し、調査やコンプライアンス報告を可能にします。一方、Cloud Protection for Salesforceは、認証情報が盗み出される前に悪意のあるURLをブロックすることで、そもそもセキュリティ侵害の発生を未然に防ぎます。Salesforceのセキュリティ確保とは、単に既存のデータを保護するだけでなく、悪意のあるコンテンツや侵害されたアカウントの侵入を防ぐことでもあります。Salesforce Shieldは前者の課題に焦点を当てており、Cloud Protection for Salesforceは後者の課題に焦点を当てています。

共に使用することの価値

これは、どちらか一方を選択すべきという話ではなく、両方を組み合わせるべきという話です。Shield の Event Monitoring、Field Audit Trail、および暗号化は、セキュリティおよびコンプライアンスチームが必要とするガバナンスとフォレンジック記録を提供します。Cloud Protection for Salesforce はアクティブな防御層を追加し、マルウェア、フィッシング、侵害された資格情報が、そもそも監査を必要とするようなインシデントに発展するのを未然に防ぎます。

成熟したセキュリティプログラムを持つ組織は、単一の防御層に頼ることはしません。ガバナンス、予防的コントロール、検知、および調査機能を組み合わせます。Salesforce Shield と Cloud Protection for Salesforce は連携することで、これらのセキュリティ機能全体に補完的な保護を提供し、侵害の可能性とインシデント発生時の影響の双方を低減します。

すでに Shield を運用している組織は、強力なデータガバナンスを備えています。Cloud Protection for Salesforce を追加することで、Shield が対応するように設計されていない領域 – 悪意のあるコンテンツや侵害されたアイデンティティのリアルタイム検知とブロック – のギャップを埋めることができます。両者を組み合わせることで、Salesforce ユーザーは一方を選択せざるを得ない状況を回避し、「可視性」と「予防（防御）」の両方を手に入れることができます。

Salesforce Experience Cloud とは何か、なぜ組織で使用されるのか？ 

Salesforce エコシステムで作業している場合、すでに Experience Cloud についてご存知でしょう。これは、顧客、パートナー、または一般ユーザーなど、外部の人々と自社を接続し、チームが Salesforce で毎日管理しているデータに直接アクセスするポータルを提供するプラットフォームです。

以下は、チームが毎日これを活用している一般的な例です:

• カスタマーサポートとセルフサービス: ユーザーはサポートに電話することなく、ケースの登録、注文の追跡、深夜2時でも回答の検索を行うことができます。

• パートナーとのコラボレーション: 代理店などのパートナーは、営業チームにメールを送ることなく、案件の登録や最新の価格表の取得を自ら行うことができます。. 

• 公開コミュニティ: 見込み客は、直接話をする前にナレッジ記事を閲覧したりイベントに申し込んだりすることができます。

• 従業員およびフランチャイズ向けポータル: 分散されたチームが、別の社内システムを用意することなく、本社と同じレコードやプロセスにログインしてアクセスできます。

これらが非常に円滑に機能する理由は、個別の Web サイトを構築する必要がなく、データの同期も不要だからです。ポータルは内部チームが使用しているものと同じレコードを読み書きするため、顧客がポータルで登録したケースは、サービスチームがコンソールで対応するケースとまったく同一のものです。このライブ CRM データへの直接的なアクセスラインこそが、非常に多くの組織が Experience Cloud に依存している理由です。

なぜ Experience Cloud ゲストユーザーのアクセスがセキュリティリスクを生むのか 

匿名訪問者を許可するすべての Experience Cloud サイトは、ゲストユーザープロファイルと呼ばれるものに依存しています。サイトへの認証されていないすべての訪問者はこの単一のプロファイルを共有し、その権限によって訪問者が表示・実行できる内容が決定されます。Salesforce におけるユーザー権限とプロファイルに関しては、一筋縄ではいかない複雑な問題であることは周知の事実です。日々それらを扱う管理者であれば誰もがその難しさを証言するでしょう。

ゲストユーザープロファイルは、ナレッジ記事や製品一覧など、公開を意図したデータのみへのアクセスを付与することを目的としています。しかし、Salesforce の権限構造は階層的かつ詳細であり、オブジェクトアクセス、レコードアクセス、項目レベルセキュリティ（FLS）、共有設定にわたっています。それらの階層のいずれか1つでも過剰に広く設定されている場合、匿名の訪問者が公開をまったく意図していなかったデータに到達してしまう可能性があります。さらに、Experience Cloud サイトはページを正しく動作させるために API エンドポイントを公開しているため、そのアクセスは単にページを1つずつ閲覧するだけでなく、スケールした形でデータ抽出が可能です。

換言すれば、ゲストユーザーとは他のユーザーと同様のアイデンティティ（身元）です。ただ単に、インターネット上の誰でも使用できるアイデンティティであるというだけです。そして、長年にわたり既知の弱点として静かに存在していたこの部分を、攻撃者がついに大規模に悪用し始めました。

これまでの Experience Cloud への攻撃  

これは机上のリスクではありません。現在の Salesforce エコシステムにおいて最もアクティブな攻撃パターンの一つです。

攻撃者は2025年以降、誤って設定されたゲストユーザーのアクセスを悪用し続けており、そのキャンペーンは現在も継続しています。重要なのは、これらの中に Salesforce プラットフォーム自体の脆弱性は一切含まれていないということです。すべては「責任共有モデル」に集約されます。Salesforce はプラットフォームを保護し、顧客は権限と設定が正しく設計されていることを確認する責任を負います。

出典（左から右）: TechRadar, Salesforce advisory, FINRA alert, SalesforceBen 

これらのキャンペーンから、特に注目すべき2つの詳細があります:

1. 第一に、攻撃者は認証情報（資格情報）を一切必要としませんでした。誤って設定されたゲストアクセスにより、表玄関はすでに開かれていたためです。
2. 第二に、ゲストアクセスは多くの場合、単なる出発点にすぎませんでした。Salesforce のセキュリティアドバイザリでは、ゲスト設定の不備によって露出したデータを利用してポータルアカウントをセルフ登録し、匿名のゲストセッションを、より広範なデータアクセス権を持つ認証済みユーザーへと引き上げることができると警告しています。外部アイデンティティと内部データとの間の境界線は、ほとんどのチームが想定しているよりも薄いものです。

Experience Cloud ゲストユーザーアクセスの保護方法 

Salesforce のアドバイザリには、それぞれの実装手順を伴う具体的なハードニング（堅牢化）手順が記載されており、これらは今四半期ではなく、今週中に対応する価値があります。これらの手順を実行することで、攻撃者が利用したギャップを塞ぐことができます。しかし、その背景にはより厳しい現実が存在します。

出典: Salesforce security advisory

学ぶべきこと: 最小権限は一回限りのプロジェクトではない 

これらのキャンペーン被害に遭った組織のいずれも、意図的にデータを露出させようとしたわけではありません。アクセス権限は時間の経過とともに徐々に拡大していくものであり、Salesforce 組織を数年間管理した経験のある人なら誰でもその経緯を理解できます。

• 単発プロジェクトのために作成された権限セットが削除されずに残っている
• 利便性のためにプロファイルが複製され、付与した記憶のないアクセス権限がそのまま引き継がれている
• 誰かがロールを変更しても以前の権限をすべて保持している、またはパートナーアカウントがパートナーシップの終了後も静かに存続している

そして、最も一般的な2つの事例を忘れてはなりません:

• 権限を設計した管理者がすでに退職している
• Experience Cloud サイトが外部コンサルタントによって構築され、社内の誰もその設定を完全に所有・管理していなかった

私たちが以前執筆した「誰も語らない Salesforce 権限ギャップ」について、これらの攻撃は、そのギャップが自動化ツールを持つ攻撃者と出会ったときにどうなるかを実証しています。今日の監査によって現在の問題を修正することはできますが、組織は静止しているわけではありません。新しい権限セットが作成され、ユーザーは入出社し、把握できないデータ侵害によって認証情報が漏洩します。問題は、現時点で権限が正しいかどうかではなく、正しくなくなったときにそれを検知できるかどうかです。それこそが、大部分の Salesforce セキュリティプログラムが依然として見落としている点です。

Identity Protection によるギャップの解消

このギャップを埋めるために私たちが構築したのが Identity Protection です。Cloud Protection for Salesforce の一部として機能し、管理者に対して組織全体のユーザーレベルのリスクに関する継続的な可視性を提供します。これらのキャンペーンを踏まえ、最も重要な3つのシグナルに焦点を当てています:

リスクの高い権限の可視化: Identity Protection は監視対象ユーザーに割り当てられた権限を評価し、`Modify All Data`（すべてのデータの変更）、`View All Data`（すべてのデータの参照）、`Manage Users`（ユーザーの管理）などのハイリスクなシステム権限にフラグを立てます。過剰なアクセス権を持つユーザーを特定でき、Identity Protection は Salesforce 固有の高度なユーザービューを参照して、そのアクセスがどこから来ているかを正確に特定します。これにより、最小権限の原則が年次のプロジェクトから、常時有効な運用へと変わります。

侵害モニタリング: Identity Protection は、Salesforce ユーザーの認証情報がサードパーティのデータ侵害に登場したことを検知するため、攻撃者が行動を起こす前に対策を講じることができます。これは内部ユーザーと外部ユーザーの両方にとって重要です。Experience Cloud のコミュニティおよびパートナーのログインは、企業のセキュリティスタックの外側に位置することが多く、会社が管理するデバイスやアイデンティティプロバイダー（IdP）がバックに存在しないケースが多々あります。それにもかかわらず、彼らはログインし、Salesforce 組織内のプラットフォームおよびデータと相互作用します。Identity Protection は従業員だけでなく、これらの外部アイデンティティもエンタープライズ規模で監視します。

統合されたリスクシグナルと即座のレスポンス: [Identities at Risk] (リスクのあるアイデンティティ) 概要画面は、リスクの高い権限と侵害への露出を、MFA や SSO の使用状況、各ユーザーに紐付く接続アプリケーションおよびアクティブなトークンの可視性と統合します。これにより、最高の複合リスクを示すユーザーを優先して対応できます。同じパネルから、ユーザーを即座に凍結（Freeze）したり、パスワードリセットを強制したりできます。  

これらのキャンペーンは、過剰な権限を持つ1つのアイデンティティ（この場合は匿名のゲスト）が自動化ツールを持つ攻撃者と接触したときに何が起こるかを示しました。継続的なアイデンティティのモニタリングこそが、その両方に先回りし続ける方法です。Identity Protection は Cloud Protection for Salesforce のユーザーベースライセンスに含まれており、追加の個別アドオンは不要です。ファイル保護および URL 保護と連携して機能し、ネイティブの Salesforce コントロールでは管理者に委ねられているコンテンツ層とアイデンティティ層をカバーします。

まとめ

これらのキャンペーンで被害を受けた組織は、不注意だったわけではありません。彼らは、今日何千もの Salesforce 顧客が運用しているのと同じポータル、同じ権限モデルを運用していただけです。ニュースの標的になるか無事で済むかの違いは、誤って設定しやすく、管理を見失いやすい設定の詳細に起因していました。

したがって、これを対策の契機として捉えてください。今週中にゲストユーザーのアクセスを監査し、組織内のすべてのアイデンティティを最小権限まで絞り込み、設定の逸脱（ドリフト）が発生したときにそれを検知できる仕組みを導入してください。なぜなら、設定は必ず逸脱するからです。攻撃者はすでにスキャンを実行しています。唯一の疑問は、彼らがあなたのサイトに到達したときに何を発見するかです。

現在のアイデンティティリスクがどのような状態にあるか確認したい場合は、デモをご予約ください。数週間ではなく数分で可視化してお見せいたします。

フィンランド・ヘルシンキ – 2026年9月1日 – WithSecure (本社: フィンランド・ヘルシンキ、以下、ウィズセキュア) は本日、Salesforce向けセキュリティ事業である「Cloud Protection for Salesforce」を独立会社として会社分割（新設分割）することを発表しました。新会社「Cloud Protection by WithSecure」は、マルウェア、フィッシング、データ経由の脅威からのSalesforce環境の保護に特化して事業を展開します。一方、WithSecureは、マネージドサービスプロバイダー（MSP）および付加価値ディストリビューター（VAD）向け統合型プロアクティブ・セキュリティプラットフォーム（エンドポイント、アイデンティティ、クラウド、コラボレーションセキュリティ、Exposure Management、AIを活用したMDRを包括）にリソースを集中させます。なお、本分割に伴う所有権（株主構造）の変更はありません。

Cloud Protection for Salesforceは、長年にわたりウィズセキュア内で自律した事業部門として運営され、独自の製品開発、市場開拓、カスタマーサクセス機能を構築してきました。その結果、Rolls-Royce & Partners Finance、Coca-Cola Bottlers、Yahoo! などの企業から信頼を獲得し、Salesforceネイティブなセキュリティソリューションのリーダーとしての地位を確立しています。

独立企業となることで、Cloud Protectionは自社の全リソース、ロードマップ、投資をSalesforceセキュリティに集中させることが可能となります。　一方、ウィズセキュアも中核となるサイバーセキュリティ事業への取り組みをより強固なものにします。

ウィズセキュアのCEOであるAntti Koskelaは、今回の分社化に関して次のように述べています。
「Cloud Protectionは独立した事業体として成長し、競争力を発揮できることを実証してきました。今回の分社化は、その実績を反映した自然な流れです。分社化により、両社がそれぞれの強みに全力を注ぐことができます。ウィズセキュアは中核であるElementsプラットフォームに、Cloud ProtectionはSalesforce向けセキュリティの圧倒的リーダーとなることに集中していきます。」

また、Cloud Protection のGeneral Manager であるJuhana Autioは、次のように述べています。
「サイバー攻撃者がAIを活用し、企業がAgentforceやHeadless360へと移行する中、Salesforceのエコシステムと脅威状況はかつてないスピードで変化しています。独立企業となることで、意思決定と投資のスピードをさらに加速させ、お客様とそのエンドユーザーがSalesforce上で常に安全を確保できるよう全力を尽くします。」

Cloud Protectionご利用のお客様へ

今回の移行に伴う製品、サポート体制、契約関係の変更はありません。既存の契約内容、サービスレベル（SLA）、担当窓口はそのまま維持されます。Cloud ProtectionがSalesforceセキュリティに全リソースを投入することにより、お客様には今後さらにきめ細やかで迅速なサポートを提供してまいります。

Cloud Protectionは引き続きフィンランドのヘルシンキを拠点とし、北米、EMEA（欧州・中東・アフリカ）、APAC（アジア太平洋・日本）のチームとともにグローバルに事業を展開します。製品は、パートナー企業様、直接販売、ならびにSalesforce AgentExchangeを通じて引き続き提供してまいります。

Cloud Protectionについて

Cloud Protectionは、Salesforce環境向けにエンタープライズグレードのセキュリティを提供しており、Rolls-Royce & Partners Finance、Coca-Cola Bottlers、Yahoo! をはじめとする Fortune 500 企業や政府機関を含む世界中の組織から信頼されています。

Salesforceネイティブなソリューションとして、ファイル、リンク、アイデンティティ、Agentforceワークフローをリアルタイムでスキャンし、既存の設定を変更することなく、標準機能や従来のメールセキュリティでは防ぎきれないマルウェア、フィッシング、アイデンティティベースの脅威をブロックします。詳細は cloudprotection.com をご覧ください。

WithSecureについて

ウィズセキュアは、多くのヨーロッパ企業に選ばれるサイバーセキュリティパートナーです。世界中のITサービスプロバイダー、MSSP、ユーザー企業から、中堅・中小企業を保護するアウトカム(成果)ベースのサイバーセキュリティソリューションにおいて大きな信頼を勝ち取っています。ウィズセキュアはヨーロッパにおけるデータ保護の規制に準拠し、プライバシー、データ主権、コンプライアンスに注力しています。 

35年以上にわたる業界経験を誇るWithSecureは、サイバーセキュリティのパラダイムシフト – 事後対応型から予防型への移行 – に対応できるよう、自社製品ポートフォリオを構築してきました。

WithSecureの最先端ソリューションの中核をなすのが「Elements Cloud」であり、AIを活用した技術、人間の専門知識、およびCo-Security (共同セキュリティ)サービスをシームレスに統合しています。さらに、エンドポイントおよびクラウドの保護、脅威の検知と対応、エクスポージャー管理にわたるモジュール式の機能により、中堅・中小企業のお客様の業務を強力に支援します。

【本件に関する報道関係者からのお問合せ先】 

Cloud Protection by WithSecure
マーケティング
marketing-jp@withsecure.com | cloudprotection.com

ウィズセキュア株式会社
マーケティング
press-jp@withsecure.com | withsecure.com

ファイルは常に Salesforce へと流れ込んでいます。ポータル経由で顧客がアップロードする文書、サポートケースの添付ファイル、Web-to-ケース（メール-to-ケース）で送信されるメール、あるいは Experience Cloud を通じてパートナーが共有するファイルなど、その経路は多岐にわたります。そのどれかひとつにでもマルウェアが含まれている可能性があり、サービスエージェントはそれらを一日中開き続けています。

では、それらすべてをどのようにスキャンすればよいのでしょうか？ 結論から言うと、Spring ’26 リリース以降、Salesforce は一部のファイルをネイティブでスキャンするようになりましたが、ファイル、添付ファイル、およびリンクを完全に保護するには Cloud Protection for Salesforce のような専用のスキャンアプリケーションが必要となります。また、本アプリケーションはスキャン結果を Salesforce Security Center に送信できるため、脅威の傾向を長期的に監視することが可能です。

本ガイドでは、ネイティブのファイルスキャン機能が保護する範囲、保護の限界、そしてそのギャップを埋める方法について詳しく解説します。

Salesforce が標準でスキャンする範囲 

Salesforce の公式ドキュメントによると、ネイティブのファイルスキャン機能は次のように動作します:

• Salesforce Filesをアップロード時にスキャンし、悪意があると識別されたファイルをブロックします。

• 対象となるのは Salesforce ファイルのみです。従来の添付ファイル（Legacy Attachments）は対象外となります。Web-to-ケース（メール-to-ケース）は添付ファイルを作成するため、外部から組織（Org）にファイルが入ってくる最も一般的な経路の 1 つがカバーされないことを意味し、これは非常に重要な点です。

• 100 MB を超えるファイルはスキャンされず、ブロックもされません。 

• 悪意がある確率が高いファイルのみにフラグを立てます。

• 本機能が有効化される前にアップロードされたファイルは、誰かがそれらをダウンロードしたときにのみチェックされます。

レコード内の URL のスキャン機能や、スキャンされた内容、検出された脅威、時間経過に伴う脅威アクティビティの動向を確認できるレポート層（機能）も存在しません。

Salesforce はこの点について明確に公開しています。ドキュメントでは、より厳しいスキャン要件を持つお客様に対して、AgentExchange 上のセキュリティパートナーを参照するよう案内しています。言い換えれば、ネイティブスキャンは最低限の基準であり、到達点ではありません。機能ごとの完全な内訳については、Salesforce のファイルスキャンと Cloud Protection for Salesforce の詳細な比較をご覧ください。

すべてのファイルと添付ファイルをリアルタイムでスキャンする方法

Cloud Protection for Salesforce は、まさに上記で挙げたようなセキュリティギャップを埋めるために構築されています。組織（Org）内で本アプリケーションを稼働させることで、次のように変わります。

すべてのファイルと添付ファイルがスキャンされます。 Salesforce ファイル、従来の添付ファイル、Web-to-ケース（メール-to-ケース）のコンテンツ、ポータルからのアップロード、Experience Cloud、Chatter、および Agentforce ワークフローを流れるコンテンツが対象です。例外となるファイルタイプや侵入経路はありません。

スキャンはアップロード時だけでなく、ダウンロード時にも実行されます。 脅威インテリジェンスは絶えず進化しているため、昨日クリーンだったファイルが今日マルウェアとして識別されることがあります。ネイティブスキャンはファイルを 1 度しかチェックしませんが、Cloud Protection for Salesforce はダウンロードのたびに再チェックを行い、ユーザーがファイルを開く前にこうした遅延検出に対応します。

組織内にすでに存在するファイルもスキャンされます。 必要に応じてオンデマンドで手動スキャンを実行したり、営業時間外にファイルを一括チェックするスケジュールスキャンを設定したりできます。

悪意のあるファイルは自動的に処理されます。 設定したポリシーに基づき、有害なコンテンツが発見された瞬間にブロックまたは隔離され、管理者へアラートが通知されます。手動による確認キューは不要です。

リンクも同様に処理されます。 ケース、Chatter 投稿、メール、リード、タスク、その他の標準オブジェクトおよびカスタムオブジェクトなど、表示されるあらゆる場所の URL がリアルタイムの脅威インテリジェンスと照合・チェックされます。ファイルや画像内の QR コードも抽出され、その遷移先がスキャンされます。これは、フィッシングリンクが常に目に見える場所にあるとは限らず、文書内や QR コードの背後に隠されているためです。

迅速に導入・利用開始できます。 アプリケーションは AgentExchange からインストールでき、セットアップ（Setup）に時間はかからず、Salesforce の設定変更も不要です。ファイルやリンクが組織に入り込むと同時に、リアルタイムスキャンが開始されます。

Security Center ですべてを監視する方法 

スキャンによって、脅威は到達した時点で検出・捕獲されます。しかし、そうしたアクティビティに対する可視性がなければ、保護機能が正しく動作しているかを確認したり、脅威のパターンを特定したり、監査人などに証明したりすることができません。

つのダッシュボードから複数の組織全体のセキュリティを監視する Salesforce のツールである Security Center をご利用の場合、Cloud Protection for Salesforce からの脅威データをそのまま画面上に表示できます。ファイルのスキャン判定、URL のスキャン結果、アラート、アイデンティティ侵害レコードなどが、傾向チャートを備えたカスタム指標として表示されます。

これにより、個々のイベントが実用的な施策につながるパターンへと変わります。例えば、新しいポータルの開設後にブロックされたファイルが急増している傾向や、特定の地域からのケースに悪意のあるリンクが集中している傾向などを把握できます。また、監査人や経営陣から Salesforce の保護対策について尋ねられた際も、最大 6 か月間の履歴とともに、信頼するダッシュボード上に証拠が用意されています。

ダッシュボード表示や 3 ステップのセットアップ手順を含む、連携の完全な解説ガイドを用意しています: 「Cloud Protection for Salesforce と Salesforce Security Center を連携する方法」をご覧ください。

Security Center を使用していない場合でも、同様のデータは Cloud Protection for Salesforce 内部のアナリティクスビューで利用可能であり、スキャンアクティビティ、検知、および傾向をカバーしています。Security Center との連携は、単にそれらのデータを他の Salesforce セキュリティシグナルと一緒に一元管理するための機能です。

すべてをスキャンし、すべてを可視化する

ネイティブのファイルスキャン機能は良い第一歩であり、標準で有効化されているのには理由があります。しかし、メールの添付ファイル、大容量ファイル、リンクは依然としてスキャンされずに通過してしまい、時間経過に伴う脅威の動向を把握する手段もありません。それこそが Cloud Protection for Salesforce の存在理由です。本製品はスキャンのギャップを解消し、Security Center を通じてモニタリングレイヤーを提供します。両方を導入することで、組織に入るすべてのファイルとリンクがチェックされ、監視可能になります。

各指標で推奨される表示項目（Field）を含む、項目ごとの完全な設定手順については、Security Center 連携ガイドを参照してください。

はじめましょう 

すでにご利用中のお客様; Security Center 連携機能はリリース 3.3 以降でご利用いただけます。最新リリースにアップデートし、セットアップガイドに従ってカスタム指標を登録してください。Cloud Protection for Salesforce 自体の設定変更は不要です。

まだご利用でないお客様: 開始方法は 2 つあります。無償の Salesforceのコンテンツリスク診断では、自社環境の実際の数値をもとに、現在スキャンされずに組織へ入ってきている脅威を可視化します。または、デモをご予約いただければ、ファイルスキャン、URL 保護、および Security Center 連携をライブ実演でご案内いたします。

よくある質問

Security Centerは、単一のダッシュボードから1つ以上の組織のセキュリティ状況（認証、権限、組織のヘルスチェックなど）を監視するためのSalesforce用ツールです。すでにSecurity Centerをお使いであれば、その存在理由を理解されていると思います。10個ものブラウザタブやスプレッドシートを行き来する代わりに、組織全体のセキュリティシグナルを1カ所で監視することができます。

そして今回、Cloud Protection for Salesforceが検知した脅威データも、その監視画面に統合できるようになりました。連携は簡単で、アラート、ファイルスキャンログ、URLスキャンログ、ブリーチ（漏洩）ログの4つのデータ種別に対応するカスタム指標をSecurity Centerに登録するだけで機能することができます。

本ガイドでは、Security Centerで可視化できる脅威データの内容とその重要性、パターンを実アクションへ繋げるトレンドの読み解き方、そして3ステップでのセットアップ方法について解説します。Security Centerを最大限に活用したい方に最適な内容となっています。

Security Centerで確認できる情報  

本連携により、Cloud Protection for Salesforceから4種類のデータを取り込むことができます。それぞれがSecurity Centerの「カスタムメトリクス」として登録されるため、ダッシュボードに表示させる項目を自由に選択可能です。

なぜこれが重要なのでしょうか？ Security Centerは、設定やアクセス権限の把握（ヘルスチェック、権限設定、ログインアクティビティなど）に優れています。しかし、Security Center単体では、組織内を行き交う「コンテンツ」そのもの – 顧客がアップロードしたファイル、ケース内のリンク、データ漏洩（ブリーチ）によって流出したユーザーの認証情報 – を監視することはできません。これらはユーザーに直接到達するリアルな脅威です。これらが可視化されていないと、まさに攻撃が発生する現場においてセキュリティ上の「盲点」が生じてしまいます。本連携はこの盲点を塞ぎ、問題発生時に確認すべきツールを1つ減らしてくれます。

アラート: 検知情報、設定変更、ジョブのステータス、グループ化されたブリーチイベントが重要度別で表示されます。何に優先して対処すべきかがひと目で把握できます。

ファイルスキャンログ: すべてのファイルスキャン結果について、判定結果と実施されたアクションを表示します。スキャンされた対象、安全性（ブロックされたか否か）、アップロード者、送信元、IPアドレスまで追跡できます。ケースやポータル経由で悪意のあるファイルが届いた場合、その一連の経緯がここに記録されます。

URLスキャンログ: Cases、Chatter、メール、リード、ToDo内でチェックされたすべてのリンクについて、判定とアクションの詳細を表示します。フィッシングリンクは受信トレイだけでなくSalesforceのレコード内にも届きます。本機能により、その足跡を他のセキュリティ監視と同じ場所で追跡できるようになります。

ブリーチログ: 認証情報（パスワード等）が過去のデータ漏洩で流出したことが判明しているユーザーの記録です。リスクレベル、漏洩元、パスワードがプレーンテキストで露出していたかどうかが含まれます。これは、アカウント乗っ取りの試みが迫っていることを知らせる最も早いアラートとなります。

トレンドが示すもの

個々のイベント情報も有用ですが、真の価値は「パターン」を把握することにあります。

Security Centerのすべてのメトリクスは時系列トレンド表示に対応しており、スキャンログを価値ある「シグナル」へと変換します。たとえば、新しい顧客ポータルを開設した翌週にブロック数が急増した、特定の地域からのケース経由で悪意あるURLが届いている、特定のユーザープロファイルにブリーチアラートが集中している、といった分析が可能です。データが一カ所に長期保存されて初めて、こうしたパターンが可視化され、迅速な対策を打てるようになります。

また、トレンド機能は管理者なら誰しもが監査人や経営陣から問われる「当社のSalesforceはどのように保護されており、その証拠を示せますか？」という質問への答えにもなります。本連携を利用すれば、経営陣がすでに信頼しているダッシュボード上に答えが用意されています。わざわざ別のツールからデータを集めてくる必要はなく、他のセキュリティ構成と並べてエビデンスを提示することができます。

必須要件と利用条件

始めるには以下の3つが必要です。

• Cloud Protection for Salesforce リリース3.3以降

• Salesforce Security Center のライセンス

• 権限セットおよびカスタムメトリクスを作成できる 管理者権限 

リリース3.3へアップグレードした後に作成されたレコードは、自動的にSecurity Centerへ連携されます。過去の履歴データについては、オプションのData Loaderバックフィル機能を使用して取り込むことが可能です。

セットアップ方法

設定はすべてSalesforceの「設定」画面内で完結します。Cloud Protection for Salesforce側の設定変更は不要です。

• ステップ1：権限の割り当て Salesforceの［設定］から「Manage Security Center（Security Centerの管理）」システム権限を含む権限セットを作成し、アクセスが必要な管理者に割り当てます。その後、アプリ起動ツールから「Security Center」を開きます。
• ステップ2：カスタムメトリクスの登録 ［設定］＞［Security Center］＞［設定］＞［カスタムメトリクス］へ進み、表示させたいデータ種別（アラート、ファイルスキャンログ、URLスキャンログ、ブリーチログ）ごとにメトリクスを作成します。各メトリクスについて、ソースオブジェクト、表示フィールド、テナントIDフィールド、トレンドの基準となる「レコード作成日」フィールドを選択し、保存して有効化します。
• ステップ3：ダッシュボードの確認 Security Centerのダッシュボードを開き、各メトリクスにデータが表示されていることを確認します。データが表示されない場合は［Update Data］をクリックしてください（Security Centerの同期周期の関係上、最初のロードには数分かかる場合があります）。

セットアップは以上です。各メトリクスの推奨表示フィールドを含むより詳細なフィールド設定については、「Security Center 統合ガイド」をご参照ください。

すべての情報を1カ所に  

セキュリティツールが信頼を得る方法は2つあります。「脅威を確実に防ぐこと」と「その仕事ぶりを可視化すること」です。本連携は、Cloud Protection for Salesforceが日々ブロックしている脅威アクティビティを、チームが普段から利用しているSecurity Centerダッシュボードへと集約します。

すでに当社のお客様ですか？ バージョン 3.3 以降をご利用であることを確認の上、詳細な セットアップガイド に従って、今すぐご利用を開始してください。

まだ当社のお客様ではありませんか？ デモをご予約 いただければ、Cloud Protection for Salesforce がユーザーに届く前に検知するあらゆる脅威とともに、連携機能の実演をライブでご覧いただけます。

よくある質問

その「ギャップ」は深刻な問題です。そして、多くの企業が認識している以上に大きな影響を及ぼします。

ビジネスを動かすデータ

実際のところ、自社のSalesforce組織に何が保管されているか考えてみてください。

• 進行中のすべての商談とその規模
• 顧客および見込み客の全データ（連絡先、対応履歴、長年にわたり蓄積されたアカウントインテリジェンス）
• 売上予測
• 契約更新日
• 契約条件
• 社内の事前共有文書以上に競合インテリジェンスが詰まった、営業コールノート

これらは単なる周辺データではなく、ビジネスの運用の中核です。採用計画の決定、プロダクト戦略の策定、そしてほぼすべての商談の中心に位置しています。データの紛失、破損、あるいは不正アクセスといった不測の事態が発生した瞬間、その影響は瞬く間に広がっていきます。

それにもかかわらず、多くのエンタープライズセキュリティプログラムにおいて、CRMは「後回し」あるいは「盲点」として扱われがちです。

なぜこの状況が生まれたのか

このギャップは決して不注意から生じたものではありません。セキュリティの考え方がクラウドの普及とともに歩んできた「経緯」を理解する必要があります。

これまでのエンタープライズセキュリティは、主にネットワークの「境界」を防衛する設計でした。つまり、自社ネットワーク内にあるものを保護する考え方です。SaaSプラットフォームが登場した際も、このマインドセットは完全には追いつきませんでした。「SaaSプロバイダーがセキュリティを担保しているため、社内チームは他の領域に専念できる」という無意識の前提が形成されたのです。この前提は決して正確ではありませんでしたが、セキュリティプログラムの構成や予算配分に深く組み込まれていきました。

特にSalesforceの場合、その高い信頼性とエンタープライズレベルのコンプライアンス認定実績が、この認識を後押ししました。「SOC 2を満たしているのだから安全に違いない」という安心感から警戒が緩み、CRMは脅威モデルの対象から外れていったのです。

「Salesforceがビジネスに不可欠であると認識されながらも、セキュリティ上の重要拠点として扱われないケースは、現在でもめずらしくありません。転機となるのは多くの場合、組織がSalesforceを『単なるSaaSアプリケーションの1つ』ではなく、**『最も価値あるデータストアの1つ』**と再定義した瞬間です。このマインドセットの転換が起きて初めて、ガバナンス、アイデンティティ管理、継続的モニタリング、そしてリカバリといった議論が自然に進むようになります。他の最も重要な基幹システムに適用している規律を、同様に向けるようになるのです。」Karmina Aquino、Cloud Protection by WithSecure – 脅威インテリジェンス責任者

攻撃者はすでに知っている

不都合な真実ですが、貴社のデータにアクセスしようとする脅威アクターは、そのような甘い前提では動いていません。

セキュリティが侵されたSalesforce組織には、極めて高い価値が存在します。広範なアクセス権限を持つアカウントが1つ乗っ取られるだけで、全顧客リスト、パイプラインの全フェーズ、価格構造、更新時の脆弱性などが白日に晒されます。これらは、競合他社や悪意のあるアクターが大金を払ってでも手に入れたがるインテリジェンスです。

攻撃者は、盗み出した認証情報、インフォスチーラーのログ、ソーシャルエンジニアリングを駆使してCRMプラットフォームへ正常なアクセス権を装って侵入する手法を強めています。高価値なビジネスデータや信頼性の高い顧客関係へダイレクトにアクセスできるからです。侵入した組織から抽出したアカウント・商談データを基に、極めて精巧なソーシャルエンジニアリング攻撃が組み立てられます。

その間、自社のセキュリティチームは「フィッシングメールを受信したエンドポイントの特定」に追われ、そのアクセス権を使って攻撃者が「その先に何へアクセスしたか」まで手が回っていないのが実状です。

「脅威アクターにとって、CRMは単なる顧客データベースではなく、『ビジネスの運用設計図』そのものです。一度正規の認証情報を入手すれば、キーパーソン、今後の更新時期、高額商談、信頼関係、そして意思決定者を正確に特定できます。このインテリジェンスにより、標的の優先順位付けや極めて説得力の高いソーシャルエンジニアリングが可能となり、詐欺、フィッシング、恐喝といった二次攻撃の有効性が飛躍的に高まります。最初の侵害は、多くの場合ほんの始まりに過ぎません。」– Karmina Aquino

運用における「適用範囲」の実効リスク

Salesforceを適用範囲外とみなすことは、抽象的なリスクにとどまらず、具体的な影響をもたらします。つまり、このプラットフォームがペネトレーションテストの対象となることはほとんどありません。セキュリティ監査の際にも、Salesforceの設定は検証されません。ユーザーのアクセス権限は、Active Directoryのように定期的な見直しサイクルが適用されません。また、退職処理のプロセスには、CRM特有の不備が見受けられることがよくあります。他のすべての領域に適用されるデータ分類ポリシーは、この組織には単純に適用されないのです。

結果として、社内で最も価値ある資産の1つが、一般的なファイル共有サーバーよりも緩い監視下で運用されるという事態を招いています。

今後のアプローチ

しかし、解決策は明確です。CRMをセキュリティスコープに含めるために、セキュリティプログラム全体をゼロから再構築する必要はありません。必要なのは、「Salesforceは最重要資産であり、それ相応の保護を行う」という明確な意思決定です。誰がアクセス権を持ち、その権限で何ができるのか、データはどう保護されているのか、そして万一の事態が発生した際のリカバリ体制はどうなっているかを正確に把握することを意味します。

Cloud Protection for Salesforce のような専用ソリューションが存在するのはまさにそのためです。連続的なモニタリング、アクセスの可視化、不測の事態における迅速な復旧機能など、他の基幹ビジネスシステムと同等の保護をCRMにも提供します。

営業チームはすでに、Salesforceがビジネスにおいて最も重要なシステムであることを知っています。今度は、セキュリティプログラムがその認識に追いつく番です。

これが、現代におけるシャドーITの姿です。企業から支給されたノートPC上で個人的に利用される消費者向けアプリのことではありません。企業の最も重要な基幹システム内部に潜み、ほぼ監視されることもなく、セキュリティチームすらその存在を把握していないサードパーティ接続の静かな集積こそが、真の脅威なのです。

拡大を続ける攻撃対象領域

Salesforceは、外部接続を前提として設計されています。AppExchangeだけでも数千ものサードパーティ製アプリケーションが掲載されており、大半のエンタープライズ組織では、マーケティングプラットフォーム、データ補完サービス、CPQツール、カスタマーサクセス機能、独自開発のミドルウェアなど、数多くの連携機能を並行して運用しています。導入時の接続はいずれも正当な目的によるものです。問題は、その「後」に起こります。

サードパーティ製アプリがユーザーに代わってSalesforceへアクセスすることを許可する「OAuthトークン」は、デフォルトでは有効期限が切れません。明示的に取り消さない限り、無期限に有効であり続けます。従業員の流動性が高く、長年にわたり多様な連携プロジェクトを実施してきた大規模組織では、「実際に使われている接続アプリ」と「存在し続けている接続アプリ」の間に大きな乖離が生じます。

広範な権限を持つユーザーによって認証された連携機能は、そのツールが現在使われているか、開発元ベンダーが買収されたか、あるいは社内の誰もその存在を覚えていないかに関わらず、当時と同等のアクセス権を保持し続けます。

休眠状態の接続は、すべて潜在的な侵入経路となります。仮にサードパーティベンダーがサイバー攻撃の被害に遭えば、そのベンダーがアクセス権を持つすべての顧客のSalesforce組織がリスクに晒されます。攻撃者は必ずしも自社を直接狙う必要はありません。エコシステム内で最も脆弱なサードパーティを標的にするだけで十分なのです。

「接続アプリのアセスメントを実施すると、毎回のように最大の驚きとして挙げられるのは、新たな脆弱性の発覚ではなく、誰かが付与したまま放置されている膨大な数のOAuthトークンです。プロジェクトのために作成された連携機能は、プロジェクト終了後もトークンだけが機能し続けます。可視化の実現こそが、多くのチームにとってセキュリティ向上への確かな第一歩となります」と、Cloud Protection by WithSecure のSalesforceアーキテクトであるTapas Tripathi (タパス・トリパティ) は指摘します。

セキュリティチームが見落とす理由

従来のセキュリティ監視ツールは、この種の問題に対応するようには設計されていません。

• エンドポイント検出ツール： デバイスの挙動を監視
• ネットワーク監視： 通信トラフィックを監視
• SIEMプラットフォーム： インフラ全体のイベントを相関分析

いずれのツールも、アプリケーション層において「何がSalesforceデータへのアクセスを許可されているか」をネイティブに把握する機能は備えていません。

さらにSalesforce内部においても、接続アプリの管理は「セキュリティ機能」ではなく「管理者機能」として位置づけられています。許可された接続の点検はSalesforce管理者の役割ですが、自動アラートや定期的なレビュープロセスが整備されていない場合、事前に対策が講じられることは稀です。情報はプラットフォーム内に存在するものの、リスクとして可視化される形では提示されません。管理者が能動的に確認する意図を持ち、適切な確認場所を把握し、さらに対応に必要な時間を確保できて初めて顕在化するのです。

結果としてこのリスクは、セキュリティ、IT、Salesforce管理の狭間に放置されることになります。所有者も不在で、誰からも点検されず、新たな連携が追加されるたびに拡大を続けていきます。

データ露出のリスク

Salesforce内に格納されている情報の重要性を考慮すると、生じるリスクは極めて深刻です。組織への読み取り権限を持つ接続アプリは、顧客リスト全体のほか、商談パイプライン、取引先履歴、連絡先詳細などを参照できます。変更権限を持つアプリであれば、レコードの改ざんや削除も可能です。さらに、連携時の権限スコープ設定においては、厳密な最小権限の定義よりも利便性が優先され、必要以上に広範なアクセス権が付与されがちなのが実状です。

サードパーティベンダーがデータ侵害に見舞われた際、問題となるのは「自社に代わって保持させていたデータ」だけにとどまりません。「相手のシステムクレデンシャルが、自社環境のどこまでアクセス可能だったか」という点が重大な焦点となります。接続アプリの監査を実施していない組織にとって、その調査結果はきわめて厳しいものとなり得ます。

「サプライチェーンリスクの本質は、自社が書いていないコードだけでなく、取り消していないアクセス権にもあります。ほとんど意識にすらのぼらないベンダーの接続アプリひとつが過剰な権限を持っていただけで、軽微なインシデントで済むはずだった事案が、致命的なデータ侵害へと発展する差を生み出すのです」とTripathiは締めくくります。

今すぐ取り組むべきアプローチ

第一歩は、接続アプリの運用状況を可視化することです。これには以下のアクションが含まれます。

• Salesforce組織へのアクセスが許可されているすべてのアプリケーションの完全なインベントリ作成
• 各アプリが保持している権限スコープの確認
• 各アプリの最終利用日時の特定
• 認証を行ったユーザーの在籍状況の確認

可視化の後は、定期的な運用プロセスの確立が必要です。休眠状態または廃止された連携機能のアクセス権を取り消す定期レビューサイクルの導入、新規接続時における「最小権限の原則」の徹底、そしてユーザーの退職プロセスにおける「該当ユーザーが過去に認可した連携機能の点検」を組み込むことが不可欠です。

接続アプリに潜むリスクは解決可能です。ただしそれには、課題の解決と「見えないリスクの可視化」を実現する適切なツールの導入に対して、明確な責任を持つ体制づくりが前提となります。

営業担当が案件を成約させるために制限されたオブジェクトへの一時的なアクセスが必要になり、権限が付与されたものの二度と取り消されない。マネージャーが新しい役に就いたが、以前の役職のアクセス権をそのまま保持している。コンサルタントが導入中に管理者権限を与えられ、そのまま放置される。元の権限セットに何が含まれていたか誰も確認せずに、権限セットが複製される。

個々に見れば、どれも重大な決定には思えません。しかし、これらが積み重なることで、誰も設計しておらず、誰も完全には理解していないアクセス権限の景観が作り出されます。これにより、何か重大な問題が発生するまでめったに表面化しないリスクが生まれるのです。

なぜ「権限の肥大化」が起きるのか

Salesforceのセキュリティモデルは極めて複雑です。プロファイル、権限セット、権限セットグループ、ロール階層、共有ルール、フィールドレベルセキュリティ、オブジェクトアクセス——それぞれの層が相互に作用する仕組みは、経験豊富な管理者にとっても直感的ではない場合があります。立ち上げたばかりの組織であればこの複雑さも管理可能ですが、何十人もの管理者と何百人ものユーザーを抱え、単発の設定変更を繰り返しながら5年〜10年運用されてきた組織では、「誰が何を見ることができ、何を行えるのか」の全体像を把握することはほぼ不可能です。

この問題を慢性化させているのは「手軽さ」です。Salesforce管理者は通常、ビジネスを止めることなくスムーズに進めること（新しいユーザーのオンボーディング、商談サイクルの支援、新しいワークフローの有効化など）に集中しています。権限を「付与」するのは数秒で済みます。しかし、その権限が「まだ存在するべきか」を監査するには、ほとんどのチームが持っていない時間とツールが必要です。結果として、アクセス権は絶え間なく追加され、削除されることはまずないという「一方通行のラチェット構造」が完成します。

また、組織全体のアクセス状況に責任を持つ単一の所有者が存在しないことも珍しくありません。所有者がいなければ、「この人物にこの権限がまだ必要なのか？」という最も重要な問いを投げる人もいなくなります。

「管理者は、特定のレポート作成や連携の課題を解決するために、オブジェクトレベルの『すべて表示／すべて変更』（あるいは組織全体の『すべてのデータの参照／すべてのデータの変更』）を付与し、そのまま元に戻さず放置しがちです。これにより、その権限セットを持つすべてのユーザーに対して、共有ルール、OWD（組織全体の共有設定）、レコードレベルの制限がサイレントに無効化されてしまいます」 Tapas Tripathi（タパス・トリパティ）（Cloud Protection for Salesforce, Salesforce Architect）

なぜ放置されてしまうのか

根本的な問題は「可視性の欠如」です。ほとんどの組織は、Salesforce内で誰が何にアクセスできるのかを示す明確で最新のマップを持っていません。標準のレポート機能でもある程度の情報は抽出できますが、プロファイル、権限セット、共有ルールの相互作用を考慮した「実質的な権限」の有意義な全体像を得るには、膨大な手作業が必要です。ほとんどのチームにとって、トラブルが起きる前にその労力を正当化することは困難です。

さらに「組織的なギャップ」もあります。Active Directoryや基幹インフラにおいてはアクセス権の定期監査が標準的実務となっていますが、Salesforceに同様の厳密さが適用されることは滅多にありません。ITセキュリティ、Salesforce運用管理、コンプライアンスのいずれの部門にも明確に属していないため、エアポケットに落ちてしまいがちなのです。結果として、最小権限の原則に基づく基本監査で落第するような権限設定が、「誰も見ていない」という理由だけで何年も放置されることになります。

「最小権限のプロファイルを一から作成する代わりに、チームは管理者プロファイルを複製してチェックボックスを数個外すだけで済ませてしまいます。元となるプロファイルが非常に強力であるため、ユーザーの管理、すべてのデータの変更、Apexの作成、アプリケーションのカスタマイズといった強力な権限が、クリーンアップ後も気づかれずに残ってしまうのです」 Tapas Tripathi

事態が悪化した際の影響

権限が過剰に付与されたアカウント自体が情報漏洩を引き起こすわけではありません。むしろ、その深刻度を決定づける要因となるのです。標準ユーザーアカウントを標的としたフィッシング攻撃は、単に「不運な一日」に過ぎません。しかし、システム管理者権限、すべてのデータに対する変更権限、あるいは広範なデータエクスポート権限を持つアカウントを標的とした同じ攻撃は、まったく異なるインシデントとなります。パイプラインの全容が丸見えになり、記録を大規模に流出させたり破壊したりする能力が得られ、さらには接続されたシステムへの侵入経路となる可能性さえあります。権限モデルは、単にユーザーが何ができるかを定義するだけではありません。何か問題が発生した際の被害範囲を定義するものでもあるのです。

これは内部者リスクについても同様です。通常の営業担当者のアクセス権限を持つ退職予定の従業員でも、損害を与える可能性があります。長年の勤務を通じて権限が拡大してきた従業員であれば、その被害はさらに甚大になるでしょう。また、権限の拡散は目に見えないため、セキュリティチームは事後になって初めて、その従業員がどのような行動をとることができたのかを知るケースが少なくありません。

設定ミスの影響も無視できません。共有ルールが過度に寛容すぎると、業務上の理由がないユーザーに意図せずレコードが公開されてしまう可能性があります。フィールドレベルのセキュリティ上の脆弱性により、契約金額、個人情報、戦略的顧客の詳細といった機密データが、意図したよりもはるかに多くのユーザーに閲覧されてしまう恐れがあります。

まとめ（今後の対策）

権限ギャップを埋めるための第一歩は、「可視化」を手に入れることです。つまり、組織内のすべてのユーザーの「実質的な権限」を確認できるようにすることを意味します。割り当てられたプロファイルだけでなく、適用されているすべての権限セット、共有ルール、ロール階層の組み合わせによる「最終的なアクセス結果」を把握しなければなりません。

そこから、「定期的な監査サイクル」を構築します。現在の役割を反映していないアクセス権の特定、休眠アカウントの検出、特定の事情で一時的に付与した例外権限が永久化しないようにするための構造化されたプロセスです。これは一回限りのプロジェクトではなく、日常的な運用プロセスであり、誰も実行する時間がないような手作業ではなく、プロセスを持続可能にするための適切なツール選定が必要となります。

「権限ギャップ」の問題は地味で目立たず、華やかさもありませんが、ほぼ確実に防ぐことができる問題です。だからこそ、今すぐに取り組む価値があるのです。