Klueサプライチェーン攻撃が示したSaaS連携リスクの現実

2026年6月のセキュリティニュースの中でも、特に多くの示唆を残したのが「Klueサプライチェーン攻撃」です。単に1社が侵害されたという話ではありません。営業支援や競合分析のために使われるSaaSが足がかりとなり、その先にある顧客企業のSalesforceデータへアクセスが広がった点に、この事件の本質があります。

しかも被害を受けた組織には、Huntress、Recorded Future、HackerOne、Snyk、Tanium、LastPass、BeyondTrustなど、セキュリティ業界で知られる企業も含まれていました。これは「セキュリティを重視している企業でも、SaaS間の連携までは十分に統制できていないことがある」という現実を突きつけています。

本稿では、Klue事件で何が起きたのかを整理したうえで、なぜこの事案が重要なのか、そして企業が実務で何を学ぶべきかを考えます。

事件の概要

Klueは市場・競合インテリジェンスのためのプラットフォームで、営業部門や事業部門が使うSaaSとして知られています。2026年6月11日から12日にかけて、攻撃者はKlueのバックエンドサーバーに不正アクセスし、不正なコード更新を通じて顧客のOAuthトークンを収集しました。

調査資料によると、侵入の起点は「放棄されたプロトタイプ統合用のレガシー認証情報」でした。つまり、すでに使われていないはずの認証情報が無効化されずに残っており、そこが突破口になったわけです。侵入後、攻撃者はKlueと接続していた顧客環境のトークンを悪用し、Salesforce REST API経由でCRMデータを大量に引き出しました。24時間にわたるデータ抽出が確認され、15分間で約1000件のクエリが集中した時間帯もあったとされています。

被害組織は15社以上が公表され、影響はSalesforceだけでなく、HubSpot、SharePoint、Zoom、Gong、Chorus、Clari、Google Drive、Slackなど複数の統合先に及ぶ可能性が認識されました。Klueはその後、全統合を無効化し、認証情報とトークンの失効、不正コードの削除、外部調査会社や法執行機関との連携を進めました。6月17日にはSalesforceがKlue Battlecardsアプリ統合を無効化しています。

攻撃の構図

この事件を理解するうえで重要なのは、「Klueそのもののデータ侵害」に話を矮小化しないことです。より正確には、Klueを経由して顧客企業のSaaS環境にある価値の高いデータへ到達した、SaaS-to-SaaS型のサプライチェーン攻撃でした。

攻撃の流れは比較的明快です。まず、管理されずに残っていた認証情報が悪用され、Klueのバックエンドに侵入されます。次に、不正なコード更新によって顧客のOAuthトークンが収集されます。最後に、そのトークンを使って正規APIにアクセスし、Salesforce上の営業関連データが抽出されました。

ここで厄介なのは、攻撃者がマルウェアで端末を直接破壊したのではなく、「正規の統合」「正規のAPI」「正規の認証済みセッション」に見える形で行動したことです。ReliaQuestの分析では、APIレイヤーの詳細ログがなければ、通常の統合トラフィックと見分けるのが難しいとされています。つまり、従来型のエンドポイント防御や境界防御だけでは捉えにくい攻撃だったのです。

さらに、この事件では新たな恐喝グループ「Icarus」が関与を主張し、Tor上のリークサイトでデータ公開を予告し、実際に一部公開に至りました。侵入、情報窃取、恐喝、対策までが6月中に一連の流れとして展開したことも、この事件の注目度を高めました。

なぜ重要なのか

Klue事件が重要なのは、被害組織の数や知名度だけではありません。企業の業務がSaaS連携に深く依存する現在、その信頼関係そのものが攻撃面になっていることを分かりやすく示したからです。

第一に、狙われたのがCRMデータだった点は見逃せません。漏えいしたのは主に取引先名、メールアドレス、電話番号、役職、ビジネス住所、価格見積や契約情報などの営業関連データで、パスワードや決済情報、脅威データ、製品コードへの影響は確認されていません。しかし、だから軽微とは言えません。営業情報は、標的型フィッシング、なりすまし、競争情報の把握、追加恐喝の材料として高い価値を持ちます。ビジネスの現場では、こうした情報の流出は信用失墜や商談への悪影響に直結します。

第二に、この攻撃は特殊な一回限りの手口ではなく、OAuth悪用という再現可能なプレイブックの一例として位置づけられている点です。調査資料でも、2025年のSalesloft DriftやGainsight侵害と似たパターンが指摘されています。つまり、SaaS連携におけるトークン管理の甘さが、今後も繰り返し突かれる可能性が高いということです。

第三に、セキュリティ企業自身が被害を受けたことには象徴的な意味があります。セキュリティ成熟度が比較的高いと見られる企業ですら、外部SaaS統合に起因するリスクを完全には封じ込められなかった。この事実は、多くの一般企業にとって「自社も例外ではない」という強い警鐘になります。

実務上の教訓

この事件から企業が学ぶべきことは明確です。

1. 使わなくなった認証情報を放置しない

今回の起点は、放棄されたレガシー認証情報でした。システムや統合は廃止しても、鍵やトークン、サービスアカウントだけが残り続けることは珍しくありません。棚卸しと無効化を定期運用に組み込み、「使っていない資格情報は存在してはならない」という原則を徹底する必要があります。

2. OAuthトークンを“接続設定”ではなく“高権限資産”として扱う

SaaS連携では、APIキーやOAuthトークンが単なる技術設定として軽く扱われがちです。しかし実際には、それらは顧客データへの入口です。発行範囲の最小化、利用先の明確化、短い有効期限、失効手順の整備、異常利用時の即時停止といったライフサイクル管理が求められます。

3. SaaS統合先をベンダー評価の対象に含める

自社が直接導入しているSaaSだけでなく、そのSaaSがさらに何と接続しているかまで視野に入れなければなりません。第三者リスク管理では、データの保存場所や暗号化だけでなく、統合構成、認証方式、インシデント時のトークン失効能力、ログ提供の可否などを確認すべきです。

4. APIログ監視を前提にする

正規APIを使う攻撃は、見た目が通常業務に近いため見逃されやすいものです。大量クエリ、短時間のバースト、不自然な時間帯の利用、通常と異なるクライアントや地域からのアクセスなど、API利用のふるまい監視を整える必要があります。

5. 「侵害される前提」で切り離し手順を準備する

今回、KlueやSalesforceが統合無効化やトークン失効を進めたことは被害抑制に重要でした。企業側も、どの統合を止めれば影響を閉じ込められるのか、誰が判断し、どの順番で遮断するのかを事前に決めておくべきです。SaaS時代のインシデント対応では、ネットワーク遮断だけでなく「連携遮断」が重要になります。

まとめ

Klueサプライチェーン攻撃は、2026年6月を代表するセキュリティトピックの一つでした。理由は明快です。侵入から影響拡大、恐喝、対策までが短期間に展開し、しかも被害が複数の有力企業に及んだからです。

ただ、この事件の本当の重みは、ニュースとしての派手さではありません。SaaS連携が当たり前になった企業環境では、信頼して接続しているサービスそのものが攻撃経路になりうる、という現実を具体的に示した点にあります。とりわけOAuthトークン、レガシー認証情報、API監視、第三者リスク管理は、もはや周辺論点ではありません。

Klue事件を他社の失敗談として眺めるだけでは不十分です。自社のSaaS統合を洗い出し、不要な認証情報を止め、どのデータにどの権限で触れられるのかを見直す。その地道な作業こそが、次の同種事件への最善の備えになります。

参考情報

• SecurityWeek: Cybersecurity Firms Impacted by Klue Supply Chain Attack

• SecurityWeek: More Cybersecurity Firms Disclose Impact From Klue Hack

• SecurityWeek: BeyondTrust, LastPass Impacted by Klue-Salesforce Incident

• Dark Reading: Scope of Salesforce Attacks Expands as Icarus Leaks Data

• CSOonline: Klue breach exposed Salesforce CRM data through stolen OAuth tokens