株式会社インターナショナルシステムリサーチ
本記事のまとめ
「セキュア・バイ・デフォルト」を欠いた初期設定の課題：サードパーティ連携を無条件に許可するような運用状態にあるクラウドサービスでは、セキュリティ判断やチェックが現場のユーザー任せになってしまいます。ユーザーを過失やミスから守る「セキュア・バイ・デフォルト」になっていないこのシステム設計の構造こそが、今回の組織全体のインフラを危険に晒す最大の決定打となりました。
「未承認AIツール」の急増と無自覚な1クリック：業務でのAI利用の急拡大に伴い、会社が許可していないAIツールへの自社リソースの連携が爆発的に増加しています。今回のインシデントも、従業員が1クリックで強力なデータアクセス権限（OAuth）を会社が許可していないAIツールに渡してしまったことが直接のきっかけとなりました。
個人任せの運用から、システムによる保護へのシフト：従業員の注意義務やリテラシーだけに依存する運用には限界があります。システム側で会社が許可していないツールは連携をあらかじめ制限し、ユーザーをリスクから根本的に保護する設計（セキュア・バイ・デフォルト）へのシフトが不可欠です。
ゼロトラスト時代に必要な「多層防御」：今回のケースが示すように、一度発行されたOAuthトークンの悪用（裏口）をログイン認証だけで防ぐことは困難です。だからこそ、システム側で「裏口のガバナンス」を固めることと同時に、あらゆる侵入経路に備えて「正面玄関の認証（CloudGate UNO）」も強固にしておくという、組織全体での多層的な防御アプローチが求められます。
はじめに：「シャドーAI」の普及が浮き彫りにした「認可（OAuth）」の盲点
生成AIをはじめとする便利なツールの急速な普及に伴い、現場主導で新しいAIサービスを業務に導入する動きが日常化しています。この「シャドーAI（未承認AIツールの利用）」の拡大において、警戒すべきはAIの技術そのものだけではありません。
本質的な脅威は、AIツールを利用する際に発生する「無自覚な1クリックによるOAuthトークンの発行」にあります。
「IDやパスワードを教えていないから大丈夫」という誤認のもと、従業員が1クリックで社内データへの強力なアクセス権限（OAuthトークン）を未承認ツールに与えてしまうリスクが存在します。便利さゆえに利用が爆発的に増えたことで、これまで隠れていた「ユーザーの判断だけで社外へアクセス権限（OAuth）を与えられてしまうガバナンスの甘さ」が一気に表面化しました。
シャドーAIはあくまで被害を拡大させる「きっかけ」に過ぎず、問題の核心はツールを問わず発生する「ガバナンス設計の脆さ」に存在します。
Vercel社のインシデントの解剖：なぜ「正面玄関」ではなく「裏口」から侵入されたのか
この事件において、攻撃者は被害企業のパスワードを一つも盗み出していません。彼らが利用したのは、企業が外部ツールに対して与えていた「信頼」そのものでした。
Vercelインシデント：OAuth悪用による侵入の4工程
踏み台（未承認ツールのベンダー侵害）
窃取（OAuthトークンの平文窃取）
侵入（無自覚な「すべて許可」）
被害（内部探索と身代金要求）
攻撃の全容と時系列フェーズ
- 起点は「踏み台」のベンダー侵害： Vercelの従業員が使っていた未承認の外部AIツール（Context.ai）の社員PCがゲームエクスプロイト（チートツール）をダウンロードしたことで、情報窃取型マルウェアLumma Stealerに感染しました。
- 暗号化されていないOAuthトークン： 攻撃者は窃取した認証情報でContext.aiのAWS環境へ侵入しました。そこには、Vercel従業員が連携させたGoogle WorkspaceのOAuthトークンが平文（非暗号化）で保管されていました。
- 無自覚な「すべて許可」： Vercel従業員は、Context.aiへ強力な権限を与えていました。攻撃者はこの「VIPパス（OAuthトークン）」を手に、正規の方法でユーザーになりすましVercel内部へ侵入していました。
- 内部探索と身代金の要求： 侵入後、攻撃者はVercel内のVercel利用者の環境変数を列挙しました。最終的に数千社分のAPIキーやデータベース情報を窃取し、身代金を要求する事態に至りました。
これは「信頼のまた貸し」と言える現象です。自社のセキュリティがどれほど完璧でも、一人の従業員が勝手に連携した外部ツールの管理がずさんであれば、そこが「裏口」となって侵入を許してしまいます。
「初期設定」の落とし穴：Google Workspaceと環境変数に潜む危険性
今回の問題は、従業員の不注意だけでなく、システムの「デフォルト設定」がセキュリティを考慮していなかった点にもあります。
| 区分 | Context.ai (踏み台) | Vercel (標的)※ | Vercel利用者 |
|---|---|---|---|
| 人のミス | 従業員が不正ツールをDLし、PCがマルウェア感染 | 未承認シャドーAIへの「全権限 (Allow All)」付与 | 環境変数の機密設定を有効にし忘れる |
| システム設計の欠陥 | OAuthトークンを暗号化せずにAWSに平文保管 | 手動で設定しない限り、環境変数が暗号化されない仕様だった | N/A |
| 根本原因 | 従業員モラルの欠如とデータ保護意識の低さ | シャドーAI放置とセキュア・バイ・デフォルト設計の欠落 | プラットフォーム仕様の非理解と盲目的な利用 |
※補足（本インシデントの経緯）： 今回のインシデントでは、攻撃者がマルウェア（Lumma Stealer）を用いてContext.aiの従業員端末を感染させたことが発端です。攻撃者が奪取した情報の中から、偶然にもVercelへの広範なアクセス権限を持つOAuthトークンを発見したことで、Vercel環境への侵入・攻撃へと発展しました。
Google Workspaceなどのシステムでは、初期設定のままだと「従業員が個人の判断で外部アプリとの連携を承認でき、要求された強力な権限（すべてのデータへのアクセスの許可など）をそのまま与えてしまう状態」になっているため、OAuthトークンに強力な権限を与えてしまいます。
加えて今回のケースで深刻だったのは、Vercel側の仕様として「手動で『機密（Sensitive）』と設定しない限り、環境変数が暗号化されない仕様」だった点です。「初期状態が安全（セキュア・バイ・デフォルト）」になっていなかったことが、被害を大きく広げる原因となりました。
OAuthトークンにおける防衛の限界とガバナンス整備
今回の事件から見えてくるのは、一度発行されてしまった「OAuthトークン」の悪用に対しては、ログイン画面や認証基盤のチェックだけで直接防ぐことが構造上難しいという事実です。
トークンが攻撃者の手に渡ってしまえば、パスワードや多要素認証（MFA）を介さずに正規権限として侵入されてしまうためです。
そのため、まずはアイデンティティ基盤（主要グループウェア等）側の管理設定そのものを見直し、未承認アプリへのアクセス許可を初期状態で遮断（管理者による事前承認制）に設定する必要があります。「ユーザーの判断で無造作にOAuthトークンを発行させないガバナンス」をシステム側で確立することが、対策の第一歩となります。
ゼロトラストの原則に基づく、「多層防衛」と「正面玄関の強化」
ゼロトラストの原則においては、OAuthトークンの発行を制限するガバナンスだけでセキュリティ対策が完結するわけではありません。単一の対策に依存するアプローチは、別の侵入経路に対して脆弱性を残すことになるからです。
仮にシステム設定によって裏口（OAuth）を適切に塞いだとしても、日常的にアクセスを行う「正面玄関（ログイン画面）」の鍵がIDとパスワードのみのような脆弱な状態であれば、フィッシング詐欺やマルウェアによってアカウント自体が容易に突破されてしまいます。
だからこそ、「OAuthトークンのガバナンス整備」と「正面玄関の強固な認証」を双方で揃える「多層防御」が不可欠となります。
当社が提供するクラウド認証サービス「CloudGate UNO」は、この認証の起点となる「正面玄関」を最先端の基準で強固に保護します。
1. パスキー（FIDO2）による「パスワードを使わない認証」
パスワードを使用しない認証（パスキー）に移行することで、パスワード窃取やフィッシングによるリスクを大幅に低減します。
2. デバイス証明書とアクセス制限
会社が許可した安全な端末（証明書がインストールされた端末）からしかログインを許可しないため、たとえ認証情報が漏洩しても、社外の怪しいデバイスからのアクセスを水際でブロックします。
便利さの裏に潜むリスクを直視し、この機会に自社のセキュリティの全体像を見直してみてはいかがでしょうか。
CloudGate UNOの機能詳細を詳しく知る
