2025年8月、Salesloft社が提供するチャットプラットフォーム「Drift」を経由した大規模なサプライチェーン攻撃が発覚しました。攻撃者は、Driftと外部サービス（Salesforceなど）を統合する際に利用されていたOAuthトークンを窃取し、複数の大企業のシステムへ不正アクセスを行いました。影響はCloudflareやZscalerといった世界的な企業にまで及び、サポートケースや顧客関連データが流出した可能性が指摘されています。
今回の攻撃の重要な点は、標的が「AIチャットボット」そのものではなく、サプライチェーンを構成する外部サービス統合の脆弱性だったことです。OAuthトークンはサービス間認証の基盤として広く利用されていますが、一度流出すれば本人になりすまして無制限にアクセスできる強力な「鍵」として機能します。そのため、管理の不備や第三者への委託によって安全性が損なわれると、そこを突破口にして被害が一気に広がるリスクを孕んでいます。
この事件は「サプライチェーン攻撃」と呼ばれますが、実態としてはDriftという外部ベンダーを通じて複数企業が侵害された事例です。つまり、1社のセキュリティ不備が取引先全体に波及する構造的なリスクが浮き彫りになったといえます。
本記事では、事件の概要と技術的なポイントを整理し、OAuthトークンのセキュリティに関して押さえるべき基本的な対策について解説します。AIという観点ではなく、「認証情報の管理不備がサプライチェーン全体のリスクになる」という本質的な問題に焦点を当てます。
攻撃の概要
今回確認された攻撃は、Salesloft社のチャットプラットフォーム「Drift」と外部サービス（特にSalesforce）との統合部分を起点としています。Driftは、顧客とのチャット内容やリード情報をSalesforceなどのCRMに自動反映させる機能を持っており、その際にOAuthトークンを用いて認証・認可を行います。
攻撃者は、このDriftが保持していたOAuthアクセストークンを窃取することに成功しました。流出経路の詳細は公表されていませんが、考えられるシナリオとしては以下が指摘されています。
- Drift内部のシステムやログからトークンが平文で漏洩した可能性
- トークンの保護・ライフサイクル管理に不備があり、有効期限が長すぎた可能性
- APIアクセス制御や監視の欠如により、不審な利用が長期間検知されなかった可能性
攻撃期間は2025年8月12日から17日にかけてで、短期間で集中的に行われたとされています。攻撃者は窃取したトークンを使い、Salesforceに正規の認証済みユーザーとしてアクセスし、サポートケース情報や営業関連データなどを参照・抽出したと見られています。
被害は単一の企業にとどまりませんでした。Driftは多数の顧客企業で利用されているため、結果的にCloudflare、Zscaler、Palo Alto Networksといった大手を含む700以上の組織が影響を受けたと報告されています。特にCloudflareは公式ブログで、自社のサポートケース情報が一部閲覧された可能性を認め、即座に対応措置を取ったことを公表しました。
この事件の特徴は、攻撃者がDrift自体を最終標的にしたわけではなく、Driftを踏み台として顧客企業のシステムに侵入した点にあります。つまり、直接攻撃が困難な大企業を狙うのではなく、その周辺のサプライチェーン（サービス提供企業）の弱点を突くことで一気に広範な影響を与える典型的な攻撃パターンです。
技術的なポイント
1. OAuthトークンの仕組みとリスク
OAuth 2.0は、サービス間で安全に認証・認可を行うために広く使われているプロトコルです。ユーザーのパスワードを直接渡す代わりに、アクセストークンという「代理の鍵」を発行し、これを利用してAPIにアクセスします。
しかし、この仕組みには大きな前提があります。「トークンが絶対に漏れない」ということです。アクセストークンは発行後、失効するまで本人になりすまして利用可能であり、流出すれば攻撃者にとって非常に強力な侵入手段となります。
特に、トークンの有効期限が長すぎる場合や、リフレッシュトークンが安全に管理されていない場合、被害はさらに深刻になります
2. 外部サービス統合とサプライチェーンの弱点
今回の事件は、Driftのような外部サービスが保持していたOAuthトークンが突破口となりました。
- Driftはチャット内容やリード情報をSalesforceに送信するため、Salesforce APIにアクセスする権限を持つトークンを管理していました。
- つまり、利用企業は自社のSalesforceを守っていても、外部サービス側のセキュリティが甘ければ意味がないという状況が生じてしまいます。
- このように、自社の境界を超えた場所にある認証情報が侵害されることで被害が波及する点が、サプライチェーン攻撃の典型的な脆弱性です。
3. トークン管理における具体的な問題点
今回のケースで想定される問題は次の通りです。
- 有効期限が長すぎるトークン：窃取後も長期間利用可能であれば、検知までに甚大な被害が広がる。
- スコープが広すぎるトークン：不要な権限を持っていれば、侵入後に参照・変更できる範囲が拡大する。
- 保存方法の不備：ログや設定ファイルに平文で残っていた場合、内部からの流出や外部侵入時に容易に盗まれる。
- 監視不足：不審なアクセスパターン（例：異常な時間帯や海外からのAPIアクセス）が検知されず、侵入が長期化する。
4. 攻撃の構造的な特徴
攻撃者はDriftのサービス自体を破壊したり改ざんしたりしたわけではありません。代わりに、Driftが持っていたOAuthトークンを利用し、あたかも正規のユーザーやアプリケーションであるかのように外部サービス（Salesforceなど）に侵入しました。
これにより、外部からの攻撃としては目立ちにくく、通常のログイン試行や不正アクセスの兆候を出さずにシステム内部に入り込めたのです。
このような「正規の認証情報を盗んで使う」攻撃は、パスワードやAPIキーの流出と同様に検知が難しいことが特徴です。
5. 今回の事例が示す本質
- OAuthは利便性の高い認証・認可の仕組みだが、トークン管理の安全性が保証されなければ逆に最大の弱点になる。
- 外部サービスと統合すること自体が「自社の防御範囲外にトークンを置く」ことを意味し、サプライチェーン全体を通じたセキュリティリスク管理が不可欠。
- この構造的な問題は、Driftに限らず多くのSaaSサービス連携に当てはまる。
セキュリティ上の教訓と対策
今回のインシデントは、OAuthトークンの管理不備がどのようにサプライチェーン全体のリスクに直結するかを示しました。重要なのは「トークンを提供する側（外部サービスベンダー）」と「トークンを受領する側（利用企業）」の双方で対策を講じることです。どちらか片方が堅牢でも、もう一方が弱ければ全体として防御は成立しません。
1. OAuthトークンを提供する側（外部サービスベンダー）
外部サービスは、多数の顧客のシステムにアクセスするためのトークンを保持する立場にあり、ここが破られると一気に被害が連鎖するリスクを抱えています。今回のDriftのように「一社の不備が多数の企業へ波及」する構造的な弱点があるため、ベンダー側には特に強固な管理が求められます。
教訓と対策
- 短寿命トークンの発行と更新
- 長期間有効なアクセストークンを発行せず、数分〜数時間で期限切れとなる短命トークンを基本とする。
- 自動更新の仕組みを導入し、顧客側は透過的に新しいトークンを利用できるようにする。
- スコープの最小化と分離
- 「読み取り専用」「書き込み限定」など、用途ごとにスコープを細かく分ける。
- 顧客ごとに独立したトークンを発行し、1つが流出しても他社には波及しない設計にする。
- 安全な保管と鍵管理
- トークンを平文でログや設定に残さない。
- HSM（Hardware Security Module）やSecrets Managerを用い、復号は安全領域でのみ可能にする。
- 異常利用の監視と自動失効
- 不自然なアクセスパターン（短時間で大量アクセス、国外からの利用など）を監視。
- 検知した場合は自動的にトークンを失効し、顧客に即通知する仕組みを標準化する。
- 透明性の確保
- インシデントが発生した場合、影響範囲と対応策を迅速かつ正確に公表する。
- 顧客に「どのトークンが影響を受けたか」「どのデータにアクセスされた可能性があるか」を開示できるログを保持しておく。
2. OAuthトークンを受領する側（顧客企業）
顧客企業は外部サービスとの統合によって利便性を得る一方、自社の認証情報を第三者に預けることになります。この時点で「自社のセキュリティ境界が広がる」ため、依存リスクを踏まえた設計・運用が不可欠です。
教訓と対策
- 外部サービスのセキュリティ評価
- ベンダー選定時に、OAuthトークンの取り扱い方針、暗号化方法、監査体制を確認する。
- SOC 2やISO 27001などの認証取得状況を参考にする。
- スコープと権限の制御
- 不要に広いスコープのトークンを許可しない。
- 「参照だけで十分な統合」であれば書き込み権限を付与しない。
- 利用環境の制限
- トークンの利用元を特定のネットワークやIPに限定する。
- 自社内のアクセス制御（ゼロトラストモデル）と組み合わせ、外部からの不審アクセスを防ぐ。
- 監視とアラート
- 外部サービス経由で行われたAPIアクセスを可視化し、不審な挙動があれば即時検知できる仕組みを持つ。
- Salesforceなど側でも「どのアプリケーションからアクセスが来ているか」を監査する。
- 侵害前提のリスクマネジメント
- トークンが漏洩する可能性をゼロにできない前提で設計する。
- 被害が起きても影響範囲を限定できるように、重要データと外部サービスとの接続を分離する。
- 定期的にトークンを再発行・棚卸しし、不要な連携は削除する。
まとめ
OAuthトークンはサービス統合の利便性を支える一方で、流出すれば強力な攻撃手段となります。今回の事件は「提供する側」と「受領する側」の双方で適切な管理を怠れば、サプライチェーンを通じて被害が拡大することを示しました。
- 提供側には「短寿命化・スコープ最小化・強固な保管・監視・透明性」が求められ、
- 受領側には「ベンダー評価・権限制御・利用制限・監視・リスクマネジメント」が不可欠です。
つまり、セキュリティは一方的な責任ではなく、提供者と利用者の協働によって初めて成り立つという点が最大の教訓といえます。
まとめ
今回の事件は、OAuthトークンという技術要素がいかに便利であると同時に、大きなリスクを抱えているかを改めて示しました。OAuthはWebサービスやSaaSの統合を容易にし、ユーザー体験を向上させる強力な仕組みです。しかし、その利便性の裏には「一度発行されたトークンが漏洩すれば、正規のユーザーになりすまして広範なアクセスを許してしまう」という構造的な脆弱性があります。
今回の侵害は、AIチャットボット自体が攻撃対象だったわけではなく、外部統合に利用されるOAuthトークンが突破口になったという事実に注目すべきです。つまり、個別のサービスだけを堅牢に守っても、サプライチェーンの一部に弱点があれば全体が危険にさらされるという現実を突きつけています。これはSolarWinds事件や他の大規模サプライチェーン攻撃とも共通する教訓です。
では、我々はどう対応すべきか。答えは「完璧な防御」を追い求めるのではなく、多層的に防御を重ね、攻撃の成功確率を下げ、万一突破されても被害を最小化することにあります。提供する側（サービスベンダー）は短寿命トークンや権限スコープの制御、安全な保管と監視を徹底し、受領する側（顧客企業）はベンダー評価や利用制御、リスク前提の運用を組み込む必要があります。
サプライチェーンを通じた攻撃は今後も増えると予想されます。外部サービスとの統合は避けられない以上、「どのように信頼を設計するか」が問われています。OAuthトークン管理のあり方は、その最前線にある課題の一つです。本件を一過性の事故として片付けるのではなく、セキュリティを提供者と利用者の協働によって成り立たせる仕組みを築くきっかけにすべきでしょう。
参考文献
- Salesloft Takes Drift Offline After OAuth Token Theft Hits Hundreds of Organizations
https://thehackernews.com/2025/09/salesloft-takes-drift-offline-after.html - The impact of the Salesloft Drift breach on Cloudflare and our customers (Cloudflare blog)
https://blog.cloudflare.com/response-to-salesloft-drift-incident/ - Salesloft Drift attacks hit Cloudflare, Palo Alto Networks, Zscaler (CyberScoop)
https://cyberscoop.com/salesloft-drift-attacks-cloudflare-palo-alto-networks-zscaler/ - Cloudflare Breach Exposes Customer Support Data in Major Salesloft Supply-Chain Attack (Winbuzzer)
https://winbuzzer.com/2025/09/03/cloudflare-breach-exposes-customer-support-data-in-major-salesloft-supply-chain-attack-xcxwbn/
