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

ビジネスを動かすデータ

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

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

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

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

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

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

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

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

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

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

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

セキュリティが侵された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 for Salesforce 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

事態が悪化した際の影響

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

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

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

まとめ（今後の対策）

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

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

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

残念ながら、そうではありません。「Salesforceなら安全」という前提は、すでに過去のものとなりました。Salesforce上でビジネスに不可欠な業務を動かしている組織にとって、「安全だという認識」と「厳しい現実」のギャップは、真に危険と言えるほどに広がっています。

脅威の進化

従来のランサムウェアは、ローカルファイルを暗号化し、復号キーと引き換えに金銭を要求する手法でした。それは荒っぽく、目に見えやすく、犯人の特定も比較的容易でした。攻撃者はシステムへのアクセスを必要とし、その被害は即座かつ明白に現れたのです。

しかし、現代のランサムウェアはより洗練され、粘り強く、そしてはるかに標的を絞り込んでいます。攻撃者は自らの存在を明かす前に、環境の内部で数週間から数ヶ月を過ごします。侵入するとシステムをマッピングし、最も価値のあるデータを特定した上で、自らが選んだ絶好のタイミングで最大の混乱を引き起こせるよう配置につくのです。

彼らの目的は、単にファイルを暗号化することではありません。復旧をできるだけ苦痛で、コストのかかるものにすることであり、それを止めさせるために身代金を要求することです。

その結果、広範な脅威グループによる恐喝キャンペーンの一環として、SalesforceのようなSaaSプラットフォームが狙われるケースがますます増えています。現代のランサムウェアグループは、インフラ自体を暗号化することはできない（権限がない）ため、代わりにビジネスに不可欠なデータを窃盗、改ざん、または削除することで、被害者への圧力を強めます。彼らが握る恐喝の交渉材料は、ロックされた画面ではありません。「顧客データベースを公開する」「商談パイプラインをすべて消去する」「復旧不可能なレベルでレコードを破損させる」という脅迫です。身代金の要求は、そこからスタートします。

「セキュリティ機能は侵害の可能性を減らすように設計されていますが、それが万全であると過信するべきではありません。特権アクセスが悪用されたとき、最終的にどれだけ迅速に復旧できるかを決定づけるのは、十分にテストされたバックアップおよび復旧戦略です」Karmina Aquino（Cloud Protection for Salesforce、脅威インテリジェンス責任者）

攻撃者がSalesforce組織に侵入する経路

ほとんどのセキュリティチームが想定しているよりも、侵入の起点は遥かに多く存在します。

• Salesforceの資格情報を盗み出すフィッシングメール
• 連携していたサードパーティ製アプリが後に侵害され、そこから付与されたOAuthトークン
• ユーザーが異変に気づく前にセッションCookieをキャプチャする、エンドポイントのマルウェア感染
• アクセス権が完全に削除されていなかった元従業員のアカウント

ひとたび内部に侵入されると、適切なアクセス権を持つ攻撃者は、従来のセキュリティアラートを1つも作動させることなく、甚大な被害をもたらすことができます。恐喝キャンペーンの一環として、彼らは以下のような行動に出る可能性があります。

• データベース全体の窃盗: レコードに一切触れる前に、顧客やパイプラインのデータベース全体を外部に流出させ、交渉のカードにする。
• レコードの大量削除: レコードを大量に削除し、それらがゴミ箱から完全に消去（パージ）されるまで潜伏することで、被害者の復旧手段をなくす。
• データのサイレント改ざん: すぐには気づかない方法でデータを破損させ、後続のすべての業務プロセスやデータの信頼性を根底から揺るがす。
• 正規の操作への擬態: これらすべてをSalesforceの標準UIから、正規の資格情報を使って行うため、監視している側からは「通常のユーザー行動」のように見える。

そこには暗号化もなければ、ロックされた画面に表示される身代金要求のメモも（少なくとも初期段階では）ありません。しかし、彼らは着実に交渉のレバーを構築しており、組織がその要求に抵抗できるかどうかは、「事件が起きる前にどのような保護策を講じていたか」に完全に依存するのです。

復旧における課題

こここそが、適切なバックアップ戦略の欠如が致命傷となるポイントであり、攻撃者の恐喝キャンペーンが真の権力を得る場所でもあります。もし攻撃者が大量のレコードを削除または破損させ、あなたがSalesforceの標準機能（15日間のゴミ箱、週次のCSVエクスポートなど）だけに頼っているとしたら、復旧の選択肢は著しく制限されます。そして、その「制限」こそが攻撃者の狙いであり、身代金の要求に現実味を持たせる原因なのです。

週次のエクスポートでは、オブジェクト間のリレーション（紐付け）データ、ワークフローの履歴、設定情報は復元されません。手に入るのは、ある特定の時点に存在したレコードの「CSV）」だけであり、それが被害に遭う前の正常な状態であるという保証すらありません。さらに、問題に気づくのが15日を過ぎてしまえば、ゴミ箱はすでに空になっています。問題の発見が遅すぎた組織にとって、復旧とは「不完全なデータからの再構築」「情報確認のための顧客や見込み客への再アプローチ」、そして「機能が低下したCRMでの数ヶ月に及ぶ業務」を意味します。失われた案件、失墜した顧客からの信頼、そして社内の混乱という観点から見たビジネスコストは、攻撃者が要求する身代金の額を容易に跳ね上がることになります。

結論（ここから得られる教訓）

Salesforceにおけるランサムウェアへの耐性（レジリエンス）とは、プラットフォームのインフラを保護することではありません。なぜなら、それはSalesforce社自身が担保しているからです。真に重要なのは、攻撃者があなたのCRMデータを恐喝の材料として悪用（窃盗、破損、削除）した場合に、組織が迅速かつ完全に復旧でき、攻撃者の要求の根拠を根こそぎ奪い取れる状態を作っておくことです。

そのためには、上書きされていく週次のエクスポートではなく、きめ細かな復元機能を備えた、継続的かつ自動化されたバックアップが必要です。ゴミ箱の中身に関係なく、正常だと分かっている特定の時点のレコード、リレーション、および設定をピンポイントで復元できる能力が求められます。信頼性の高い復旧態勢こそが、恐喝の脅威を無効化する唯一の手段なのです。

「ビジネスに不可欠なプロセスがSalesforceのようなSaaSプラットフォームに移行するにつれ、防衛（防御）と同じくらい『回復力（レジリエンス）』が重要になってきます。組織は、攻撃者を侵入させない計画だけでなく、正規の資格情報が悪用された場合にいかに迅速に復旧するかという計画も立てる必要があります」Karmina Aquino

ランサムウェアグループは、あなたのビジネスを人質に取るために、組織の物理インフラに触れる必要すらありません。ここで問われるのは、「あなたの組織の復旧態勢が、攻撃者のハッタリを跳ね返せるほど強固であるかどうか」、ただそれだけなのです。

最近、Salesforceをご利用のお客様の環境におけるフィッシング活動を調査していた際、新たな「OAuthデバイスコードフィッシング」のキャンペーンを発見しました。

Microsoft社はすでに、このキャンペーンの背景にあるOAuthの仕組みや攻撃者のインフラに関する優れた技術分析を公開しています。本記事では、その分析を繰り返すのではなく、同記事では触れられていない新たな観察結果と、なぜこれがSalesforce管理者にとって今なお重要なのかに焦点を当てます。

なじみの手法 

デバイスコードフィッシング自体は新しいものではありません。

すでに2024年の初頭には、資格情報（認証情報）を盗み取ることなくOAuthトークンを取得するために、Microsoftのデバイス認可グラント（Device Authorization Grant）を悪用するキャンペーンが観測されていました。しかし、ここ数ヶ月で「Phishing-as-a-Service（PaaS：サービスとしてのフィッシング）」キットが大幅に進化し、サイバー犯罪のエコシステム内でより広く採用されるようになったことで、この手法は急速に主流化しつつあります。現在のキャンペーンでは、標的となるユーザーに違和感を与えないシームレスな体験を提供するため、プロセス全体を正規のコンテンツホスティングやコラボレーションプラットフォーム、テンプレート型のフィッシングページ、そして正規のIDプロバイダー（IdP）による認証の背後に隠蔽する傾向が強まっています。

主な発見

フィッシングフレームワークの分析により、以下の事実が明らかになりました。

• MicrosoftとGoogle両方のデバイスコード認証への対応
• コラボレーションサービスやMicrosoftサービスを騙る30種類以上の囮（ルアー）テンプレート
• ランタイムでのローカライズに対応した14の言語サポート
• 中継地点の囮として、Proton DocsやLark Docsなどの正規のSaaSプラットフォームを悪用
• バックエンドのセッショントラッキングとフロントエンドのポーリングによる、デバイスコードワークフローの自動化

観測されたデバイスコードフィッシングの流れ

Microsoftは根本にあるOAuthの仕組みを詳細にドキュメント化していますが、今回の調査で分析されたサンプルからは、別の興味深い視点が見えてきました。それは、「フィッシングキャンペーンがどのように被害者に届けられるか」という点です。攻撃者は、ユーザーを直接悪意のあるログインページに誘導するのではなく、正規のコンテンツホスティングプラットフォーム、カスタマイズ可能なフィッシングフロントエンド、そして正規のMicrosoftまたはGoogleのデバイスコード認可フローという、複数のステージを連鎖（チェーン）させています。これにより、最初から最後まで信頼できるように見えるワークフローを構築しています。

図1. 分析中に観測された大まかな流れ （※この図は、根本的な認可のやり取りではなく、フィッシングキャンペーンがどのように配信されるかに焦点を当てるため、OAuthプロトコルを意図的に簡略化しています）

すべては1つの文書から始まる

このキャンペーンは、多くの文書ベースのフィッシング攻撃と同様に始まります。 

ユーザーは、共有文書を装ったメールの添付ファイルを受け取ります。 

図2. スペイン語のメールサンプル

このキャンペーンが幅広い言語をサポートしている点は注目に値します。この言語サポートは、添付ファイルから中継ファイル、そしてフィッシングページに至るまで一貫して見られます。

図3. 複数言語の添付ファイル

多くのフィッシングキャンペーンとは異なり、これらの文書は中継ホストとして正規のSaaSプラットフォームへと誘導します。標的ユーザーをすぐにフィッシングインフラに誘導するのではなく、Proton Docs、Lark Docs、Zoho Writer、Medium、Bookwiz、Mindsmithなどの本物のサービスを使用して、悪意のあるフィッシングインフラへのリンクを含む、一見無害なコンテンツをホストしていました。

図4. さまざまな正規SaaSプラットフォームでホストされている、ローカライズされた中継文書

このアプローチにはいくつかの利点があります：

• 文書自体が正規のSaaSプラットフォームにホストされている
• URLが信頼できるように見える
• レピュテーションベースのフィルタリングで文書がブロックされにくい
• フィッシングインフラがチェーンの「1クリック深い」場所に隠れる

このほか、Appsmith、Playbook、Soloist.ai、7taps、Ouro Foundationなどのプラットフォームも悪用が観測されました。

フロントエンドのフィッシングコンポーネント 

元のページは主に、ランタイムデコード、エンコードされたペイロード、動的レンダリングを使用し、高度に難読化されたJavaScriptで構成されていました

デコードすると、これが単なる静的なフィッシングページではなく、フィッシングフレームワークであることが明白になりました。

フィッシングフロントエンドは以下の役割を担っています： 

• テンプレートに基づく偽ページのレンダリング
• ローカライズ（多言語化）
• クリップボードへのコピー
• MicrosoftまたはGoogleのデバイスコードページの表示

デコードされたフロントエンドは、OAuthトークンを直接処理していないようです。代わりに、攻撃者が制御するAPIエンドポイントをポーリングしてセッション状態を確認しています。このことから、OAuthデバイスコードの生成とトークンのポーリングは、攻撃者が制御するOAuthクライアントまたはバックエンドアプリケーションを介して、サーバー側で行われている可能性が高いと考えられます。

囮のテンプレート

デコードされたJavaScriptからは、ページのレイアウトと言語・メッセージを分離した、テンプレート駆動型のレンダラーが確認されました。

コードからは、30種類以上の囮テンプレートに対応していることが判明しています。

図5. 囮テンプレートを構築するための関数

その中には、以下のような文書共有サービスが含まれていました： 

• OneDrive  
• SharePoint  
• Dropbox  
• Google Drive  
• OneNote  
• DocuSign  
• Adobe  

また、以下のようなMicrosoftブランドのワークフローも含まれていました：

• Teams meetings  
• Planner  
• Forms  
• Intune  
• Bookings  
• Password Reset  
• MFA Setup  
• Quarantine notifications  
• Copilot  
• Stream  
• Whiteboard  
• Yammer 

図6. さまざまな囮のテーマ

多言語対応

もう1つの興味深い発見は、ローカライズ（現地語化）のサポートです。

デコードされた翻訳テーブルは、少なくとも以下の14言語に対応していました。 

• English  
• Dutch  
• German  
• French  
• Spanish  
• Portuguese  
• Italian  
• Turkish  
• Polish  
• Russian  
• Japanese  
• Korean  
• Chinese  
• Arabic  

言語ごとに別々のフィッシングページを維持するのではなく、このフレームワークは共通のHTMLテンプレートをレンダリングした後に、インターフェースの文字列をローカライズされた同等の文字列に置き換えます。 

図7. ローカライズされた文字列

これにより攻撃者は、同じバックエンドを再利用しながら、さまざまなコラボレーションプラットフォームや業務ワークフローに合わせた、標的ユーザーの言語による囮を提示することができます。

図8. 同じ囮テンプレート、異なる言語

IDプロバイダーのサポート

デコードされたフロントエンドの分析により、このキャンペーンが複数のIDプロバイダー（IdP）に対応していることが示唆されました。

図9. MicrosoftとGoogleへの対応

使用するIDプロバイダーは、構成設定によって決定されます。

Microsoft用設定時: 標的ユーザーを https://login.microsoftonline.com/common/oauth2/deviceauthに誘導します。 

図10. 正規のMicrosoftのプロンプト画面

Google用設定時: 代わりに https://www.google.com/deviceを使用します。

図11. 正規のGoogleのプロンプト画面

構成

各フィッシングページをハードコーディングするのではなく、フロントエンドは単純な設定オブジェクトを読み込んで囮のレンダリング方法を決定します。設定には、視覚的なテーマ、文書のメタデータ、送信者名、言語、および認証ワークフローが指定されています。これにより、わずかなパラメータを変更するだけで、同じコードベースから多種多様なフィッシングの囮を生成することができます。

今回のサンプルでは、フレームワークはOneDriveのテーマを選択し、PDF文書を表示し、送信者名と文書タイトルをカスタマイズし、インターフェースをフランス語にローカライズし、デバイスコードのワークフローを使用するようにページを設定していました。

図12. 構成のサンプル

図13. 構成に基づいて生成された囮画面

この設定駆動型のアプローチにより、攻撃者はブランド、言語、文書タイプごとに別々のフィッシングページを管理することなく、数個のパラメータを変更するだけでキャンペーンを迅速に適応させることができます。

攻撃者が制御するOAuthバックエンド／クライアント

インフラのこの部分は外部からは見えませんが、おそらく以下の役割を果たしていると考えられます：

• IDプロバイダーへのデバイスコードの要求
• device_code、user_code、セッション情報の保存
• ユーザーが認可を完了するまで、IDプロバイダーのトークンエンドポイントをポーリング
• 認可ステータスの監視
• 簡略化したステータスをフロントエンドに公開
• アクセストークンおよびリフレッシュトークンの取得

資格情報を狙う通常のフィッシングとは異なり、デバイスコードフィッシングはユーザーのパスワードを盗んだり、MFAをバイパスしようとはしません。

代わりに、標的となったユーザーは、IDプロバイダーとの間で正規の認証フローを完了します。MFAが必要な場合でも、ユーザーは正規の認証プロセスを進めていることになります。この攻撃が成功するのは、認証（Authentication）ではなく、認可（Authorization）を悪用しているからです。

攻撃の最終ゴールは、単にユーザーに確認コードを入力させることではありません。攻撃者が制御するOAuthアプリケーションを認可することにより、標的ユーザーはそのアカウントへのAPIアクセス権を付与してしまいます。IDプロバイダー、アプリケーション、および付与された権限によっては、攻撃者がメール、ファイル、コラボレーションデータ、またはその他のクラウドリソースにアクセスできるようになる可能性があります。企業環境では、この委任されたアクセス権により、追加の資格情報を必要とせずに、接続されたMicrosoftサービス間を横方向に移動できるようになる場合もあります。盗まれた認可は、最終的にデータの窃盗、ビジネスメール詐欺、組織内でのラテラルムーブメント、あるいは恐喝に悪用される恐れがあります。

オペレーター主導から自動化されたフィッシングへ 

以前に私たちが文書化したSalesforceデバイスフロー攻撃との最大の違いの1つは、このフィッシングフレームワークに組み込まれている自動化の度合いです。

過去のSalesforceのキャンペーンでは、標的ユーザーとのリアルタイムのやり取りに大きく依存しており、しばしばビッシング（電話フィッシング）などを用いてユーザーを説得し、有効期限が切れる前に確認ページにアクセスさせて短寿命のデバイスコードを入力させることがよくありました。

初期のMicrosoftデバイスコードフィッシングキャンペーンも、同様の課題に直面していました。デバイスコードは通常、メールやメッセージで直接配信されるため、コードがすぐに失効してしまうことから、タイミングが極めて重要でした。

しかし、今回分析したフレームワークは、その制限をほぼ完全に解消しています。

攻撃者が制御するバックエンドが常に新鮮な認可セッションを管理し、フィッシングフロントエンドがそのステータスをリアルタイムで追跡します。標的ユーザーの視点からは、ワークフローはきわめてシームレスです。ユーザーは単に文書共有の画面を進め、表示されたコードを入力するだけです。

これにより、コードの失効に伴う緊急性が大幅に軽減され、攻撃者がリアルタイムでやり取りを調整する必要がなくなり、キャンペーンの規模を拡大することが格段に容易になります。

Salesforce管理者が注意すべき理由 

このキャンペーンは最終的にMicrosoftやGoogleのアイデンティティ（ID）を悪用するものですが、私たちがこれに遭遇したのは、Salesforceのお客様環境を標的としたフィッシング活動を調査しているときでした。

観測されたケースでは、フィッシングメールはSalesforceと連携する業務ワークフローを通じてユーザーに届いていました。これは、最終的な攻撃対象がSalesforceプラットフォームの「外」にある場合でも、Salesforceが攻撃の侵入口になり得ることを示しています。

ユーザーがフィッシングのワークフローに従ってしまうと、攻撃者が次に狙うのはSalesforceではなく、ユーザーのデジタルアイデンティティです。

攻撃者は、Salesforceの運用に影響を与えるために、必ずしもSalesforceへの直接的なアクセスを必要としません。そのアイデンティティが侵害されると、メール、クラウドストレージ、コラボレーションプラットフォーム、内部文書、業務上のコミュニケーションが漏洩する可能性があります。そして、それらと同じリソースが、Salesforceのビジネスプロセスを支えていたり、顧客の機密情報を含んでいたり、取引の承認やSalesforce連携システムとのやり取りに使用されていることが非常に多いのです。

したがって、Salesforceユーザーを保護することは、これらの攻撃がユーザーに到達するまでの「通信チャネル」を保護することでもあるのです。

推奨対策

OAuthの認可は最終的にSalesforceの外部で行われますが、組織はフィッシングキャンペーンがSalesforce連携のワークフローを通じてユーザーに到達する可能性を低減させる必要があります。

Salesforce管理者は以下の対策を検討すべきです：

• Email-to-Case（メールからケース）やその他の受信メールワークフローを、フィッシングの添付ファイルや文書共有の囮から保護する。
• メールの統合機能を通じてSalesforceに取り込まれる外部コンテンツをレビューする。
• 正規のMicrosoftやGoogleの認証ページであっても、フィッシング攻撃の一部である可能性があることをユーザーに教育・訓練する。
• ID管理者と連携し、不審なデバイスコード認可や、新しく認可されたOAuthアプリケーションがないかを調査する。

Cloud Protection for Salesforceをご利用中のお客様は、PHISH/PDF.Agent 検出機能により、これらの文書ベースのフィッシングキャンペーンから保護されています。ユーザーがフィッシングインフラに到達する前に攻撃を阻止することが可能です。

結論

今回の調査は、攻撃者がフィッシングワークフローに正規のクラウドサービスをいかに巧妙に組み込んでいるかを示しています。ユーザーを直接悪意のあるインフラに誘導するのではなく、信頼された文書ホスティングプラットフォーム、カスタマイズ可能なフィッシングフロントエンド、そして正規のMicrosoftまたはGoogleの認証ページを連鎖させることで、最初から最後まで見慣れた安心感のある体験を作り出しています。ワークフローの各ステップは、単体で見ればどれも正規のものに見えます。これらを一連の流れとして捉えて初めて、攻撃の全貌が明らかになります。

このキャンペーンが最終的に狙ったのはMicrosoftとGoogleのアイデンティティ（ID）でしたが、これが発見されたのはSalesforceのお客様環境に影響を与えるフィッシング活動の調査中でした。

現代のクラウド攻撃が単一のプラットフォーム内に留まることは滅多にありません。フィッシングメールがSalesforce連携のワークフローを通じて届き、ユーザーにMicrosoftやGoogleでの認証を促し、最終的には複数のSaaSアプリケーションにまたがるビジネスプロセスを支えるアイデンティティを侵害する、といったことが起こり得ます。

Salesforce管理者にとって、プラットフォームを保護することは、そこに接続されているユーザーや通信チャネルを保護することにほかなりません。ユーザーがフィッシングインフラに到達する前にこれらのキャンペーンを阻止することは、最終的にSalesforceの枠を遥かに超えた広範なアイデンティティの侵害を防ぐことにつながります。

クラウドセキュリティは、もはや個々のプラットフォームだけで定義できるものではありません。Salesforce、Microsoft 365、Google Workspace、その他無数のSaaSアプリケーションは、すべて「同じユーザー」を共有しています。攻撃者はすでにそのことを理解しています。防御側である私たちも、同じように広い視野で考える必要があります。

Salesforceは攻撃の「目的地」ではないかもしれませんが、「攻撃経路」の一部になり得るのです。

これらの誤解は単なる間違いにとどまらず、金銭面でも、そして企業の評判の面でも、きわめて大きな代償を伴います。Salesforceのセキュリティに対して間違った思い込みを抱いている企業は、データ漏洩やコンプライアンス違反、さらには内部不正といった脅威に対して、日常的に自社を無防備な状態にさらしてしまっているのです。

ここからは、Salesforceのセキュリティに関して特によくある7つの誤解を取り上げ、それらが生まれる背景と、その誤解から脱却するために今すぐ取り組むべき対策について解説します。

誤解 1：「Salesforceは安全だから、私たちのデータも安全だ」

Salesforce社は、インフラの堅牢化、通信の暗号化、侵入テスト、さらにはISO 27001やSOC 2といった認証の取得など、プラットフォームレベルのセキュリティに巨額の投資を行っています。この誤解が根強く残っているのは、同社の取り組みが真に優れているがゆえに、「プラットフォーム自体の強固なセキュリティ」と「その中に保存されている自社データの安全性」を、ついつい混同してしまいがちだからです。

しかし、Salesforceは「責任共有モデル」に基づいて運用されています。Salesforce社が守るのはあくまでプラットフォームであり、それ以外のすべてはユーザー企業側の責任となります。つまり、プロファイルや権限、共有ルールの正しい設定、データのエクスポート権限の管理、そしてユーザーが組織内で実際にどのような操作を行っているかの監査などは、すべて自社で行わなければなりません。プロファイルの設定ミスが一つあったり、連携ユーザーに過剰な権限が与えられていたりすれば、Salesforce自体のインフラがいかに堅牢であろうとも、機密データは簡単に外部へ漏洩してしまうのです。

私たちにできる対策とは？まずは「責任共有モデル」において、自社がどこに責任を持つべきなのか、その境界線を正しく理解することから始めましょう。そして、その領域が実際にしっかりと保護されているかを確認してください。具体的には、Salesforce内を行き交うすべての要素を安全に保つ必要があります。ユーザーがアップロードするファイル、クリックするリンク、組織にアクセスするアイデンティティ（認証情報）、そしてデータを処理するAIのワークフローにいたるまで、すべてが対象です。WithSecure Cloud Protection for Salesforceは、まさにこの領域をカバーするために専用設計されたソリューションです。既存の設定に影響を与えることなく、リアルタイムでこれらすべてを保護します。

誤解 2：「管理者がアクセス権を制御しているから、誰が何を見られるかは把握できている」

多くの企業は、システム管理者がプロファイルやロールを管理しているため、アクセス権は完全にコントロールできていると思い込んでいます。しかし現実には、Salesforceの共有モデルはエンタープライズ向けソフトウェアの中でも屈指の複雑さを誇ります。プロファイル、権限セット、ロール階層、共有ルール、手動共有、そしてApexによる共有管理などが複雑に絡み合っているため、経験豊富な管理者であっても、その挙動を直感的に把握するのは容易ではありません。

この誤解が生まれる原因は、アクセス権を制御する「仕組み」自体は確かに存在しているからです。問題なのは、それらを包括的に監査することが極めて難しい点にあります。一見すると制限が厳しそうに見えるプロファイルを持つユーザーであっても、共有ルールやロール階層が加味された結果、意図したよりもはるかに多くのデータにアクセスできてしまっているケースは珍しくありません。

私たちにできる対策とは？ Salesforceの責任共有モデルを完全にマッピングするには入念な手動監査が必要ですが、最もリスクが高い要因の一つは、「必要以上の権限が蓄積されてしまったアイデンティティ（アカウント）」です。Cloud Protection for Salesforceの「アイデンティティ保護」機能は、ユーザーアカウントだけでなく、システム連携用などの非人間アカウントも含め、「すべてのデータの変更」や「すべてのデータの参照」といった高リスクな権限を持つすべてのアイデンティティを自動で検知します。管理者は単一のダッシュボード上でこれらのリスクを即座に把握し、Salesforceの画面から離れることなく、ワンクリックで「アカウントの凍結」「パスワードのリセット」「権限の編集」といったアクションを実行できます。

誤解 3：「内部脅威を心配する必要はない。うちのチームは信頼できる」

内部脅威は、必ずしも悪意を持った人物によって引き起こされるわけではありません。自らのロール（役割）をはるかに超えた権限がいつの間にか蓄積されてしまっている外部委託業者、退職後もシステム連携用の資格情報がアクティブなまま残っている元従業員、あるいは、外部でのデータ漏洩によってログイン情報が流出し、気づかないうちに組織への不正アクセスを許してしまっているユーザーなど――これらはすべて内部リスクのシナリオであり、CRM環境においては外部からの攻撃よりもはるかに頻繁に発生しています。

この誤解が根強く残っているのは、自社の従業員を潜在的なリスクとして扱うことに心理的な抵抗があるためであり、また、Salesforceのセキュリティに関する議論の多くが「外部からの攻撃者」にばかり焦点を当てているからです。

私たちにできる対策とは？ Cloud Protection for Salesforceは、組織内におけるコンテンツのアクティビティをセキュリティチームが完全に可視化できるようにします。「どのファイルが」「誰によってアップロードされ」「どれくらいの頻度でコンテンツにアクセスされ」「どのIPアドレスから実行されたか」を詳細に把握することが可能です。さらに、過剰な権限を持つアカウントを特定し、外部のデータ漏洩でログイン情報が流出してしまっているユーザーをあぶり出す「Identity Protection（アイデンティティ保護）」機能と組み合わせることで、チーム全員を容疑者扱いすることなく、アカウントに起因する内部リスクを絞り込み、具体的な対策を講じるための視覚化された情報をセキュリティチームに提供します。

誤解 4：「バックアップを取っているから、何か問題が起きてもいつでも復元できる」

Salesforceの標準プランには、多くの企業が求める復旧要件を満たすようなバックアップソリューションは含まれていません。Salesforce社が買収した「Own（旧OwnBackup）」による有償のオプションは存在しますが、これには別途ライセンスが必要です。また、仮に導入していたとしても、データの復元は手動で行う時間のかかるプロセスであり、特定の時点への復元を簡単に行えるわけではありません。

この誤解は、すべてのエンタープライズ向けSaaSプラットフォームには強力なバックアップが標準搭載されているはずだ、という思い込みから生まれています。しかし、Salesforceに関して言えば、その思い込みは完全に間違いです。

私たちにできる対策とは？ ずは、Salesforceの週次データエクスポートだけに頼るのではなく、毎日自動でバックアップが行われ、きめ細かな時点復元（グラニュラー・ポイントインタイム・リストア）が可能な、適切なバックアップソリューションに投資をしてください。しかし、どれほど優れたバックアップであっても、それは「問題が発生した後」にしか役に立ちません。

データの復旧を余儀なくされる最も一般的なシナリオの一つが「ランサムウェア」であり、そのランサムウェアは「ファイル」として組織内に侵入してきます。

Cloud Protection for Salesforceは、第三者評価機関であるAV-TESTの調査でマルウェア検出率100%を達成したのと同じエンジンを使用し、アップロードされるすべてのファイルをスキャンします。これにより、ランサムウェアや悪意のあるファイルが組織内に着信する前にブロックします。優れたバックアップは事後の被害からあなたを守りますが、マルウェアの侵入そのものを防ぐことは、バックアップに頼らざるを得ない事態そのものを減らすことにつながるのです。

誤解 5：「当社のSalesforce組織は非公開環境であり、パブリックなインターネット上には公開されていない」

Salesforceはクラウドプラットフォームであり、そのログインページやAPIを含め、あなたの組織（環境）はインターネット接続さえあれば世界中のどこからでもアクセス可能です。多くのITチームがSalesforceをまるで「社内システム」であるかのように扱い、従来のネットワーク境界（ペリメーター）による制御の恩恵を受けられていると思い込んでいますが、実際には受けていません。

この思い込みは、脆弱なセッションポリシー、不十分なAPIアクセスの監視、そしてポータルやWebフォームを通じて組織内に入り込んでくるコンテンツに対するネイティブな制御の欠如といった「セキュリティの空白地帯」を生み出します。これらはすべて、攻撃者にとって格好の標的となるのです。

私たちにできる対策とは？ 脆弱なセッションポリシーやAPIアクセスについては、IP制限の適用や、Salesforce社が提供する「Salesforce Shield」（要別途ライセンス）の活用によって堅牢化することができます。

しかし、多くの企業で対策が見落とされがちなのが、ポータルやフォームを経由して組織内に流入してくるコンテンツです。これらのトラフィックは、企業のメールセキュリティやエンドポイント（PCなど）の対策ツールでは一切検知することができません。Cloud Protection for Salesforceは、まさにこの盲点（ブラインドスポット）をカバーします。ファイルのアップロード時やURLのクリック時にそれらをリアルタイムでスキャンするだけでなく、検証済みのデータ漏洩情報とSalesforceのログイン資格情報を継続的に照合し、アカウントが不正利用される前に、流出したログイン情報の危険性をいち早く検知します。

誤解 6：「Salesforceがコンプライアンス認証を取得しているから、当社も準拠できている」

Salesforce社は、数多くの優れたコンプライアンス認証を取得しています。企業は、GDPRやHIPAA（医療保険の相互運用性と責任に関する法律）、PCI-DSS（クレジットカード業界のデータセキュリティ基準）への対応状況を問われた際、同社のこれらの認証を根拠に挙げることがよくあります。しかし、プラットフォーム側が認証を持っているからといって、自社が負うべきコンプライアンスの義務がSalesforce社に移転するわけではありません。

例えばGDPRの枠組みにおいて、データの管理責任を負う「データ管理者」はあくまでユーザー企業側です。適法なデータ処理、データ主体の権利（開示や消去の請求など）への対応、データ保持ポリシーの策定、そしてデータ漏洩時の通知義務などは、すべて自社の責任となります。これらはSalesforce社が代行してくれるものではなく、また、単一のセキュリティツールを導入しただけで完全に解決できるものでもありません。これらへの対応には、明文化されたプロセスや法務によるレビュー、そして多くの場合、組織的なコンプライアンスプログラムの運用が必要不可欠です。

私たちにできる対策とは？Cloud Protection for Salesforceは、責任共有モデルにおける「コンテンツセキュリティ」の側面から、企業のコンプライアンス体制（コンプライアンスポスチャ）の強化を強力に支援します。本ソリューションは、スキャンされたすべてのファイル、検査されたすべてのURL、および検知されたすべてのアイデンティティ（アカウント）リスクを網羅した、リアルタイムのダッシュボードと、そのまま監査に提出できるイベントログのエクスポート機能を提供します。これにより、コンプライアンスチームは、監査のたびにSalesforce管理者の手を煩わせることなく、必要なエビデンス（証跡）を直接取得できるようになります。なお、Cloud Protection for Salesforce自体も、ISAE 3000 Type 2、ISO 27001、およびEU GDPRの認証を取得しており、高い信頼性を担保しています。

誤解 7：「セキュリティは一度きりのプロジェクトであり、継続的な業務ではない」

Salesforceの組織は、日々変化し続ける「生き物」です。ユーザーの異動や昇進、新しい外部システムとの連携、ビジネスプロセスの変化などに伴い、アカウントの権限は時間の経過とともに雪だるま式に蓄積されていきます。今日、どれほどクリーンで強固なセキュリティ体制を築いていたとしても、能動的なメンテナンスを怠れば、わずか半年ほどでその体制は著しく形骸化してしまいます。

この誤解が生まれてしまうのも無理はありません。セキュリティの定期見直しには多大な労力がかかりますし、一度環境を構築してしまえば「完了した」と感じてしまいがちだからです。しかし、これは多くの企業が実際に直面し、実証されている深刻な問題なのです。

私たちにできる対策とは？ Cloud Protection for Salesforceは常時稼働し、すべてのファイル、リンク、そしてアイデンティティ（アカウント）をリアルタイムで継続的にスキャンします。そのため、自社のセキュリティレベルが「最後にいつ手動レビューを行ったか」という不確実なタイミングに左右されることはありません。

新しいユーザーが追加されればログイン情報の流出リスクが即座にチェックされ、新しいファイルはアップロード時にスキャンされ、新しいリンクはクリックされた瞬間に検査されます。リアルタイムのダッシュボードにより、セキュリティチームは「前四半期時点の古いスナップショット」ではなく、「今、この瞬間」の組織の脅威状況を常に正確に把握できるようになります。

まとめ

Salesforceは、強固なセキュリティ機能を備えた、極めて強力で優れた設計のプラットフォームです。しかし、「機能が存在すること」と「正しく設定されていること」は別であり、さらに「正しく設定されていること」と「継続的なガバナンスが行われていること」もまた別問題です。この違いを正しく理解し、具体的なアクションを起こせる企業こそが、自社のデータ、従業員、そして大切な顧客を真に守り抜くことができるのです。