SalesforceはDreamforceカンファレンスで大規模なOAuth侵害の波について触れなかったが、サードパーティ認証の確保は、同社が目指すエージェンティックな未来にとって極めて重要だ。
先週開催されたSalesforceの旗艦イベントDreamforceでは、参加者に対しSalesforce環境やAIエージェントのセキュリティベストプラクティス、そしてSalesforce自身がAIを活用してセキュリティを向上させる取り組みについて様々なセッションが提供された。同社はイベントに先立ち、CISO向けにセキュリティ課題を扱うエージェントと、プライバシーやコンプライアンスに対応するエージェントという2つの新しいエージェントをリリースした。
全体として、「セキュリティは共有責任である」というテーマが強調された。Salesforceは自社の役割を果たし、顧客も自分たちの責任を果たす必要があるというものだ。
しかし、カンファレンスで取り上げられなかったのは、過去数か月に発生し、700社以上・約15億件の記録に影響を与え、70件以上の訴訟を引き起こしたSalesforce関連の侵害によって明らかになった脆弱性だった。
「私はイベントに参加し、すべてのリーダーシップと話しましたが、この話題は出ませんでした」とConstellation Researchの副社長Chirag Mehta氏は語る。「この件は話題にならなかったのです。」
この見落としは、Salesforceエコシステムでここ数か月に起きた出来事の教訓が、Salesforceのエージェンティックなビジョンの中心となる、ますます接続性が高まりAIが浸透する未来にとって極めて重要であることを考えると、機会損失だった可能性が高い。
サードパーティによるサイバー災害の構造
問題となっているのは、近年最大規模のSaaSサプライチェーン侵害の一つだ。Google Threat Intelligence Groupによると、700以上の組織が8月の侵害の影響を受けた。この事件では「攻撃者が多くの企業のSalesforceインスタンスから大量のデータを体系的にエクスポートした」という。
データがSalesforceに保存されていたことから、サイバー分野以外の人はこれがSalesforceの侵害だと考えるかもしれないが、そうではなかったとMehta氏は指摘する。
「確かに、侵害はSalesforceインスタンスで発生しました」と彼は説明する。「しかし、それはSalesforceの行動が原因ではありません。何が起きているかを理解している人は、Salesforceが何をすべきか、顧客が何をすべきかを理解しています。」
実際には、攻撃者がサードパーティAIチャットツールSalesloft DriftからSalesforceのOAuthトークンを入手し、そのトークンを使ってSalesforceインスタンスから大量のデータをダウンロードしたことで侵害が発生した。
Salesforceは、「ごく少数の顧客」が影響を受けたと述べて侵害の重大性を最小限に抑えようとしたが、活動を検知した際には「有効なアクセスおよびリフレッシュトークンを無効化し、DriftをAppExchangeから削除した。その後、影響を受けた顧客に通知した」と説明している。
しかし、Salesforceの顧客であるCDN大手Cloudflareによれば、同社は8月9日にこの侵害に関連する偵察活動の最初の兆候を確認し、8月12日には攻撃者がCloudflareのSalesforceテナントにアクセスした。8月17日までに、攻撃者はCloudflareのSalesforceケースワークフローを分析し、チームメンバーが様々なケースをどのように処理しているかを把握し、データの持ち出しを完了した。
3日後の8月20日、SalesforceはSalesloft Driftの接続を取り消し、自社ウェブサイトで通知を公開した。「その時点でCloudflareはまだ通知を受けておらず、このベンダーの対応が自社環境に関連する可能性があるとは認識していませんでした」とCloudflareのセキュリティ責任者は述べている。
Cloudflareだけではなかった。数百社が影響を受け、その中にはサイバーセキュリティの大手企業も含まれていた。
Mitiga Securityの研究者Idan Cohen氏は「Driftのケースでは、顧客が不注意だったわけではない。攻撃者はハッキングで侵入したのではなく、信頼されたサードパーティサービスを装ってログインした」と記している。
Salesforceアカウントの侵害はこれだけではなかった。6月にはShinyHuntersとして知られる別の攻撃グループが、ITサポート担当者を装い、ユーザーを騙してSalesforceのData Loaderアプリケーションの悪意あるバージョンへの接続を承認させ、Salesforce環境からデータを持ち出した。
これらの攻撃を6月のレポートで説明したGoogleの脅威インテリジェンスチーム自身も、8月に同様の攻撃の被害に遭った。
10月までに、攻撃者は760社から15億件以上のSalesforce記録を盗んだと主張。さらに、Salesforceやその被害企業（トヨタ、FedEx、Hulu、UPSなど）に対し恐喝キャンペーンを開始した。
Salesforceに対しては、システムに接続されたサードパーティアプリケーションの審査や、データ持ち出しやその他の悪意ある活動の監視が不十分だったとして、複数の訴訟が提起されている。
「Salesforceは…自社のソフトウェア環境を管理し、他社が通常実施しているセキュリティプロトコルを導入することで、これらの攻撃を防ぐ義務と能力があった。しかし、Salesforceはそれを怠った」と、8月29日にカリフォルニアで提起された集団訴訟の一つは述べている。
OAuth悪用の可能性は「既知のリスク」だったにもかかわらず、Salesforceはサードパーティ接続の審査や保護の構築、ネットワーク監視を怠ったと、別の集団訴訟の原告らは訴状で主張している。
サンディエゴの法律事務所CaseyGerryによれば、Salesforceのデータ侵害に関連して全米で70件以上の訴訟が提起されている。
最大の死角
企業がOAuth連携を通じてサードパーティにアクセスを委譲すると、全業界に共通するシステミックなセキュリティの死角が生まれる。
これらのトークンを盗むことで、攻撃者はすべての接続システムにアクセスできる。「悪意ある接続アプリを承認すると、多要素認証やパスワードリセット、ログイン監視など多くの従来の防御策を回避でき、OAuthトークンはSalesforce自身が発行するため、悪意あるアプリからの活動も信頼された連携からのもののように見える」とFBIは9月に警告している。
このような脆弱性の悪用は今後さらに深刻化するだろう。特にAI関連の連携が標準となるにつれて。
従来のCRM連携が連絡先データのみを必要とするのに対し、「AIセールスアシスタントは通常、連絡先、メール履歴、カレンダー情報、案件パイプラインデータ、会話ログ、製品カタログなどを必要とする」と、Trend MicroのAIセキュリティ専門家Fernando Tucci氏はAIチャットボットであるSalesloft Driftの侵害が特別な理由についてのレポートで指摘している。「この広範なアクセスパターンにより、単一のAI連携が侵害されただけで従来のポイントソリューションよりもはるかに多くの機密情報が漏洩する可能性がある。」
さらに悪いことに、AIチャットボットは大規模なデータセットへのアクセスを前提に設計されているため、悪意ある攻撃者が同じ接続を利用してデータを盗んでも、トラフィックパターンが正規のものに見える場合がある。
これらのパートナーシップや接続をすべて把握するには、ベンダー管理との緊密な連携が必要だとAkamaiのアドバイザリーCISO、Steve Winterfeld氏は言う。「加えて、自社データの所在を把握するには、文化に根ざしたポリシーと技術的なコントロールの両方が必要です」と彼は述べる。
ホワイトラベルサービス、API、そして今やLLM（大規模言語モデル）などの登場で、これら2つの目標はさらに複雑になっている。「まだサプライチェーン侵害対応演習を実施していないなら、今こそ実施すべきです」とWinterfeld氏は言う。「最近の出来事は、プログラムの検証がいかに重要かを強調しています。」
皮肉なことに、被害企業の中にはZscaler、Cloudflare、Palo Alto Networks、Pager Duty、SpyCloud、Tenable、Proofpoint、Rubrik、BeyondTrust、Bugcrowd、JFrog、CyberArk、Black Duckなど多くのセキュリティ企業も含まれていた。
被害を免れた企業
今回の侵害で被害を受けなかった企業の一つが、クラウド型IAMベンダーのOktaだ。その理由は、許可されたIPアドレスからのみ接続を許可していたからだ。
Oktaによれば、同社は侵害を知った際、直ちにログを確認し、盗まれたトークンによるリソースアクセスの試行を発見したが、それらは失敗していた。
「この侵害を防いだ最も重要なコントロールは、インバウンドIP制限の強制でした」と同社は述べている。「攻撃者は盗まれたトークンを使って当社のSalesforceインスタンスにアクセスしようとしましたが、接続元が許可されていないIPアドレスだったため攻撃は失敗しました。このセキュリティレイヤーは本質的であり、不正な試みを玄関口でブロックしました。」
このホワイトリスト方式のセキュリティは強力な戦術だが、実装には多大な規律が求められるため難しい。
もう一つの課題は、すべてのSaaSベンダーがこの機能をサポートしているわけではないことだ。「クラウドファーストの世界の多くのプロバイダーは、この基本的なセキュリティ機能を提供しておらず、相互接続されたシステムの保護に大きな課題をもたらしている」とOktaは述べている。
SaaSプロバイダー向けの基本的なセキュリティベンチマークは、Cloud Security Allianceが最近発表したSaaS Security Capability Framework（SSCF）をきっかけに、ようやく整備され始めている。
Oktaは、Salesforceはすでにこの機能を提供しているが、「APIやユーザーごとに制限を設定する必要があるため、利用には相当な労力が必要」と付け加えている。
接続を保護するもう一つの方法は、証明書の所有証明（DPoP）を用いて特定のクライアントに限定することだ。これにより盗まれたトークンの再利用を防げるが、認証フローの変更やクライアント・サーバー双方への新たな要件が生じるため、実際にはさらに難しい。もう一つの選択肢は相互TLS（mTLS）で、さらに強力なセキュリティを提供するが、複雑さも増す。
例えば金融業界では、一部の規制当局がDPoPやmTLSを義務付けている。医療分野では義務化されていないが、Tyk Technologiesによれば、ここでも活用例があるという。
今後、相互接続されたSaaSアプリやAIツールの利用が増えるにつれ、より多くの企業がこうしたアップグレードを検討すべきだ。
Internet Engineering Task Forceは、OAuthセキュリティのベストプラクティスとしてDPoPとmTLSの両方を推奨している。
今後高まるリスク
企業が自社の境界外のシステムへの接続を許可する際には、引き受けるリスクと利用可能なセキュリティコントロールを理解する必要があると、ConstellationのMehta氏は述べる。
多要素認証のような一般的かつ単純なコントロールでさえ、全従業員に徹底するのは難しいと彼は言う。
「ソリューションプロバイダーの立場から言えば、彼らは特定のセキュリティコントロールや機能を提供し、実際にそれを使うかどうかは顧客次第です。私の見解では、これは共有責任です」とMehta氏は述べる。
セキュリティの共有責任は、先週のDreamforceの重要なメッセージの一つだったが、Salesloft事件の議論は目立って欠如していた——これは参加者にとって損失だった。
なぜなら、ここ数か月のSalesforce関連のサイバーセキュリティから得られる最大の教訓は、ソフトウェアサプライチェーンのセキュリティがかつてないほど重要になっているということだからだ。そして、より多くのシステムが接続されるにつれて、その重要性はさらに増す——これはSalesforceがエージェンティックな企業を実現するという目標の重要な要素でもある。
ソフトウェアサプライチェーンのセキュリティはすでに容易ではなく、SalesforceがAIの力でこれを簡単にすると約束している一方で、AIそのものがこの問題をさらに難しくする要因となるだろう。
