ほとんどの組織は、従業員が未承認のAIツールを採用することを当然のことながら懸念しています。ユーザーが機密データをChatGPT、Claude、またはその他の多くのチャットボットにアップロードする形のLLMを使用するシャドウAIの使用は、正当な懸念です。しかし、それが最大の問題ではありません。
従業員がAIアプリをGoogle Workspace、Microsoft 365、Salesforce、またはその他のコアプラットフォームに接続すると、環境とサードパーティ間に永続的でプログラマティックなブリッジを作成することになります。
従業員がアプリの使用を停止しても、そのブリッジは消えません。また、そのサードパーティが侵害された場合、ブリッジはシステムへの直接的な経路になります。
私たちはこのシナリオをVercelの侵害で実際に見かけました。Context.aiのAIアプリはVercelの従業員によってトライアルされ、その従業員はそれに対してGoogle Workspaceアカウントへのアクセス（OAuthを経由）を付与していました。Context.aiが侵害されたとき、Vercelはその余波に巻き込まれました。
AIの急速な採用はシャドウSaaSの増幅要因である
シャドウITは新しい問題ではありません。ほとんどの組織はSaaS上で大規模に（またはほぼ完全に）実行され、ブラウザでアクセスされ、企業あたり数百のアプリを使用しています。管理されない自己採用アプリは、セキュリティチームにとって長い間厄介な問題になっています。しかし、AIの急速な採用はこれを増幅させる要因です。
AIアプリの文脈で認識する必要があるシャドウITの異なるタイプがあります：
-
シャドウアプリ：従業員がサインアップして、ビジネス承認なしでビジネス目的で使用しているアプリ。これには、企業アカウントまたは個人アカウントでサインアップしたアプリが含まれます。
-
シャドウテナント：従業員が個人アカウントでアクセスしているアプリで、本質的に組織の管理外でシャドウテナントを作成しています。アプリ自体が承認されている場合でも同様です。
-
シャドウ拡張機能：多くのAIアプリには拡張機能が付属しており、信頼できない、または明らかに悪意のある第三者拡張機能が数多くあります。ブラウザ拡張機能は、アプリケーション外のブラウザアクティビティへの可視性を提示することで、方程式に別の角度を追加します。
-
シャドウ統合：既知または承認されていないアプリ間のOAuth接続。アプリ自体が承認されている場合でも、そのアプリをプライマリエンタープライズアプリに直接プラグインすることは、それに含まれるすべての機密データと機能を備えていることもあり、必ずしも承認されていません。
Vercelのケースでは、私たちは具体的にはシャドウ統合について話しています。しかし、これらのすべては組織に主要なリスクをもたらします。
Vercelの侵害：OAuthグラント失敗の教科書的な例
Vercelの侵害は、シャドウAI統合の影響を明確に示しています。
Vercelの従業員がAIアプリ（具体的にはContext.aiの廃止された消費者向けの「AI Office Suite」製品）をGoogle Workspaceテナントに接続していました。VercelはContext.aiの登録顧客ではありませんでした。
これはおそらく統合された自動サービストライアルで、軽く使用され、忘れられていました。組織の攻撃面に見えないノードを追加しています。
Context.aiアプリを採用することで、Vercel従業員はサードパーティの従業員とシステムをセキュリティの依存関係として追加しました。
Context.aiがその後侵害されたとき（推奨される原因はRobloxのチートを検索している従業員からのインフォスティーラー感染の結果です。本当です）、攻撃者はContext.ai環境に保存されているOAuthトークンを利用して、下流の顧客アカウントにピボットすることができました。
これには、Vercel従業員のGoogle Workspaceが含まれていました。これは、内部ダッシュボード、従業員レコード、APIキー、NPMトークン、およびGitHubトークンへのアクセス権を持つ、十分な権限を持つアカウントでした。
Vercelは異例ではありません：攻撃者は大規模にOAuthを標的にしています
広範なOAuthの相互接続は、AIアプリの問題だけではありません。攻撃者はしばらくの間これを悪用してきており、ペースは加速しています：
-
2025年に、Scattered Lapsus$ HuntersはSalesloft（具体的にはSalesloft Driftプラットフォーム）とGainsightを侵害した後、SalesforceおよびGoogle Workspaceテナントに対するOAuth主導の供給チェーン攻撃を開始しました。Google、Cloudflare、Rubrik、Elastic、Proofpoint、JFrog、Zscaler、Tenable、Palo Alto Networks、CyberArk、BeyondTrust、Qualysおよびその他多くを含む1000以上の組織が影響を受け、15億以上のレコードが盗まれました。
-
Snowflakeの顧客はデータ異常検出企業Anodotでの侵害後に影響を受けました。攻撃者は盗まれた認証トークンを利用してSalesforceデータにアクセスしようと試みました。Rockstar Gamesは著名な犠牲者でした。
攻撃者は供給チェーン攻撃の一部として既存のOAuth接続を悪用しているだけではありません。攻撃者は被害者環境への入口としてOAuth重視のフィッシングを使用しています。昨年のSalesforceキャンペーンはデバイスコードフィッシングで始まりました。攻撃者は被害者をだまして、攻撃者が管理するアプリをSalesforceテナントに登録させ、大量のデータ流出のための完全なAPIアクセスを付与しました。
それ以来、今年はデバイスコードフィッシング攻撃が37倍増加し、十数以上の犯罪PhaaS キットが流通しています。
パターンは明確です：OAuth統合はエンタープライズ環境で最も信頼性の高い悪用される攻撃面の1つになりつつあり、従業員が接続するすべての新しいAIツールは網をさらに広くします。
OAuth蔓延の網はGoogleとMicrosoftをはるかに超えて広がっています
Vercelの侵害は例示的ですが、問題の表面をかすめるだけです。
メインのエンタープライズクラウド環境（M365またはGoogle Workspaceを考えてください）でOAuthを制御することは相当に簡単です。両方のプラットフォームは管理者にOAuth接続を監査および制御する機能を与えます。Vercelの侵害は、従業員が管理者の承認なしに新しいOAuth統合を追加することをブロックされていた場合に回避できたでしょう。Google管理パネルのトグルです。または、統合が日常的な監査でフラグされて削除されていた場合。
しかし、すべてのSaaSアプリでこれを行うことはかなり難しくなります。包括的で最新のインベントリが必要なだけでなく、すべてのアプリのアプリ管理者である必要があり（自己採用アプリの場合は常にそうとは限りません）、特定のアプリはテナント内のユーザーに代わってOAuthグラントを制限および削除する制御を与える必要があります。
典型的なAIアプリがどのように動作するかを考えてください。ワークフローを効果的に自動化したい場合、あるアプリからデータを引き出し、別のアプリで集約・分析し、その情報をレポート、ダッシュボード、またはプレゼンテーションで提示し、その後配布します。これは1つのワークフローで相当な統合です。MCP接続は、他のSaaSアプリと同じ方法でこの相互接続性を達成するためにOAuthを使用します。
私たちは攻撃者にとって金鉱となるZapierのような自動化アプリについて話していました。さて、AIアプリは、より相互接続され、より頻繁に使用され、攻撃者がそれらを悪用する方法の面でより柔軟になりつつあります。
セキュリティチームが今すべきこと
OAuth同意をロックダウンします。プライマリエンタープライズアプリで新しい統合への同意を許可するためにデフォルト拒否アプローチを採用します。これは最近ブラウザ拡張機能管理についてアドバイスしたのと同じ原則です。ユーザーは承認なしに新しい信頼関係を導入することはできません。
既に接続されているものを監査します。環境に既に存在するOAuth統合を定期的に監査して、それらが依然として確実に必要であることを確認します。各統合は攻撃面を拡張し、攻撃者に広範なアクセス権を付与する可能性があります。
GoogleとMicrosoftを超えて考えてください。プライマリエンタープライズクラウドでOAuthを制御することは必要ですが、十分ではありません。SaaS間の接続の可視性は低く、制御が少ないことが多いです。すべてのアプリで発生するOAuthグラントを可視化する必要があります。
AI採用が蔓延に大きく貢献しているとしても、これは単にシャドウAIの問題ではないことを忘れないでください。
Push Securityがどのように支援できるか
確認したように、このパズルにはかなり多くの部分があります。Push Securityはすべての部分で支援することができます。
Pushはブラウザで従業員が行うすべてのアプリログインを観察し、組織全体のSaaSとAI使用の包括的な画像を作成します。これにはログイン方法とログインのセキュリティの程度が含まれます。MFAがあったか、どの種類のMFA、弱い或いは侵害されたパスワード、SSOを使用していたかなど。
Pushはまた環境内のOAuth統合を追跡し、それらを管理および削除する機能を提供し、組織全体のアプリ使用を表示、管理、保護するための単一のプラットフォームを提供します。
これにより、脆弱性と可能な制御ギャップの両方を明らかにし、それらについて何かを行うことが容易になります。
しかし、Pushが本当に優れているのは、プライマリエンタープライズアプリの外であってもOAuth接続リクエストを観察およびブロックする能力です。Pushを使用すると、ブラウザを通過するときにOAuth統合リクエストを検出およびブロックできます。
このアプリに依存しない制御レベルは、OAuth統合蔓延を停止するために絶対に重要です。
Pushのブラウザベースのセキュリティプラットフォームはまた、AiTMフィッシング、認証情報スタッフィング、悪意のあるブラウザ拡張機能、デバイスコードフィッシング、ClickFix、セッションハイジャックなどのブラウザベースの攻撃を検出およびブロックします。最も顕著なインフォスティーラー配信ベクトル（Context.aiの侵害のソース）を含めています。
PushはすべてのブラウザセッションとタブのすべてのWebページを脅威について分析し、遅延なくリアルタイムで分析します。
PushでシャドウAIを保護する方法について詳しく学び、ライブデモのためにチームと時間を予約してください。
