アスクルはなぜ侵害されたのか クラウドの安全神話を崩す「例外」の正体：MFAやOAuthの落とし穴

組織がクラウドサービスを導入するにつれて、セキュリティ管理はますます複雑になる。アスクルなどの著名企業も、現場のやむを得ない事情で生じた「例外」から侵害を受けた。なぜ対策のセオリーは崩れるのか。

[TechTargetジャパン]

　企業におけるクラウドサービスの利用は、もはや不可欠なものとなっている。ビジネスを加速させる一方で、そのセキュリティ管理は複雑化の一途をたどっている。

　セキュリティ人材の育成を手掛ける川口設計で代表取締役を務める川口洋氏は、大手セキュリティ企業でのSOC（セキュリティ監視センター）業務や、内閣サイバーセキュリティセンター（NISC）での行政機関向けインシデント処理など、サイバーセキュリティの最前線で活動してきた専門家だ。

　川口氏は、クラウドサービス利用時のセキュリティ対策の「セオリーと現場の実態」について言及し、組織が「守っているつもり」になっていても、実際には防御が崩れてしまうポイントとして以下の5つを挙げた。

• クラウドベンダーと自社の責任分界点の曖昧さ
• 誰がどのシステムにアクセスできるかというIDや権限の管理不足
• 公開範囲や管理者権限などの設定ミス
• データ保管場所の把握とバックアップの復旧体制の不備
• 異常なログインや設定変更を検知する監視体制の欠如

　ほとんどの組織はこれらのセオリーを理解し、対策を講じているはずだ。しかし、現実には大規模なインシデントが後を絶たない。

　実際のインシデント事例から見えてくるのは、現場のやむを得ない事情で生まれた「例外」が、いかにして致命的な事故を招くかという実態だ。以下では、具体的な3つの事例と現場の裏側、組織が直ちに取り組むべき対策を紹介する。

アスクルの事例：委託先と「MFA未適用」の例外

併せて読みたいお薦め記事

セキュリティの盲点をなくす

• 本当に安全な「多要素認証」とは？　MFA基本要素と巧妙化する攻撃への対抗手段
• 「パスワードレス認証とは」の前に考える、企業のセキュリティが甘過ぎた実態

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

　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日のセッション「業務背景から読み解くクラウドセキュリティ 〜対策のセオリーと現場の実態〜」を基に作成しました。