EDR

2026年8月27日2026年8月27日

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再委託先まで把握する

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

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

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

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

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

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

まとめ

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

参考情報

NIST SP 800-161 Rev.1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, https://csrc.nist.gov/pubs/sp/800/161/r1/final
NIST SP 1305, NIST Cybersecurity Framework 2.0: Quick-Start Guide for Cybersecurity Supply Chain Risk Management (C-SCRM), https://csrc.nist.gov/pubs/sp/1305/final
CISA,Information and Communications Technology Supply Chain Risk Management, https://www.cisa.gov/information-and-communications-technology-supply-chain-risk-management
CISA,StopRansomware Guide,https://www.cisa.gov/stopransomware/ransomware-guide

編集責任：木下

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

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

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

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

最新情報はこちら

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

2026年8月21日2026年8月27日

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月時点）

BleepingComputer,Foxconn confirms cyberattack claimed by Nitrogen ransomware gang（https://www.bleepingcomputer.com/news/security/electronics-giant-foxconn-confirms-cyberattack-on-north-american-factories/）
WIRED,Foxconn Ransomware Attack Shows Nothing Is Safe Forever,（https://www.wired.com/story/foxconn-ransomware-attack-shows-nothing-is-safe-forever/）
Focus Taiwan,Foxconn confirms cyberattack on North American facilities,（https://focustaiwan.tw/business/202605130008）
NIST SP 800-161 Rev. 1,Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations,（https://csrc.nist.gov/pubs/sp/800/161/r1/upd1/final）
CISA,Information and Communications Technology Supply Chain Risk Management,（https://www.cisa.gov/information-and-communications-technology-supply-chain-risk-management）

編集責任：木下

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

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

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

最新情報はこちら

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

2026年7月23日2026年9月4日

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

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

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

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

DDoS攻撃とは

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

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

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

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

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

DoS攻撃との違い

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

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

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

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

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

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

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

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

DDoS攻撃の仕組み

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

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

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

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

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

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

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

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

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

攻撃の流れ

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

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

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

DDoS攻撃の主な種類

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

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

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

ボリューム攻撃

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

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

プロトコル攻撃

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

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

アプリケーション層攻撃

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

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

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

DDoS攻撃による被害

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

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

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

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

サービス停止

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

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

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

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

業務への影響

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

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

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

企業の信頼低下

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

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

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

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

通信の監視と異常検知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

【関連記事】

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

【参考情報】

Cloudflare「Cloudflare DDoS Protection」（https://developers.cloudflare.com/ddos-protection/）
Cloudflare「DDoSブースター／IPストレッサーとは？｜DDoS攻撃のツール」（https://www.cloudflare.com/ja-jp/learning/ddos/ddos-attack-tools/ddos-booter-ip-stresser/）
AWS「AWS Best Practices for DDoS Resiliency」（https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/aws-best-practices-ddos-resiliency.html）

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

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

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

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

編集責任：木下

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

2026年7月23日2026年7月27日

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を狙ったゼロデイ攻撃を公表し、セキュリティ更新プログラムの適用を強く呼びかけました*1。

この事例の重要な点は、公開サーバの脆弱性が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攻撃対策とは？検知・監視・初動対応の考え方」で詳しく解説しています。

【参考情報】

CISA,Active Exploitation of SolarWinds Software,2020/12/14（https://www.cisa.gov/news-events/alerts/2020/12/13/active-exploitation-solarwinds-software）
CISA,ED 21-01: Mitigate SolarWinds Orion Code Compromise (Closed),2020/12/13（https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise）
JPCERT/CC,What We Can Do against the Chaotic A41APT Campaign, Hajime Yanagishita, Kiyotaka Tamada, You Nakatsuru, Suguru Ishimaru 2022/01/27,JSAC2022発表資料（https://jsac.jpcert.or.jp/archive/2022/pdf/JSAC2022_9_yanagishita-tamada-nakatsuru-ishimaru_en.pdf）
JPCERT/CC,A41APT case, Yusuke Niwa / Hajime Yanagishita / Charles Li / Suguru Ishimaru / Motohiko Sato 2020/01/28,JSAC2021発表資料,（https://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_202_niwa-yanagishita_en.pdf）

編集責任：木下

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

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

アタックサーフェス調査
SQAT^® 脆弱性診断
G-MDR^®
※外部サイトにリンクします。
インシデント初動対応準備支援
※外部サイトにリンクします。

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

最新情報はこちら

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

2026年7月22日2026年7月22日

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は、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攻撃は実際にどのような企業・組織で発生しているのでしょうか。代表的な国内外の事例から、攻撃の特徴や企業が学ぶべきポイントを解説します。

【参考情報】

NIST,Cybersecurity Framework（https://www.nist.gov/cyberframework）
NIST,The NIST Cybersecurity Framework 2.0（https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf）
NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile（https://csrc.nist.gov/pubs/sp/800/61/r3/final）
NIST SP 800-207,Zero Trust Architecture（https://csrc.nist.gov/pubs/sp/800/207/final）
NIST,Zero Trust Architecture（https://www.nist.gov/publications/zero-trust-architecture）
CISA,Known Exploited Vulnerabilities Catalog（https://www.cisa.gov/known-exploited-vulnerabilities-catalog）
CISA,Best Practices for Event Logging and Threat Detection（https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection）
CISA,Incident Response Plan Basics（https://www.cisa.gov/sites/default/files/publications/Incident-Response-Plan-Basics_508c.pdf）
CISA,Incident Response（https://www.cisa.gov/topics/cyber-threats-and-response/incident-response）
CISA,Cybersecurity Incident & Vulnerability Response Playbooks（https://www.cisa.gov/sites/default/files/2024-08/Federal_Government_Cybersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf）

編集責任：木下

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

アタックサーフェス調査
SQAT^® 脆弱性診断
G-MDR^®
※外部サイトにリンクします。
インシデント初動対応準備支援
※外部サイトにリンクします。

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

最新情報はこちら

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

2026年7月16日2026年7月23日

IT資産管理を効率化する方法とは？担当者が押さえたい運用のポイント

IT資産管理を継続するには、台帳を作成するだけでは十分ではありません。定期的な棚卸しや資産台帳の整備、ツールの活用、運用ルールの見直しなど、継続して管理できる仕組みづくりが重要です。本記事では、IT資産管理を効率化するための基本ステップと、実務で押さえたい運用のポイントを解説します。

IT資産管理の基本について知りたい方は、まず「IT資産管理とは」をご覧ください。
「IT資産管理とは？企業のセキュリティ対策で最初に取り組むべき理由を解説」

IT資産管理は重要だと分かっていても、実際の運用では「台帳が更新されない」「管理対象が多すぎる」「クラウドやSaaSまで把握しきれない」といった悩みが起こりがちです。特に、少人数の情報システム部門や兼任体制の企業では、手作業だけでIT資産を正確に管理し続けるのは現実的ではありません。

IT資産管理で押さえるべき基本ステップ

IT資産管理を効率化するには、いきなりツールを導入するのではなく、基本ステップを整理することが大切です。最初に行うべきことは、管理対象の範囲を決めることです。PC、サーバー、ネットワーク機器、スマートフォン、タブレット、ソフトウェア、クラウドサービス、SaaS、アカウント、ライセンスのうち、どこまでをIT資産管理の対象にするのかを明確にします。次に、現在のIT資産を棚卸しします。棚卸しによって、台帳に載っていない端末、使われていないSaaS、放置されたクラウド環境、サポート期限が近いソフトウェアなどを洗い出します。その後、資産台帳を整備し、資産の種類、利用者、管理責任者、重要度、バージョン、サポート期限、最終確認日などを記録します。

棚卸しを定期的に行う

IT資産棚卸しは、IT資産管理の出発点です。棚卸しでは、以下のような複数の情報源を突き合わせます。ひとつの情報源だけに頼ると、見落としが発生しやすいため、複数の情報を照合することが重要です。

購買台帳・リース契約
MDM／EDR
Active DirectoryやID管理基盤
クラウド管理画面
SaaSの契約情報 – ネットワーク接続情報

たとえば、購買台帳には存在するのにEDRには表示されない端末があれば、未セットアップ、未接続、廃棄漏れの可能性があります。逆に、EDRやネットワーク上には存在するのに購買台帳や資産台帳にない端末があれば、未登録端末や持ち込み端末の可能性があります。クラウド環境では、誰が作成したか分からないインスタンス、公開設定のまま放置されたストレージ、検証後に削除されていないリソースを確認します。棚卸しの頻度は、企業規模やIT環境によって異なりますが、少なくとも年1回の一斉棚卸しだけでは変化に追いつきにくくなっています。端末の入れ替え、SaaS契約、クラウド環境の作成など、変化が多い領域については、月次や四半期単位で確認する運用が望ましいでしょう。

どのような資産が見落とされやすいかについては「見落としがちなIT資産がセキュリティ事故を招く？企業で起こりやすい5つの管理課題」もあわせてご覧ください。

資産台帳を整備する

棚卸しで見つけたIT資産は、資産台帳に整理します。台帳は、単に資産名を並べるためのものではありません。脆弱性対応、パッチ適用、ライセンス管理、費用管理、インシデント対応に使える情報でなければ、実務では役に立ちません。資産台帳には、資産ID、資産種別、製品名、メーカー、OSやソフトウェアのバージョン、利用者、所属部門、管理責任者、設置場所、IPアドレス、利用目的、業務上の重要度、保存・処理する情報の種類、サポート期限、ライセンス情報、最終確認日などを記録します。すべてを最初から完璧に埋める必要はありませんが、脆弱性対応やインシデント対応に必要な項目は優先して整備するべきです。

NIST SP 1800-5では、有効なIT資産管理は物理資産と仮想資産を結びつけ、資産が何で、どこにあり、どのように使われているかを把握できるようにするものと説明されています。この視点を踏まえると、台帳は固定的な一覧ではなく、現場の利用実態を反映する情報基盤として設計する必要があります。

ツールで自動化する

IT資産管理を効率化するうえで、ツールによる自動化は有効です。管理対象が少ないうちは手作業でも対応できますが、端末、クラウド、SaaS、アカウント、ソフトウェアが増えると、人手だけで最新状態を維持するのは難しくなります。IT資産管理ツールを使えば、端末情報、インストール済みソフトウェア、OSバージョン、利用者情報、接続状況などを自動収集しやすくなります。MDMはモバイル端末やPCの管理に役立ち、EDRは端末の稼働状況やセキュリティ状態の把握に活用できます。クラウド環境では、クラウド管理ツールやCSPMによって、リソース、設定、公開状態、権限の可視化を進められます。SaaSについては、ID管理基盤やSaaS管理ツールと連携し、利用アカウントや不要ライセンスを確認します。

IT資産管理ツールによって可視化した資産情報は、脆弱性管理にも活用できます。資産台帳とスキャン結果を結びつけることで、どの資産にどの脆弱性が存在するのかを把握しやすくなります。

運用ルールを整備する

IT資産管理は、ツールを導入するだけでは定着しません。新しい端末を購入したとき、SaaSを契約したとき、クラウド環境を作成したとき、従業員が異動・退職したとき、機器を廃棄したときに、誰が、いつ、どの情報を更新するのかを決めておく必要があります。

ライフサイクル管理

調達から廃棄までのライフサイクルにIT資産管理を組み込むことも重要です。購入申請時に資産登録を行い、利用開始時に管理責任者を設定し、定期的に利用状況を確認し、不要になったらアカウント停止やデータ消去、契約解除、廃棄証跡の保管まで行う。この流れが決まっていないと、台帳はすぐに古くなります。

シャドーIT対策

シャドーIT対策では、禁止だけでなく申請しやすい仕組みも必要です。現場が必要なツールを安全に使える申請ルート、承認済みSaaSの一覧、例外利用時の確認項目を整備することで、非公式な利用を減らしやすくなります。英国のサイバーセキュリティ機関NCSCも、「シャドーITは従業員が業務上の課題を解決しようとして発生することが多く、責めるのではなく、報告しやすいセキュリティ文化を作ることが重要」だと説明しています*4。

IT資産の可視化を脆弱性管理やパッチ管理につなげる

近年では、社内で管理しているIT資産だけでなく、インターネット上に公開されている資産を継続的に把握・管理するために、ASM（Attack Surface Management）を活用する企業も増えています。

IT資産の可視化はゴールではありません。可視化した資産情報を、脆弱性管理やパッチ管理につなげることが重要です。NIST SP 800-40 Rev.4では、パッチ管理を、パッチやアップデートを識別し、優先順位付けし、取得し、適用し、適用結果を検証するプロセスとして説明しています。その前提として、どの資産が存在し、どのソフトウェアやバージョンを利用しているかを把握している必要があります。たとえば、重大な脆弱性が公開された場合、資産台帳が整備されていれば、対象バージョンを利用している端末やサーバーをすばやく抽出できます。重要システム、外部公開システム、個人情報を扱うシステムなどを優先して対応する判断も可能になります。逆に、資産情報がなければ、全社に一斉確認を依頼するしかなく、対応に時間がかかります。

IT資産管理、脆弱性管理、パッチ管理は別々の業務ではなく、つながった運用として設計することが重要です。IT資産を把握し、リスクを評価し、優先順位をつけ、対策し、結果を確認する。この流れができて初めて、セキュリティ対策は継続的に機能します。

まとめ：効率化の目的は、管理を楽にすることではなく対応を早くすること

IT資産管理を効率化する目的は、単に運用負荷を減らすことではありません。IT資産を継続的に把握し、脆弱性への対応やインシデント発生時の初動対応を迅速に行える状態を維持することが重要です。そのためには、定期的な棚卸しや資産台帳の整備、ツールによる自動化、運用ルールの見直しを組み合わせ、自社のIT環境に合わせた継続的な運用を構築しましょう。

【参考情報】

CIS（Center for Internet Security）「The 18 CIS Critical Security Controls」（https://www.cisecurity.org/controls/cis-controls-list）

【関連記事】

編集責任：木下

公開IT資産を可視化してみませんか？

社内で管理しているIT資産と、インターネット上から見える資産は必ずしも一致しません。攻撃者視点で公開資産を可視化する「アタックサーフェス調査サービス」をご紹介します。

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

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

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

2026年7月1日2026年7月1日

サッポロHD海外2社に不正アクセス ―海外グループ会社を狙うサイバー攻撃リスクとは

サッポロホールディングスが公表した海外グループ会社2社への不正アクセスは、海外拠点を狙ったサイバー攻撃リスクを改めて浮き彫りにしました。現時点では情報漏洩の有無や影響範囲は調査中ですが、海外子会社や現地法人のセキュリティがグループ全体の事業継続や信頼に影響を及ぼす可能性があります。本記事では、本件の概要を整理するとともに、海外拠点が攻撃の入口になりやすい理由や、企業が見直すべき認証管理、ログ監視、脆弱性管理などの対策について解説します。

※本記事は2026年6月30日までに公開された情報もとに作成しています。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

サッポロホールディングス株式会社は2026年6月24日、同社の海外グループ会社2社のシステムに対して不正アクセスが発生したことを公表しました*2。対象となったのは、POKKA PTE. LTD.とSLEEMAN BREWERIES LTD.です。サイバー攻撃の恐れがある不正な通信ログを検知し、初動調査を行った結果、不正アクセスが判明したとされています。

今回の事案で注目すべきなのは、国内本社ではなく海外グループ会社で不正アクセスが確認された点です。企業のグローバル展開が進むなか、海外子会社、海外拠点、現地法人、委託先、販売会社などを含めたセキュリティ対策は、もはや一部門だけの問題ではありません。サイバー攻撃は、もっとも守りが弱い場所から侵入し、グループ全体の信頼や事業継続に影響を及ぼす可能性があります。サッポロホールディングスの公表によると、POKKA PTE. LTD.では2026年6月14日、SLEEMAN BREWERIES LTD.では同年6月17日に不正アクセスを確認しています。安全確保のため、関係するシステムや機器は遮断され、外部専門家の協力のもと原因や影響範囲の調査が進められています。公表時点では、情報漏洩の事実および影響範囲は確認中であり、国内事業への影響は確認されていません。また、2社への不正アクセスについて、現時点で因果関係は認められていないとされています。

サッポロHDの海外グループ会社で何が起きたのか

今回の不正アクセスは、サッポロホールディングスの海外グループ会社であるPOKKA PTE. LTD.とSLEEMAN BREWERIES LTD.において確認されました。POKKA PTE. LTD.は海外飲料事業、SLEEMAN BREWERIES LTD.は海外酒類事業に関係する企業です。サッポロホールディングスは海外酒類事業を北米中心に展開しており、海外飲料事業ではシンガポール、マレーシア、中東など約60か国でPOKKAブランドを展開していると説明しています。

このことから、今回の事案は単なる「海外拠点のトラブル」として片付けるべきものではありません。企業が海外展開を進めるほど、システム、ネットワーク、アカウント、取引先、現地運用体制は複雑になります。国内本社のセキュリティレベルが高くても、海外子会社や現地拠点の監視体制、認証管理、端末管理、ログ管理が十分でなければ、攻撃者にとって侵入口になり得ます。ただし、現時点で公表されている情報からは、ランサムウェア攻撃であったか、特定の攻撃グループが関与したか、どのような情報が外部に流出したかは確認できません。したがって、本件を「情報漏洩事故」や「ランサムウェア被害」と断定することは避ける必要があります。一次ソースから確認できるのは、不正な通信ログの検知、不正アクセスの判明、関係システム・機器の遮断、外部専門家による調査、情報漏洩の有無は確認中という点です。

なぜ海外グループ会社はサイバー攻撃の入口になりやすいのか

海外グループ会社や海外子会社は、サイバー攻撃の入口になりやすい構造的なリスクを抱えています。理由の一つは、拠点ごとにIT環境やセキュリティ運用の成熟度が異なりやすいことです。本社ではEDR、ログ監視、多要素認証、脆弱性管理が整備されていても、海外拠点では現地事情や人員不足により、同じ水準の対策が実施されていないケースがあります。

もう一つの理由は、グループ会社が業務上、本社や他拠点とつながっていることです。販売、製造、物流、会計、メール、クラウドサービスなど、業務に必要な連携がある以上、一つの拠点への不正アクセスが、別拠点への攻撃や認証情報の悪用につながる可能性は否定できません。今回のサッポロホールディングスの発表では2社間の因果関係は認められていないとされていますが、企業一般のリスクとしては、海外拠点を含めたグループ全体のセキュリティ統制が重要になります。

独立行政法人情報処理推進機構（IPA）から公開された「情報セキュリティ10大脅威 2026」でも、組織向け脅威の上位に「サプライチェーンや委託先を狙った攻撃」が挙げられています。これは、攻撃者が必ずしも本丸である大企業や本社を直接狙うのではなく、関係会社、委託先、取引先、外部サービスなどを経由して侵入を試みるリスクが高まっていることを示しています。

不正通信ログの検知が示す「早期発見」の重要性

今回の公表で見落としてはならないのが、「サイバー攻撃の恐れがある不正な通信ログを検知した」という点です。不正アクセスは、必ずしも最初から目に見える被害として現れるわけではありません。ファイルが暗号化される、Webサイトが改ざんされる、顧客情報が公開されるといった被害が起きる前に、攻撃者がネットワーク内で探索や権限拡大を行っている場合があります。

そのため、企業にとって重要なのは、攻撃を完全に防ぐことだけではなく、異常な通信、不審なログイン、通常と異なる端末挙動を早期に見つける体制です。ログを取得していても、監視や分析ができていなければ、攻撃の兆候を見逃してしまいます。特に海外拠点では、時差、言語、現地ベンダーとの契約、運用担当者の違いにより、インシデントの発見や報告が遅れる可能性があります。不正アクセス対策では、ファイアウォールやウイルス対策ソフトだけでは不十分です。EDRによる端末監視、SIEMによるログ分析、SOCによる常時監視、ID管理、多要素認証、脆弱性診断、ペネトレーションテストなどを組み合わせ、攻撃を受けた場合でも早期に検知し、被害を最小化する考え方が求められます。

情報漏洩が確認されていない段階でも対応が必要な理由

サッポロホールディングスは、公表時点で情報漏洩の事実および影響範囲は確認中としています。ここで重要なのは、「漏洩が確認されていない」ことと「リスクがない」ことは同じではないという点です。サイバー攻撃では、外部送信の痕跡、認証情報の悪用、攻撃者の侵入経路、アクセスされたファイル、影響を受けたシステムを慎重に調査する必要があります。

調査中の段階では、企業は被害範囲を過小評価することも、過度に断定することも避けなければなりません。公表内容において「確認中」「影響が確認された場合は速やかに報告」といった表現が使われているのは、調査結果に基づいて正確に説明する姿勢の表れといえます。企業が同様の事案に備えるためには、インシデント発生後の連絡体制、初動対応手順、システム遮断の判断基準、外部専門家への相談ルート、顧客・取引先への説明方針を事前に整備しておくことが重要です。サイバー攻撃を受けてから対応を考えるのではなく、攻撃を受ける前提で準備しておくことが、事業継続と信頼維持につながります。

海外拠点を持つ企業が見直すべきセキュリティ対策

海外グループ会社や海外子会社を持つ企業は、まずグループ全体のIT資産を把握する必要があります。どの拠点にどのシステムがあり、誰が管理し、どのネットワークとつながっているのかが分からなければ、リスクの評価も対策の優先順位付けもできません。

次に重要なのが、認証情報の管理です。海外拠点のVPN、メール、クラウドサービス、業務システムに対して多要素認証を導入し、不要なアカウントや退職者アカウントを放置しないことが求められます。攻撃者は、脆弱性だけでなく、漏洩したID・パスワードや使い回された認証情報を悪用することがあります。

また、脆弱性管理も欠かせません。海外拠点では、本社の管理外にあるサーバ、ネットワーク機器、リモートアクセス環境、業務アプリケーションが残っている場合があります。定期的な脆弱性診断や外部公開資産の棚卸しを行い、攻撃者から見える入口を減らすことが重要です。

さらに、ログ監視とインシデント対応訓練も見直すべきです。不正通信ログを検知しても、その意味を判断できる人がいなければ対応は遅れます。検知、報告、遮断、調査、復旧、再発防止までの流れを整備し、海外拠点を含めて実効性を確認しておく必要があります。

サイバー攻撃対策は「国内本社だけ」では足りない

今回のサッポロホールディングスの事案は、海外グループ会社への不正アクセスとして公表されました。国内事業への影響は確認されていないとされていますが、企業にとっては、海外拠点を含むグループ全体のセキュリティを見直すきっかけになります。

サイバー攻撃は、企業規模や知名度に関係なく、システムの弱点、管理のすき間、監視の遅れを突いてきます。特に海外展開を進める企業では、本社、海外子会社、委託先、取引先、クラウドサービスを含めた全体像を把握し、どこから攻撃されても早期に検知・対応できる体制を作ることが欠かせません。不正アクセス、情報漏洩、ランサムウェア、サプライチェーン攻撃への備えは、もはや情報システム部門だけの課題ではありません。経営リスクとしてセキュリティを捉え、グループ全体で守る仕組みを整えることが、企業の信頼と事業継続を守るための第一歩です。

まとめ

サッポロホールディングスの海外グループ会社2社で確認された不正アクセスは、海外拠点を持つ企業にとって重要な示唆を含んでいます。公表時点では情報漏洩の有無や影響範囲は確認中であり、国内事業への影響も確認されていません。しかし、海外子会社や現地法人を含むグループ全体のセキュリティ管理が求められる時代であることは明らかです。

企業は、海外拠点のセキュリティ対策を現地任せにせず、IT資産の把握、認証管理、脆弱性診断、ログ監視、インシデント対応体制の整備を進める必要があります。攻撃を完全に防ぐことが難しい今、重要なのは、侵入の兆候を早く見つけ、被害を広げない仕組みを持つことです。サイバー攻撃対策を見直す際は、国内本社だけでなく、海外グループ会社、委託先、取引先、クラウド環境まで含めた全体像を確認することが欠かせません。今回の事案は、グローバル企業だけでなく、海外取引や外部委託を行うすべての企業にとって、自社のセキュリティ体制を点検する機会といえるでしょう。

【参考情報】

サッポロビール株式会社「当社の海外グループ会社２社のシステムへの不正アクセス発生について」（2026年6月24日公表）（https://www.sapporobreweries.com/notice/detail/20260624000010.html）

編集責任：木下

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

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

2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」

2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」

2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

最新情報はこちら

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

2026年6月26日2026年6月28日

インシデント対応体制とは？CSIRTの役割と企業が整えるべき運用のポイント

サイバー攻撃や情報漏えいなどのセキュリティインシデントでは、迅速かつ適切な対応が被害の拡大防止につながります。そのためには、担当者任せではなく、役割分担や連絡体制をあらかじめ整備しておくことが重要です。本記事では、インシデント対応体制の基本的な考え方をはじめ、CSIRTやSOCの役割、企業が体制を構築・運用する際のポイントを解説します。

インシデント管理の全体像については、以下の記事をご覧ください。
「セキュリティインシデント管理とは？企業が押さえるべき対応フローと体制の全体像」

サイバー攻撃や情報漏洩、ランサムウェア感染、不正アクセスなどのセキュリティインシデントは、発生してから担当者が個別に対応するだけでは十分に対処できません。インシデント対応では、技術的な調査や復旧だけでなく、経営判断、法務確認、顧客対応、広報対応、取引先との調整など、複数の部門が関係します。

そのため、企業にはあらかじめインシデント対応体制を整備しておくことが求められます。誰が異常を受け付け、誰が初動対応を判断し、誰が調査を進め、誰が経営層や外部関係者へ報告するのかが決まっていなければ、発生直後の混乱を避けることはできません。JPCERT/CCは「CSIRTマテリアル」について、組織的なインシデント対応体制である「組織内CSIRT」の構築を支援する目的で作成したものと説明しています。また、すべての組織が同じ形のCSIRTを持つべきというものではなく、それぞれの組織の状況に応じた適切な形があるとしています。つまり、インシデント対応体制は、大企業だけが整備する特別な仕組みではなく、企業規模や事業内容に応じて現実的に設計すべきものです。

なぜ体制が必要なのか

インシデント対応体制が必要な理由は、セキュリティインシデントが一部門だけで完結する問題ではないためです。たとえば、マルウェア感染が発生した場合、情報システム部門は端末隔離やログ調査を行います。しかし、個人情報漏洩の可能性があれば法務や個人情報保護の担当部門が関与し、顧客影響があれば営業やカスタマーサポートが対応し、外部公表が必要になれば広報や経営層の判断が必要になります。

不正アクセスやランサムウェア感染では、技術的な調査と同時に、事業継続の判断も必要になります。システムを停止するのか、どの業務を優先して復旧するのか、取引先へいつ説明するのかといった判断は、現場担当者だけで決められるものではありません。事前に体制がなければ、関係者への連絡が遅れ、対応の優先順位も曖昧になります。

NIST SP 800-61 r2「Computer Security Incident Handling Guide」でも、効果的なインシデント対応は複雑な取り組みであり、成功する対応能力を確立するには、計画とリソースが必要であるとされています。また、インシデント対応では、IT部門だけでなく、法務などの内部関係者や、外部のインシデント対応チーム、法執行機関などとの連携も想定されています。

体制がない企業では、インシデントが発生したときに「誰に報告すればよいか分からない」「誰が判断責任を持つのか分からない」「外部ベンダーに何を依頼すればよいか分からない」という状態になりがちです。平時であれば多少の確認不足は補えますが、インシデント発生時には時間が限られています。対応の遅れは、被害拡大や情報漏洩、事業停止、信用低下につながる可能性があります。

独立行政法人情報処理推進機構（IPA）が公開するプラクティス・ナビ「指示7 インシデント発生時の緊急対応体制の整備」の中で、CSIRT等の対応体制が整備されていないこと、証拠保全ルールや外部報告・公表ルールが定められていないこと、想定インシデントに応じた分析・対応手順がないこと、CSIRT業務が属人化していること、演習を行っていないことを課題として挙げています。

インシデント対応体制とは、単に担当者の名前を決めることではありません。発生時に必要な判断、作業、報告、連携を整理し、組織として動ける状態にすることです。対応体制が整っていれば、発生直後の混乱を抑え、被害拡大防止、原因調査、復旧、再発防止までを一貫して進めやすくなります。

インシデント対応体制の基本構成

インシデント対応体制は、企業規模や業種、システム構成によって異なります。ただし、多くの企業に共通する基本構成として、CSIRT、SOC、各部門の連携があります。これらはそれぞれ役割が異なり、単独で機能するものではありません。CSIRTは、インシデント対応を組織として進めるための中核的な役割を担います。インシデントの受付、事実確認、対応方針の調整、関係部門への連絡、外部機関や専門ベンダーとの連携、再発防止策の整理などを担うことが一般的です。企業によっては、専任組織として設置される場合もあれば、情報システム部門やセキュリティ担当者を中心に兼任体制で運用される場合もあります。SOCは、Security Operation Centerの略で、主に監視や検知、分析を担う機能です。EDR、SIEM、ファイアウォール、クラウド監査ログ、認証ログなどを監視し、不審な通信や挙動を検知します。SOCは、インシデントの兆候を早期に発見し、CSIRTや情報システム部門へエスカレーションする役割を持ちます。自社内にSOCを持つ企業もありますが、専門ベンダーのSOCやMDRサービスを活用する企業もあります。

各部門の役割も重要です。情報システム部門は、端末、サーバ、ネットワーク、クラウド環境の技術的対応を担います。法務部門は、個人情報保護法や契約上の責任、監督官庁への報告要否などを確認します。広報部門は、外部公表やメディア対応、顧客向け説明文の調整を担います。営業部門やカスタマーサポート部門は、顧客や取引先からの問い合わせ対応を担います。経営層は、事業停止や外部公表、重大なリスク判断について意思決定を行います。

これらの体制は、実際のインシデント対応フローの中で機能します。具体的な対応手順については、以下の記事で詳しく解説しています。
「インシデント対応フローとは？発生時に企業が取るべき手順と判断ポイント」

重要なのは、CSIRT、SOC、各部門の役割を分けるだけでなく、連携の流れを決めておくことです。SOCが検知したアラートを誰に報告するのか、CSIRTがどの基準で重大度を判断するのか、法務や広報をどのタイミングで巻き込むのか、経営層への報告基準は何かを定めておかなければ、体制図があっても実際には動きません。インシデント対応体制は、組織図上の箱を作ることではなく、実際に発生したときに機能する連絡・判断・対応の仕組みを作ることです。

CSIRTとは何か

CSIRTとは、Computer Security Incident Response Teamの略で、コンピューターセキュリティインシデントに対応するチームを意味します。JPCERT/CCによれば、CSIRTは「Computer Security Incident Response Team＝コンピューターセキュリティインシデントに対応するチーム」の略であると説明されています。CSIRTの役割は、単に技術的な調査を行うことだけではありません。組織内で発生したインシデントの情報を集約し、対応方針を整理し、関係部門をつなぎ、必要に応じて外部機関や専門ベンダーと連携することが重要な役割です。企業によっては、脆弱性情報の収集、注意喚起、セキュリティ教育、訓練、再発防止策の推進など、平時の活動もCSIRTが担う場合があります。

JPCERT/CCの公開する資料「組織内 CSIRT の役割とその範囲」では、組織内CSIRTの役割には違いがあり、インシデントへの直接対応、支援的対応、調整役としての対応などが示されています。つまり、CSIRTは必ずしもすべての技術対応を自ら行う必要はありません。企業の体制に応じて、現場対応を支援する立場、部門間を調整する立場、外部専門家との窓口になる立場など、現実的な役割を設計することが重要です。

CSIRTが必要とされる理由は、インシデント発生時に情報と判断を一元化するためです。インシデント対応では、端末の隔離、ログ調査、外部連絡、顧客説明、法務判断、復旧作業など、さまざまな対応が同時に発生します。これらが各部門でばらばらに進むと、情報の食い違いや判断の遅れが起こりやすくなります。CSIRTが中心となって情報を集約すれば、経営層への報告も整理しやすくなります。経営層が必要とするのは、単なる技術情報ではなく、事業への影響、顧客への影響、復旧見通し、法的・契約上のリスク、外部公表の必要性などです。CSIRTは、技術部門と経営判断をつなぐ役割を担うことで、インシデント対応を企業全体のリスク対応として進めやすくします。ただし、CSIRTは設置するだけでは機能しません。連絡先が古い、権限が曖昧、判断基準がない、訓練をしていない、担当者が兼任で実質的に動けないといった状態では、有事に十分な役割を果たせません。CSIRTの必要性を理解したうえで、自社の規模やリソースに合った運用を設計することが大切です。

体制が機能しない原因

インシデント対応体制が機能しない原因として、最も多いのが属人化です。特定の担当者だけがシステム構成を理解している、ログの確認方法を知っている、外部ベンダーとの連絡先を把握している、過去のインシデント対応の経緯を覚えているという状態では、その担当者が不在のときに対応が止まります。属人化は、日常業務では見えにくい問題です。詳しい担当者がいれば、普段のトラブルはその人が解決できてしまいます。しかし、インシデント発生時には、短時間で多くの判断と作業が必要になります。特定の個人に情報や判断が集中すると、対応速度が落ち、確認漏れや連絡漏れが起こりやすくなります。

IPAのプラクティス・ナビ「プラクティス7-4 CSIRT業務の属人化回避も兼ねたインシデントや脅威に関する情報の共有・蓄積」では、CSIRT業務の属人化回避を目的とした情報共有・蓄積の重要性を示しています。公開されている事例でも、CSIRT設立の中核だった従業員が退職した際に対応能力が低下し、その後、業務を属人化させない仕組みの整備が必要になったことが紹介されています。

もう一つの原因は、判断基準がないことです。どのアラートをインシデントとして扱うのか、どの段階でCSIRTを招集するのか、端末隔離やシステム停止を誰が判断するのか、外部報告や公表を検討する基準は何かが決まっていなければ、現場は迷います。判断基準がないと、対応は担当者の経験や感覚に依存します。経験豊富な担当者であれば適切に判断できる場合もありますが、担当者が変われば対応品質も変わります。また、重大なインシデントほど、技術的な判断だけでなく、事業影響や法務リスク、顧客影響を含めた判断が必要になります。判断基準が曖昧なままでは、経営層への報告も遅れやすくなります。

体制が機能しない企業では、形式的な体制図だけが存在していることもあります。CSIRTという名前はあるものの、実際のメンバー、役割、権限、連絡手順、訓練計画が決まっていない状態です。このような体制では、インシデント発生時に「誰が何をするのか」を改めて確認することになり、初動対応が遅れます。さらに、部門間の連携不足も大きな要因です。情報システム部門が技術対応を進めていても、法務や広報、営業、経営層への共有が遅れると、顧客説明や外部公表の準備が間に合いません。反対に、経営層や広報が十分な事実確認を待たずに情報発信を進めると、誤った説明につながる可能性があります。インシデント対応体制を機能させるには、体制図を作るだけでなく、情報共有の流れ、判断権限、報告基準、記録方法を具体化する必要があります。

体制構築のポイント

インシデント対応体制を構築するうえで重要なのは、まず対応フローを明確にすることです。検知、初動対応、調査、復旧、再発防止という流れの中で、誰がどの工程を担当するのかを整理します。たとえば、従業員からの不審メール報告を誰が受け付けるのか、SOCや監視サービスのアラートを誰が確認するのか、感染端末の隔離を誰が実施するのか、経営層への報告を誰が行うのかを定めます。このとき、細かすぎる手順書を作ることよりも、実際に使える判断ルールを整備することが大切です。インシデントは事案ごとに状況が異なるため、すべてを手順書通りに進められるとは限りません。だからこそ、重大度の判断基準、エスカレーション条件、外部連携の基準、証拠保全の原則、復旧判断の考え方を整理しておく必要があります。

IPA「サイバーセキュリティ経営ガイドライン Ver3.0 実践のためのプラクティス集第4版」では、インシデント発生時の緊急対応体制の整備として、司令塔としてのCSIRTの設置、従業員の初動対応の規定、想定されるインシデントに関するセキュリティ分析計画の事前策定、情報共有・蓄積、インシデント対応演習などが示されています。

次に重要なのが、訓練です。手順書や体制図を作っても、実際に動かしていなければ、有事に機能するとは限りません。インシデント対応訓練では、ランサムウェア感染、不正アクセス、情報漏洩、Webサイト改ざん、委託先からの侵害連絡など、想定シナリオをもとに、連絡、判断、報告、初動対応の流れを確認します。訓練では、技術対応だけでなく、経営層への報告、法務確認、広報文案の検討、顧客問い合わせへの対応、外部ベンダーへの連絡も含めて確認することが望ましいです。実際に演習してみると、連絡先が古い、判断者が不在時の代替ルートがない、ログの取得範囲が不足している、委託先との責任分界点が曖昧といった課題が見つかります。

体制構築では、外部リソースの活用も現実的な選択肢になります。すべての企業が専任CSIRTや自社SOCを持てるわけではありません。特に中堅・中小企業では、情報システム部門が日常業務とセキュリティ対応を兼任しているケースも多くあります。その場合は、外部SOC、MDR、インシデント対応支援ベンダー、フォレンジック調査会社、顧問弁護士、保険会社など、必要な支援先を平時から整理しておくことが重要です。ただし、外部委託すればすべて任せられるわけではありません。外部ベンダーが調査や監視を支援しても、最終的な事業判断、顧客対応、外部公表、再発防止策の実行は企業自身が行う必要があります。外部リソースは、自社の対応体制を補完するものとして位置づけることが大切です。

インシデント対応体制の整備は、情報漏洩対策全体の一部でもあります。あわせて以下の記事もご確認ください。
「情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―」

まとめ

インシデント対応体制とは、セキュリティインシデントが発生したときに、企業が組織として対応するための仕組みです。CSIRT、SOC、情報システム部門、法務、広報、営業、経営層などが連携し、検知、初動対応、調査、復旧、再発防止を進められる状態を整えることが重要です。CSIRTは、インシデント対応の司令塔や調整役として、情報を集約し、対応方針を整理し、関係部門や外部機関との連携を担います。SOCは、監視や検知、分析を通じて、インシデントの兆候を早期に発見する役割を持ちます。各部門は、それぞれの専門性に基づいて、技術対応、法務判断、顧客説明、広報対応、経営判断を担います。

一方で、体制は作るだけでは機能しません。属人化した対応、曖昧な判断基準、古い連絡先、訓練不足、部門間連携の弱さがあると、インシデント発生時に初動が遅れます。特に、誰が判断し、誰が報告し、誰が外部と連携するのかが曖昧な状態では、対応の品質は担当者個人に依存してしまいます。企業がまず取り組むべきことは、自社のインシデント対応フローを整理し、役割分担と連絡ルートを明確にすることです。そのうえで、重大度の判断基準、証拠保全ルール、外部報告・公表の検討基準、委託先や外部ベンダーとの連携方法を定め、定期的な訓練によって実効性を確認する必要があります。インシデント対応体制は、セキュリティ部門だけのための仕組みではありません。情報漏洩対策、事業継続、顧客信頼、経営リスク管理を支える重要な基盤です。自社の規模に合った現実的な体制から整備し、継続的に見直していくことが、インシデント発生時の被害最小化につながります。

【参考情報】

NIST（米国立標準技術研究所）NIST SP 800-61 Rev. 2「Computer Security Incident Handling Guide」（https://csrc.nist.gov/pubs/sp/800/61/r2/final）
JPCERT/CC「CSIRTガイド」（https://www.jpcert.or.jp/csirt_material/files/guide_ver1.0_20211130.pdf）

編集責任：木下

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

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

最新情報はこちら

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

2026年6月19日2026年6月22日

【企業のためのランサムウェア対策ガイド】ランサムウェアの攻撃手法とは – 侵入から暗号化までの流れを解説

ランサムウェアの攻撃手法とは - 侵入から暗号化までの流れを解説アイキャッチ画像

ランサムウェア攻撃は、単にファイルを暗号化するだけではありません。近年の攻撃では、侵入後に認証情報の窃取や権限昇格、社内ネットワーク内での横展開、重要データの窃取を経て、最終的に暗号化や二重恐喝へと発展するケースが一般的です。本記事では、ランサムウェア攻撃がどのような段階を経て進行するのか、その流れと企業が警戒すべきポイントを解説します。

ランサムウェアの基本的な仕組みや全体像については、以下の記事で整理しています。
「ランサムウェアとは何か ―企業が知るべき被害・仕組み・対策の基本―」

ランサムウェア攻撃は、単に「ウイルスに感染してファイルが暗号化される攻撃」ではありません。現在の企業向けランサムウェア攻撃では、攻撃者が社内ネットワークへ侵入し、認証情報を盗み、権限を広げ、重要データを持ち出し、最後にシステムやファイルを暗号化するという複数段階の流れをたどることが一般的です。特に近年は、暗号化だけでなく、事前に窃取したデータを公開すると脅す「二重恐喝」が多く確認されています。警察庁「サイバー空間をめぐる脅威の情勢等」の調査報告によると、近年のランサムウェア被害はデータを窃取したうえで「対価を支払わなければ公開する」と脅す二重恐喝が多くを占めるといいます。

ランサムウェア攻撃の全体像

ランサムウェア攻撃は、外部から突然暗号化プログラムが送り込まれて終わるものではありません。実際には、攻撃者が最初に侵入経路を確保し、その後に社内環境を調査し、より強い権限を持つアカウントを探し、重要なサーバやファイル共有へ移動しながら、最終的に暗号化や脅迫へ進む流れを取ります。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が公開している「#StopRansomware Guide」でも、ランサムウェアやデータ恐喝型攻撃への対策が初期侵入経路ごとに整理されています。本ガイドでは、インターネットに公開されたシステム、脆弱性、認証情報、リモートアクセス、メールなどが重要な観点として扱われています。つまり、ランサムウェア対策は、暗号化プログラムそのものを止めるだけでなく、攻撃の前段階をどこで検知し、どこで遮断するかが重要になります。攻撃の流れを理解すると、ランサムウェア対策の考え方も変わります。入口対策だけではなく、侵入後の不審な認証、権限昇格、横展開、データ窃取、バックアップ破壊、暗号化準備といった兆候を監視する必要があります。特に企業では、感染を完全に防ぐことだけに注力するのではなく、侵入された場合でも早期に発見し、被害拡大を防ぐ体制が求められます。

ランサムウェアの仕組みについては、以下の記事でより詳しく解説しています。
「ランサムウェアの仕組みとは ―感染から暗号化までの動きを解説―」

攻撃の流れ（フェーズ別）

侵入

ランサムウェア攻撃の最初の段階は、企業ネットワークへの侵入です。侵入経路としては、フィッシングメール、VPN機器の脆弱性、リモートデスクトップ、外部公開サーバ、認証情報の悪用、委託先や外部サービス経由のアクセスなどが挙げられます。

攻撃者は、必ずしも高度な手法だけを使うわけではありません。公開済みの脆弱性が修正されていないVPN機器や、外部公開されたリモートデスクトップ接続（RDP）、使い回されたパスワード、退職者の残存アカウントなど、基本的な管理不備が入口になることもあります。この段階で重要なのは、自社の外部公開資産を把握し、侵入口になり得る箇所を減らすことです。攻撃者から見えるサーバ、VPN、リモートアクセス環境、クラウド管理画面、ファイル共有サービスを把握できていなければ、侵入の兆候を見つけることも、優先的に対策することも難しくなります。

独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」でも、組織向け脅威として「ランサム攻撃による被害」が1位、「サプライチェーンや委託先を狙った攻撃」が2位に挙げられており、企業にとってランサムウェアと外部経由の侵入は継続的な重要課題とされています。

権限昇格

侵入に成功した攻撃者は、次により強い権限を得ようとします。一般ユーザの端末に入っただけでは、重要サーバの停止や大規模な暗号化を実行できない場合があるためです。そのため、攻撃者は端末内に保存された認証情報、ブラウザに残ったパスワード、管理ツールの接続情報、設定ファイル、共有フォルダ内の情報などを探します。

権限昇格が成功すると、攻撃者は管理者アカウントやドメイン管理者権限を悪用し、より広範囲のシステムへアクセスできるようになります。管理者権限を持つアカウントが日常業務にも使われている場合や、複数のサーバで同じ認証情報が使い回されている場合、攻撃者の行動範囲は一気に広がります。この段階を防ぐためには、管理者権限の最小化、特権アカウントの分離、多要素認証、不要アカウントの削除、認証ログの監視が重要です。ランサムウェア攻撃では、暗号化そのものより前に、認証情報の不正利用や通常とは異なるログインが発生していることがあります。その兆候を早く見つけることが、被害拡大を防ぐ鍵になります。

横展開（ラテラルムーブメント）

権限を得た攻撃者は、社内ネットワーク内を移動しながら、重要なサーバやデータの所在を探します。この動きを横展開、またはラテラルムーブメントと呼びます。横展開では、ファイルサーバ、業務システム、Active Directory、バックアップサーバ、仮想基盤、クラウド連携システムなどが調査対象になります。攻撃者は、どのシステムを暗号化すれば業務停止の影響が大きいか、どのデータを盗めば脅迫材料になるか、どのバックアップを破壊すれば復旧を困難にできるかを確認します。この段階では、社内通信の異常、管理者ツールの不審な利用、通常とは異なる時間帯のアクセス、複数端末への連続ログイン、ファイル共有への大量アクセスなどが兆候になります。しかし、正規のアカウントや管理ツールが悪用される場合、単純なウイルス対策ソフトだけでは検知が難しいことがあります。そのため、ランサムウェア対策では、EDRやログ監視、ネットワーク監視、認証基盤の監視を組み合わせ、侵入後の不審な行動を見つける考え方が重要になります。

データ窃取

近年のランサムウェア攻撃では、暗号化の前にデータを盗む手口が一般化しています。攻撃者は、顧客情報、従業員情報、契約書、財務情報、設計情報、取引先情報、メールデータなどを持ち出し、身代金交渉の材料にします。この手法が二重恐喝です。従来のランサムウェアは、ファイルを暗号化して「復号したければ身代金を支払え」と要求するものでした。しかし現在は、暗号化に加えて「盗んだデータを公開する」「取引先や顧客へ連絡する」と脅すケースが増えています。この段階で被害が発生すると、たとえバックアップからシステムを復旧できたとしても、情報漏洩対応、顧客説明、取引先対応、法的対応、信用低下への対応が必要になります。つまり、バックアップは重要ですが、バックアップだけでランサムウェア被害を完全に抑え込めるわけではありません。データ窃取を早期に検知するには、重要データへのアクセス監視、大量ダウンロードの検知、外部送信通信の監視、クラウドストレージやファイル共有サービスの利用状況確認が必要です。特に、通常業務では発生しない大量の圧縮ファイル作成や外部アップロードは、ランサムウェア攻撃の前兆として注意すべきです。

暗号化

攻撃の最終段階で、ランサムウェアによる暗号化が実行されます。攻撃者は、業務停止の影響が大きいサーバや共有フォルダ、端末、仮想基盤を対象にし、ファイルを暗号化します。同時に、バックアップを削除したり、復旧機能を無効化したり、セキュリティ製品を停止しようとする場合もあります。暗号化が始まると、業務システムが使えない、ファイルサーバにアクセスできない、受発注や出荷が止まる、社内の連絡体制が混乱するなど、事業継続に大きな影響が出ます。NIST（米国立標準技術研究所）が公開しているNIST IR 8374でも、重要業務の復旧優先順位、バックアップの保護、復旧手順のテスト、対応計画の整備が重要であると示されています。暗号化段階まで到達してからでは、被害をゼロに抑えることは難しくなります。そのため、企業のランサムウェア対策では、暗号化を検知する仕組みに加え、暗号化前の侵入、権限昇格、横展開、データ窃取を早期に見つけることが重要です。

なぜ攻撃を止められないのか

ランサムウェア攻撃を止められない大きな理由は、侵入から暗号化までの途中段階に気づけないことです。攻撃者は、正規のアカウントや管理ツールを悪用することがあります。その場合、単純に「不審なファイルがあるか」「既知のマルウェアが検出されたか」だけを見ていても、攻撃の進行に気づけない可能性があります。

また、権限管理の不備も被害を拡大させます。管理者権限を持つアカウントが多すぎる、退職者のアカウントが残っている、共有アカウントを使っている、重要サーバへのアクセス制限が甘い、といった状態では、攻撃者が一度侵入しただけで広範囲へ移動できてしまいます。

検知遅れの背景には、ログが残っていない、ログを見ていない、異常を判断する基準がない、担当者が限られている、休日や夜間の監視ができないといった運用面の課題もあります。セキュリティ製品を導入していても、アラートを確認する体制がなければ、攻撃の兆候を見逃す可能性があります。そのため、ランサムウェア対策では、技術対策だけでなく、運用体制の整備が欠かせません。誰がアラートを見るのか、どの条件で隔離するのか、どの段階で経営層へ報告するのか、外部専門家へいつ相談するのかを事前に決めておく必要があります。

企業が理解すべきポイント

企業がまず理解すべきなのは、ランサムウェア攻撃を完全に防ぐことは難しいという現実です。もちろん、脆弱性管理、メール対策、多要素認証、EDR、バックアップ、ネットワーク分離などの対策は重要です。しかし、攻撃手法は変化し続けており、外部委託先やクラウドサービス、認証情報の悪用など、自社だけでは完全に制御しにくい要素もあります。だからこそ、企業に求められるのは「侵入されないこと」だけを前提にした対策ではなく、「侵入される可能性を前提に、早期に検知し、被害を限定し、復旧できる体制」を整えることです。早期検知の観点では、通常とは異なるログイン、権限昇格、管理者ツールの不審な利用、複数端末への連続アクセス、大量のファイル操作、外部への大容量通信などを監視することが重要です。これらは、暗号化が始まる前に現れる可能性がある兆候です。

また、経営層はランサムウェアを単なるIT部門の問題としてではなく、事業継続、情報管理、顧客対応、法務、広報、取引先対応を含む経営リスクとして捉える必要があります。ランサムウェア攻撃は、システム停止だけでなく、情報漏洩、信用低下、売上損失、顧客離脱、サプライチェーンへの影響を引き起こす可能性があるためです。

ランサムウェアによって企業にどのような被害が発生するのかについては、次の記事で詳しく解説します。
「ランサムウェア被害の実態 – 業務停止・損害・企業が直面するリスクとは」

まとめ

ランサムウェア攻撃は、侵入、権限昇格、横展開、データ窃取、暗号化という複数の段階を経て進行します。暗号化は被害が目に見える最終段階であり、その前には攻撃者による認証情報の悪用、社内探索、重要データの特定、情報持ち出しが行われている可能性があります。近年は、データを暗号化するだけでなく、盗んだ情報を公開すると脅す二重恐喝が多く確認されています。そのため、バックアップを取得しているだけでは十分とはいえません。復旧できる体制に加え、データ窃取を防ぎ、早期に検知し、情報漏洩対応まで想定した準備が必要です。企業が取るべき対策は、入口対策、権限管理、ログ監視、EDR、脆弱性管理、バックアップ、インシデント対応体制を組み合わせた多層防御です。特に重要なのは、攻撃の流れを理解し、暗号化される前の段階で異常に気づくことです。ランサムウェア対策は、特定の製品を導入すれば終わるものではありません。攻撃者がどのように侵入し、どのように社内を移動し、どのようにデータを盗み、どのタイミングで暗号化するのかを理解したうえで、自社の弱点を継続的に見直すことが重要です。

【参考情報】

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）「#StopRansomware Guide PDF」（https://www.cisa.gov/sites/default/files/2025-03/StopRansomware-Guide%20508.pdf）
NIST（米国立標準技術研究所）「Ransomware Risk Management: A Cybersecurity Framework Profile」（https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8374.pdf）
NIST（米国立標準技術研究所）「Ransomware Risk Management Rev.1 Initial Public Draft」（https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8374r1.ipd.pdf）

編集責任：木下

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

2026年4月12日2026年5月7日

脆弱性対応とは？CVE対応とパッチ管理の実務フロー

脆弱性対応は、企業の情報システムを守るうえで避けて通れない業務です。新しい脆弱性は日々公開されており、それらの一部は実際に攻撃へ悪用されています。問題は、脆弱性の存在そのものではなく、自社に影響する脆弱性を見極められず、対応が遅れることです。脆弱性への初動が遅れれば、情報漏洩、業務停止、ランサムウェア感染など、企業活動に直結する被害へ発展しかねません。だからこそ、脆弱性対応は単なるパッチ適用ではなく、情報収集、影響調査、優先順位付け、修正、再確認までを含めた一連の実務として捉える必要があります。

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、脆弱性対応を含むvulnerability management（脆弱性管理）の目的を、脆弱性や悪用可能な状態の発生頻度と影響を減らすことだと整理しています。

企業の脆弱性管理については、以下の記事で詳しく解説しています。
「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順」

脆弱性対応とは

脆弱性対応とは、公開された脆弱性情報や自社で発見した弱点に対して、自社システムへの影響を調査し、必要な対策を選び、修正し、修正後の状態を確認する一連の対応を指します。ここで重要なのは、脆弱性対応が「脆弱性があるからすぐパッチを当てる」という単純な作業ではないことです。実務では、対象資産の把握、公開有無、業務影響、代替策の有無、停止可能時間、クラウドやOSSへの影響などを考慮しながら判断します。NISTも、パッチ管理を「パッチ、更新、アップグレードを識別し、優先順位を付け、取得し、適用し、その適用を確認するプロセス」と定義しており、単純な更新作業ではなく管理プロセスそのものとして扱っています。

脆弱性対応が重要視される理由のひとつは、公開された脆弱性の一部が現実に悪用されているからです。CISAは「KEVカタログ（Known Exploited Vulnerabilities）」で、実際に悪用が確認された脆弱性を定期的に公開しています。つまり企業に求められるのは、脆弱性情報を収集することだけではなく、「どれが今まさに危険なのか」「自社に関係するのか」を見極めて動くことです。脆弱性対応とは、攻撃の入口になりうる弱点を、優先順位をつけて現実的に潰していく運用だといえます。

CVEとは

脆弱性対応を進めるうえで、まず押さえておきたいのがCVEです。CVEはCommon Vulnerabilities and Exposuresの略で、公開された脆弱性や露出情報に対して一意の識別子を付ける仕組みです。米MITREはCVE Programの役割を、公開されたサイバーセキュリティ上の脆弱性を識別し、定義し、整理することだと説明しています。

また、NVD（米国国立脆弱性データベース）でもCVEを特定の製品やコードベースに対して識別された脆弱性の辞書・用語集として扱っています。つまりCVEは、世界中のベンダー、研究者、利用企業が同じ脆弱性を同じ名前で参照するための共通言語です。脆弱性対応を行う際には、まず対象となる脆弱性情報を正確に把握することが重要です。多くの脆弱性は CVE識別番号で管理されています。

CVEは世界中で共有される脆弱性情報の共通IDであり、企業のセキュリティ対策において重要な役割を果たします。CVEの仕組みや意味については、以下の記事で詳しく解説しています。
「CVEとは？共通脆弱性識別子の基本と管理方法を徹底解説」

実務では、CVE識別番号だけを見て終わりではありません。CVEは「何の脆弱性か」を特定するためのIDであり、深刻度や攻撃条件、自社への影響を判断するには、NVDやベンダーアドバイザリ、製品別のセキュリティ情報をあわせて確認する必要があります。NVDはCVEに対してCVSSなどの標準化データを付与し、脆弱性管理や自動化に使える情報を提供しています。そのため企業の脆弱性対応では、「まずCVEを把握し、次にNVDやベンダー情報で内容を確認し、自社資産と突き合わせる」という流れが基本になります。

CVSSスコアの見方

CVEを把握したあとに多くの担当者が見るのがCVSSスコアです。CVSSはCommon Vulnerability Scoring Systemの略で、脆弱性の深刻度を定性的・数値的に表すための標準的な指標です。NVDはCVSSについて、「脆弱性の重大度を示すための方法であり、リスクそのものを示すものではない」と明確に説明しています。つまり、CVSSが高いから必ず最優先、低いから後回しでよい、とは限りません。CVSSを確認するときは、まず「スコアの高さ」よりも「どういう条件で悪用されるか」に注目したほうが有効です。たとえば、ネットワーク経由で認証不要の攻撃が可能なのか、ローカル権限が必要なのか、ユーザ操作を伴うのかによって、現実の危険度は大きく変わります。

また同じCVSSでも、インターネットに公開された機器にある脆弱性と、閉域環境の限定的なシステムにある脆弱性では、優先度は異なります。NVDはCVSSv4.0をサポートしており*2、従来よりもきめ細かな評価が可能になっていますが、それでも「深刻度」と「自社のリスク」は同一ではありません。実際の脆弱性対応では、CVSSに加えて、公開状態、資産の重要度、業務影響、既存の緩和策、そして実悪用の有無まで見て判断する必要があります。特に、CISAのKEVカタログに掲載された脆弱性は、すでに悪用が確認されているという意味で、単なる理論上の脆弱性より一段重く扱うべきです。CVSSは脆弱性対応の出発点として有用ですが、最終判断は必ず自社環境に引きつけて行う必要があります。

脆弱性対応の手順

脆弱性対応の実務フローは、一般的に以下の流れで進みます。

脆弱性情報の収集
影響調査
優先順位決定
パッチ適用
再確認

まずに必要なのは、脆弱性情報を取りこぼさないことです。CVE、NVD、ベンダーのセキュリティアドバイザリ、クラウドベンダーの通知、CISAのKEVなどを継続的に確認し、自社に関係する情報を早めに捉える必要があります。CISAは、KEV Catalogを確認し、掲載された脆弱性の修正を優先することを強く推奨しています。

次に行うのが影響調査です。ここで重要になるのは、自社がどの資産を保有し、どのソフトウェアやクラウドサービスを利用しているかを把握していることです。脆弱性情報が公開されても、自社に対象製品があるかどうか分からなければ、対応そのものが始まりません。特にクラウド環境では、OSやミドルウェアだけでなく、コンテナイメージ、マネージドサービスの設定、アクセス権限なども確認対象になります。クラウドでは共有責任モデルが採用されており、利用企業が管理すべき範囲は依然として広く残ります。

三つ目は優先順位決定です。ここではCVSSだけでなく、インターネット公開の有無、認証要否、既知の悪用状況、業務停止時の影響、代替策の有無を踏まえて判断します。たとえば、CVSSが高くても外部到達性がなく緩和策が効いているものより、CVSSがそこまで高くなくても既知悪用されている公開資産の脆弱性のほうが先に対処すべき場合があります。NISTのパッチ管理ガイドでも、識別だけでなく優先順位付けと検証まで含めてプロセスとして扱うことが示されています。

その後に実施するのが修正です。多くの場合はパッチ適用やバージョン更新になりますが、常にそれだけではありません。ベンダー修正がまだ出ていない場合や、即時適用が難しい場合には、設定変更、アクセス制限、機能停止、ネットワーク分離、WAFやEDRなどによる補完策を検討する必要があります。CISAも、回避策はあくまで暫定手段であり、公式パッチが利用可能になったら移行するのが望ましいと案内しています。

最後に必要なのが再確認です。パッチを適用したつもりでも、適用漏れ、再起動未実施、対象誤認、別系統サーバーの取り残しなどは珍しくありません。NISTはパッチ管理の定義の中に「検証」を含めています。つまり脆弱性対応は、適用作業で終わりではなく、修正が有効に反映され、サービスへの悪影響がないことまで確かめて完了します。

クラウド環境では、OSやミドルウェアの更新だけでなく、クラウドサービスの設定やコンテナイメージの更新なども脆弱性対応に含まれます。また、近年はOSSライブラリに含まれる脆弱性が問題となるケースも増えています。SBOMを利用することで、自社システムに影響するOSS脆弱性を迅速に特定できます。NTIA（米国商務省電気通信情報局：National Telecommunications and Information Administration）はSBOMを「ソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録」と説明しています。ただし、公開されている脆弱性情報だけでは、自社のシステムにどの脆弱性が存在するのかを完全に把握することはできません。そのため多くの企業では、脆弱性スキャンツールや脆弱性診断を用いてシステムの安全性を確認します。

脆弱性スキャンの仕組みや診断方法については、以下の記事で詳しく解説しています。
「脆弱性スキャンとは？脆弱性診断ツールの選び方と導入ポイント」

パッチ管理のベストプラクティス

パッチ管理のベストプラクティスを考えるうえで大切なのは、パッチ適用を場当たり的な更新作業にしないことです。NISTはenterprise patch management（エンタープライズ向けパッチ管理）を、識別、優先順位付け、取得、適用、検証までを含むプロセスとして定義しています。この考え方に沿うなら、ベストプラクティスとは「早く当てること」だけではなく、「誰が、何を、どの順で、どこまで確認して実施するか」を事前に決めておくことになります。

まず重要なのは、資産台帳とパッチ対象の対応関係を明確にしておくことです。対象サーバー、業務端末、ネットワーク機器、クラウド上のワークロード、仮想マシン、コンテナイメージなどが整理されていなければ、どこにパッチを適用すべきか判断できません。NISTの実装ガイドでも、日常時と緊急時の両方に対応するには、資産把握とパッチ適用の仕組みが必要だと示されています。

次に欠かせないのが、テストと本番適用の切り分けです。重大な脆弱性だからといって、影響の大きい基幹系に無検証で更新をかけるのは危険です。一方で、テストに時間をかけすぎて攻撃されるのも問題です。したがって実務では、対象の重要度や公開状況に応じて、緊急パッチ、通常パッチ、代替策併用のように運用レベルを分ける設計が現実的です。CISAの資料でも、パッチ管理計画、テスト、バックアップ、ロールバックを含めた準備の重要性が示されています。

さらに、近年のパッチ管理ではOSSライブラリの更新管理が欠かせません。アプリケーション本体に問題がなくても、依存するライブラリやフレームワークに脆弱性があれば、そのままリスクになります。そこで有効なのがSCAやSBOMです。SBOMによって依存関係を把握しておけば、新たなCVEが出た際にも、どのアプリケーションに影響するかを迅速に調べやすくなります。これは、パッチ管理の対象をOSやミドルウェアだけでなく、ソフトウェア部品レベルまで広げるための実務的な方法です。

企業の脆弱性対応の失敗例

企業の脆弱性対応が失敗する典型例は、脆弱性情報を見ているのに、自社への影響確認ができないケースです。CVEを把握しても、対象製品のバージョンや設置場所、外部公開状況が分からなければ、優先順位も対策方針も決められません。結果として、「あとで確認しよう」と先送りされ、実際に攻撃が始まった時点で慌てて対応することになります。CISAがKEVカタログを継続公開しているのは、こうした遅れが実被害につながりやすいからです。

もうひとつ多いのは、CVSSスコアだけで機械的に対応順を決める失敗です。CVSSは重要な指標ですが、NVDでは「CVSSはリスクではない」と説明しています*2https://nvd.nist.gov/vuln-metrics/cvss。にもかかわらず、スコアの高さだけで判断すると、公開サーバー上で悪用が進む脆弱性より、閉域環境の理論上危険な脆弱性を優先してしまうことがあります。脆弱性対応では、深刻度、公開状態、悪用実績、業務影響を合わせて考える必要があります。

さらに、パッチを当てて終わりにしてしまうのも典型的な失敗です。適用漏れ、再起動忘れ、周辺システムの未更新、検証不足による障害発生などは珍しくありません。NISTがパッチ管理に「検証」を含めているのは、こうした現実があるからです。脆弱性対応は、修正したことを確認し、その結果を記録し、次回に再利用できる形で残して初めて組織の知見になります。

脆弱性管理との違い

脆弱性対応と脆弱性管理は、似ているようで役割が異なります。脆弱性対応は、個別の脆弱性が見つかったときに、影響を調べ、優先順位を付け、修正する実務です。一方の脆弱性管理は、その対応を継続的に回すための全体運用を指します。CISAが脆弱性管理を「脆弱性や悪用可能な状態の発生頻度と影響を減らすための活動」として示しているように、脆弱性管理は発見、評価、是正、確認を繰り返す仕組み全体です。脆弱性対応は、その中の重要な一工程だと考えると整理しやすくなります。

つまり、脆弱性対応は個別事案へのアクションであり、脆弱性管理はそれを支える土台です。資産台帳、情報収集ルール、優先順位基準、パッチ管理フロー、検証体制、記録・改善の仕組みが整っていなければ、脆弱性対応は属人的になり、毎回判断がぶれます。逆に、脆弱性管理が機能していれば、新しいCVEが出ても落ち着いて影響確認と対応判断を進めやすくなります。

IT資産管理と脆弱性管理の関係については、以下の記事で詳しく解説しています。
「脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-」

まとめ

脆弱性対応とは、CVE情報を確認して終わることでも、パッチを当てて終わることでもありません。脆弱性情報を収集し、自社への影響を調べ、CVSSや悪用状況、業務影響を踏まえて優先順位を決め、修正し、最後に再確認するまでが一連の流れです。特に、実悪用が確認された脆弱性を優先する視点、クラウドやOSSを含めて影響を判断する視点、SBOMやSCAを活用して依存関係を見える化する視点は、今の企業実務では欠かせません。

脆弱性対応を強くするには、単発の対応力ではなく、継続的に判断と是正を回せる仕組みが必要です。CVEを読む力、CVSSを鵜呑みにしない判断力、資産を把握する力、そしてパッチ管理を確実にやりきる運用力がそろって初めて、企業の脆弱性対応は実効性を持ちます。検索流入で「脆弱性対応」「CVE対応」「パッチ管理」を調べている担当者にとって重要なのは、知識だけでなく、明日から自社でどう動くかが見えることです。本記事がその整理の起点になれば幸いです。

【参考情報】

NIST（米国立標準技術研究所）,NIST SP 800-40 Rev. 4,Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology（https://csrc.nist.gov/pubs/sp/800/40/r4/final）
Common Vulnerabilities and Exposures（CVE.org）
（https://www.cve.org/）
NIST SPECIAL PUBLICATION 1800-31,Improving Enterprise Patching for General IT Systems: Utilizing Existing Tools and Performing Processes in Better Ways（https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-31.pdf）
CISA（米サイバーセキュリティ・インフラセキュリティ庁）「Reducing the Significant Risk of Known Exploited Vulnerabilities」（https://www.cisa.gov/known-exploited-vulnerabilities）
CISA,Recommended Practice for Patch Management of Control Systems,December 2008（https://www.cisa.gov/sites/default/files/2023-01/RP_Patch_Management_S508C.pdf）

【関連ウェビナーのご案内】
本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日（水）14時からの開催のウェビナーでは、AssetViewとFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。