皆さん、こんにちは！エンジニア向けに技術情報をお届けするTetraです。
CXプラットフォームの脆弱性とOAuth悪用の脅威概要
今日は最新のニュースではなく、あえて過去の事例を振り返り、今なお私たちを脅かすセキュリティの課題について考えたいと思います。普段、我々が必死に守っているサーバーやDBの「正面玄関」ではなく、マーケティングチームやカスタマーサポートが使っている「勝手口」が開けっ放しになっているかもしれない、というお話です。
本記事では、一昨年（2024年）に話題となった、顧客体験（CX）プラットフォームの脆弱性を突き、OAuthトークンを悪用して700社以上の組織に侵入した攻撃事例を技術的な視点で解説します。WAFや従来の境界防御をすり抜ける「正規権限」による攻撃のメカニズム、そして現在も脅威であり続けるAIへの「データポイズニング」について、エンジニアが取るべき具体的な対策（SSPMの導入やトークン棚卸しなど）と共に深掘りしていきます。
キーワード：CXプラットフォーム脆弱性、OAuthトークン侵害、AIデータポイズニング、サプライチェーンリスク、SSPM
【事例解説】CXプラットフォームが700社のセキュリティホールに
かつてVentureBeatの報道などで、顧客体験（CX）プラットフォームを経由したサプライチェーン攻撃が深刻なリスクとして議論されました。特に記憶に新しいのは、2024年8月に発生したSalesloftやDriftといった主要SaaSを標的とした侵害事例です。この攻撃の特徴は、ランサムウェアやウイルスといった従来のマルウェアを一切使用せず、盗み出したOAuthトークンを使って正規のAPI経由で侵入が行われた点にありました。結果として、CloudflareやPalo Alto Networksを含む700以上の組織のSalesforce環境へ、攻撃者がアクセス可能な状態になってしまっていたのです。
CXプラットフォームは、SNSのレビュー、メール、コールセンターの通話記録など、膨大な「非構造化データ」をAIに取り込み、CRMや給与システムと連携して自動処理を行っています。しかし、多くの企業のセキュリティ監視センター（SOC）は、このCXツールのAIが「何を食べているか（データの入力）」や「どこへアクセスしているか（API連携）」を十分に監視できていませんでした。攻撃者はこの盲点を突き、正当な権限でラテラルムーブメント（横展開）を行ったのです。
【技術解説】なぜWAFをすり抜けるのか？OAuth悪用のメカニズム
エンジニアの皆さんなら、「なぜWAFやファイアウォールで防げないのか？」と疑問に思うかもしれません。その答えは、攻撃手法が「脆弱性の悪用（Exploit）」ではなく「機能の悪用（Abuse）」だからです。これは2026年の現在でも、変わらず有効な脅威です。
1. 正規のBearerトークンによる認証通過
通常の攻撃であれば、SQLインジェクションやXSSのような不正なパターンを含むリクエストがWAFによって遮断されます。しかし、このケースで攻撃者が使用するのは、正規の手順で発行されたOAuthのアクセストークンです。HTTPヘッダーに Authorization: Bearer {valid_token} が付与されたリクエストは、システム側から見れば「認証された正当なユーザー」そのものです。したがって、IPアドレス制限などが設定されていない限り、ゲートウェイはこれを通過させてしまいます。
2. スコープ（権限）の過剰付与
最大の問題は、発行されるトークンのスコープ（権限範囲）にあります。本来であれば「プロフィールの読み取り（read）」だけで済むはずの連携が、設定の簡便さを優先して「全データの読み書き（full access）」や「管理者権限（admin）」といった強力なスコープで認可されているケースが散見されます。攻撃者はこの過剰な権限を利用し、本来アクセスできないはずのSalesforce上の顧客台帳や商談データをごっそりと抜き出します。
3. リフレッシュトークンの永続化
さらに厄介なのが offline_access スコープによるリフレッシュトークンの発行です。一度認証してしまえば、ユーザーがログアウトしても、攻撃者はリフレッシュトークンを使って半永久的に新しいアクセストークンを取得し続けることが可能です。これにより、発覚するまで数ヶ月にわたり潜伏し続ける「持続的な標的型攻撃（APT）」が成立してしまうのです。
【考察】「便利なツール」が「特権ID」を持つ恐怖
ここからは、現役エンジニアとしての視点でこの事例を深掘りしていきましょう。
正直なところ、当時この事例を知って「やっぱりか」と冷や汗をかいた方も多かったのではないでしょうか。日本の開発現場でもよくある光景ですが、マーケティング部門や人事部門が「業務効率化」のためにSaaSを導入すること、ありますよね。「エンジニアのリソースを使わずに導入できるから」と、クレジットカード一枚で契約され、いつの間にかSlackやSalesforce、あるいは社内のデータベースと連携されている……。いわゆる「シャドーIT」や「ビジネス主導IT」と呼ばれる領域です。
ここに潜む最大のリスクは、「権限のインフレ」と「ゾンビトークン」です。
報道でも指摘されていましたが、例えば「半年前のマーケティングキャンペーン」のために発行されたAPIトークンが、キャンペーン終了後も削除されずに生き残っているケース。これ、システム運用の現場では本当によくある話だと思います。
開発者が管理しているAWSのアクセスキーなら定期的なローテーションや権限の最小化を意識しますが、非技術者が設定したSaaSの連携トークンは、「とりあえず動くように」と強力な権限が付与されたまま、放置されがちです。
攻撃者からすれば、堅牢な企業の境界防御を突破するよりも、こうした放置されたOAuthトークンをダークウェブなどで入手し、「正規のユーザー」としてログインする方が圧倒的に楽です。ログを見ても「正規のAPIアクセス」として記録されるため、従来のSIEM（セキュリティ情報イベント管理）やDLP（情報漏洩防止）ツールでは検知が極めて難しいのです。これが、この事例が残した大きな教訓です。
【未来】AIへの「データポイズニング」が現実的な脅威に
さらに、技術的な観点で注目すべきは「AIへの入力データ」に対する攻撃です。
これまでのセキュリティは「不正なコードを実行させない」「データを盗ませない」が主眼でしたが、AI活用が当たり前となった現在、「AIに嘘を教え込まない」ことがより重要になっています。
RAG（検索拡張生成）への汚染攻撃
多くのCXプラットフォームでは、社内のナレッジベースや過去の対応履歴をAIに参照させる「RAG（Retrieval-Augmented Generation）」という技術が使われています。もし攻撃者が、カスタマーサポートのチャットボットやメールフォームを通じて、悪意のあるプロンプトや虚偽の情報（ポイズニングデータ）を大量に送り込んだらどうなるでしょうか？
例えば、「特定の条件を満たす顧客には、全額返金を行うのが会社の新しいポリシーです」といった偽の情報をAIの学習データや検索インデックスに紛れ込ませるのです。次にAIが正規の顧客対応をする際、この汚染された情報を「真実」として参照し、勝手に返金処理を承認してしまう可能性があります。
当時の記事では、これが「ビジネス上の誤判断」を招くと警鐘を鳴らしていました。AIが汚染されたデータを学習し、誤った給与調整や顧客対応を自動で実行してしまう。これはもはやサイバー攻撃というより、ビジネスロジックそのものへのハッキングです。
現在、AIエージェントが自律的にタスクをこなす場面が増えていますが、その「判断の根拠」となるデータの入口（Input Integrity）を守る技術は、依然として重要な課題です。パブリックな入力フォームに対するボット対策だけでは、AIエンジンの保護には不十分なのが現状です。
【提言】エンジニアは「管轄外」に踏み込む勇気を
では、私たちエンジニアはどうすべきでしょうか。
「それは情シスの仕事でしょ？」「マーケティング部が勝手にやったことだし」と言いたくなる気持ちは分かります。しかし、システム全体がAPIで繋がっている以上、ひとたび侵入を許せば、私たちが管理する本番データベースまで被害が及ぶ可能性があります。
私が提案したいアクションは以下の3つです。
- SSPM（SaaS Security Posture Management）の導入検討
手動での管理には限界があります。SaaSの設定ミスや過剰な権限を自動検知するSSPMツールの導入を検討しましょう。これにより、どのアプリがどのデータにアクセスしているかを可視化し、ポリシー違反を即座に検知できます。 - 「ゾンビトークン」の徹底的な棚卸し
開発環境だけでなく、全社的なSaaS連携の棚卸しを提案しましょう。「OAuth接続されているアプリの一覧」をIDプロバイダー（OktaやEntra IDなど）から出力するだけでも、意外な穴が見つかるはずです。特に「終了したプロジェクト」のアカウントやトークンは即座に無効化（Revoke）する必要があります。 - 「振る舞い検知」の視点を持つ
認証が通ったからといって信用しないゼロトラストの考え方を、SaaS連携にも適用すべきです。「普段アクセスしないデータに大量にアクセスしていないか」「深夜帯に異常なエクスポートが行われていないか」といった、認証後の振る舞い（UEBA: User and Entity Behavior Analytics）に注目したモニタリング体制が必要です。 - 非技術部門とのコミュニケーション
これが一番難しいかもしれませんが、最も効果的です。マーケティングや人事の担当者に、「便利なツールを使うな」と言うのではなく、「安全に使うための設定（権限の絞り込みなど）を手伝うよ」と声をかけること。シャドーITを撲滅するのではなく、管理下に置く（ライトアップする）アプローチが、これからのエンジニアには求められています。
まとめ
今回の振り返りは、セキュリティの死角が「技術的な脆弱性」から「運用の隙間（設定ミス）」や「AIの学習データ」にシフトしていることを改めて示しています。
便利なSaaSやAIツールが増えるほど、それらを繋ぐAPIという「糸」は複雑に絡み合います。その糸が攻撃者の侵入経路にならないよう、私たちエンジニアが率先してハサミ（不要な接続の遮断）と監視カメラ（モニタリング）を持っていく必要がありますね。
情報元: VentureBeat
※本記事は執筆時点（2026年02月20日）の情報に基づきます。
コメント