タグ: インシデント対応

投稿日:

Cisco FMCの脆弱性が実悪用 ―Qilinランサムウェアへの悪用事例と対策

Share
Cisco FMCの脆弱性が実悪用アイキャッチ画像

Cisco Secure Firewall Management Center（FMC）の脆弱性を悪用した攻撃が確認されています。FMCはファイアウォールなどを集中管理する製品であり、侵害された場合には、管理基盤だけでなく組織内のシステムへの影響も確認する必要があります。本記事では、FMCに影響する2件の脆弱性の概要と、実際の攻撃で確認された活動を整理し、企業が進めるべき確認と対応について解説します。

※本記事は2026年9月16日時点で公開されている情報に基づき作成しています。

Cisco FMCはファイアウォールなどを集中管理する製品

2026年9月9日、Cisco Talosは、Cisco Secure Firewall Management Center（FMC）の2件の脆弱性が実際の攻撃で悪用されていると公表しました*1。確認された攻撃活動には、FMCへの侵入後に組織内の端末へQilinランサムウェアを展開した事例も含まれています。

FMCは、Ciscoのファイアウォールや侵入防御などを集中管理するための製品です。通信の許可・遮断、アプリケーション制御、脅威への対策といったポリシーを管理し、ネットワークで起きている事象を分析する役割を持ちます*2。この役割を踏まえると、管理基盤の安全性は、配下の機器を運用するうえでの前提になります。業務用サーバーの更新計画に加え、管理者が使うセキュリティ製品そのものについても、利用バージョン、アクセス経路、管理権限を把握する必要があります。

また、「Cisco製のファイアウォールを利用している」という情報だけでは影響を判断できません。今回の対象はFMCソフトウェアなど、公式アドバイザリが指定した製品です。Ciscoは両脆弱性について、Secure Firewall ASA Software、Secure Firewall Threat Defense（FTD）Software、Firewall Device Manager（FDM）は影響を受けないとしています。管理対象の機器と、その機器を管理する製品を分けて確認しましょう。

※なおCVE-2026-20079については、Cisco Security Cloud Control（SCC）Firewall Managementも対象ですが、SaaSとしてCisco側ですでに修正済みで、ユーザーによる対応は不要とされています。

CVSS 10.0と5.3 二つの脆弱性の違い

CVE-2026-20079は、FMCのWebインターフェースにおける認証回避の脆弱性です。認証されていない遠隔の攻撃者が認証を回避し、影響を受ける装置でスクリプトを実行して、OSのroot権限を取得できる可能性があります。CVSS v3.1基本値は10.0です。rootはOSにおける強い管理権限であり、管理基盤そのものを操作される問題として受け止める必要があります。

CVE-2026-20316は、低権限アカウントの静的な認証情報が存在することに起因する脆弱性です。認証されていない遠隔の攻撃者がそのアカウントでログインし、機微なデータへアクセスできる可能性があります。CVSS v3.1基本値は5.3ですが、Ciscoは他のFMCの脆弱性と組み合わせて権限昇格に利用できることから、独自の深刻度分類では「High」と評価しています。ここで判断を誤りやすいのが、5.3という数字を見て対応を後回しにすることです。今回のように実悪用が確認され、別の問題と組み合わされると影響が広がる場合は、基本値だけでは優先順位を決められません。ベンダーによる評価の理由と、実際の攻撃での利用状況まで読むことが大切です。

図1：FMCの脆弱性悪用と侵害後の活動

出典：Cisco Talos「Active exploitation of Cisco Secure Firewall Management Center vulnerabilities」（https://blog.talosintelligence.com/fmc-ongoing-exploitation/）を基に弊社作成

Qilinランサムウェアの侵入経路は静的認証情報の悪用

Talosは、FMC上で確認した侵害後の活動を3つの群に分けています。UAT-12197はCVE-2026-20079を悪用し、Webシェルなどを設置して認証情報を窃取していました。UAT-11823では2件の脆弱性の悪用が確認され、管理対象機器の設定情報収集や、Cyclops Blinkの亜種の展開などが観測されています。Qilinランサムウェアの展開が確認されたのは、これらとは別のUAT-11988です。この群はCVE-2026-20316に関係する静的認証情報でFMCに入り、正規の組み込みツールを悪用して内部環境を調査しました。認証情報の窃取や接続経路の確保を経て、端末へQilinを展開しています。

修正プログラムの適用と侵害調査を進める

今回の対応では、FMCを修正版へアップグレードすることと、すでに侵害されていないかを確認することを分けて考える必要があります。まず、実際に運用しているFMCのバージョンを把握し、Ciscoが公開しているCVE-2026-20079とCVE-2026-20316のセキュリティアドバイザリに記載された「Fixed Software（修正版）」と照合してください。Ciscoは、これらの脆弱性への修正を含むハードニングリリースを公開しており、影響を受ける環境について、該当する修正版へのアップグレードを推奨しています。利用しているバージョンによって適切な更新先が異なるため、最新の公式アドバイザリを確認したうえで対応を進めることが重要です。さらに、すでに侵害されていないかを調べます。Ciscoは、対象ログにあるpackage_info関連の実行記録に、/var/tmp/license.tmpが含まれる場合を、悪用の可能性を示す確認ポイントとして挙げています。単に同名のファイルを探すだけではなく、公式に示されたログの文脈で確認し、侵害が疑われる場合はCisco TACへ速やかに連絡するよう求めています。

修正版へのアップグレードは今後の悪用を防ぐために重要ですが、すでに侵害されていないことを証明するものではありません。Ciscoも、侵害が疑われる場合はCisco TACへ連絡し、復旧に関する案内に従うよう求めています。「更新済み」の記録を付ける担当と、侵害の可能性を判断する担当が異なる場合は、両者の確認結果を一つの対応記録で共有すると、調査の抜けを防ぎやすくなります。

図2：修正版へのアップグレードと侵害調査 それぞれの目的

出典：Cisco「Cisco Secure Firewall Management Center Software Authentication Bypass Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-onprem-fmc-authbypass-5JPp45V2）「Cisco Secure Firewall Management Center Software Static Credential Vulnerability」（https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-fmc-static-cred-BET3Cjh）を基に弊社作成

管理装置の復旧だけで対応を終えないために

侵害の疑いがあるときは、FMCだけを調べて完了とする判断は慎重に行う必要があります。今回の事例を踏まえた実務上の確認事項は、FMCで何が実行されたか、そこからどのシステムに接続できたか、認証情報の悪用がほかの環境に及んでいないか、という範囲です。これはすべての利用組織に同じ被害があるという意味ではなく、自社の接続関係と調査結果に沿って影響範囲を確かめるための考え方です。復旧を急ぐ場面でも、調査に必要なデータをどう確保するか、どこまでの通信を止めるか、どの状態をもって安全に再開できると判断するかを、保守担当者や専門家と共有する必要があります。連絡先だけでなく、判断する責任者と、判断に必要な情報を平時に定めておけば、発生後の対応に取り掛かりやすくなります。

BBSecの緊急対応支援で、調査から復旧方針の整理へ

不審なログが見つかったものの影響範囲を判断できない場合や、証拠を保全しながら復旧を進める必要がある場合には、専門的な調査や対応が必要になることがあります。BBSecでは「緊急対応支援」を通じて、初動対応やデジタルフォレンジック、原因・影響範囲の調査、復旧に向けた対応などを支援しています。緊急コンタクト窓口は24時間365日受け付けています。

また、インシデント発生に備えて平時から対応体制を整えておきたい企業向けに、「インシデントレスポンス／フォレンジック」を提供しています。契約などの確認を事前に進め、有事の初動を円滑にするための仕組みです。基本契約の締結は無償ですが、フォレンジック調査費用は含まれません。必要な支援範囲を平時から相談し、自社の対応体制につなげておくことができます。

侵害が疑われる場合は、製品固有の対応についてCiscoの案内を確認するとともに、影響範囲の調査やインシデント対応にお困りの場合は、BBSecの「緊急対応支援」へご相談ください。

緊急対応支援サービスページリンクバナー

【参考情報】

編集責任：木下

セキュリティ対策についてお困りの方へ

自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

盗まれたトークンから約3時間でクラウド管理権限へ ―AnthropicのAI悪用報告から考える企業の対策

Share
AnthropicのAI悪用報告から考える企業の対策アイキャッチ画像

生成AIの活用が広がる一方で、サイバー攻撃にAIを悪用する動きも確認されています。Anthropicが2026年9月10日に公表したAI悪用の調査報告には、盗まれた開発者トークンを足掛かりに、攻撃者が被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例が記されています。AIサイバー攻撃への備えを考えるうえで、この事例は、認証情報の保護と、検知後に動ける体制を点検する材料となります。

AnthropicのAI悪用報告で何が確認されたのか

今回の報告では、2025年12月から2026年8月にかけてAnthropicが検知・対処したAI悪用活動が取り上げられています。サイバー攻撃におけるAIの使われ方には幅があり、攻撃者の補助として利用された例に加え、偵察、侵入、認証情報の収集、情報窃取などをAIに実行させる例や、複数の標的に対してAIエージェントが並行して処理する例も確認されています。一方、標的の選定や攻撃結果の確認、収益化などの重要な判断には、人間が引き続き関与していたとされています。

報告には、認証情報の悪用に関する事例も複数示されています。被害組織の環境から盗んだAIサービスのAPIキーを別の攻撃に利用した例に加え、盗まれた開発者トークンを足掛かりに、被害組織のクラウド環境の完全な管理権限を約3時間で取得した事例も報告されています。認証情報は情報を盗む入口となるだけでなく、攻撃に用いるAIの計算資源へのアクセスにも利用されていました。*3

なお、約3時間という数値は、Anthropicが観測した個別の侵害事例に関するものです。すべてのAIを使った攻撃が同じ速さで進むことや、従来の攻撃より何倍速いかを示す統計ではありません。この事例から企業が考えるべきなのは、約3時間という時間そのものではなく、認証情報が悪用された場合に、異常を検知し、調査やアクセス制限などの対応へ移るまでにどの程度の時間を要するかという点です。

図1：AI悪用による侵入の個別事例

開発者トークンから管理権限取得までの個別事例
開発者トークンから管理権限取得までの個別事例
出典：Anthropic「Detecting and countering misuse of AI: September 2026」（https://www.anthropic.com/threat-intelligence-report-september-2026）を基に作成

認証情報漏洩への対策は、トークンの権限まで確認する

認証情報の管理を見直すときは、人がログインに使うパスワードに加え、アプリケーションや開発環境が使うアクセスキー、トークンも対象にします。ここからは、クラウド環境で取り組める対策をAWSの公式資料を例に整理します。前述の被害事例のクラウド事業者をAWSと特定するものではありません。

AWSはIAMの推奨事項として、一時的な認証情報の利用、多要素認証（MFA）、業務に必要な範囲に絞った権限付与、使われていない認証情報や権限の定期的な見直しを挙げています*2。システムが継続的に使う認証情報についても、長期のアクセスキーを配布する構成から、IAMロールによる一時的な認証情報へ移行できるかを検討します。自社で点検する際は、認証情報を誰が管理し、どのシステムが使い、どのデータにアクセスできるのかを確認し、用途が終わったテスト用の権限や、担当者の異動後も残る認証情報などを整理します。認証情報の保護とあわせて、必要以上の権限を与えないことが重要です。

クラウドのログは、データへの操作まで記録されているか

クラウド監視では、「ログを取得している」だけでなく、実際にどの操作まで記録されているかを確認する必要があります。例えばAWS CloudTrailでは、Amazon S3上のオブジェクトの読み取りなどはデータイベントに分類され、証跡やイベントデータストアでは初期設定で記録されないため、取得には設定と追加料金が必要です*3。自社の重要データについて、調査時に確認したい操作が記録に残るかを点検し、顧客データを保管する領域であれば、誰が、いつ、どのデータへアクセスしたかを追える設定になっているかを確認します。大量のログを一律に増やすのではなく、守るべきデータと必要な調査項目を先に決めると、取得範囲や費用も検討しやすくなります。

また、アクセスがあったという事実だけで、不正利用とは断定できません。AWSのGuardDutyの対応ガイドも、検知に関係するユーザーやロール、API操作を特定し、操作時刻や接続元IPアドレスを含めて正当な利用か確認するよう案内しています*4。担当者がこれらを照合できる情報と連絡先を持つことが、アラートを判断につなげる前提になります。

検知後は、どの認証情報の利用を止めるか判断する

認証情報の不正利用が疑われる場面では、影響するユーザーやロールと、その権限を特定する必要があります。API操作の内容を見れば、正常な処理との違いや調査すべき範囲を検討できます。確認の結果、正当な利用と判断できない場合は、該当するクラウドサービスの手順に沿って封じ込めを進めます。

ここで注意したいのが、すでに発行された一時的な認証情報の扱いです。AWSは、不正利用を止める手段として、一時的な認証情報に付与される権限の変更や、IAMロールの既存セッションの取り消し方法を説明しています*5。対象のロールを利用する正常なユーザーにも影響する場合があり、どの利用を止めるかを区別することが必要です。

緊急時の手順には、実行する操作だけでなく、その操作で停止する業務と、判断を行う担当者も記載しておきます。「認証情報を無効にする」とだけ書かれた手順を、自社のアカウントやサービスに当てはめて確認する作業です。担当部門が異なる場合も、現場で判断できる範囲をあらかじめ合意しておくことが、連絡待ちを減らすための実務的な準備になります。

図2：認証情報の悪用に備える監視と初動対応

出典：AWS「Remediating potentially compromised AWS credentials」（https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html）「Disabling permissions for temporary security credentials」（https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html）「SEC10-BP07 Run simulations」（https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_run_game_days.html）を基に弊社作成

「対応できるはず」を訓練で確かめる

検知から対応までの時間を短くしたいなら、まず自社の手順を一度動かして確かめることです。AWSのWell-Architected Frameworkでは、インシデント対応能力を評価する方法として演習を挙げ、机上演習では関係者の役割や責任、連絡手段、手順書を確認できると説明しています。*6

例えば「夜間に、通常と異なる認証情報の利用が通知された」という場面を設定し、担当者に連絡が届くか、正当な作業かを確認できるか、アクセス制限を誰が判断するかを話し合います。これは本稿で提案する訓練の例です。連絡先の更新漏れや判断権限の曖昧さが見つかれば、実際のインシデントが起こる前に修正できます。

演習では、通知を確認した時点、調査を始めた時点、対応を決めた時点を分けて記録すると、改善すべき箇所を具体化できます。約3時間という他社事例をそのまま自社の目標時間にするのではなく、自社の重要業務と運用体制に即して、対応を遅らせる要因を取り除くことが大切です。

監視からインシデント対応まで、セキュリティ体制を見直したい企業へ

こうした体制を自社だけで維持することが難しい場合は、監視や分析、対応を専門家と分担する方法があります。ブロードバンドセキュリティ（BBSec）の「G-MDR®」では、セキュリティ対策を統合的に監視・相関分析し、専門エンジニアが24時間365日体制で監視・運用を支援します。アラートの検知だけでなく、その後の調査や対応を含めたセキュリティ体制についてもご相談いただけます。

G-MDR® について詳しく見る

※外部サイトにリンクします。

セキュリティ対策について相談する

「アラートは検知できても、その後の調査や対応に不安がある」「24時間365日の監視体制を整えたい」といった課題がある場合は、BBSecまでお気軽にご相談ください。

導入を検討する際は、自社のクラウド環境や既存製品から連携できるログ、検知後に実行する対応、社内の承認が必要な操作を具体的に相談するとよいでしょう。すべてのクラウドサービスや復旧作業が無条件に対象になると考えず、自社に必要な監視範囲と対応範囲を確認することが大切です。

【参考情報】

編集責任：木下

ウェビナー開催のお知らせ

最新情報はこちら

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

DDoS攻撃を受けたらどうする？―初動対応から復旧までの流れを解説―

Share
DDoS攻撃を受けたらどうする？アイキャッチ画像

DDoS攻撃では、事前の対策だけでなく、攻撃を受けた際の迅速な初動対応が重要です。対応が遅れると、サービス停止だけでなく、売上機会の損失や顧客対応の混乱につながるおそれがあります。本記事では、DDoS攻撃を受けた場合の初動対応から、ISP・クラウド事業者との連携、復旧、再発防止までの流れを解説します。

DDoS攻撃の基本的な仕組みや種類、被害、対策については、「DDoS攻撃とは？仕組み・被害・対策を企業向けに解説」もあわせてご覧ください。

DDoS攻撃を受けたときに想定される影響

DDoS攻撃を受けると、大量の通信やリクエストによってWebサイトやサービスの応答が遅延し、場合によっては利用できなくなります。影響はサービス停止だけでなく、決済・予約・受発注などの業務停止、顧客・取引先からの問い合わせ増加などにも及ぶ可能性があります。

また、DDoS攻撃による混乱に乗じて、不正アクセスや情報窃取など別の攻撃が行われる可能性も考慮する必要があります。そのため、単なる通信障害と判断せず、セキュリティインシデントとして状況を確認することが重要です。DoS攻撃が単一または少数の攻撃元から行われるのに対し、DDoS攻撃は多数の端末などを悪用して分散的に行われるため、攻撃元の特定や単純な遮断が難しくなります。

DoS攻撃とDDoS攻撃の仕組みや違いについて詳しくは、「DoS攻撃とDDoS攻撃の違いとは 仕組み・被害・対策を比較解説」をご覧ください。

DDoS攻撃を受けたときの対応の流れ

DDoS攻撃が疑われる場合、場当たり的に設定変更や機器の再起動を行うのではなく、状況を確認しながら段階的に対応することが重要です。基本的な流れは、次のとおりです。

実際の対応方法は、攻撃の種類や規模、システム構成、利用しているクラウド・ネットワークサービスなどによって異なります。重要なのは、技術担当者だけで対応を完結させようとせず、必要に応じて社内外の関係者と連携できる体制を整えることです。

初動対応で最初に行うべきこと

DDoS攻撃を受けた場合、最初に必要なのは、慌てて機器の再起動や設定変更を行うことではありません。まず、発生している事象がDDoS攻撃によるものなのか、通常のアクセス増加やシステム障害なのかを切り分ける必要があります。初初動対応では、攻撃の有無を確認し、被害範囲を把握し、関係者へ連絡するとともに、可能な範囲でログなどの証跡を保全します。

攻撃発生を確認する

最初に、どのような異常が発生しているかを確認します。Webサイトの応答遅延、タイムアウト、サーバーエラー、CPUやメモリ使用率の急上昇、ネットワーク帯域の逼迫、特定URLへのリクエスト集中などが確認ポイントになります。

アクセス解析、サーバーログ、WAFログ、ロードバランサーのメトリクス、クラウド監視サービス、ネットワーク機器のトラフィック情報を確認し、通常時と比べて異常な増加がないかを調べます。平時のトラフィック量やピーク時の傾向を把握していれば、DDoS攻撃なのか、キャンペーンやニュース掲載などによる正規アクセスの増加なのかを判断しやすくなります。

ただし、DDoS攻撃は必ずしも大量通信だけとは限りません。アプリケーション層を狙う攻撃では、一見すると通常のHTTPリクエストに見える通信が集中し、検索機能、ログイン画面、APIなど特定の処理に負荷がかかることがあります。そのため、通信量だけでなく、アクセス先、リクエスト頻度、送信元の分布、レスポンスコードの変化なども確認します。

被害範囲を把握する

次に、どのサービスが影響を受けているかを把握します。コーポレートサイトだけなのか、ECサイトや会員サイトも影響を受けているのか、社内ネットワークや業務システムにも影響があるのかを整理します。被害範囲を確認する際は、外部からの疎通確認だけでなく、社内からの接続状況、監視アラート、問い合わせ件数、取引先からの連絡内容なども確認します。攻撃対象が特定のドメイン、IPアドレス、ポート、URL、APIなどに集中していることがわかれば、後続のトラフィック制御やCDN・WAF設定の調整にも役立ちます。

また、DDoS攻撃による負荷によってログ出力や監視自体が遅延している可能性もあります。一つの監視画面だけで判断せず、複数の情報源を突き合わせて状況を確認することが重要です。

関係者へ連絡する

DDoS攻撃の可能性がある場合は、社内の関係者へ速やかに連絡します。情報システム部門、セキュリティ担当、ネットワーク担当、Webサイト運用担当、カスタマーサポート、広報、法務、経営層など、影響範囲に応じて必要な関係者へ情報を共有します。サービス停止が顧客や取引先に影響する場合は、技術的な復旧だけでなく、問い合わせ対応や外部への説明も必要になります。復旧の見通しが立っていない段階でも、「現在確認している事象」「影響を受けているサービス」「現在実施している対応」などを社内で共有しておくことで、対応の混乱を抑えられます。あわせて、契約しているISP、クラウド事業者、CDN、WAF、セキュリティ監視サービス、運用保守ベンダーへの連絡準備も進めます。

ログを保全する

DDoS攻撃への対応では、復旧作業と並行して、可能な範囲でログなどの証跡を保全することも重要です。負荷軽減を優先する過程で設定を変更したり、ログローテーションによって過去のログが上書きされたりすると、後から攻撃状況を確認できなくなる可能性があります。保全対象としては、Webサーバーログ、WAFログ、ロードバランサーログ、DNSログ、ファイアウォールログ、クラウド監視メトリクス、ネットワーク機器のトラフィック情報、アラート履歴などが考えられます。

これらの情報は、攻撃の種類や影響範囲を分析するだけでなく、DDoS攻撃の前後に不正アクセスなど別の事象が発生していなかったかを確認する際にも役立ちます。

ISP・クラウド事業者と連携する

DDoS攻撃への対応では、自社だけで完結しようとしないことが重要です。攻撃トラフィックが自社回線に到達してから遮断しようとしても、すでに回線帯域が逼迫していれば、正規利用者の通信も届かなくなる可能性があります。そのため、攻撃の種類や規模に応じて、ISP、クラウド事業者、CDN、DDoS対策サービスなどと連携し、上流側でトラフィックを制御することが重要になります。

ISPへの連絡

オンプレミス環境や自社回線でサービスを公開している場合、ISPへの連絡が必要になることがあります。自社のファイアウォールで遮断する前に回線が逼迫している場合には、上流側でのフィルタリングや経路制御などの対応が必要になる可能性があるためです。

ISPへ連絡する際は、攻撃を受けているグローバルIPアドレス、影響を受けているサービス、発生時刻、観測している通信量、主なプロトコルやポート、送信元の傾向、現在発生している障害内容を整理して伝えます。また、契約内容によっては、DDoS緩和サービスや緊急時のトラフィック制御オプションが提供されている場合があります。攻撃が発生してから確認するのではなく、平時から連絡窓口、受付時間、必要情報、対応範囲などを把握しておくことが望まれます。

CDN・WAFの活用

WebサイトやWebアプリケーションを公開している場合、CDNやWAFを活用して攻撃トラフィックを緩和できる場合があります。CDNはアクセスを分散し、オリジンサーバーへの負荷を軽減するために利用できます。WAFでは、HTTPリクエストの特徴やアクセス頻度などに応じて、不審なアクセスを制御することが可能です。ただし、CDNやWAFを導入しているだけで、すべてのDDoS攻撃を防げるわけではありません。DNSが適切にCDN経由になっているか、オリジンサーバーへ直接アクセスできる状態になっていないか、必要な防御機能が有効になっているかなどを確認する必要があります。

攻撃中にアクセス制御を強化する場合は、正規利用者まで遮断してしまう可能性にも注意が必要です。ログやトラフィックの状況を確認しながら、段階的に調整します。

クラウド事業者との連携

クラウド環境でサービスを運用している場合は、利用しているクラウド事業者が提供するDDoS対策機能やサポートサービスを確認します。主要なクラウド事業者では、ネットワークレベルのDDoS対策機能や、契約内容に応じたサポートが提供されています。攻撃発生時に支援を受けられるよう、対象リソース、攻撃状況、アプリケーションの正常性、WAFやロードバランサーのログなどを共有できる状態にしておくことが重要です。また、クラウド環境ではスケールアウトによって一時的に処理能力を増やせる場合がありますが、攻撃トラフィックに応じてリソースを増やし続ければ、利用料金が増大する可能性があります。CDN、WAF、ロードバランサー、オートスケーリング、DDoS対策機能などを組み合わせて対応することが重要です。

復旧時に確認すべきポイント

DDoS攻撃の通信量が減少し、Webサイトやサービスが再び利用できるようになっても、すぐに「復旧完了」と判断するのは危険です。攻撃が一時的に弱まっている可能性や、緊急対応として行った設定変更がサービスに影響している可能性があります。また、DDoS攻撃と同時に別の攻撃が行われていなかったかも確認する必要があります。

サービスが正常に利用できるか

Webサイトへアクセスできることだけでなく、ログイン、検索、決済、予約、API連携など、主要な機能が正常に動作しているかを確認します。サーバーやネットワーク機器のCPU・メモリ・帯域使用率、エラー発生状況なども確認し、通常時に近い状態へ戻っているかを確認します。また、攻撃が再開する可能性も考慮し、一定期間はトラフィックやアラートを継続して監視することが重要です。

二次被害が発生していないか

DDoS攻撃への対応中は、大量のアラートやサービス障害への対応に注意が集中します。そのため、同じ時間帯に不審なログインや脆弱性を狙ったアクセスなど、別の不審な事象が発生していなかったかを確認します。WAF、認証、サーバー、ネットワーク機器、EDRなどのログを確認し、通常とは異なる挙動が確認された場合は、必要に応じて追加調査を行います。

一時的に変更した設定がないか

DDoS攻撃への緊急対応として、IPアドレスや地域によるアクセス制限、WAFルールの変更、レート制限などを実施することがあります。こうした設定を残したままにすると、正規利用者のアクセスや業務に影響する可能性があります。攻撃収束後は、変更した設定とその目的を確認し、継続すべき設定と元に戻す設定を整理します。

顧客や取引先への説明

サービス停止などによって顧客や取引先に影響が発生した場合は、必要に応じて障害の発生時刻、影響範囲、復旧状況などを説明します。この段階では、確認できていない原因や被害を断定しないことも重要です。技術部門だけで判断せず、広報、法務、顧客対応部門などと連携して説明内容を整理します。

再発防止に向けて見直すべきこと

サービスを復旧させた後は、今回の攻撃と対応内容を振り返り、次の攻撃に備えます。DDoS攻撃を完全に防ぐことは難しいため、「攻撃を受けないこと」だけではなく、「受けても影響を抑え、早期に復旧できること」が重要です。

攻撃ログやトラフィックの分析

保全したログやトラフィック情報を確認し、攻撃がいつ始まり、どのサービスが狙われ、どのような通信が発生していたのかを整理します。あわせて、検知から関係者への連絡、緩和策の実施、サービス復旧までにどの程度の時間を要したかを振り返ることで、対応上の課題を把握できます。

ネットワーク構成の見直し

まず見直すべきは、ネットワーク構成です。公開サービスが単一の回線や単一拠点に依存していないか、CDNやAnycastを活用できる構成になっているか、オリジンサーバーが直接攻撃を受けやすい状態になっていないかを確認します。また、Webサイト、API、管理画面、社内業務システムなどが同じネットワークに過度に依存している場合、一つの攻撃による影響が複数のサービスや業務へ波及する可能性があります。公開系と管理系の分離や、DNS構成なども含め、攻撃を受けた際に影響が広がりにくい構成になっているかを確認することが重要です。

DDoS攻撃では、回線帯域、ネットワーク機器、DNS、Webアプリケーション、APIなど、攻撃の種類によって影響を受ける箇所が異なります。今回の攻撃でどこがボトルネックになったのかを確認し、その結果をネットワーク構成の見直しに反映することが、次の攻撃による影響を抑えることにつながります。

DDoS対策サービスの導入・見直し

次に、DDoS対策サービスの導入や見直しを検討します。CDN、WAF、DDoSスクラビング、クラウド事業者のDDoS保護機能、ISPのDDoS緩和サービスなど、選択肢は複数あります。重要なのは、自社のサービス特性に合った対策を選ぶことです。静的コンテンツが多いサイトであればCDNによるキャッシュが有効な場合があります。ログインや検索、予約、決済など動的処理が多いサービスでは、WAFやレート制限、アプリケーション層の監視が重要になります。大規模な帯域攻撃が想定される場合は、上流側でのDDoS緩和やスクラビングを検討する必要があります。

また、対策サービスは導入して終わりではありません。緊急時の連絡窓口、対応開始条件、保護対象のIPアドレスやドメイン、ログの取得方法、誤検知時の解除手順、費用条件を事前に確認しておく必要があります。攻撃発生時に初めて管理画面を開く状態では、十分な対応ができないおそれがあります。

DDoS攻撃に備えて平時から準備しておくこと

DDoS攻撃が発生してから対策や連絡体制を検討していては、初動が遅れるおそれがあります。攻撃による影響を抑え、迅速に対応・復旧するためには、ネットワーク構成やDDoS対策サービス、インシデント対応手順などを平時から確認し、実際の攻撃を想定した訓練を行っておくことが重要です。

インシデント対応手順の見直し

対応手順には、攻撃発生時の確認項目、社内連絡先、外部事業者の連絡先、判断権限、ログ保全方法、顧客告知の流れ、復旧判断基準を含めます。特にDDoS攻撃では、技術部門だけでなく、カスタマーサポート、広報、営業、法務、経営層との連携が必要になるため、役割分担を明確にしておくことが重要です。

また、インシデント対応手順は一度作成しただけでは十分ではありません。サービス構成の変更、クラウドへの移行、新しいWAFやCDNの導入、担当者の異動、外部ベンダーの変更などがあれば、それにあわせて手順も更新する必要があります。古い連絡先や現在は利用していないシステム名などが残っていないか、定期的に確認しておきましょう。

DDoS攻撃を含むセキュリティインシデントでは、事前に対応手順を整備しておくことが重要です。関連記事「セキュリティインシデントとは？基礎知識と代表的な事例を解説」もあわせてご覧ください。

訓練の実施

DDoS攻撃への対応力を高めるには、訓練の実施が有効です。実際の攻撃時には、監視アラート、問い合わせ、社内報告、外部事業者との連絡が同時に発生します。手順書を読むだけでは、こうした混乱の中で適切に動けるかは分かりません。

訓練では、「Webサイトの応答が急激に悪化した」「特定APIに大量アクセスが集中している」「ISPから異常トラフィックの連絡があった」など、具体的なシナリオを用意します。そのうえで、誰が最初に状況を確認するのか、どの情報を集めるのか、誰がISPやクラウド事業者へ連絡するのか、どの段階で顧客告知を検討するのかを確認します。

訓練後は、手順の不備や連絡体制の弱点を洗い出し、改善します。DDoS攻撃の対応では、攻撃を完全に止めることだけでなく、被害を限定し、事業への影響を抑え、利用者に適切に説明することが重要です。そのためには、平時からの準備と訓練が欠かせません。

まとめ

DDoS攻撃を受けた場合は、単にサーバーを復旧させるだけでなく、攻撃状況の確認、影響範囲の把握、関係者への連絡、ISP・クラウド事業者などとの連携を並行して進める必要があります。また、通信量が減少したからといって、すぐに対応を終了するのではなく、サービスが正常に利用できることや、DDoS攻撃の前後に別の不審な事象が発生していないことを確認することも重要です。

DDoS攻撃を完全に防ぐことは困難ですが、平時から連絡体制やログ取得、外部事業者との連携方法を整理しておくことで、攻撃発生時の混乱を抑え、サービスへの影響を最小限にすることができます。

【参考情報】

編集責任：木下

資料ダウンロードボタン
年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
お問い合わせボタン
サービスに関する疑問や質問はこちらからお気軽にお問合せください。
Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

サイバー攻撃に備えるサプライチェーンBCPとは？委託先管理の見直しポイントを解説

Share
サイバー攻撃に備えるサプライチェーンBCPとは？アイキャッチ画像

製造業では、委託先や部品メーカーへのサイバー攻撃が、自社の生産停止や納期遅延につながる可能性があります。本記事では、サイバー攻撃を事業継続リスクとして捉え、サプライチェーンBCPと委託先管理で確認すべきポイントを解説します。

ランサムウェアによる情報漏洩や供給への影響については、「ランサムウェアの二重恐喝とは？製造業サプライチェーンに与える影響を解説」もあわせてご覧ください。

サプライチェーンBCPにサイバー攻撃を含めるべき理由

BCPとは、災害や事故などの緊急事態が発生した際にも、重要な事業を継続・早期復旧するための計画です。従来のBCPでは、地震、台風、火災、感染症、物流停止などが主な想定リスクとされてきました。しかし、製造業においては、サイバー攻撃も同じように事業を止める要因になり得ます。

たとえば、製造委託先がランサムウェア攻撃を受けた場合、生産管理システムや受発注システムが停止し、製品の出荷や納品が遅れる可能性があります。また、部品メーカーが攻撃を受ければ、必要な部材が届かず、自社の生産計画にも影響が及びます。物流会社や保守会社が停止した場合も、製品の配送や設備対応に支障が出ることがあります。さらに、サイバー攻撃では業務停止だけでなく、情報漏洩も同時に発生する可能性があります。設計情報、部品表、製造工程、顧客情報、取引条件などが流出すれば、復旧後も知的財産の保護、契約対応、顧客説明、信用回復が必要になります。

このように、サイバー攻撃は単なるIT障害ではなく、調達、生産、物流、販売、法務、広報を巻き込む事業継続リスクです。サプライチェーンBCPでは、委託先や取引先のサイバー被害を想定するとともに、「どの委託先が停止すると、どの事業・製品・工程に影響するのか」を把握し、事業への影響が大きい委託先から優先して対策を検討することが重要です。

製造業のサプライチェーンが狙われる背景や、製造委託先への攻撃が取引先へ及ぼす影響については、「Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策」で詳しく解説しています。

委託先管理で確認すべきポイント

サイバー攻撃に備えるためには、すべての委託先を一律に管理するのではなく、自社の事業への影響度に応じて優先順位をつけることが重要です。委託している業務の重要度、取り扱う情報、システムへのアクセス範囲、代替の可否などを確認し、停止や情報漏洩が発生した場合の影響が大きい委託先から優先して対策状況を確認します。

委託先のセキュリティ対策を確認する

重要な委託先については、契約時だけでなく、取引継続中もセキュリティ対策の状況を定期的に確認することが重要です。EDRやウイルス対策の導入状況、脆弱性管理、OSやソフトウェアの更新、多要素認証、ログ監視、バックアップなどを確認します。アンケートによる自己申告だけでなく、必要に応じて監査や証跡の確認などを行い、実際の対策状況を確認することも有効です。

共有する情報を必要最小限にする

委託先に提供している設計データ、部品表、仕様書、検査手順、顧客情報などが、本当に業務上必要な範囲に限定されているかを確認します。必要以上の情報を共有していると、委託先がサイバー攻撃を受けた際に、情報漏洩の影響範囲が広がる可能性があります。委託する業務に応じて、共有する情報や保存期間を見直すことが重要です。

アクセス権限を適切に管理する

委託先に自社のシステムやクラウドサービスへのアクセスを許可している場合は、必要最小限の権限になっているかを確認します。プロジェクト単位、顧客単位、工程単位などで権限を分けることで、アカウントが侵害された場合の影響を限定しやすくなります。また、共有フォルダやクラウドストレージに過剰な権限が付与されていないか、退職者や異動者のアカウント等が残っていないかを定期的に確認し、担当者変更の際には速やかにアクセス権限を見直すことも重要です。

再委託先まで把握する

委託先がさらに別の企業へ業務を委託している場合、自社の情報や業務がどこまで広がっているのか把握できていないことがあります。再委託の可否や条件、再委託先に求めるセキュリティ対策、情報の取り扱い範囲などをあらかじめ定め、重要な業務については再委託先を含めたサプライチェーンを把握しておくことが重要です。

インシデント発生時に備えた契約・体制の見直し

委託先がサイバー攻撃を受けた場合に備え、契約や対応体制を事前に整えておくことも重要です。インシデントが発生してから対応範囲を確認していては、初動が遅れ、被害の把握や顧客対応に支障が出る可能性があります。

まず契約面では、インシデント発生時の通知期限を明確にしておく必要があります。インシデントを認識した場合の通知時期、通知先、共有すべき情報をあらかじめ定めておくことが望まれます。また必要に応じて「認識後○時間以内」など具体的な通知期限を契約上定めることも検討します。さらに調査協力や証拠保全に関する条項も重要です。ログ、通信記録、端末情報、アクセス履歴などの証拠が適切に保全されなければ、被害範囲や原因の特定が難しくなります。外部専門家によるフォレンジック調査を行う場合の協力範囲も、事前に整理しておくべきです。

そして、情報漏洩が発生した場合の責任範囲、法令等に基づく報告、顧客・取引先への説明、損害対応についても確認が必要です。特に製造業では、設計情報や部品情報の流出が競争力や取引関係に影響するため、単なる個人情報漏洩とは異なる観点で対応を考える必要があります。

体制面では、委託先の停止を想定した代替策を準備しておくことが重要です。代替生産先、代替部品、在庫確保、出荷優先順位、顧客への連絡手順、重要データの社内保全などを事前に整理しておくことで、サイバー攻撃発生時の混乱を抑えることができます。サプライチェーンBCPは、計画を作成して終わりではありません。定期的に訓練を行い、委託先や関係部門を含めて、実際に機能するかを確認することが重要です。

まとめ

サプライチェーンのサイバーリスク対策では、委託先のセキュリティ対策を確認するだけでなく、「どの委託先が停止すると自社の事業に影響するのか」を把握することが重要です。重要度に応じて対策状況や契約、インシデント時の連携方法を確認し、代替策や復旧手順をBCPに組み込んでおく必要があります。サイバー攻撃による停止を前提として、委託先や関係部門を含めた訓練と見直しを継続することが、サプライチェーン全体のレジリエンス向上につながります。

参考情報

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

ランサムウェアの二重恐喝とは？製造業サプライチェーンに与える影響を解説

Share
ランサムウェアの二重恐喝とは？製造業サプライチェーンに与える影響を解説アイキャッチ画像

ランサムウェア攻撃では、データを暗号化するだけでなく、窃取した情報の公開をちらつかせる「二重恐喝」が大きな脅威となっています。本記事では、製造業のサプライチェーンに及ぶ影響と企業が備えるべき対策を解説します。

製造委託先への攻撃リスクについては、前回記事「Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策」もあわせてご覧ください。

ランサムウェアの二重恐喝とは

二重恐喝とは、攻撃者が企業のデータを暗号化するだけでなく、事前に重要データを窃取し、「身代金を支払わなければ公開する」と脅す攻撃手法です。企業がバックアップからシステムを復旧できる場合でも、窃取されたデータの公開リスクが残るため、攻撃者にとって強い圧力材料になります。

この手口では、まずフィッシングメール、脆弱性の悪用、認証情報の窃取、リモートアクセス環境の不正利用などを通じて社内ネットワークに侵入します。その後、社内のファイルサーバ、共有フォルダ、業務システムなどを探索し、重要情報を外部へ持ち出します。最後にシステムやファイルを暗号化し、復号や窃取データの非公開と引き換えに金銭を要求します。

従来のランサムウェア対策では、バックアップを取得していれば復旧できる可能性がありました。しかし、二重恐喝では「復旧できるか」だけではなく、「漏洩した情報をどう扱うか」が大きな問題になります。特に顧客情報、取引先情報、設計情報、契約情報などが含まれる場合、情報の内容や影響範囲によっては、法令等に基づく報告や、顧客・取引先への説明、法務・広報対応などが必要になることがあります。つまり、二重恐喝は単なるIT障害ではなく、情報管理、法務、広報、経営判断を巻き込む重大インシデントです。

製造業で二重恐喝の影響が大きくなりやすい理由

製造業では、情報漏洩と業務停止の影響が同時に発生しやすい点に注意が必要です。製造現場では、生産管理システム、在庫管理、受発注システム、設計データ共有基盤、品質管理システムなど、多くのシステムが業務に直結しています。これらが暗号化や停止の影響を受けると、生産ラインの停止、納期遅延、在庫不足、出荷停止につながる可能性があります。

さらに、製造業が扱う情報には、競争力に直結するものが多く含まれます。設計図、部品表、製造工程、検査手順、試作品情報、原価情報、調達先情報などが流出した場合、模倣品の製造、価格競争力の低下、技術ノウハウの不正利用といったリスクが生じます。

製造業のサプライチェーンでは、製造委託先や部品メーカーとの間で、設計データ、仕様書、受発注情報などを共有するケースがあります。そのため、攻撃を受けた企業自身の情報だけでなく、委託元や取引先から預かっている情報まで窃取される可能性があります。自社が直接攻撃を受けていなくても、取引先への攻撃を起点として情報漏洩や供給停止の影響を受ける点が、サプライチェーンにおける二重恐喝の大きなリスクです。

また、製造業はサプライチェーンが複雑であり、一社の停止が複数の企業に波及しやすい特徴があります。製造委託先、部品メーカー、物流会社、保守会社、販売会社などが連携しているため、どこか一社がランサムウェア被害を受けると、関連企業にも納期調整や代替手配、顧客説明などの負担が発生します。さらに操業停止による事業への影響に加えて、設計情報や取引先情報などの漏洩リスクも生じます。そのため二重恐喝を受けた場合、システム復旧、情報漏洩への対応、取引先への説明などを同時に迫られる可能性があります。製造業では二重恐喝を、サプライチェーン全体の事業継続リスクとして捉える必要があります。

二重恐喝への対策として企業が確認すべきこと

二重恐喝への対策では、暗号化への備えと情報漏洩への備えを分けて考えることが重要です。まず、暗号化への備えとして、バックアップの取得と復旧手順の確認が欠かせません。バックアップは定期的に取得するだけでなく、攻撃者に同時に暗号化・削除されないよう、オフライン保管や改ざん耐性のある仕組みを検討する必要があります。

次に、情報漏洩への備えとして、重要データの所在を把握し、アクセス権限を必要最小限にすることが重要です。設計情報や顧客情報などの重要データに誰がアクセスできるのか、どのシステムに保存されているのかを整理し、不要な共有や過剰な権限を見直します。

また、DLP（Data Loss Prevention：情報漏洩防止）やログ監視を活用し、大量ダウンロード、不審な外部送信、通常と異なるアクセスを検知できる体制を整えることも有効です。EDRや脆弱性管理、メール対策、多要素認証などにより、侵入そのものを防ぐ取り組みも必要です。さらに、インシデント発生時には、IT部門だけでなく、法務、広報、経営層、事業部門が連携して対応する必要があります。情報漏洩の可能性がある場合、顧客や取引先への説明、監督官庁への報告、証拠保全、外部専門家との連携が求められます。

製造業では被害が生産や供給に波及する可能性があります。サイバー攻撃を想定した事業継続や委託先管理については、「サイバー攻撃に備えるサプライチェーンBCPとは？委託先管理の見直しポイントを解説」で詳しく解説します。

まとめ

ランサムウェアの二重恐喝は、システムの暗号化だけでなく、窃取データの公開を材料に企業へ圧力をかける攻撃手法です。バックアップによってシステムを復旧できたとしても、情報漏洩のリスクは残るため、企業にはより広範な対応が求められます。特に製造業では、設計情報、部品表、製造工程、調達情報など、競争力や事業継続に直結する情報を多く扱います。ランサムウェア攻撃を受けた場合、情報漏洩、操業停止、供給遅延、取引先対応が同時に発生する可能性があります。企業は、バックアップだけでなく、重要データへのアクセス管理、データ持ち出しの監視、EDR、脆弱性管理、多要素認証などを組み合わせ、暗号化と情報漏洩の双方に備える必要があります。

さらに製造業では、取引先や委託先を含めた事業継続の観点も欠かせません。次回は、サイバー攻撃を前提としたサプライチェーンBCPと委託先管理について解説します。

参考情報

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策

Share
「Foxconnへのサイバー攻撃とは？製造委託先が狙われる理由とサプライチェーン対策」アイキャッチ画像

2026年5月、電子機器の製造受託大手Foxconnの北米拠点がサイバー攻撃を受け、攻撃者は約8TBのデータを窃取したと主張しました。製造委託先には複数企業の設計・製造情報が集まるため、侵害の影響が取引先へ広がるおそれがあります。本記事では、製造委託先が狙われる理由と、企業が取るべきサプライチェーン対策を解説します。

Foxconnへのサイバー攻撃で何が起きたのか

2026年5月、電子機器の製造受託大手Foxconnは、北米の一部拠点がサイバー攻撃を受けたことを明らかにしました。Foxconnによると、影響を受けた工場では復旧対応が進められ、通常の生産体制へ段階的に戻っているとされています。

この攻撃について、ランサムウェア攻撃グループ「Nitrogen」は、約8TB、1,100万件を超えるファイルを窃取したと主張しました。窃取した情報には、Apple、Intel、Google、Dell、Nvidia、AMDなどの顧客企業に関係する情報が含まれるとも主張しています。

ただし、データ窃取の規模や内容、顧客企業に関する情報が実際に含まれていたかについて、Foxconnは詳細を公表していません。そのため、攻撃者側の主張とFoxconnが確認・公表している事実は分けて捉える必要があります。

なぜ製造委託先はサイバー攻撃の標的になりやすいのか

製造委託先が狙われやすい理由の一つは、発注元企業との間に多くの情報連携が発生するためです。製造委託企業には、設計図、部品表、製品仕様、検査手順、試作品情報、調達計画など、製品開発や量産に必要な情報が集約されることがあります。

攻撃者から見ると、こうした企業を侵害することで、発注元企業へ直接侵入しなくても、重要情報に近づける可能性があります。特に大企業はセキュリティ対策が強化されている一方で、委託先や再委託先まで同じ水準で管理されているとは限りません。攻撃者はこの「守りの差」を狙い、比較的侵入しやすい取引先を足がかりにすることがあります。

また、製造業では受発注システム、設計データ共有基盤、生産管理システム、保守対応の連絡経路など、複数企業をまたぐ業務連携が多く存在します。こうした接点が適切に管理されていない場合、侵害された委託先から関連企業へ芋づる式に影響が広がる可能性があります。

つまり、製造委託先は単なる外部企業ではなく、発注元企業の事業継続や情報保護に直結するサプライチェーンの一部として考える必要があります。

Foxconnでは過去にも被害が発生

なお、Foxconnとその関連企業では今回が初めての被害ではなく、過去にもサイバー攻撃による被害が報じられています。

2020年はDoppelPaymerによる攻撃、2022年には別のメキシコ拠点がLockBitの標的となりました。また2024年には子会社のFoxsemiconも攻撃を受けています。

世界各地に拠点や子会社を持つ企業では、組織全体で統一した対策を進めていても、拠点や関連会社によってセキュリティ対策や運用の水準に差が生じることがあります。攻撃者は、こうしたサプライチェーンやグループ企業内の接点を狙う可能性があります。

製造委託先の侵害がもたらす主なリスク

製造委託先が侵害された場合、影響は委託先単独の問題に留まりません。まず懸念されるのは、顧客企業に関係する情報の漏洩です。実際にFoxconnの事例では、攻撃者側が顧客企業の機密情報の窃取を主張しており(Foxconn側は詳細未公表)、こうした主張の真偽が確認される前から報道が先行する点も、企業にとって風評面のリスクとなり得ます。

設計情報や部品表、製造手順、製品仕様などが流出すれば、知的財産の漏洩、模倣品の製造、競争力の低下につながるおそれがあります。

また、製品やシステムの構成情報が外部に出ることで、攻撃者が弱点を分析しやすくなる可能性もあります。たとえば、使用している部品、ソフトウェア、通信仕様、検査工程などの情報が悪用されれば、将来的な攻撃の足がかりになることも考えられます。

さらに、ランサムウェア攻撃では、工場の操業停止や生産ラインの停止も大きなリスクです。製造委託先の業務が止まれば、発注元企業にとっても納期遅延、欠品、代替生産の調整、顧客説明などの対応が必要になります。

近年のランサムウェア攻撃では、システムを暗号化するだけでなく、事前にデータを窃取したうえで公開をちらつかせる「二重恐喝」も多く確認されています。そのため、バックアップからシステムを復旧できたとしても、窃取された情報の公開リスクが残ります。

ランサムウェアの二重恐喝の仕組みや、製造業のサプライチェーンに与える影響については、こちらの記事で詳しく解説しています。
「ランサムウェアの二重恐喝とは？製造業サプライチェーンに与える影響を解説」

製造委託先の侵害は、情報漏洩、知財リスク、操業停止、供給遅延、信用低下が同時に発生し得る、サプライチェーン全体のリスクとして捉えるべきです。

企業が取るべき対策

企業は、製造委託先を「外部の別会社」として扱うだけではなく、自社のサプライチェーンの一部として管理することが重要です。

委託先と共有する情報を最小限にする

まず実施すべきことは、委託先に渡す情報を必要最小限にすることです。設計データ、部品表、製造手順などの重要情報は、必要な範囲、期間、担当者に限定して共有する必要があります。

アクセス権限を分離する

次に、アクセス権限をプロジェクト単位で分離することが有効です。すべての担当者が広範な情報にアクセスできる状態では、侵害時の被害が拡大しやすくなります。プロジェクトごと、顧客ごと、工程ごとにアクセス範囲を分けることで、万一の侵害時にも影響範囲を抑えやすくなります。

委託先の対策状況を定期的に確認する

委託先のセキュリティ対策状況を定期的に確認することも重要です。ただし、すべての委託先に同じ水準の対策や監査を一律に求めるのではなく、委託する業務の重要度や、共有する情報の機密性に応じて確認内容を設定する必要があります。

たとえば、設計情報や顧客情報を扱う委託先、業務停止時に自社の生産や供給へ大きな影響を及ぼす委託先については、ランサムウェア対策、EDRなどの端末監視、バックアップ、ログ管理、脆弱性管理、インシデント対応体制を重点的に確認します。一方で、扱う情報や事業への影響が限定的な委託先については、確認項目を絞るなど、リスクに応じた管理が現実的です。

重要な委託先については、契約時の確認だけで終わらせず、取引期間中も定期的に対策状況を確認し、環境やリスクの変化に応じて見直すことが求められます。

情報漏洩とランサムウェアへの技術的対策を講じる

技術的な対策としては、DLPによるデータ持ち出し監視、アクセスログの分析、大量ダウンロードの検知、重要データの暗号化、バックアップの分離保管などが挙げられます。特にランサムウェア対策では、バックアップが攻撃者に同時に破壊・暗号化されないよう、オフライン保管や改ざん耐性のあるバックアップ設計を検討する必要があります。

契約と事業継続計画を整備する

契約面では、インシデント発生時の通知期限、調査協力、証拠保全、再委託先管理、損害範囲、データ削除義務を明確にしておくことが重要です。さらに、代替生産先、代替部品、重要データの社内保全を含め、サイバー攻撃を前提としたサプライチェーンBCPを整備する必要があります。

サイバー攻撃を想定したサプライチェーンBCPの考え方や、委託先管理で確認すべきポイントについては、こちらの記事で詳しく解説しています。
「サイバー攻撃に備えるサプライチェーンBCPとは？委託先管理の見直しポイントを解説」

まとめ

製造委託先は、複数の顧客企業に関わる設計情報や製造情報を扱うため、攻撃者にとって高価値な標的になり得ます。発注元企業のセキュリティ対策が強固であっても、委託先や再委託先に弱点があれば、そこを入口として情報漏洩や業務停止が発生する可能性があります。

製造業におけるサプライチェーンリスクは、自然災害や物流停止だけではありません。サイバー攻撃による情報漏洩、操業停止、供給遅延、二重恐喝も、事業継続に直結する重要なリスクです。 企業は、委託先への情報共有を最小限に抑え、アクセス権限を分離し、定期的なセキュリティ監査を行うことが求められます。加えて、契約面の見直しやサイバー攻撃を想定したBCPの整備を進めることで、サプライチェーン全体のレジリエンスを高めることが重要です。

【参考情報】（2026年8月時点）

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

サイバーインシデント緊急対応

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

最新情報はこちら

Security Serviceへのリンクバナー画像
BBsecコーポレートサイトへのリンクバナー画像
セキュリティ緊急対応のバナー画像

Security NEWS TOPに戻る
バックナンバー TOPに戻る

投稿日:

さくらのレンタルサーバ不正アクセスが示す「管理環境」のリスク―583アカウントに不正ログイン

Share
さくらのレンタルサーバで不正アクセスアイキャッチ画像

2026年8月17日、さくらインターネットは「さくらのレンタルサーバ」の一部顧客環境への不正アクセスを公表しました。本記事では、同社や公的機関の一次情報をもとに、判明している事実や情報漏えいの可能性、利用企業が確認すべき対策を解説します。

※本記事は2026年8月17日時点で確認できる公表資料に基づき作成しています。

さくらインターネットへの不正アクセスで何が起きたのか

さくらインターネットの発表によると、同社は2026年8月9日、管理するサーバ環境で異常を検知し、調査を開始しました*7。その後、第三者が同社の管理環境を経由して、「さくらのレンタルサーバ」の一部顧客環境へ不正アクセスしていたことが判明しました。8月9日は攻撃開始日ではなく、異常を検知した日です。

8月17日の公表時点で、不正ログインの対象は583アカウントです。第三者が顧客アカウントからアクセスできる領域まで到達していたほか、一部のサーバにはマルウェアが設置されていました。また、一部の顧客情報を含む個人データが、第三者に閲覧または取得された可能性があるとされています。漏えいした可能性がある情報として挙げられているのは、「顧客領域内に保存された情報」と「利用者識別子」です。ただし、具体的な情報項目、対象人数、実際に取得されたデータの範囲は調査中です。

同社は認証情報の失効、アクセス遮断、マルウェアの除去、監視強化、外部専門機関を交えたフォレンジック調査を進めています。あわせて、データベースアップグレード機能、プラン変更、移行ツールなどの一部機能を制限しています。現時点では「さくらのVPS」「さくらのクラウド」「さくらの専用サーバ PHY」「高火力 PHY」への影響は確認されていませんが、その他のサービスを含めた調査は継続中です。

注目すべきは『管理環境を経由』した点

一般的なWebサイトの不正アクセスでは、更新されていないCMSやプラグイン、弱いパスワードなど、顧客側の環境が侵入口になるケースがあります。しかし今回の発表は、第三者がさくらインターネットの管理環境を経由して顧客環境へアクセスしたと説明しています。「管理環境」が具体的にどのシステムを指すのか、最初の侵入に脆弱性や窃取された認証情報が使われたのかは公表されていません。そのため、特定の製品やWordPressの脆弱性、ゼロデイ攻撃などと結び付ける根拠はありません。それでも、サービス提供者側の管理環境を経由し、複数の顧客アカウントへ影響が及んだ点は重要です。

さくらインターネットのサポート情報によれば、「さくらのレンタルサーバ」は複数の利用者が1台のサーバを共有する共用サーバとして運営されています*2。共用ホスティングでは、利用企業が自社サイトを適切に管理していても、サービス提供者側の管理層で発生した問題の影響を完全にコントロールすることはできません。これは「レンタルサーバだから危険」という話ではありません。自社ですべてのサーバを運用する場合にも、別の脆弱性や運用リスクがあります。重要なのは、外部サービスへ運用を委ねることで負担は軽減できても、情報管理やインシデント対応まで外部へ丸投げできるわけではないという点です。なお、「さくらのレンタルサーバ」は共用サーバとして提供されていますが、今回の不正アクセスと共用サーバという構成との因果関係は公表されていません。

583アカウントは「583人分の情報漏えい」ではない

今回さくらインターネットから公表された「583」という数字は、情報漏えいが確認された人数ではなく、不正ログインが判明したアカウント数です。また、「被害申告が確認されていない」ことと「改ざんがなかったことが確認された」ことは区別して捉える必要があります。現段階では、不正ログインとマルウェアの設置は確認済みである一方、個々の顧客環境で何が閲覧、取得、変更されたのかを調べている途中だと捉えるのが適切でしょう。

「通信の秘密」に該当する情報とは

さくらインターネットは、攻撃者が顧客情報だけでなく、「通信の秘密」に該当する情報へアクセスできる状態にあったと説明しています。通信の秘密は、メール本文などの通信内容だけを意味するものではありません。

個人情報保護委員会と総務省の「電気通信事業における個人情報等の保護に関するガイドライン」では、通信当事者の住所や氏名、発受信場所、通信年月日、通信回数、通信の存在自体に関する情報も含まれるとされています。ただし、今回どの情報が実際に閲覧・取得されたのかは公表されておらず、具体的な影響範囲は調査中です。さくらインターネットは、総務省や個人情報保護委員会などの関係機関への報告・情報共有を行うとともに、影響の可能性がある顧客への個別通知を開始しています。

レンタルサーバの侵害が企業へ及ぼす影響

企業が利用するレンタルサーバには、WebサイトのHTMLファイルや画像だけが置かれているとは限りません。問い合わせフォームから取得した情報、会員データ、データベース、業務用メールなどが保存されている場合があります。アプリケーションの設定ファイルに、データベースや外部クラウドサービスへ接続するための認証情報が記録されているケースもあります。

さくらインターネットの公式マニュアルでは、サーバーコントロールパネルへ管理者権限でログインした場合、そのレンタルサーバで行えるすべての操作に加え、作成された全メールアドレスの受信メール閲覧や設定変更などが可能と説明されています*3。ただし、今回不正ログインされた583アカウントが、この管理者権限を持つアカウントに該当するかは公表されていません。ここで重要なのは、実際の被害を先回りして断定することではなく、自社がサーバ上に何を保存し、どのシステムと接続しているかを把握しておくことです。

Webサイトが停止・改ざんされれば、情報発信や問い合わせ受付、ECサイトの販売などに影響します。仮にメールアカウントなどが不正利用された場合には、なりすましメールやフィッシング、取引先への攻撃に悪用されるおそれもあります。外部サービス上の一つのアカウントが、社内外の複数システムをつなぐ接点になっていないかを確認する必要があります。

相次ぐサービス提供者側の不正アクセス

サービス提供者側のシステムが侵害され、利用企業やその顧客へ影響が波及した事例は、今回が初めてではありません。

2025年には、インターネットイニシアティブ（IIJ）の法人向けメールセキュリティサービス「IIJセキュアMXサービス」が、第三者製ソフトウェアの当時未発見だった脆弱性を悪用した不正アクセスを受けました。そして2026年には、KDDIがISP事業者向けに提供していたメールシステムでも、第三者製ソフトウェアの未知の脆弱性を悪用した不正アクセスが発生し、メールアドレスやパスワードなどの漏えいが確認されています。

IIJやKDDIの事案と、今回のさくらインターネットへの不正アクセスが同じ原因や攻撃手法によるものだと示す情報はありません。一方、サービス提供者のシステムが侵害された場合、その影響がサービスを利用する複数の組織へ広がり得る点は共通しています。

IPA「情報セキュリティ10大脅威 2026」でも、「サプライチェーンや委託先を狙った攻撃」は組織向け脅威の2位となっています。ただし、今回の侵入原因や攻撃者の目的は判明しておらず、本件をサプライチェーン攻撃と断定することはできません。「委託先やITサービスを通じて自社へ影響が及ぶリスク」を考えるための事例として捉えるのが適切です。

さくらのレンタルサーバ利用者が確認すべきこと

今回の事案を受けて確認すること

さくらインターネットは利用者に対し、身に覚えのないファイルや管理者アカウントが追加されていないか、Webサイトやアプリケーションに不審な変更がないか、心当たりのないログインやメール送信が発生していないかを確認するよう求めています。確認の際は、現在表示されているWebサイトだけを見て「異常なし」と判断するのではなく、サーバーコントロールパネルのログイン履歴、取得できる範囲の接続・メール送信ログ、ファイルの更新日時なども確認します。身に覚えのないファイルや不審な通信を発見した場合は、調査に必要な記録を残したうえで、さくらインターネットやセキュリティの専門家へ相談することが重要です。

なお、2026年8月17日時点では、全利用者に対する一律のパスワード変更は求められていません。さくらインターネットは、パスワード変更などの追加対応が必要と判明した場合、対象者へ個別に案内するとしています。個別通知を受けた場合はその指示に従い、同じパスワードを他のサービスでも使用している場合は、該当サービスのパスワードも変更する必要があります。

平時から備えておくこと

平時の対策としては、サーバーコントロールパネルとWebメールの二要素認証を有効にし、管理者権限を必要な担当者だけに限定することが有効です。ただし、今回のようにサービス提供者の管理環境を経由した不正アクセスでは、利用者側の二要素認証だけですべてのリスクを防げるとは限りません。今回の侵入を二要素認証で防げたとする情報も公表されていないため、一般的なアカウント乗っ取り対策として捉える必要があります。また、Webサイト、データベース、メール、設定ファイルなど、サーバ上に保存している情報を定期的に棚卸しし、漏えいした場合の影響を把握しておくことも重要です。あわせて、復旧に必要なデータは同じサービス内だけに保存せず、別の媒体や環境にもバックアップを保持します。

IPAの「日常における情報セキュリティ対策」では、データを3つ持ち、2種類の異なる媒体でバックアップし、そのうち1つは異なる場所（オフサイト）で保管する「321ルール」を紹介しています。

外部へ委託しても自社のリスク管理は必要

レンタルサーバやクラウドサービスを利用する目的の一つは、専門事業者へ運用を任せ、自社の負担を軽減することです。しかし、サービス上で扱う情報の種類や重要度を決めるのは利用企業であり、インシデント発生時には、利用企業側にも顧客や取引先への説明・対応が求められる場合があります。サービスを選ぶ際は、料金や容量、表示速度だけでなく、取得できるログ、バックアップの保存場所、障害・不正アクセス時の連絡方法、調査への協力範囲、データの返却・削除方法なども確認しておく必要があります。特に、Webサイトやメールが事業継続に直結する企業では、サービス停止や情報漏えいを想定した連絡体制と復旧手順を、委託先と共有しておくことが重要です。

IPAが進める「サプライチェーン強化に向けたセキュリティ対策評価制度」でも、ITサービスを含む委託先への攻撃を起点としたサービス停止、機密情報の漏えい、改ざん、踏み台化などがリスクとして挙げられています。委託先のセキュリティを確認することは、自社の事業を守るためのリスク管理です。

さくらのレンタルサーバ不正アクセスに関するFAQ

▼ 自分のアカウントが対象か確認する方法は？
▼ パスワード変更は必要ですか？
▼ どの情報が漏えいした可能性がありますか？

まとめ

今回のさくらインターネットへの不正アクセスでは、583アカウントへの不正ログインや一部サーバへのマルウェア設置が確認され、顧客領域に保存された情報などが第三者に閲覧・取得された可能性も公表されています。一方、侵入経路や攻撃の開始時期、実際に取得された情報の範囲などは、現時点では調査中です。今回注目すべきなのは、被害の数字だけでなく、サービス提供者の管理環境を経由して複数の顧客環境へ不正アクセスが行われた点です。利用企業は公式情報を継続的に確認するとともに、自社環境に不審な変更がないかを点検し、サーバ上に保存している情報や外部システムとの接続関係を把握しておく必要があります。 外部サービスを利用していても、自社の情報や事業へのリスクがなくなるわけではありません。本件を、自社のセキュリティ対策だけでなく、委託先やITサービスを含めたリスク管理を見直す機会とすることが重要です。

参考情報

編集責任：木下

BBSecの脆弱性診断・セキュリティ対策支援サービス

BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

ウェビナー開催のお知らせ

  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で何が起きた？ RansomHouseの主張と情報漏えいの可能性・供給網への影響

    Share
    「ニチレイへのサイバー攻撃で何が起きた？RansomHouseの主張と情報漏えいの可能性・供給網への影響」アイキャッチ画像

    2026年7月13日、ニチレイは不正アクセスによるシステム障害を公表しました。影響は冷蔵倉庫の入出庫や冷凍食品の出荷に及び、7月24日に全拠点が通常稼働へ移行しました。その後、RansomHouseを名乗るグループによる犯行声明や、20万件以上のファイル公開が報じられています。本記事では、その後に明らかになった情報を踏まえ、公式発表で確認できる事実と攻撃者側の主張、第三者の観測を分けて整理し、食品・物流サプライチェーンへの影響と企業に求められる備えを解説します。

    ニチレイが公式に確認したのは、サーバーへのサイバー攻撃、システム障害に伴う入出庫・出荷業務への影響、被害サーバーの一部に個人情報が保管されていたことです。一方、RansomHouseの関与、ランサムウェアによる暗号化、公開ファイルの真正性、情報漏えいの対象人数と範囲、侵入経路は、2026年8月13日時点で公式に確定していません。

    ※本記事は2026年8月13日時点で確認できる公表資料に基づき作成しています。RansomHouseの主張と20万件報道は、公式発表と混同しないよう補足情報として区分しています。

    7月31日時点の公式発表に基づく経緯や、業務再開までの対応、BCPの観点はこちらの記事で解説しています。
    前回記事（速報版）　：「ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP」

    ニチレイへのサイバー攻撃で何が起きたのか

    今回のニチレイへのサイバー攻撃は、情報システムだけの障害ではありませんでした。冷蔵倉庫の入出庫や冷凍食品の出荷が止まり、モノの流れそのものに影響が及んだ点が特徴です。食品物流は、保管温度や納品時間が厳しく管理される業務です。受発注や在庫、倉庫作業を支えるシステムが使えなくなれば、倉庫に商品があっても通常どおりに動かせない状況が起こり得ます。

    ニチレイは障害発生当日に緊急対策本部を設置し、個人情報や顧客データの保護を優先してグループ内システムを遮断しました。遮断は被害拡大を防ぐために重要な措置ですが、その判断によって業務への影響が表面化することもあります。サイバーインシデントでは、「止めないこと」と「安全を確認できない状態で動かさないこと」の間で、経営判断が求められます。

    ニチレイのサイバー攻撃を時系列で整理

    7月13日～24日：サイバー攻撃の確認から通常稼働への移行

    ニチレイは7月13日、不正アクセスによるシステム障害が発生したと発表しました。7月15日には自社サーバーへのサイバー攻撃を確認し、被害サーバーの一部に個人情報が保管されていたことから、個人情報保護委員会へ漏えいの可能性がある事案として速報しています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には受発注制限を解除。影響を受けた全拠点が平常時の通常稼働へ移行しました。

    ※発生から業務再開までの詳しい経緯は、前回の速報版で解説しています。

    8月7日：業績への影響を公表

    8月7日の2026年12月期第1四半期決算説明資料（決算期変更に伴う変則決算）で、ニチレイはシステム障害による売上面のマイナス影響を最大50億円、営業利益への影響を8億円と見込み、緊急対応で発生したコストや今後見込まれる損失として特別損失10億円を織り込みました。金額の意味が異なるため、これらを単純に合算して「被害総額」とみなすことはできません。

    8月10日：「20万件以上」のファイル公開が報じられる

    8月10日、テレビ朝日ANNニュースはS&Jの観測として、RansomHouseを名乗るグループが少なくとも20万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*4。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、8月13日時点で、ニチレイの公式サイトには第5報以降、漏えい範囲や対象人数を確定する追加発表は掲載されていません。

    ニチレイから個人情報は漏えいしたのか

    結論からいえば、ニチレイは「個人情報の漏えいの可能性」を公表していますが、実際に社外へ流出した情報の項目や対象人数、件数は明らかにしていません。公式に確認できるのは、被害サーバーの一部に個人情報が保管されていたこと、個人情報保護委員会へ報告したこと、対象者へ通知したことまでです。この対象者への通知が行われたこと自体も、個人情報の社外流出が確定したことを意味するものではありません。

    個人情報保護法では、不正アクセスなどによる個人データの漏えいが発生した場合だけでなく、発生したおそれがある場合にも、一定の要件のもとで個人情報保護委員会への報告と本人通知が必要になります*2。したがって、「個人情報保護委員会へ報告した」という事実だけで、漏えいが確定したとは判断できません。調査が進むにつれて公表内容が更新されることもあるため、初報だけで結論づけず、続報を追う必要があります。

    「20万件以上」は20万人分の個人情報ではない

    報道で使われた「20万件以上」は、文書や画像、フォルダー内のデータなどを含むファイル数です。1人に複数のファイルがひもづく場合もあれば、個人情報を含まない業務資料が数えられている可能性もあります。反対に、1つのファイルに複数人の情報が含まれる可能性もあります。そのため、ファイル数から被害人数を換算することはできません。さらに、公開されたとされるファイルのすべてがニチレイから窃取された真正なデータなのか、S&Jがどの範囲を確認したのかについて、ニチレイによる公式な検証結果は出ていません。

    RansomHouseとは？ニチレイへの犯行は確認されたのか

    RansomHouseは、被害組織からデータを窃取し、公開をちらつかせて金銭を要求する恐喝活動で知られるグループです。パロアルトネットワークスのUnit 42は、RansomHouseをRansomware as a Service（RaaS）として分析し、データ窃取と暗号化を組み合わせる二重脅迫、ESXi環境を狙う管理ツール「MrAgent」と暗号化ツール「Mario」の利用を報告しています*3。

    ただし、これはRansomHouse一般の活動に関する技術分析です。ニチレイの環境でMrAgentやMarioが使われたこと、サーバーやファイルが暗号化されたことを示すものではありません。RansomHouseを名乗るグループは犯行を主張していますが、ニチレイは攻撃主体を公式に特定しておらず、侵入経路や攻撃手法も公表していません。

    サイバー攻撃は食品・物流サプライチェーンへどう波及したか

    ニチレイの事例で見落とせないのは、被害が自社のサーバー内にとどまらず、商品の保管と配送を待つ取引先や、その先の店舗運営へ波及し得ることです。食品物流は、多数の荷主、倉庫、輸配送会社、小売・外食企業をつなぐ共通基盤です。中核となる事業者の機能が止まれば、取引先自身のシステムが侵害されていなくても、商品を受け取れないという形で事業が止まります。

    同時期、日本ケンタッキー・フライド・チキン株式会社（以降KFC）も、食材配送を委託する物流会社で発生した不正アクセス起因のシステム障害により、商品の一部品切れ、販売メニューの制限、営業時間の短縮などが生じたと公表しました*4。7月22日には全店舗への食材納品体制が整い、通常営業へ戻っています。KFCは物流委託先の社名を公表していないため、ニチレイの事案との関係を公式情報だけで断定することはできません。一方、この事例は、物流委託先のシステム障害が消費者向けサービスにまで波及し得る構造を示しています。

    「サプライチェーン攻撃」と「サプライチェーンへの影響」は別物

    ここで用語を分けて考える必要があります。サプライチェーン攻撃は一般に、取引先や委託先、利用するソフトウェアやサービスを足がかりとして標的へ侵入する攻撃を指します。今回、ニチレイへの侵入経路は公表されていないため、攻撃経路という意味でサプライチェーン攻撃だったとは断定できません。

    一方で、サイバー攻撃による業務停止が供給網の先へ広がる「サプライチェーンリスク」は明確に表面化しました。侵入経路の問題と、事業依存関係による影響の連鎖は別の論点です。この二つを混同しないことが、ニュースを正確に読み、自社の対策へ落とし込む第一歩になります。

    ニチレイが公表した業績への影響

    ニチレイの2026年12月期第1四半期決算説明資料では、事業停止に伴う売上面のマイナス影響を最大50億円と見込んでいます。内訳は食品事業が20億円、低温物流事業が30億円です。営業利益への影響は8億円で、食品事業2億円、低温物流事業4億円、持株会社のシステム対応費用2億円とされています。さらに、緊急対応で発生したコストと今後発生が見込まれる損失として、10億円の特別損失を織り込みました。

    ※ニチレイが公表した売上への影響、営業利益への影響、特別損失は、それぞれ意味の異なる数字です。これらを単純に合算して「サイバー攻撃による被害総額」とみなすことはできません。

    親会社株主に帰属する当期純利益の予想は252億円から204億円へ48億円下方修正されましたが、この48億円すべてがサイバー攻撃による損失ではありません。中東情勢によるコスト増や食品・物流事業の進捗など、複数の要因が含まれています。なお、連結売上高の通期予想自体は海外事業の伸長を反映して上方修正されています。

    企業が学ぶべきサイバー攻撃対策

    重要業務と外部依存を、システム単位ではなく事業単位で洗い出す

    まず必要なのは、どのシステムが止まると、どの業務、取引先、商品、売上に影響するのかを平時に把握することです。自社システムの一覧だけでは足りません。物流、決済、クラウド、保守会社、受発注先など、重要業務を支える外部依存まで含め、許容停止時間と代替手段を整理します。委託先が止まった場合の連絡順序、手作業へ切り替えられる範囲、代替事業者の有無も、BCPとインシデント対応計画の両方で確認しておく必要があります。

    また、インシデント対応訓練では自社がサイバー攻撃を受けるケースだけでなく、物流会社やクラウドサービス、主要な仕入先など、重要な委託先・取引先のシステムが停止するケースも想定することが重要です。自社システムが正常でも外部サービスが利用できない状況で、どこまで業務を継続できるのかを確認しておく必要があります。

    「業務復旧」と「情報漏えい対応」を別の時計で管理する

    ニチレイは7月24日に通常稼働へ移行しましたが、その後もダークウェブ上でのデータ公開が報じられました。ここから分かるのは、システム復旧の完了と、情報漏えい調査の完了は一致しないということです。前者は業務を安全に再開できるかという可用性の問題、後者は何が持ち出され、誰にどのような影響があるかという機密性と法令対応の問題です。復旧宣言後も、フォレンジック調査、漏えい範囲の特定、本人通知、二次被害の監視、対外説明を継続できる体制が欠かせません。

    遮断・復旧・証拠保全を同時に進められる初動体制をつくる

    攻撃を疑った場合は、インシデント対応責任者や専門家の判断のもと、必要に応じて感染が疑われる端末やサーバーをネットワークから隔離し、被害拡大を抑える必要があります。一方、電源断や安易な初期化によって調査に必要な証拠を失うおそれもあります。誰が遮断を判断し、どのログを保存し、外部の専門会社や警察、監督機関へいつ連絡するのかを事前に決め、机上訓練で確かめておくことが重要です。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」でも、インシデント発生に備えた体制構築とサプライチェーン全体での対策を経営課題として位置づけています。

    バックアップは取得だけでなく、隔離と復旧テストまで行う

    ランサムウェアを含む破壊的な攻撃に備えるには、バックアップを本番環境と同じ認証基盤やネットワークに置き続けないことが重要です。実際に戻せるかを定期的に試し、復旧に必要な時間が事業側の許容範囲に収まるかまで確認して、初めてBCPとして機能します。

    よくある質問

    ▼ ニチレイへの攻撃はランサムウェアだったのですか？
    ▼ 20万件とは20万人分の個人情報ですか？
    ▼ 個人情報の漏えいは確定していますか？
    ▼ ニチレイのシステムと業務は復旧していますか？
    ▼ 今回の事案はサプライチェーン攻撃ですか？

    まとめ―復旧の速さだけでは測れないサイバー攻撃の損失

    ニチレイへのサイバー攻撃は、冷蔵倉庫と冷凍食品出荷の停止、取引先への影響、個人情報漏えいの可能性、財務損失という複数の問題を同時に突きつけました。全拠点が通常稼働へ戻った後にデータ公開が報じられた経緯は、事業継続と情報保護を別々に備える必要性を示しています。

    企業が見るべきなのは、自社への侵入を防げるかだけではありません。重要な委託先が止まったときに業務を続けられるか、攻撃を検知した直後に安全に遮断できるか、バックアップから所定時間内に戻せるか、漏えい調査と対外説明を長期にわたって続けられるかまでが、現在のサイバー攻撃対策です。平時のうちに外部専門会社との連絡経路や調査体制を整え、実際のシナリオで検証しておくことが、被害の大きさを左右します。漏えい調査と対外説明を長期にわたって続けられるかまでを想定することが、現在のサイバーリスク対策には求められます。

    参考情報

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    ニチレイへのサイバー攻撃で食品物流に影響―業務再開までの経緯と企業が見直すべきBCP

    Share
    ニチレイへのサイバー攻撃で食品物流に影響アイキャッチ画像

    2026年7月、ニチレイがサイバー攻撃を受け、冷蔵倉庫の入出庫業務や冷凍食品の出荷業務に影響が生じました。同社は被害拡大を防ぐためグループのシステムを遮断し、一部制限のもとで業務を順次再開。7月24日には、影響を受けた業務が通常稼働へ移行しました。本事案は、サイバー攻撃が情報漏えいだけでなく、物流や取引先を含む事業継続にも影響を及ぼすことを示しています。本記事では、公式発表に基づいて対応の経緯を整理し、企業が見直すべきBCPについて解説します。

    ※本記事は2026年7月31日時点で確認できる公表資料に基づき作成しています。公表されていない製品名、CVE番号、攻撃者、侵入手法の詳細については推測を加えずに構成しています。

    ニチレイへのサイバー攻撃とは

    2026年7月13日、株式会社ニチレイは不正アクセスによるシステム障害が発生したと公表しました*5。影響が出たのは、ニチレイロジグループ各社の冷蔵倉庫における入出庫業務と、ニチレイフーズの冷凍食品出荷業務です。同社は発生当日に緊急対策本部を立ち上げるとともに、お客さまや取引先の個人情報・顧客データなどの保護を最優先し、グループで使用するシステムの遮断措置を講じたことを、2日後の第2報*2で明らかにしています。その後、7月17日から一部制限のもとで業務を順次再開し、7月24日には、影響を受けた入出庫業務と冷凍食品出荷業務の受発注制限を解除して、全拠点を平常時の通常稼働へ移行しています。

    この事案が示したのは、サイバー攻撃の被害が情報漏えいだけにとどまらないことです。攻撃を受けた疑いが生じれば、被害拡大を防ぐためにシステムを止める判断が必要になる場合があります。受発注、在庫管理、倉庫の入出庫、出荷といった業務がITでつながる現在、封じ込め措置そのものが事業停止リスクを伴います。本件からは、侵入を防ぐ対策だけでなく、システムを遮断した後も業務を継続し、段階的に復旧する計画が欠かせないことが分かります。サイバーセキュリティ対策とBCPは、一体で検討すべき課題です。

    7月13日から24日まで―公式発表で追う対応と復旧

    7月13日：不正アクセスによるシステム障害を公表

    ニチレイは7月13日、不正アクセスによるシステム障害が同日に発生したと発表しました。第1報の時点では、個人情報や顧客データが社外へ流出した事実は確認されていないとしていました。一方、冷蔵倉庫の入出庫業務と冷凍食品の出荷業務にはすでに影響が生じており、障害の範囲は公表時点で日本国内に限られると説明しています。

    ここで注意したいのは、7月13日が「攻撃者の侵入日」と確認されたわけではない点です。公式発表から断定できるのは、不正アクセスによるシステム障害が7月13日に発生し、同日公表されたことまでです。攻撃者が最初に侵入した日時や、不正アクセスを検知した正確な時刻・契機は明らかにされていません。

    7月15日：サイバー攻撃を確認、個人情報漏えいの可能性を報告

    7月15日の第2報で、ニチレイは調査の結果、自社サーバがサイバー攻撃を受けたことを確認したと発表しました。さらなる被害拡大を防ぐため、攻撃の詳細は非開示としています。また、被害を受けたサーバの一部に個人情報が保管されていたため、個人情報保護委員会へ「漏えいの可能性がある事案」として第一報を行いました。

    同社は発生当日の7月13日にグループで使用するシステムを遮断しており、この遮断措置に伴って冷蔵倉庫の入出庫と冷凍食品出荷に影響が生じたと説明しています。なお、7月16日付のIR情報では、連結業績への影響は精査中とされ、重要な影響が判明した場合は速やかに開示すると説明しています。

    7月17日：受発注を制限しながら部分稼働

    7月17日、ニチレイは外部のセキュリティ専門会社の支援のもと、影響を受けた業務を順次再開しました。ただし、直ちに平常運転へ戻ったわけではなく、顧客や取引先からの受発注を一部制限し、冷蔵倉庫と食品工場を部分稼働させる形での再開でした。この段階でも、原因と影響範囲は調査中とされていました。

    7月22日から24日：対象者への通知と通常稼働への移行

    7月22日の第4報*3では、外部のセキュリティ専門会社に加え、警察および関係機関と連携して対応していることが公表されました。被害サーバの一部に個人情報が保管されていたため、対象者へ別途通知を行っていることも明らかにされています。

    7月24日、ニチレイは受発注制限を解除し、影響を受けていた入出庫業務と冷凍食品出荷業務について、全拠点が平常時の通常稼働へ移行したと発表しました。ただし、これは影響業務の通常稼働への移行を示すものであり、原因調査や影響範囲の特定まで完了したことを意味するものではありません。

    なぜ食品サプライチェーンへの影響が注目されたのか

    ニチレイが2026年5月12日に公開した「事業概要説明資料」によると、同社の低温物流事業は全国75カ所に冷蔵倉庫を保有し、冷蔵倉庫の保管能力で国内1位です。さらに、ニチレイグループ外の取扱比率が90％を超えるとされています。今回、75カ所すべてに同じ程度の支障が生じたと公表されているわけではありません。ただし、この事業構造から、低温物流業務の中断がニチレイグループ以外の荷主にも波及し得ることが分かります。

    実際、ミールキット宅配サービスのヨシケイは7月27日、ニチレイグループのシステム障害により倉庫からの商品出庫に支障が生じ、一部エリアで代替品や代替食材を届ける場合があると公表しました*4。ニチレイは7月24日に影響業務の通常稼働への移行を発表していますが、自社の業務が再開しても、取引先側では在庫調整や代替品の手配などが続く場合があります。ヨシケイの発表は、障害の影響が取引先の商品供給にまで波及したことを示す事例といえます。

    なお、サイバー攻撃の影響が取引先へ波及したことと、取引先などを侵入経路とする「サプライチェーン攻撃」は区別する必要があります。ニチレイは侵入経路を公表していないため、本件をサプライチェーン攻撃と分類することはできません。一方、業務停止の影響が取引関係を通じて広がるリスクは、物流や食品製造だけでなく、決済、医療、クラウドサービスなどにも共通します。

    個人情報は漏えいしたのか

    2026年7月31日時点で、ニチレイは個人情報の漏えいを確定したとは発表していません。公表されているのは、被害サーバの一部に個人情報が保管されていたこと、漏えいの可能性がある事案として個人情報保護委員会へ第一報を行ったこと、対象者へ別途通知したことです。

    個人情報保護委員会は、不正の目的をもって行われたおそれがある個人データの漏えい等について、実際の漏えいが確定した場合だけでなく、それがある段階も報告対象になると示しています*5。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

    対象人数、顧客・従業員などの属性、情報項目、持ち出しの有無、不正利用の有無も公表されていません。したがって、現段階で「顧客情報が流出した」「大規模な個人情報漏えいが起きた」と書くのは不正確です。新たな公式発表が出た場合は、漏えいの事実、対象範囲、二次被害の有無を分けて確認する必要があります。

    ランサムウェア攻撃だったのか

    ニチレイは、攻撃手法、侵入経路、悪用された脆弱性、マルウェアの種類、データ暗号化や身代金要求の有無、攻撃者について公表していません。このため、本件をランサムウェア攻撃、ゼロデイ攻撃、あるいは特定の攻撃グループによる犯行と断定できる公式情報はありません。

    攻撃者を名乗る第三者の主張が報じられた場合でも、それだけで攻撃手法や犯行主体が確定するわけではありません。本記事では、ニチレイまたは捜査機関が確認した情報と、外部からの未検証の主張を区別して扱います。

    ニチレイの事例から企業が見直すべきサイバー攻撃対策

    重要業務とシステムの依存関係を可視化する

    対策の出発点となるのは、止まると事業や顧客に大きな影響が出る業務を特定し、それを支えるシステム、データ、拠点、委託先を対応付けることです。受発注システムだけを復旧しても、在庫情報、倉庫作業、輸配送との連携が戻らなければ商品は届きません。業務影響分析（BIA）を用いて復旧の優先順位を整理し、目標復旧時間（RTO）や目標復旧時点（RPO）に加え、システム停止中も最低限維持すべき業務とその水準を、IT部門と現場部門で共有しておくことが有効です。

    多層防御によって被害範囲を限定する

    ニチレイは侵入経路や攻撃手法を公表していないため、本件の原因に特定の対策不足を結び付けることはできません。以下は、同種の業務停止に備えるための一般的な対策です。

    サイバー攻撃への備えでは、侵入を防ぐだけでなく、侵入された場合にも被害を広げない対策が必要です。重要システムやネットワークの分離、特権アカウントの適切な管理、多要素認証、ログの保全・監視などを組み合わせ、攻撃者による内部での移動や権限拡大を抑制します。

    経済産業省・独立行政法人情報処理推進機構（IPA）の「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集 第4版」も、侵入を防ぐ入口対策に加え、内部での活動拡大を防ぐネットワーク対策、外部への不正通信を防ぐ出口対策、重要データを守る対策を組み合わせる多層防御を示しています。

    「システムを止めた状態」で続ける手順を用意する

    不正アクセスの疑いがある状況では、ネットワークの遮断や機器の隔離、サービス停止が必要になることがあります。IPAの「中小企業のためのセキュリティインシデント対応の手引き」でも、被害拡大の可能性がある場合の初動対応として、ネットワーク遮断や対象機器の隔離、システム・サービスの停止を挙げています。

    だからこそ、BCPはバックアップからシステムを戻す手順だけでは不十分です。システムを遮断した際に利用する代替手順を、業務内容に応じて事前に設計しておく必要があります。例えば、受発注や入出庫を電話、メール、紙の帳票などへ一時的に切り替える場合も、処理可能な件数、誤処理を防ぐ照合方法、記録の保全、平常系へ戻す際のデータ反映まで検証しなければなりません。机上演習に加え、主要システムを利用できない状況を想定し、代替手順が実際に機能するか確認することが重要です。

    復旧可能なバックアップと復旧手順を検証する

    バックアップは、データを保存しているだけでは事業復旧を保証できません。本番環境と同時に暗号化・削除されないよう、ネットワークから分離した媒体や異なる環境にも保管し、バックアップデータの完全性を定期的に確認する必要があります。

    さらに、復元テストを実施し、重要なシステムやデータを想定した時間内に復旧できるかを検証します。復旧の順序、必要な担当者、利用する機器や認証情報、システム間の依存関係も事前に整理しておくことが重要です。

    サイバー攻撃を受けた環境を安全確認なしに復元すると、侵害された設定やマルウェアまで戻してしまうおそれがあります。原因調査や安全性の確認と並行して、どの時点のデータを、どの環境へ、どの順番で戻すかを判断できる復旧手順を整備しておく必要があります。

    初動対応をIT部門だけに背負わせない

    インシデント発生時には、封じ込め、証拠保全、原因調査、復旧に加え、顧客や取引先への連絡、個人情報保護委員会などへの報告、警察との連携、経営判断が並行して進みます。ニチレイも緊急対策本部を設置し、外部のセキュリティ専門会社、警察、関係機関と連携しました。

    平時から、経営、情報システム、事業部門、法務、広報、個人情報保護担当の役割と連絡順序を決め、フォレンジック調査や復旧を依頼する外部専門家の連絡先を整えておくべきです。対応手順は、社内システムが利用できない状況でも参照できる場所に保管します。また、調査に必要なログやデータを不用意に消去しないよう、対象機器の隔離方法や外部専門家へ連絡する判断基準を訓練しておくことが重要です。

    取引先を含めて復旧情報を共有する

    自社が通常稼働へ戻っても、取引先側では在庫不足、納品遅延、代替商品の手配、顧客への案内が続く可能性があります。サプライチェーン全体の復旧を早めるには、「何が止まっているか」「どの業務をいつ再開するか」「制限が残るか」を、攻撃者に利する情報を避けながら継続的に共有することが重要です。

    公表文のひな型だけでなく、重要取引先への連絡経路、問い合わせ窓口、更新頻度、技術情報と事業影響を分けて説明するルールまで準備しておくと、混乱を抑えやすくなります。セキュリティ部門が把握する復旧状況を、物流、営業、調達、顧客対応の言葉へ変換する役割も必要です。

    よくある質問

    ▼ ニチレイのシステム障害はいつ発生しましたか
    ▼ どの業務に影響が出ましたか
    ▼ 個人情報は漏えいしましたか
    ▼ ランサムウェア攻撃だったのでしょうか

    まとめ―サイバー攻撃対策は業務復旧まで設計する

    ニチレイへのサイバー攻撃では、冷蔵倉庫の入出庫と冷凍食品出荷に支障が生じ、制限付きの再開を経て通常運用へ戻りました。一方、2026年7月31日時点では、攻撃手法や侵入経路、個人情報の外部流出の有無、最終的な影響範囲は公表されていません。

    今回の事例から企業が学ぶべきなのは、侵入防止策だけではありません。被害拡大を防ぐためにシステムを遮断しても重要業務を続けられるか、安全性を確認しながらどの順番で復旧するか、取引先へ何を伝えるかまで含めて設計する必要があります。サイバー攻撃をIT障害として閉じず、経営と現場を巻き込んだサイバーBCPとして準備することが、事業とサプライチェーンの強靱性を左右します。

    【参考情報】

    編集責任：木下

    BBSecの脆弱性診断・セキュリティ対策支援サービス

    BBSec（ブロードバンドセキュリティ）では、Webアプリケーション診断、プラットフォーム診断、クラウド環境診断、脆弱性管理支援など、企業のセキュリティリスクを可視化する各種サービスを提供しています。外部サービスや委託先を含めたセキュリティ体制の見直し、情報漏えいリスクへの備え、インシデント発生前の予防対策を検討している企業は、ぜひご相談ください。

    ウェビナー開催のお知らせ

  • 2026年8月19日（水）14:00～15:00「セキュリティ対策の有効性を検証する ―ペネトレーションテストの実施ポイントと脆弱性診断との違い―」
  • 2026年8月26日（水）「AI時代に見直すセキュリティ対策 ～ASMの考え方で始める攻撃対象領域の可視化とリスク対策～」

    • 最新情報はこちら

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    投稿日:

    DDoS攻撃とは？仕組み・種類・被害・対策を企業向けに解説

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    DDoS攻撃とは？仕組み・種類・被害・対策を企業向けに解説アイキャッチ画像

    DDoS攻撃は、大量の通信を送り付けて、Webサイトやサーバーを利用しにくくするサイバー攻撃です。サービス停止や業務の停滞を招くおそれがあるため、企業は仕組みと対策を理解しておく必要があります。本記事では、DDoS攻撃の種類や被害、基本的な対策を解説します。

    DoS攻撃との違いを詳しく知りたい方、実際にDDoS攻撃を受けた場合の初動対応や復旧の流れについて知りたい方は以下の記事もあわせてご覧ください。
    「DoS攻撃とDDoS攻撃の違いとは」
    「DDoS攻撃を受けたらどうする？」

    DDoS攻撃とは

    DDoS攻撃（Distributed Denial of Service attack）は、Webサイトやサーバー、ネットワーク機器などに大量の通信やリクエストを送り付け、正常なサービス提供を妨害するサイバー攻撃です。攻撃を受けると、Webサイトの表示遅延やサービス停止、ネットワークの応答遅延などが発生し、正規の利用者がサービスを利用できなくなることがあります。

    DDoS攻撃の特徴は、攻撃者が多数の端末やネットワークを利用する点にあります。攻撃者は、マルウェアなどに感染した機器で構成される「ボットネット」を悪用します。

    世界中の端末から一斉に通信を送るため、単一の送信元を遮断するだけでは防ぎにくい攻撃です。近年では、ECサイトや金融機関、自治体、医療機関など、幅広い組織が標的となっています。企業規模を問わず対策が求められています。

    また、DDoS攻撃は、サービス停止だけを目的とするものではありません。攻撃による混乱に乗じて、不正アクセスや情報窃取など、別の攻撃を試みる「陽動」として利用されるケースもあります。

    DDoS攻撃を理解するためには、まずDoS攻撃との違いや、どのような目的で実行されるのかを知ることが重要です。

    DoS攻撃との違い

    DoS攻撃は、単一または少数の端末からサービスを妨害する攻撃です。DDoS攻撃は、多数の端末から分散して通信を送るため、攻撃元の特定や遮断が難しくなります。

    DoS攻撃とDDoS攻撃の違いについては、以下の記事で詳しく解説しています。ぜひあわせてご覧ください。「DoS攻撃とDDoS攻撃の違いとは」

    なぜDDoS攻撃が行われるのか

    DDoS攻撃の目的は、単にWebサイトやサービスを停止させることだけではありません。企業活動を妨害したり、金銭を要求したり、別のサイバー攻撃を成功させるための陽動として利用されたりするなど、さまざまな目的で実行されます。

    例えば、ECサイトや予約システムを停止させることで売上機会の損失を狙うケースや、競合他社への業務妨害を目的とした攻撃が報告されています。

    また、サービス停止による混乱の中で、不正アクセスや情報窃取を試みることもあります。このような「陽動攻撃」として、DDoS攻撃が利用されるケースもあります。

    近年では、IoT機器の普及やボットネットの大規模化が進んでいます。その結果、専門的な知識がなくても、攻撃サービスを利用して大規模なDDoS攻撃を実行できる環境が問題視されています。

    こうしたサービスは、DDoS-for-Hire、すなわちDDoS請負サービスなどと呼ばれます。そのため、企業規模を問わず、DDoS攻撃を想定した備えが重要になっています。

    DDoS攻撃の仕組み

    DDoS攻撃は、多数の端末やサーバから、標的へ一斉に大量の通信を送る攻撃です。サーバやネットワーク機器に過剰な負荷をかけ、正常なサービス提供を妨げます。

    攻撃対象は、Webサイトだけではありません。DNSサーバやVPN、API、クラウドサービスなど、多岐にわたります。

    攻撃者は、自ら大量の通信を送るのではありません。マルウェアに感染したIoT機器やパソコン、サーバーなどを遠隔操作します。そして、ボットネットを構築して攻撃を実行するのが一般的です。

    また、DDoS攻撃は、大量の通信によって回線帯域を圧迫するものだけではありません。ネットワーク機器に負荷をかける攻撃や、Webアプリケーションへ大量のリクエストを送る攻撃など、複数の手法があります。

    そのため、自社サービスを守るためには、攻撃の仕組みを理解し、それぞれの手法に応じた対策を講じることが重要です。

    ボットネットによる分散攻撃

    DDoS攻撃では、多くの場合「ボットネット（Botnet）」と呼ばれるネットワークが悪用されます。ボットネットとは、マルウェアに感染したパソコンやサーバ、IoT機器などが攻撃者の遠隔操作下に置かれた状態のネットワークです。攻撃者はこれらの端末へ一斉に指示を送り、標的に大量の通信を発生させます。

    近年では、監視カメラやルーター、ネットワーク機器など、十分なセキュリティ対策が施されていないIoT機器がボットネットに組み込まれる事例も確認されています。機器の所有者が気付かないまま攻撃に加担しているケースも少なくありません。

    ボットネットを利用したDDoS攻撃では、世界中に分散した多数の端末から同時に通信が送られるため、単一の送信元を遮断するだけでは十分な対策が難しくなります。

    攻撃の流れ

    DDoS攻撃は、一般的に次のような流れで実行されます。

    1. ボットネットの構築
      攻撃者は、マルウェアに感染したパソコンやサーバー、IoT機器などを遠隔操作できる状態にし、ボットネットを構築します。
    2. 攻撃対象の選定
      WebサイトやECサイト、VPN、DNSサーバー、APIなど、攻撃対象となるシステムを選定します。
    3. 攻撃命令の送信
      攻撃者がボットネットへ攻撃命令を送ると、多数の端末が一斉に標的へ通信やリクエストを送信します。
    4. サービスへの影響
      大量の通信によってネットワーク回線やサーバー、ネットワーク機器、Webアプリケーションに負荷がかかり、応答遅延やサービス停止などが発生します。

    攻撃の種類によっては、ネットワーク帯域を圧迫するだけでなく、ファイアウォールやロードバランサーなどのネットワーク機器に負荷をかけるものや、Webアプリケーションへ大量のリクエストを送るものもあります。そのため、攻撃の種類に応じた対策を講じることが重要です。

    DDoS攻撃の主な種類

    DDoS攻撃にはさまざまな手法がありますが、大きく分けると「ボリューム攻撃」「プロトコル攻撃」「アプリケーション層攻撃」の3種類に分類できます。

    攻撃対象や攻撃方法が異なるため、サービスへの影響や有効な対策もそれぞれ異なります。攻撃の種類を理解することは、自社サービスがどのようなリスクにさらされているのかを把握し、適切な対策を講じるための第一歩です。

    ここでは、代表的な3つの攻撃手法について解説します。

    ボリューム攻撃

    ボリューム攻撃は、大量の通信を送り付けてネットワーク回線の帯域を圧迫し、正規の利用者がサービスへアクセスできない状態にする攻撃です。DDoS攻撃の中でも代表的な手法であり、回線容量を超える通信が発生すると、サーバーが正常に稼働していてもサービスを利用できなくなることがあります。

    代表的な手法として、UDP FloodやDNS Amplification（DNSリフレクション攻撃）、NTP Amplificationなどがあります。特にDNSやNTPなどの公開サーバーを悪用する反射・増幅型攻撃では、小さなリクエストを利用して何倍もの通信量を発生させるため、攻撃者は比較的少ない通信量でも大きな負荷を与えることができます。

    プロトコル攻撃

    プロトコル攻撃は、TCP/IPなどの通信プロトコルの仕組みを悪用し、サーバーやファイアウォール、ロードバランサーなどのネットワーク機器に負荷をかける攻撃です。通信回線そのものを埋め尽くすボリューム攻撃とは異なり、ネットワーク機器やサーバーの処理能力を消費させることで、正常な通信を妨害します。

    代表的な手法としては、SYN Floodがあります。TCP通信の接続要求（SYNパケット）を大量に送り付けることで、サーバは接続待ちの状態を維持し続けることになり、新たな正規ユーザからの接続を受け付けられなくなる場合があります。このほか、Ping FloodやSmurf攻撃などもプロトコル攻撃の一種として知られています。

    アプリケーション層攻撃

    アプリケーション層攻撃は、WebサイトやWebアプリケーション、APIなどを標的とするDDoS攻撃です。利用者が直接アクセスするサービスが狙われます。

    通信量そのものはそれほど多くなくても、サーバーが処理に時間を要するリクエストを大量に送ることで、CPUやメモリなどのリソースを消費させ、サービスの応答遅延や停止を引き起こします。

    代表的な手法としてHTTP Floodがあります。通常のWeb閲覧と同じHTTPリクエストを大量に送信するため、正規のアクセスと見分けにくく、単純な通信量の監視だけでは検知が難しい場合があります。また、検索機能やログイン画面、APIなど、サーバー負荷の高い処理を集中的に狙う攻撃も確認されています。

    DDoS攻撃による被害

    DDoS攻撃による影響は、単にWebサイトが一時的に閲覧できなくなるだけではありません。サービス停止による売上機会の損失や業務の停滞、顧客対応の負荷増加など、企業活動全体へ影響が及ぶ可能性があります。

    また、長時間にわたってサービスが利用できない状態が続くと、企業の信頼低下やブランドイメージの毀損につながるおそれもあります。

    近年では、DDoS攻撃を単独で行うだけでなく、その混乱に乗じて不正アクセスや情報窃取など別の攻撃を試みるケースも報告されています。そのため、DDoS攻撃は単なる通信障害ではなく、企業の事業継続に関わるセキュリティリスクとして捉えることが重要です。

    ここでは、企業が受ける代表的な被害について解説します。

    サービス停止

    DDoS攻撃による代表的な被害は、Webサイトやオンラインサービスの停止です。

    大量の通信やリクエストが送られると、サーバーやネットワーク機器に過剰な負荷がかかります。その結果、Webページの表示遅延やタイムアウト、エラーが発生し、正規の利用者がサービスを利用できなくなることがあります。

    特に、ECサイトや予約システム、会員向けサービス、決済サービスなど、インターネットを通じて提供されるサービスでは、短時間の停止であっても売上機会の損失や顧客満足度の低下につながる可能性があります。

    さらに、DDoS攻撃ではサーバー自体に障害が発生していなくても、回線帯域の逼迫やネットワーク機器への負荷によってサービスが利用できなくなる場合があります。そのため、システムが正常に稼働しているように見えても、利用者からは「サービスが停止している」と認識されるケースも少なくありません。

    業務への影響

    DDoS攻撃の影響は、Webサイトの停止だけにとどまりません。公開サービスと社内システムが同じネットワークや認証基盤を利用している場合には、VPNや業務システム、クラウドサービスなどへ影響が及び、日常業務に支障をきたすことがあります。

    また、サービス停止に伴い、顧客や取引先からの問い合わせが急増し、カスタマーサポートや営業部門の対応負荷が高まることもあります。

    ECサイトでは注文処理や決済が滞り、BtoBサービスでは取引先の業務に影響を与えるなど、事業継続にも大きな影響を及ぼす可能性があります。さらに、障害対応のために情報システム部門やセキュリティ担当者が長時間の対応を余儀なくされ、本来予定していた業務が停滞するケースも少なくありません。

    企業の信頼低下

    DDoS攻撃によるサービス停止が長時間続いたり、繰り返し発生したりすると、企業に対する信頼の低下につながるおそれがあります。利用者は「サービスが安定して利用できない企業」という印象を持つ可能性があり、顧客離れや新規顧客の獲得機会の損失につながることもあります。

    さらに、DDoS攻撃をきっかけに、自社のセキュリティ対策やインシデント対応体制が十分であるかを取引先や顧客から問われることもあります。そのため、平時から適切な対策を講じるとともに、攻撃発生時には迅速かつ適切な対応を行うことが、企業の信頼維持につながります。

    企業が実施すべきDDoS攻撃対策

    DDoS攻撃は、完全に防ぐことが難しいサイバー攻撃の一つです。そのため、攻撃を受けることを前提に、被害を最小限に抑えるための対策を講じることが重要です。ここでは、企業が押さえておきたい代表的なDDoS攻撃対策を紹介します。

    通信の監視と異常検知

    DDoS攻撃による被害を最小限に抑えるためには、通信状況を継続的に監視し、通常とは異なるアクセスを早期に検知できる体制を整えることが重要です。

    アクセス数や通信量、リクエスト数などの推移を日頃から把握しておくことで、異常な増加が発生した際に迅速な対応につなげることができます。

    近年では、SIEM（Security Information and Event Management）やネットワーク監視ツールを活用し、異常な通信を自動で検知・通知する仕組みを導入する企業も増えています。

    DDoS攻撃は短時間で通信量が急増するケースが多いため、異常を検知してから対応を開始するまでの時間が重要です。

    CDN・WAF・DDoS対策サービスの活用

    DDoS攻撃は、攻撃元が世界中の多数の端末に分散しているため、自社設備だけで防ぎきることは難しく、外部サービスとの連携が対策の基本方針になります。特に、大量の通信が発生するボリューム攻撃では、自社ネットワークに到達する前に不要な通信を分散・遮断する仕組みが重要になります。

    • CDN（Content Delivery Network）：コンテンツを複数のサーバーに分散して配信することで、通信負荷を分散し、サービスの継続性向上に役立ちます。
    • WAF（Web Application Firewall）：Webアプリケーションへの不正なアクセスや不審なリクエストを検知・制御する機能を備えており、特にアプリケーション層を狙った攻撃への対策として有効です。
    • DDoS対策サービス：専用の設備で攻撃トラフィックを検知・吸収・フィルタリングし、正常な通信のみを自社環境へ転送する仕組みを提供しています。

    攻撃の規模やサービスの重要度に応じて、ISPやクラウド事業者が提供する対策サービスも含め、自社に適した構成を検討するとよいでしょう。

    自社の対策状況に不安がある場合

    「どのサービスを、どこまで導入すべきか」の判断が難しい場合は、専門会社によるDDoS耐性評価・セキュリティ診断を活用するのも一つの方法です。現状のリスクを可視化したうえで、優先度をつけて対策を進めることができます。

    インシデント対応体制の整備

    DDoS攻撃は、技術的な対策だけで完全に防ぐことは困難です。そのため、攻撃を受けた際に迅速かつ適切に対応できる体制をあらかじめ整備しておくことが重要です。

    具体的には、攻撃発生時の連絡体制や対応手順を文書化し、情報システム部門だけでなく、経営層や広報部門、カスタマーサポート部門など、関係者の役割を明確にしておくことが求められます。

    また、ISPやクラウド事業者、セキュリティベンダーなどの連絡先や支援体制を事前に確認しておくことで、緊急時の対応を円滑に進められます。

    まとめ

    DDoS攻撃は、大量の通信によってWebサイトやネットワークサービスを利用できない状態にするサイバー攻撃です。攻撃手法にはボリューム攻撃、プロトコル攻撃、アプリケーション層攻撃などがあり、それぞれ特徴や有効な対策が異なります。

    企業は、通信の監視や異常検知、CDN・WAF・DDoS対策サービスの活用に加え、インシデント対応体制の整備など、多層的な対策を講じることが重要です。また、攻撃を完全に防ぐことは難しいため、被害を最小限に抑えるための備えも欠かせません。

    攻撃発生時の具体的な対応手順や、復旧までの流れについては、以下の記事で詳しく解説しています。あわせてご覧ください。
    「DDoS攻撃を受けたらどうする？初動対応から復旧までの流れを解説」

    【関連記事】

    DDos攻撃について、SQAT.jpでは以下の記事でも解説しています。こちらもあわせてぜひご覧ください。

    【参考情報】

    DDoS対策や公開システムのセキュリティに不安はありませんか？

    DDoS攻撃への備えには、ネットワークやWebアプリケーションのリスクを把握することが重要です。BBSecでは、脆弱性診断をはじめ、お客様の環境に応じたセキュリティ評価をご提供しています。

    Webアプリケーション脆弱性診断バナー

    アクセス急増の原因が複雑で判断が難しい場合や、継続的な運用に不安がある場合は、第三者の視点を取り入れることも有効です。定期的なセキュリティ診断や評価を通じて、自社では気づきにくいリスクを把握することができます。

    公開日：2021年6月23日
    更新日：2026年7月29日

    編集責任：木下

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る