アサヒビールとアスクルのランサムウェア攻撃から見る原因と、このような状況にならないための対策

アサヒビールとアスクルがランサムウェア攻撃を受けたことについては、既にご存知のことですが、この原因を探るとともに、同様の攻撃を回避するにはどうすればいいのかを生成AIを使って整理しました。

ChatGPT 5.1がリリースされたので、その性能や使い勝手を検証することも目的としています。

使ってみた感想として、「目的を与えれば、自律的に目的を達成する」ことを目指す、Agentic AIとはこういう方向に向かうのかなぁ、と感じさせるものでした。それは、こちらの意図をくみ取り、どのように答えを出すべきかを推測し、こういうこともやってはどうか、こういうことには気をつけなくちゃいけないなど、かなりおせっかい焼きです。

文章は2種類です。

一般的な説明と経営者向けの説明です。

ご参考まで。

一般向けの説明　===

1. 背景と目的

近年、日本国内でも大手企業を狙ったランサムウェア攻撃が相次いでいます。2025年には、アサヒグループホールディングス（以下、アサヒビール）およびアスクルがランサムウェア攻撃を受け、業務停止や情報流出のリスクが社会問題となりました。

本レポートでは、これら二つの事例を題材として、

• 公開情報から分かる事実と、

• 一般的なランサムウェアの侵入経路や攻撃手口、

• 同様の事態を防ぐために、いま企業が取るべき対策

を整理し、「オンプレ中心・VPN前提の世界」から「クラウド＋ゼロトラスト」への移行の必要性を含めて考察します。

2. 事例概要

2.1 アサヒビールのランサムウェア攻撃

• 2025年9月末、アサヒグループHDはサイバー攻撃によるシステム障害を公表。

• その後の発表で、国内システムがランサムウェア攻撃を受けたこと、情報流出の可能性があることを明らかにしました。

• 攻撃者側として、ランサムウェアグループ「Qilin（キリン）」がダークウェブ上で犯行声明を出し、社内データを窃取したと主張しています。

• ただし、どの機器・どの脆弱性・どのアカウントが初期侵入に利用されたのかといった、具体的な侵入経路は公式には公表されていません。

2.2 アスクルのランサムウェア攻撃

• 2025年10月、アスクルはランサムウェアによるシステム障害発生を公表しました。

• ECサイト「ASKUL」「LOHACO」を含む受注・出荷業務が停止し、多数の取引先にも影響が波及しました。

• 後の調査で、顧客・取引先情報の一部が外部に流出したことが確認されています。

• こちらも、外部からの不正アクセスおよびランサムウェア感染が公表されているものの、具体的な侵入経路（VPN機器、メール、クラウド設定不備など）の詳細は公表されていません。

3. 原因と推定される侵入経路の整理

3.1 公開情報から確定しているポイント

アサヒビール・アスクル両社に共通して、公表資料から読み取れるのは次の点です。

1. 外部からの不正アクセスを起点とするランサムウェア攻撃であること

2. 社内システムの暗号化や業務停止が発生したこと

3. 顧客・取引先等の情報流出の可能性（あるいは流出の確認）があること

一方で、次の点は公式には公表されておらず、外部からは断定できません。

• どのサーバ／機器（VPN装置、ファイアウォール、公開Webサーバ等）が最初に突破されたか

• どの脆弱性（CVE）や設定不備が悪用されたか

• 認証情報の盗難・不正ログインがあったのかどうか

したがって、本レポートでは以降、一般的なランサムウェア攻撃の傾向や、Qilin等のグループの典型的な手口をもとにした「あり得る経路」の整理を行いますが、個別企業における真の原因は、各社のインシデント調査報告に依存することに留意が必要です。

3.2 ランサムウェア攻撃で典型的な侵入経路

最近の国際的な調査レポートやインシデント分析では、企業へのランサムウェア攻撃における「初期侵入ベクタ」として次のようなものが多いと報告されています。

1. 境界機器（VPN装置・ファイアウォール・リモートアクセスゲートウェイ）の脆弱性悪用

   • Fortinet、Cisco、SonicWall、Palo Alto 等のVPN／ファイアウォール製品の既知脆弱性

   • 旧バージョンのまま放置された機器や、サポート切れ（EoL）の機器

2. 盗まれた／推測された認証情報の悪用

   • フィッシングメールや情報窃取マルウェア（Infostealer）によるID／パスワードの窃取

   • 闇市場から購入したVPNやRDPアカウント情報

   • 短く・使い回しのパスワードに対する総当たり攻撃（ブルートフォース、パスワードスプレー）

3. リモートデスクトップ（RDP）やCitrix等のリモートアクセスの悪用

   • インターネットに直接公開されたRDP

   • MFA未設定のリモートアクセス

4. 公開アプリケーション／クラウドサービスの脆弱性や設定不備

   • WebアプリケーションやAPIの脆弱性

   • AWSや各種SaaSの権限設計ミス・公開設定ミス（意図せぬインターネット公開など）

5. 標的型メール（フィッシング）からの端末侵害

   • 添付ファイルやURLを踏ませてマルウェアに感染させる

   • その端末を踏み台に、VPN／クラウド／管理者権限を取得

アサヒビールの攻撃を行ったとされる Qilin グループについても、海外の技術分析では、

• VPN装置の脆弱性悪用

• フィッシングからの情報窃取

• RDPやCitrixを使った横展開

といった手口が頻出することが報告されています。

3.3 アサヒビール・アスクル事例から読み取れる構造的な課題

個別企業について「この経路だ」と断定することはできませんが、両事例と一般的な傾向から、次のような構造的な課題が浮かび上がります。

1. オンプレミス環境＋VPN中心のアーキテクチャの限界

   • 社内システムをオンプレに集約し、社外からのアクセスはVPN装置経由という構成が多い。

   • 一度VPN装置やその手前の認証が破られると、社内ネットワークに広くアクセスされやすい。

2. 境界機器のライフサイクル管理・パッチ管理の難しさ

   • VPN／ファイアウォールは24時間止めにくく、パッチ適用が後回しになりがち。

   • EoL機器が残存し、既知脆弱性が長期間放置されることも多い。

3. ID・認証情報の管理の甘さ

   • パスワードポリシーの形骸化、MFA未導入、退職者アカウントの放置など。

   • フィッシング対策が追いつかず、認証情報が外部に漏れる。

4. クラウド・SaaS利用が増える一方で、設定・権限設計が追いつかない

   • オンプレとクラウドが混在し、全体像としてのセキュリティ設計が不十分になりがち。

   • セキュリティ監査・ログ管理が各所に分散し、攻撃の早期検知が難しい。

4. 同様の状況を避けるための対策

ここからは、「アサヒビールとアスクルの事例のような大規模被害を避けるために、企業は何をすべきか」を整理します。

4.1 技術面での基本対策

4.1.1 境界機器（VPN・ファイアウォール）のリスク低減

• 最新パッチの迅速適用

  • セキュリティアップデート情報を常時監視し、優先度をつけて適用する体制を構築。

• EoL機器の計画的な廃止・更新

  • サポート終了機器を洗い出し、リプレース計画を明確化。

• インターネットからの直接アクセスを最小化

  • 管理インターフェースをインターネット側に公開しない。

  • メンテナンス用アクセスは踏み台サーバやゼロトラスト経由に限定。

4.1.2 ID・アクセス管理の強化

• 多要素認証（MFA）の全面導入

  • VPN、リモートデスクトップ、クラウド管理コンソールなど、重要システムへのアクセスにはMFAを必須とする。

• 強固なパスワードとパスワードレスの推進

  • 短く・使い回しのパスワードを禁止し、パスワードマネージャーの利用を促進。

  • 可能であればFIDO2等のパスワードレス認証へ移行。

• アカウントライフサイクル管理

  • 入社・異動・退職に応じて権限を自動で変更・削除する仕組みを整備。

4.1.3 エンドポイントとメールセキュリティ

• EDR／EPPの導入と運用

  • 社員端末にEDRを導入し、不審な挙動を検知・遮断できるようにする。

• フィッシング対策の多層化

  • メールゲートウェイでのURL・添付ファイル検査。

  • 定期的な訓練メールによる社員教育。

4.1.4 バックアップとインシデントレスポンス

• バックアップの分離と定期検証

  • ランサムウェアから直接アクセスされにくい形（オフサイト・オフライン・WORM等）でバックアップを保管。

  • 復旧手順を定期的にテストし、「復旧できること」を確認しておく。

• インシデント対応計画（IR Plan）の整備

  • 連絡体制、初動手順、外部専門家への連携方法などを文書化。

4.2 アーキテクチャレベルの対策：クラウド＋ゼロトラストへの移行

技術的な個別対策だけでなく、そもそものシステム構成を「攻撃されにくく、被害が広がりにくい」形に変えていくことが重要です。その方向性として、

オンプレ環境にサーバー類を極力持たず、クラウドやSaaSへ移行する。

ユーザーとのアクセスは、VPNではなくゼロトラスト・アーキテクチャで構築する。

という戦略は、非常に現実的で有効です。

4.2.1 なぜクラウド＋ゼロトラストが有効なのか

1. 攻撃対象としてのVPN装置・オンプレFWを減らせる

   • 境界機器の脆弱性がそもそも存在しなくなる、あるいは大幅に減少する。

2. 「社内ネットワークに入られたら終わり」という構造を変えられる

   • ゼロトラストでは、「ネットワークの内側＝信頼できる」という前提を捨て、

     • ユーザー／端末／アプリ／データ単位で認証・認可を行う。

   • 一つの入り口が破られても、横方向への展開がしにくい構造になる。

3. クラウド事業者のセキュリティ機能を活用できる

   • パッチ適用、冗長化、ログ収集、脅威検知など、多くの機能がマネージドサービスとして提供される。

4.2.2 ただし、リスクは「IDとクラウド設定」にシフトする

クラウド＋ゼロトラストに移行すると、

• VPN機器の脆弱性リスクは下がる一方、

• ID基盤（Entra ID / Okta / Google Workspace等）とクラウド設定（IAM・ネットワーク・ストレージ公開設定など）が新たな"要塞"となります。

そのため、次のような取り組みが不可欠です。

• IdPに対するMFA・条件付きアクセス・リスクベース認証の導入

• クラウド設定の診断（CSPM）と権限の最小化設計

• 管理者アカウントの厳格な保護（分離端末／専用アカウント等）

4.2.3 現実的な移行ステップのイメージ

一気にオンプレゼロ・VPNゼロを実現できる企業は多くありません。現実的には、次のような段階的アプローチが考えられます。

1. 対外公開される入口からクラウド＋ゼロトラストに寄せる

   • 社外向けWebサービス、社外からの社員アクセス（テレワーク）を優先的に移行。

2. 新規システム・更新システムは"クラウド前提"で設計

   • これ以上オンプレ資産を増やさない方針を明確にする。

3. 残るオンプレは"閉じたエリア"で最小限に運用

   • 工場や制御系、特殊な基幹システムなど、どうしてもオンプレが必要な部分は、

     • 入口を極小化し、

     • 物理・ネットワーク・アカウントを強固に制限した上で運用。

5. まとめ

• アサヒビールとアスクルのランサムウェア攻撃は、いずれも外部からの不正アクセスを起点としたサイバー攻撃であり、業務停止や情報流出のリスクが顕在化した事例です。

• 公開情報だけでは具体的な侵入経路（どの脆弱性・どの機器・どのアカウントか）を特定することはできませんが、最近の攻撃動向やQilin等のランサムウェアグループの手口から、

  • 境界機器（VPN・ファイアウォール）の脆弱性、

  • 盗まれた／弱い認証情報、

  • RDP／Citrix等のリモートアクセス、

  • 公開アプリやクラウド設定の不備、
    といった要素が主要なリスクであることが分かります。

• そのうえで、同様の事態を避けるためには、

  • 境界機器・ID・エンドポイント・バックアップなどの基本セキュリティ対策の徹底と、

  • オンプレ中心・VPN前提の構成から、クラウド＋ゼロトラストを軸とする新しいアーキテクチャへの移行
    の両輪が必要です。

本レポートが、自社のランサムウェア対策や、今後のシステム構成の見直し（クラウドシフト・ゼロトラスト化）を議論する際のたたき台となれば幸いです。

経営者向けの説明　===

アサヒビールとアスクルのランサムウェア攻撃から見る原因と対策

1. 何が起きたのか（事例の要点）

• アサヒグループHD（2025年9月）と アスクル（2025年10月）が、相次いでランサムウェア攻撃を受けた。

• 共通する結果は、

  • システム障害による 業務停止・出荷遅延

  • 顧客・取引先情報の流出リスク

  • 社会的信用の毀損

• ただし、両社ともに 具体的な侵入経路（どの機器・どの脆弱性・どのアカウントか）は公表されていない。

2. 背景にある「構造的な原因」

公開情報と、最近のランサムウェア事案の傾向から、次のような構造的な課題が見える。

1. オンプレ＋VPN前提の古いアーキテクチャ

   • 社内システムはオンプレミスに集中、社外からはVPN接続、という前提。

   • VPN装置や境界ファイアウォールが「単一の入口」となり、ここを突破されると社内ネットワークに広く侵入されやすい。

2. 境界機器の脆弱性・老朽化リスク

   • 24時間止めにくい機器ほど、パッチ適用・更新が後回しになる。

   • サポート切れ機器や、既知脆弱性を抱えたままの装置が残存しやすい。

3. ID・パスワードへの依存と管理不備

   • パスワード使い回し、MFA未導入、退職者アカウントの放置など、

   • フィッシングや情報窃取マルウェアによる「認証情報の乗っ取り」に弱い。

4. クラウド・SaaS利用の拡大に対する設計・運用の遅れ

   • オンプレとクラウドが混在し、全体のセキュリティ設計が追いついていない。

   • 設定ミスや権限設計の不備が、新たな侵入口になる。

3. 経営として押さえるべき対策の方向性

詳細な技術論に踏み込む前に、経営として決めるべき大きな方向性は次の2点である。

3-1. 「入口対策」の強化（今ある前提のままでもすぐやること）

1. 境界機器・リモートアクセスのガバナンス強化

   • VPN装置・ファイアウォールの パッチ適用・更新のルールと予算 を明確にする。

   • 不要なインターネット公開・RDP公開を廃止する。

2. ID・認証基盤の強化

   • 重要システム（VPN、管理画面、クラウド管理コンソール）には 多要素認証（MFA）を必須化。

   • パスワードポリシーの見直しと、パスワードマネージャー等の導入を検討。

3. 被害を最小化する備え

   • ランサムウェアから直接アクセスされにくい バックアップの確保 と、復旧訓練。

   • インシデント発生時の 連絡・意思決定プロセス（IR計画） を整備。

3-2. 「前提そのもの」を変える中長期の方向性

オンプレ中心・VPN前提から、クラウド＋ゼロトラスト前提へシフトする。

1. クラウド・SaaSへのシフト

   • 今後新たに構築・更新するシステムは「クラウド前提」とし、

   • これ以上オンプレ資産を増やさない方針を打ち出す。

2. ゼロトラスト型のアクセスに移行

   • 「社内ネットワークに入る」のではなく、「必要なアプリだけに安全にアクセスする」仕組みへ。

   • VPN装置やフラットな社内LANに依存しない構造を目指す。

3. ID・クラウド設定を新たな"要塞"として扱う

   • IdP（認証基盤）やクラウド設定のセキュリティレベルを戦略的に引き上げる。

   • 権限の最小化、設定ミスを検知するサービスの導入などを検討。

4. 経営メッセージとしてのまとめ

• アサヒビールとアスクルの事例は、

  • 「ランサムウェアリスクは、もはや一部のIT企業の話ではない」こと、

  • 従来型の オンプレ＋VPN前提の構造に限界が来ている ことを示している。

• 経営としては、

  1. まずは 現在の前提の中でできる入口対策・備えを即座に実行すること。

  2. 同時に、3〜5年スパンで クラウド＋ゼロトラストを前提としたシステム構成へと移行する方針を明確にすること。

この2本立てで進めることが、「自社が次のアサヒ・アスクルにならないための」現実的な道筋となる。

「システムインテグレーション革命」出版！

AI前提の世の中になろうとしている今、SIビジネスもまたAI前提に舵を切らなくてはなりません。しかし、どこに向かって、どのように舵を切ればいいのでしょうか。

本書は、「システムインテグレーション崩壊」、「システムインテグレーション再生の戦略」に続く第三弾としてとして。AIの大波を乗り越えるシナリオを描いています。是非、手に取ってご覧下さい。