SaaSサプライチェーンが2026年最大の侵入経路に——サードパーティ接続のリスク管理

企業が利用するSaaSアプリの平均数は130以上、そしてその相互接続のうち約45%が適切な監視下にない——これが2026年のエンタープライズSaaSセキュリティの現実だ。カナダの通信大手TELUSがDriftの認証情報を起点に1PBのデータを窃取され、Salesforceの開発者ツール「AuraInspector」が攻撃者のスキャニングに悪用される事例が相次いでいる。従来のネットワーク境界やエンドポイントではなく、SaaS-to-SaaSの接続そのものが2026年最大の攻撃ベクトルとなりつつある。

本記事では、なぜSaaSサプライチェーンがこれほど危険になったのか、具体的な攻撃手法、そして日本企業が今すぐ取るべき対策を解説する。

SaaSサプライチェーン攻撃とは何か

SaaSサプライチェーン攻撃とは、企業が直接利用しているSaaSアプリケーションではなく、そのSaaSが接続しているサードパーティのSaaSを経由して侵入する攻撃手法だ。現代の企業環境では、CRMがマーケティングツールと連携し、マーケティングツールがデータ分析基盤と連携し、データ分析基盤がストレージと連携する——という具合に、SaaS同士が複雑に相互接続している。

この「SaaS-to-SaaS接続」は、OAuthトークンやAPIキーを介して実現されている。問題は、いったんサードパーティSaaSが侵害されると、そこに保存されている認証情報やトークンを通じて、接続先のすべてのSaaS環境にアクセスできてしまう可能性があることだ。

従来のサプライチェーン攻撃（SolarWindsやlog4j）がソフトウェアの依存関係を悪用したのに対し、SaaSサプライチェーン攻撃はサービス間の信頼関係そのものを悪用する。ソフトウェアの脆弱性を突く必要はなく、正規の認証情報で正規のAPIを叩くだけで済むため、従来型のセキュリティ対策では検知が極めて困難だ。

2026年に急増している攻撃パターン

OAuthトークンの悪用

最も深刻な攻撃ベクトルの一つがOAuthトークンの悪用だ。多くのSaaS間連携はOAuth 2.0を使って認可を行っているが、攻撃者はこのトークンを以下の手法で入手・悪用している。

• サードパーティSaaS侵害: 連携先のSaaSが侵害されると、そこに保存されているOAuthトークンが窃取される
• 過剰な権限スコープ: 「とりあえずフルアクセス」で設定されたOAuth連携が、攻撃者に必要以上の権限を与える
• トークンの無期限設定: リフレッシュトークンが無期限で有効なケースが多く、一度窃取されると長期間悪用される
• 同意フィッシング: 正規に見せかけた悪意あるOAuthアプリに従業員がアクセス許可を付与してしまう

TELUS侵害に見るDrift認証情報の悪用

2026年3月のTELUS Digital侵害事件は、SaaSサプライチェーン攻撃の典型例だ。攻撃グループ「ShinyHunters」は、TELUSが利用していたカスタマーエンゲージメントプラットフォーム「Drift」のデータからGCP（Google Cloud Platform）のサービスアカウント認証情報を発見した。

Driftのチャットボット設定ファイルや連携スクリプトにハードコードされていた認証情報が、攻撃の起点となった。ここから、BigQuery → trufflehogによる追加認証情報の探索 → ラテラルムーブメントという流れで、最終的に約1PBのデータが窃取された。この事件が示しているのは、SaaSの連携設定に埋め込まれた認証情報が、企業全体のセキュリティを崩壊させうるという事実だ。

Salesforce AuraInspectorの悪用

Salesforceの開発者向けブラウザ拡張機能「AuraInspector」が、攻撃者の偵察ツールとして悪用されるケースも増加している。AuraInspectorはSalesforceのLightningコンポーネントをデバッグするためのツールだが、これを使うことで以下の情報を取得できる。

• Salesforce組織のAPIエンドポイント構造
• カスタムオブジェクトとフィールドの一覧
• アクセス制御の設定状態
• 接続されているサードパーティアプリの情報

攻撃者はこの情報をもとに、Salesforce環境に対する標的型攻撃を計画する。特に危険なのは、AuraInspectorの利用自体は正規のデバッグ行為と区別がつかないため、アラートが発生しにくい点だ。

APIキーの漏洩

GitHub、GitLab、Bitbucketなどのコードリポジトリに誤ってコミットされたAPIキーも、依然として主要な侵入経路だ。2025年の調査では、GitHub上の公開リポジトリだけで約1,200万件のシークレット（APIキー、トークン、認証情報）が検出されている。SaaS間連携に使われるAPIキーが漏洩すると、攻撃者はそのまま連携先のSaaS環境にアクセスできてしまう。

この図は、サードパーティSaaS侵害を起点とした攻撃フローと、SaaS-to-SaaS接続における典型的なリスクポイントの全体像を示しています。

シャドーSaaSの増殖

IT部門の承認を得ずに従業員が独自に導入する「シャドーSaaS」も深刻な問題だ。調査によると、企業が認識しているSaaSアプリの数は平均130程度だが、実際に使用されているSaaSはその2〜3倍にのぼるとされる。シャドーSaaSは以下の点で特にリスクが高い。

• セキュリティレビューを経ていないため、脆弱な設定のまま放置される
• OAuthでコアSaaS（Google Workspace、Microsoft 365など）と接続されていることが多い
• IT部門が存在を把握していないため、インシデント発生時の検知・対応が遅れる
• 従業員が退職しても連携が解除されず、「孤児アカウント」化する

SaaS攻撃とネットワーク攻撃の比較

項目	従来のネットワーク攻撃	SaaSサプライチェーン攻撃
侵入経路	ファイアウォール突破、VPN脆弱性	OAuthトークン、APIキー
検知難易度	IDS/IPSで検知可能	正規APIアクセスと区別困難
攻撃範囲	ネットワーク内のシステム	接続されたすべてのSaaS
横展開速度	手動のラテラルムーブメント	トークンで即座にアクセス
従来対策の有効性	ファイアウォール、EDR	対策が不十分なことが多い
復旧の複雑さ	パッチ適用、隔離	全トークン・全APIキーの無効化
影響範囲の特定	ネットワークログで追跡可能	SaaS間のログが分散し追跡困難

SSPM（SaaSセキュリティ態勢管理）とは

こうしたSaaSサプライチェーンリスクに対応するために急成長しているのが、SSPM（SaaS Security Posture Management） というカテゴリの製品だ。SSPMは以下の機能を提供する。

主要機能

1. SaaSインベントリの自動検出: 企業が利用しているすべてのSaaS（シャドーSaaS含む）を自動的に検出・一覧化
2. 設定監査: 各SaaSのセキュリティ設定（MFA強制、データ共有設定、権限設定など）をベストプラクティスと照合
3. OAuth権限の可視化: SaaS間のOAuth接続とその権限スコープを一覧表示し、過剰な権限を検出
4. 設定ドリフトの検知: セキュリティ設定が変更された場合にリアルタイムでアラート
5. コンプライアンス対応: SOC 2、ISO 27001、GDPRなどへの準拠状況を継続的に評価

主要SSPMベンダー比較

ベンダー	特徴	対応SaaS数	価格帯
AppOmni	包括的なSaaS可視化、M365/Salesforce特化	150+	$15〜/ユーザー/月
Obsidian Security	脅威検知に強い、UEBA統合	100+	要問合せ
Adaptive Shield	設定監査と自動修復、API連携豊富	130+	$12〜/ユーザー/月
Nudge Security	シャドーSaaS検出に特化、エージェントレス	200+	$4〜/ユーザー/月
Valence Security	ワークフロー自動化、リスク優先順位付け	120+	要問合せ

SSPM市場は2026年時点で推定$3.7B（約5,550億円）規模に成長しており、年間成長率（CAGR）約35%で拡大を続けている。

この図は、SaaSセキュリティ対策の成熟度を4段階で示すとともに、SSPM市場の急成長を棒グラフで可視化しています。

日本企業への影響と課題

日本企業にとって、SaaSサプライチェーンリスクは海外以上に深刻な課題を含んでいる。

DX推進によるSaaS導入の急拡大

日本企業のDX推進に伴い、SaaS導入数は急増している。しかし、導入スピードにセキュリティ管理が追いついていないケースが多い。特に以下の点が問題だ。

• 事業部門主導のSaaS導入: 情シス部門を経由せずにSaaSが導入され、OAuth連携が設定される
• ベンダー評価の不足: 海外SaaSのセキュリティ態勢を適切に評価する体制・知見が不足
• 契約書の見落とし: SaaS間のデータ共有に関する責任範囲が契約で明確化されていない

日本特有の課題

• 言語の壁: SSPMツールの多くは英語UIのみで、日本語対応が遅れている
• セキュリティ人材不足: SaaS特有の脅威に対応できるセキュリティ人材が圧倒的に不足
• 「境界防御」思想の根強さ: ネットワーク境界を守れば安全という従来の発想が残り、SaaS間連携のリスクが見落とされがち
• 改正個人情報保護法との関連: 2024年改正で漏洩報告義務が厳格化されたが、SaaSサプライチェーン経由の漏洩では責任範囲の特定が困難

日本市場の動向

国内でもSSPM関連の動きは出始めている。NTTデータやラックなどのセキュリティベンダーがSSPM関連サービスの提供を開始しており、2026年後半にはさらに選択肢が増える見込みだ。ただし、海外に比べると導入率は1〜2年の遅れがある。

今すぐ取るべき防御策

1. 認証情報の棚卸しと管理強化

まず最優先で取り組むべきは、SaaS間連携に使われている認証情報の棚卸しだ。

• すべてのOAuth連携とそのスコープ（権限範囲）を一覧化する
• 不要になった連携を即座に解除する
• APIキーのローテーションスケジュールを設定する（最低90日ごと）
• 1Passwordなどのパスワードマネージャーでサービスアカウント認証情報を一元管理し、ハードコードを排除する

2. シャドーSaaSの検出と統制

IT部門が把握していないSaaSを検出するために、以下のアプローチを取る。

• ネットワークトラフィック分析でSaaSへの接続を検出
• OAuth同意ログを監査し、未承認のアプリ連携を特定
• 従業員向けの「SaaS利用申請フロー」を整備する
• 定期的なSaaS利用状況のアンケート調査を実施

3. SSPM導入の検討

企業規模やSaaS利用状況に応じて、SSPMツールの導入を検討する。まずは無料トライアルやPoCから始めて、自社環境でのリスク可視化効果を確認するのが良い。

4. インシデント対応計画の更新

SaaSサプライチェーンインシデントに特化した対応計画を策定する。

• サードパーティSaaS侵害時のトークン無効化手順
• 影響を受けるSaaS環境の特定方法
• データ流出範囲の調査手法
• 関係各所への報告フローと法的対応

5. ベンダーリスク管理の強化

SaaSベンダーのセキュリティ態勢を継続的に評価する仕組みを構築する。

• SOC 2 Type IIレポートの定期的な確認
• セキュリティインシデント通知のSLAを契約に明記
• ベンダーのサードパーティ接続ポリシーの確認
• サプライチェーンリスクスコアリングの導入

まとめ

SaaSサプライチェーン攻撃は、2026年のサイバーセキュリティにおいて最も警戒すべき脅威の一つだ。TELUS Digital事件のように、サードパーティSaaSの認証情報一つから企業全体のデータが流出するリスクは、もはや理論上の話ではなく現実の脅威となっている。

日本企業が今すぐ取るべきアクションステップは以下の通りだ。

1. 今週中に: 自社のSaaS間OAuth連携の一覧を作成し、不要な連携を解除する。1Passwordなどで認証情報の一元管理を開始する
2. 今月中に: シャドーSaaSの検出を実施し、未承認のSaaS利用を把握する。SSPM製品の無料トライアルを2〜3社で試す
3. 今四半期中に: SSPM導入の意思決定を行い、SaaSサプライチェーンインシデント対応計画を策定する。ベンダーリスク管理のフレームワークを構築する

SaaSの利便性を享受しつつセキュリティを確保するには、「SaaS間の接続そのものがリスク」という認識を組織全体で共有することが第一歩だ。境界防御からゼロトラスト、そしてSaaSサプライチェーン管理へ——セキュリティの重心は確実に移行している。