アサヒHDランサム攻撃（2025年9月）から考える：非機能要件／BCP設計の改善策
0. はじめに
最近、頻発している大規模システムへのサイバー攻撃において考察する中で、
これまでのスキルを整理しブラッシュアップする必要があると感じ、考察を纏めてみました。
実在の事例において仮定や想定を基に考察を組み立てているため、
実際、現場で昼夜対応している関係者の皆様のご苦労を考えると、理想論を振り回すようで不快に感じる部分があるかもしれませんが、趣旨について理解の上ご容赦ください。
1. 本稿の概要
2025/9/29にアサヒグループHDにおいて発生したサイバー攻撃のケーススタディとして構成していますが、タイムラインや影響等については既に広く報じられており、本稿としては詳細な記述を割愛しています。
私自身が各業種のシステム開発に従事した中で得た知見を基に、被害発生箇所の想定や俯瞰して考察した課題や懸念について システム開発技術として、全体システムセキュリティ対策としてどうあるべきか、今後の実務的な取組みについて検討してみました。
＜本稿の構成＞
- サイバー攻撃の概要
- 前提／注意事項
- 全体システム像の想定
- 侵入ポイントや方法についての考察
- 懸念点／課題
- 改善ポイントの考察
- 総括
- 追記 ← 2025/12/02 追加検証
2. サイバー攻撃の概要
| 日 付 | 事 象 ／ 状 況 |
|---|---|
| 2025/ 9/29 | サイバー攻撃によりシステム障害が発生。国内の受注・出荷、コールセンター業務を停止 |
| 2025/10/ 2 | アサヒビールが手作業で業務を一部再開し、全6工場を再稼働 |
| 2025/10/ 3 | 攻撃がランサムウェアによるものと判明。被害拡大防止のためシステムを遮断し、社外メールの受信を停止したと発表 |
| 2025/10/ 7 | ランサムウェア集団「Qilin」がダークウェブ上で犯行声明を発表 |
| 2025/10/ 8 | 流出した疑いのある情報をインターネット上で確認。影響は日本で管理するシステムに限定と説明 |
| 2025/10/14 | 個人情報が流出した可能性を公表。該当者には通知を行い、法令に基づく措置を実施する方針を示す |
| 同 上 | 同日、システム障害の影響で2025年12月期第3四半期決算の開示が期末後45日を超える見込みであることを公表 |
※ 動かないコンピュータから抜粋
3. 前提／注意事項
- 全体システム構成が不明なためセキュリティ面を考慮した構成を想定の下、考察を行っています
- サイバー攻撃の内容については、日経クロステック無料会員向け公開情報を参考にしています
例：ランサム被害で物流システムが停止 9300超のファイルを盗取と犯行声明 - 組織体制や上場企業における内部統制などについて、公開されている情報から推測して考察していますが、もしも認識に不備があればご連絡ください
- 主に非機能要件定義を中心とした上流工程スキルをブラッシュアップする検討の一環ですので、前向きなご指摘をお待ちしております。また、転記や転載についてはご一報いただけると幸いです
4. 全体システム像の想定
各システム群とセキュリティ機器の構成にフォーカスを置いて俯瞰図を想定してみました。
目的としては、現状の報道や評論記事はシステム像が抽象的なために、今後の取組みとして何をどう改善していくのかもボンヤリとしてしまって一過性の警鐘で終わる懸念を抱いた事から、具体的な取組みには『ベースとなるイメージ』が必要と考え作成しました。
5. 侵入ポイントや方法についての考察
- 国内のみが被害を被っている点
- 『窃取されたデータは、9300以上のファイルで約27GB相当』との報道があった。データ量としては少量だが大きな被害を与えている点
※ 2025/10/19発生のアスクル事案における『窃取が主張されたファイルは1.1TB』との報道と比較すると、一連のサイバー攻撃が短時間で実行されたと推測しています - 業態としてSCMにおけるデータ連携先が広範囲で、リアルタイム化推進による認証連携が進んでいると考えられる点
- 侵入などの脅威検知系システムについては、営業規模に相当した考慮／整備がなされていると考えられる点
以上から、侵入ポイントとして認証システムが狙われたのではないか、と考えています。
同様の指摘は、上記引用元の日経クロステック記事内でも
サイバーセキュリティー企業S＆Jの三輪信雄社長が「障害の影響範囲が広範囲にわたっており、恐らく社内ネットワークのActive Directoryサーバー（ADサーバー、ドメインコントローラー）を狙った典型的な事案ではないか」と指摘
していますが、個人的にはより具体的に「VPN機器の脆弱性を利用した可能性よりも認証情報を奪取して侵入した確率が高いのではないか」と考えています。
最近、Salesforce のソフト利用企業で古典的ななりすましによる情報漏洩がありましたが、フィッシングメールやマルウェアを使って社内PC端末から不正に ID／パスワードなどの認証情報を窃取出来、APIルートやSSO経路を使って攻撃するなど技術的な選択肢もあるため、認証系システムが狙われる傾向が多いように感じています。
「サイバー攻撃＝脆弱性を利用した侵入」というステロタイプの記事も目につきますが、その「脆弱性」とは何を指しているのか疑問でもあります。
例えて言えば、社外PC端末から外部施設のフリーWiFiを使用して認証情報を奪取されるようなケースでは、セキュリティ教育体制の「脆弱性」とでも言うべきでしょうが、曖昧な抽象的表現からは読み取れません。(勿論、大企業でこのレベルの教育不備を感じた事はありませんが…。)
また、正規ルートからの侵入であれば「侵入検知」ではなく「改ざん検知」の監視アラートで発覚する想定ですので、インシデントを防ぐというよりサイバー攻撃を最小限に抑えるという対応になり、今回は「改ざん検知」で発覚したのではないかとも想定しています。
6. 懸念点／課題
1. セキュリティ対策として、組織体制が十分に考慮されていたか？
2. BCP上の考慮として、シナリオやテストが想定されていたか？
3. システム開発における、非機能要件／運用設計ドキュメントはどうあるべきか？
4. バックアップ／リストアが、復旧観点で想定したBCPシナリオと合致しているか？
5. システム停止時の手作業による業務遂行ガイドラインが、監査対応形式でBCPに含まれているか？
今回のようなケースでの復旧対応業務のフローを検討したところ、想像以上に作業内容はハードだと感じました。中小企業は別としても、上場企業の場合は各段階で承認ステップが必要になる想定のため、工数・工期が必要となるのは必然的と言えます。
ましてや既存ネットワークを使わずに、コミュニケーション網や承認ワークフローを早期に臨時で確保するためには、BCPにおいてガイドラインが整備されている必要があると強く感じました。
上記の5点については、次章でそれぞれ詳細化していきます。
7. 改善ポイントの考察
7-1. セキュリティ対策として、組織体制が十分に考慮されていたか？
後述する中でも必要性については言及しますが、最高セキュリティ責任者（CISO）に相当する担当幹部の任命が必須だと考えています。今回、明示的にロールを任ぜられている方を上手く見つけられませんでしたが、多分、兼務されているのではないかと考えます。
ただIPAも推奨していますし、大規模システムの場合には特に独立した形でシステムもしくはセキュリティの統括責任者を設置する事が危機管理面でとても重要になると考えます。
7-2. BCP上の考慮として、シナリオやテストが想定されていたか？
初期の発表で気になったのが、2025/10/3付 お知らせにおいて「緊急事態対策本部を立ち上げ」「障害の発生したシステムの遮断措置」が発表された点でした。
アクションプランとして広報対応が考慮されていなかったのかもしれませんが、本来は 9/29付で実施した事項が４日遅れで発表された形です。状況を詳しく見極めたかったのかと思いますが、BCPにおけるシナリオの想定について懸念を感じた部分でした。
前述のCISOとも関連しますが、サイバー攻撃によって被害を受けた際の復旧を想定したテストを行うとすれば、ミニマムで実施するとしても一定規模のコストや要員を確保し、指揮命令権をもって実行する体制や仕組みが必要であり、現実的な対策として机上シミュレーションを多く取り入れたとしても、それは変わらないと考えています。
7-3. システム開発における、非機能要件はどうあるべきか？
企業全体のセキュリティポリシーに基づいた非機能要件のガイドラインから、個別システム毎に具体化していく流れになる想定ですが、全体としての整合性を個別開発時の検証だけで、見落としなく把握・調整出来るのか疑問もあります。勿論、出来るようにするためのガイドラインではあり、個別ドキュメントを軽視するつもりもないので「あるべき姿」を再考します。
7-3-1. 本番環境再構築手順
インフラ環境のIaC化を含めた環境構築の自動化が進んでいるものの、本番環境構築手順についてドキュメントがきちんと整備されている例は多くないというのが肌感覚です。
本番環境を遮断した場合、開発環境やステージング環境を昇格させるのは難しいと考えており、システムの入れ物は IaC から構築がすぐに出来ても、サーバ証明書の入手やAPIキーを含む各種鍵の再発行や鍵管理の再構築などなど、ネットワークや他システムとの信頼関係を再構築する部分は自動化で対応出来ない部分が多い想定です。
緊急時の復旧優先度が高いシステムは、非機能要件-「可用性・継続性」項において本番環境再構築手順化について明記すべき、だと考えました。
その際に当然、テストにおける検証が必要になるものの、他システムや外部連携がある場合にはコストだけでなく調整も諸々発生するため、CISOを頂点とする管理組織がやはり必要だと思います。
フルスペックでのテストが現実的でない場合には、内容を吟味して部分実施と机上シミュレーションという対応も検討出来る体制が必要、だと考えています。
コストが許せば、オンプレでコールドスタンバイさせておくなど、系統を分けた冗長化構成を備えておくのも一案ですが、モジュール更新やマスタ更新などの頻度と各種コストを考えると、かなり思いきった判断が必要で難しいと思っています。
7-3-2. SBOM管理
SBOMと書くと、ソフトウェアコンポーネントの構成／依存関係の管理という捉え方になってしまいますが、構成機器のファームウェアを含んだ形での管理が望ましいと考えています。
非機能要件-「開発・リリース管理」項において対象の範囲／管理項目などの要件の明記と共に、全体システムとしての管理から外して個別管理とせざるを得ない場合の、取扱いの枠組みについても要件として明示が必要、だと考えます。
セキュリティ対策における脆弱性除去を速やかに行うため、既に多くのドキュメントで明記済みかもしれません。
7-3-3. バックアップデータ
非機能要件-「可用性・継続性」項においてバックアップデータの要件として
(1) 優先度やRTO/RPO(目標復旧時間／目標復旧時点)に応じた頻度・世代・形式
(2) 暗号化等で破壊されにくい安全な保管形式への移送
(3) バックアップデータとの差分更新手段
(4) データが改ざんされていない事を保証するためのデータ整合性検証プロセス
(5) BCPシナリオに耐えうる実用性を備えたDBの再構築手順化
の5点が記載に含まれているべき、だと考えました。
汎用機が主流の時代には、MTに保管したり復元手順についても必須事項でしたが、現代ではリアルタイム性の要求が高くなって、サービス停止時間を極力減らす傾向のためか、バックアップデータが緊急時に使えるかという点が怪しくなっているようにも感じています。
7-3-4. パッチ適用対策
ファームウェア等の脆弱性情報を把握しても、運用上の制約からパッチ適用のネックとなる事象があり、非機能要件-「可用性・継続性」項の記載内容との調整が必要となります。
(1) 計画的なシステム停止要件として、定期的なメンテナンス枠を設けておく
(2) フェールオーバーの要件がパッチ適用の妨げにならないように下記について考慮する
(a) 冗長化構成
(b) 装置間のファームウェア不整合防止
(c) ファームウェア更新中に発生したフェールオーバーの切り替え遅延対策
(d) 検証環境がない場合の対応
(e) 影響レベル毎のパッチ方針設定
(3) 変更申請承認遅れを防ぐための、外部業者実施も含めた承認ワークフローを検討する
という3点について運用部門とも相談して整備すべき、だと考えました。
要件定義のための要件定義とならないように、詳細化時点でのトレーサビリティについても注記しておきたいところです。
7-3-5. ソーシャルセキュリティ対策
非機能要件-「認証・認可」／「組織・体制」項において、ソーシャルセキュリティについても記載の考慮をすべき、だと考えています。但し、企業全体のセキュリティポリシーにおいて整備されるべきものなので、個別システムとしての特異性がある部分の特別事項について明記したり、企業全体のセキュリティポリシーへのフィードバックを検討するなどの仕組みも必要、だと思います。
入室管理がカードキーによって厳格化されているとはいえ、共連れや紛失カードの悪用などで社内に物理侵入してしまえば、フリーアドレス化が進んでいる場合には意外と簡単に社内LANに接続出来るケースがあります。
金融業のセキュリティ意識と以外業種とではセキュリティ意識にかなり差があると常々感じており、物理的にもリスクが潜んでいると考えるべき、なので「6. 懸念点／課題」に明示されていませんが付記しました。
7-4. システム開発における、運用設計はどうあるべきか？
今回の考察では機能設計に踏み込まないので、基本的には非機能要件に記載した事項の詳細化が中心となります。
7-4-1. 運用ポリシー
障害や攻撃被害時に業務影響の範囲が大きい重要システムは、高可用性を少し犠牲にしてもセキュリティ強化やバックアップデータ隔離などに重点を置く判断も必要、だと考えています。
7-4-2. 運用手順
バックアップやシステム復旧の手順について非機能要件における考慮事項を詳細化する必要があります。
7-4-3. セキュリティ運用ポリシー
パッチ適用の手順について非機能要件考慮事項をポリシー化するとともに、ログ管理ポリシーとして、サイバー攻撃時に破壊されることを考慮とした対策を設計時に検討すべき、だと考えています。
7-4-4. 変更管理計画
パッチ適用の承認ワークフローについて非機能要件における考慮事項を詳細化する必要があります。
7-4-5. 運用監視
アカウント種類／端末所属先／IPアドレス範囲等で選別したときに、通常業務としてはイレギュラーな多数ファイル更新や一定量以上のデータ転送についても、攻撃を疑う観点で監視アラートレベルを設定すべき、だと考えています。
一定期間毎に監視ルールが妥当か見直す仕組みがあれば尚良いとは思いますが、流石に理想論で、現実的には個別システムの範疇ではコスト的に納まらないように想像しました。
7-5. 懸念点／課題におけるBCP考慮との整合性
- バックアップ／リストアが、復旧観点で想定したBCPシナリオと合致しているか？
- システム停止時の手作業による業務遂行ガイドラインが、監査対応形式でBCPに含まれているか？
今回のケースではバックアップデータでDBを再構築した後に、手作業で行った業務データの取込みが必要となり、データをExcel等で纏めておいてもらったものをCSV形式にしてインポートすると想定しています。
データ入力の揺らぎがわりと面倒だと考えていますが、会計監査／システム監査における要件をどうやったら満足させるのか、については具体的検討において解が出ていません。
被害を被ったシステムを再構築して、全システムを復旧するフローを考えると下図のようになる想定で、BCPに特化して考察する機会を別途設けて検討したいと考えています。
8. 総括
- CISOが専任されていなければ、専任幹部を任命する
- BCPの見直しを行い、検証／テストを実施する
- 重要システムのバックアップシステム・バックアップデータについて再検証する
- 重要システムにおいて、定期メンテナンス枠の設定／検証を行う
- サプライチェーンの接続形態と認証連携について、リスク分析を行う
- 人的要因によって誘発されたかどうか検証し、フィードバックを行う
- 企業全体のセキュリティ教育や風土において、不備はなかったか検証する
特に、BCPのシナリオ不足やテスト不足があるのかないのか、気になりました。
プラン策定時と想定が異なっている場合の更新や想定不足の洗い出しによる追加と、関係部署を含めたプランのウォークスルー検証や、机上シミュレーションを含めたテストの全社実施など、CISOが主導して継続的に対策を行っていく必要があるからです。
今回のケースにおいて関連がなくても、人的リスク要因として社内PC端末の画面ロックが疎かになっているケースがないか、MFAデバイスの適切な運用、死活アカウント管理など、些細な事の積み重ねにも気を配って多角的なPDCAによってレベル向上を続けていかねばならず、今回の考察を終えてセキュリティ対策に終わりはないと再認識しました。
狙われないように、また狙われても兆候が検知出来るようなセキュリティ対策を、包括して行わなければならない厳しい時代になっていると感じます。
9. 追記
新たな情報を含めた整理を簡単ですが行いましたので、箇条書きベースで追記しておきます。
2025/11/27 記者会見で明らかになった事実
(1) 発表者は、アサヒグループHD社長、同 CFO、アサヒグループジャパン社長の3名
(2) 感染経路はグループ会社のNW機器で、VPN装置かどうかについての明言は避けた
(3) グループ会社NW機器から侵入され、主要DCを経由してパスワード・管理者権限を奪取された
(4) システム受注再開は アサヒグループ食品＝12/2、アサヒビール・アサヒ飲料＝12/3
を予定
(5) 感染源の調査や追加のセキュリティ対策を講じ、安全性を確認して段階的に復旧し、2026年2月以降に完全復旧の見込み
(6) NISTガイドライン「サイバーセキュリティフレームワーク」を使用し、従来から診断を実施
(7) ゼロトラストを導入途中において攻撃があり、今回、ゼロトラストの通信環境を整える事はあらかた完了
(8) EDRを導入していたが、今回の攻撃では検知出来ていない
(9) バックアップが生きていて、自力で復旧出来ると判断
初回考察との差異
(1) フィッシングメールやマルウェア等で ID／パスワードを奪取された訳ではなく、NW機器から侵入を許し、その後パスワード・管理者権限を奪取された
(2) 復旧は単純復旧ではなく、大幅な改善対策を盛り込んだ上で復旧を図っている
初回考察との一致点
(1) CISO もしくは類似役員は現れなかった
※ 社長やCFOが兼任する場合、守備範囲が広すぎて実効性が薄れるため専任が必要と想定
(2) グループ会社の認証連携が関係している
(3) パスワードや管理者権限が奪取されたため、侵入検知が有効でなかった
今後の懸念点
(1) 感染源の調査が完了したステータスでない
※ システム再開は、感染源の調査が完了した後に行われる想定だった
(2) BCPの改善内容と、テストによる検証が実施されるかどうか
システム関連業務における一般的課題
グループ会社からの侵入ということを改めて考えると、SBOM管理・脆弱性対応・BCPのそれぞれをグループ会社全体で考慮する必要があるので、開発や運用の考慮において難度が上がると実感しました。
Discussion