タグ: サプライチェーン

投稿日:

SCS評価制度とは？★3・★4の違い、開始時期と企業が進める対策【2026年版】

Share
SCS評価制度とは？★3・★4の違い、開始時期と企業が進める対策アイキャッチ画像

取引先から届くセキュリティチェックシートの内容が企業ごとに異なり、回答や確認に時間がかかる。――このような悩みを抱えている発注企業、受注企業は少なくありません。サプライチェーンを通じたサイバー攻撃が相次ぐ一方で、取引先の対策状況を客観的に判断する共通の物差しは、これまで十分に整っていませんでした。こうした課題に対応するために構築されたのが、「サプライチェーン強化に向けたセキュリティ対策評価制度」、通称SCS評価制度です。★3と★4については、2027年3月頃の運用開始が予定されています。

本記事では、SCS評価制度とはどのような制度なのか、対象企業や義務の有無、★3・★4の違いを整理したうえで、制度開始に向けて企業が今から進めておきたいセキュリティ対策を解説します。

サプライチェーン強化に向けたセキュリティ対策評価制度（以降、記事内「SCS評価制度」と表記）は、サプライチェーンに関わる組織のセキュリティ対策を共通基準で可視化する制度です。★3は専門家確認付き自己評価、★4は第三者評価と技術検証によって確認され、2027年3月頃の運用開始が予定されています。

※本記事の情報は2026年9月3日時点でIPA、経済産業省およびBBSecが公表している資料に基づいています。今後公表・更新される情報については、最新の公式資料をご確認ください。

SCS評価制度とは

SCS評価制度とは、組織が定めた適用範囲におけるIT基盤などのセキュリティ対策状況を共通の基準で評価し、段階別のマークによって可視化する制度です。2026年3月に公表された制度構築方針を基礎に設計され、経済産業省と内閣官房国家サイバー統括室の監督のもと、独立行政法人情報処理推進機構（IPA）が運営します。*1

この制度で想定されているのは、企業間の取引契約などにおいて、委託元が委託先に適切な段階（★）を提示し、その水準に応じた対策の実施状況を確認する使い方です。委託元は取引先のセキュリティ対策を共通基準で確認しやすくなり、委託先は複数の取引先から届く異なるチェックリストへ個別に回答する負担を軽減できると期待されています。

つまり、SCS評価制度の本質は企業を単純に格付けすることではなく、発注側と受注側がセキュリティ対策について共通の言葉で確認できるようにすることにあります。 ここでいうサプライチェーンは、製造業の部品供給網だけを指すものではありません。業務委託やITサービスの利用関係を含む「ビジネス・ITサービスサプライチェーン」を念頭に置いた制度です。委託先への攻撃による事業・サービスの停止、機密情報の漏えいや改ざん、取引先を踏み台とした不正侵入などのリスクを減らし、サプライチェーン全体のセキュリティ水準を高めることが制度の目的です。

なぜSCS評価制度が創設されたのか

企業の事業活動は、自社だけで完結するものではありません。クラウドサービスや外部のシステム運用、ソフトウェア開発、物流、決済など、さまざまな取引先とのつながりによって成り立っています。そのため、自社が対策を強化していても、委託先のシステムやアカウントを起点として被害が波及するおそれがあります。攻撃経路が取引先へ広がる一方で、対策確認のコストは発注側と受注側の双方に積み上がってきました。SCS評価制度は、この二つの問題を同じ共通基準で扱い、サプライチェーン上の立場やリスクに応じた対策を選びやすくするための仕組みです。

SCS評価制度はいつから始まるのか

IPAのFAQによると、SCS評価制度の★3・★4は、2027年3月頃の運用開始が予定されています。2026年4月には★3・★4の要求事項・評価基準が公開*2され、同年9月2日には、制度の基本規程や評価機関、技術検証事業者などに関する規則が公開・更新されました。*3

今後は、要求事項・評価基準の解説書、取得ガイド、申請方法が2026年10月頃に公開される予定です。★4の第三者評価を担当する評価機関は2026年12月末頃、★3の自己評価結果を確認するSCSセキュリティ専門家は2027年1月以降に公表される予定となっています。申請・登録にかかる費用は、2026年9月3日時点では公表されていません。

制度の詳細は今後も更新されるため、対応を検討する企業はIPAの公式サイトで最新情報を確認する必要があります。ただし、要求事項・評価基準はすでに公開されています。制度開始まで待つのではなく、現状とのギャップを把握し、時間のかかる対策から着手できる段階に入っています。

SCS評価制度の対象企業と義務の有無

SCS評価制度は、特定の業種や企業規模だけに限定されたものではありません。ビジネス・ITサービスサプライチェーンに関わる幅広い組織での活用が想定されています。ただし、すべての企業にマーク取得を法律で義務付ける制度ではなく、SCS評価制度自体は任意制度です。ここは「制度が任意であること」と「取引上求められる可能性があること」を分けて考える必要があります。

同制度では、二社間の取引契約などにおいて、委託元が委託先に適切な段階を提示する利用方法が想定されています。そのため、法令上の一律の義務ではなくても、取引条件や調達要件として特定の段階への対応を求められる可能性はあります。受注側の企業にとっては、取引先から問い合わせを受けてから準備を始めるのではなく、自社の対策状況を説明できる状態にしておくことが重要です。

SCS評価制度の★3・★4・★5の違い

SCS評価制度では、企業に求めるセキュリティ対策を段階別に示します。先行して運用されるのが★3と★4で、より高度なサイバー攻撃への対応を想定する★5は、要求事項や評価方法、開始時期を含めて検討中です。IPAの公表資料に基づいて両段階を整理すると、次のようになります。

比較項目★3★4
想定する水準一般的なサイバー脅威に対処し得る水準初期侵入の防御に加え、被害拡大や攻撃目的の達成を抑え、取引先のデータやシステムの保護に寄与する水準
要求事項26項目43項目（★3の要求事項を包含）
評価方法SCSセキュリティ専門家の確認を受けた自己評価評価機関による第三者評価と技術検証
主な確認内容自己評価書類の確認と助言文書確認、実地審査、技術検証
有効期間登録完了の通知日から1年間登録完了の通知日から3年間。ただし、1年ごとに自己評価を実施

★3：専門家確認付きの自己評価

公表資料では、★3は「一般的なサイバー脅威に対処し得る水準」と位置づけられ、26の要求事項が設定されています。取得希望組織が行った自己評価を、制度に登録されたSCSセキュリティ専門家が確認・助言し、経営層による自己適合宣言などを添えてIPAへ申請します。単なる自己申告ではなく、すべての要求事項・評価基準を満たす必要があり、有効期間は1年間です。

★3で求められる26の要求事項・81の評価基準や、自己評価から登録までの流れについては、「SCS評価制度の★3とは？26の要求事項・81の評価基準と自己評価を解説」で解説しています。

★4：第三者評価と技術検証によって確認

★4は★3の要求事項を包含し、合計43の要求事項が設定されています。初期侵入を防ぐだけでなく、侵入後の被害拡大防止や、取引先のデータ・システムを守る対策までが求められます。評価機関による文書確認・実地審査に加え、評価機関または評価機関から委託された技術検証事業者による技術検証が行われます。有効期間は3年間ですが、有効期間中も1年ごとの自己評価が必要です。

★4で求められる43の要求事項や、第三者評価・技術検証の内容については、「SCS評価制度の★4とは？43の要求事項・第三者評価・技術検証と取得準備を解説」で解説しています。

★3を取得せずに★4を目指すことも可能

★4は★3の内容を包含していますが、★3を先に取得しなければ申請できない制度ではありません。自社のサプライチェーン上の役割や取引先から求められる水準を踏まえ、当初から★4を目指すこともできます。 ただし、★4では43の要求事項に加えて第三者評価と技術検証が行われます。準備負担や必要な期間を把握しないまま目標を決めるのではなく、まず自社の現状と不足事項を確認することが重要です。

自社は★3と★4のどちらを目指すべきか

目指す段階は、会社の規模だけで一律に決めるものではありません。SCS評価制度は、委託元が取引上のリスクに応じて委託先へ適切な段階を提示する使い方を想定しています。まず確認すべきなのは、主要な取引先や業界でどのような水準が求められそうか、自社の事業停止や情報漏えいが取引先へどの程度の影響を及ぼすかという点です。

取引先の機密情報や重要なシステムを扱う企業、障害が発生した際に取引先の事業継続へ大きな影響を与える企業では、より高い水準を求められる可能性があります。一方で、自社だけで段階を断定するのではなく、公開済みの要求事項を確認し、取引先との協議や専門家の助言を踏まえて判断するのが現実的です。

SECURITY ACTIONやISMSとの違い

SCS評価制度と混同されやすい仕組みに、IPAの「SECURITY ACTION」があります。SECURITY ACTIONは、中小企業が情報セキュリティ対策へ取り組むことを自ら宣言する制度です。IPAも、SCS評価制度の★3・★4を目指す準備段階としてSECURITY ACTIONを案内しています。一方、SCS評価制度では公開された要求事項への適合が必要となり、★3では専門家確認、★4では第三者評価と技術検証が加わります。

ISMSは、JIS Q 27001（ISO/IEC 27001）を基準として、組織が情報セキュリティマネジメントシステムを確立し、実施、維持、継続的改善しているかを第三者の認証機関が評価する仕組みです。これに対しSCS評価制度は、サプライチェーン上の取引で必要となる対策水準を段階別に可視化することを目的としています。

既存の制度に取り組んでいる企業は、これまで整備した規程やリスク管理の仕組みをSCS評価制度への準備に活用できる可能性があります。ただし、SCS評価制度で登録を受けるには、対象となる段階で定められたすべての要求事項・評価基準を満たす必要があります。ISMS認証やSECURITY ACTIONの宣言だけで、SCS評価制度の登録へ自動的に移行するものではありません。

SCS評価制度に向けて企業が今から進める対策

評価の適用範囲とIT資産を整理する

最初に行いたいのは、どの組織、拠点、システムを評価の適用範囲とするかを整理することです。SCS評価制度は、登録を希望する組織が定めた適用範囲内のIT基盤などを対象にします。サーバ、ネットワーク機器、端末、クラウドサービスなどのIT資産が把握できていなければ、要求事項への適合状況も正確に判断できません。

要求事項と現在の対策との差を確認する

次に、公開済みの要求事項・評価基準と、自社の規程、システム設定、実際の運用を照合します。すでに実施している対策、証跡が残っていない対策、未対応の項目に分けると、課題が見えやすくなります。規程を作るだけでなく、決めたルールどおりに運用され、その実施記録を示せるかまで確認しておきたいところです。

優先順位を付けてロードマップを策定する

不足している対策を一度に整備しようとすると、現場の負担が大きくなります。規程の改定で対応できる課題と、ツール導入、システム変更、教育、訓練が必要な課題を分け、担当者、期限、予算を含むロードマップへ落とし込みます。特に★4を目指す場合は、対策を日常業務へ組み込み、実施記録や証跡を継続的に残せる状態が欠かせません。

適用範囲の設定からギャップ分析、是正計画、証跡の整備まで、具体的な準備の進め方については、「SCS評価制度への対応は何から始める？ギャップ分析から是正・運用定着まで」で解説しています。

制度開始前の準備には専門的な支援も有効

SCS評価制度への対応では、要求事項を読むだけでなく、評価範囲の設定、現状分析、規程と実運用の確認、是正計画の策定を並行して進める必要があります。社内だけでは判断が難しい場合、制度開始前に外部の専門家を活用し、自社の現在地を客観的に把握する方法があります。

BBSecでは、SCS評価制度の運用開始に備えた事前対策支援サービスを提供しています。公開済みの★3・★4要求事項に沿って行った事前点検の結果をコンサルタントが分析し、評価サマリーと対策ロードマップを提供する「★3/★4自己評価対応支援（プレリミナリーサーベイ）」のほか、★4の要求事項と既存対策との差を文書確認やインタビューで整理する取得準備支援、策定したロードマップに沿って対策の実行を支援する「★3/★4準拠に向けた対策実行支援（BBSec Prime for Supply Chain Security Measures）」を用意しています。

これらは、SCS評価制度の正式な登録やマーク付与そのものではなく、評価取得に向けた現状把握、準備、是正・実装を支援するサービスです。★3の申請には、SCS評価制度へ登録されたセキュリティ専門家の確認が必要です。★4には、制度運営機関から指定を受けた評価機関による第三者評価と、評価機関または技術検証事業者による技術検証が必要です。その前段階で要求事項とのギャップを明らかにし、対応の手戻りを抑えるための選択肢となります。 ★3・★4の要求事項と自社の現状との差を把握したい、対応ロードマップを整理したい、社内の人員だけでは是正が進まないといった課題がある場合は、制度開始を待たずにご相談ください。

SCS評価制度に関するよくある質問

▼ SCS評価制度はいつから始まりますか
▼ SCS評価制度への対応は義務ですか
▼ ★3と★4の違いは何ですか
▼ ★4を取得する前に★3の取得は必要ですか
▼ SCS評価制度の申請・登録費用はいくらですか

まとめ

SCS評価制度は、サプライチェーンを構成する企業のセキュリティ対策を共通基準で評価し、取引先へ説明しやすくする制度です。★3はSCSセキュリティ専門家の確認を受ける自己評価、★4は評価機関による第三者評価と技術検証という違いがあり、2027年3月頃の運用開始が予定されています。制度自体は任意ですが、取引先との契約や調達で活用されることが想定されています。公開済みの要求事項を確認し、適用範囲とIT資産の整理、現状とのギャップ分析、対策ロードマップの策定から準備を始めることが重要です。制度の開始時期を待つのではなく、自社が現在どこまで対応できているのかを把握することが、最初の一歩になります。

【参考情報】

編集責任：木下

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

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

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

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

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

最新情報はこちら

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に戻る

投稿日:

2026年2Q KEVカタログに見る攻撃トレンド ― 実際に悪用された脆弱性から読み解く攻撃者の狙い

Share
2026年2Q KEVカタログに見る攻撃トレンドアイキャッチ画像

前回記事では、2026年第2四半期（2Q）のKEVカタログを統計データから分析しました。本記事では、同期間にKEVへ追加された脆弱性のうち、実際の攻撃事例に着目。攻撃者が狙う製品の共通点や脆弱性の悪用方法を分析し、2026年2Qに見られた攻撃トレンドを読み解きます。

実際の攻撃事例から見える2026年2Qの特徴

2026年第2QにKEVへ追加された脆弱性のうち、具体的な攻撃事例が確認されているものを見ると、VPNやRMM（Remote Monitoring and Management）、メールサーバ、業務システム、開発ツールなど、さまざまな製品が攻撃対象となっています。一見すると異なる製品ですが、事例を横断すると共通点も見えてきます。特に注目したいのが、インターネットからアクセス可能なシステムや、侵害後に組織内部へのアクセスに利用できる管理系製品が狙われていることです。

攻撃者にとっては、こうした製品を侵害できれば、その先にある社内ネットワークへ侵入する足掛かりを得られます。つまり、狙われているのは単に「脆弱な製品」ではなく、侵害後の展開に利用価値の高い製品だと考えることができます。

さらに、開発環境やソフトウェアサプライチェーンを起点として、別の製品や利用者へ被害が連鎖する事例も見られました。以下では、代表的な事例から、こうした攻撃の特徴を詳しく見ていきます。

VPNや管理システムは「入口」として狙われる

象徴的な事例の一つが、Check Point Security GatewayのCVE-2026-50751です。この脆弱性は、非推奨となっているIKEv1を利用したRemote Access VPNなどに存在する認証回避の脆弱性で、攻撃者が有効なユーザーパスワードを持たなくてもVPNセッションを確立できる可能性があります。Check Pointは実際の悪用を確認しており、事例の一つには侵害後の活動にランサムウェア「Qilin」との関連性も確認されています*4。

VPNは本来、社外から安全に組織内部へ接続するための仕組みです。しかし、その認証機構自体が突破されれば、攻撃者にとっては社内ネットワークへの正規の入口に近い役割を果たしてしまいます。

同様の特徴は、Oracle PeopleSoft Enterprise PeopleToolsのCVE-2026-35273にも見られます。Google Threat Intelligence GroupとMandiantは、ShinyHuntersとして知られるUNC6240による攻撃でこの脆弱性と整合する悪用を確認しています*2。活動はOracleによるアドバイザリ公開前から観測されており、ゼロデイとして悪用されていたと分析しています。

狙われるRMM・リモート管理製品の脆弱性

同様に注意したいのがRMM製品です。2026年第2Qには、ConnectWise ScreenConnectのCVE-2024-1708や、SimpleHelpの複数の脆弱性もKEVへ追加されています。

SimpleHelpでは、CVE-2024-57726やCVE-2024-57728など、複数の脆弱性が確認されています。CVE-2024-57726では低権限の技術者アカウントから過剰な権限を持つAPIキーを作成して管理者権限へ昇格でき、CVE-2024-57728では管理者権限を得た攻撃者が細工したZIPファイルを利用して任意の場所へファイルを書き込み、コード実行につなげられる可能性があります。SimpleHelp自身も、これらの脆弱性を組み合わせることで、情報取得から権限昇格、最終的なコード実行までの攻撃チェーンが成立し得ると説明しています。

RMM製品は、管理者が複数の端末へ遠隔接続し、操作やソフトウェア配布などを行うための正規ツールです。そのため、攻撃者に侵害された場合、単にRMMサーバ自体が被害を受けるだけではありません。正規の管理機能が、侵入後のアクセス維持や別端末への展開に悪用される可能性があります。

これらの事例に共通するのは、侵害後に組織内部へアクセスしやすい製品が攻撃対象になっていることです。攻撃者にとって重要なのは、脆弱性そのものの深刻度だけではありません。その製品を侵害した後に「どこまでアクセスできるか」「次の攻撃へつなげられるか」という点も、標的を選ぶうえで重要な要素になっていると考えられます。Microsoftが報告したStorm-1175の活動でも、この特徴が明確に表れています。

既知の脆弱性を使い分けるランサムウェア攻撃

Storm-1175は、ランサムウェア「Medusa」を展開する金銭目的の攻撃者です。Microsoftによると、同グループはインターネット上に公開された脆弱なシステムを探索し、主に公開済みのNデイ脆弱性を悪用して初期侵入した、といいます*3。侵入後は情報窃取などを行い、数日以内、場合によっては24時間以内にランサムウェア展開まで進むことが確認されています。Storm-1175の特徴は、特定の製品や一つの脆弱性だけを狙っているわけではない点です。

Nデイ脆弱性についてはこちらの記事でも解説しています。あわせてぜひご覧ください。
「定期的な脆弱性診断でシステムを守ろう！-放置された脆弱性のリスクと対処方法-」

Microsoftの調査では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数の製品の脆弱性が初期侵入に利用されていました。2026年第2四半期にKEVへ追加された脆弱性にも、これらの活動で利用されたものが複数含まれています。侵入後には、新しい管理者アカウントを作成してアクセスを維持し、PowerShellやPsExecなどのツールを使用してネットワーク内部へ展開します。さらに、RMMツールを永続化やペイロード配布、横展開などに利用し、認証情報の窃取やセキュリティ機能の妨害を経て、最終的にMedusaランサムウェアを展開するという攻撃の流れが確認されています。

この事例から見えてくるのは、攻撃者が特定のCVEだけに固執するのではなく、外部から侵入可能な複数の脆弱性を使い分け、その時点で利用できるものを入口としているという実態です。つまり、一つの注目度の高い脆弱性だけに対応しても、別のインターネット公開システムに悪用可能な脆弱性が残っていれば、そこが新たな侵入口になる可能性があります。

開発環境も攻撃対象に ― サプライチェーン経由の侵害

もう一つ、2026年第2Qで注目したいのが、一般的なWebサーバやVPNへの脆弱性攻撃とは異なるソフトウェアサプライチェーン経由の攻撃です。CVE-2026-45321として登録されたTanStackのサプライチェーン侵害では、正規のnpmパッケージとして悪意あるバージョンが公開されました。悪意あるコードは、AWSやGCPなどのクラウド認証情報、GitHubトークン、npmトークン、SSH秘密鍵など、開発環境に保存されているさまざまな認証情報を窃取する機能を持っていました。さらに、この侵害は別の製品にも波及しました。

Nx ConsoleのCVE-2026-48027では、悪意あるバージョンのVS Code拡張機能が公開され、ディスクやメモリ上の認証情報を収集するペイロードが実行されました。Nxの調査によると、開発者の一人がTanStackに関連するサプライチェーン攻撃の影響を受け、流出したGitHub認証情報がNx Consoleの不正公開につながったとされています*4。

つまり、ある開発ツールの侵害 → 認証情報の窃取 → 別プロジェクトの侵害 → 正規ソフトウェアを通じた被害拡大、という連鎖が生じたことになります。

Nx Consoleの悪意のあるバージョンは、Visual Studio Marketplaceでは約18分間公開されていました。短時間で削除されたとしても、ソフトウェアの自動更新や正規マーケットプレイスへの信頼を利用した攻撃では、その間に利用者へ影響が及ぶ可能性があります。 これは、境界機器の脆弱性を突いて社内へ侵入する攻撃とは異なります。正規の配布経路や信頼された開発者アカウントそのものが攻撃経路になるため、「正規のアップデートだから安全」という前提だけでは防ぎにくい点が特徴です。

2026年2Qの事例から見えた3つの攻撃トレンド

今回の事例を横断すると、三つの特徴が見えてきます。

第一は、攻撃者が侵害後の展開に利用しやすいシステムを入口としていることです。VPNやRMMなどは外部からアクセス可能であるだけでなく、組織内部への接続や複数端末の管理といった機能を持っています。そのため、侵害されると、その正規機能自体が次の攻撃段階へ進むための足掛かりになり得ます。第二は、攻撃者が複数の既知脆弱性を使い分けていることです。Storm-1175の事例では、PaperCut、Microsoft Exchange Server、ConnectWise ScreenConnect、JetBrains TeamCity、SimpleHelp、BeyondTrustなど、複数製品のNデイ脆弱性が初期侵入に利用されていました。重要なのは、個々の脆弱性の新旧だけではなく、攻撃者が外部から侵入可能なシステムを探し、その時点で利用可能な脆弱性を入口としている点です。第三は、攻撃対象が組織の境界から開発環境やソフトウェアサプライチェーンへも広がっていることです。TanStackとNx Consoleの事例では、一つの認証情報の侵害が別のソフトウェアへ連鎖し、正規の配布経路を通じて被害が広がるリスクが示されました。

これらに共通するのは、攻撃者にとっての「侵害後の価値」です。外部から到達できるか、高い権限や重要な認証情報を得られるか、さらに別のシステムへアクセスできるかといった条件が、攻撃対象を考えるうえで重要になっていると考えられます。

まとめ

2026年第2四半期にKEVへ追加された脆弱性の実際の悪用事例を見ると、統計データだけでは見えにくい攻撃者の行動が浮かび上がってきます。VPNやRMMなどの管理系システムを足掛かりとした侵入、既知の脆弱性を使い分けて短期間でランサムウェア展開まで進む攻撃、そして開発環境から別のソフトウェアへ被害が連鎖するサプライチェーン攻撃など、攻撃経路は多様化しています。こうした事例を見るうえで重要なのは、「どのCVEが危険なのか」だけでなく、その製品やシステムが侵害された場合、攻撃者が次に何をできるのかという視点です。実際の悪用事例と自組織のIT資産を照らし合わせ、インターネットへの公開状況や権限、他システムとの接続関係まで含めてリスクを捉えることが、攻撃の早期発見や被害拡大の防止につながります。

【参考情報】

編集責任：木下

BBSecでは

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

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

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

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

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

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

    • 最新情報はこちら

    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。
    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万件以上のファイルを公開し、個人情報も含まれているとみられると報じました*5。ニチレイは追加で情報が公開されていることを把握しているものの、コメントを差し控えると回答したとされています。なお、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に戻る

    投稿日:

    【続報】KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えい―未知の脆弱性が原因

    Share
    KDDIメールシステムへの不正アクセス、約1,223万人のメールアドレス漏えいアイキャッチ画像

    2026年6月17日、KDDI株式会社は、ISP事業者向けに提供するメールシステムが不正アクセスを受けていたことを確認しました。この不正アクセスにより、約1,223万人分のメールアドレスと、そのうち約762万人分のパスワードが漏えいしました。原因は、ソフトウェアベンダーも把握していなかった第三者製ソフトウェアの脆弱性です。本記事では、確定した被害範囲とゼロデイ攻撃との関係、認証情報漏えいのリスク、企業が見直すべき対策を解説します。

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

    KDDIのISP向けメールシステムへの不正アクセスとは

    KDDIは2026年6月23日、同社がISP事業者向けに提供するメールシステムで不正アクセスが発生し、メール関連情報が外部に漏えいした可能性があると公表しました*6。初報で示されたのは、メールボックスにひもづくメールアドレスとパスワードの最大1,422万件です。この時点では調査中の最大値で、解約済みの利用者や一定期間利用されていない休眠アカウントも含まれていました。

    その後、KDDIは7月6日に調査結果を公表*2し、7月21日に対象人数を訂正しました。更新後の確定値は、メールアドレスが12,231,954人分、パスワードが7,616,173人分です。

    影響したISP事業者とメールサービス

    対象として公表されたのは6社です。STNetの「ピカラ光サービス」「ピカラモバイルサービス」「お仕事ピカラサービス」に係るメール、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメール、JCOMの「J:COM NET」とケーブルテレビ事業者向けメール、中部テレコミュニケーションの「コミュファ光」「ビジネスコミュファ」のメール、ニフティの「@niftyメール」、ビッグローブの「BIGLOBEメール」です。

    一方、KDDIは、auメール、UQ mobileメール、au one netメールについて、今回のシステムとは異なる設備で構築されており、本件による影響や情報漏えいはないと説明しています。「KDDIのメールが一律に被害を受けた」と広げて表現するのは適切ではありません。

    また、KDDIが示した全体人数は、6社すべてで同じ種類の情報が漏えいしたことを意味しません。事業者別の調査結果には差があり、たとえばJ:COM NET利用者についてJCOMが確認した漏えい情報はメールアドレスのみです。CPIについても、KDDIはパスワードそのものの漏えいはないと公表しています。一方、JCOMがケーブルテレビ事業者向けに提供するメールサービスでは、一部の利用者についてパスワード漏えいが確認されています。対象者は契約先の公式案内で、自分に該当する情報と必要な対応を確認することが重要です。

    2026年5月16日の発生から2026年7月の確定公表まで

    KDDIの調査では、不正アクセスは一部のISP事業者において2026年5月16日から発生していました。KDDIが不正アクセスを確認したのは6月17日で、同日に被疑箇所を特定し、システム改修と脆弱性への対処を実施しています。発生開始から確認までには約1か月の隔たりがあり、未知の脆弱性を突いた攻撃を早期に検知する難しさが表れています。

    確認後の対応として、KDDIは6月21日に、外部通信を制御する全サーバーへのEDR導入を完了しました。さらに6月23日、第三者機関によるフォレンジック調査を通じ、本件で悪用された脆弱性以外に不審な痕跡が存在しないことを確認したとしています。6月24日には総務省から電気通信事業法に基づく報告を求められ、7月6日に報告書を提出しました。

    利用者対応では、KDDIと各ISP事業者がメールアカウントのパスワード変更を進めました。7月6日の公表時点では、日常的に利用されているアカウントを中心に多数の変更が行われ、利用頻度の低いアカウントを含めてISP事業者による強制変更を進めていると説明されています。公表資料が示すのは当時の進捗であるため、その後の完了状況は各ISP事業者の最新案内で確認する必要があります。

    なぜ「ゼロデイ攻撃」と整理できるのか

    KDDIは公式資料で「ゼロデイ」という言葉を用いていません。ただし、悪用された脆弱性は、KDDIが不正アクセスを確認した2026年6月17日時点で、当該ソフトウェアのベンダーも認識していなかったと説明されています。

    米国国立標準技術研究所（NIST）は、「従来知られていなかったハードウェア、ファームウェア、ソフトウェアの脆弱性を悪用する攻撃」をゼロデイ攻撃と定義しています*3。この定義に照らせば、本件をゼロデイ脆弱性の悪用事例として整理することには根拠があります。

    ただし、KDDIの更新資料には、第三者製ソフトウェアの製品名、脆弱性の技術的詳細、CVE番号、攻撃者の属性は記載されていません。したがって、侵入手法や攻撃主体、脆弱性の深刻度を推測で補うべきではありません。現時点で確実に言えるのは、第三者製ソフトウェアの未知の脆弱性が悪用され、メールアドレスとパスワードの漏えいが確認されたことです。

    ゼロデイ攻撃では、公開済みの修正プログラムを適用するという通常の脆弱性管理だけでは初動時の防御が間に合いません。そのため、外部公開範囲の縮小、ネットワーク分離、権限の最小化、EDRやNDRによる挙動監視、外向き通信の監視、十分な期間のログ保全といった、脆弱性そのものに依存しない多層防御が重要になります。KDDIがシステム改修に加えてEDR導入とフォレンジック調査を実施した点も、検知と影響範囲確認の重要性を示しています。

    「サプライチェーン攻撃」ではなく、サプライチェーンリスクとして見る

    本件では第三者製ソフトウェアの脆弱性が悪用されましたが、これだけを根拠に、サプライチェーン攻撃と断定するのは慎重であるべきです。公表資料には、ソフトウェアベンダーの開発環境や更新配布経路が侵害され、悪意あるコードが供給されたという説明はありません。確認されているのは、KDDIのメール基盤に導入されていたソフトウェアの脆弱性が攻撃されたという事実です。

    一方で、サイバーセキュリティのサプライチェーンリスクという観点では重要な事例です。NIST SP 800-161 Rev.1は、組織が利用する製品やサービスを含むサプライチェーン全体について、リスクを特定、評価、低減することを求めています。自社システムであっても、その構成要素には商用ソフトウェア、OSS、クラウドサービス、保守事業者など多くの外部依存が含まれます。脆弱性が一つの共通基盤に存在すれば、直接の契約関係やサービス名称が異なる複数の利用者へ影響が広がり得ます。

    今回、6社のISP事業者が提供する複数ブランドのメールサービスに影響が及んだことは、共通基盤への集中が障害時や侵害時の影響範囲を大きくすることを示しました。各ISPが個別に侵入されたとする公表ではなく、共通して利用するメール基盤で発生した事案である点が重要です。サービス名や契約先だけを見てリスクを分けるのではなく、実際にどの基盤、製品、運用主体を共有しているかまで把握する必要があります。

    パスワード漏えいで警戒すべき二次被害

    確認された情報にはメールアドレスだけでなく、7,616,173人分のパスワードが含まれます。ただし、KDDIの初報は漏えいした可能性のあるパスワードについて、ハッシュ化または暗号化されたものも含むと説明しており、すべてが平文で保存されていた、あるいは直ちに不正ログインが成立したと読み替えることはできません。また、7月21日更新資料で「漏えいが確認された情報」として人数が示されたのはメールアドレスとパスワードで、メール本文や添付ファイルの漏えい確認について同資料に記載はありません。

    それでも、メールアドレスと認証情報の組み合わせは二次攻撃への備えが必要です。同じパスワードを他のサービスでも使い回していれば、漏えいした組み合わせを別サービスに試すパスワードリスト攻撃につながるおそれがあります。IPAは、パスワードを長く複雑にし、使い回さないことに加え、利用できるサービスでは多要素認証を設定するよう推奨しています。

    さらに、漏えいしたメールアドレスを宛先として、ISPやKDDIを装ったフィッシングメールが送られる可能性も考慮すべきです。ただし、これは将来のリスクに関する一般的な注意であり、本件を原因とするフィッシング被害や他サービスへの不正ログインが確認されたという意味ではありません。利用者への注意喚起では、確認済みの事実と想定されるリスクを混同しない表現が求められます。

    企業が見直すべき4つの実務ポイント

    外部依存と共通基盤の「影響半径」を把握する

    最初に必要なのは、導入している製品やサービスの一覧だけではなく、それぞれがどのデータにアクセスでき、どの顧客、事業、関連会社へ影響し得るかを結び付けて把握することです。SaaSやマネージドサービスの契約先が別々でも、背後で同じ認証基盤やメール基盤を共有している可能性があります。重要度、外部公開の有無、保存データ、依存先、代替手段、停止・侵害時の連絡先を整理し、共通基盤の事故が起きた場合の影響半径を平時から想定しておく必要があります。

    未知の脆弱性を前提に補完的統制を置く

    脆弱性管理は不可欠ですが、パッチが存在しない期間をゼロにはできません。インターネットから直接到達できる機能を最小限にし、管理系機能を分離し、サービスアカウントを含む権限を必要最小限に抑えることが基本です。加えて、EDRやNDR、WAFなどを環境に応じて組み合わせ、通常と異なるプロセス実行、大量のデータ参照、想定外の外向き通信を検知できる状態を整えます。未知の脆弱性を直接検知できなくても、悪用後の挙動を捉えられれば滞在時間と被害範囲を縮小できます。

    認証情報漏えい時の対応手順を事前に決める

    認証情報が漏えいした場合、対象者の特定、パスワードの強制変更、既存セッションやトークンの失効、不審なログインの調査、利用者への通知、問い合わせ対応を並行して進める必要があります。パスワード使い回しへの注意やフィッシング対策も同時に案内し、多要素認証を利用できる環境では導入を促すことが有効です。通知文面、意思決定者、関係部署、委託先との連絡経路をインシデント対応計画に組み込んでおけば、大規模なリセットが必要になったときの混乱を減らせます。

    休眠・解約済みアカウントをデータ管理の問題として扱う

    初報の最大件数には、解約済み利用者や一定期間使われていない休眠利用者も含まれていました。使われていないアカウントは、利用者が異常に気付きにくい一方、管理対象と漏えい時の対応負荷を増やします。法令、契約、事業上の必要性を踏まえて保存期間を定め、不要になったアカウントの無効化やデータ削除、匿名化を進めることが重要です。保持が必要な場合も、現役アカウントと同じ到達性や権限を残さず、用途に応じた分離と監視を行うべきです。

    対象サービスの利用者が確認すべきこと

    対象となるメールサービスの利用者は、まず契約中のISP事業者が公開する最新情報を確認してください。パスワード変更の案内がある場合は、メール本文のリンクからではなく、ブックマークや公式サイトから手続きページへアクセスする方が安全です。メールと同じパスワードを他のサービスで使っている場合は、そちらもサービスごとに異なるパスワードへ変更し、提供されていれば多要素認証を有効にします。不審なログイン履歴、転送設定、送信履歴がないかも確認し、身に覚えのない操作があればISPの公式窓口へ相談してください。

    よくある質問

    ▼ KDDIのauメールも今回の不正アクセスの対象ですか
    ▼ この事案はゼロデイ攻撃ですか
    ▼ サプライチェーン攻撃と呼んでよいですか

    まとめ：未知の脆弱性と共通基盤のリスクを分けて考える

    KDDIのISP事業者向けメールシステムへの不正アクセスは、12,231,954人分のメールアドレスと7,616,173人分のパスワードが漏えいした大規模インシデントです。しかし、注目すべきなのは件数だけではありません。ベンダーも把握していなかった脆弱性が悪用されたこと、一つの共通基盤を通じて複数のISPサービスへ影響が及んだこと、休眠・解約済み利用者を含む認証情報の対応が必要になったことが、企業の実務に直結する論点です。

    既知の脆弱性に迅速に対処する体制を整えたうえで、未知の脆弱性を前提とする監視と分離、外部依存関係と影響半径の把握、認証情報漏えい時の対応手順、不要データの削減を進める必要があります。サプライチェーン攻撃という言葉を安易に当てはめるのではなく、確認された事実と、そこから導ける共通基盤・外部依存のリスクを切り分けて検討することが、再発防止策を具体化する第一歩となるでしょう。

    【参考情報】

    編集責任：木下

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

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

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

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

    • 最新情報はこちら

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

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

    投稿日:

    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―

    Share
    APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―アイキャッチ画像

    APT攻撃は、企業や政府機関、研究機関などを標的に、長期間にわたって情報窃取や諜報活動を行う高度なサイバー攻撃です。侵入経路は標的型メールや脆弱性の悪用、サプライチェーン攻撃などさまざまで、被害は組織内にとどまらないこともあります。本記事では、国内外の代表的なAPT攻撃事例を紹介し、企業が学ぶべき教訓と対策のポイントを解説します。

    APT攻撃の定義や特徴について詳しく知りたい方は、まずこちらの記事をご覧ください。「APT攻撃とは？標的型攻撃との違いと企業リスクを解説【2026年版】」

    APT攻撃事例が注目される理由

    APT攻撃事例が注目されるのは、被害が一企業にとどまらず、取引先や顧客、社会インフラへ広がる可能性があるためです。APT攻撃では、標的となった組織の機密情報が盗まれるだけでなく、取引先、顧客、グループ会社、委託先、政府機関などへ影響が広がることがあります。特に近年のAPT攻撃では、サプライチェーンやクラウドサービス、リモートアクセス環境が狙われるケースが目立ちます。攻撃者は、最も守りが固い本丸を正面から攻撃するのではなく、比較的侵入しやすい周辺システムや取引先、公開サーバ、保守用アカウントなどを足がかりにします。

    また、APT攻撃は発見までに時間がかかることがあります。侵入直後に大規模な障害やランサムウェア被害が起きるとは限らず、攻撃者が長期間にわたって潜伏し、情報収集や権限拡大を続ける場合があります。そのため、事例を通じて攻撃の流れを理解し、侵入前の防御だけでなく、侵入後の検知や初動対応を整えることが重要です。

    APT攻撃の具体的な手口の流れは、こちらで解説しています。ぜひあわせてご覧ください。
    「APT攻撃の手口とは？侵入から情報窃取までの流れを解説」

    SolarWindsへのサプライチェーン攻撃（2020年12月）

    SolarWinds事件は、APT攻撃の代表的な事例として広く知られています。SolarWinds社が提供するIT管理ソフトウェア「Orion」の正規アップデートが攻撃に悪用され、利用組織に不正なコードが配布されたサプライチェーン攻撃です。この事件の特徴は、攻撃者がソフトウェアの利用企業を直接攻撃したのではなく、多くの組織が信頼して利用していた正規ソフトウェアの更新プロセスを悪用した点にあります。企業や政府機関にとって、利用中のソフトウェアベンダーから提供されるアップデートは、通常は信頼できるものとして扱われます。攻撃者はこの信頼関係を逆手に取り、正規の更新に紛れ込む形で侵入の足がかりを作りました。

    この事例から学べることは、「正規のアップデートだから安全」という前提そのものが攻撃対象になり得るということです。ベンダーのセキュリティ体制を確認するだけでは不十分で、正規プロセスを経た通信であっても、通常と異なる挙動（普段アクセスしない外部ホストへの通信など）を検知できる仕組みが必要になります。

    Microsoft Exchange Serverを狙った攻撃（2021年3月）

    Microsoft Exchange攻撃は、オンプレミス版のMicrosoft Exchange Serverに存在した複数の脆弱性が悪用された事例です。攻撃者は脆弱性を悪用してExchange Serverへアクセスし、メールアカウントへのアクセスや、長期的な侵入を可能にする追加のマルウェア設置を行っていました。これを受け、Microsoftは2021年3月、Exchange Serverを狙ったゼロデイ攻撃を公表し、セキュリティ更新プログラムの適用を強く呼びかけました*4。

    この事例の重要な点は、公開サーバの脆弱性がAPT攻撃の入口になり得ることです。メールサーバは多くの組織で外部と通信するために利用され、インターネットからアクセス可能な状態で運用されることがあります。そのため、脆弱性が存在すると、攻撃者にとって非常に価値の高い侵入経路になります。

    この事例から学べることは、「パッチを当てて終わり」にしてはいけないということです。すでに攻撃者が侵入していた場合、更新プログラムを適用しても、設置済みのバックドアや不正アカウントが残る可能性があります。実際、この攻撃では公表後も被害が拡大し、パッチ適用と並行した侵害有無の確認（ログ調査、IOC確認、認証情報のリセットなど）の重要性が浮き彫りになりました。

    日本企業を狙ったAPT攻撃

    APT攻撃は海外だけの問題ではありません。日本企業や日本の組織も、APT攻撃の標的になっています。日本を標的とするAPTグループとしては、APT10、Kimsuky、Lazarusなどが広く知られており、標的型メールやVPN機器の脆弱性悪用など複数の手口が確認されています。日本には、製造業、研究機関、重要インフラ、防衛関連、先端技術、金融、通信、行政機関など、攻撃者にとって価値の高い情報を持つ組織が多く存在します。そのため、技術情報、知的財産、政策関連情報、取引情報、認証情報などを狙った攻撃が継続的に確認されています。

    たとえば、APT10に関しては、内閣サイバーセキュリティセンター（NISC）2018年12月に注意喚起を行っています*2。APT10は、標的型メール攻撃や知的財産の窃取などとの関連で国際的に注目された攻撃グループです。

    またJPCERT/CCは2024年3月、日本組織を標的としたKimsukyの攻撃活動を公表しました*3。外交・安全保障関連組織を装った標的型メールを送付し、PowerShellを利用した情報窃取やキーロガーの展開など、侵入後に発見されにくい手口が確認されています。

    この事例から学べることは、国内拠点だけでなく、海外拠点やグループ会社、委託先も攻撃経路になり得るという点です。海外拠点では、本社と比べてセキュリティ人材や監視体制が不足している場合があります。攻撃者はそのような弱点を利用し、グループ全体のネットワークへ侵入しようとする可能性があります。本社だけでなく、グループ会社・海外拠点・委託先との接続点を含めたリスク管理が欠かせません。

    事例から見える共通点

    SolarWinds事件、Microsoft Exchange攻撃、日本企業を狙ったAPT攻撃には、それぞれ異なる背景があります。しかし、複数の事例を比較すると、いくつかの共通点が見えてきます。

    第一に、APT攻撃では信頼された経路が悪用されやすいという点です。SolarWinds事件では正規ソフトウェアの更新経路が悪用され、Microsoft Exchange攻撃では業務に不可欠なメールサーバが狙われました。日本企業を狙った攻撃でも、取引先や関係機関を装った標的型メール、VPNなどの業務上必要な接続経路が悪用されています。

    第二に、脆弱性や設定不備が侵入の足がかりになる点です。公開サーバやVPN、メールシステムなどに未修正の脆弱性が残っていると、攻撃者はそこから内部へ侵入できます。特に、悪用が確認された脆弱性への対応が遅れると、APT攻撃だけでなく、ランサムウェア攻撃や情報窃取にもつながる可能性があります。

    第三に、侵入後の発見が難しい点です。APT攻撃者は、正規アカウント、管理ツール、暗号化通信、業務時間帯の通信などを利用し、通常業務に紛れるように活動します。そのため、入口対策だけでは不十分であり、EDR、SIEM、ログ監視、認証ログの分析などを通じて、侵入後の異常を見つける体制が必要です。

    第四に、サプライチェーン全体へ被害が波及する可能性がある点です。サプライチェーン攻撃では、自社が侵害されることで取引先に被害が広がる可能性があります。逆に、取引先や委託先が侵害され、自社が被害を受けることもあります。

    事例から企業が学ぶべきこと

    3つの事例を通じて見えてくるのは、対策を個別の製品導入で終わらせず、「侵入されることを前提とした備え」を組織全体で作ることの重要性です。

    • SolarWinds事件からは、信頼している経路ほど疑う視点を持つ必要性
    • Microsoft Exchange攻撃からは、パッチ適用後も侵害有無を確認する姿勢の必要性
    • 日本企業を狙った攻撃からは、本社以外の拠点・委託先を含めたリスク管理の必要性

    いずれの事例にも共通するのは、「侵入を完全に防ぐ」だけではなく、「侵入後を見据えた検知・監視・対応体制」が被害の最小化につながるという点です。

    まとめ

    APT攻撃事例を見ると、攻撃者は標的組織へ直接侵入するだけでなく、ソフトウェア更新、公開サーバ、VPN、標的型メール、取引先、海外拠点など、さまざまな経路を悪用していることがわかります。SolarWinds事件はサプライチェーン攻撃のリスクを示し、Microsoft Exchange攻撃は外部公開システムの脆弱性管理の重要性を示しました。日本企業を狙ったAPT攻撃からは、国内組織も継続的に標的となっている現実が見えてきます。

    過去の攻撃事例は単なるニュースではなく、自社のセキュリティ対策を改善するための実践的な教材です。事例から学び、自社の弱点を具体的に見直すことこそが、APT攻撃の被害を最小限に抑える第一歩といえます。

    APT攻撃への備えでは、侵入前の対策だけでなく、侵入後の検知・監視・初動対応まで含めた多層的な対策が重要です。具体的な対策については、「APT攻撃対策とは？検知・監視・初動対応の考え方」で詳しく解説しています。

    【参考情報】

    編集責任：木下

    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ（BBSec）では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。

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

    最新情報はこちら

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

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

    投稿日:

    APT攻撃対策とは？検知・監視・初動対応の考え方

    Share
    APT攻撃対策とは？検知・監視・初動対応の考え方アイキャッチ画像

    前回記事で解説した通り、APT攻撃は標的組織を事前に調査したうえで侵入し、権限昇格や横展開を重ねながら目的の情報に近づいていきます。一度侵入を許すと長期間にわたり情報窃取や不正活動が継続するケースも少なくありません。そのためAPT攻撃対策では「侵入させない」ことだけを目指すのではなく、侵入前対策・侵入後対策・インシデント対応体制を組み合わせ、早期発見と被害最小化を実現する仕組みが欠かせません。本記事では、その具体的な対策内容について解説します。

    APT攻撃の侵入経路や攻撃の流れについて詳しく知りたい方は、「APT攻撃の手口とは？侵入から情報窃取までの流れを解説」で、初期侵入から情報窃取までのプロセスを解説しています。ぜひあわせてご覧ください。

    なぜAPT攻撃は防ぎにくいのか

    APT攻撃が防ぎにくい理由は、攻撃者が特定の組織を狙い、時間をかけて侵入経路を探すためです。一般的なマルウェア感染やばらまき型攻撃とは異なり、APT攻撃では、攻撃者が標的組織の業務、取引先、利用システム、従業員の役割などを事前に調査します。そのうえで、標的型メールや脆弱性の悪用、正規アカウントの不正利用など、検知されにくい手口を選びます。また、APT攻撃では、最初の侵入後すぐに目立つ被害が発生するとは限りません。攻撃者は内部ネットワークに潜伏し、権限昇格や横展開を行いながら、機密情報や認証情報の所在を探ります。正規の管理ツールや盗まれたID・パスワードを使って活動する場合もあり、従来型の境界防御だけでは不審な動きを見落とす可能性があります。そのため、APT攻撃対策では、入口を守る対策に加えて、侵入後の異常を検知する仕組み、ログをもとに調査できる体制、被害を最小化する初動対応が欠かせません。さらに、入口対策だけでなく、「侵入を前提」とした検知・監視・対応体制も必要です。

    侵入前対策

    APT攻撃への備えとして、まず重要になるのは侵入前対策です。侵入前対策とは、攻撃者が組織内へ入り込む可能性を下げるための基本的な防御策です。完全な防御は難しいものの、攻撃者にとって侵入しにくい環境を作ることで、被害の発生確率を下げることができます。 なかでも重要なのが、多要素認証、脆弱性管理、標的型メール対策です。これらは単独ではなく、多層防御の考え方で組み合わせることが重要です。複数の対策を組み合わせ、攻撃者が一つの弱点を突破しても、次の段階へ進みにくい状態をつくることが求められます。

    MFA（多要素認証）

    IDとパスワードだけに頼らず、スマートフォンアプリ、セキュリティキー、生体認証など、複数の認証要素を組み合わせて本人確認を行う仕組みです。APT攻撃では、フィッシングメールやマルウェアによって認証情報が盗まれることがあります。IDとパスワードだけで社内システムやクラウドサービスへアクセスできる環境では、攻撃者が正規ユーザになりすましてログインするリスクが高まります。MFAを導入することで、パスワードが漏えいした場合でも、不正ログインを防げる可能性が高まります。ただし、MFAを導入すればすべての攻撃を防げるわけではありません。近年は、MFAを突破しようとするフィッシングや、認証疲れを狙った攻撃も確認されています。そのため、可能であればフィッシング耐性の高い認証方式（例:FIDO2、パスキーなど）を採用し、管理者アカウントやリモートアクセス、クラウド管理画面など、重要度の高い環境から優先的に適用することが重要です。

    脆弱性管理

    APT攻撃では、VPN機器、公開サーバ、メールサーバ、業務システム、クラウド環境などの脆弱性が侵入経路として悪用されることがあります。特に、インターネットからアクセス可能な機器やシステムに未修正の脆弱性が残っている場合、攻撃者にとって侵入の足がかりになります。脆弱性管理では、単に脆弱性情報を収集するだけでなく、自社のどのシステムに影響があるのか、外部公開されているのか、悪用事例があるのか、業務上の重要度は高いのかを踏まえて、対応の優先順位を決める必要があります。すべての脆弱性へ同時に対応することは現実的ではないため、実際に悪用されている脆弱性や、外部から攻撃可能なシステムを優先して修正する考え方が重要です。また、パッチ適用がすぐに難しい場合には、一時的な回避策、アクセス制限、監視強化、不要サービスの停止などを組み合わせる必要があります。APT攻撃では、脆弱性の放置が初期侵入や横展開につながる可能性があるため、脆弱性管理は単なる情報システム部門の運用作業ではなく、経営リスクを下げるための重要な取り組みといえます。

    標的型メール対策

    標的型メールは、APT攻撃の代表的な侵入経路の一つです。現在はメールだけでなく、チャットやクラウドサービスを悪用した攻撃も増えています。標的型メール対策では、メールセキュリティ製品による検査だけでなく、従業員教育、訓練、報告しやすい仕組みの整備が重要です。攻撃メールを完全に遮断することは難しいため、従業員が不審なメールに気づき、開封前または開封後すぐに報告できる体制を作る必要があります。また、メールをきっかけに認証情報が入力されるケースもあるため、MFAやアクセス制御と組み合わせて対策することが効果的です。標的型メール対策は、単独で完結するものではなく、認証管理、端末防御、ログ監視、インシデント対応と連動させることで、初めてAPT攻撃への実効性が高まります。

    標的型攻撃の手口の詳細は「標的型攻撃とは？代表的な手口と企業が取るべき対策を解説」をご参照ください。

    侵入後対策

    APT攻撃では、侵入前対策をすり抜けられる可能性があります。そのため、侵入後に攻撃者の活動を検知し、被害拡大を防ぐ仕組みが必要です。侵入後対策の中心になるのが、EDR、SIEM、ログ監視です。従来のセキュリティ対策では、外部からの攻撃を境界で防ぐことに重点が置かれてきました。しかし、クラウド利用、テレワーク、サプライチェーン連携が広がる現在では、社内と社外の境界があいまいになっています。APT攻撃への対策では、端末、サーバー、ネットワーク、クラウド、IDの動きを継続的に監視し、通常とは異なる振る舞いを早期に見つけることが重要です。

    EDR

    EDRは、Endpoint Detection and Responseの略で、PCやサーバーなどのエンドポイント上の不審な挙動を検知し、調査や対応を支援する仕組みです。APT攻撃では、マルウェアの実行、認証情報の窃取、管理ツールの悪用、不審なプロセスの起動などが端末上で発生することがあります。EDRは、こうした端末上の動きを可視化し、攻撃の兆候を把握するために有効です。EDRの重要な役割は、単にマルウェアを検知することではありません。侵入後に何が起きたのか、どの端末からどの端末へ移動したのか、どのファイルが操作されたのか、どのアカウントが使われたのかを調査するための情報を提供する点にあります。APT攻撃では、発見時点で攻撃がすでに横展開している場合もあります。そのため、EDRによって端末単位の挙動を把握し、感染端末の隔離、プロセス停止、調査対象の特定などを迅速に行える状態を整えておく必要があります。最近では、EDRに加え、メールやクラウドも含めて分析するXDRを導入する企業も増えています。

    SIEM

    SIEMは、Security Information and Event Managementの略で、複数のシステムからログを集約し、相関分析(複数のログを組み合わせて関連性を分析すること)を行う仕組みです。APT攻撃では、個々のログだけを見ると小さな異常に見える行動が、複数のログを組み合わせることで攻撃の流れとして見えてくることがあります。たとえば、通常とは異なる国や地域からのログイン、深夜帯の管理者権限利用、短時間での大量アクセス、普段使わない端末からの認証、ファイルサーバへの大量アクセスなどは、単独では見逃されることがあります。しかし、SIEMで複数のログを関連付けることで、初期侵入、権限昇格、横展開、情報窃取の兆候を把握しやすくなります。SIEMを有効に活用するには、ログを集めるだけでなく、どのログを監視対象にするのか、どのような条件でアラートを出すのか、誰が確認するのか、アラート発生後にどのような初動を取るのかを事前に決めておく必要があります。そしてツールを導入するだけではなく、運用設計まで含めて整えることも重要です。社内で運用が難しい場合は、SOCサービスなど外部監視サービスを利用する方法もあります。

    ログ監視

    ログ監視は、APT攻撃対策の基盤となる取り組みです。攻撃者の行動は、認証ログ、端末ログ、プロキシログ、DNSログ、VPNログ、クラウドサービスの監査ログ、ファイルアクセスログなどに痕跡として残ることがあります。しかし、ログが取得されていなかったり、保存期間が短かったり、必要な項目が記録されていなかったりすると、インシデント発生後に攻撃の流れを追跡できません。特にAPT攻撃では、侵入から発見までに時間がかかることがあるため、一定期間のログを保管し、過去にさかのぼって調査できる状態を作る必要があります。ログ監視では、単に大量のログを保存するだけでは不十分です。重要なのは、通常時のアクセス傾向を把握し、そこから外れた動きを見つけることです。普段アクセスしないサーバーへの接続、短時間での権限変更、退職者アカウントの利用、海外からのVPN接続、大量のファイル圧縮や外部送信など、攻撃の兆候となる行動を継続的に確認する必要があります。保持期間は法令や業種要件、インシデント対応を考慮して決める必要があります。

    ゼロトラストの考え方

    ここまで紹介した侵入前対策・侵入後対策は、いずれもゼロトラストという一つの考え方の実装例と捉えることができます。

    ゼロトラストとは、社内ネットワークにいるから安全、正規ユーザだから安全といった前提を置かず、ユーザ、端末、アプリケーション、データへのアクセスを継続的に確認する考え方です。従来の境界防御では、社内ネットワークの内側を比較的信頼する考え方が一般的でした。しかし、APT攻撃では、一度内部へ侵入した攻撃者が正規アカウントや管理ツールを悪用し、横展開する可能性があります。そのため、社内ネットワーク内の通信であっても、常に正当性を確認し、必要最小限の権限だけを付与することが前提になります。ゼロトラストの実現には、MFA、ID管理、端末管理、アクセス制御、ログ監視、ネットワーク分離、継続的なリスク評価などが関係します。単一の製品を導入すれば完成するものではなく、組織の業務やシステム構成に合わせて段階的に整備していく必要があります。

    APT攻撃への対策としてゼロトラストを取り入れることで、攻撃者が一つのアカウントや端末を悪用しても、重要情報へ簡単に到達できない環境を作りやすくなります。侵入を前提に、被害範囲を限定し、異常を早期に検知するという点で、ゼロトラストはAPT対策と相性のよい考え方です。

    インシデント対応体制

    APT攻撃への対策では、検知した後の初動対応によって被害の大きさが大きく左右されます。初動対応では「封じ込め（Containment）」「根絶（Eradication）」「復旧（Recovery）」の順で進める考え方が一般的です。不審な挙動を発見しても、対応手順や判断基準が決まっていなければ、関係者への連絡、端末隔離、証拠保全、外部報告、復旧判断が遅れてしまいます。その間に攻撃者が横展開を進めたり、情報を外部へ持ち出したりする可能性があります。

    インシデント対応体制では、まず「誰が判断するのか」を明確にする必要があります。情報システム部門、セキュリティ担当、経営層、法務、広報、事業部門、外部専門家など、関係者の役割を事前に決めておくことが重要です。特にAPT攻撃では、技術的な調査だけでなく、事業影響、顧客対応、取引先対応、法的対応、広報対応が必要になる場合があります。 また、初動対応では、証拠を消さないことも重要です。感染が疑われる端末をすぐに初期化してしまうと、侵入経路や攻撃範囲を調査するための情報が失われる可能性があります。端末の隔離、ログ保全、アカウント停止、通信遮断、影響範囲の確認などを、状況に応じて慎重に実施する必要があります。平時からインシデント対応手順を整備し、訓練を行っておくことで、実際の攻撃発生時に混乱を減らすことができます。APT攻撃対策は、技術的な防御だけではなく、組織としてどのように判断し、対応するかまで含めた取り組みです。

    まとめ

    APT攻撃対策では、侵入を完全に防ぐことだけを目指すのではなく、侵入前対策、侵入後対策、インシデント対応体制を組み合わせることが重要です。MFA、脆弱性管理、標的型メール対策によって侵入リスクを下げ、EDR、SIEM、ログ監視によって侵入後の不審な動きを早期に検知します。さらに、インシデント対応体制を整備し、攻撃が疑われる場合に迅速な初動対応を取れるようにしておくことで、被害の拡大を抑えることができます。APT攻撃は、攻撃者が時間をかけて目的達成を狙う攻撃であるため、企業側も継続的な監視と改善を前提に備える必要があります。

    次の記事はこちら
    「APT攻撃事例から学ぶ ―国内外の被害事例と企業が取るべき対策―」
    APT攻撃は実際にどのような企業・組織で発生しているのでしょうか。代表的な国内外の事例から、攻撃の特徴や企業が学ぶべきポイントを解説します。

    【参考情報】

    編集責任：木下

    APT攻撃への備えをご検討中の方へ

    APT攻撃は、侵入を完全に防ぐことが難しい高度なサイバー攻撃です。侵入経路の把握や脆弱性管理、監視体制の強化など、継続的な対策が求められます。弊社、ブロードバンドセキュリティ（BBSec）では、脆弱性診断、アタックサーフェス管理調査、セキュリティ運用サービス、コンサルティングサービスなど、企業のセキュリティ対策を支援するサービスを提供しています。

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

    最新情報はこちら

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

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