アスクル事例で考えるランサムウェア被害｜サプライチェーンに広がった影響と企業の対策
2026年7月22日(水)
ランサムウェア被害は、感染した企業のシステムだけに影響するとは限りません。
受注・出荷、物流、顧客対応、取引先のサービス提供まで広がると、自社だけでなくサプライチェーン全体の業務に影響を及ぼす可能性があります。
2025年10月に発生したアスクルのランサムウェア被害は、まさにそのリスクを示した事例です。
アスクルはランサムウェア攻撃によるデータ暗号化とシステム障害により、大規模なサービス停止と保有情報の流出を確認したと報告しました。
この記事では、公式発表で確認できる内容をもとに、企業が見直すべきバックアップ、サプライチェーンリスク、BCP対策を解説します。
アスクルのランサムウェア被害事例とは
まずは、アスクルのランサムウェア被害について、公式発表で確認できる範囲を整理します。ここでは原因を過度に推測するのではなく、企業活動にどのような影響が出たのかを中心に見ていきます。
2025年10月に発生したランサムウェア被害の概要
アスクルは2025年10月19日、ランサムウェア攻撃によるデータの暗号化とシステム障害が発生したことを確認しました。その影響で、事業所向け通販サービス「ASKUL」、購買支援サービス「ソロエルアリーナ」、個人向け通販サービス「LOHACO」などの受注・出荷業務を停止する事態となりました。
日常的にオフィス用品や生活用品を届けるサービスは、多くの企業や個人の業務・生活に組み込まれています。そのため、受注や出荷が止まると、単にECサイトが使えないという問題にとどまらず、備品調達・物流・顧客対応などにも影響が広がります。
この事例で注目したいのは、ランサムウェア被害が「データを暗号化された企業だけの問題」では終わらない点です。業務の中核となるシステムが止まれば、そのサービスを利用する企業や取引先にも連鎖的に影響が出ることになります。
受注・出荷停止が企業活動に与えた影響
アスクルの報告では、物流システムや社内システムでランサムウェア感染が確認され、一部データが暗号化されて使用不能になったことが示されています。特に、物流センターを管理運営する複数の物流システムが暗号化されたことで、出荷業務に重大な影響が生じました。
受注・出荷システムが止まると「注文を受けられない、在庫を確認できない、出荷指示が出せない、顧客へ納期を案内できない」といった問題が一気に発生します。現場では代替手段を検討する必要がありますが、平常時と同じスピードや正確性を保つことは簡単ではありません。
企業にとって怖いのは、システム障害がそのまま事業停止に近い状態へつながってしまうことです。特にECや物流のようにシステムと業務が強く結びついている企業では、ランサムウェア対策はIT部門だけの課題ではなく、経営や事業継続に直結するテーマになります。
情報流出と問い合わせ対応の長期化
アスクルは、ランサムウェア攻撃により、お客様情報に加えて一部取引先情報が外部へ流出したことも報告しています。また、3PLサービスを利用する取引先企業やそのエンドユーザーに関する情報が外部に流出した可能性についても公表しています。
情報流出が発生または疑われる場合、企業はシステム復旧だけに集中することができません。対象範囲の調査・個別連絡・問い合わせ窓口の設置・取引先への説明など、対外対応も同時に進める必要があります。
こうした対応は復旧後も一定期間続きます。
ランサムウェア被害では、システムを戻すことと、信頼を回復することの両方が求められるため、被害が大きくなるほど企業全体の負荷も重くなります。
アスクルのランサムウェア被害で注目すべきポイント
ここからは、アスクルの事例を「ニュース」として見るだけではなく、企業が自社の対策に落とし込むべきポイントとして解説していきます。特に注目したいのは、委託先アカウント・監視体制・バックアップの3点です。
業務委託先アカウントからの不正アクセス
アスクルの報告では、例外的に多要素認証を適用していなかった業務委託先向けの管理者アカウントについて、IDとパスワードが何らかの方法で漏えいし、不正利用されたことが確認されています。
この点は、多くの企業にとって他人事ではありません。
システム開発・保守・運用・物流・EC・顧客対応など、企業活動では外部委託先にアクセス権限を付与する場面が多くあります。自社の従業員には厳格なルールを適用していても、委託先アカウントだけ例外的な運用になっていれば、そこが攻撃の入口になる可能性があります。
委託先に権限を渡すこと自体が悪いわけではありません。
問題は、権限の範囲・認証方法・利用端末・アクセスログ・棚卸しの頻度が十分に管理されているかです。特に管理者権限を持つアカウントは、ひとたび悪用されると被害が広がりやすいため、社内アカウント以上に慎重な管理が求められます。
24時間監視がなかったことで検知が遅れた可能性
アスクルは安全性強化策として、24時間365日の監視と即時対応の体制整備を挙げています。また、報告では侵害が発生したデータセンターにおいて、EDRが未導入であったことや、24時間監視が行われていなかったことにも触れられています。
ランサムウェア攻撃では、侵入直後にすぐ暗号化が始まるケースもあれば、時間をかけて内部を探索し、重要なシステムやデータを狙うケースもあります。
夜間や休日に異常が起きた場合、誰が確認し、誰が判断し、どこまで遮断するのかが決まっていなければ対応が遅れてしまいます。監視は仕組みだけでなく、運用とセットで考える必要があります。
バックアップデータも暗号化され、復旧に時間を要した
アスクルの報告では、物流センターを管理運営する複数の物流システムが暗号化され、同じデータセンター内のバックアップファイルも暗号化されたため、復旧に時間を要したことが示されています。また、ランサムウェア攻撃を想定したバックアップ環境ではなかったため、一部バックアップも暗号化され、迅速な復旧が困難になったとされています。
この点は、今回の事例から多くの企業が学ぶべき重要なポイントです。バックアップを取っていても、本番環境と同じネットワークや同じ権限でアクセスできる状態にあれば、攻撃者にまとめて暗号化される可能性があります。
重要なのは、バックアップの有無ではなく、攻撃を受けても守られているか、実際に復旧できるかです。
アスクル事例から見るサプライチェーンリスク
アスクルの事例は、ランサムウェア被害が自社のシステム内だけで完結しないことを示しています。
特に物流やEC、3PLなど外部サービスとの連携が深い企業では、サプライチェーン全体でリスクを見直す必要があります。
自社が攻撃されなくても業務が止まるリスク
サプライチェーンリスクの難しさは、自社が直接攻撃されていなくても業務が止まる可能性があることです。物流・EC・決済・クラウド・保守運用など、外部サービスに依存している業務が増えるほど、どこか一か所の障害が自社のサービスに影響する可能性があります。
アスクルのケースでは、物流受託サービスを利用している取引先企業や、その顧客に関する情報流出の可能性も公表されています。これは、自社の委託先や連携先で発生したインシデントが自社の顧客対応や事業継続にも影響し得ることを示しています。
企業が見直すべきなのは、自社システムだけではありません。
業務に欠かせない委託先や外部サービスが止まった場合に、自社のどの業務が影響を受けるのかを把握しておくことが大切です。
物流システム停止が取引先や顧客に波及する構造
物流システムは、注文受付・在庫確認・出荷指示・配送状況の管理など、多くの工程を支えています。そのため、物流システムが停止すると、注文が受けられないだけでなく、すでに受けた注文を出荷できない、顧客へ正確な案内ができないといった問題が起こります。
特に、他社の物流を支える3PL事業では影響範囲がさらに広がります。
物流を委託している企業にとっては、自社システムが正常でも、委託先の出荷機能が止まれば顧客への商品提供が滞ります。
こうした構造を考えると、サイバー攻撃への備えは「自社のサーバを守る」だけでは足りません。重要な業務を支える外部サービスまで含めて、止まった場合の代替手段や連絡体制を確認しておく必要があります。
委託先アカウント・外部接続の管理が重要になる理由
委託先に管理者権限やリモートアクセス権限を付与する場合、そのアカウントは便利である一方、攻撃者に悪用されると大きなリスクになります。アスクルの報告でも、業務委託先向けの管理者アカウントが不正利用されたことが確認されています。
確認したいポイントは、MFAの適用有無だけではありません。
権限が業務に必要な範囲に限定されているか、アクセス元端末は管理されているか、利用状況のログが確認できるか、契約終了後にアカウントが削除されているかもチェックしなければならないでしょう。
委託先管理は、契約書上のセキュリティ条項だけで完結するものではありません。実際の運用として、誰が、いつ、どのシステムへ、どの権限で接続できるのかを見える化しておくことが、サプライチェーン全体の防御力を高める第一歩になります。
ランサムウェア被害でバックアップが使えなくなる理由
アスクル事例の大きな教訓は、バックアップがあっても、ランサムウェア攻撃を想定した設計になっていなければ復旧が難しくなるという点です。
ここでは、なぜバックアップが使えなくなるのかを解説していきます。
オンラインバックアップだけでは攻撃の影響を受ける可能性がある
オンラインバックアップは日々の運用では便利なものです。自動で取得でき、障害時にも素早く戻せる可能性があります。
ただし、本番環境と常時つながっている場合、攻撃者に権限を奪われると、そのままバックアップにもアクセスされてしまうおそれがあります。
ランサムウェア攻撃では業務データだけでなく、復旧手段であるバックアップも暗号化・削除の対象になり得ます。攻撃者にとってバックアップを使えなくすることは、被害企業に圧力をかける手段になります。
そのため、オンラインバックアップだけに依存するのではなく、オフライン保管・イミュータブル化・アクセス権限の分離・世代管理などを組み合わせ、攻撃を受けてもバックアップを守れる状態にしておく必要があります。
バックアップは「ある」より「守られている」ことが重要
バックアップ対策でよくある落とし穴は「バックアップを取っている」という事実だけで安心してしまうことです。
しかし、ランサムウェア対策で本当に重要なのは、バックアップファイルそのものが暗号化・改ざん・削除から守られているかです。
例えば、バックアップが本番環境と同じ認証情報で操作できる状態にあると、攻撃者が管理者権限を奪った場合に同時に被害を受ける可能性があります。また、復旧に必要な設定ファイルやDBダンプまで守られていなければ、データだけが残っていても業務再開に時間がかかってしまいます。
バックアップは復旧のための最後の手段です。単に保存するだけでなく、攻撃者に触らせない、書き換えさせない、消させない設計が求められます。
復旧訓練をしていないバックアップは実務で機能しにくい
バックアップが無事に残っていても、復旧手順が決まっていなければ、実際の復旧に時間がかかります。どのシステムから戻すのか、どの時点のデータを使うのか、復元後に安全確認を誰が行うのかを決めておかなければ、有事の判断が遅れます。
特に物流やECのように複数システムが連携している業務では、一部だけ復旧しても全体が動きません。在庫・受注・決済・出荷・顧客対応などの連携を踏まえ、復旧の優先順位をあらかじめ整理しておくことが大切です。
復旧訓練はバックアップが本当に使えるかを確認する機会です。
机上の手順だけでなく、実際に復元できるかを確認しておくことで、ランサムウェア被害時の混乱を減らせます。
アスクルのランサムウェア被害から企業が見直すべき対策
ここからはアスクルの事例を踏まえ、企業が自社の対策として確認したいポイントを解説します。技術対策だけでなく、委託先管理・監視運用・バックアップ・BCPまで含めて考えておきましょう。
全リモートアクセスへのMFA徹底
アスクルは安全性強化策として、全リモートアクセスへの多要素認証の徹底を挙げました。これは、社内利用者だけでなく、委託先や外部パートナーのアクセスにも関わる重要な対策です。
IDとパスワードだけの認証は、漏えいや使い回し、フィッシングなどによって突破されるリスクがあります。特に管理者権限を持つアカウントでは認証の弱さがそのまま重大な被害につながります。
MFAは万能ではありませんが、攻撃者が認証情報を入手した場合でも、不正ログインを防ぐための大切な壁になります。
まずはリモートアクセス・管理者アカウント・委託先アカウントから優先的に適用範囲を見直しましょう。
24時間365日の監視と即時対応体制
続いてアスクルは再発防止策として、24時間365日の監視と即時対応体制、EDR導入を含む多層的な検知体制の整備を挙げています。
ランサムウェア攻撃では、暗号化が始まってから気づくのでは対応が手遅れになってしまうこともあります。
侵入・権限昇格・内部探索・データ持ち出しなどの段階で異常に気づければ、被害を小さくできる可能性があります。
ただし、24時間監視を自社だけで行うのは簡単ではありません。
人員や判断基準、夜間対応、エスカレーションルールが必要ですが、自社運用が難しい場合はSOCや外部監視サービスの活用も選択肢になります。
ランサムウェア攻撃を想定したバックアップ環境の構築
バックアップ対策では通常の障害復旧だけでなく、ランサムウェア攻撃を前提にした設計が必要です。アスクルの報告でも、オンラインバックアップは実施していたものの、ランサムウェア攻撃を想定したバックアップ環境ではなかったため、一部バックアップも暗号化され、迅速な復旧が困難になったとされています。
企業が見直したいのは、バックアップの保存先・権限・世代管理・復元テストです。
攻撃者が本番環境へ侵入しても、バックアップまで同時に破壊されない構成になっているかを確認する必要があります。
また、バックアップ対象も重要です。業務データだけでなく、システム設定やDB、アプリケーションファイル、復旧手順に必要な情報まで含めて、何を守るべきかを整理しておきましょう。
BCPをサイバー攻撃前提で見直す
BCPというと、地震や火災、停電などを想定する企業も多いですが、今はサイバー攻撃による業務停止も現実的なリスクの1つです。
サイバー攻撃前提のBCPでは、システムが使えない状態でどこまで業務を続けるのかを考える必要があります。受注を止めるのか、一部商品だけ受け付けるのか、手作業で出荷できる範囲はどこまでか、顧客への案内を誰が行うのかを事前に決めておきましょう。
また、BCPは自社だけで完結しません。
物流・EC・コールセンター・保守運用など、外部委託先と連携する業務についても、停止時の連絡ルートや代替手段を確認しておくことが求められます。
DIT Securityで支援できること
アスクルの事例から見えるのは、ランサムウェア対策では「バックアップを取る」だけでは足りないということです。
復旧に必要なデータやシステムそのものを守り、業務停止を長期化させないための備えが求められます。
バックアップ破壊による復旧阻止に備えるSentinelARGUS
DIT Securityが提供するSentinelARGUSは、守りたいデータやシステムをイミュータブル、つまり変更不可の状態にすることで、ランサムウェアによる暗号化・改ざん・削除から保護するソリューションです。
ランサムウェア被害で特に避けたいのは復旧に必要なバックアップまで破壊されることです。バックアップが使えなくなると、復旧の選択肢が限られ、業務再開までの時間も長引きます。
SentinelARGUSは一般的な業務データだけでなく、アプリケーションデータ、DBファイル、設定ファイル、バックアップファイルなども保護対象にできます。
物流・業務システムを止めないための自衛型ランサムウェア対策
物流やECのように、業務システムが事業の中心にある企業ではデータや設定ファイルの暗号化がそのままサービス停止につながります。アスクルの事例でも、物流システムやバックアップが影響を受けたことで、復旧に時間を要したことが報告されています。
SentinelARGUSは、従来型のシグネチャーや振る舞い検知に頼るだけではなく、監視対象への不正な変更を防ぐ考え方を持っています。正規ユーザや正規プロセスをホワイトリスト化することで、通常業務への影響を抑えながら、守るべき対象を保護できます。
攻撃を完全に防ぐことだけを前提にするのではなく、攻撃を受けても重要ファイルやバックアップを壊されない状態に近づける。これが、ランサムウェア時代に求められる自衛型の対策です。
BCPを見据えたランサムウェア対策の相談先として
ランサムウェア対策は製品を導入して終わりではありません。
どのデータを守るのか、どのシステムを優先するのか、復旧時に何が必要になるのかを整理したうえで、運用に落とし込む必要があります。
DIT Securityでは、ランサムウェア対策を「感染を防ぐための対策」だけでなく、「被害を受けても事業を止めにくくするための備え」として捉え、企業ごとの状況に合わせた支援を行っています。
まとめ
アスクルのランサムウェア被害は受注・出荷業務の停止だけでなく、物流受託サービスを利用する企業や顧客にも影響が広がった事例です。自社が直接攻撃されていなくても、委託先や外部サービスの障害によって業務が止まる可能性があることを示しています。
また、今回の事例からは、バックアップの重要性も改めて見えてきます。
バックアップは「ある」だけでは十分ではありません。ランサムウェアによる暗号化・削除から守られ、実際に復旧できる状態になっていてこそ、事業継続に役立ちます。
企業がこれから見直すべきなのは、委託先アカウントの管理・MFAの徹底・24時間監視・バックアップ保護・サイバー攻撃を前提にしたBCPです。すべてを一度に整えるのは簡単ではありませんが、まずは自社にとって止まると困るシステムやデータを洗い出すことから始めると、必要な対策が見えてくるでしょう。
ランサムウェア被害による復旧不能リスクや業務停止リスクに備えたい場合はDIT SecurityのSentinelARGUS詳細ページをご確認ください。
執筆者情報
