タグ: 脆弱性

投稿日:

デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策

Share
デジタル庁GSSに不正アクセス ―約24.6万件の情報漏洩の可能性と企業の対策アイキャッチ画像

デジタル庁は2026年9月11日、ガバメントソリューションサービス（GSS）への不正アクセスにより、職員や業務関係者の個人情報約24.6万件が漏洩した可能性があると公表しました*1。今回の事案では、VPN機器の既知の脆弱性が悪用され、保守運用担当者のアカウントを利用した大量のファイルアクセスが検知されています。本記事では、公表情報をもとに事案の経緯と影響を整理するとともに、企業が脆弱性管理やセキュリティログ監視で見直したいポイントについて解説します。

GSS不正アクセスの検知から公表までの経緯

GSSは、デジタル庁が運用し、各府省庁などが業務に利用するサービスです。今回の調査は、6月25日に保守運用担当者のアカウントによるサーバー上の大量ファイルアクセスを検知したことから始まりました。VPN機器の脆弱性を使って第三者が侵入していたと判明したのは7月9日です。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断したと説明されています。6月25日は検知日であり、侵入開始日を示すものではありません。7月15日に個人情報保護委員会へ報告し、対象者や情報の内容の調査を進めたうえで9月11日に公表しました。

公式Q&Aによると、影響範囲や侵入経路、漏えいした可能性のある情報の特定に時間を要したとしています。公表時点では、修正プログラムの適用や関係アカウントの認証情報変更、通信遮断などの措置を実施済みで、その後、新たな不正アクセスや不審な通信は確認されておらず、政府業務への支障も生じていないと説明しています。*2。

図1：GSS不正アクセスの検知から公表まで

出典：デジタル庁「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」（https://www.digital.go.jp/news/2026-0911-01）および「ガバメントソリューションサービスへの不正アクセスによる職員等の個人情報の漏えいの可能性について」に関するQ&A」（https://www.digital.go.jp/press/5fc99139-a4e2-4b7b-8b0c-d475e926143f）を基に作成

約24.6万件の個人情報が漏洩した可能性

約24.6万件の内訳は、GSS利用機関の職員や業務に携わった公務員等の情報が約18.9万件、業務に携わった事業者や個人の情報が約5.7万件です。漏洩した可能性のある個人情報には、氏名、メールアドレス、電話番号、住所などが含まれます。属性別では、氏名が約23.6万件、メールアドレスが約23.1万件、電話番号が約9.4万件、住所が約0.1万件とされています。これらの属性には重複があるため、単純に合計することはできません。

デジタル庁は、一般の国民の個人情報や、マイナンバー、金融機関口座情報、年金番号は含まれないと説明しています。ただし、公務員以外でも、関係省庁の業務に携わった企業の従業員や個人事業主などは対象に含まれます。また、約24.6万件すべてについて、外部への持ち出しが確認されたわけではありません。不正アクセスの痕跡があり、漏えいの可能性を否定できない情報も対象にした数字です。9月14日時点で確認した公表資料では、関連する二次被害は確認されていません。

深刻度「中」でも悪用

今回の脆弱性は、攻撃が確認される前に公表されていた既知の問題でした。デジタル庁は、当初の深刻度評価に応じた一般的対応より早く対処を進めたものの、修正プログラムの適用前に悪用されたと説明しています。この情報だけで、脆弱性を把握していなかった、あるいは放置していたとは判断できません。VPN製品名やCVE番号なども公表されていません。企業で見直したいのは、脆弱性の深刻度と、自社での対応優先度をつなぐ判断です。

CVSSを管理するFIRSTは、CVSSの基本評価値は脆弱性そのものの深刻度を表し、単独でリスク評価に使うべきではないと説明しています*3。利用環境や脅威の状況を加えて評価する考え方が、公式ガイドに示されています。

これを自社の運用に落とし込むなら、スコアの横に「どこから接続できる機器か」「侵害された場合に何へアクセスできるか」「業務や情報にどのような影響があるか」を記録する方法が考えられます。同じ深刻度でも、外部から接続できるVPNと、接続元を限定した機器では、確認すべき条件が異なります。これは今回のGSSの詳細構成を推定する話ではなく、自社で優先順位を判断するための実務上の整理です。パッチ適用に調整が必要な場合は、ベンダーが示す回避策や接続制限の適用可否も併せて検討します。その際、「次回メンテナンスで更新する」という予定だけで終わらせず、更新までに残るリスクと担当者、再判断の条件を記録しておくと、悪用情報が追加された際の見直しにつなげやすくなります。

図2：脆弱性対応の優先順位を考える視点

出典：FIRST「CVSS v4.0 User Guide」、デジタル庁「本事案に関するQ&A」をもとに弊社作成
※GSSの実際の運用・判断手順を示すものではありません。

保守アカウントを信頼しきらず、操作の実態を確かめる

もう一つの論点が、保守運用担当者のアカウントを通じたアクセスです。今回の公表資料では、アカウントをどのように悪用できる状態にしたのか、認証情報をどう取得したのかまでは明らかにされていません。パスワードの使い回しや多要素認証の未導入が原因だった、と断定することはできません。

企業側で検討したいのは、認証の成否に加え、アクセス後の行動を確認できる状態です。例えば、保守作業の予定と実際のアクセス時刻を照合し、対象サーバー、操作内容、ファイルへのアクセス量が作業目的と整合するかを確認する、といった運用が考えられます。大量アクセス自体には正当な作業もあるため、件数だけで不正と決めつけず、普段の利用や作業申請と照らし合わせることが大切です。その判断を支えるのが、VPNの接続記録、認証ログ、サーバーの監査ログなどです。NISTのログ管理ガイドでは、ログ管理の基盤整備や、組織全体で継続的にログを管理するプロセスの構築について示しています*4。

企業では、必要なログを取得・保存するだけでなく、複数のログを時系列で確認できる状態を整え、異常を検知した際の対応や役割分担まで含めて運用を設計することが重要です。

ゼロトラストも、日々の脆弱性管理と監視が土台になる

GSSはゼロトラストアーキテクチャを採用していたと説明されています。ただし、具体的な構成や対策は非公表です。今回の事案だけから、ゼロトラスト全体の有効性や、特定の対策が機能しなかった理由を評価することはできません。NISTはゼロトラストを、ネットワーク上の場所や資産の所有者だけで、利用者や機器を暗黙に信頼しない考え方として整理しています*5。

企業が確認すべきなのは、自社でどのアクセスを検証し、どこまでを許可し、どの記録から異常を判断できるかです。VPNの更新、アクセス権限の確認、ログ分析を、導入した製品や構成に合わせて継続する必要があります。

BBSecのログ分析・活用支援で、確認できる範囲を広げる

「ログは保存しているが、保守アカウントの不正利用をどう見つけるか決まっていない」。そうした課題には、取得対象と分析目的の整理から取り組む方法があります。BBSecの「セキュリティログ分析／活用支援」は、蓄積したログの分析から、ログ取得環境の整備に向けたコンサルティング、Splunkを用いた統合ログ管理・分析環境の構築、運用までを支援するサービスです。現状の管理ポリシー、取得状況、体制、運用プロセスを確認し、改善プランを検討しましょう。自社のVPNや認証基盤、サーバーについて、取得するログと検知したい事象を具体化すれば、追加すべき記録や運用上の課題を検討できます。既存ログの活用や分析環境の見直しを進めたい企業は、BBSecにご相談ください。

【参考情報】

編集責任：木下

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

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

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

最新情報はこちら

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【参考情報】

編集責任：木下

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

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

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

最新情報はこちら

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

投稿日:

2026年上半期のサイバー脅威情勢 ―ランサムウェア被害は半期最多123件に

Share
2026年上半期のサイバー脅威情勢アイキャッチ画像

警察庁が2026年9月10日に公表した「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」によると、ランサムウェアの被害報告は123件となり、2020年下半期の統計開始以降、半期として最多となりました。注目したいのは、被害件数だけでなく、侵入経路や被害後の復旧の実態です。本記事では、警察庁の公表資料をもとに、企業が押さえておきたいポイントと必要な対策を解説します。

ランサムウェア被害は半期最多123件

2026年上半期のランサムウェア被害報告件数は、前年同期の116件から7件増えました。増加率は約6.0％です。被害を受けた企業・団体等のうち、中小企業79件、大企業31件、団体等13件でした。中小企業が全体の約64％を占め、業種別では製造業が37件と最も多くなっています。*3[統計編141・142頁]

ランサムウェア被害報告件数の半期推移

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08_kami_cyber_jousei.pdf）統計データをもとに弊社作成

※本統計データは警察庁に報告された企業・団体等の被害件数であり、国内で発生したすべての被害を示すものではありません。

また、暗号化せずに盗んだ情報の公開をほのめかして金銭を要求する「ノーウェアランサム」は、別に9件報告されています。ランサムウェア被害を考える際には、データの暗号化だけでなく、情報窃取を伴う脅威にも注意が必要です。それでも、中小企業にも被害が広く及んでいる事実は、自社の規模を理由に対策を後回しにできないことを示しています。限られた人数で対策を進める企業ほど、インターネットに公開している機器と、停止した場合に仕事が進まなくなるシステムを具体的に洗い出すところから始めるのがよいでしょう。

感染経路はVPN機器が最多

警察庁の被害組織へのアンケートでは、感染経路の有効回答36件のうち、VPN機器が18件、リモートデスクトップが9件、その他が9件でした。VPN機器とリモートデスクトップで75％を占めました。ただし、感染経路について回答が得られた36件を対象とした結果です。*2[統計編143頁]

また、同報告書では、攻撃者が未修正の脆弱性や漏えいした認証情報などを悪用してネットワークへ侵入する手口が示されています*3[本文10頁]。そのため、「VPN機器からの侵入＝製品の脆弱性が原因」とは限りません。VPN機器などのソフトウェアの更新状況だけでなく、アカウントや認証の管理も併せて確認することが重要です。

こうした侵入への対策として、警察庁の「ランサムウェア被害防止対策」では、VPN機器等への更新ファイルの適用、認証情報の適切な管理、多要素認証やアクセス制限などを挙げています。これを日々の運用に落とし込むには、装置の製品名とバージョン、保守期限、更新の担当者を把握し、不要な公開設定や使われていないアカウントを見直すところから始めます。委託先が運用している場合も、更新を依頼するだけで終えず、適用結果を確認する役割を決めておきましょう。

公開機器の管理が重要となる背景には、脆弱な機器などを探す活動が継続的に観測されていることもあります。警察庁のセンサーが検知した脆弱性探索行為等の不審なアクセスは、1日・1IPアドレス当たり1万3,687件でした*4[本文5頁]。ただし、これは警察庁の観測環境における値であり、一般企業が毎日同じ件数の攻撃を受けていることを意味するものではありません。外部から接続可能な機器やサービスを継続的に把握し、不要な公開がないか定期的に確認することが重要です。

調査・復旧費用は1,000万円以上が6割

ランサムウェア被害に伴う調査・復旧費用の総額について、有効回答35件のうち21件が1,000万円以上でした。このうち4件は1億円以上です。身代金の要求額を示す統計ではなく、被害後の調査と復旧に要した費用である点を押さえておく必要があります。また、復旧等に要した期間は、有効回答48件のうち、1か月未満が23件、回答時点で復旧中が13件でした*5[統計編144・145・146頁]。

「復旧中」には終了時期が確定していない回答が含まれるため、残りを一括して「1か月以上停止した」と読むことはできません。また、システムの復旧期間と、全社の業務停止期間も同じではありません。

被害後の負担とバックアップ復元の実態

調査・復旧費用が1,000万円以上

60.0％

21件 ／ 有効回答35件

バックアップから復元できなかった

72.5％

29件 ／ 有効回答40件

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」をもとに弊社作成。割合は警察庁公表の件数をもとに弊社算出。
※項目ごとに有効回答数が異なるため、2つの割合を直接比較するものではありません。また、一般企業における被害率やバックアップの失敗率を示すものではありません。

被害後の調査や復旧には大きな費用が発生する場合があります。被害が発生してから対応を検討するのではなく、平時から復旧の優先順位や必要な対応を整理しておくことが重要です。

万一の費用負担に備えるサイバー保険

サイバー攻撃への備えでは、被害を防ぐための対策に加えて、万一インシデントが発生した場合の費用負担についても考えておくことが重要です。BBSecでは、SQAT® 脆弱性診断サービスにサイバー保険を付帯しています。情報漏えいやサイバー攻撃に起因する賠償損害や、事故発生時の対応にかかる費用損害などを補償し、平時のセキュリティ対策と万一への備えを支援します。

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

【関連記事】

バックアップは復元できる状態まで確かめる

バックアップからの復元結果に関する有効回答40件では、復元できたのは11件、できなかったのは29件でした*6[統計編148頁]。

バックアップを取得していても、被害発生時に必ず復元できるとは限りません。重要なのは、バックアップの有無だけでなく、保存先が攻撃の影響を受けにくい状態になっているか、実際にデータを復元できるか、復元後にシステムや業務を再開できるかまで確認しておくことです。警察庁もランサムウェア被害防止策として、バックアップをネットワークから切り離して保管することなどを呼びかけています*7。日常のバックアップ結果に加えて、復元の手順と所要時間を確認し、事業継続計画に反映させることが重要です。

さらに、暗号化されたデータを復元できても、盗まれた情報への対応は残ります。報告書によると、手口が判明した66件のうち61件は二重恐喝でした*8[本文98頁・統計編140頁]。二重恐喝とは、データの暗号化に加え、窃取した情報の公開を材料に金銭等を要求する手口です。バックアップの整備と並行して、持ち出された情報の範囲を調べ、関係者への説明に必要な事実を整理できるよう備える必要があります。

フィッシング報告は約73万件

フィッシング対策協議会の集計によると、2026年上半期のフィッシング報告件数は約73万件でした*9。なお、この数字は同協議会に寄せられた報告件数であり、被害者数や不正送金の件数を示すものではありません。前年同期を下回っているものの、引き続き多くのフィッシングが報告されており、継続した対策が必要です。

警察庁の報告書では、AI技術の発達により、文章や偽装が自然で見抜きにくいフィッシングへの注意を促しています*10[本文17頁]。そのため、「日本語が不自然なら疑う」といった見分け方だけに頼るのではなく、メールやSMSで手続きを求められた場合は、本文中のリンクからアクセスせず、公式サイトや公式アプリなど、確認済みの経路からアクセスすることが重要です。

企業側でも、従業員への注意喚起だけでなく、多要素認証の導入や不審なログインの監視など、認証情報が窃取された場合も想定した対策が求められます。フィッシング対策とランサムウェア対策は別の入口を持つことがありますが、認証情報の管理と異常の早期把握は、双方に関わる備えです。

ランサムウェア対策を事業継続につなげる

警察庁の報告書では、ネットワークへの侵入後に権限奪取や内部探索、情報窃取が行われ、暗号化に至る攻撃の流れが示されています*11[本文10頁]。こうした攻撃の流れを企業の対策に置き換えると、公開機器の管理から侵入後の監視、復旧の準備までを一続きで考えることが重要です。VPN機器などの更新や認証強化を進めるだけでなく、不審なログインや権限の悪用を把握し、速やかに封じ込めへ移れる体制を整えておく必要があります。

事業継続の準備では、どの業務を優先して再開するか、誰がシステムの切り離しや再接続を判断するか、社内システムが使えないときにどう連絡するかを具体化します。調査や封じ込めと調整しながら復旧を進める必要があるため、自然災害を想定した計画だけでは対応しきれない場面があります。

侵入への備えと事業継続をつなぐ対策

出典：警察庁「令和8年上半期におけるサイバー空間をめぐる脅威の情勢等について」（https://www.npa.go.jp/publications/statistics/cybersecurity/data/R8kami/R08_kami_cyber_jousei.pdf）および「ランサムウェア被害防止対策」をもとに弊社作成

IT-BCPで復旧の優先順位を明確にする

ランサムウェア被害からの復旧では、システムを元に戻すだけでなく、どの業務を優先して再開するか、そのためにどのシステムから復旧するかをあらかじめ整理しておくことが重要です。また、調査や封じ込めの状況を踏まえながら復旧を進める必要があるため、復旧時の判断基準や役割分担も明確にしておく必要があります。

IT-BCPは、ITシステムが利用できなくなった場合の事業継続と復旧に備える計画です。BBSecでは、「ランサムウェアに対応したIT-BCP策定支援」を提供しています。現状の対策状況を確認し、復旧優先度や目標とする対策レベルを設定したうえで、システム・ネットワークの要件、運用要件、改善計画の具体化を支援します。「バックアップはあるものの、どのシステムから復旧するか決まっていない」「インシデント発生時の復旧判断や役割分担が明確になっていない」といった課題がある場合には、業務とシステムの関係を整理し、ランサムウェア被害を想定した復旧計画を検討しておくことが重要です。

[ランサムウェアに対応したIT-BCP策定支援の詳細・相談はこちら]

また、インシデント発生時の初動手順や体制を整備したい場合には「インシデント初動対応準備支援」、セキュリティ対策のログ監視・分析などの運用体制を強化したい場合には「G-MDR®」など、平時からの備えを組み合わせることも有効です。

【参考情報】

編集責任：木下

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

ランサムウェア対策やインシデント対応、事業継続に向けた備えなど、自社のセキュリティ対策についてお悩みの場合は、ブロードバンドセキュリティ（BBSec）までお気軽にご相談ください。

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

最新情報はこちら

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

投稿日:

SonicWall SMA1000の脆弱性が攻撃に悪用 ―CVE-2026-83548・CVE-2026-83549の影響と対策

Share
SonicWall SMA1000の脆弱性とは？CVE-2026-83548・83549の影響と対策アイキャッチ画像

2026年9月、SonicWallはリモートアクセス製品「SMA 1000シリーズ」に影響する複数の脆弱性を公表しました。これらの脆弱性は実際の攻撃での悪用が確認されており、米国CISAが公開する「Known Exploited Vulnerabilities（KEV）カタログ」にも追加されています。SMA 1000シリーズを利用している組織では、対象バージョンを確認し、速やかに対策を行う必要があります。本記事では、今回公表された脆弱性の概要や影響を受ける製品・バージョン、企業が実施すべき対応について解説します。

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

SonicWall SMA1000とは

SonicWall Secure Mobile Access（SMA）1000シリーズは、社外の利用者から社内やクラウド上の業務システムへのアクセスを提供するセキュアリモートアクセス製品です。SMA 6210、SMA 7210の物理アプライアンスに加え、仮想アプライアンスのSMA 8200vが提供されています。リモートアクセス装置は、外部から内部資源へ接続するための入口という性質を持ちます。そのため、脆弱性が悪用された場合、単体の機器障害にとどまらず、認証情報や内部システムへのアクセスを含めた侵害可能性の調査が必要になります。今回、SonicWallがアップデートだけでなく侵害指標（IoC）の確認も求めているのは、このような製品の役割を踏まえた対応といえます。

CVE-2026-83548・CVE-2026-83549の概要

SonicWallが公表したのは、Appliance Work Placeインターフェースに存在する認証前のSSRFと、Appliance Management Console（AMC）に存在する認証後のOSコマンドインジェクションです。いずれも実際の攻撃での悪用が確認されていますが、攻撃者、被害組織、侵害台数、攻撃目的などの詳細は公表されていません。

CVE-2026-83548：認証前に悪用可能なSSRF（CVSS 10.0）

CVE-2026-83548は、SMA1000のAppliance Work Placeインターフェースに存在するサーバーサイドリクエストフォージェリ（SSRF）の脆弱性です。意図しない代替アクセス経路が生じることが原因とされ、リモートの未認証攻撃者が機密性の高い機能へ不正にアクセスし、許可されていない操作を行える可能性があります。深刻度はCVSS 10.0の「Critical」です。

SSRFとは、攻撃者が対象サーバーを代理にして、本来は外部から直接アクセスできない宛先へリクエストを送らせる攻撃です。公開インターフェースと内部の管理機能との境界を越える足掛かりになり得るため、認証前に悪用できる今回の脆弱性は特に優先度が高いと判断できます。

CVE-2026-83549：管理コンソールのOSコマンドインジェクション（CVSS 7.8）

CVE-2026-83549は、SMA1000のAppliance Management Console（AMC）に存在するOSコマンドインジェクションの脆弱性です。SonicWallによると、特定の条件下で、管理者として認証された攻撃者が任意のOSコマンドを実行し、リモートコード実行につながる可能性があります。深刻度はCVSS 7.8の「High」です。

2件はいずれも同じSMA1000に存在する脆弱性であることから、組み合わせて悪用される可能性にも注意が必要です。ただし、SonicWallの公開情報では、2件が実際に一つの攻撃チェーンとして利用されたことや、CVE-2026-83548を起点として認証なしでリモートコード実行に至ることまでは明らかにされていません。

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

影響を受けるのはSMA 1000シリーズのSMA 6210、SMA 7210、SMA 8200vです。物理アプライアンスと仮想アプライアンスの双方が対象になります。SonicWall製ファイアウォール全般やSMA 100シリーズまで対象が広がるとの発表ではありません。自社の製品名だけでなく、platform-hotfixを含む完全なバージョン番号を確認してください。

対象製品影響を受けるバージョン修正版
SMA 6210／7210／8200v12.4.3-0345312.4.3-03526以上
SMA 6210／7210／8200v12.5.0-0283512.5.0-02952以上
出典：SonicWall「Product Notice: SMA 1000 Series affected by Multiple Vulnerabilities（SNWLID-2026-0016）」（https://www.sonicwall.com/support/notices/product-notice-sma-1000-series-affected-by-multiple-vulnerabilities-snwlid-2026-0016/kA1VN000002AXmQ0AW）を元に弊社作成

CVE情報では、12.4.3-03453および12.5.0-02835と、それ以前のバージョンが影響対象とされています。修正版は12.4系が12.4.3-03526、12.5系が12.5.0-02952です。SonicWallはMySonicWallから入手できる最新hotfixへのアップグレードを求めています。

CISAも既知の悪用された脆弱性カタログへ追加

2026年9月2日、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）は、CVE-2026-83548とCVE-2026-83549をKnown Exploited Vulnerabilities Catalog（KEVカタログ）へ追加しました。KEVへの掲載は、単に深刻度が高いというだけでなく、現実の攻撃で悪用された根拠があることを示します。 CISAは米国の連邦文民行政機関に対し、両脆弱性の対応期限を9月5日に設定しました。この期限が日本企業に直接適用されるわけではありませんが、公開からわずか数日という短い期限は、CISAが迅速な対応を必要と判断したことを表しています。SMA1000を利用する日本企業も、通常の定例アップデートを待つのではなく、緊急対応として扱うべき状況です。また、CISAのKEV情報ではフォレンジックトリアージも求められており、単なる修正プログラムの適用だけでなく、侵害の有無を確認することが重視されています。

なぜ『パッチを当てて終了』では不十分なのか

今回の脆弱性は、公表時点ですでに攻撃での悪用が確認されています。修正版へ更新すれば、その後に同じ脆弱性を利用されるリスクは抑えられますが、更新前に侵害されていなかったことまでは証明できません。攻撃者がすでに設定を変更したり、認証情報を取得したり、別の侵入経路を残したりしていれば、脆弱性を修正した後も影響が続く可能性があります。これは今回の被害状況を示すものではなく、侵害済み機器に対する一般的なリスクです。

SonicWallは、対象バージョンを利用するすべての組織に対し、最新hotfixへの更新に加えて、SonicWall Technical Supportへ連絡し、侵害指標を確認するよう案内しています。今回の公開アドバイザリには具体的なIPアドレス、ファイルハッシュ、URLパスなどのIoC一覧は掲載されていません。2026年7月に公表された別の脆弱性用IoCを、今回の調査へそのまま流用するべきではありません。

SMA1000利用組織が直ちに実施すべき対応

対象機器とhotfixレベルを確認する

まず、SMA 6210、7210、8200vの導入有無と、各機器の完全なバージョン番号を確認します。台帳だけに頼らず、運用委託先、クラウド環境、検証環境、待機系を含めて実機の状態と照合することが重要です。仮想アプライアンスも対象であるため、物理機器だけを確認して終えてはいけません。

最新hotfixへ更新する

12.4系は12.4.3-03526、12.5系は12.5.0-02952以上へ更新します。SonicWallは別の公式回避策を示していないため、アクセス制限などの補完策だけで更新を先送りすることは適切ではありません。業務影響を確認しながらも、悪用確認済みの脆弱性として優先的にメンテナンス時間を確保する必要があります。

侵害指標を確認し、影響範囲を調査する

更新と並行して、SonicWall Technical Supportの支援を受け、対象機器に侵害の痕跡がないかを確認します。必要に応じてログや設定を保全し、異常な管理操作、設定変更、認証の試行、外部との通信などについて確認します。ログが不足している場合は、周辺のファイアウォール、認証基盤、SIEMなどに残る記録も組み合わせて判断します。

IoCが確認された場合は機器と認証情報を再構成する

SonicWallはIoCが確認された場合、ハードウェアアプライアンスを再イメージ化し、仮想アプライアンスを再デプロイするよう求めています。加えて、すべての利用者および管理者パスワードを変更し、TOTPトークンをリセットする必要があります。TOTPリセットの推奨は、今回TOTPシードの窃取が確認されたことを意味するものではなく、侵害後に信頼できる認証状態を再構築するための措置と捉えるべきです。

7月の脆弱性対応後も、再度hotfixの確認が必要

SMA1000では2026年7月にも、SSRFのCVE-2026-15409と、リモートコード実行につながるCVE-2026-15410が公表され、実際の攻撃での悪用が確認されました。このときの修正版は12.4.3-03453および12.5.0-02835以上でした。今回の新たな脆弱性では、そのバージョンも影響対象となり、さらに新しい12.4.3-03526、12.5.0-02952への更新が必要です。

つまり、7月に緊急対応を完了した組織であっても、9月時点で再確認が欠かせません。製品名やメジャーバージョンだけで資産を管理するのではなく、hotfixレベルと適用日、脆弱性ごとの対応状況まで追跡できる運用が必要です。相次ぐ公表は、境界機器の脆弱性管理を年に数回の棚卸しで済ませることが難しい現実を示しています。

境界機器の脆弱性悪用に備える4つのポイント

外部公開資産を攻撃者と同じ視点で把握する

リモートアクセス装置、VPN、ファイアウォールなどの境界機器は、インターネットから到達できるため攻撃者に探索されやすい資産です。管理台帳と実際の公開状況が一致しているかを継続的に確認し、不要な機器や管理画面を公開しないことが基本になります。

悪用状況を加味して脆弱性対応の優先順位を決める

CVSSは重要な判断材料ですが、点数だけで対応順を決めると、現実の攻撃状況を見落とします。今回のCVE-2026-83549はCVSS 7.8である一方、悪用が確認され、CISA KEVにも掲載されています。製品の公開範囲、内部ネットワークへの接続性、KEV掲載、ベンダーの注意喚起を組み合わせ、緊急対応へ切り替える基準を定めておく必要があります。

ログを一元化し、調査できる期間を確保する

インシデント発生後に調査しようとしても、機器のログが短期間で上書きされていれば侵害の有無を判断できません。境界機器、認証基盤、ネットワーク、エンドポイントのログを一元的に保管し、時刻同期、保存期間、改ざん防止、監視ルールを平時から整えておくことが重要です。

再構築と認証情報のリセットを含む対応手順を用意する

境界機器が侵害された場合は、サービス停止や再構築が必要になることがあります。機器の再イメージ化、設定の安全性確認、パスワード変更、MFAトークンの再登録、代替のリモートアクセス手段まで含めた手順を準備し、事業継続部門と合意しておく必要があります。

BBSecが支援する外部公開資産の把握・監視・緊急対応

悪用確認済みの脆弱性へ迅速に対応するには、対象機器を把握する仕組み、脆弱性情報を運用へ反映する体制、侵害を検知・調査できるログ、緊急時に専門家へつなぐ手順を一つの流れとして整えることが重要です。BBSecでは、攻撃者の視点からインターネット上のIT資産を可視化する「アタックサーフェス調査」、脆弱性情報を迅速に提供する「脆弱性情報提供」、各種ログの分析・活用を支援するサービス、インシデント発生時の「緊急対応支援」などを提供しています。SonicWall SMA1000に限らず、VPNやリモートアクセス装置を含む境界機器の管理に不安がある場合は、外部公開資産の把握から監視、初動対応までを分断せずに見直すことが有効です。

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

SonicWall SMA1000の脆弱性に関するFAQ

▼ SonicWall SMA1000のどの製品が影響を受けますか？
▼ CVE-2026-83548とCVE-2026-83549は実際に悪用されていますか？
▼ hotfixを適用すれば対応は完了しますか？
▼ 今回の脆弱性はゼロデイですか？

まとめ

SonicWall SMA1000のCVE-2026-83548とCVE-2026-83549は、実際の攻撃で悪用が確認され、CISA KEVにも追加された脆弱性です。SMA 6210、7210、8200vを利用する組織は、12.4.3-03526または12.5.0-02952以上への更新を急ぐ必要があります。対応の要点は、パッチを適用するだけで終わらせないことです。対象資産の特定、侵害指標の確認、必要に応じた再イメージ化または再デプロイ、パスワードとTOTPトークンのリセットまでを一連のインシデント対応として実施してください。境界機器は社内システムへ通じる入口です。脆弱性が公表されてから探し始めるのではなく、平時から資産、バージョン、ログ、対応責任者を把握しておくことが、ゼロデイ攻撃への備えになります。

【参考情報】

編集責任：木下

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

最新情報はこちら

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

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

投稿日:

AIセキュリティとは？生成AI時代に企業が知っておくべきリスクと対策

Share
AIセキュリティとは？生成AI時代に企業が知っておくべきリスクと対アイキャッチ画像策

生成AIの業務利用が広がる一方、情報漏洩や誤情報、著作権、AIシステムを狙った攻撃など、新たなリスクも生じています。本記事では、企業がAIを安全に活用するために押さえておきたい、AIセキュリティの主なリスクと対策を紹介します。

AIセキュリティについて、テーマ別に詳しく知りたい方はこちらもご覧ください。

AIセキュリティとは

AIセキュリティとは、AIの利用やAIを組み込んだシステムに伴うセキュリティ上のリスクを把握し、情報やシステム、業務を守るための取り組みです。企業におけるAI活用を考える際には、大きく二つの観点があります。

一つは、AIを利用することで生じるリスクです。従業員が生成AIに機密情報や個人情報を入力することによる情報漏洩、生成された誤情報の利用、著作権や知的財産に関する問題、企業が把握していないAIサービスを業務に利用する「シャドーAI」などが挙げられます。

もう一つは、AIシステムそのものに対するセキュリティリスクです。AIやLLM（大規模言語モデル）を組み込んだシステムでは、悪意のある指示によって意図しない動作を引き起こすプロンプトインジェクションをはじめ、機密情報の漏洩や不適切な権限の利用など、AI特有のリスクを考慮する必要があります。

生成AIやAIエージェントの普及により、AIは単に質問に回答するツールから、社内データを参照したり、外部のシステムやサービスと連携して処理を行ったりする存在へと用途を広げています。そのためAIセキュリティでは、従業員の利用ルールだけでなく、AIに接続するデータやシステム、付与する権限まで含めてリスクを捉えることが重要になります。

AIセキュリティが注目される背景

生成AIは、文章作成や要約、翻訳、情報収集、プログラミングなど幅広い業務で活用されています。また、既存の業務システムやWebサービスに生成AIを組み込むケースも増え、企業とAIとの接点は広がっています。

こうした活用の拡大に伴い、セキュリティ上の課題も顕在化しています。従業員が組織の許可を得ずに生成AIを利用するシャドーAIによる情報漏洩や、不正確な出力による業務への影響などは、その代表例です。

さらに、AIシステム自体が攻撃対象になることも考慮しなければなりません。従来のWebアプリケーションやクラウドサービスへのセキュリティ対策に加えて、AI・LLMの特性を悪用した攻撃への備えも必要になっています。

AIをめぐっては、国内外で安全性や透明性、適正な利用に関するルールやガイドラインの整備も進められています。企業には、技術的なセキュリティ対策だけでなく、こうした動向を踏まえてAIの利用方針や管理体制を継続的に見直すことも求められます。

従来のセキュリティ対策との違い

AIを利用する場合でも、アクセス制御や認証、脆弱性管理、ログ監視といった従来のセキュリティ対策が不要になるわけではありません。これらは引き続き重要な基盤となります。そのうえでAIセキュリティでは、AIへの入力、AIからの出力、AIが参照するデータ、AIに与える権限といった新たな要素についても対策を考える必要があります。

例えば、システムへのアクセス権限が適切に管理されていても、従業員が外部の生成AIサービスへ機密情報を入力すれば、別の経路から情報が外部へ渡る可能性があります。また、AIを組み込んだシステムでは、通常の操作では想定していなかった指示によってAIの動作が誘導される可能性もあります。

したがって、AIセキュリティでは従来のサイバーセキュリティを土台としながら、「AIをどのように利用するか」と「AIを組み込んだシステムをどのように守るか」の両面から対策を考えることがポイントとなります。

企業が注意すべき生成AIの主なリスク

生成AIは業務効率化や情報収集などに役立つ一方、使い方によっては情報漏洩や誤った判断につながる可能性があります。企業で利用する際には、どのような情報を入力するのか、生成された内容をどのように扱うのかといった観点からリスクを把握する必要があります。

機密情報・個人情報の漏洩

生成AIに顧客情報や社内の機密情報、個人情報などを入力すると、利用するサービスの仕様や設定によっては、入力した情報がサービス提供者側で保存・利用される可能性があります。業務で生成AIを利用する場合は、入力してよい情報と禁止する情報を明確にするとともに、利用するサービスのデータ取り扱い方針や設定を確認することが必要です。

誤情報・ハルシネーション

生成AIは、事実と異なる内容や、もっともらしい誤情報を生成することがあります。こうした現象は「ハルシネーション」と呼ばれます。

生成された文章や回答を十分に確認せず、社内資料や顧客への回答、意思決定などに利用すると、誤った情報が業務に影響を及ぼすおそれがあります。重要な情報については、信頼できる情報源と照合するなど、人による確認が欠かせません。

著作権・知的財産に関するリスク

生成AIでは、入力する情報と生成されたコンテンツの双方について、著作権や知的財産への配慮が必要です。第三者が権利を持つ文章や画像などを安易に入力したり、AIが生成したコンテンツを確認せずに公開・商用利用したりすると、権利上の問題につながる可能性があります。利用する生成AIサービスの規約を確認するとともに、生成物の利用方法に応じた確認体制を整えることが求められます。

シャドーAI

シャドーAIとは、組織が把握・管理していない生成AIサービスを従業員が業務で利用している状態を指します。企業が生成AIの利用を一律に禁止していても、従業員が個人アカウントなどを使って利用すれば、機密情報が管理外のサービスへ入力される可能性があります。そのため、単に利用を禁止するだけでなく、利用可能なAIサービスや用途を明確にし、組織として利用状況を把握できる環境を整えることが重要です。

生成AIの利用に伴うリスクや企業が取るべき対策については、「生成AIのリスクとは？企業利用で注意すべき情報漏洩・著作権・誤情報と対策」で詳しく紹介します。

AIを狙ったサイバー攻撃にも注意が必要

AIセキュリティで考えるべきなのは、従業員が生成AIを安全に利用するための対策だけではありません。AIやLLM（大規模言語モデル）を組み込んだシステムが普及することで、AIの仕組みや特性を悪用した攻撃への備えも必要になっています。

プロンプトインジェクション

プロンプトインジェクションは、攻撃者が悪意のある指示をAIに与えることで、本来想定されていない動作や出力を引き起こそうとする攻撃です。ユーザーが直接入力する指示だけでなく、AIが読み込むWebページや文書などに悪意のある指示を埋め込む「間接プロンプトインジェクション」にも注意が必要です。外部の情報を参照するAIや、他のシステムと連携して処理を行うAIでは、影響範囲が広がる可能性があります。

センシティブ情報の漏洩

AIを組み込んだシステムでは、モデルが参照できる情報やユーザーの入力内容などが、意図せず出力される可能性があります。特に、社内文書や顧客情報などをAIから参照できるようにしている場合には、利用者の権限に応じて参照可能な情報を制御するなど、AIだけに依存しないアクセス制御が必要です。

データやモデルへの不正な操作

AIの動作は、学習データや外部から取得する情報などの影響を受けます。攻撃者によってデータが意図的に操作されれば、AIの判断や出力が影響を受ける可能性があります。AIが参照するデータの信頼性を確認するとともに、データへのアクセスや変更を適切に管理することが求められます。

AIに与える権限にも注意

AIエージェントなど、AIが外部サービスや社内システムと連携して処理を実行する仕組みでは、AIにどこまでの権限を与えるかが重要になります。必要以上の権限を付与すると、AIが意図しない操作を行った場合や攻撃者に悪用された場合の影響が大きくなります。人のアカウントと同様に、AIについても必要最小限の権限を設定し、重要な処理には人による確認を組み合わせることが重要です。

OWASPが示すLLMアプリケーションのリスク

LLMを利用したアプリケーションには、従来のWebアプリケーションと共通するリスクに加え、プロンプトインジェクションをはじめとしたLLM特有のリスクがあります。

OWASPでは、LLMや生成AIアプリケーションで特に注意すべきセキュリティリスクを整理しています。AIを組み込んだサービスを開発・提供する企業では、こうしたリスクを踏まえて、設計・開発・運用の各段階で対策を検討する必要があります。

具体的な脅威と対策については、「LLMセキュリティとは？プロンプトインジェクションなどの脅威と対策」で詳しく紹介します。

AIセキュリティ対策は「利用」と「システム」の両面から考える

ここまで見てきたように、AIセキュリティには、従業員による生成AIの利用に伴うリスクと、AIを組み込んだシステムそのものに対するリスクがあります。そのため企業では、利用ルールの整備だけでなく、ガバナンスや技術的なセキュリティ対策を組み合わせて取り組むことが必要です。

AI利用ルールを整備する

まず、従業員がどのような条件でAIを利用できるのかを明確にします。利用可能なAIサービスや用途、入力してはいけない情報、生成物を利用する際の確認方法などを定め、従業員が判断に迷わないルールにすることが重要です。また、AIサービスや利用方法は変化するため、一度ルールを作成して終わりにせず、利用状況に応じて見直していく必要があります。

AIガバナンスの体制を整備する

AIの利用を個々の従業員や部門だけに任せるのではなく、組織として管理する仕組みも必要です。誰がAI利用を管理するのか、どのようにリスクを評価するのか、問題が発生した場合にどの部門が対応するのかなど、役割と責任を明確にします。

AI利用ガイドラインの策定方法や組織としての管理体制については、「AIガバナンスとは？企業に必要な体制とAI利用ガイドラインの作り方」で詳しく紹介します。

シャドーAIを把握・管理する

ルールを整備しても、組織が把握していないAIサービスが利用されていれば、リスクを十分に管理できません。どの部門でどのようなAIが利用されているかを把握し、必要に応じて利用サービスを承認制にするなど、実際の利用状況とルールを一致させる取り組みが必要です。

AIを組み込んだシステムのセキュリティを確認する

AIを利用したシステムを開発・導入する場合には、通常のアプリケーションと同様のセキュリティ対策に加えて、AI・LLM固有のリスクも確認します。入力・出力の検証、アクセス制御、権限管理、APIや外部サービスとの連携、ログの記録などを確認し、プロンプトインジェクションをはじめとする攻撃への対策も検討します。

継続的なセキュリティ対策の見直し

AIを取り巻くサービスや技術、攻撃手法は変化しています。現在安全と判断した利用方法や設定であっても、将来も同じとは限りません。AIの利用状況や新たな脅威を定期的に確認し、ガイドラインやシステム設定、セキュリティ対策を継続的に見直していくことが重要です。

企業はAIセキュリティ対策をどこから始めるべきか

AIセキュリティといっても、すべての対策を一度に導入する必要はありません。まずは自社でAIがどのように使われているかを把握し、リスクの高い領域から優先して対策を進めます。

STEP1　AIの利用状況を把握する
利用しているAIサービス、利用部門、用途、取り扱う情報などを整理します。
STEP2　扱う情報とリスクを整理する
機密情報や個人情報など、AIで扱う情報と想定されるリスクを確認します。
STEP3　AI利用ガイドラインを整備する
利用可能なサービスや用途、禁止事項、生成物の確認方法などを定めます。
STEP4　技術的なセキュリティ対策を実施する
AIを組み込んだシステムについて、アクセス制御や権限管理、入出力の検証、脆弱性への対策などを行います。
STEP5　継続的に評価・改善する
利用状況や新たなリスクを確認し、ルールと技術対策を定期的に見直します。

AIの利用を一律に禁止するのではなく、どこにリスクがあるのかを把握したうえで、業務上のメリットと安全性のバランスを取りながら活用していくことが重要です。

AIセキュリティに関するよくある質問

▼ AIセキュリティとは何ですか？
▼ 生成AIを業務で利用する場合、どのようなリスクがありますか？
▼ AI利用ガイドラインには何を定めればよいですか？
▼ LLMにはどのようなセキュリティリスクがありますか？

まとめ

生成AIの普及によって、企業がAIを業務やシステムに取り入れる機会は広がっています。それに伴い、情報漏洩や誤情報、著作権などの利用上のリスクだけでなく、プロンプトインジェクションをはじめとするAI・LLMを狙った攻撃についても考える必要があります。AIセキュリティでは、AIを安全に利用することとAIを組み込んだシステムを安全にすることの両面から対策を進めることがポイントです。まずは自社でどのようにAIが利用されているかを把握し、AI利用ガイドラインや管理体制を整備するとともに、AIを組み込んだシステムについてはアクセス制御や権限管理、入出力の検証など、技術的な対策も進めていきましょう。

AIを取り巻く技術や脅威は変化しています。利用を一律に制限するのではなく、リスクを継続的に把握・評価しながら、安全なAI活用につなげていくことが重要です。

参考情報

公開日：2025年4月16日
更新日：2026年8月26日

編集責任：木下

BBSecでは

AIの利用拡大に伴い、企業を取り巻くIT環境やセキュリティリスクも変化しています。公開IT資産の把握、脆弱性の確認、セキュリティ対策の有効性検証など、自社の課題に応じた対策をご相談ください。

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

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

参考情報

編集責任：木下

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

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

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

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

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

最新情報はこちら

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

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

投稿日:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

【参考情報】

編集責任：木下

BBSecでは

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

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

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

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

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

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

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

    • 最新情報はこちら

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

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

    投稿日:

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

    投稿日:

    WordPress脆弱性「wp2shell」とは？影響・対象バージョン・対策を解説

    Share
    wp2shellとは？WordPress脆弱性の対象バージョンと対策アイキャッチ画像

    2026年7月、WordPress Coreに存在する2件の脆弱性を悪用し、認証前から管理者権限の取得や任意コード実行（RCE）につながる攻撃チェーン「wp2shell」が公表されました。WordPress.orgは修正版を公開し、対象バージョンへの強制自動更新を有効化していますが、すでにPoCや実攻撃が確認され、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）も「Known Exploited Vulnerabilities（KEV）カタログ」へ登録しています。本記事では、wp2shellの対象バージョンや仕組み、確認されている攻撃、侵害確認のポイント、企業が取るべき対策を解説します。

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

    まず確認したいポイント

    • 影響を受けるバージョン：WordPress 6.9.0～6.9.4、7.0.0～7.0.1（6.8.0～6.8.5もSQLインジェクションの影響あり）
    • 対応方法：修正済バージョン（WordPress 6.9.5／7.0.2／6.8.6）へ更新
    • 更新後の確認：稼働バージョンと侵害の有無（管理者アカウント・プラグイン・PHPファイル・ログ）

    自動更新が有効でも、更新が正常に完了しているとは限りません。実際に稼働しているバージョンを確認し、修正前のバージョンを公開していた場合は、更新に加えて侵害の有無も確認する必要があります。

    wp2shellの対象バージョン

    wp2shellの影響範囲はWordPressのバージョンによって異なります。まずは利用中のバージョンが対象かどうかを確認してください。特にWordPress 6.8系について、「wp2shellのRCE対象外」と「今回の脆弱性の影響をまったく受けない」を混同しないことが大切です。

    WordPressバージョンCVE-2026-60137CVE-2026-63030wp2shellによる未認証RCE修正済バージョン
    6.8未満対象外対象外対象外今回の2件については対象外。ただし、サポート状況を踏まえ最新バージョンを推奨
    6.8.0～6.8.5影響あり対象外対象外6.8.6
    6.9.0～6.9.4影響あり影響あり影響あり6.9.5
    7.0.0～7.0.1影響あり影響あり影響あり7.0.2
    7.1 Beta 1影響あり影響あり影響あり7.1 Beta 2

    WordPress.orgは重大性を踏まえ、影響を受けるサイトへの強制自動更新を有効化しました。ただし、自動更新が無効な環境や、ファイル権限・通信の問題で更新に失敗した環境、運用上の理由でバージョンが固定されている環境も考えられます。自動更新の設定ではなく、現在稼働中のバージョンを基準に影響を判断してください。

    wp2shellとは

    wp2shellは単独の脆弱性名や3件目のCVEではありません。WordPress Coreに存在するCVE-2026-60137とCVE-2026-63030を連鎖させ、認証前のSQLインジェクションから管理者権限の取得、さらに任意コード実行へつなげる攻撃チェーンの通称です。

    脆弱性概要wp2shellでの役割
    CVE-2026-60137WP_Queryのauthor__not_inパラメータに関するSQLインジェクション攻撃者がデータベース処理を不正に操作する足掛かりになる
    CVE-2026-63030WordPress REST APIのバッチ処理で発生するルート混同本来の検証と異なる処理経路を使わせ、SQLインジェクションを認証前から到達可能にする

    WordPressのREST APIには、複数のサブリクエストをまとめて処理するバッチ機能があります。脆弱なバージョンでは、サブリクエストの入力を検証したルートと、実際に処理するルートの対応関係がずれる場合があります。その結果、本来は型や値を検証されるはずの入力が、適切な検証を受けないままデータベース処理へ到達し、SQLインジェクションが成立します。

    発見者が示したフルチェーンでは、SQLインジェクションを起点に複数のWordPress内部処理を悪用し、一時的に管理者権限でREST APIを実行させて新しい管理者アカウントを作成します。その後、プラグインのアップロード機能を悪用して任意コード実行へ至ります。

    wp2shellは脆弱なプラグインやテーマを前提とせず、WordPress Coreの脆弱性を連鎖させる攻撃です。Searchlight Cyberは、「脆弱なプラグインを必要とせず、標準的なWordPress環境で成立し得る」と説明しています*5。一方、Cloudflareは、同社が確認したRCE経路について「永続オブジェクトキャッシュを使用していない場合」という条件を示しています*2。永続オブジェクトキャッシュを使用していても、SQLインジェクション自体の影響は残るため、構成にかかわらず、影響を受けるWordPress Coreは修正版へ更新することが重要です。

    wp2shellの影響

    GitHubで公開された「Icex0/wp2shell-poc」は、Searchlight Cyberの公式チェッカーではなく、第三者による独立したPoCです。公開されたPoCには、SQLインジェクションの確認から管理者アカウント作成、任意コード実行までを再現する機能が実装されています。

    公開されたPoCには、SQLインジェクションの確認から管理者アカウントの作成、任意コード実行までを再現する機能が実装されています。これにより、攻撃の検証や自動化が容易になりました。PoCの利用は、許可を得た環境での検証に限定すべきです。

    実攻撃とKEV登録状況

    修正版の公開後、複数のPoCが公開され、実環境では悪性プラグインやWebシェルを設置する攻撃も確認されました。

    Wizは7月20日、同社が可視化できるクラウド環境において、複数の攻撃者が脆弱なWordPressを悪用した事例を確認したと報告しました*3。観測された活動には、悪性WordPressプラグインのアップロード、PHP Webシェルの設置、管理画面へのアクセス、管理者名やメールアドレスの列挙、ローカルファイルインクルージョンの試行が含まれます。一方、同社は同日時点で、横展開やデータ流出は確認していないとも述べています。

    7月21日には、米国CISAがCVE-2026-60137とCVE-2026-63030をKEVカタログへ追加しました。KEVへの登録は、実際の悪用を裏付ける証拠があることを示します。ただし、攻撃件数や国内での被害規模まで示すものではありません。それでも、修正版公開後の短期間にPoCと実攻撃が確認されていることから、対象バージョンのWordPressをインターネットへ公開している場合は、対象環境では定期メンテナンスを待たず、緊急性の高いパッチとして扱う必要があります。

    国内では独立行政法人情報処理推進機構（IPA）が7月22日に注意喚起を公開*4しています。また、JPCERT/CCも7月23日に「複数のセキュリティ企業が悪用を確認している」として、修正版への更新を呼びかけています*5。

    侵害確認のポイント

    ステップ1：稼働バージョンと公開期間を確認する

    • 現在のWordPress Coreのバージョンを確認する
    • 修正版へ更新済みの場合も、それ以前に脆弱な状態で公開していた期間がないか確認する（少なくとも2026年7月17日以降、可能であれば保存されている範囲全体のログを対象にする）
    • DNS、クラウド、レンタルサーバー、外部委託先を含め、管理対象外のWordPressや検証用サイトを含め、組織が現在公開されているWeb資産を棚卸しする

    ステップ2：REST APIのバッチエンドポイントへの通信を調べる

    • WebサーバーやWAFのログで /wp-json/batch/v1 および ?rest_route=/batch/v1 への不審なリクエストを確認する
    • HTTP 207の応答、wp2shell／rezwp2shell を含むUser-Agentを補助的な手掛かりとして確認する（※単独で攻撃成功を示すものではない）
    • 送信元、リクエスト内容、後続する管理画面へのアクセス、ファイル作成などを時系列で突き合わせる

    バッチAPIは正規の処理でも使われるため、HTTPステータスだけで侵害を断定することはできません。PoC固有のUser-Agentも容易に変更できる点に注意してください。

    ステップ3：管理者アカウント、プラグイン、PHPファイルを確認する

    • WordPressのユーザー一覧で、作成者や作成時刻に心当たりのない管理者アカウントがないか確認する
    • インストールした記録のないプラグインがないか確認する
    • wp-content/pluginsやキャッシュ領域に追加・変更されたPHPファイルがないか確認する
    • Webサーバープロセスからシェルや不審な子プロセスが起動された記録がないか確認する

    既知のファイル名やハッシュとの一致だけに頼るべきではありません。公開PoCは改変でき、攻撃者も名称や配置先を変えられます。通信、アカウント、ファイル、プロセスという複数の痕跡から判断してください。侵害の疑いがある場合は、証拠を保全したうえで対象を隔離し、組織のインシデント対応手順に従って調査を進めます。

    今すぐ行うべき対策

    WordPress Coreを修正版へ更新

    根本対策は、6.8系なら6.8.6、6.9系なら6.9.5、7.0系なら7.0.2への更新です。別のブランチへ移行する場合は、そのブランチで今回の脆弱性が修正済みのバージョンを選びます。WordPressの管理画面だけでなく、構成管理ツールやホスティング事業者の管理画面も確認し、更新後に実際のバージョンが切り替わったことを検証します。

    本番サイトの更新では、バックアップと復旧手順を確認し、プラグインやテーマとの互換性も検証します。ただし、今回のように実悪用が確認された脆弱性では、通常の更新サイクルをそのまま適用せず、リスクに応じて緊急変更として扱う判断が必要です。

    すぐに更新できない場合はWAFで一時的に遮断

    直ちにアップデートできない場合、Searchlight Cyberは暫定策として、未認証のバッチAPIへのアクセスを制限する方法を示しています。WAFやリバースプロキシで/wp-json/batch/v1とrest_route=/batch/v1の両方を対象にし、外部からの未認証アクセスを遮断します。

    遮断条件は、URLをデコード・正規化した後の値で判定し、受信時のHTTPメソッドだけで絞り込まないようにします。サブディレクトリに設置したWordPressや、WAFを通らずオリジンサーバーへ直接接続できる経路も確認が必要です。

    この対策は、正規のREST API利用に影響する可能性があります。また、WAFは脆弱なコードを修正するものではなく、設定や通信経路によっては防御を迂回されるおそれもあります。あくまで更新までの一時的なリスク低減策と位置づけ、WordPress Coreのアップデートを先送りしないでください。

    更新後も侵害の有無を調査

    修正版への更新は、この2件の脆弱性を利用した新たな侵入を防ぐための根本対策です。ただし、更新前に作成された管理者アカウントやWebシェルは削除されません。脆弱な状態で公開していたサイトは、更新後もログ、アカウント、プラグイン、ファイル改変を確認します。

    侵害が確認された場合は、単に不審なファイルを削除して公開を再開するのではなく、影響範囲を特定し、信頼できるバックアップからの復旧、認証情報や秘密情報の変更、再侵入経路の遮断までを一連のインシデント対応として行う必要があります。

    よくある質問

    ▼ wp2shellはWordPressプラグインの脆弱性ですか？
    ▼ WordPress 6.8系はwp2shellの影響を受けますか？
    ▼ 自動更新を有効にしていれば対策済みですか？
    ▼ WAFだけでwp2shellを防げますか？
    ▼ wp2shellを利用した実攻撃は確認されていますか？
    ▼ 修正版へ更新すれば侵害調査は不要ですか？

    まとめ

    wp2shellは、WordPress Coreに存在する2件の脆弱性を組み合わせ、認証前から管理者権限の取得や任意コード実行（RCE）につながる攻撃チェーンです。対象となるWordPressバージョンでは、すでにPoCや実攻撃が確認され、CISAのKEVカタログにも登録されています。

    影響を受けるバージョンを利用している場合は、修正版への更新を速やかに実施してください。また、修正前のバージョンをインターネットに公開していた場合は、更新だけでなく、管理者アカウントやプラグイン、PHPファイル、アクセスログなどを確認し、侵害の有無も調査することが重要です。

    今回の事例は、脆弱性情報の公開後、短期間でPoCや実攻撃が確認された事例でもあります。今後の緊急対応を迅速化するため、平時から公開資産を継続的に把握できる運用体制を整えることが重要です。

    【関連記事】

    【参考情報】

    【コラム】AIを活用した脆弱性研究

    今回のwp2shellは、AIを活用した脆弱性研究の事例としても注目されました。Searchlight CyberのAdam Kues氏は、GPT-5.6 Sol Ultraをコード監査に活用し、約10時間で攻撃チェーンを構築できたと報告しています。一方で、調査対象の選定や検証、WordPressへの責任ある報告は研究者自身が行っており、「AIが単独で脆弱性を発見した」わけではありません。本件は、AIの活用によって脆弱性研究が効率化される一方、修正版公開後からPoCや実攻撃が出現するまでの期間が短くなる可能性を示した事例としても注目されています。

    参考：

    編集責任：木下

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

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

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

    最新情報はこちら

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

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

    投稿日:

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

    Share
    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は従業員が業務上の課題を解決しようとして発生することが多く、責めるのではなく、報告しやすいセキュリティ文化を作ることが重要」だと説明しています*6。

    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 Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

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