タグ: インシデント対応

投稿日:

ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと

Share
ニチレイが個人情報漏洩を確認アイキャッチ画像

株式会社ニチレイは2026年9月18日、7月に発生したシステム障害に関する第7報で、サイバー攻撃を受けたサーバーの一部から個人情報の漏えいを確認したと発表しました。配送先や取引先の役職員、従業員・退職者とその家族、求職者などが対象です。7月24日には入出庫・冷凍食品出荷業務が全拠点で通常稼働へ移行していましたが、その後も調査は続き、8月の「漏えいのおそれ」の公表を経て、9月に漏えいが確認されました。本記事では、公式発表をもとに新たに判明した事実を整理し、業務復旧と漏えい調査を並行して進めるために企業が備えておきたいポイントを解説します。

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

本件については、これまでの経緯もあわせて解説しています。あわせてぜひご覧ください。

漏えいが確認された対象と件数

第7報で示されたのは3区分です。ニチレイグループ各社が受託した配送業務の配送先のお客さまは3,308件で、情報の項目は氏名、住所、電話番号です。取引先の役職員は6,849件で、会社名、所属、役職、氏名、住所、電話番号、メールアドレスが挙げられています。グループ従業員と2021年以降の退職者、その家族、求職者の区分は43,709件です。氏名や連絡先、生年月日、従業員番号などに加え、給与賞与情報、在留資格、所属・異動等の人事情報が含まれています。ただし、1件ごとに公表された全項目が含まれるわけではありません。クレジットカード情報は含まれないとしています。

第7報で公表された3区分の件数を単純に合計すると53,866件です。ただし、これは本記事で各区分を加算した値であり、ニチレイが「漏えいした人数」として公表した数字ではありません。影響を確認する際は、合計値だけでなく、対象区分と漏えいが確認された情報の項目を分けて見る必要があります。

7月の業務復旧から9月の漏えい確認まで

7月13日の第1報では、不正アクセスによるシステム障害と、ニチレイロジグループ各社の冷蔵倉庫の入出庫業務、ニチレイフーズの冷凍食品出荷業務への影響が公表されました。第7報によると、同社は発生当日にシステムを遮断し、緊急対策本部を設置しています。7月24日の第5報では、受発注制限を解除して全拠点を通常稼働へ移行したと発表しました。

その後、8月14日の第6報で一部従業員情報の漏えいのおそれを公表し、9月18日の第7報で漏えいの確認と対象区分・件数を明らかにしました。第7報には9月11日に個人情報保護委員会へ報告したことも記載されています。業務の復旧日を、そのまま調査や対象者対応の完了日と捉えないことが、公表内容を理解する上での要点です。

第7報の時点でも原因分析と影響範囲の調査は続いています。確認した同社の発表には、具体的な侵入経路や悪用された脆弱性、ランサムウェアの使用を特定する説明はありません。攻撃の名称や原因を補って解釈せず、公表済みの事実と調査中の事項を分けて捉える必要があります。

図：ニチレイの漏えい情報と復旧後の調査

出典：株式会社ニチレイ「当社グループでのシステム障害発生について（第5報）」（2026年7月24日）、「当社グループでのシステム障害発生について（第7報）」（2026年9月18日）をもとに作成
※件数を人数と同一視しません。各記録にすべての情報項目が含まれるわけではありません。

対象者への案内と二次被害への注意

ニチレイは対象者へ順次個別に連絡しており、連絡先が分からないなど個別通知が難しい場合は公表をもって案内に代えるとしています。また、第7報の公表時点では、不正利用等の二次被害は確認されていません。この説明は9月18日時点の確認状況として読む必要があります。同社は、ニチレイや公的機関、金融機関を装った不審なメール、SMS、電話への注意も呼びかけています。不審な連絡に記載されたURLへのアクセス、個人情報の提供、添付ファイルの開封を避け、関連する不審な事象は公表資料に記載された窓口へ相談するよう案内しています。対象者は個別の通知内容と公式発表を確認し、自分に関わる情報の範囲を把握することが大切です。

業務復旧と調査を並行できる体制

ここからは、公表事実と公的な手引きを踏まえた企業一般への提案です。IPAの「中小企業のためのセキュリティインシデント対応の手引き」は、被害拡大を防ぐ初動、関係者への報告・公表、証拠保全と復旧・再発防止を整理しています。事業を早く再開する準備と、被害を正確に把握して説明する準備を、同じ対応計画に組み込むことが重要です。

物流や出荷を支えるシステムでは、停止した場合にどの業務へ影響が及ぶかを平時に整理しておくと、遮断や復旧の判断を具体化できます。IT部門だけでなく、現場責任者と経営層が、優先して再開する業務、代替手段、再接続を判断する責任者を共有しておくことを勧めます。サイバー攻撃では被害範囲がすぐに分からない場合もあるため、安全性を確認する工程を復旧計画に含めることが欠かせません。

証拠・ログを残す

漏えい調査に備えて、端末やサーバー、ネットワーク機器の記録をどの担当者が保全し、専門家に何を渡すかも決めておきます。IPAは、不用意な操作で記録を消さないことや、必要に応じたフォレンジック調査を挙げています。復旧作業の担当者と調査担当者が作業内容を共有し、記録の確保を確認した上で修復を進める手順にしておけば、後から事実を確かめるための手掛かりを残せます。

説明体制では、業務の稼働状況、漏えいが確認された情報、調査中の事項、対象者への連絡状況を分けて管理する方法が考えられます。問い合わせ窓口と公表担当者が同じ更新情報を参照できるようにし、追加の事実が判明した場合の確認・承認手順まで準備しておくと、復旧後も必要な説明を続けやすくなります。これは、IPAが示す状況に応じた継続的な報告・公表を、自社の運用に落とし込むための提案です。

個人情報の保管場所・権限を把握する

今回公表された対象には、配送先や取引先だけでなく、従業員、退職者、家族、求職者が含まれます。この範囲を自社点検の手掛かりにすると、顧客データベース以外に人事・採用関連のファイルや共有領域も確認対象となります。どの部署が何の目的で保有し、どのシステムに保存しているかを整理することが、影響範囲を調べる際の基礎になります。

あわせて、業務上必要な担当者だけが情報へアクセスできるか、異動や退職に伴う権限変更が反映されているかを点検します。個人情報保護委員会の通則ガイドラインも、担当者と取り扱うデータベースの範囲を限定するアクセス制御、アクセス者の識別・認証、不正アクセス対策などを示しています。給与や人事に関する情報を扱う部門も含め、保存場所と利用権限を確認することが実務上の出発点です。

IT-BCPとフォレンジックを平時から準備する

ニチレイは第7報で、グループ全体のセキュリティと監視体制の強化に加え、事業継続計画の見直しを進めるとしています。自社でも、通常の障害復旧手順に、攻撃の封じ込め、証拠保全、情報漏えい調査を組み合わせて対応できるかを確認しておきたいところです。

サイバー攻撃を想定した復旧計画の具体化には、ブロードバンドセキュリティ（BBSec）の「ランサムウェアに対応したIT-BCP策定支援」を活用できます。同サービスはランサムウェアを含むサイバー攻撃を対象に、企業の状況やニーズに応じたIT-BCPの策定・見直しを支援します。現行計画の対象や復旧判断の手順を整理する際の相談先として、ご検討ください。

情報漏えいの疑いが生じた際には、業務復旧を進めながら、調査に必要な証拠を適切に保全し、被害状況を確認する必要があります。BBSecの「デジタルフォレンジック」では、事象の把握や証拠保全・データ収集、原因や影響範囲の調査をご支援します。平時から調査支援を依頼する手順まで整えることで、業務復旧と事実確認を進める体制を具体化できます。平時のご相談はSQAT.jpよりお問い合わせください。

インシデントレスポンス／フォレンジック

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

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

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

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

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

→【続報】2026年9月18日、ニチレイは第7報で個人情報の漏えいを確認し、対象区分と件数を公表しました。最新の公表内容はこちらの記事で解説しています。
「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

※本記事は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万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*1。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、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万人分の個人情報ですか？
▼ 個人情報の漏えいは確定していますか？
▼ ニチレイのシステムと業務は復旧していますか？
▼ 今回の事案はサプライチェーン攻撃ですか？

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

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

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

参考情報

公開日：2026年8月13日
更新日：2026年10月6日

編集責任：木下

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年9月18日、ニチレイは個人情報の漏えいを確認したと発表しました。最新の公表内容はこちらの記事で解説しています。
    「ニチレイが個人情報漏洩を確認 ―第7報で判明した被害と企業が備えるべきこと」

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

    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。このため、個人情報保護委員会への報告が行われたことだけをもって、外部流出が確定したとは判断できません。

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

    ※その後、9月18日の第7報で個人情報の漏えいが確認されました。最新情報はこちら。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    よくある質問

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

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

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

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

    【参考情報】

    公開日：2026年8月5日
    更新日：2026年10月6日

    編集責任：木下

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

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

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

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

    • 最新情報はこちら

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

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

    投稿日:

    佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性

    Share
    佐川急便「お荷物問い合わせサービス」に不正アクセス、個人情報流出の可能性アイキャッチ画像

    佐川急便は2026年9月30日、Webサイトの「お荷物問い合わせサービス」で第三者による不正アクセスを確認したと発表しました。10月1日の第2報では個人情報が外部に流出した可能性を公表し、同日の第3報で専用コールセンターの開設を案内しています。対象には荷物の送り主と届け先、運賃契約者、スマートクラブ登録者の情報が含まれる可能性があり、件数や影響範囲、原因の調査が続いています。本記事では、公表された事実と、企業が同様の事態に備えて確認しておきたい対応を整理します。

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

    不正アクセス確認から個人情報流出の可能性公表まで

    第1報によると、不正アクセスを確認した日は9月30日です。佐川急便は確認後に同サービスへのアクセスを一部制限し、荷物の問い合わせが利用しづらくなる場合があると案内しました。翌10月1日の第2報では、調査によって個人情報の外部流出の可能性が判明したと説明し、被害拡大を防ぐために一部のWebサービスを停止していることを公表しています。

    その後の公表でも、影響範囲と原因は引き続き調査中とされています。確認できた公表内容からは、侵入に使われた具体的な手法や脆弱性、対象人数を確定できません。「不正アクセスを確認したこと」と「個人情報が流出した可能性」を分けて捉える必要があります。公表されていない攻撃経路を推測し、自社の対策を特定の製品や手法だけに絞ることも避ける必要があります。

    流出した可能性がある情報と「約100日間」の意味

    第2報では、対象となる可能性がある人と情報を三つに分けています。荷物の送り主と届け先については、氏名、住所、電話番号が対象とされ、法人の場合は法人名と担当者名が含まれます。この区分について、9月30日からさかのぼる約100日間の累計データと説明されています。運賃契約を結んでいる法人・個人についても、氏名または法人名と担当者名、住所、電話番号が挙げられています。スマートクラブ登録者については、氏名、住所、電話番号に加え、メールアドレスと会員IDが対象とされています。一方、クレジットカード情報とパスワードは含まれないとしています。対象件数と範囲は調査中です。

    ここでいう「約100日間」は、荷物の送り主・届け先に関する対象データの説明です。不正アクセスが約100日間継続していたという意味ではありません。 また、運賃契約者やスマートクラブ登録者にも一律に適用される期間とは示されていません。対象には荷物の届け先も含まれる可能性があるため、自ら発送や会員登録をしていない場合でも、届け先として情報が登録されている可能性があります。個々の対象については、今後の佐川急便の公式案内を確認する必要があります。

    図：佐川急便が公表した流出可能性の対象

    出典：佐川急便「「お荷物問い合わせサービス」への不正アクセスによる個人情報流出の可能性について（第2報）2026年10月1日」（https://www2.sagawa-exp.co.jp/information/detail/420/）を基に弊社作成。
    いずれも流出した可能性がある情報であり、流出の確定や対象人数を示すものではありません。「約100日間」の記載は、送り主・届け先の区分に付されたものです。

    Webサービスの停止と集荷・配達の状況を区別する

    第2報の停止対象には、インターネット貨物お荷物問い合わせとそのAPI、飛脚宅配便受付、飛脚往復便受付と同ゴルフ受付、商品回収返金サービス、配達予定時・不在発生後の受取先変更、回収くんが挙げられています。一方、荷物の集荷・配達は通常どおり行っていると説明しています。Webで追跡や手続きができないことと、配送そのものが停止していることは分けて捉える必要があります。

    第3報では、個人情報流出の可能性に関する専用コールセンターの開設も案内されています。受付時間など最新の問い合わせ方法については、佐川急便の公式案内を確認してください。集荷や配達状況など荷物に関する問い合わせについては、最寄りの営業所へ連絡するよう案内されています。

    佐川急便は、同社を装う不審な連絡への注意も呼びかけています。不審な連絡に記載されたURLへのアクセスや、個人情報の入力・提供をしないよう注意が必要です。利用者向けに案内する企業も、佐川急便からの注意喚起と公式窓口を共有し、追加情報の確認先をそろえておくとよいでしょう。

    配送を委託する企業は顧客情報の受け渡しを確認する

    今回の公表を受け、配送を利用する企業が自社の備えとして確認したいのは、どの業務で、誰の情報を、どの相手に渡しているかです。例えばEC事業では、購入者と届け先が異なる場合があります。発送担当者の情報だけを確認しても、顧客への説明に必要な範囲を把握できるとは限りません。ここからは佐川急便の調査結果とは切り分け、配送データを扱う企業が平時から確認しておきたい一般的な備えについて整理します。

    配送会社に渡している情報を整理する

    まず、自社の受注記録や出荷記録と、配送会社に渡す情報の項目を対応づけます。注文番号、発送日、送り状番号などを使って、対象期間の出荷と届け先を社内で確認できる状態を整えておきます。これは流出を確定する作業ではなく、配送会社から追加情報が示されたときに、自社との関係を確認するための準備です。整理した資料にも個人情報が含まれるため、閲覧できる担当者と共有先を定めて扱いましょう。

    関係部門で確認状況を共有する

    配送会社や業務委託先との連絡では、対象期間、情報項目、確認済みの内容、調査中の内容を記録します。社内でも物流、情報システム、顧客対応などの関係部門で情報を共有し、顧客への説明や公表を誰が判断・承認するかを決めておくことが重要です。調査中の事項を断定せず、情報の更新日時と確認中の事項を明確にすることで、社内外への説明の食い違いを抑えられます。

    影響範囲を調べられるログと初動の役割分担を備える

    自社でWebサービスや配送連携システムを運用している場合は、異常を検知した後に何を調べられるかも確認しておきたい点です。JPCERT/CCは、複数のサーバーや機器のログを適切に採取・分析することで、侵入や攻撃の影響範囲を捉えられる可能性があると説明しています。一方、必要なログが取得されていない、または十分な期間保存されていないため、全容を解明できなかった例についても触れています。

    そのため、ログを保存するだけでなく、どのシステムの、どの操作を確認するために記録するのかを決めておくことが重要です。アクセス時刻や利用アカウント、データの参照・出力に関する記録を実際に取得できるか確認します。保存期間や上書きされる条件、ログを取り出す担当者も整理しておけば、調査を始める際の迷いを減らせます。記録に痕跡が見つからない場合には、そもそもその操作を記録できる設定だったかを確かめることも必要です。

    こうした技術面の準備と併せて、異常の受付、深刻度の判断、サービスの停止や制限を決める責任者、委託先への連絡担当を定めておきます。調査に必要な記録の保全と、顧客対応に必要な事実の整理を並行して進められる体制が望まれます。今回の事案で公表されている原因や対応の評価とは切り分け、自社で同様の連絡を受けた場合に必要な情報と判断を点検しておくことが、具体的な備えにつながります。

    インシデントに備えてログと初動対応を見直す

    ログの取得範囲や分析方法を整理したい場合は、BBSecの「セキュリティログ分析／活用支援」が選択肢になります。既存ログの分析、取得環境の整備に向けた助言、統合ログ管理・分析環境の構築から運用までを支援するサービスです。自社の記録で何を確認でき、どこに不足があるかを検討する際に活用できます。また、「インシデント初動対応準備支援」では、企業の現状に合わせ、初動対応フローやガイドラインの作成を支援します。調査の根拠となるログと、関係部門が動くための手順を平時から整えておきたい企業は、ブロードバンドセキュリティ（BBSec）にご相談ください。

    【参考情報】

    編集責任：木下

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

    最新情報はこちら

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

    投稿日:

    2026年の国内ランサムウェア被害をCisco Talosが調査 ―バックアップまで狙う攻撃への対策

    Share
    2026年の国内ランサムウェア被害アイキャッチ画像

    ランサムウェア対策では、業務データだけでなく、復旧に必要なバックアップや、その管理権限を守ることも重要です。Cisco Talosは2026年9月17日、日本国内のランサムウェア被害動向と攻撃基盤に関する調査結果を公表しました*6。本記事では、この調査から分かったことを整理し、企業が見直しておきたい監視、アクセス管理、復旧への備えについて解説します。

    Talosが把握した国内ランサムウェア被害は90件

    図1：日本のランサムウェア被害件数の比較

    出典：Cisco Talos「Ransomware incidents in Japan in the first half of 2026」（https://blog.talosintelligence.com/ransomware-incidents-in-japan-in-the-first-half-of-2026/）を基に弊社作成
    ※日本全体の被害総数ではありません。

    Talosが調査で把握した日本のランサムウェア被害は、2026年1～7月に90件でした。前年の同じ期間の86件から4件（約4.7％）増加となります。この90件はTalosが把握した範囲の数値で、日本全体の被害総数を示すものではありません。業種別では製造業が34％を占めました。また、資本金が分かる組織のうち、10億円未満の組織は78％でした*2。

    同調査は企業規模を見る参考にはなりますが、資本金だけで中小企業に該当するかを判断することはできません。被害件数の大小だけで自社の安全性を測らず、守るべき業務やデータに照らして対策を点検しましょう。

    The Gentlemenの調査で見えたバックアップへの接近

    今回、国内で最も多く観測されたグループはThe Gentlemenの14件で、QilinとSafePayが各7件で続きました。TalosはThe Gentlemenに関連するとみられる攻撃者の基盤を調べ、バックアップ内のWindowsファイルシステムを参照し、認証情報やパスワードハッシュを抽出したほか、バックアップデータを外部のクラウドストレージへ転送した痕跡を報告しています。攻撃の流れは操作履歴などから再構成したものであり、すべての被害組織で同じ経路の攻撃が成功したと確認されたわけではありません。

    バックアップは、情報の保管先としても点検対象になります。復旧用のコピーに重要な情報が含まれているなら、そのコピーを誰が読めるのか、誰が削除できるのかまで確かめる必要があります。英国NCSCも、バックアップの管理に使うアカウントやアクセス経路の保護、多要素認証の利用を推奨しています*3。取得の成否だけでなく、保存先へのアクセスを制御できているかが確認の要点です。

    QilinのAI利用はどこまで分かったのか

    Talosがランサムウェア「Qilin」による攻撃を受けた環境を調査したところ、Qilinが使用していたオープンディレクトリから見つかったPythonスクリプトに、AIによる生成を示唆する特徴が確認されました。Talosは、その確度を中～高程度と評価しています。確認されたスクリプトには、Veeamバックアップを停止・無効化・破壊する機能を持つものも含まれていました。ただし、AIが攻撃全体を自律的に実行したと証明されたわけではありません。AI利用に関する評価と、スクリプトが備える機能は分けて読む必要があります。

    企業の対策として点検したいのは、強い権限を持つアカウントで、どの操作まで実行できるかです。管理者権限の付与範囲を絞り、操作を記録し、不審な動きに対応する体制を整えましょう。こうした基本対策は、攻撃用コードの作成方法にかかわらず必要になります。AIという話題だけに対策を寄せず、自社で管理できる権限と監視の範囲を確認しましょう。

    【関連記事】
    Cisco Secure Firewall Management Center（FMC）の脆弱性を悪用し、侵入後にQilinランサムウェアが展開された事例も確認されています。実際の攻撃で確認された活動や、対象製品の確認、修正版へのアップグレードと侵害調査のポイントについて解説しています。
    「Cisco FMCの脆弱性が実悪用―Qilinランサムウェアへの悪用事例と対策」

    企業が見直したいランサムウェア対策

    ここからは、警察庁と英国NCSCの対策情報をもとに、自社で確認する際の観点を整理します。

    図2：侵入の防止から被害調査までの対策範囲

    参考：警察庁「ランサムウェア被害防止対策」（https://www.npa.go.jp/bureau/cyber/countermeasures/ransom.html）、National Cyber Security Centre (NCSC)「Mitigating malware and ransomware attacks」（https://www.ncsc.gov.uk/guidance/mitigating-malware-and-ransomware-attacks）を基に弊社作成
    ※ランサムウェア対策として、公開機器・リモート接続、端末・管理アカウント、重要サーバー・バックアップを保護し、インシデント発生時には証拠保全、影響調査、復旧判断を行う流れを示した模式図。
    ※一般的な対策の位置関係を示しており、今回の調査で確認された攻撃をそのまま再現した図ではありません。

    公開機器とリモート接続の管理を確かめる

    VPNなど外部から接続する機器は、使用製品とバージョン、更新を担当する部署を把握し、修正プログラムを適用できる状態にしておきましょう。認証には多要素認証を組み合わせ、接続元やアクセス先も必要な範囲に制限します。警察庁は、脆弱性への対応に加えて認証情報の管理と権限の最小化を案内しています。担当者が確認する際は、設定の有無とあわせて、例外として残された接続がないかも点検しましょう。

    端末と認証のログをつなぎ 初動対応を決める

    侵入後の横展開とは、攻撃者が侵害した端末などを足掛かりに、別のシステムへアクセスを広げることです。その調査や検知には、端末内の活動だけでなく、認証やネットワーク通信の記録も役立ちます。NCSCは、端末、サービス、ネットワーク機器など複数の情報源を組み合わせた監視を勧めています*4。

    運用の点検では、不審なログインが見つかった際に、その前後の端末操作や外部通信を調べられるかを確認します。さらに、夜間に通知を受け取る担当者や、アカウント停止・端末隔離を判断する担当者を決めておきましょう。セキュリティ製品を導入するだけでなく、異常を検知した際に実際の調査や対応へ移れる体制になっているかを確認することが重要です。

    バックアップを保護し復元できることを試す

    バックアップは、業務環境が侵害されても一緒に失われないよう保管する必要があります。NCSCは、ネットワークから分離したバックアップ、復元手順の定期的な確認、バックアップ製品の更新に加え、インシデントを想定した対応計画の策定や訓練を推奨しています*5。クラウドに保存する場合も、過去の世代を直ちに削除されない仕組みがあるかを確認しましょう。復旧の準備では、どの業務を先に再開するかを決め、そのために必要なシステムを実際に戻せるか試します。バックアップ取得の記録が残っていても、担当者が復元手順を実行できるとは限りません。社内システムが使えない状況でも、連絡先や手順書を参照できるようにしておきましょう。

    自社の課題に合わせてBBSecの支援を活用する

    監視の通知を受け取った後の分析や対応を自社だけで担いきれない場合は、BBSecの「G-MDR®」が選択肢になります。各種セキュリティ対策を統合的に監視・相関分析し、脅威の検知から遮断・封じ込め、被害調査、対応支援を24時間365日体制で提供するサービスです。相談に当たっては、自社で収集できるログや管理対象を整理し、必要な対応範囲を確認するとよいでしょう。復旧計画を見直したい企業には、「ランサムウェアに対応したIT-BCP策定支援」があります。現状の対策状況を調査し、復旧の優先度や目標とする対策レベル、システム・ネットワークと運用の要件、改善計画の策定を支援します。復旧の優先順位と事業再開に向けた要件を具体化したい場合に、検討できるサービスです。

    すでに不正アクセスが発生している、または侵害が疑われる場合には、まず侵入経路や影響範囲、情報漏えいの有無などを確認する必要があります。BBSecでは「緊急対応支援」を通じて、初動対応やデジタルフォレンジック、原因・影響範囲の調査、復旧に向けた対応などを支援しています。

    また、情報が外部に持ち出された可能性がある場合には、「サイバー脅威情報調査」を組み合わせることで、ダークWeb上で自社に関連する情報が公開されていないかを調査できます。社内のログや端末などを対象とした調査とは目的が異なるため、必要に応じて組み合わせることで、内部の侵害状況と外部への情報流出の両面から確認できます。なお、ダークWeb上で情報が確認されなかったことだけをもって、情報漏えいがなかったと判断することはできません。情報漏えいの懸念がある場合、監視や復旧の備えについても、自社で対応に不安が残る箇所を整理したうえでBBSecへご相談ください。

    【参考情報】

    編集責任：木下

    ランサムウェア対策やインシデント対応についてご相談ください

    ランサムウェア対策は、侵入を防ぐだけでなく、監視や初動対応、バックアップからの復旧まで含めて備えることが重要です。自社の対策状況や対応体制に不安がある場合は、ブロードバンドセキュリティ（BBSec）へご相談ください。

    お問い合わせページリンクボタン

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

    最新情報はこちら

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

    投稿日:

    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件の脆弱性が実際の攻撃で悪用されていると公表しました*6。確認された攻撃活動には、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に戻る