川口氏が注目する最近のインシデント事例からは、セオリー通りにいかない現場の隙が攻撃者に狙われている実態が浮かび上がる。

　1つ目の事例は、2025年10月にアスクルで発生したランサムウェア被害だ。同社は物流システムを使った出荷再開までに約1.5カ月を要し 、システム障害対応費用として52億1600万円の特別損失を計上するなど 、甚大な被害を受けた。

　このインシデントの原因の一つとされているのが、委託先向けの管理者アカウントにおいて、多要素認証（MFA）が未適用だったことだ。川口氏は「アスクルほどの規模の組織であれば、MFAの適用は当たり前のように管理されていたはずだ。しかし、急に作成したアカウントであったり、システム移行の都合であったりといった背景で、例外が生じていたのではないか」と推測する。

　このような委託先や管理者、緊急用IDといった「例外アカウント」の運用不備が攻撃者に狙われる。対策としては、MFAを導入済みかどうかではなく、「例外が残っていないかどうか」を棚卸しすることが極めて重要だ。

Vercelの事例：信頼したOAuthアプリケーションからの侵害

　2つ目の事例は、Webアプリケーションの構築・ホスティングサービスを提供するVercelの従業員アカウントが侵害され、顧客の情報にまで影響が及んだ事件だ。この事件の起点となったのは、同社の従業員が業務で利用していたサードパーティーのAIサービス「Context.ai」だった。

　川口氏によれば、まずContext.aiを提供するContextの従業員の端末がマルウェアに感染した。これを起点として、Vercelの従業員の「Google Workspace」アカウントが乗っ取られ 、そこからVercelの社内システムへと横展開されて、最終的に、機密値として保護されていなかった環境変数にアクセスされるという流れだ。

　「さまざまな便利なAIサービスが登場する中で、業務効率化のためにそれらを導入しない選択肢はない」と川口氏は述べる一方で、「SaaS（Software as a Service）連携の時代においては、信頼して連携に同意したOAuthアプリケーションが新たな侵入経路になる」と警鐘を鳴らす。OAuthとは、パスワードを直接渡すことなく、あるサービス（今回の例ではGoogle Workspace）のデータへのアクセス権を別のサービス（同Context.ai）に認可する仕組みのことだ。攻撃者はパスワードだけではなく、同意済みのアプリケーションやOAuth権限を狙ってくるため 、自組織のシステム構成でどのような連携が許可されているのかを可視化し、ルールを定める必要がある。

CI/CDパイプラインにおける自動化の盲点

　3つ目は、ソフトウェアのサプライチェーンや自動化の仕組みが連鎖的に狙われる事例だ。「GitHub Actions」「npm」「PyPI」といった開発サービスやツールにおいて 、正規の更新経路が悪用される事件が相次いでいる。

　ビジネスの加速を目指す組織にとって、CI（継続的インテグレーション）/CD（継続的デリバリー）パイプラインを用いた自動化は欠かせない。しかし、攻撃者は人間のログインパスワードだけではなく、CI/CDパイプラインのシークレット情報やAPIキー、OIDCトークンなどの自動化処理に付与された権限を標的としている。OIDC（OpenID Connect）トークンは、固定のパスワードや秘密鍵をプログラム内に保持することなく、サービス間で一時的なアクセス権を安全に受け渡す仕組みを指す。川口氏は、「クラウドサービスの管理画面だけではなく、クラウドサービスの設定や構成を変更できる自動処理そのものを守る必要がある」と指摘する。

例外を管理し、期限と責任者を明確にする

　これらの事例が示すのは、セオリー通りの対策が実施できない「裏側」にこそリスクが潜んでいるということだ。工場の制約でスマートフォンが持ち込めずMFAが適用できない 、業務部門の強い要求で例外設定が放置される、便利さ優先でSaaS連携の実態が把握し切れなくなるといった現場の課題は、どの組織にも存在し得る。

　「『クラウド事故』は、ビジネスのさまざまな制約から作られた『例外』から起きる。例外なしで運用できる組織は少ないからこそ、例外の存在を受け入れた上で、それをどのように管理するかが重要だ」と川口氏は語る。

　その第一歩として、川口氏は直ちに確認してほしい5つのポイントを挙げた。

1. ID・権限の例外
   • MFA未適用のアカウントや過剰な権限、委託先・緊急用IDの棚卸し
2. アクセスキーとトークン
   • APIキーやCI/CDのシークレット、パーソナルアクセストークンの見直し
3. OAuth／SaaS連携
   • AIツールや外部アプリケーションに対する同意済み権限の把握
4. ログイン／設定変更ログ
   • 管理者のログインや権限変更、公開設定変更などを監視する仕組みの構築
5. 拡張機能
   • Webブラウザや統合開発環境（IDE）の拡張機能に潜むリスクの可視化

　例外的な運用を認める場合には、無期限とするのではなく「いつまで適用するのか」という期限と責任者を明確に設定することが不可欠だ。全てを一度に改善することは難しくても、まずはこれらのポイントのいずれか1つから着手し 、自組織の「例外」を把握することが、クラウドサービスの安全性を高める堅実なアプローチになる。

本稿は、アイティメディアが2026年5月25日～6月1日に開催した「ITmedia Security Week 2026 春」における、5月27日のセッション「業務背景から読み解くクラウドセキュリティ ～対策のセオリーと現場の実態～」を基に作成しました。