Salesforce の Drift トークンキャンペーンが OAuth 同意を説明責任の境界にした

要約

• Google Threat Intelligence Group は、2025年8月8日から少なくとも8月18日にかけて、UNC6395 が Salesloft Drift サードパーティアプリケーションに関連する侵害された OAuth トークンを使用して Salesforce の顧客インスタンスを標的にしたと報告した。
• Salesforce の Trust アドバイザリによると、Salesloft が Salesforce と協力してアクティブなアクセストークンおよびリフレッシュトークンを無効化し、Drift を AppExchange から削除した。問題は Salesforce の中核プラットフォームの脆弱性に起因するものではなかった。
• Salesloft の Trust Center は後に、Mandiant が Drift 製品に影響を及ぼす侵入の疑いについて調査し、根本原因、範囲、封じ込め、修復、Drift と Salesloft アプリケーション間のセグメンテーションを評価したと発表した。
• このインシデントは、OAuth 同意が単なる管理上の背景ではないことを示している。広範な権限を持つ統合は、顧客の CRM データ、サポートケース、レコードに埋め込まれた認証情報、さらには下流のクラウドシステムへのアクセス経路となりうる。
• 説明責任は管理に従う。Salesloft は Drift 製品とトークン保管を管理していた。Salesforce はプラットフォームの接続アプリガバナンス、AppExchange の対応、顧客通知チャネル、監査可視性、緊急トークン無効化を管理していた。顧客は接続アプリの承認とデータ衛生を管理していたが、多くの場合、プラットフォームとベンダーが統合を利用可能にした後のことだった。

公的なタイムラインは委任された権限から始まる

Google Threat Intelligence Group のアドバイザリWidespread Data Theft Targets Salesforce Instances via Salesloft Driftが中心的な技術情報源である。GTIG の発表によれば、2025年8月8日より早くから少なくとも8月18日まで、UNC6395 として追跡される攻撃者が、Salesloft Drift サードパーティアプリケーションに関連する侵害された OAuth トークンを用いて Salesforce の顧客インスタンスを標的にした。GTIG は、攻撃者が多数の企業 Salesforce インスタンスから大量のデータをエクスポートし、AWS アクセスキー、パスワード、Snowflake トークンなどのシークレットを探索したと述べている。

Salesforce 自身のセキュリティアドバイザリは、プラットフォームの境界を定義している。Salesforce は、このインシデントが Salesloft によって公開された Drift アプリに関係しており、Salesloft が Salesforce と協力してアクティブなアクセストークンとリフレッシュトークンを無効化し、Drift が AppExchange から削除されたことを明らかにした。また、この問題は Salesforce の中核プラットフォームの脆弱性に起因するものではないとも述べている。この声明は重要であり、保持されるべきである。このインシデントは、攻撃者が Salesforce の中核ソフトウェアの脆弱性を悪用した証拠ではない。

Salesloft のTrust Centerは後に、Drift 製品に影響を与えた侵入の疑いに関する Mandiant の調査について説明している。Mandiant は2025年8月26日に関与し、根本原因と範囲の特定、封じ込めと修復の支援、Drift と Salesloft アプリケーション間のセグメンテーションの検証を行ったとしている。この情報源は、調査が Salesforce プラットフォーム層だけでなく、ベンダー層でも実施されたことを示すという点で重要である。

公的な対応の順序は重要である。Google と Salesforce は、8月初旬から中旬の活動について説明している。Salesforce のアドバイザリでは、トークンが無効化され、Drift が AppExchange から削除されたとしている。AppOmni のDrift-Salesforce 侵害の分析でも同様に、Salesloft と Salesforce が Drift の OAuth トークンを失効させ、影響を受けた組織が Salesforce から直接通知を受けたと記録されている。Unit 42の脅威ブリーフは、侵害された OAuth 認証情報が影響を受けた Salesforce 環境からデータを流出させるために使用されたキャンペーンとして追跡している。

重要な説明責任の事実は、委任された権限である。OAuth は、ユーザーや管理者が自分のパスワードを共有することなく、アプリケーションにデータや操作へのアクセスを許可する仕組みである。この設計は現代の SaaS に不可欠である。しかし、サードパーティアプリが広範なスコープ、長期間有効なリフレッシュトークン、弱いトークン保管、高価値の CRM データへのアクセスを持っている場合には危険でもある。トークンが権限そのものになる。

これは通常のパスワード盗難ではない

多くの侵害対策プレイブックは、いまだに人間のログインを前提としている。パスワードをリセットし、MFA を追加し、ログイン履歴を確認して次へ進む。Drift キャンペーンは、それが不十分である理由を示している。OAuth トークンは、ユーザーがパスワードを入力するのと同じではない。すでにデータへのアクセス同意を得ている信頼されたアプリケーションを表すことができ、アプリケーションが人の介在なしに API を呼び出すことを期待されているため、一部の人間のログイン制御を迂回できる可能性がある。

これは MFA が無関係であることを意味しない。MFA は初期のユーザー侵害を防ぎ、管理同意ワークフローを保護できる。しかし、有効なアプリトークンが存在した後は、重要な制御はアプリのスコープ、トークン保管、リフレッシュトークンの有効期間、アプリレビュー、失効速度、API 監視、データアクセスの異常検知となる。顧客は堅牢なユーザーMFA を備えていても、サードパーティアプリのトークンが盗まれれば露出する可能性がある。

FBI と IC3 の TLP:CLEAR アドバイザリCyber Criminal Groups UNC6040 and UNC6395 Compromising Salesforce Platformsは、UNC6395 が Salesloft Drift アプリケーションの侵害された OAuth トークンを使用し、アクセスメカニズムが他の Salesforce を標的としたキャンペーンと異なると警告した。FINRA のSalesloft Drift AI サプライチェーン攻撃に関するサイバーセキュリティアラートは、規制対象金融機関向けにこのインシデントを位置づけ、盗まれた OAuth 認証トークンが脅威アクターに信頼された Drift アプリケーションを偽装し、顧客環境への不正アクセスを取得することを許したと述べている。

これら二つのアドバイザリは、これが単なるベンダー侵害でなく、ガバナンスの問題であった理由を示している。規制対象の企業は、サードパーティアプリケーションが Salesforce データへのアクセス権限を持っていたかどうか、CRM レコード内にシークレットが保存されていたかどうか、顧客や見込み客が露出したかどうかを精査しなければならなかった。プラットフォームとベンダーの問題は、顧客のコンプライアンス問題となった。

Salesforce の接続アプリに関するドキュメントは、外部アプリケーションが Salesforce と統合する基本モデルを説明している。OAuth 設定を含む接続アプリの OAuth ドキュメントは、スコープとポリシーが重要である理由を示している。これらの文書はインシデントの証拠ではない。制御対象の表面を説明している。

スコープが信頼を影響範囲に変えた

OAuth スコープは、アプリが何をできるかを定義する。最小限の設計では、アプリは特定のタスクに必要なアクセス権のみを取得する。広範な設計では、大規模なレコードクラスの読み取りや書き込み、API の呼び出し、アクセスの更新、広範なデータ面にわたる操作が可能になる。Drift キャンペーンは、統合の利便性がスコープの規律を上回っていたかどうかを問いかけている。

GTIG は、UNC6395 が Salesforce 環境から体系的にデータをクエリおよびエクスポートし、レコード内の認証情報を探索したと報告している。これは、露出が Salesloft が所有するフィールド一覧に限定されなかったことを意味する。顧客の Salesforce データが統合を通じてアクセス可能であり、その範囲に含まれていたのである。顧客が Salesforce のケース、メモ、サポートスレッド、チャットトランスクリプト、カスタムフィールド、または添付ファイルにシークレットを保存していた場合、それらのシークレットが次の段階のリスクになり得る。

これが、ベンダーの自社顧客テーブルへの侵害との重要な違いである。侵害されたトークンによって、攻撃者は接続された各顧客の Salesforce 環境内のデータに手が届いた。被害の大きさは、各顧客が何を保存していたか、Salesforce 組織がどのように構成されていたか、アプリがアクセス可能なオブジェクト、レコード内にシークレットが埋め込まれていたかによって異なった。同じトークンクラスの窃取でも、顧客によって被害の程度は異なりうる。

AppOmni の分析は、SaaS 間の防止と接続アプリ全体の可視性の困難さを強調している。Arctic Wolf のセキュリティ速報も同様に、侵害された Salesloft Drift OAuth トークンを通じた Salesforce データの窃取に焦点を当てている。これらの情報源はベンダー分析ではあるが、同じ管理点を補強している。すなわち、SaaS 統合は人間ではない ID を生成し、それはライフサイクルガバナンスに値する。

「非人間 ID」という用語は抽象的かもしれない。このインシデントでは、それは人間がキーボードの前にいなくても行動できるアプリ認証情報を意味する。それは一度承認されると持続する可能性がある。統合を有用にするために広範なアクセス権が与えられることがある。通常のユーザーログインダッシュボードには表示されないかもしれない。それを正当化した業務プロセスよりも長く存続する可能性がある。ひとたび盗まれれば、API 呼び出しはその ID にとって通常のことであるため、素早く動くことができる。

接続アプリマーケットプレイスは管理チェーンの一部である

Salesforce のアドバイザリによれば、Drift はさらなる調査があるまで AppExchange から削除された。この対応が重要なのは、AppExchange が単なるディレクトリではないからである。それは信頼のシグナルである。顧客は、マーケットプレイスに掲載されたアプリがレビュープロセスを通過しており、インストールに適切であるとしばしば推測する。マーケットプレイスは顧客のデューデリジェンスを不要にするわけではないが、顧客の選択に影響を与える。

マーケットプレイスアプリがキャンペーンのアクセス経路となった場合、プラットフォームの責任はベンダーの侵害を引き起こしたことではない。責任は、顧客ごとの発見よりも早く、検知、通信、無効化、回復支援を行わなければならないことにある。プラットフォームはテナント全体のアプリインストール状況を把握している。どの顧客がそのアプリをインストールしたかを特定できる。トークン失効を調整できる。影響を受けた顧客に通知できる。掲載を削除または一時停止できる。この顧客横断的な可視性こそが、プラットフォームガバナンスが重要である理由である。

公的な記録では、Salesforce がそのプラットフォームの役割を果たしたように見える。すなわち、Salesloft と協力し、トークンを無効化し、アプリを削除し、影響を受けた組織に通知した。説明責任に関する問いは、最初の不審な活動から見て、それがどれだけ迅速に行われたか、そして顧客が自身の露出を判断するのに十分なログアクセスを持っていたかどうかである。GTIG はキャンペーン活動が早くとも8月8日から始まったと報告しており、トークン失効は8月20日に報告された。大まかな間隔は見えるが、内部の検出決定プロセスは見えない。

顧客にも責任はある。アプリを選択し、スコープを承認し、レコードにシークレットを保存し、API の挙動を監視し、接続アプリをレビューする責任である。しかし、顧客の責任はプラットフォームの提供能力によって制限される。接続アプリレビューが理解しにくい、スコープが粗すぎる、ログがアクセスしにくい、トークンインベントリが断片化している、マーケットプレイスの信頼が曖昧である場合、顧客は不完全な可視性のもとで意思決定を行う。

したがって、このインシデントは単純な三者間の責任追及として捉えるべきではない。それは連鎖である。Salesloft は Drift とそのトークンを守らなければならなかった。Salesforce は接続アプリの信頼と緊急失効を管理しなければならなかった。顧客はアプリアクセスを制限し、CRM データからシークレットを除去しなければならなかった。攻撃者はその連鎖を悪用した。

CRM データがシークレット探索の表面になった

GTIG の最も憂慮すべき発見は、単に CRM レコードがエクスポートされたことではなかった。攻撃者がシークレットを探索したことである。Salesforce 環境には、サポートケース、営業ノート、顧客オンボーディングの詳細、技術トラブルシューティングのスレッド、チケットに貼り付けられた API キー、VPN エンドポイント、クラウドアカウント識別子、統合認証情報、ケースコメントに誤って保存されたパスワード、または機密運用データを含む添付ファイルが存在する可能性がある。そのような資料は CRM レコード内にあってはならないが、実際の組織ではしばしば存在する。

これにより、被害の焦点はプライバシーから水平展開リスクへと移る。攻撃者が CRM エクスポートを利用して AWS キー、Snowflake トークン、VPN 認証情報、その他のシークレットを見つけ出せば、侵害は顧客データ露出からインフラストラクチャの侵害へと拡大しうる。CRM システムは他システムの地図となる。サポートチームが問題を文書化する場所であり、その文書はサポート対象システムを攻撃するために必要な手がかりを含んでいる可能性がある。

GTIG の公開アドバイザリでは、組織がシークレットを検索し、認証情報をローテーションすべきとしている。このアドバイスは運用上高コストである。顧客は、本来そこに保存すべきでなかった資料を自分たちのデータから探さなければならないからだ。したがって、このインシデントは顧客層のデータ衛生の失敗を露呈するが、引き金は信頼された統合の侵害であった。顧客は、チャットボットや収益ワークフローの統合が認証情報を含むレコードに到達しうることを認識していなかったかもしれない。

Salesforce と顧客は、シークレットスキャンを CRM 管理策として扱うことで、このリスクを軽減できる。レコードはキーパターンについてスキャンされるべきである。サポートワークフローでは、パスワードやトークンの貼り付けを阻止すべきである。機密フィールドはマスクされるべきである。アプリのスコープには不要なオブジェクトを含めるべきではない。エクスポートは監視されるべきである。これらは特殊な管理策ではなく、CRM システムが雑多な運用データを保持するという現実への実践的な対応である。

このリスクは、顧客通知が重要である理由も説明している。影響を受けた顧客組織は、レコードを検索し、露出したシークレットをローテーションし、下流のクラウドログを確認し、必要に応じて自社の顧客に警告するために、十分に早く知る必要があった。通知が遅れたり曖昧であったりすれば、盗まれたシークレットが有効なまま残る可能性がある。

失効は必要だったが、それだけでは回復にはならなかった

トークン失効は、直接的な委任アクセス経路を閉ざす。Salesforce のアドバイザリと GTIG は、いずれも Drift のアクセストークンとリフレッシュトークンの失効または無効化を説明している。それは必要だった。それだけでは、すでにエクスポートされたデータや、すでに収集されたシークレットを除去することはできない。回復は顧客環境の内部で続行されなければならなかった。

回復の第一段階は、露出範囲の特定である。どの Salesforce オブジェクトがアクセスされ、どのレコードが照会され、どの API ジョブが実行され、どの統合が使用されたか。Salesforce のイベント監視とトランザクションセキュリティのドキュメントや API ログがここで重要になるが、ログの可用性はエディション、設定、保持期間、顧客の成熟度によって異なる。公開アドバイザリは、テナントレベルの証拠を代替できない。

第二段階は、シークレットのローテーションである。レコードに AWS キー、Snowflake トークン、VPN 認証情報、API キー、パスワード、Webhook シークレットが含まれていた場合、それらのシークレットを発見し、ローテーションする必要がある。シークレットは自由形式のテキストフィールド、添付ファイル、ケースコメント、チャットログ、カスタムオブジェクトに存在しうるため、これは難しい。自動検索は役立つが、通常とは異なる形式を見落とす可能性がある。手動レビューは時間がかかる。

第三段階は、顧客や下流への通知である。CRM データがエクスポートされた Salesforce 顧客は、自社の顧客、従業員、見込み客、パートナー、規制当局に対する義務を負う可能性がある。これによりカスケードが生じる。Salesloft のインシデントは Salesforce のプラットフォームインシデントとなり、それは各影響顧客のインシデントとなり、さらに各影響顧客の顧客への通知となりうる。一つの OAuth 侵害のコストは外側へと伝播する。

第四段階は、アプリガバナンスの見直しである。顧客は、他に同様のスコープを持つ接続アプリがどれだけあるか、それらがまだ必要かどうか、リフレッシュトークンが長期間有効かどうか、アプリの所有者は分かっているか、ベンダーリスクレビューは最新か、緊急失効のプレイブックは存在するかを問う必要がある。Drift インシデントは、他の深く許可されたすべての SaaS 統合にとっての予行演習として扱われるべきである。

AI ブランディングは説明責任の問題を変えなかった

一部の公開議論では、Drift は AI チャットボット統合として位置づけられた。製品の文脈としては重要だが、セキュリティの失敗は AI だから魔法だったわけではない。重要な問題は委任された SaaS アクセスであった。チャットボット、セールスエンゲージメントツール、サポートウィジェット、分析コネクタ、データエンリッチメントツール、マーケティングオートメーションプラットフォーム、いずれも顧客システムへの広範なトークンを保持すれば危険になりうる。

AI は統合への需要を高めるかもしれない。企業は、より多くのコンテキストを見る会話型ツールを求めるからだ。営業やサポートのチャットボットは、CRM レコードの読み取り、顧客質問への回答、ケース更新、リードのルーティング、パーソナライズされた応答を行うことができればより有用である。各スコープの追加は、有用性とリスクを増大させる。そのスコープの背後にあるトークンが盗まれれば、攻撃者はその製品を魅力的にしたのと同じ広範なコンテキストを受け取る。

これは SaaS オートメーションのセキュリティ経済学である。ベンダーはよりスムーズなワークフローを売り込む。顧客はワークフローが手間を省くためにアクセスを承認する。プラットフォームは、統合がエコシステムの価値を拡大するために許可モデルを提供する。リスクは、どの当事者もキャンペーンの後までトークン侵害のコストを十分に価格設定していないことである。Drift インシデントは、その過小評価されたリスクの事例研究である。

FINRA のアラートが重要なのは、規制された金融機関がこれを一般的なテックニュースとして扱うことが許されていないからである。金融機関が Salesforce と Drift を使用していた場合、顧客、見込み客、内部のデータが露出したかどうか、CRM レコード内の認証情報が下流のリスクを生み出したかどうかを評価しなければならなかった。同じ論理は、医療、教育、ソフトウェア、公共部門の契約、および Salesforce が機密性の高い運用コンテキストを含むすべてのセクターに適用される。

このインシデントは可視性の非対称性を露わにした

プラットフォームは、個々の顧客には見えないパターンを把握している。単一の顧客は、自身の Salesforce 組織内の奇妙な API 挙動に気づくかもしれない。Salesforce は AppExchange アプリのインストール、トークン失効、そして顧客横断的なパターンを見ることができる。Salesloft は Drift 製品のテレメトリとトークン保管状況を見ることができる。Google Threat Intelligence は、顧客をまたぎ、自身の調査を通じて脅威活動を見ることができる。どの一顧客もキャンペーン全体を見ることはできない。

この非対称性は義務を生み出す。顧客横断的な可視性を持つ当事者は、迅速に警告しなければならない。製品テレメトリを持つ当事者は、迅速に調査し封じ込めなければならない。プラットフォームは、影響を受けた顧客が誰であるかを特定しなければならない。顧客は、通知を受けたら迅速に行動しなければならない。いずれかの当事者が完璧な証拠を待てば、攻撃者は有効な権限を使い続けることができる。

公的な記録は、協調的な行動を示唆しているが、内部のエスカレーションの正確な速度は示していない。GTIG はキャンペーンが早くとも8月8日から始まったと述べた。Salesforce のアドバイザリは、失効と削除の措置を報告した。Salesloft の Trust Center は、Mandiant が8月26日に関与したと述べている。これらの日付は動きを示しているが、各当事者がいつ行動を起こすに足るだけの知識を得たのか、あるいはそれ以前にどのようなシグナルが利用可能だったのかは示していない。

この欠けたタイムラインが重要なのは、OAuth キャンペーンが高速だからである。トークンが盗まれれば、攻撃者はクエリとエクスポートを自動化できる。数日の差で、顧客が使用前にシークレットをローテーションできるかどうかが決まる。高品質のポストモーテムは、検出時間、判断時間、トークン失効時間、顧客通知時間、そしてログ利用可能時間を示すはずである。

顧客が責められることなく学ぶべきこと

顧客には責任があるが、教訓が「顧客がもっとよく知っておくべきだった」となってはならない。多くの顧客は、プラットフォームの信頼シグナルに依拠してマーケットプレイスアプリをインストールする。ベンダーが必要だと言うためにスコープを承認する。従業員が CRM を顧客業務の共有記憶として使用するために、運用データが CRM 内に保存される。これらは無謀な行為ではなく、通常のビジネス行動である。

より良い教訓は、接続アプリの規律あるガバナンスである。顧客は、接続アプリ、所有者、スコープ、トークンの有効期間、最終利用日、ベンダーリスクステータスの棚卸しを行うべきである。不要になったアプリは削除すべきである。アプリが利用できるプロファイルと権限セットを制限すべきである。CRM データのシークレットをスキャンすべきである。API の挙動をユーザーごとだけでなく、アプリごとに監視すべきである。緊急トークン失効のプレイブックを備えるべきである。

Salesforce は、これらの顧客の責任を容易にも困難にもできる。明確なアプリ権限の説明、アプリのリスクスコアリング、広範なスコープに対する管理者警告、シンプルなトークンインベントリ、より良いデフォルトの有効期限、異常アラート、強力な AppExchange レビューは、顧客の負担を軽減できる。プラットフォームの設計が顧客の行動を形作る。

Salesloft や他の SaaS ベンダーも、トークンを安全に保管し、最小限のスコープを要求し、認証情報をローテーションし、インシデント更新を迅速に公開し、セグメンテーションを証明することで負担を軽減できる。Salesloft の Trust Center が Drift と Salesloft アプリケーション間のセグメンテーションの検証を参照していることは重要である。顧客は、ある製品の侵害がより広範なベンダー侵害にならなかったという確信を必要としているからである。

OAuth 標準は、なぜベアラートークンに特別な規律が必要かを説明している

OAuth は委任された認可のために設計されている。コアとなる OAuth 2.0仕様RFC 6749は、クライアントがリソース所有者の認可のもとにリソースへのアクセストークンを取得することを可能にする。ユーザーがクライアントにパスワードを渡す必要がないため、この設計は強力である。リスクは、アクセストークンがしばしばベアラー（無記名）認証情報であることだ。すなわち、保有者は誰でも、それが期限切れになるか失効されるまで、そのスコープ内で使用できる。

RFC 6819の OAuth 脅威モデルとセキュリティ考慮事項は、トークン漏洩、トークン保管、リプレイ、フィッシング、リダイレクト悪用、そしてスコープと有効期間の制限の必要性を警告している。新しい OAuth 2.0セキュリティベストカレントプラクティスであるRFC 9700は、現代的な防御パターンを強調することでその方向性を継承している。これらの標準は Salesforce のインシデント報告ではない。Drift キャンペーンがなぜ構造的に危険だったのかを説明している。

もし Drift トークンが広範な Salesforce アクセス権を持っていれば、トークン自体が信頼を体現していたことになる。セキュリティチームは、ユーザーパスワードを削除し、MFA を強制しても、アプリトークンが有効なままであればリスクに直面しうる。これが、トークン失効が緊急措置だった理由である。また、次の層がスコープ最小化である理由でもある。狭いスコープを持つ盗まれたトークンは害を及ぼしうるが、限定されている。広範な読み取りアクセスを持つ盗まれたトークンは、データエクスポートツールになりうる。

MITRE ATT&CK のテクニックSteal Application Access Tokenは、攻撃者がリモートシステムや API にアクセスするためにアプリケーションアクセストークンを盗むことを説明している。Use Alternate Authentication Materialは、パスワードの代わりに有効な認証成果物を使用するというより広範なパターンをカバーしている。これらのフレームワークは、Salesforce 固有の事実を誇張することなく、攻撃クラスを名指しするのに役立つ。問題は、有効な委任された資料が悪意のある者の手に渡ったことである。

標準的な教訓はシンプルだが、運用上は難しい。トークンはシークレットとして扱われるべきである。リフレッシュトークンは将来のアクセスを生成できるため、特に機密性の高いシークレットとして扱われるべきである。スコープは製品が許容できる限り狭くすべきである。トークンはローテーション可能かつ失効可能であるべきである。ログはアプリとオブジェクトごとにトークンの使用状況を示すべきである。顧客はどの非人間 ID が自社のデータを読み取れるかを知るべきである。プラットフォームは、危険なスコープが黙って承認されるのを難しくすべきである。

接続アプリの衛生管理には、侵害後のスプレッドシートではなく、オーナーが必要である

多くの組織は、インシデントの最中に自分たちの接続アプリを発見する。それは遅すぎる。接続アプリの棚卸しはキャンペーンの前に存在すべきである。アプリ名、ベンダー、ビジネスオーナー、テクニカルオーナー、スコープ、インストールされたプロファイル、最終使用日、リフレッシュトークンポリシー、触れるデータオブジェクト、契約状況、そして削除手順。もし誰もアプリを所有していなければ、誰もリスクを所有していない。

Salesforce の接続アプリ管理および接続アプリの OAuth ポリシーのドキュメントは、プラットフォームが管理制御を提供していることを示している。問題は、顧客がそれらをうまく使いこなすためのスタッフ、知識、インセンティブを持っているかどうかである。小規模企業は営業用チャットツールをインストールし、そのスコープを二度と見直さないかもしれない。大企業は数百の接続アプリを抱えながら、統一されたレビューサイクルがないかもしれない。

ここでプラットフォームの設計がエラーを減らすべきである。危険なスコープは平易な言葉で可視化されるべきである。未使用の接続アプリは容易に見つけられるべきである。リフレッシュトークンを持つアプリは強調表示されるべきである。高リスクアプリには、有効期限または定期的な再認可のオプションがあるべきである。管理者は、無関係なワークフローを壊さずにアプリのアクセスを失効できるべきである。セキュリティチームは、アプリ固有の API 異常アラートを受信すべきである。

顧客はポリシーも必要とする。命名された所有者とレビュー日なしに、どのアプリも広範なアクセスを受けるべきではない。ビジネスオーナーが去った後に、アプリがインストールされたままであるべきではない。便利だからといって、CRM レコード内にシークレットを保存すべきではない。「単なる営業ツール」だからといって、どのアプリもインシデントプレイブックから免除されるべきではない。Drift キャンペーンは、営業ツールがセキュリティインシデント経路になりうることを示した。

問題は部分的には経済的である。接続アプリは労力を節約する。レビューには労力がかかる。利益が即時的でリスクが稀である場合、組織はレビューへの投資を怠る。プラットフォームとベンダーは、良好なガバナンスのコストを下げることで、この不均衡を軽減できる。すなわち、明確なダッシュボード、リスクスコア、自動化された推奨、そしてより安全なデフォルトである。

ログは顧客が行動に移せる質問に答えなければならない

インシデント対応ガイダンスはしばしば顧客にログの確認を促す。そのアドバイスは、ログが適切な質問に答える場合にのみ有用である。Drift キャンペーンに関しては、顧客はどのアプリトークンが使用されたか、どの Salesforce オブジェクトが照会されたか、どのレコードがエクスポートされたか、どの IP からか、どのユーザーコンテキストでか、どの時間枠でか、そしてクエリがシークレットのような文字列を検索したかどうかを知る必要があった。

Salesforce のイベント監視、API ログ、接続アプリレポートは役に立つが、完全な証拠へのアクセスはライセンス、保持期間、設定に依存する可能性がある。適切なエディションやログエクスポートパイプラインを持たない顧客は、通知を受け取っても露出を判断するのに苦労するかもしれない。これはプラットフォームガバナンスの問題である。マーケットプレイス統合が顧客を越えて悪用された場合、プラットフォームは正規化された証拠パッケージを提供するのに最適な立場にある。

顧客はまた、再現可能なトリアージパスを必要とする。第一に、Drift がインストールされ接続されていたかを特定する。第二に、キャンペーン期間中にトークンがアクティブだったかを判断する。第三に、アプリに帰属する API アクティビティを検査する。第四に、オブジェクトとフィールドのアクセスを特定する。第五に、エクスポートまたはアクセス可能なレコードをシークレットについて検索する。第六に、露出した可能性のあるシークレットをローテーションする。第七に、規制対象または顧客データが関与している場合、下流の関係者に通知する。

FBI/IC3 アドバイザリと GTIG のガイダンスは顧客をこの種の行動へと導いているが、実行にはばらつきがある。大手金融機関はセキュリティオペレーションチームとログレイクを持っているかもしれない。小規模な SaaS 企業は、Salesforce 管理者、管理されたセキュリティベンダー、そしてバックログを抱えているかもしれない。したがって、同じキャンペーンでも回復の負担は不均等である。

その不平等性は説明責任にとって重要である。成熟度が大きく異なる企業群を対象とするプラットフォームは、すべての顧客が生のログや脅威インテリジェンスの指標を解釈できると仮定すべきではない。実行可能でテナント固有の証拠は、対応コストと、盗まれたシークレットが有効なまま残る可能性を低減する。

CRM レコード内のシークレットは予防可能でありながら一般的な失敗である

不快な教訓の一つは、顧客が CRM を運用シークレットの安全な保管場所として扱うのをやめなければならないことである。サポートチームや営業チームは、問題を解決しようとするあまり、しばしば API キー、認証情報、ベアラートークン、Webhook シークレット、VPN の詳細、スクリーンショットをケースやメモに貼り付ける。CRM は便利なアーカイブになる。統合がそれを読み取れる場合、その便利なアーカイブはシークレットリポジトリになる。

OWASP のシークレット管理チートシートは、シークレットが管理された保管、ローテーション、アクセス規律を必要とする理由を説明している。Drift キャンペーンは、この原則を CRM データに適用する。シークレットがレコードに現れると、CRM エクスポートはキーホルダーになりうる。

修復は部分的に技術的である。レコードをシークレットパターンについてスキャンし、機密フィールドをマスクし、添付ファイルを制限し、既知のキー形式が現れたら警告する。また、文化的なものでもある。サポートチームに対し、シークレットを要求したり保存したりしないよう訓練し、必要な診断資料のための安全な入力チャネルを提供し、発見されたシークレットを容易に削除できるようにする。組織が迅速なサポートを称賛し、安全でないサポートノートを罰しないなら、従業員は近道を続けるだろう。

Salesforce と統合ベンダーは、シークレット検出機能を組み込み、広範なアプリスコープが機密運用データを含む可能性のあるオブジェクトを含む場合に顧客に警告することで支援できる。しかし、顧客は依然として各自の組織内のデータ衛生を所有している。Drift インシデントが CRM にシークレットを保存する悪習慣を生み出したわけではない。それは、その習慣がサードパーティのトークン侵害をいかに増幅しうるかを露呈したのである。

公的な記録は、起きなかったことを保存すべきである

公的な記録が示していないことを述べることも同様に重要である。情報源は、攻撃者が Salesforce の中核的な脆弱性を悪用したことを示していない。すべての Salesforce 顧客が影響を受けたことを示していない。Drift 接続顧客全員で同じデータがエクスポートされたことを示していない。エクスポートされたすべてのレコードにシークレットが含まれていたことを示していない。Salesloft のより広範な製品群が、同社の調査で説明された以上に侵害されたことも示していない。

これらの制限は公正さを保護する。また、真の教訓をより鮮明にする。このインシデントが誇張なしに深刻であるのは、信頼された統合が顧客環境への委任アクセス経路となったからである。その重大性は、プラットフォームのゼロデイをでっち上げる必要性からではなく、信頼モデルに由来する。

このインシデントは、「サードパーティリスク」といった漠然とした言葉に矮小化されるべきでもない。特異的なサードパーティリスクは、トークン保管と接続アプリの権限であった。ベンダーは SOC 報告書、契約書、セキュリティ質問票を持っていても、同時に例外的な保護を必要とするトークンを保持しうる。顧客のベンダーリスクレビューでは、SaaS 統合がトークンをどのように保管するか、どのようなスコープを必要とするか、どれだけ迅速にトークンを失効できるか、インシデント後にベンダーがどのような証拠を提供できるかを問う必要がある。

プラットフォームの AppExchange レビューも具体性を要する。それは、アプリが機能し、リスト掲載時にベースラインのセキュリティ要件を満たしているかどうかのみを確認するべきではない。継続的な監視、迅速な停止、顧客通知、インシデント後の再検証をサポートすべきである。マーケットプレイスにおける信頼は、一回限りのバッジではなく、継続的な義務である。

評価を変えうる証拠

更なる証拠があれば、この評価はいずれの方向にも変わりうる。もし後のフォレンジック詳細が、侵害されたトークンが極めて狭小であり、エクスポートが限定的であり、影響を受けた顧客が迅速に完全なオブジェクトレベルのログを受け取ったことを示すなら、運用上の重大度は引き下げられるべきである。もし後の証拠が、より広範なスコープ、長期間有効なトークン、弱いトークン保管、失効の遅延、広範なシークレット露出を示すなら、重大度は引き上げられるべきである。

Salesforce が AppExchange の監視改善、トークンインベントリ機能、顧客ログパッケージ、より安全な接続アプリのデフォルトについてさらなる詳細を公表すれば、それによって修復記録は強化される。Salesloft が根本原因、トークン保管、セグメンテーション、顧客の修復に関する詳細を公表すれば、それによってベンダーの説明責任は強化される。規制当局が知見を発表した場合、それらは現在の公的アドバイザリ記録とは別に評価されるべきである。

それまでは、証拠は高い信頼性の管理上の結論を支持している。すなわち、SaaS エコシステムは、委任されたトークンを統合の配管ではなく、プロダクション認証情報として扱う接続アプリガバナンスを必要とする。

この結論は、誇張を避けているからこそ有用である。これにより、顧客は最終的な法廷記録を待つことなく、接続アプリを堅牢化できる。プラットフォームは、証拠が示さないコアプラットフォームの欠陥を認めることなく、マーケットプレイスとトークンの制御を改善できる。ベンダーは、トークン保管を製品安全性の義務として扱うことができる。このキャンペーンの教訓は推測ではない。委任されたアクセスは盗まれうる。そして盗まれたとき、エコシステムは、誰がそれを失効できるか、誰がそれを説明できるか、誰がそれが何に触れたかを証明できるかを知らなければならない。

失効訓練は定例化されるべきである

OAuth ガバナンスが本物かどうかを知る最も速い方法は、インシデント前に失効訓練を実施することである。重要でない接続アプリを一つ選ぶ。ビジネスオーナー、スコープ、ユーザー、トークン、ログ、依存するワークフロー、そしてロールバックの手順を特定する。管理された時間枠内でアクセスを失効させ、何が壊れるかを測定する。そして、誰が復旧を承認し、アプリが再接続しても安全であることを示す証拠が何かを文書化する。

この訓練は、抽象的なアプリ棚卸しを運用的な知識に変える。セキュリティがアプリを見つけられるか、管理者がそれを失効できるか、ビジネスがワークフローを理解しているか、ユーザーが明確な指示を受け取るか、ログがアプリが何にアクセスしたかを証明できるかが示される。また、なぜ存在するのか誰も知らないために、チームが古い統合に触れるのを恐れている場所も明らかになる。

Drift キャンペーンは、この実践が重要である理由を示している。実際の侵害では、組織は攻撃者が盗んだトークンを使っている間に、誰が統合を所有しているかを発見するのに日数をかけるわけにはいかない。準備された顧客は、まず失効させ、迅速に調査し、証拠がある場合にのみ再接続できる。準備されていない顧客は、すべてのトークンが事業継続に見えるために躊躇するかもしれない。

説明責任のテスト

Drift-Salesforce キャンペーンは、以下の7つの管理策を通じて判断されるべきである。

第一に、トークン保管：Salesloft はアクセストークンとリフレッシュトークンを極めて機密性の高い認証情報として保護し、そのアーキテクチャは Drift および他の製品にわたってトークンの露出を最小限に抑えたか。

第二に、スコープ設計：Drift 統合は、必要な Salesforce 権限のみを要求し、顧客はそれらの権限を承認することの影響範囲を理解していたか。

第三に、マーケットプレイスガバナンス：Salesforce の AppExchange レビュー、監視、緊急削除プロセスは、ベンダーアプリが安全でなくなった後、十分に迅速に顧客リスクを低減したか。

第四に、顧客横断的検出：Salesforce、Salesloft、脅威インテリジェンスパートナーは、さらなるエクスポートの前にトークンを失効させるのに十分な速さでキャンペーンパターンを特定したか。

第五に、テナント証拠：影響を受けた顧客は、何が照会され、シークレットが露出したかどうかを判断するために十分なログ、オブジェクトアクセス証拠、およびガイダンスを受け取ったか。

第六に、シークレット衛生：顧客はパスワード、API キー、クラウドトークン、または VPN 認証情報を Salesforce レコードに保存していたか、そして露出後にそれらをローテーションしたか。

第七に、公開情報伝達：アドバイザリは、Salesforce のコアが悪用されていないという重要な区別を維持しつつ、信頼されたアプリトークンを通じて Salesforce の顧客データがアクセスされたことを明確にしたか。

最終的な所見は、Salesforce が脆弱な製品だったということではない。公的記録はその逆を述べている。問題は Salesforce の中核プラットフォームの脆弱性に起因するものではなかった。所見は、顧客がエコシステムを通じてプラットフォームを経験するため、Salesforce の信頼境界が接続アプリを含むということである。OAuth トークンは委任された権限である。信頼された統合がその権限を失ったとき、プラットフォーム、ベンダー、顧客はすべて異なる義務を負う。Drift キャンペーンは、承認された生産性統合を攻撃者が保持する鍵に変えるという最も不快な方法で、それらの義務を可視化したのである。