タグ: Webアプリケーション

投稿日:

HTTP2Shellとは ―Node.jsやPythonに広がるBrotli脆弱性の影響と対策

Share
HTTP2Shell（CVE-2026-111497）とは？影響製品と対策を解説アイキャッチ画像

WebサイトやAPIの安全性を確認する際は、外部からのリクエストだけでなく、アプリケーションが受信するレスポンスにも注意が必要です。HTTP2Shell（CVE-2026-111497）は、GoogleのBrotliデコーダーに存在する脆弱性で、細工された圧縮データの展開によって、情報漏洩や任意コード実行につながるおそれがあります。Node2Shellとも呼ばれるこの問題は、Node.jsに加え、Python関連パッケージやBun、Envoyなど幅広い製品に影響します。本記事では、主な攻撃経路、影響を受ける製品、修正版と対策を解説します。

HTTP2ShellとNode2Shellの関係

Brotliは、Webコンテンツなどのデータを小さくするために使われる圧縮方式です。HTTP通信では、本文がBrotli形式で圧縮されていることをContent-Encoding: brというヘッダーで示します。本脆弱性は、当初Node.jsへの影響が注目されたことから「Node2Shell」と呼ばれていました*1。その後、Brotliを利用する複数の製品にも影響が及ぶことが明らかになり、「HTTP2Shell」という呼称も使われるようになりました。なお、名称にHTTPが含まれていますが、HTTP/2通信に限定された脆弱性ではありません。

問題があるのは、圧縮されたデータを元に戻すデコーダーです。不正なデータの処理を打ち切るべき場面で処理が続き、内部バッファの範囲を超えて書き込むことがあります。結果として、プロセスの停止やメモリ内の情報漏洩、条件によっては遠隔からの任意コード実行（RCE）につながります。

Googleが登録したCVEレコードの評価はCVSS v4.0で9.2、深刻度はCriticalです。一方、Node.jsの公式告知ではHighに分類されています*2。確認すべきなのは、脆弱なBrotliデコーダーを使用し、攻撃者が用意したデータがそこに届くかどうかです。

HTTPリクエストとレスポンスの両方が攻撃経路になる

受信側では、WebアプリケーションがBrotli圧縮されたリクエスト本文を展開する経路が問題になります。Impervaは、Express 5やbody-parser 2系でBrotli圧縮された本文を展開する構成で、細工したデータがNode.jsに内包されるデコーダーへ渡るケースを検証しています*3。⁠

もう一つは、アプリケーションがHTTPクライアントとして通信する経路です。Node.jsの組み込みfetchがBrotli圧縮された応答を展開すると、接続先のサーバーが返したデータがデコーダーに届きます。公開APIへの入力対策とあわせて、外部サイトから情報を取得する機能にも目を向ける必要があります。

図1：HTTP2Shellで確認する二つの攻撃経路

脆弱なBrotliデコーダーに細工されたデータが届く二つの攻撃経路を示した概念図
出典：Imperva, Inc.、Bunプロジェクトの公開情報をもとに作成。
※任意コード実行の成立条件は製品や構成によって異なります。

影響を受ける製品と修正版

影響調査では、開発言語の名前だけで範囲を区切らないことが大切です。Pythonの場合は、Python本体全体の問題として扱うのではなく、Brotliやbrotlicffiといったパッケージの導入状況を調べます。urllib3やrequestsなどは、これらのパッケージが利用できる環境でBrotli応答を自動展開するため、アプリケーションのコードにBrotliの呼び出しが見当たらなくても確認が必要です。

表1：主要コンポーネントの修正版と確認する条件

コンポーネント修正版確認する条件
Google Brotli1.0.10／1.1.1／1.2.11.0.3～1.0.9、1.1.0、1.2.0
Node.js22.23.4／24.22.1／26.12.1各系列の未修正版。内包するデコーダーの利用経路を確認
Python関連パッケージBrotli 1.2.1
brotlicffi 1.2.1.0		仮想環境やコンテナーごとの導入状況を確認
Bun1.4.41.0.21以上1.4.4未満。コンパイル済み実行ファイルも確認
Envoy1.40.0／1.39.3／1.38.6／1.37.8／1.36.12Brotli展開フィルターを設定した環境
Istio1.31.2／1.30.6／1.29.9Brotli展開を有効にした環境。1.29系はサポート終了
出典：Google LLC、Node.jsプロジェクト、GitHub Advisory Database、Bunプロジェクト、Envoy Proxyプロジェクト、Istioプロジェクトをもとに作成。
※主要コンポーネントの修正版と確認条件を整理しています。バージョン番号は各開発元の公表値です。影響製品を網羅したものではなく、利用環境に応じて各製品の公式情報を確認してください。

EnvoyではBrotliの展開フィルターを設定した環境、IstioではEnvoyFilterなどを使ってBrotli展開を有効にした環境が確認対象です。製品名が一致するだけで、すべての構成が同じ攻撃経路を持つとは限りません。反対に、別製品に内包されたライブラリは、アプリケーションの依存パッケージ一覧だけでは見落とすおそれがあります。

コード実行の実証と実際の攻撃を分けて読む

Impervaは、公式のNode.js 24.22.0のLinux arm64イメージを用いた実験で、細工したBrotliデータによるコード実行を報告しています。修正版の24.22.1では同じ入力が拒否されました。ただし、実験環境では成功まで複数回の試行を要しています。この結果を、すべてのOSや構成で同じ攻撃が成立するという意味に広げることはできません。

また、研究環境での実証は、実際の組織に対する攻撃成功の報告とは別です。CVEレコードに収録されたCISAの評価では、2026年10月23日時点のExploitation（悪用状況）が「none」とされています。ただし、これは評価時点の情報であり、その後の悪用の有無を保証するものではありません。修正の優先順位は、被害報告の有無だけでなく、自社環境で攻撃者が用意したデータが脆弱な展開処理へ届くかどうかを踏まえて判断する必要があります。

Go向けBrotli実装にも関連する報告があります。Sweet Securityはv1.2.6でpanicと接続切断を再現しましたが、その実験ではアプリケーション全体は動作を続けていました。Go実装で任意コード実行やプロセス全体の停止が実証されたわけではありません*4。メンテナーは10月23日に修正コミット33c2a98による対応を報告しています*5。

更新する対象を実行環境まで追う

Node.jsを使う環境では、Brotliを内包するNode.jsランタイムそのものを更新する必要があります。Pythonでは仮想環境ごとにパッケージを確認し、コンテナーを使っている場合は、更新後の構成でイメージを再ビルドして再配置します。管理画面に表示された設定値だけでなく、稼働中のプロセスに修正が反映されていることまで確認します。

Bunでは、bun build –compileで作成した実行ファイルにランタイムが埋め込まれます。開発端末のBunを更新しても、すでに配布した実行ファイルは自動では直りません。公式告知はBun 1.4.4への更新と、該当する実行ファイルの再ビルドを求めています*6。製品に組み込まれたBrotliを修正するには、製品側の更新が必要になる点に注意してください。

図2：影響確認から修正の反映までの流れ

影響確認から修正版の適用までの対応を整理した概念図
出典：Node.jsプロジェクト、Aikido Security BV、Bunプロジェクト、Envoy Proxyプロジェクトの公開情報をもとに作成。
※暫定対策は修正版への更新を代替するものではありません。

更新までの暫定対策では展開前に止める

すぐに更新できない場合は、脆弱なデコーダーにBrotli圧縮データが渡らないようにすることが暫定対策となります。受信リクエストでは、Brotli形式の本文を展開する前に拒否する方法があります。外部サイトからのレスポンスについても、Brotli展開を無効にするか、展開前に拒否できるかを確認します。送信するAccept-Encodingからbrを削除するだけでは、接続先がBrotli圧縮されたレスポンスを返す可能性を排除できません。

回避策の設定方法は製品によって異なります。Bunの公式告知では、fetchの呼び出しにdecompress: falseを指定する方法が示されていますが、その呼び出しだけに適用される設定です。ほかのBrotli展開処理まで一括して無効になるわけではありません。回避策の対象範囲を確認したうえで修正版へ更新してください。

HTTP2Shellへの対応では、公開Webサーバーの点検に加え、外部と通信するアプリケーションや製品内の依存ライブラリまで確認を進めます。Brotliを含む実行環境を洗い出し、攻撃者のデータが届く経路を確認したうえで、稼働中のプロセスに修正が反映されたことまで確かめてください。外部から細工されたBrotliデータを受信・展開する可能性があった環境では、修正版の適用に加え、不審なプロセスの異常終了や関連ログなどを確認し、侵害の兆候がないか調査することも重要です。

Webアプリケーションのセキュリティ対策を見直しませんか？

公開WebサイトやAPIの安全性を維持するには、利用するソフトウェアの更新に加え、アプリケーション全体の脆弱性を継続的に確認することが重要です。ブロードバンドセキュリティ（BBSec）では、Webアプリケーションの脆弱性診断を通じて、企業のセキュリティ対策を支援しています。

SQATWebアプリケーション脆弱性診断サービスページバナーリンク

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

PHPの重大な脆弱性「PHP2shell」の修正版公開 ―影響範囲とAIによる発見の経緯

Share
PHPの重大な脆弱性「php2shell」の修正版公開アイキャッチ画像

PHPの重大な脆弱性「PHP2shell」への対応は、更新の準備から修正版を適用する段階に移りました。PHPプロジェクトは2026年10月21日、認証なしでサーバー上のコードを実行されるおそれがある2件の脆弱性を修正し、利用者に速やかな更新を求めています。またOpenAIも同日、AIを活用した発見と、PHPの開発者やセキュリティ事業者による対応の経緯を公表しました。本記事では、修正バージョン、影響範囲、暫定策の限界を整理し、AI時代の脆弱性管理で企業が見直したい運用を解説します。

※本記事は2026年10月22日12時時点で公表されている情報を基に作成しています。脆弱性の影響範囲や対策については、PHP公式および利用製品の提供元が公表する最新情報をご確認ください。

PHP本体に存在する2件の重大な脆弱性「PHP2shell」

対象はCVE-2026-109618とCVE-2026-109619です。いずれも深刻度はCVSS v4.0で9.2のCriticalとされています。前者はメモリ不足が起きた際、不完全な内部データを後の終了処理で使ってしまう問題です。後者は、リクエストの処理後に解放されたメモリへの参照が残り、同じワーカーが後続のリクエストを処理するときに使ってしまう問題です。

PHP公式は、PHP-FPM、Apacheのmod_php、php-cgi、FrankenPHP、LiteSpeedなど、Webリクエストを処理するPHP環境をリスクのある対象として挙げています*7。特にmod_phpでは、アプリケーションのコードが動く前に認証不要の攻撃が成立する実証があり、最もリスクが高いと評価しています。

ただし、攻撃が成立する条件や実証の範囲は、実行方式、設定、アプリケーションなどによって異なります。すべての構成で同じ攻撃が同じように成立するわけではありません。構成による違いを理由に更新を見送らず、公式のアドバイザリと利用環境を照合することが必要です。

PHPの修正バージョンと旧バージョンの対応

10月21日に公開された修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。各系列でこれらより前のバージョンを使っている場合は、修正版への更新を進めます。Linuxディストリビューションや長期サポート事業者のパッケージでは、提供元のセキュリティ情報と修正済みパッケージを確認してください。旧版を維持したまま修正を取り込むバックポートでは、上流のPHPとバージョン表記が一致しない場合があります。表示番号だけで結論を出さず、提供元が今回の2件のCVEに対応しているかを確認することが大切です。

PHP 8.1以前は、PHPプロジェクトの通常の更新対象から外れています。ただし、今回は問題の重大さから、PHP 7.4、8.0、8.1向けに最小限のソースバックポートも提供されました。これを通常サポートの再開と捉えず、保守事業者の対応を確認しながら、サポート対象への移行を進めてください。

図1：PHP2shellに対応したPHPの修正バージョン

PHP2shellに対応したPHPの修正バージョンの表
出典：The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」「RCE via OOM corruption」「RCE via stale global state」を基に弊社作成。
※2026年10月21日公開の修正バージョンを系列ごとに示しています。修正版より前のバージョンは更新確認の対象です。ただし、旧系列やLinuxディストリビューション等によるバックポートは表に含めていません。提供元のCVE対応情報も確認してください。

OpenAIが公表したAIによる発見と協調開示

OpenAIによると、セキュリティ企業Califは「Patch the Planet」の取り組みでGPT-5.6 Solを使い、重大な欠陥を特定しました*2。また、Wizも独立して両方の脆弱性を発見・報告しています。修正とリリースを主導したのはPHPのメンテナーで、OpenAIなどが調査・テスト・調整を支援しました。

発見の経緯には、以前から把握されていた問題も含まれます。The PHP Foundationは、CVE-2026-109618の原因となったメモリ不足処理の問題について、2024年に兆候を認識していたと説明しています*3。その後の研究報告によって深刻な影響が明確になりました。AIによる研究が進む一方で、報告の判断やパッチの作業には人が関与しているとも説明しています。

協調開示では、問題の公表に向けて開発者が修正を検証し、配布元やサービス事業者が更新や防御策を準備します。今回も、PHPの修正を利用者に届けるまでに複数の組織が関わりました。企業の運用でも、情報を受け取る担当、対象システムを把握する担当、更新を実施する担当の間で作業が止まらない体制が欠かせません。

図2：脆弱性の発見から企業の更新までをつなぐ役割

PHP脆弱性対応フロー図
出典：OpenAI「Patch the Planet：エージェントによる重大な脆弱性の発見と世界規模の対応連携」、The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」を基に弊社作成。
※今回の主な役割を簡略化した概念図です。矢印は連携を示し、厳密な時系列や組織間の指揮命令関係を示すものではありません。企業による適用・確認は運用上の対応を示しています。

設定変更やWAFだけで対策を終えない

PHP公式は、更新が唯一の完全な対策であり、暫定策は特定の攻撃経路への露出を減らすものとしています。例えば、session.upload_progress.enabled=0は、確認済みのセッション関連経路を抑える設定です。CVE-2026-109619のすべての経路を防ぐものではなく、反映には全ワーカーの再起動も必要です。エラー表示を消すだけでも対策にはなりません。

Cloudflareは10月21日の公表で、顧客を狙う攻撃トラフィックを観測し、WAFの防御を回避しようとする変化も確認したと報告しています*4。これは同社の観測であり、すべての環境で侵害が成功したことを示す情報ではありません。同社はWAFによる防御を提供しつつ、PHP自体の更新も求めています。

更新までの時間が必要な場合は、運用担当者と事業者が公式の緩和策を確認し、利用機能や可用性への影響を検討します。設定を変更した記録と、修正版を適用した記録は分けて管理してください。暫定策を講じたことで更新作業が止まらないよう、未更新の環境には担当者と対応期限を設定します。

CMSの更新状況に加えてPHPの稼働環境を確認する

今回の修正対象は、CMSやプラグインの下で動くPHP本体です。CMSの管理画面で更新済みと表示されていても、それだけではPHPの修正が適用されたことを確認できません。ホスティング事業者がPHPを管理している場合は、事業者に更新状況と利用者側で必要な操作を確認します。

企業側では、コーポレートサイトやECサイト、問い合わせフォーム、部門や委託先が管理するWebシステムについて、PHPの利用有無、実行方式、バージョン、更新元、管理者をそろえます。複数のサーバーやコンテナで動かしている場合は、一部の更新だけで完了としないよう、環境ごとに対応状況を残してください。適用後は、提供元の手順に従って再起動などの必要な処理を行い、実際にWebリクエストを処理している環境に修正が反映されたことを確認します。ログイン、フォーム送信、購入手続きなど、業務上重要な操作の動作確認も行います。米国国立標準技術研究所（NIST）も、パッチ管理には更新の識別、優先順位付け、取得、適用だけでなく、適用確認までを含めています。

並行して、アクセスログやエラーログの記録・保全状況を確認します。更新の完了は、過去に侵害されていないことの証明にはなりません。不審な通信やファイル、予期しないプロセスなどが見つかった場合は、記録を保全し、組織のインシデント対応手順に沿って調査につなげてください。

BBSecが支援する脆弱性情報の収集と公開資産の把握

緊急更新を進めるうえでは、自社に関係する情報を見つけ、未対応のシステムを追える状態が必要です。ブロードバンドセキュリティ（BBSec）の「脆弱性情報提供　SAS（Secure Net Alert Mail Service）」は、登録されたシステム情報に基づき、関連する脆弱性情報を絞り込んで提供するサービスです。対応ステータスの管理機能も備え、日々の脆弱性管理を支援します。SASの配信情報は、プランに応じてJVNやNVDの公開情報を利用します。PHP公式や利用中の事業者が出す案内も直接確認し、情報提供サービスと組み合わせて対応を進めることが大切です。

公開資産の把握に課題がある場合は、「アタックサーフェス調査（SQAT® ASM）」も活用できます。インターネット上の公開情報から、攻撃者に見える資産や脅威となり得る情報を調査するサービスです。調査結果を社内の資産台帳と照合し、管理担当や更新状況を確かめる手掛かりにできます。

まずは今回のPHP更新を着実に進め、その過程で情報の見落としや担当の不明確さが見つかったら、日々の管理方法も見直してください。脆弱性情報の選別や公開資産の把握にお困りの場合は、BBSecへご相談ください。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

skyticketで約1,464万件の情報流出 ―3つの不正アクセス経路から考えるWebサービスのセキュリティ対策

Share
skyticketで約1,464万件の情報流出アイキャッチ画像

旅行比較予約サイト「skyticket」を運営するアドベンチャーは2026年10月9日、顧客情報の流出に関する3件の不正アクセスを公表しました。さらに10月16日には、第2報として一部利用者のクレジットカード情報等の流出を発表しています。 発生した場所も、対象情報も一様ではありません。企業の対策に生かすには、個々の事案を分けて理解し、管理機能と利用者向け機能の双方で、アクセス制御が適切かを確認する必要があります。

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

約1,464万件の情報流出と3つの不正アクセス事案

10月16日の第2報では、サーバーへの不正アクセスにより、最大6,140名分のクレジットカード情報等が流出したことも判明しました。公式発表が整理した3つの経路と対象件数は下図の通りです。

図：skyticketの3つの不正アクセス経路と情報流出の概要

skyticketの3つの不正アクセス経路と情報流出の概要
出典：株式会社アドベンチャーの2026年10月9日および10月16日公表資料をもとに弊社作成
※約413万件は約1,464万件の内数です。第2報で判明したクレジットカード情報（最大6,140名分）はサーバー事案に関する追加情報です。3事案では件数の単位や調査状況が異なるため、合計を被害人数として扱うことはできません。

自社への教訓を考える際も、これらを一つの原因で説明しないことが重要です。管理機能からアクセスできる範囲と、利用者へ個人情報を返す機能のアクセス制御は、それぞれの担当者と仕様を確認する必要があります。

利用者が確認したい流出情報と注意点

同社は10月9日の発表でクレジットカード番号の流出を否定していましたが、10月16日の第2報で内容を訂正しました。2017年2月から2018年6月までに「skyticketプレミアム」の会費支払いに利用されたクレジットカード情報が、最大6,140名分流出したことが判明しています。対象にはカード番号、名義人名、有効期限が含まれますが、セキュリティコードは含まれていません。また、会員特典である「ベネフィット・ステーション」の会員ID、氏名、パスワードの流出も確認されています。同社は対象者にクレジットカードの利用明細の確認を求めるとともに、会員には公式サイト・アプリでのパスワード変更と、同じパスワードを使う他サービスでの変更を呼びかけています。

企業側の通知でも、どの情報が対象で、利用者に何をしてほしいのかを結び付けて伝える必要があります。氏名や連絡先、予約内容が対象であれば、単に「不審なメールに注意」とするだけでなく、問い合わせ先と確認方法を案内する方が、利用者は行動に移しやすくなります。

ハッシュ化されたパスワードも 流出後の対応が必要

パスワードのハッシュ化は、入力された文字列を一定の処理でハッシュ値に変換して保存し、元のパスワードをそのまま持たないための仕組みです。ただし、ハッシュ値が外部へ出た場合に、パスワードが絶対に判明しないことを意味するわけではありません。攻撃者がパスワードの候補からハッシュ値を計算して照合する攻撃に対し、解析を困難にする仕組みが重要です。

OWASPは、パスワード保存に適した方式や処理コストの設定、利用者ごとに異なるソルトの使用などを説明しています。ソルトとは、同じパスワードでも同じハッシュ値になりにくくするために加える値です。本件の発表では方式や具体的な設定までは示されていないため、解析の容易さを断定することはできません。企業が保管方法を点検する際は、「ハッシュ化しているか」という確認だけで終えないことが大切です。方式、設定値、ソルトの扱いを確認し、漏えい時に利用者へ変更を求める手順まで整えておきます。パスワードの安全な保存方法と、流出時の対応手順を併せて整備することが重要です。

認証と認可を分けて 予約情報へのアクセスを確認する

今回のバス予約ページの問題から、Webサービスの担当者が再確認したいのが認証と認可の違いです。認証は「誰であるか」を確認する処理、認可は「その情報や操作を許可してよいか」を判断する処理です。ログインできた利用者であっても、他人の予約情報を閲覧できていいわけではありません。

OWASPは、必要最小限の権限、原則としてアクセスを拒否する設計、リクエストごとの権限確認を推奨しています。URLが推測しにくいことや、画面にリンクが表示されないことだけを、アクセス制御の代わりにはできません。利用者と対象データの関係を、サーバー側で判断する設計が必要です。自社サービスの点検では、予約完了画面、マイページ、明細のダウンロード、APIなど、個人情報を返す機能を対象にします。未ログインの状態だけでなく、別の利用者として操作した場合や、権限を変更した後の状態も確認します。これは本件でAPIや別利用者の権限に問題があったと断定するものではなく、認可の確認を自社へ広げるための観点です。

管理機能の先にあるデータも 守る範囲に含める

今回の発表は、管理機能に使われた製品や具体的な操作方法を明らかにしていません。公表されていない製品や攻撃手法を、原因として推測することは適切ではありません。[1]企業側は、自社の管理機能からアクセスできるデータを確認するとよいでしょう。業務担当者に必要な操作、アプリケーションが必要とする接続権限、運用保守のための権限を区別し、それぞれが目的を超えて広がっていないかを点検します。必要最小限の権限は、画面の利用者にも、バックエンドの接続にも適用すべき考え方です。

第2報では、2018年7月にクレジットカード情報を自社サーバーで保管しない方式へ移行した際、会費支払いに関する記録（ログ）が削除されずに残っていたことが明らかになりました。このログは今回の不正アクセスで取得され、暗号化されたカード情報とともに、暗号化に用いる情報も不正に取得されていたため、情報が読み取られるおそれがあるとされています。この事案は、システム変更時に不要となったデータの削除状況や、ログに含まれる機密情報の管理を確認する重要性も示しています。

弊社が2026年10月8日に公表した提言でも、公開Webサービスの脆弱性修正、設定の適正化、認証・権限管理の徹底に加え、対策の実効性を継続的に確認することの重要性を指摘しています。新機能のリリース前だけでなく、運用中の変更がアクセス範囲を広げていないかを確かめることが重要です。

ブロードバンドセキュリティ（BBSec）「国内で相次ぐ不正アクセスを受け、
BBSecが公開Webサービスの基本対策の再点検を提言」（2026年10月8日）（https://www.bbsec.co.jp/news/20261008.html）

Webアプリケーション・APIの脆弱性を診断で確認

自社でログインできることは確認していても、許可されない操作が拒否されることまで十分に検証できているでしょうか。BBSecの「Webアプリケーション脆弱性診断」は、外部から動的に検証し、攻撃の入口になり得る問題の検出を支援します。開発時の確認に加えて、運用中のシステムにも定期的に活用できます。診断を検討する際は、顧客向けの画面だけでなく、業務管理機能、個人情報を返すAPI、利用者の役割ごとのアクセス範囲を伝えることが大切です。どの機能と権限の組み合わせを検証するかは、個別の対象や業務要件に合わせて調整します。さらに設計段階から見直したい場合には、要件定義・設計のレビューや開発標準の整備を支援する「Shift Leftコンサルティング」もご活用いただけます。

個人情報の収集・管理・提供に関わる各機能を横断的に確認することが、セキュリティ対策の抜け漏れを防ぐ第一歩です。自社のWebサービスでどこまで点検できているかを整理し、重要な情報を扱う範囲から具体的な検証につなげていきましょう。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

国内で相次ぐ不正アクセス、企業が点検すべきAPIと業務システム

Share
国内で相次ぐ不正アクセス、企業が点検すべきAPIと業務システムアイキャッチ画像

不正アクセスに関する注意喚起を受け、自社で利用している製品を確認するだけでは、点検すべき範囲を見落とす可能性があります。Webサービスの裏側で動くAPIや、限られた従業員だけが使う業務システムまで含め、公開範囲と操作権限を確認することが重要です。

JPCERT/CCは2026年10月8日、国内組織で相次ぐ不正アクセスについて注意喚起を公表し、翌9日に情報を追加しました*5。本記事では、注意喚起のうちAPIや業務システムに関する内容を中心に、OWASPの技術資料も踏まえながら、企業が実施すべき点検方法を解説します。

今回の注意喚起で確認されていること

JPCERT/CCが取り上げているのは、2026年9月前後に国内組織で相次いだ、個人情報等の漏えいにつながる不正アクセスです。既知の脆弱性の探索・悪用やAPI経由の不正操作、BIツール「Metabase」の脆弱性を悪用した攻撃などが報告されています。また、一般利用者向けのサービスだけでなく、BIツールや従業員向け管理システムも被害対象となっています。10月9日の更新では、公開Webサーバーからアクセス可能なアプリケーションサーバーにWebシェルが設置された事案が追加されました。

ただし、公表された事案を一つの原因で説明することはできませんJPCERT/CCは、攻撃に関する技術的な情報の共有が十分でない状況を説明し、把握している情報について「限定的かつ断片的」としています※。

出典：JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月9日更新）（https://www.jpcert.or.jp/at/2026/at260030.html）I. 概要より一部引用。

こうした状況を踏まえ、以降はAPIや業務システムのセキュリティ対策について、企業が確認すべきポイントを解説します。

画面に表示されないAPIも点検が必要

APIは、アプリケーション同士がデータや機能をやり取りするための仕組みです。スマートフォンアプリやWeb画面でボタンを押すと、その裏側でAPIに要求が送られ、サーバーが処理する構成があります。画面の表示と、サーバーが要求を受け付ける条件は、それぞれ確認する必要があります。例えば、一般利用者には管理ボタンを表示しない設計でも、それだけで管理用APIへの要求を防げるわけではありません。要求を受けたサーバーが利用者の権限を確認しなければ、本来許可されていない機能を実行されるおそれがあります。OWASPは、こうした問題を機能レベルの認可の不備として整理しています*2。

認証は利用者が誰かを確認すること、認可はその利用者が何をしてよいかを判断することです。ログイン済みであっても、すべての顧客情報を閲覧してよいとは限りません。同じ閲覧機能でも、自分の契約に属するデータだけを扱えるよう、対象データごとに権限を確認する必要があります。

図：画面の表示制御とAPIの権限確認

画面の表示制御とAPIの権限確認
出典： OWASP「API Security Top 10 2023」（API1:2023、API5:2023）および「REST Security Cheat Sheet」を参考に弊社作成。
注記： 一般的なAPIの認証・認可の仕組みを示した模式図であり、今回の不正アクセス事案を再現したものではありません。

管理用や内部利用を想定したAPIであっても、適切なアクセス制御は欠かせません。OWASPの「REST Security Cheat Sheet」では、非公開のRESTサービスについても、各APIエンドポイントでアクセス制御を実施することを求めています。APIのURLが一般に知られていないことだけを安全性の根拠とせず、アクセス元の制限や利用者の認証・認可を適切に設定する必要があります。

自社で確認すべき6つの点検項目

公開中のシステムとAPIを把握しているか

まず、運用担当者や開発委託先に、現在動いているシステムとAPIの一覧を確認します。サービス名だけでなく、利用目的、管理担当者、接続先、扱うデータ、利用を許可する相手まで整理すると、見直すべき範囲がはっきりします。仕様書と実際の稼働環境に差がないかも確認したいところです。特に確認したいのは、更新前のAPI、試験用の環境、保守用の機能です。OWASPは、管理から漏れた古いAPIや不要な公開環境をリスクとして挙げています*3。本番のAPIを修正しても、同じデータに接続する旧版が動き続けていれば、点検は完了していません。廃止の判断には利用状況を確認し、停止する担当者と日程まで決めておきます。

また、公開Webサーバーから内部のアプリケーションサーバーや管理システムへ、どのような通信が許可されているかも確認します。外部公開していないシステムであっても、公開サーバーを経由して到達できる場合があります。業務上必要な通信に限定されているか、不要な接続経路が残っていないかを点検することが重要です。

利用者ごとの操作権限は適切か

権限の確認では、誰に、どの機能を、どのデータに対して許可するのかを明文化します。例えば「担当者は自分の担当顧客を閲覧できるが、他部署の顧客情報の出力はできない」といった業務上の条件です。一般利用者と管理者の区別に加えて、所属部署や契約先などの境界も整理します。そのうえで、許可された操作が成功することと、許可されていない操作が拒否されることの両方を確認します。機能単位の権限と、データ単位の権限は別々の観点です。実機での確認は、システム所有者と対象範囲を合意し、検証用アカウントやテストデータを用意して進めます。

APIキーやトークンを失効できるか

APIキーやアクセストークンの管理では、発行済みのものを把握できるかに加え、漏えいが疑われた際に失効させられるかを確認します。どのシステムが使い、どこまでの操作を許可し、誰が更新するのかが分からなければ、緊急時の判断が遅れます。OWASPも、秘密情報への最小限の権限付与と、更新・失効・有効期限を含む管理を示しています*4。実務では、鍵の値そのものを点検表に転記せず、識別子と用途、管理先を記録すると扱いやすくなります。更新後に古い認証情報が使えなくなるか、連携先の設定変更が必要かも確かめます。APIキーの所持だけを機密性の高い処理の許可条件とせず、システムの用途や扱う情報に応じて、適切な認証・認可の仕組みを組み合わせることが重要です。

APIの大量実行を制限できるか

操作権限の確認とあわせて、短時間に繰り返される要求への制限も確認します。検索やパスワード再設定など、機能ごとに通常の利用量を把握し、実行回数や一度に返すデータ件数に適切な上限を設けます。OWASPも、業務に応じたレート制限や応答件数の制限を推奨しています*5。ただし、回数を制限しても、権限のない操作が一度でも通る問題は解消しません。認可の点検と並行して進めます。

脆弱性の修正と暫定措置を管理できるか

既知の脆弱性への対応は、利用製品や部品のバージョンを把握することから始まります。開発委託先に確認する場合も、「対応済み」という回答だけで終えず、修正した対象と反映日、残っている課題を共有してもらいます。更新による業務影響が心配な場合は、検証環境で機能を確認したうえで反映します。すぐに更新できなければ、提供元の回避策や機能制限などの適用可否を検討します。OWASPも、修正版の検証と、修正できない場合の暫定的な緩和策を分けて扱っています*6。暫定措置には担当者と見直し期限を設定し、恒久対応まで追跡することを勧めます。

不審な操作をログで追跡できるか

ログの点検では、記録の有無に加えて、利用者と操作内容を結び付けて調べられるかを確認します。認証や権限確認の失敗、権限変更、アカウント作成、データ出力といった操作は、調査に役立つ手掛かりになります。OWASPのログ管理資料でも、これらの記録が取り上げられています*7。例えば、通常と異なる時間帯に大量の出力が行われた場合、操作した主体、対象データ、実行結果を追えるでしょうか。担当者が一件の操作を実際にたどってみると、記録項目や保存先の不足を見つけやすくなります。一方、パスワードやアクセストークンをそのままログに残すと、記録自体が漏えいの原因になり得ます。必要な情報を選び、秘密情報は記録から除外・マスキングする設計が必要です。

点検結果を改善と初動対応につなげる

点検で見つかった問題は、対応する人と完了を確かめる方法まで決めて初めて管理できます。本記事では、点検結果に「対象」「確認できた事実」「業務への影響」「対応担当者」「期限」「再確認の方法」を残す運用を勧めます。判断材料が不足する項目は、問題なしとして閉じず、未確認の内容を明らかにして担当者へ引き継ぎます。例えば、使われていない公開APIが見つかったなら、利用状況を確認して公開を止め、実際に外部から利用できなくなったかを確認します。権限の不備を修正したなら、許可されない操作が拒否されることと、正規の業務が継続できることを再度確かめます。修正作業の完了と、安全性の確認を対応記録の中で結び付けることが大切です。

不正アクセスが疑われる場合の対応

すでに不審な操作が確認されている場合は、予防目的の点検だけでなく、インシデント対応の担当者へ速やかに連絡します。原因調査に必要なログや設定情報などを保全し、証拠を失わないよう注意しながら、被害の拡大を抑える措置を検討します。平時から、夜間や休日の連絡先と、システムの利用停止を判断する責任者を決めておくことも重要です。

脆弱性診断を相談する前に整理しておきたい情報

専門家に相談する際には、対象URLの一覧に加え、API仕様書、利用者の権限区分、重要な業務機能、扱う情報を整理しておくと、確認したい範囲が伝わりやすくなります。顧客向けの画面だけを対象にするのか、管理機能やAPIも含めるのかを、依頼段階で明確にしておきましょう。自社のAPIや管理機能について、どこまでを診断対象に含めるべきか判断が難しい場合は、システムの構成や業務上の権限を共有したうえでご相談ください。運用中のシステムを定期的に点検する機会としては、脆弱性診断を活用できます。

Webアプリケーションの脆弱性を把握し、適切な対策につなげる

ブロードバンドセキュリティ（BBSec）の「Webアプリケーション脆弱性診断」では、Webアプリケーションの脆弱性を診断し、リスクの深刻度と推奨対策をご報告します。管理機能やAPIを含む診断範囲についても、お気軽にご相談ください。

【関連記事】

APIの脅威と対策について知りたい方は、「OWASP API Security Top 10とは？APIの脅威と対策を知ろう」もあわせてご覧ください。

公開範囲と権限を確かめることから始める

今回の注意喚起を自社の対策につなげるには、現在公開しているシステムを把握し、誰がどの情報を扱えるのかを確かめることが出発点になります。まずは主要な業務システムを一つ選び、APIの一覧、権限の設計、操作ログを担当者と確認してみてください。確認できない部分が見つかれば、そこから次の調査や改善につなげられます。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

投稿日:

2026年2Q KEVカタログ掲載CVEの統計と分析

Share
2026年2Q KEVカタログ掲載CVEの統計と分析アイキャッチ画像

前回記事では、米CISAから公開された「KEVカタログ（Known Exploited Vulnerabilities）」へ2026年第1四半期（1Q）に追加された脆弱性を統計的に分析し、実際に悪用された脆弱性から見える攻撃傾向について解説しました。本記事では、2026年4月1日から6月30日までにKEVカタログへ追加された脆弱性を対象に、前回四半期との比較を交えながら、2026年第2四半期（2Q）に見られた特徴を整理します。

2026年2四半期（2Q）の統計データ概要

2026年2QにKEVカタログへ追加された脆弱性は75件でした。2026年第1四半期（1Q）と比較すると4件増加しており、件数だけを見ると大きな変化ではありません。しかし、KEVは「実際に悪用されたことが確認された脆弱性」を掲載するカタログであるため、追加件数の増減以上に「どのような脆弱性が追加されたのか」を見ることが重要です。

月別では追加件数にばらつきが見られ、一時的な集中というよりは、四半期を通じて継続的に新たな悪用事例が確認されたことが分かります。

月別のKEV追加件数

月追加件数構成比
4月3141.3%
5月2128.0%
6月2330.7%

このことは、攻撃者が特定の大型脆弱性だけを狙うのではなく、新たに公開された脆弱性や過去の脆弱性を継続的に攻撃対象へ組み込んでいることを示唆しています。

主要ベンダー別の内訳

KEVへ追加された脆弱性をベンダー別に見ると、複数の脆弱性が同一ベンダーへ集中しているケースが確認されました。一方で、2026年2Qの特徴は、特定ベンダーへの極端な集中というよりも、ネットワーク機器、リモート管理ツール、業務システム、Webアプリケーションなど、幅広い製品群に悪用対象が広がっていることです。

企業が保有するIT資産は多様化しており、攻撃者もそれに合わせて侵入口を分散させています。そのため、「Microsoft製品だけを優先する」「VPN製品だけを重点管理する」といった限定的な運用では十分とは言えません。

ベンダー別KEV追加件数（上位10社）

順位ベンダーQ2件数Q1件数増減
1Microsoft1512+3
2Cisco74+3
3SimpleHelp30新規
3Ubiquiti30新規
3Ivanti32+1
3Adobe30新規
7LiteSpeed20新規
7Oracle20新規
7Google23-1
7BerriAI20新規

特に管理用途で利用される製品やインターネットへ公開される機器は、侵害された場合の影響が大きく、継続して攻撃対象となっています。

脆弱性タイプ（CWE）の分布

CWE件数
CWE-22（パストラバーサル）6
CWE-20（不適切な入力検証）5
CWE-94（コードインジェクション）5
CWE-287（不適切な認証）5
CWE-306（重要な機能の使用に対する認証の欠如）4
CWE-502（不適切なデータ逆シリアル化）3
CWE-78（OSコマンドインジェクション）3
CWE-284（不適切なアクセス制御）3
CWE-89（SQLインジェクション）3

KEVに追加された脆弱性をCWE別に分類すると、依然として攻撃者が初期侵入に利用しやすい脆弱性が多く確認されました。代表的な脆弱性として以下が上位を占めています。

  • OSコマンドインジェクション
  • 認証回避
  • 不適切な認可
  • パストラバーサル
  • リモートコード実行（RCE）

これらはいずれも、攻撃者が認証前または低権限の状態からシステムへ侵入し、その後の権限昇格や横展開につなげやすい脆弱性です。特に認証回避や認可不備は、CVSSスコア以上に実運用への影響が大きく、VPN機器や管理画面、リモート保守製品などで繰り返し悪用されています。

脆弱性の種類を見ると、「攻撃者が最初にシステムへ入り込むための入り口」が依然として重点的に狙われていることが分かります。

攻撃の自動化容易性（Automatable）

2026年第2Qも、自動化が容易である「Yes」と評価された脆弱性が一定数確認されました。攻撃者は現在、脆弱性を発見すると短期間でスキャンツールへ組み込み、インターネット上の対象を広範囲に探索するケースが一般的です。認証回避やリモートコード実行（RCE）の脆弱性は、PoC（概念実証コード）が公開されると、数日から数週間で大規模なスキャンの対象になることも珍しくありません。

企業側としては、「実際に狙われてから対応する」のではなく、自動化攻撃の対象になり得る脆弱性については、公開直後から迅速なパッチ適用や緩和策の実施を検討する必要があります。

CVSSスコア分布‐CVSSだけでは優先順位は決められない‐

重大度Q2件数Q2構成比Q1件数
Critical（9.0～10.0）2736.0%30
High（7.0～8.9）3850.7%34
Medium（4.0～6.9）1013.3%7
Low／None00%0

KEVへ登録された脆弱性のCVSSを集計すると、CriticalとHighを合わせて全体の約87％を占めました。これは高リスク脆弱性が多いことを示していますが、一方でMedium評価の脆弱性もKEVへ登録されています。つまり、CVSSがそれほど高くなくても、実際に悪用されれば優先的な対応対象になるという点が、KEVの大きな特徴です。

CVSSは技術的な深刻度を示す指標ですが、攻撃者が利用するかどうかまでは評価していません。そのため、脆弱性管理ではCVSSとKEVを組み合わせて優先順位を判断することが重要になります。また、現在はCVSS v3.xとCVSS v4.0が混在しており、単純なスコア比較には注意が必要です。評価体系が異なるため、スコアだけで危険性の増減を判断すべきではありません。

実際にランサムウェア攻撃に悪用された脆弱性

2026年第2Qでは、12件（全体の16.0%）の脆弱性でランサムウェアとの関連が確認されました。件数だけを見ると全体の一部に見えますが、ランサムウェア攻撃で利用される脆弱性は、侵入後に高い権限を取得できるものや、企業ネットワーク全体へ影響を及ぼしやすいものが多い点に注意が必要です。

一方で、「Unknown」と分類された脆弱性は、「ランサムウェアでは利用されていない」という意味ではありません。現時点で公開情報から確認できていないことを示しており、今後の調査やインシデント分析によって状況が変わる可能性があります。

第1四半期（1Q）との比較

追加件数だけを見ると、2Qは1Qから大きく増加したわけではありません。しかし、登録された脆弱性の内容を見ると、いくつかの特徴が見えてきます。

まず、攻撃対象が特定のベンダーに集中するのではなく、ネットワーク機器やリモート管理ツール、業務システム、Webアプリケーション、開発環境など、多様な製品へ広がっている点が挙げられます。また、認証回避や認可不備といった初期侵入につながる脆弱性が引き続き多く確認されました。こうした傾向からは、攻撃者が新たな攻撃手法を次々と生み出すというよりも、既知の脆弱性を効率的に悪用し、侵入の足掛かりとして利用している状況がうかがえます。

さらに、KEVには公開から時間が経過した脆弱性も継続して追加されています。これは、攻撃者が古い脆弱性を積極的に狙っているというよりも、パッチ未適用のシステムやサポート終了製品が依然として運用されている実態を反映している可能性があります。脆弱性が公表されてから時間が経過していても、適切な更新が行われていなければ、引き続き攻撃対象となることを示していると言えるでしょう。

統計から見える3つのポイント

2026年2QのKEVを俯瞰すると、特に注目すべき点は次の3つです。

攻撃対象の分散

従来は特定ベンダーのゼロデイ脆弱性が大きく注目されることがありましたが、第2四半期は幅広い製品が攻撃対象となりました。企業は個別製品への対応だけでなく、自社が保有する資産全体を把握した上で、継続的に脆弱性を管理する必要があります。

自動化攻撃への対応

Automatableと評価された脆弱性は、公開後短期間で大規模なスキャンの対象になる可能性があります。攻撃が始まってから対応するのではなく、KEVへの追加を一つの判断材料として優先的に対処することが重要です。

CVSSだけでは優先順位を決められない

高いCVSSスコアを持つ脆弱性への対応はもちろん重要ですが、実際に攻撃で悪用されているという事実は、運用上さらに重要な意味を持ちます。KEVは、その「実際の悪用」という観点を補完する情報源として活用できます。

まとめ

2026年2Qは、件数そのものよりも、攻撃対象の多様化や、自動化しやすい脆弱性、認証回避など初期侵入を容易にする脆弱性が継続して悪用されている点が特徴的でした。これらは特定の業種や製品に限った問題ではなく、多くの組織が共通して直面するリスクと言えるでしょう。定期的にKEVの追加状況を確認し、自社資産との照合やパッチ適用の優先順位付けへ活用することは、限られたリソースで効果的な脆弱性管理を実施するための重要な取り組みとなります。

件数や分類だけでは、実際の攻撃者がどのような製品を標的とし、どのような脆弱性を悪用しているのかまでは見えてきません。実際に攻撃で悪用された事例の分析については以下の記事をご覧ください。
「2026年2Q KEVカタログに見る攻撃トレンド ― 実際に悪用された脆弱性から読み解く攻撃者の狙い」

【参考情報】

編集責任：木下

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

    投稿日:

    DoS攻撃とDDoS攻撃の違いとは？仕組み・被害・対策を比較解説

    Share
    DoS攻撃とDDoS攻撃の違いとは？アイキャッチ画像

    DoS攻撃とDDoS攻撃は、Webサイトやサーバーに大量の通信を送り付け、サービスを利用しにくくしたり、停止させたりするサイバー攻撃です。

    どちらもサービス妨害を目的とする攻撃ですが、攻撃元の数や規模、検知・防御の難しさには大きな違いがあります。特にDDoS攻撃は、多数の端末から同時に通信が送られるため、正規のアクセスとの見分けが難しく、企業のWebサービスや業務システムに大きな影響を及ぼすおそれがあります。

    本記事では、DoS攻撃とDDoS攻撃の仕組みや違い、企業に及ぼす被害、対策のポイントについて比較しながら解説します。

    DDoS攻撃の基本的な仕組みや種類について知りたい方は、こちらの記事をご覧ください。「DDoS攻撃とは？仕組み・種類・被害・対策を企業向けに解説」

    DoS攻撃とは

    DoS攻撃とは、「Denial of Service attack」の略称で、サーバーやネットワーク機器に過剰な負荷をかけ、サービスを利用できない状態にするサイバー攻撃です。

    攻撃者は、特定のWebサイトやサーバに対して大量のリクエストやデータを送り付けます。処理能力や通信容量を超える負荷が発生すると、システムの応答が遅くなったり、サービスが停止したりする可能性があります。

    一方で、単純に大量の通信を送るだけでなく、Webアプリケーションやネットワーク機器の脆弱性、設定不備を悪用して、少ない通信でシステムを停止させる攻撃もあります。

    例えば、次のような問題がDoS攻撃に悪用される可能性があります。

    • 極端に長い文字列を処理してしまう
    • アップロードできるファイル容量に上限がない
    • 短時間に送信されるリクエスト数を制限していない
    • ネットワーク機器やソフトウェアに脆弱性が残っている
    • 不要なサービスやポートが外部に公開されている

    このような脆弱性や設定不備に起因するDoS攻撃については、システムの修正や設定の見直しによって、発生リスクを抑えることが可能です。

    DDoS攻撃とは

    DDoS攻撃とは、「Distributed Denial of Service attack」の略称で、複数の端末から一斉にDoS攻撃を行う手法です。

    Distributedは”分散された”という意味であり、攻撃者は多数の端末を利用して、対象となるWebサイトやサーバーに大量の通信を送り付けます。

    DDoS攻撃では、マルウェアに感染したパソコンやサーバー、ルーター、ネットワークカメラ、IoT機器などが攻撃に利用されることがあります。攻撃者の指示によって遠隔操作される端末の集まりは、ボットネットと呼ばれます。

    端末の所有者が、自分の機器が攻撃に利用されていることに気づいていないケースも少なくありません。攻撃者は、こうした多数の端末から同時に通信を発生させることで、大規模な攻撃を実行します。

    DDoS攻撃では、攻撃元となるIPアドレスが多数存在するため、特定の通信だけを遮断することが困難です。また、一般の利用者による正規のアクセスと攻撃通信が混在することもあり、単純なアクセス制限では対応できない場合があります。

    そのため、DDoS攻撃への対応には、通信量の監視やアクセス制御だけでなく、CDN、WAF（ウェブアプリケーションファイアウォール）、DDoS対策サービス、クラウド側の防御機能などを組み合わせた対策が必要です。

    DoS攻撃とDDoS攻撃の違い

    Dos攻撃／DDos攻撃とはのサムネ
    DoS攻撃/DDoS攻撃の概要図

    DoS攻撃とDDoS攻撃は、どちらもサービスの停止や遅延を引き起こす攻撃です。大きな違いは、攻撃元の数と攻撃規模にあります。

    DoS攻撃では、攻撃元が限られている場合、特定のIPアドレスを遮断することで対応できる可能性があります。

    一方、DDoS攻撃では、数多くの端末から通信が送られるため、攻撃元を一括して遮断することが難しくなります。正常な利用者の通信まで遮断してしまうと、自らサービスを停止させる結果にもなりかねません。

    また、DDoS攻撃は、大量の通信を送り付けるだけでなく、Webサーバーやアプリケーションに負荷の高い処理を繰り返させる形で実行されることもあります。

    そのため、通信量だけを監視するのではなく、アクセスパターンやリクエスト内容、処理負荷なども含めて異常を検知する必要があります。

    なぜDDoS攻撃が脅威なのか

    DDoS攻撃が企業にとって大きな脅威となる理由は、攻撃規模が大きいことだけではありません。攻撃元が分散しており、正規のアクセスとの見分けが難しい点にあります。

    多数の端末から同時に攻撃される

    DDoS攻撃では、ボットネットに組み込まれた多数の端末が利用されます。

    攻撃元が世界中に分散している場合、個別のIPアドレスを遮断しても、別の端末から攻撃が続く可能性があります。

    また、攻撃元となる端末の多くは、一般の企業や個人が利用しているパソコン、サーバー、IoT機器などです。そのため、単純に特定の国や地域からの通信を遮断するだけでは、攻撃を防げないことがあります。

    正規のアクセスと区別しにくい

    DDoS攻撃には、ネットワーク回線を大量の通信で埋め尽くす攻撃だけでなく、通常のWebアクセスとよく似たリクエストを繰り返す攻撃もあります。

    例えば、検索機能やログイン画面、商品一覧、APIなど、サーバー側で比較的大きな処理が必要となる機能にアクセスを集中させる手法です。

    通信そのものは通常のアクセスと似ているため、攻撃だけを正確に遮断することが難しくなります。

    短時間でも大きな損失につながる

    Webサイトやオンラインサービスが停止すると、企業にはさまざまな影響が生じます。

    • 商品やサービスの販売機会を失う
    • 顧客がサービスを利用できなくなる
    • コールセンターや問い合わせ窓口への連絡が増える
    • 復旧対応や原因調査に人的コストがかかる
    • 顧客や取引先からの信用が低下する
    • SLA違反や契約上の問題が発生する

    ECサイトや予約サービス、金融サービス、オンラインゲーム、SaaSなど、インターネット上でサービスを提供する企業では、短時間の停止でも売上や顧客満足度に大きな影響を与える可能性があります。

    別の攻撃と同時に行われることがある

    DDoS攻撃は、単独で実行されるとは限りません。

    大量のアラートや障害対応によって企業の担当者を混乱させ、その間に別のシステムへの不正アクセスを試みるなど、陽動目的で利用される可能性もあります。

    DDoS攻撃が発生した場合には、サービス復旧だけに集中するのではなく、不審なログインや設定変更、マルウェア感染、情報漏えいなど、別の異常が発生していないかも確認することが重要です。

    企業が取るべき対策

    DoS攻撃やDDoS攻撃を完全に防ぐことは容易ではありません。特に大規模なDDoS攻撃では、自社のサーバーやネットワーク機器だけで防御することは難しく、通信が自社環境に到達する前の段階で対処する必要があります。重要なのは、単一の製品や設定だけに依存せず、複数の対策を組み合わせることです。

    1. 必要のないサービス・プロセス・ポートは停止する
    2. OSや機器、ソフトウェアを更新する
    3. リクエスト数やデータ容量を制限する
    4. CDNやDDoS対策サービスを利用する
    5. 脆弱性対策が施されたパッチを適用する
    6. WAFを導入する
    7. システムを冗長化する
    8. 通信状況を監視する
    9. 脆弱性診断を実施する
    10. DoS攻撃/DDoS攻撃の端緒になりうる各種の不備を見つけて直す

    自組織のセキュリティ状況を見直し、リスク状況を把握することにより、攻撃に備えることが大切です。どの対策のほうがより効果があるということではなく、それぞれ防御するレイヤーが異なるので複数組み合わせていく、「多層防御」がより効果的です。

    WAF（ウェブアプリケーションファイアウォール）

    WAFでは大量に不正に送信される大量のパケットのブロックや、一時的にアクセスが集中した際にはサーバが停止する前にアクセスの制限をかけるなどができます。また、適切なシグネチャ（Webアプリケーションへのアクセスパターンの定義ファイル）を設定しておくことで、攻撃コードの送信を検知して攻撃コードがアプリケーションに届く前に不正なコードの送信としてWAFで止めることが可能になります。

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

    脆弱性診断を行うことで予め管理しているWebアプリケーションの脆弱性状況を把握し、脆弱性の修正を行うことによってスキャンされた際に脆弱性情報としてハッカーの目に留まることを防げます。脆弱性を悪用した攻撃についても同様でそもそも悪用できそうな脆弱性がない、という状態を維持することができます。

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

    脆弱性や設定不備に起因するDoS攻撃は予防できる

    DoS攻撃/DDoS攻撃は攻撃の発生に気づくのが難しいという話を記事内で述べましたが、一方で、防ぐことができるタイプの攻撃も存在します。

    一部のWebサイトでは、「長大な文字列を受け入れてしまう」「ファイルの容量を制限しない」など、DoS攻撃につけ込まれてしまう問題が存在することがあります。また、ネットワーク関連の設定の不備によってDoS攻撃を受ける可能性も存在します。しかし、こうした脆弱性は、修正による回避が可能です。

    また、あなたの企業が直接DoS攻撃の攻撃対象とならなくても、上述のような脆弱性を放置しておくとDDoS攻撃の踏み台にされることもあります。その対策としては、各種機器・OS・ソフトウェアの脆弱性管理を適切に行うことや、脆弱性診断等のセキュリティ診断を定期的に実施して未知のリスクを把握し、対処することが重要です。

    【コラム】診断会社あるある「すわ、DoS攻撃？」

    ここで余談ではありますが、診断実施に伴う「あるある」エピソードを。
    セキュリティ診断を行う際には、必ず、実施の年月日や時間帯を関連する部署に周知しなくてはなりません。実は、診断実施に伴って事業部門等が「DoS攻撃が発生した！」と勘違いすることが、しばしばあるのです。もちろん、一般にインターネット上に公開しているシステムの場合には業務に差し支えるような検査の仕方をしないというのが大前提ですが、それでも、大量の問合せ等が発生すると何も知らされていない担当部署はサイバー攻撃と勘違いすることがあります。ついでにこの際に抜き打ちで社内のサイバー訓練を・・・と目論みたい気持ちが出たとしても、それを実行に移すのは大変危険です。訓練は訓練させる側にきちんとした検証シナリオがあってこそ効果を発揮します。まずは関係各所との連携を徹底するところから始めましょう。

    DDoS攻撃では、サービス復旧だけでなく、不正アクセスや情報漏えいの有無も確認することが重要です。初動対応の流れや確認すべきポイントについては、こちらの記事で詳しく解説しています。
    「DDoS攻撃を受けたらどうする？―初動対応から復旧までの流れを解説―」

    まとめ

    DoS攻撃とDDoS攻撃は、どちらもサーバーやネットワークに負荷をかけ、サービスの遅延や停止を引き起こす攻撃です。

    DoS攻撃は1台または少数の端末から行われることが多いのに対し、DDoS攻撃は多数の端末から同時に実行されます。

    DDoS攻撃は、攻撃元が分散しているため特定や遮断が難しく、正規のアクセスと攻撃通信を見分けにくい点が特徴です。

    企業は、CDNやWAF、DDoS対策サービス、システムの冗長化、通信監視などを組み合わせて、被害を抑える必要があります。

    また、脆弱性や設定不備を悪用するDoS攻撃については、OSやソフトウェアの更新、不要なサービスの停止、アクセス制御の見直し、脆弱性診断などによってリスクを低減できます。

    攻撃を完全に防ぐことだけを目指すのではなく、異常を早期に検知し、サービスへの影響を最小限に抑え、迅速に復旧できる体制を整えておくことが重要です。

    公開日：2022年8月3日
    更新日：2026年8月5日

    編集責任：木下

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

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

    投稿日:

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

    Share

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

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

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

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

    DDoS攻撃とは

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

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

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

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

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

    DoS攻撃との違い

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

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

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

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

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

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

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

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

    DDoS攻撃の仕組み

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

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

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

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

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

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

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

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

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

    攻撃の流れ

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

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

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

    DDoS攻撃の主な種類

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

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

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

    ボリューム攻撃

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

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

    プロトコル攻撃

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

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

    アプリケーション層攻撃

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

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

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

    DDoS攻撃による被害

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

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

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

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

    サービス停止

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

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

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

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

    業務への影響

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

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

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

    企業の信頼低下

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

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

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

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

    通信の監視と異常検知

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    まとめ

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

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

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

    【関連記事】

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

    【参考情報】

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

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

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

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

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

    編集責任：木下

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

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

    投稿日:

    【企業のためのランサムウェア対策ガイド】ランサムウェアの感染経路とは ―企業が見落としがちなVPN・RDP侵入リスクを解説

    Share
    ランサムウェアの感染経路とは ―企業が見落としがちなVPN・RDP侵入リスクを解説アイキャッチ画像

    ランサムウェア対策を考えるうえで重要なのが、「どこから侵入されるのか」を理解することです。近年の企業向けランサムウェア攻撃では、メールだけでなく、VPN機器やリモートデスクトップ（RDP）の脆弱性、認証情報の悪用、サプライチェーン経由の侵入など、多様な経路が利用されています。本記事では、企業が見落としがちな代表的な感染経路と、その対策の考え方について解説します。

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

    ランサムウェアは、ある日突然社内のパソコンやサーバ上で実行されるように見えます。しかし実際には、その前段階で攻撃者が企業ネットワークへ侵入しています。メール、VPN機器、リモートデスクトップ、ソフトウェアの脆弱性、外部委託先など、侵入経路はさまざまです。特に近年は、単に添付ファイルを開かせる攻撃だけでなく、インターネットに公開されたVPN機器やリモートアクセス環境の脆弱性、認証情報の悪用、委託先や外部サービスを踏み台にした侵入が問題になっています。警察庁やIPAの資料でも、国内のランサムウェア被害ではVPN機器やリモートデスクトップなど、テレワーク環境に関連する経路が多く確認されています。

    ランサムウェアはどこから侵入するのか

    ランサムウェアの感染経路は、ひとつに限定されません。攻撃者は、企業の外部に開いている入口、従業員が日常的に使うメール、保守やテレワークのためのリモート接続、未修正のソフトウェア、さらには取引先や委託先との接続関係まで、複数の経路を組み合わせて侵入を試みます。従来は、ランサムウェアというと「不審なメールの添付ファイルを開いて感染する」というイメージが強くありました。もちろんメールは現在でも重要な感染経路ですが、企業におけるランサムウェア被害では、VPN機器やリモートデスクトップなど、外部から社内環境へ接続するための仕組みが狙われるケースが目立ちます。

    米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が公開している「#StopRansomware Guide」でも、ランサムウェアやデータ恐喝型攻撃の初期侵入経路として、インターネットに公開された脆弱性や設定ミス、フィッシング、認証情報の悪用、リモートアクセス環境などが重視されています。つまり、ランサムウェア対策は「端末にウイルス対策ソフトを入れる」だけでは不十分であり、外部公開資産、認証、運用設定、委託先管理まで含めて考える必要があります。

    代表的な感染経路

    メールによる感染

    メールは、現在でもランサムウェア感染の代表的な入口です。攻撃者は、請求書、見積書、配送通知、業務連絡、採用関連の連絡などを装い、添付ファイルや本文中のリンクを開かせようとします。従業員が添付ファイルを開いたり、リンク先で認証情報を入力したりすると、マルウェア感染やアカウント窃取につながる可能性があります。ただし、近年のランサムウェア攻撃では、メールから即座に暗号化が始まるとは限りません。メールをきっかけに認証情報を盗み、その後VPNやクラウドサービスへ不正ログインする場合もあります。また、メール経由で侵入したマルウェアが端末内の情報を収集し、攻撃者が次の侵入経路を探す足がかりになることもあります。そのため、メール対策は「怪しいメールを開かないように教育する」だけでは不十分です。迷惑メール対策、添付ファイルの検査、URLフィルタリング、多要素認証、端末の挙動監視を組み合わせ、万が一クリックされても被害が広がりにくい仕組みを整える必要があります。

    VPN機器の脆弱性

    企業のランサムウェア対策で特に注意すべき感染経路が、VPN機器の脆弱性です。VPNは、テレワークや拠点間接続、外部からの保守作業に欠かせない仕組みですが、インターネット側に公開されているため、攻撃者にとっても狙いやすい入口になります。独立行政法人情報処理推進機構（IPA）「情報セキュリティ10大脅威 2026」でも、ランサムウェア被害の感染経路としてVPN機器経由が大きな割合を占め、VPN機器経由とリモートデスクトップ経由を合わせると毎年高い割合を占めていることが示されています。

    VPN機器に未修正の脆弱性が残っている場合、攻撃者は認証を突破したり、機器上の情報を盗んだり、社内ネットワークへ侵入したりする可能性があります。特に、サポート切れの機器、更新が滞っているファームウェア、初期設定に近いまま運用されている環境、不要なアカウントが残っている環境は危険です。VPN機器は一度導入すると、業務インフラとして長く使われがちです。そのため、導入時には問題がなかったとしても、数年後に深刻な脆弱性が公表され、攻撃対象になることがあります。ランサムウェア対策では、VPN機器のメーカー名、型番、バージョン、サポート期限、適用済みパッチを定期的に確認することが重要です。

    リモートデスクトップ（RDP）の悪用

    リモートデスクトップ（RDP）も、ランサムウェアの代表的な感染経路です。RDPは、離れた場所から社内のPCやサーバを操作できる便利な仕組みですが、外部から直接接続できる状態になっていると、攻撃者にとって格好の侵入口になります。CISAが公開するランサムウェア関連アドバイザリ（#StopRansomware: Akira Ransomware）でも、RDPやVPNなどのリモートアクセスサービスが初期侵入に使われる事例が継続的に示されています。

    攻撃者は、単純なパスワードの総当たり攻撃、過去に漏えいした認証情報の悪用、設定不備の探索などによって、RDP接続を突破しようとします。一度RDP経由で社内端末やサーバへ入られると、攻撃者は管理者権限の取得、他端末への横展開、データの持ち出し、バックアップの削除、ランサムウェアの実行へと進む可能性があります。RDPを業務上どうしても使う場合は、インターネットへ直接公開しないことが基本です。VPNやゼロトラスト型のアクセス制御を経由させ、多要素認証を必須にし、接続元制限、ログ監視、不要アカウントの削除を徹底する必要があります。

    ソフトウェアの脆弱性

    ランサムウェアの感染経路として見落とされやすいのが、OS、ミドルウェア、業務システム、Webアプリケーション、ネットワーク機器などのソフトウェア脆弱性です。Verizon「2025 Data Breach Investigations Report」（DBIR）でも、脆弱性の悪用による初期アクセスが増加していることが示されており、境界デバイスや外部公開システムの管理が企業のセキュリティ課題として重要になっています。

    攻撃者は、公開された脆弱性情報をもとに、未修正のシステムをインターネット上で探索します。特に危険なのは、外部からアクセスできるシステムに深刻な脆弱性が残っている場合です。VPN、ファイアウォール、メールサーバ、ファイル転送システム、Web管理画面、クラウド連携用の管理コンソールなどは、攻撃者から常に探索対象になっていると考えるべきです。脆弱性対策では、単にパッチを適用するだけではなく、自社がどのシステムを外部公開しているかを把握することが出発点になります。資産管理が不十分なままでは、どの機器に脆弱性があるのか、どのシステムを優先して更新すべきかを判断できません。

    サプライチェーン経由の感染

    ランサムウェアの感染経路は、自社のネットワークや端末だけに限られません。委託先、外部サービス、クラウドサービス、保守ベンダー、取引先との接続環境を通じて侵入されることもあります。こうした外部経由の侵入は、サプライチェーン攻撃としても知られています。Verizon「2025 Data Breach Investigations Report」でも、漏えい・侵害に第三者が関与する割合が増加していることが示されており、サプライチェーンリスクは企業規模を問わず無視できない課題になっています。

    たとえば、業務委託先が利用しているアカウントが侵害され、そのアカウントを使って自社環境へ不正アクセスされるケースがあります。また、外部保守用に開放していたリモート接続が攻撃者に悪用される場合や、取引先とのファイル共有環境を通じてマルウェアが持ち込まれる場合もあります。サプライチェーン経由の感染が厄介なのは、自社だけで完全に制御しにくい点です。自社のセキュリティ対策が一定水準に達していても、接続先や委託先の管理が甘ければ、そこが攻撃者にとっての入口になります。

    こうした外部経由の侵入は、サプライチェーン攻撃としても知られています。詳しくは以下の記事で解説しています。
    「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

    ランサムウェア対策としては、委託先との接続経路、付与している権限、共有している情報、外部アカウントの管理状況を定期的に見直す必要があります。外部委託先に対しても、多要素認証、アクセス権限の最小化、ログ取得、契約上のセキュリティ要件、インシデント発生時の連絡体制を確認しておくことが重要です。

    なぜ気づかず侵入されるのか

    ランサムウェア感染が深刻化する理由のひとつは、攻撃者が侵入してから暗号化を実行するまでに時間差があることです。企業側から見ると、ある日突然ファイルが暗号化されたように見えます。しかし実際には、その前に認証情報の窃取、社内探索、権限昇格、横展開、データ窃取といった活動が行われている場合があります。攻撃者が長く潜伏できる背景には、認証情報の管理不備があります。退職者や異動者のアカウントが残っている、管理者権限が過剰に付与されている、同じパスワードを複数システムで使い回している、多要素認証が導入されていない、といった状態では、攻撃者にとって侵入後の行動が容易になります。また、設定ミスも大きな問題です。RDPがインターネットに公開されている、VPN機器のファームウェアが古い、管理画面に外部からアクセスできる、不要なポートが開いている、ログが保存されていないといった状態は、攻撃者にとって有利に働きます。

    NIST(米国立情報技術研究所)NIST IR 8374 Rev.1「Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile」では、ランサムウェアへの備えとして、識別、防御、検知、対応、復旧を含めた包括的なリスク管理の重要性が示されています。これは、ランサムウェア対策が単なるマルウェア対策ではなく、資産管理、アクセス制御、バックアップ、ログ監視、インシデント対応を含む経営課題であることを意味します。

    感染リスクを下げるための考え方

    ランサムウェアの感染リスクを下げるには、すべての対策を一度に完璧に実施しようとするのではなく、侵入されやすい場所から優先順位をつけて対策することが重要です。特に企業では、VPN機器、リモートデスクトップ、外部公開サーバ、メール、認証情報、委託先接続の順に確認すると、自社の弱点を見つけやすくなります。

    最初に行うべきことは、外部から見える資産の棚卸しです。どのVPN機器を使っているのか、RDPが外部公開されていないか、古いサーバや管理画面が残っていないか、クラウドサービスの管理者アカウントが適切に管理されているかを確認します。自社が把握していないシステムは、守ることも更新することもできません。次に、認証情報の保護を強化します。多要素認証の導入、不要アカウントの削除、管理者権限の最小化、パスワードの使い回し防止、ログイン試行の監視は、ランサムウェア対策の基本です。特にVPN、RDP、クラウド管理画面、メールアカウントには優先的に適用すべきです。さらに、脆弱性管理を継続的に行う必要があります。OSやソフトウェアの更新だけでなく、ネットワーク機器、VPN、ファイアウォール、NAS、ファイル転送システムなど、外部公開される可能性のある機器の脆弱性情報を確認し、リスクの高いものから修正します。バックアップも重要ですが、バックアップがあるだけでは十分ではありません。攻撃者にバックアップまで削除・暗号化されないよう、ネットワークから分離したバックアップや、復旧手順の確認が必要です。ランサムウェア対策では、感染を防ぐ対策と、感染した場合でも事業を止めない対策を組み合わせることが求められます。

    まとめ

    ランサムウェアの感染経路は、メールだけではありません。VPN機器の脆弱性、リモートデスクトップの悪用、ソフトウェアの未修正脆弱性、認証情報の窃取、設定ミス、委託先や外部サービスを経由したサプライチェーン攻撃など、企業のさまざまな入口が狙われています。特に近年の企業向けランサムウェア攻撃では、攻撃者が事前に社内ネットワークへ侵入し、権限を広げ、データを盗み、最後に暗号化を実行する流れが一般化しています。そのため、ランサムウェア対策は「感染後にどう復旧するか」だけでなく、「どこから入られる可能性があるか」を把握し、侵入経路を減らすことから始める必要があります。

    企業がまず取り組むべきことは、自社の外部公開資産を把握し、VPNやRDPの設定を見直し、ソフトウェアの脆弱性を管理し、認証情報を守り、委託先との接続経路を確認することです。すべてを一度に完璧にする必要はありませんが、攻撃者にとって狙いやすい入口を放置し続けることは、ランサムウェア被害のリスクを高めます。ランサムウェアの感染経路を理解することは、対策の出発点です。自社のどこが侵入口になり得るのかを確認し、優先順位をつけて改善していくことが、企業のランサムウェア対策において最も現実的で効果的な第一歩になります。

    万が一感染してしまった場合の具体的な対応については、以下の記事で詳しく解説しています。
    「セキュリティインシデントの基礎から対応・再発防止まで　第2回：セキュリティインシデント発生時の対応 ─初動から復旧まで」

    【参考情報】

    編集責任：木下

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

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

    投稿日:

    クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―

    Share
    クレジットカード情報漏洩に備える ―非保持化・PCI DSS準拠でも漏洩が起きる理由とは―アイキャッチ画像

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではありません。非保持化やPCI DSS準拠を実施していても、Webサイトの脆弱性や設定不備を起点に漏洩が発生するケースは少なくありません。本記事では、実際の漏洩事例や発生後に直面する課題を踏まえながら、情報漏洩に備えるために押さえておきたいポイントを解説します。

    なぜクレジットカード情報漏洩が起きるのか

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題として発生するわけではありません。ECサイトの決済は、ECサイト加盟店、決済代行事業者（PSP：Payment Service Provider）、アクワイアラ、国際ブランドなど、複数の事業者が連携して成り立っています。そのため、サイバー攻撃者に狙われる対象は、カード情報を直接保有するシステムだけに限られません。

    実際には、ECサイト加盟店のECサイトや管理画面、CMS、外部委託先、決済画面へ遷移する前後の処理など、周辺のどこかにWebアプリケーションの脆弱性や設定不備が存在するだけで、カード情報の窃取につながる可能性があります。カード情報を自社で保持していない場合でも、サイト改竄や悪意あるコードの挿入によって、利用者が入力した情報が攻撃者へ送信されてしまうケースがあります。弊社のPFI調査資料でも、カード情報を自社保有していない企業からの漏洩に関する相談が多く発生していることが示されています。

    ECサイトでは外部サービス連携、プラグイン更新、機能追加などが継続的に発生します。そのため、一度安全な構成を整備したとしても、それだけで安全性が維持されるわけではありません。日々の運用の中で新たに生まれた脆弱性が、攻撃の端緒となる場合があります。特に、Webアプリケーションの脆弱性や管理画面の設定不備は、PFI調査において主要な漏洩の原因として挙げられています。決済は複数の事業者が関与する仕組みであるため、そのサプライチェーンの一箇所で発生したサイバー攻撃が、ECサイト加盟店の業務停止、PSPへの問い合わせ対応、アクワイアラや国際ブランドへの報告対応へと波及する可能性があります。クレジットカードの情報漏洩は、単なる技術的な事故ではなく、決済サプライチェーン全体へ影響を及ぼすインシデントとして捉える必要があります。

    実際に発生している情報漏洩事例

    公表資料や業界資料を見ると、漏洩のきっかけは一様ではありません。ECサイトの改竄、不正ファイルの設置、偽の決済画面への誘導、委託先や関連システムの不備など、さまざまな経路からカード情報の窃取につながっています。経済産業省の資料でも、ECサイト加盟店、ECシステム提供事業者、PSP、消費者を狙ったフィッシング被害など、複数の漏洩事案の類型が整理されています。たとえば、ECサイト加盟店のECサイトに存在する脆弱性を突かれ、サイトが改竄されるケースがあります。この場合、カード情報を保持していなくても、不正ファイルの設置や偽の決済画面への誘導により、利用者が入力したカード番号等が攻撃者へ送信される可能性があります。また、委託先業者によるサイト更新時の設定不備を起点に、不正アクセスや情報漏洩につながるケースもあります。さらに、決済関連システム側の脆弱なアプリケーションへ不正アクセスされる事例も挙げられています。

    PSPで情報漏洩が発生すると、利用者、ECサイト加盟店、クレジットカード会社など、多くの関係者を巻き込む被害につながるおそれがあります。これらの事例は、クレジットカード情報漏洩が単一のセキュリティ製品だけで防げる問題ではなく、開発、運用、委託管理、監視のすべてが関係する問題であることを示しています。また、近年は発覚経緯にも変化が見られます。2024年のカード情報流出事件では、警察の指摘により発覚した事案が35.1％を占めたとの分析もあります。また、2024年のクレジットカード不正利用被害額は555億円とされ、その9割超がECサイトでの番号盗用によるものとされています*8。

    これらの事例から分かるのは、クレジットカード情報漏洩が例外的な事故ではなく、現実的にはEC決済の現場で継続的に発生する身近なリスクだということです。PSPにとっても、漏洩元が自社であるか否かにかかわらず、問い合わせ、調査協力、ECサイト加盟店支援、関係者への説明といった対応が発生し得る点を踏まえる必要があります。

    なぜ対策していても防げないのか

    クレジットカードの情報漏洩対策として、「カード情報を保持しない非保持化」や「PCI DSS準拠」といった取り組みは非常に重要です。しかし、これらはリスクを低減するための対策であり、残念ながら漏洩を完全に防ぐことを保証してくれるものではありません。たとえば、カード情報の非保持化を行っている場合でも、ECサイトが改竄され、偽の入力フォームや悪意あるスクリプトが設置されてしまえば、利用者が入力したカード情報が攻撃者へと送信される可能性があります。つまり、カード情報を「保管していない」ことと、「情報入力時に窃取されない」ことは別の問題なのです。ECサイト全体の安全性まで担保されるわけではありません。PCI DSSについても同様です。PCI DSSに準拠していること自体が将来の侵害を否定してくれるものではありません。実際のインシデントでは、Webアプリケーションの脆弱性、管理画面の設定不備、委託管理先の不備、脆弱なパスワード設定など、複数の問題が重なって発生するケースが見られます。弊社のPFI調査資料でも、アプリケーションの脆弱性や管理画面の設定不備が主要な漏洩原因として挙げられています。

    重要なのは、「非保持化しているから安全」、「PCI DSSに準拠しているから安全」と受け止めるのではなく、それぞれの対策が守れる範囲と限界を理解することです。クレジットカード情報漏洩は、技術、運用、管理といった複数の要因が重なって発生するため、防御だけではなく、継続的な監視や発生時の対応体制まで含めて備える必要があります。

    インシデント発生後の現実

    クレジットカード情報漏洩が疑われる事態に直面すると、現場では短時間で多くの判断が求められます。特に、次のような課題が発生する可能性があります。

    • 初動対応の遅れ
      被害拡大を防ぐため、ECサイトの停止、クレジットカード決済の一時停止、不正ファイルの確認、関係者への連絡などを並行して進める必要があります。対応が遅れた場合、新たな被害につながるおそれがあります。
    • ログ不足
      原因や影響範囲を調査しようとしても、必要なログが保存されていない、保存期間が短い、委託先から提供されないといった状況では、調査が難航します。ログの保全・管理体制が不十分であることが課題となるケースも少なくありません。
    • 調査・報告対応
      インシデント対応では、被害拡大を防ぐための封じ込めも重要です。さらに、個人情報保護委員会への報告や本人通知、公表対応など、時間的制約のある対外対応も並行して進めなければなりません。
    • 業務・信用への影響
      決済停止やECサイト停止は、売上の減少、顧客対応、問い合わせ対応の発生に直結します。実際に、クレジットカード決済の停止が長期化した事例や、決済再開までの期間、クレジットカード決済以外でECサイトを継続できるかといった相談も挙げられています。決済再開に向けた調整や関係者との連携も必要となり、事業運営や信用面にも大きな影響を及ぼす可能性があります。

    PSPはどこまで責任を負うのか？

    クレジットカード情報漏洩のインシデントでは、実際に情報漏洩が発生したECサイト加盟店やシステム事業者だけでなく、決済に関わる複数の事業者が対応を求められる場合があります。特にPSPはインシデント発生時に一定の関与が発生する可能性があります。たとえば、ECサイト加盟店からの問い合わせ対応、決済停止や再開に関する調整、関係各所への情報共有、調査協力などが挙げられます。また、利用者への影響範囲や決済への影響を整理する中で、PSPが保有するログや取引情報の確認が必要になるケースもあります。

    もちろん、すべてのケースでPSPが法的責任を負うとは限りません。しかし実際には、「どのシステムで何が起きたのか」、「どこまで影響が及んでいるのか」を整理する過程で、決済のハブとしての対応が求められる場面があります。関係者間で認識や説明内容に差異が生じれば、公表内容や顧客説明にも影響する可能性があります。また、インシデント発生時には、技術的な問題だけでなく、ECサイト加盟店や委託先との調整、問い合わせ対応、事実確認など、実務面での負荷も大きくなります。そのためPSPにとっても、インシデント対応は「加盟店側の問題」と安易に切り離して考えられるものではありません。重要なのは、インシデント発生後に責任範囲を議論することだけではなく、平時から、どのような連携体制で対応するのか、どの情報を誰が保有しているのか、どのように調査や報告を進めるのかを十分に整理しておくことです。

    インシデント対応で求められるフォレンジック調査

    クレジットカード情報漏洩が疑われる場合、適切な封じ込めや再発防止につなげるためにも、何が起きたのかを客観的に把握することが重要です。そのため、フォレンジック調査では次のような対応を行います。

    • 原因の特定
      ECサイトの改竄、不正ファイルの設置、管理画面からの侵入など、どのような経路で侵害が発生したのかを調査し、事実関係を整理します。
    • 被害範囲の把握
      どの期間に、どの画面やシステムが影響を受け、どの情報が漏洩した可能性があるのかを確認します。影響範囲を把握することで、関係者への説明、外部報告、顧客対応、決済再開の判断をしやすくなります。
    • 侵入経路や影響の分析
      ログ、ファイル、通信履歴、システム構成などを調査し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにします。
    • 報告・説明対応の支援
      クレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応が求められることがあります。第三者による調査結果は、事実確認や説明責任を果たすうえで重要な根拠となります。
    • 再発防止にむけた基盤づくり
      フォレンジック調査は単なる原因調査ではなく、被害拡大防止、再発防止、関係者への説明を支えるための重要なプロセスです。ログ、ファイル、通信、システム構成などを確認し、侵入経路や改竄内容、攻撃の時系列、影響範囲を明らかにしていきます。何が分かり、何が分からないのかを整理することで、その後の対応につなげることができます。特にクレジットカード情報漏洩が疑われる場合には、アクワイアラや国際ブランド等への報告対応も想定されるため、第三者による調査結果が重要になる場面があります。

    初動対応を左右する平時の備え

    クレジットカード情報漏洩のインシデントでは、発生後の初動対応がその後の調査、報告、復旧に大きく影響します。どのシステムを確認するのか、どのログを保全するのか、誰に連絡するのかが整理されていなければ、対応開始までに時間を要してしまいます。結果として、被害範囲の特定や関係者への説明も遅れる可能性があります。そのため重要になるのが、「平時からの備え」です。具体的には、システム構成や委託先の把握、ログの保存場所や保全方針の確認、関係者の連絡先や判断権限の整理、初動対応手順の整備、外部専門家との連携体制の確保などが挙げられます。さらに、NDAや基本契約を事前に整えておけば、インシデント発生後に契約条件や情報共有範囲を調整する時間を減らし、調査や封じ込めに着手しやすくなります。これらを事前に確認しておくことで、発生時に「何から手を付けるか」と迷う時間を減らすことができます。

    平時の備えは技術部門だけの課題ではありません。法務、広報、顧客対応、経営層、委託先を含めた体制整備が必要です。インシデント発生時には、技術調査と並行して、報告、通知、公表、問い合わせ対応が進むためです。クレジットカード情報漏洩対策では、防御策を強化することはもちろん重要です。しかし、それだけでは十分とはいえません。万一に発生した場合は、速やかに封じ込め、調査し、説明できる状態を作っておくことが重要です。

    有事に備えた準備はできていますか？

    クレジットカード情報漏えいが発生した場合、初動対応、原因調査、被害範囲の特定、関係各所への報告など、多くの対応を短期間で進める必要があります。BBSecでは、PCI SSC認定のPFIとして、クレジットカード情報漏えいフォレンジック調査を提供しています。万が一の際に迅速な対応を行うためにも、平時からの備えをご検討ください。
    ▶ クレジットカード情報漏えいフォレンジック調査サービスはこちら

    まとめ

    クレジットカード情報漏洩は、ECサイト加盟店だけの問題ではなく、PSPを含む決済サプライチェーン全体に影響を及ぼすインシデントです。情報の非保持化やPCI DSS準拠といった対策は重要ですが、それだけでリスクを完全に防ぐことはできません。だからこそ、防御策に加え、発生時の初動対応、調査、関係者連携まで含めて、平時から備えておくことが重要です。

    「非保持化しているから安心」とは言い切れない時代へ
    情報漏洩インシデントは、Webアプリケーションの脆弱性や設定不備、運用上の課題など、複数の要因が重なって発生します。PCI DSS v4.0では、継続的な脆弱性管理やペネトレーションテストなど、従来以上に運用・監視を重視した対応が求められています。情報漏洩リスクに備えるために、PCI DSS v4.0で押さえておきたいポイントをウェビナーで詳しく解説しています。
    【関連ウェビナー】「今さら聞けない！PCI DSS v4.0で求められる脆弱性診断」
    ▶ 詳細・お申し込みはこちら

    Security Report 2026春夏号資料ダウンロードボタン

    無料PDF｜SQAT® Security Report 2026春夏号

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

    サービスに関する疑問や質問はこちら

    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    BBSecホワイトペーパー「企業のセキュリティ成熟度チェックリスト」資料ダウンロードボタン

    編集責任：木下

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

    投稿日:

    脆弱性スキャンとは？脆弱性診断ツールの選び方と導入ポイント

    Share
    「脆弱性スキャンとは？脆弱性診断ツールの選び方と導入ポイント」アイキャッチ画像

    脆弱性スキャンは、企業のシステムやネットワーク、Webアプリケーション、クラウド環境に存在する既知の脆弱性を効率よく洗い出すための基本的な手段です。近年は、公開サーバーやVPN機器だけでなく、クラウド上のワークロード、コンテナ、OSSライブラリまで管理対象が広がっており、手作業だけで安全性を確認するのは現実的ではありません。そこで重要になるのが、脆弱性スキャナーや脆弱性診断ツールを使って、環境全体を継続的に確認する考え方です。CISAも、インターネット公開資産に対する継続的な 脆弱性スキャンを、基本的な「サイバーハイジーン（Cyber Hygiene）」の一環として位置付けています。

    ただし、脆弱性スキャンを導入すれば自動的に安全になるわけではありません。スキャンはあくまで既知の弱点を機械的に見つける仕組みであり、誤検知や過検知、設定不備の見落とし、業務影響を踏まえた優先順位判断までは自動では完結しません。そのため実務では、脆弱性スキャンの役割を正しく理解したうえで、脆弱性診断や脆弱性管理のプロセスと組み合わせて運用する必要があります。本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理します。

    脆弱性スキャンとは

    脆弱性スキャンとは、サーバー、ネットワーク機器、Webアプリケーション、クラウド環境などに対して自動的に検査を行い、既知の脆弱性や不適切な設定、不足している更新などを検出する仕組みです。企業が脆弱性スキャンを導入する目的は、攻撃者に悪用される前に自社環境の弱点を見つけ、修正につなげることにあります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）のCyber Hygiene Servicesでも、Vulnerability Scanning（脆弱性スキャン）はインターネットから到達可能な資産を継続的に監視し脆弱性の有無を評価するサービス、として説明されています。

    脆弱性スキャンの特徴は、自動化にあります。人手では確認しきれない大量のIPアドレス、Webアプリケーション、仮想マシン、コンテナイメージなどを機械的に点検し、既知の脆弱性情報や設定ミスと突き合わせることで、短時間に広い範囲を確認できます。NIST SP 800-115『Technical Guide to Information Security Testing』でも、自動化されたテスト手法は情報セキュリティ評価の重要な手段とされ、SCAPのような標準化された枠組みが脆弱性管理の自動化を支えるものとして紹介されています。

    一方で、脆弱性スキャンには限界もあります。自動スキャンは既知のパターンには強いものの、業務ロジックに起因する脆弱性や、文脈を踏まえた攻撃シナリオまでは把握しきれない場合があります。また、誤検知や重複検知が発生することもあるため、結果をそのまま鵜呑みにするのではなく、影響の確認と優先順位付けが必要です。つまり脆弱性スキャンは、脆弱性管理の入口として非常に有効ですが、それだけで完結するものではありません。

    脆弱性スキャンを適切に実施するためには、対象となるIT資産を正確に把握することが重要です。サーバーやネットワークだけでなく、クラウド環境やOSSコンポーネントも対象となります。IT資産管理と脆弱性管理の関係については、以下の記事も参考になります。
    「脆弱性管理とIT資産管理 -サイバー攻撃から組織を守る取り組み-」

    脆弱性診断との違い

    脆弱性スキャンと脆弱性診断は混同されやすい言葉ですが、実務上は役割が異なります。脆弱性スキャンは、既知の脆弱性や設定不備を自動的に広く洗い出すことに向いています。これに対して脆弱性診断は、専門家が対象システムの構造や挙動を踏まえながら、ツールだけでは見つけにくい問題も含めて詳細に評価する行為です。OWASPでは、ペネトレーションテストやセキュリティテストがスキャン単独よりも実際の攻撃可能性やリスク評価をより正確に把握する助けになる、と説明しています*2。

    たとえば、Webアプリケーションに対する自動スキャンでは、SQLインジェクションやクロスサイトスクリプティングの典型的なパターンは検出しやすい一方で、権限管理の不備や業務フロー上のロジック欠陥、複数機能をまたいだ複雑な脆弱性は取り逃がす可能性があります。OWASPのOWASP Web Security Testing Guideでは、Webセキュリティ評価が単なる自動実行ではなく、アプリケーションの設計や攻撃面を踏まえた体系的なテストであることを示しています。

    そのため企業では、脆弱性スキャンと脆弱性診断を対立概念として捉えるよりも、目的に応じて使い分けることが重要です。日常的な広範囲確認には脆弱性スキャンが向いており、公開Webサービスや重要システムの深い評価には脆弱性診断が向いています。脆弱性スキャンは継続運用の基盤、脆弱性診断は重点箇所の深掘りというように整理すると理解しやすいでしょう。

    脆弱性スキャンの種類

    脆弱性スキャンにはいくつかの種類があり、どこを対象にするかで使うツールや評価軸が変わります。

    Webスキャン

    OWASPでは、Webアプリケーション脆弱性スキャンを、外部からWebアプリケーションを自動検査し、XSS、SQLインジェクション、コマンドインジェクション、パストラバーサル、不適切な設定などの脆弱性を探すツール、として説明しています*2。いわゆるDAST（Dynamic Application Security Testing）に近い領域であり、インターネット公開されるサービスでは特に重要です。企業サイト、会員サイト、管理画面、APIなど、公開面があるならWebスキャンは有力な選択肢になります。

    ネットワークスキャン

    サーバー、ルーター、ファイアウォール、VPN装置などに対して、開いているポート、稼働サービス、既知の脆弱性、更新不足の状況を確認するものです。特にインターネットに公開された機器は攻撃対象になりやすいため、CISAも継続的なスキャンの重要性を強調しています。

    クラウドスキャン

    クラウドでは、OSやミドルウェアの脆弱性だけでなく、ストレージの公開設定、IAM権限、コンテナ設定、イメージの更新状況なども安全性に大きく影響します。従来型のネットワークスキャンだけでは十分でなく、CSPMやCNAPP系の機能を持つツールでクラウド設定やワークロードを可視化する必要があります。共有責任モデルのもとでは、クラウド事業者が管理しない部分は利用企業側が継続的に見なければなりません。

    さらに、OSS脆弱性スキャン、いわゆるSCAも見逃せません。現代のソフトウェアは多くのOSSライブラリに依存しており、アプリケーション本体に問題がなくても、依存パッケージの脆弱性がリスクになります。NTIA（米国商務省電気通信情報局：National Telecommunications and Information Administration）が公開している「The Minimum Elements For a Software Bill of Materials (SBOM) 」では、SBOMをソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録、と定義しており、OSS脆弱性管理の前提として極めて重要です。SCAやSBOM対応ツールを使うことで、どのアプリケーションにどの部品が含まれているかを把握しやすくなります。

    脆弱性スキャナーの比較

    脆弱性スキャナーを比較するとき、まず見るべきなのはCVE対応の範囲です。脆弱性スキャンの基本は、既知の脆弱性データと自社環境を突き合わせることにあるため、どの程度広くCVE情報やベンダー情報に対応しているかは重要です。とはいえ、単に「CVEに対応している」と書かれているだけでは不十分で、更新頻度、対応製品の広さ、クラウドやコンテナへの追従性まで見たほうが実務では役立ちます。CISAが示す脆弱性管理の考え方*3でも、継続的に変化する資産や脅威を前提にした運用が重視されています。

    次に確認したいのがスキャン精度です。脆弱性スキャナーは便利ですが、誤検知が多すぎると運用部門が疲弊し、逆に本当に重要な項目を見逃しやすくなります。逆に、検知が甘ければ見つかるべき脆弱性を取り逃がすことになります。ツールの比較では、単なる検知件数ではなく、結果がどれだけ実務で使いやすいか、重複排除や重要度の絞り込みがしやすいかも見ておく必要があります。OWASPが指摘するようにスキャン結果だけでは実際の攻撃可能性を完全に評価できない*4ため結果の解釈しやすさも重要です。

    さらに、OSSライブラリ検出やSBOM生成の可否は、近年ますます重要になっています。SCAに対応していないツールでは、アプリケーション内部の依存関係まで把握できず、ソフトウェアサプライチェーンリスクへの対応が難しくなります。SBOMを生成・管理できるかどうかは、脆弱性スキャンの範囲をインフラからソフトウェア部品まで広げられるかどうかに直結します。NTIAはSBOMが脆弱性管理、ソフトウェア在庫管理、ライセンス管理などの基本ユースケースに役立つとしています。

    脆弱性スキャン導入のポイント

    脆弱性スキャンを導入する際に考えるべきポイントは以下のとおりです。

    導入目的の明確化

    公開Webサイトの安全性を高めたいのか、社内サーバーの更新漏れを防ぎたいのか、クラウド設定不備を見つけたいのか、OSS脆弱性を把握したいのかで、適したツールは変わります。目的が曖昧なまま「有名だから」という理由だけで導入すると、期待した検知ができなかったり、運用負荷だけが増えたりします。

    導入後の運用体制の整備

    脆弱性スキャンは、導入しただけでは意味がなく、誰が結果を確認し、どこまで精査し、どの基準で是正依頼を出し、修正後にどう再確認するかまで決めておく必要があります。NISTのパッチ・脆弱性管理ガイドでも、技術そのものより、継続運用のプロセス設計が重要であることが示されています。ツール導入はゴールではなく、脆弱性管理のサイクルを回すための手段です。

    資産管理との連携

    スキャン結果を脆弱性対応に直結させるためには、資産管理との連携も欠かせません。どのサーバーがどの業務に使われているのか、どのシステムが外部公開されているのか、どのアプリケーションがどのOSS部品を利用しているのかが分からなければ、検出された脆弱性の優先順位を決められません。特にクラウドやコンテナ環境では、資産の増減が激しいため、台帳やCMDB、クラウド資産可視化と組み合わせた運用が重要です。

    脆弱性診断・ペネトレーションテストとの併用

    脆弱性スキャンは広く速く確認するのに強い一方で、業務ロジックや複雑な攻撃経路までは十分に評価できないことがあります。公開サービスや重要システムでは、重点的な診断を組み合わせるほうが現実的です。OWASPも、ペネトレーションテストがスキャンだけでは見えない実攻撃視点の評価に役立つと説明しています。

    脆弱性スキャンで脆弱性を発見した後は、迅速に対応を行うことが重要です。適切な優先順位付けやパッチ適用を行わなければ、攻撃リスクを低減することはできません。脆弱性対応の具体的な手順については、以下の記事で詳しく解説しています。
    「脆弱性対応とは？CVE対応とパッチ管理の実務フロー」

    脆弱性管理との関係

    脆弱性スキャンは、脆弱性管理そのものではありませんが、脆弱性管理を支える重要な要素です。脆弱性管理は、資産把握、脆弱性情報収集、評価、是正、再確認を継続的に回す運用全体を指します。その中で脆弱性スキャンは、「発見」と「継続的な監視」を支える手段として機能します。CISAが脆弱性管理を、脆弱性や悪用可能な状態の頻度と影響を減らす取り組みとして整理している*5ことからも、スキャン単独ではなく運用全体の中で捉えるべきことが分かります。

    脆弱性スキャンは、脆弱性管理の一部として実施される重要なプロセスです。しかし、スキャンを実施するだけでは不十分であり、発見した脆弱性を評価・対応まで含めて継続的に管理する必要があります。企業の脆弱性管理全体の流れについては、以下の記事で詳しく解説しています。
    「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」

    実務では、脆弱性スキャンで見つけた結果をそのまま並べるだけでは意味がありません。資産の重要度、公開状態、CVSS、既知悪用の有無、業務影響などを踏まえて優先順位を決め、必要な修正や診断につなげていく必要があります。さらに、OSS脆弱性についてはSCAやSBOMを組み合わせて調査範囲を広げることが重要です。つまり脆弱性スキャンは、脆弱性管理の入口であり、全体運用へつなぐための観測手段だといえます。

    まとめ

    脆弱性スキャンとは、既知の脆弱性や設定不備を自動的に洗い出し、企業の攻撃面を継続的に可視化するための基本手段です。ネットワークスキャン、Webスキャン、クラウド環境スキャン、OSS脆弱性スキャンといった種類があり、企業のシステム構成に応じて適切に選ぶ必要があります。ただし、脆弱性スキャンは万能ではなく、脆弱性診断やペネトレーションテストのような深い評価とは役割が異なります。広く見つけるのがスキャン、深く確かめるのが診断、と整理すると理解しやすいです。

    導入時に重要なのは、ツールの知名度ではなく、自社の目的に合っているかどうかです。CVE対応の広さ、スキャン精度、クラウド対応、OSSライブラリ検出、SBOM生成の可否などを見極めたうえで、導入後に誰がどのように結果を処理するかまで設計しておく必要があります。脆弱性スキャンを単独の製品選定で終わらせず、脆弱性管理の継続運用へつなげることが、企業にとって本当の導入効果につながります。

    【参考情報】

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

    その他のウェビナー開催情報はこちら

    BBSecでは

    BBSecでは以下のようなご支援が可能です。 お客様のご状況に合わせて最適なご提案をいたします。

    自ステムの状態を知る

    SQAT®脆弱性診断サービス

    サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

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

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

    編集責任：木下

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

    資料ダウンロードボタン

    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

    お問い合わせボタン

    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBSecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像