タグ: 脆弱性

投稿日:

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環境で成立し得る」と説明しています*1。一方、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に戻る

投稿日:

見落としがちなIT資産がセキュリティ事故を招く？企業で起こりやすい5つの管理課題

Share
「見落としがちなIT資産管理の課題5選」アイキャッチ画像

前回記事では、IT資産管理の基本と重要性を解説しました。管理されていない端末やクラウド環境、シャドーIT、サポート終了製品など、見落とされたIT資産が被害につながるケースも少なくありません。今回は、管理が行き届かない場合に実際どのような問題が起こりやすいのか、企業で起こりやすい5つの管理課題を具体的に見ていきます。

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

セキュリティ事故は、必ずしも高度な攻撃だけで起こるわけではありません。実際には、管理されていない端末、放置されたクラウド環境、退職者のアカウント、サポート終了ソフトウェアなど、見落としがちなIT資産がきっかけになることがあります。IT資産管理が不十分な状態では、脆弱性情報が公開されても対象資産を特定できず、インシデント発生時にも影響範囲をすばやく把握できません。

なぜ管理漏れが起こるのか

IT資産の管理漏れは、担当者の怠慢だけで起こるものではありません。むしろ、事業スピードに管理体制が追いつかないことで発生します。新しいSaaSを部門単位で契約する、検証用にクラウド環境を作成する、テレワーク用に端末を追加する、業務委託先にアカウントを付与する。こうした日常的な業務の中で、台帳更新や承認プロセスが後回しになると、実態とのズレが広がっていきます。

企業で起こりやすい5つの管理課題

台帳が更新されない

IT資産管理で最も起こりやすい課題は、資産台帳が更新されないことです。導入時には正確だった台帳も、ソフトウェア更新やクラウド環境の追加が反映されなければ、すぐに実態とずれていきます。特にExcelやGoogleスプレッドシートで管理している場合、更新担当者が限られ、現場の変更が反映されないまま時間が経過しがちです。その結果、台帳上は存在するのに実際には廃棄済みの機器、逆に台帳にはないが稼働している資産が発生します。インシデント対応時にこの状態だと、影響範囲の特定に時間がかかり、初動対応の遅れにつながります。

シャドーITが増える

シャドーITとは、情報システム部門や管理部門が把握していないIT資産やサービスが、業務目的で利用されている状態を指します。英国のサイバーセキュリティ機関NCSCでは、「シャドーITは悪意によって生まれるとは限らず、従業員が業務を進めるために、承認済みのツールやプロセスでは対応できない課題を解決しようとして発生することが多い」と説明しています。たとえば、ファイル共有が不便だから個人用クラウドストレージを使う、社内承認に時間がかかるため部門でSaaSを契約する、開発検証のために個人名義に近い形でクラウド環境を作る、といった行動です。本人に悪意がなくても、会社のセキュリティポリシー、バックアップ、アクセス制御、監査ログ、退職時のアカウント削除の対象外になるため、情報漏洩や不正アクセスのリスクが高まります。シャドーIT対策で重要なのは、単に禁止することではありません。なぜ現場が非公式な手段を使わざるを得なかったのかを把握し、業務に必要なツールを安全に使える仕組みに変えることです。

クラウド資産が把握できない

クラウド環境では、サーバやストレージ、データベース、コンテナ、API、アカウント、権限設定などが短時間で作成・変更・削除されます。オンプレミス環境のように物理的なサーバーが目に見えるわけではないため、管理対象から漏れやすいのが特徴です。検証用に作ったクラウド環境が放置され、インターネットに公開されたままになる。開発者が一時的に広い権限を付与し、その後も戻されない。ログ設定やバックアップ設定が本番環境と異なる。こうした状態は、クラウド利用が進む企業ほど起こりやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の「Cybersecurity Performance Goals」でも、既知の資産だけでなく、未知の資産、シャドー資産、未管理資産を特定し、新たな脆弱性への検知・対応を速めることが目的として示されています。

EOL（End of Life）・EOS（End of Service）を見逃す

サポートが終了したOS、ネットワーク機器、VPN機器、業務アプリケーション、ミドルウェアを使い続けることも、IT資産管理上の大きな課題です。サポートが終了した製品は、脆弱性が発見されても修正プログラムが提供されない可能性があります。資産台帳にサポート期限や保守期限が記録されていなければ、更新計画を立てることもできません。

EOL・EOSについては前回記事でも触れていますので、あわせてご覧ください。

また、ソフトウェア資産の構成管理まで行いたい場合、EOL・EOS対策の延長としてSBOM（ソフトウェア部品表）も重要になります。経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 Ver.2.0」では、資産管理台帳だけでは、下位コンポーネントとして利用されるOSSなどに脆弱性が見つかった場合に、間接的な影響を検知できない場合があると説明されています。

SBOMについては、「SBOMとは？ソフトウェア部品表の基本と企業が導入すべき理由」でも解説しています。あわせてご覧ください。

部門ごとに管理している

IT資産管理が部門ごとに分断されていることも、企業でよく見られる課題です。情報システム部門はPCとネットワーク機器を管理し、開発部門はクラウド環境を管理し、総務部門はリース契約を管理し、各事業部がSaaS契約を管理している。このような状態では、全社としてどのIT資産が存在するのかを把握できません。部門ごとの管理は、現場のスピードを保つうえでは便利です。しかし、セキュリティ事故が起きたときには、誰が責任者なのか、どの情報が保存されているのか、どの範囲に影響があるのかが分からなくなります。特に、SaaSやクラウドサービスでは、管理者権限を持つ担当者が異動・退職した後に、契約やアカウントだけが残り続けるケースもあります。

管理課題を解決するポイント

IT資産管理の課題を解決するには、台帳を作るだけでは不十分です。重要なのは、資産が増える、変わる、使われなくなるタイミングで、台帳や管理システムが自然に更新される運用を作ることです。まず、IT資産管理の対象範囲を明確にします。PCやサーバだけでなく、クラウド環境、SaaS、アカウント、ネットワーク機器、ソフトウェア、ライセンスまで含めるかを決めます。次に、資産ごとに管理責任者を定めます。所有者が曖昧な資産は、脆弱性対応や費用管理、廃棄判断が遅れやすくなります。そのうえで、購買、入社、異動、退職、クラウド作成、SaaS契約、機器廃棄といった業務フローにIT資産管理を組み込みます。ツールを導入する場合も、単体で完結させるのではなく、ID管理、EDR、MDM、脆弱性管理、クラウド管理と連携させることで、実態に近い情報を保ちやすくなります。

課題を解決する具体的な運用方法については「IT資産管理を効率化する方法とは？担当者が押さえたい運用のポイント」をご覧ください。

まとめ：見えていないIT資産は、守れない

IT資産管理の課題は、すぐに大きな障害として表面化するとは限りません。しかし、管理漏れ、シャドーIT、クラウド資産の放置、サポートが終了した製品・機器の見逃し、部門ごとの分断が積み重なると、セキュリティ事故の温床になります。

次回は、こうした課題を解決するための具体的な運用方法について解説します。

【参考情報】

編集責任：木下

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

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

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

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

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

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

投稿日:

IT資産管理とは？企業のセキュリティ対策で最初に取り組むべき理由を解説

Share
IT資産管理とは？企業のセキュリティ対策で最初に取り組むべき理由アイキャッチ画像

企業のセキュリティ対策では、EDRや脆弱性診断などの対策に注目が集まりがちですが、その前提となるのが「IT資産管理」です。自社で利用している端末やサーバー、クラウドサービス、SaaSなどを正確に把握できていなければ、脆弱性への対応やインシデント対応も適切に行えません。本記事では、IT資産管理の基本から重要性、管理できていない場合のリスク、実践のポイントまで分かりやすく解説します。

企業のセキュリティ対策というと、EDR、WAF、脆弱性診断、ゼロトラスト、SOCなどの高度な対策を思い浮かべる方も多いかもしれません。しかし、どれだけ優れたセキュリティ製品を導入しても、自社がどの端末、サーバー、クラウドサービス、ソフトウェアを利用しているのかを把握できていなければ、守るべき対象を正しく守ることはできません。 IT資産管理は、企業が利用するIT資産を継続的に把握・管理する取り組みです。単なる資産台帳の作成ではなく、脆弱性管理やパッチ管理、ライセンス管理、インシデント対応を支える重要な基盤となります。

IT資産管理とは

IT資産管理とは、企業活動で利用されるIT機器、ソフトウェア、クラウドサービス、ネットワーク機器、アカウントなどを把握し、誰が、どこで、何の目的で、どの状態で使っているのかを管理することです。従来は、PCやサーバーの購入日、設置場所、利用者、リース期限などを管理する「物品管理」に近い意味で使われることもありました。しかし現在のIT資産管理では、資産を一覧化するだけでなく、資産の追加・変更・廃止に合わせて継続的に更新し、常に最新の状態で管理することが求められています。管理対象となるIT資産には、業務用PC、サーバー、スマートフォン、タブレット、ネットワーク機器、複合機、IoT機器、仮想マシン、クラウド上のインスタンス、SaaS、業務アプリケーション、OS、ミドルウェア、ライセンス、利用アカウントなどが含まれます。

NIST(米国国立標準技術研究所)が金融サービス業界向けに公表した実装ガイドでは、物理的な資産管理だけでは「自社の端末がどのOSを使っているか」「どの端末に脆弱性があるか」までは分からないとした上で、IT資産管理はこうした情報を結びつけて管理することで、資産の可視性とセキュリティを高めるものだと説明しています*2。

また、IT資産管理の重要性は、NISTだけでなくCISクリティカルセキュリティコントロール（CISコントロール）でも示されています。ベストプラクティス「Control 1」では、モバイル端末を含むエンドユーザー端末、ネットワーク機器、IoT機器、サーバーを対象資産と定め、これらを物理・仮想・リモート・クラウド環境を問わず継続的に把握・追跡することが、資産管理の第一歩として位置づけられています。あわせて、未承認・未管理の資産を洗い出し、除去または是正することも求められています。

このように、IT資産管理は単なる資産一覧の作成ではなく、継続的に資産を可視化し、セキュリティ対策へつなげるための基盤といえます。IT資産管理とは「パソコンが何台あるか」を数える作業ではなく、攻撃者から見たときに侵入口になり得るもの、業務停止につながるもの、情報漏洩につながるものを可視化する取り組みです。資産の存在を知らなければ、脆弱性があっても対応できません。利用者が分からなければ、インシデント発生時に連絡できません。重要度が分からなければ、限られた人員で何から対応すべきか判断できません。

なぜ今IT資産管理が重要なのか

IT資産管理の重要性が高まっている背景には、クラウド利用の拡大、テレワークの普及、SaaSの増加があります。総務省「通信利用動向調査」は、企業における情報通信ネットワークや情報通信サービスの利用動向を把握するための統計であり、企業編ではクラウドサービス利用やテレワーク導入状況などのデータが提供されています。こうした環境では、社内ネットワーク内にある機器だけを見ていればよい時代ではなくなりました。たとえば、開発部門が検証用にクラウド環境を作成し、営業部門が顧客管理のためにSaaSを契約し、従業員が自宅や外出先から業務システムにアクセスする。こうした働き方は業務効率を高める一方で、情報システム部門が把握していないIT資産を生みやすくします。社内の承認を経ずに導入されたSaaS、管理されていないクラウドストレージ、退職者のアカウント、放置された検証環境は、いずれもセキュリティ上のリスクになります。さらに、生成AIサービスの業務利用が広がり、情報システム部門が把握していないクラウドサービスやAIツールが利用されるケースも増えています。

経済産業省とIPAが公表する「サイバーセキュリティ経営ガイドライン Ver.3.0」でも、経営者が確認すべきチェック項目として、「守るべきデジタル環境・サービス・情報を特定し、資産の場所やビジネス上の価値等に基づいて対策の優先順位付けを行うこと」（指示4）、さらに「重要なシステムの資産管理・構成管理・パッチ管理を行うこと」、「組織内でシャドーITを利用させない対策を行うこと」（指示5）が挙げられています。

IT資産管理は、セキュリティ対策の中でも地味に見えるかもしれません。しかし、攻撃対象となる端末やサービスが増え続ける現在では、最初に取り組むべき基盤です。

IT資産管理で起こりやすい課題について詳しく解説した記事はこちら
「見落としがちなIT資産がセキュリティ事故を招く？企業で起こりやすい5つの管理課題」

IT資産管理ができていない企業で起こる問題

IT資産管理ができていないと、管理漏れやシャドーITの発生、サポート終了製品の放置など、セキュリティインシデントにつながるさまざまなリスクを抱えることになります。代表的な課題は次のとおりです。

管理漏れ

新しく購入した端末が台帳に反映されない、退職者のPCやアカウントが残ったままになる、検証用サーバーが本番環境と同じネットワークに接続されたまま放置される、といった状態です。平時には問題が見えにくくても、脆弱性情報が公開されたときやインシデントが発生したときに、どの端末が対象なのか、誰が利用しているのかが分からず、対応が遅れます。

シャドーIT

英国のサイバーセキュリティ機関NCSCは、シャドーITを、業務目的で使われているにもかかわらず資産管理の対象に含まれておらず、組織のITプロセスやポリシーからも外れている「未知の資産」だと位置づけています*2。対象はデバイスに限らず、従業員が個人契約しているクラウドストレージや、部門が独自に導入した未承認のクラウドサービスも含まれるとした上で、機密データの流出やマルウェア感染の拡大につながるリスクを指摘しています。

EOL（End of Life）機器

サポートが終了した製品では、脆弱性が発見されても修正プログラムが提供されない場合があります。JPCERT/CCも、マイクロソフト製品のサポート終了に関する注意喚起の中で、サポート終了後の製品は新たに発見された脆弱性が修正プログラムの提供対象外となり、悪用されるリスクが残り続けると繰り返し呼びかけています*3。

ライセンス管理

不要なSaaS契約が残り続ける、退職者分のライセンスが解放されない、利用許諾に反したソフトウェア利用が発生する、といった問題は、コスト面だけでなくコンプライアンス面のリスクにもつながります。

IT資産管理と脆弱性管理の違い

IT資産管理と脆弱性管理の違いを整理すると、下表のとおりです。

項目IT資産管理脆弱性管理
目的管理対象を把握するリスクを評価する
何を行うか台帳を整備する脆弱性を検出する
管理内容利用状況を管理する優先順位を付ける
継続的な運用継続的に更新する修正・パッチ適用する

IT資産管理と脆弱性管理は、それぞれ独立した取り組みではありません。まずIT資産管理によって「何を管理すべきか」を明確にし、その上で脆弱性管理を通じてリスクを評価・対応することが重要です。IT資産を正確に把握できていなければ、脆弱性の有無を確認したり、適切に対策を講じたりすることはできません。

NIST SP 800-40 Rev.4では、企業のパッチ管理を、パッチやアップデートを識別し、優先順位付けし、取得し、適用し、適用結果を検証するプロセスとして説明しています。同文書は、パッチ適用を技術基盤の「予防保守」として位置づけ、事業継続のために必要なコストであるとも指摘しており、経営判断としても軽視すべきでない活動だとしています。これは、資産が把握されていることを前提にした活動です。

IT資産を把握した後は、脆弱性管理によってリスクを評価・対応していく必要があります。詳しくは「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」をご覧ください。

まず何から始めればよいのか

IT資産管理を始める際に、最初から完璧な台帳を作ろうとする必要はありません。まずは、自社が守るべき範囲を決め、主要な端末、サーバー、ネットワーク機器、クラウドサービス、SaaS、アカウントを棚卸しすることから始めます。情報システム部門が管理している台帳、購買履歴、ネットワーク接続情報、MDMやEDRの管理画面、クラウド管理画面、SaaSの契約情報を突き合わせるだけでも、見落としていた資産が見つかることがあります。次に、資産台帳を整備します。台帳には、資産名、種別、利用部門、利用者、管理責任者、設置場所、OSやソフトウェアのバージョン、IPアドレス、重要度、サポート期限、最終確認日などを記録します。重要なのは、台帳を作って終わりにしないことです。入社、異動、退職、機器購入、クラウド環境作成、SaaS契約、廃棄といった業務プロセスと台帳更新を結びつけなければ、すぐに古い情報になります。最後に、可視化を継続します。IT資産管理ツールや脆弱性スキャン、クラウド管理ツール、ID管理基盤などを組み合わせることで、手作業だけでは追いきれない変化を検知しやすくなります。実際にIT資産管理を始める際には、棚卸しや台帳整備、運用ルールの策定などのステップがあります。

IT資産管理を効率化する具体的な方法はこちら
「IT資産管理を効率化する方法とは？担当者が押さえたい運用のポイント」

まとめ：IT資産管理はセキュリティ対策の出発点

IT資産管理は、単にIT資産台帳を作成することではなく、企業が利用する端末やサーバー、クラウドサービス、SaaSなどを継続的に把握・管理し、セキュリティ対策の土台を築くための取り組みです。IT資産の可視化ができていなければ、脆弱性管理やパッチ管理、インシデント対応を適切に進めることはできません。またIT環境は日々変化するため、一度台帳を作れば終わりではありません。新たなクラウドサービスの利用や端末の追加・廃止、組織変更などに応じて資産情報を更新し続けることが、セキュリティリスクの低減につながります。

次回は、管理が行き届かない場合に実際どのような問題が起こりやすいのか、具体的な課題を掘り下げていきます。

IT資産管理についてさらに理解を深めたい方は、以下の記事もあわせてご覧ください。

また、IT資産管理の次のステップとなる脆弱性管理については、こちらの記事をご覧ください。
「脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】」

【参考情報】

編集責任：木下

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

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

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

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

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

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

投稿日:

アフラック不正アクセスで約438万人の個人情報漏洩 ―保険会社を狙うサイバー攻撃のリスクと企業が取るべき対策

Share
「アフラック不正アクセスで約438万人の個人情報漏洩」アイキャッチ画像

保険会社が保有する個人情報は、単なる氏名や住所にとどまりません。契約内容、証券番号、保障内容、口座情報など、生活や資産に深く関わる情報が含まれるため、ひとたび情報漏えいが発生すると、なりすまし連絡やフィッシング詐欺、電話詐欺などに悪用される恐れがあります。

アフラック生命保険は2026年6月30日、「契約者専用サイト「アフラック よりそうネット」などのシステムが第三者による不正アクセスを受け、顧客の個人情報を含む一部情報が漏えいした」と公表しました。対象となる顧客数は約438万人で、このうち約23万人については保険料振替口座情報も含まれるとされています。現時点で、本件に関わる情報の不正利用は確認されていません。 本記事では、アフラックの不正アクセス事案の概要を整理しながら、保険会社や金融機関、個人情報を扱う企業が見直すべきサイバーセキュリティ対策、情報漏えい対策、インシデント対応のポイントを解説します。

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

アフラックで発生した不正アクセスと個人情報漏洩の概要

アフラック生命保険の公式発表*4によると、不正アクセスを受けたのは、契約者専用サイト「アフラック よりそうネット」などのシステムです。「アフラック よりそうネット」は、契約内容の確認や住所・電話番号の変更などを、パソコンやスマートフォンから行える契約者向けサイトと説明されています。

漏洩した顧客関連の情報には、氏名、生年月日、性別、住所、電話番号、証券番号、保障内容、保険料振替口座情報などが含まれます。保険料振替口座情報には、金融機関名、支店名、預金種類、口座番号、口座名義などが含まれるとされています。一方で、「マイナンバーおよびクレジットカード情報は含まれていない」と公表されています。漏洩件数は、顧客数で約438万人です。そのうち、漏洩した項目に保険料振替口座情報が含まれる顧客数は約23万人とされています。また、代理店関連の個人情報として、代理店代表者氏名、代理店住所、代理店電話番号など、約4万店分の情報も漏洩したとのことです。

不正アクセスはいつ発生し、いつ判明したのか

公式発表によれば、情報漏洩が判明したのは2026年6月25日です。同日、アフラックは当該不正アクセスを遮断し、不正アクセスの拡大を防ぐため、関連するシステムを停止しました。その後の調査で、不正アクセスが最初に発生したのは2026年6月15日であり、6月25日までに複数回、不正にアクセスされていたことが確認されています。一方で、原因の詳細は「調査中」とされています。現時点で、脆弱性の悪用、認証情報の窃取、内部アカウントの悪用、ランサムウェア攻撃など、具体的な攻撃手口は公表されていません。

現在停止しているサービスと顧客対応

アフラックは、不正アクセスの拡大を防ぐため、一部システムを停止しています。公式ページでは、よりそうネット、人間ドック・健診予約サービス、妊活コンシェルジュサービス、オンライン家計簿サービス「マネーフォワード for アフラック」、アフラックAIサポートコンシェルジュなどが、現在利用できないサービスとして案内されています。ただし保険金・給付金の請求をはじめとする各種問い合わせや手続きは、「コールセンターなどで通常どおり受け付けている」と説明されています。対象となる顧客には、「順次、お詫びとお知らせの文書を送付する」としており、「金融庁・警察等の関係機関にも報告済み」とのことです。 システム停止は、利用者にとって不便を生みます。しかし、不正アクセスの範囲が判明していない段階で関連システムを止める判断は、被害拡大を抑えるうえで重要な初動対応です。

独立行政法人情報処理推進機構（IPA）が公開している「情報漏えい発生時の対応ポイント集」でも、不正アクセスによって個人情報や機密情報が漏えいする危険性が確認された場合、ネットワークからの切り離しやサービス停止などの処置が必要になると説明されています。

なぜ保険会社の個人情報漏えいは深刻なのか

今回のアフラック不正アクセス事案で注目すべき点は、漏洩した可能性のある情報の組み合わせです。氏名、住所、電話番号、生年月日だけでなく、証券番号や保障内容、保険料振替口座情報まで含まれる場合、攻撃者は「保険契約の確認」「給付金手続き」「口座情報の確認」「契約内容の更新」などを装った連絡を行いやすくなります。これは、単なるメールアドレス漏洩よりも、なりすましの説得力が高まりやすい情報漏洩といえます。

フィッシング対策協議会はフィッシングについて、「実在する組織を騙って、ユーザネーム、パスワード、アカウントID、ATMの暗証番号、クレジットカード番号といった個人情報を詐取すること」と説明しています*2。今回の事案で実際にフィッシング被害が確認されたわけではありませんが、保険会社をかたる不審なメール、SMS、電話には十分な注意が必要です。 特に、金融機関名や口座番号が含まれる可能性がある顧客については、口座そのものから直ちに出金されるとは限らないものの、別の詐欺や本人確認の突破材料として悪用されるおそれがあります。アフラックも公式発表の中で、不審な連絡を受けた場合や、保険料振替口座における不審な取引などの懸念が生じた場合には、同社連絡先へ連絡するよう案内しています。

企業が学ぶべきポイントは「侵入されない」だけではない

サイバーセキュリティ対策というと、ファイアウォール、ウイルス対策ソフト、多要素認証、脆弱性診断など、「侵入を防ぐ対策」に目が向きがちです。もちろん、これらの対策は重要です。しかし、今回のように不正アクセスが複数回行われ、一定期間後に判明した事案を見ると、企業に求められるのは「侵入を完全に防ぐ」ことだけではありません。重要なのは、侵入の兆候を早期に検知し、被害範囲を特定し、必要なシステムを迅速に隔離し、顧客や関係機関へ適切に説明できる体制です。

個人情報保護委員会では、「個人データの漏えい等が発生し、個人の権利利益を害するおそれがある場合、個人情報保護委員会への報告および本人への通知が必要」と説明しています*3。該当する事態には、「財産的被害が生じるおそれがある事態」、「不正の目的をもって行われた漏えい等が発生した事態」、「1,000人を超える漏えい等が発生した事態」が含まれます。また、本人へ通知する際には、「概要、個人データの項目、原因などを、本人にとって分かりやすい方法」で伝える必要があります。企業の情報漏洩対応では、技術的な調査だけでなく、顧客への説明、問い合わせ対応、監督官庁への報告、再発防止策の公表までを一連のインシデント対応として設計しておく必要があります。

関連記事：情報漏洩対策の基本を詳しく知りたい方へ

情報漏洩対策は、不正アクセスを防ぐだけでは十分ではありません。情報漏洩が発生する原因や企業への影響、技術・運用・組織の3つの観点から取り組むべき対策について、基礎から分かりやすく解説しています。あわせてご覧ください。
「情報漏洩対策とは何か ―企業が知るべき原因・リスク・防止策の全体像―」

金融・保険業界で高まるサードパーティリスク管理の重要性

今回のアフラックの事案について、現時点の公式発表では、委託先や外部サービスが侵入経路だったとは説明されていません。そのため、本件をサードパーティ起点のインシデントと断定することはできません。一方で、金融庁は金融分野のサイバーセキュリティ対策として、サードパーティ・サイバーセキュリティリスク管理の重要性を継続的に取り上げています*4。金融庁の関連資料では、金融機関が管理すべきサードパーティや、その先に存在するNthパーティの範囲、集中リスク、契約後の継続的なモニタリングなどが課題として示されています。

アフラックでは2023年にも、業務委託先の外部業者において同社保有の個人情報の一部が流出した事案が公表されていました*5。この2023年事案では、対象となった顧客数は132万3,468人で、流出した個人情報の項目は姓のみ、年齢、性別、証券番号、保険種類番号、保障額、保険料などでした。今回の2026年事案とは発生経路や漏洩項目が異なるため同一視はできませんが、保険会社が扱う情報の価値と、外部委託先を含めた管理体制の重要性を考えるうえで、過去事例として参照できます。

保険会社、金融機関、医療機関、自治体、BtoBサービス事業者など、重要な個人情報を扱う組織では、自社システムだけでなく、外部委託先、クラウドサービス、SaaS、開発会社、運用保守会社まで含めたリスク管理が欠かせません。契約時のセキュリティチェックだけで終わらせず、運用中の監査、ログ確認、脆弱性対応、インシデント発生時の連絡体制まで確認しておくことが重要です。

企業が今すぐ見直すべきセキュリティ対策

今回の事案から企業が学ぶべき第一のポイントは、個人情報を保管するシステムのアクセス管理です。顧客情報、契約情報、口座情報などを扱う管理画面では、多要素認証、IPアドレス制限、権限の最小化、休眠アカウントの棚卸し、特権IDの監視を徹底する必要があります。IDとパスワードだけに依存した認証は、フィッシングや認証情報漏えいによって突破されるリスクがあります。

第二のポイントは、ログ監視と異常検知です。不正アクセスが発生しても、ログが取得されていなければ、侵入経路や閲覧された情報、被害範囲を後から正確に追うことが難しくなります。個人情報保護委員会のフォレンジック調査に関する資料でも、不正アクセスの原因や被害範囲を明らかにし、効果的な再発防止策につなげるために、ログなどの証拠保全が重要であることが示されています。

第三のポイントは、インシデント発生時の復旧体制です。経済産業省の「サイバーセキュリティ経営ガイドライン Ver 3.0」では、インシデントにより業務停止等に至った場合に備え、復旧手順書の策定、復旧対応体制の整備、サプライチェーンも含めた実践的な演習の実施が必要であるとされています。顧客向けサービスを止める判断、代替手段の案内、問い合わせ窓口の設置は、平時に準備していなければ迅速に実行できません。

第四のポイントは、個人情報の持ち方そのものの見直しです。すべての情報を同じシステムで参照できる状態にしていないか、業務上不要な項目まで保存していないか、口座情報などの重要情報に追加の保護措置を設けているかを確認する必要があります。情報漏えい対策では、侵入を防ぐことに加え、万が一侵入された場合でも漏洩範囲を最小化する設計が求められます。

顧客側が注意すべきこと

今回のアフラック不正アクセス事案では、現時点で情報の不正利用は確認されていないとされています。しかし、漏洩した可能性のある情報には電話番号や住所、証券番号、保障内容、口座情報が含まれるため、顧客側でも不審な連絡に注意する必要があります。もしも、「契約内容の確認が必要です」「保険料の引き落とし口座を再登録してください」「給付金の手続きに必要です」といった連絡があった場合でも、メールやSMSに記載されたURLを安易に開かず、公式サイトや正規の問い合わせ窓口から確認することが大切です。警察庁もフィッシング対策として、迷惑メッセージブロック機能の活用や、ID・パスワードの使い回しを避けることを呼びかけています*6。特に、保険会社や金融機関を名乗る電話で、暗証番号、認証コード、インターネットバンキングのログイン情報などを求められた場合は注意が必要です。正規の企業を装った連絡であっても、その場で情報を伝えず、いったん電話を切って公式窓口に確認する対応が安全です。

まとめ　情報漏えい対策は「防御」から「検知・対応・復旧」へ

アフラックの不正アクセスによる個人情報漏えいは、保険会社や金融機関だけの問題ではありません。顧客情報、契約情報、決済情報、口座情報、問い合わせ履歴などを扱うすべての企業にとって、情報漏えい対策とインシデント対応の重要性を改めて示す事案です。

今回の公式発表で確認できるのは、約438万人の顧客情報が漏えいし、そのうち約23万人については保険料振替口座情報が含まれること、代理店約4万店分の情報も漏洩したこと、そして不正アクセスが6月15日から6月25日まで複数回確認されていることです。一方で、原因や攻撃手口の詳細は調査中であり、現時点で断定できる情報は限られています。

企業に求められるのは、侵入を防ぐための対策だけではありません。異常を早く見つける監視体制、被害範囲を確認するログ管理、顧客へ説明できる情報整理、サービス停止時の代替手段、復旧手順、再発防止策までを含めた総合的なサイバーセキュリティ体制です。 個人情報漏洩は、発生してから対応を考えるのでは遅すぎます。自社の顧客情報がどこにあり、誰がアクセスでき、どのログが残り、インシデント発生時に誰が判断するのか。今回の事案を機に、企業は不正アクセス対策、脆弱性管理、ログ監視、委託先管理、インシデント対応計画を改めて見直す必要があります。

【参考情報】

編集責任：木下

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

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

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

  • 2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」
  • 2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」
  • 2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

    • 最新情報はこちら

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

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

    投稿日:

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

    Share
    「サッポロHD海外2社に不正アクセス」アイキャッチ画像

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    まとめ

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

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

    【参考情報】

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

    編集責任：木下

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

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

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

  • 2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」
  • 2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」
  • 2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

    • 最新情報はこちら

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

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

    投稿日:

    KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性―企業が見直すべき「共通基盤リスク」とは

    Share
    「KDDIメールシステムに不正アクセス、最大1,422万件漏えいの可能性」アイキャッチ画像

    KDDI株式会社（以降、KDDI）がISP事業者向けに提供するメールシステムで不正アクセスが確認され、BIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスにおいて、メールアドレスやパスワードが外部に漏えいした可能性があることが公表されました。漏えいした可能性のある情報は最大1,422万件にのぼり、現在利用中のユーザーだけでなく、解約済みの顧客や一定期間利用のない休眠アカウントも含まれるとされています。

    今回の事案で注目すべきなのは、単に「メールアドレスとパスワードが漏えいした可能性がある」という点だけではありません。KDDIが提供するISP向けの共通メール基盤に不正アクセスが発生したことで、複数の事業者・複数のサービスに影響が広がった点が重要です。これは、現代の企業システムにおいて避けて通れない「外部委託先リスク」「サプライチェーンリスク」「共通基盤リスク」を象徴する事案といえます。

    本記事では、KDDIの公式発表および関係各社の公表情報をもとに、今回の不正アクセスの概要、影響範囲、利用者が取るべき対応、そして企業が学ぶべきセキュリティ対策について解説します。

    KDDIのISP向けメールシステムで何が起きたのか

    KDDIは、インターネットサービスプロバイダー、いわゆるISP事業者向けに提供しているメールシステムにおいて、不正アクセスを受けていたことを2026年6月17日に確認しました。KDDIの発表によると、不正アクセスの原因は、同システムで利用していた第三者製ソフトウェアの脆弱性を悪用されたことによるものです。

    KDDIは同日、被害拡大を防ぐためにシステムを改修し、不正アクセスの被疑箇所を特定したうえで、技術的な防御措置を実施したとしています。また、個人情報保護委員会や総務省への報告・相談を含む必要な対応も進めていると説明しています。

    現時点で公表されている漏えい可能性のある情報は、対象メールサービスで作成されたメールボックスに紐づくメールアドレスとパスワードです。件数は最大1,422万件とされており、この数字には解約済みの顧客や、一定期間利用していない休眠アカウントも含まれています。なお、パスワードの中には、ハッシュ化または暗号化されたものも含まれるとされています。

    ここで注意したいのは、最大1,422万件という数字が「実際に漏えいした件数」と確定したものではないという点です。KDDIは調査継続中であるため、現時点では漏えいした可能性のある最大値として公表されています。

    影響を受けるメールサービス

    今回の不正アクセスで対象とされているのは、KDDIがISP事業者向けに提供していたメールシステムを利用する複数のメールサービスです。KDDIの発表では、STNetのピカラ光サービス、ピカラモバイルサービス、お仕事ピカラサービスに係るメールサービス、KDDIウェブコミュニケーションズのレンタルサーバー「CPI」のメールサービス、JCOMのJ:COM NETおよびケーブルテレビ事業者向けメールサービス、中部テレコミュニケーションのコミュファ光・ビジネスコミュファのメールサービス、ニフティの@niftyメール、ビッグローブのBIGLOBEメールが対象として挙げられています。

    各社の発表を見ても、KDDIが提供する基盤システムを利用していたこと、第三者製ソフトウェアの脆弱性悪用によって不正アクセスが発生したこと、メールアドレスやメールパスワードなどが漏えいした可能性があることが説明されています。BIGLOBEでは、BIGLOBEメールアドレス、BIGLOBE IDおよびパスワードが漏えいした可能性があると公表しています。@niftyでは、メールアドレスおよびメールパスワードが第三者に漏えいした可能性があるとして、利用者にメールパスワードの変更を求めています。

    このように、ひとつの基盤システムに起きた不正アクセスが、複数ブランドの利用者に影響する形になっています。これは、クラウドサービス、外部委託システム、SaaS、共通認証基盤などを活用する多くの企業にとっても、決して他人事ではありません。

    なぜメールアドレスとパスワードの漏えいは危険なのか

    メールアドレスとパスワードの漏えいは、単なる連絡先情報の流出にとどまりません。メールアカウントは、多くのWebサービスや業務システムにおいて本人確認やパスワード再設定の起点として使われています。そのため、メールアカウントに不正ログインされると、他サービスへの侵入、なりすまし、フィッシングメールの送信、業務情報の閲覧など、被害が連鎖するおそれがあります。

    特に危険なのは、同じパスワードを複数のサービスで使い回しているケースです。攻撃者は、漏えいしたメールアドレスとパスワードの組み合わせを使い、別のWebサービスやクラウドサービスへのログインを試みることがあります。これは一般にパスワードリスト攻撃、またはクレデンシャルスタッフィングと呼ばれる手口です。

    今回の件では、対象情報にメールパスワードが含まれる可能性があるため、利用者は対象メールサービスのパスワードを変更するだけでなく、同じ、または似たパスワードを使用している他サービスについても見直す必要があります。メール、ECサイト、SNS、クラウドストレージ、業務用SaaSなどでパスワードを使い回している場合は、早急な変更が望まれます。

    利用者が今すぐ取るべき対応

    対象サービスを利用している可能性がある場合、まずは各ISP事業者やサービス提供会社の公式案内を確認することが重要です。検索結果やSNS上のリンクからではなく、公式サイト、公式サポートページ、契約時に案内された会員ページなどから確認することで、フィッシングサイトに誘導されるリスクを下げられます。

    次に、対象となるメールパスワードを変更します。@niftyのように、一定期限までに変更が確認できない場合、システム側でメールパスワードを順次無効化すると案内している事業者もあります。Outlook、Macメール、スマートフォンのメールアプリなどを利用している場合は、Web上でパスワードを変更した後、メールソフト側に保存されているパスワードも更新する必要があります。

    また、メールパスワードとログインパスワードを同じ文字列にしている場合や、他のサービスでも同じパスワードを使っている場合は、それらも変更すべきです。メールアカウントは、他サービスのパスワード再設定メールを受け取る重要な入口です。メールアカウントの安全性が崩れると、他のアカウントにも被害が広がる可能性があります。 加えて、しばらくの間は不審なメールへの警戒が必要です。今回の不正アクセスに便乗し、「パスワード変更が必要です」「アカウントを確認してください」などと称する偽メールが送られる可能性もあります。本文中のURLを安易にクリックせず、ブックマークや公式アプリ、公式サイトから手続きすることが大切です。

    「委託先だから安全」ではないという現実

    今回の事案は、企業のセキュリティ対策を考えるうえで重要な教訓を含んでいます。多くの企業は、自社の業務効率化やコスト削減、専門性の確保を目的に、メール基盤、クラウドサービス、決済システム、顧客管理システム、認証基盤などを外部サービスに委託しています。これは現代の事業運営では自然な選択です。

    しかし、外部サービスを利用しているからといって、リスクが自社から消えるわけではありません。委託先や共通基盤でインシデントが発生すれば、自社の顧客情報、業務データ、ブランド信頼にも影響が及びます。特に、複数の事業者が同じ基盤を利用している場合、一箇所の脆弱性が広範囲のサービスに波及する可能性があります。 企業に求められるのは、外部委託先を「便利なサービス提供者」として見るだけでなく、自社のセキュリティ境界の一部として管理する姿勢です。契約時のセキュリティ要件、脆弱性対応の体制、インシデント発生時の報告フロー、影響範囲の確認方法、利用者への通知方針などを事前に整理しておかなければ、実際に問題が起きた際の初動対応が遅れてしまいます。

    第三者製ソフトウェアの脆弱性はなぜ狙われるのか

    KDDIは今回の不正アクセスについて、第三者製ソフトウェアの脆弱性が悪用されたと説明しています。現時点でソフトウェア名やCVE番号などの詳細は公表されていませんが、一般論として、第三者製ソフトウェアの脆弱性は攻撃者にとって非常に狙いやすいポイントです。

    企業システムは、自社開発のプログラムだけで構成されているわけではありません。OS、ミドルウェア、メールサーバー、認証機能、管理画面、ライブラリ、監視ツールなど、さまざまな外部コンポーネントに支えられています。これらのどこかに脆弱性が存在し、修正が遅れれば、攻撃者に侵入口を与えることになります。 特に、インターネットからアクセス可能なシステムや、多数の顧客情報を扱う共通基盤では、脆弱性管理の遅れが大きなインシデントにつながりかねません。脆弱性情報を収集し、影響有無を確認し、必要なパッチ適用や回避策を迅速に実施する体制が不可欠です。

    企業が見直すべきセキュリティ対策

    今回のような不正アクセスや情報漏えいリスクに備えるには、単にパスワードを強化するだけでは不十分です。まず重要なのは、自社がどの外部サービスや委託先に、どのような情報を預けているのかを把握することです。顧客情報、メールアドレス、認証情報、業務データ、ログ情報など、預託している情報の種類と影響範囲を整理しておく必要があります。

    次に、委託先や利用サービスに対するセキュリティ確認を継続的に行うことが求められます。契約時だけでなく、運用中も脆弱性対応、インシデント報告体制、アクセス制御、ログ管理、バックアップ、暗号化、権限管理などの観点で確認を続けることが重要です。

    さらに、自社側でも認証情報の管理を強化する必要があります。多要素認証の導入、パスワード使い回しの禁止、不要アカウントの棚卸し、退職者や休眠アカウントの削除、権限の最小化などは、基本的でありながら効果の高い対策です。今回の件で解約済みや休眠アカウントも最大件数に含まれていることは、使われていないアカウントや古いデータの管理がいかに重要かを示しています。 最後に、インシデント発生時の対応手順を事前に整備しておくことも欠かせません。誰が影響範囲を確認し、誰が顧客へ通知し、どのタイミングで監督官庁へ報告し、どのように再発防止策を公表するのか。こうした手順が曖昧なままでは、被害の拡大だけでなく、顧客からの信頼低下にもつながります。

    メール漏えいではなくサプライチェーンリスクの問題

    今回のKDDIメールシステム不正アクセスは、メールアドレスとパスワードの漏えい可能性が注目されています。しかし、企業のセキュリティ担当者や経営層が本当に見るべきポイントは、その背後にある構造です。

    ひとつの共通基盤に脆弱性があり、そこを攻撃されることで、複数のISP事業者やメールサービスに影響が広がりました。これは、外部委託やクラウド利用が進む現在の企業環境において、どの企業にも起こり得る問題です。自社のシステムが直接攻撃されていなくても、委託先、取引先、共通基盤、利用中のSaaSで起きたインシデントが、自社の顧客対応や事業継続に影響する可能性があります。 セキュリティ対策は、もはや自社ネットワークの内側だけを守ればよい時代ではありません。外部サービスを含めた全体像を把握し、脆弱性管理、委託先管理、認証情報管理、インシデント対応を一体として整備することが求められます。

    まとめ

    KDDIのISP事業者向けメールシステムに対する不正アクセスでは、メールアドレスやパスワードが最大1,422万件漏えいした可能性があると公表されました。対象にはBIGLOBEメール、@niftyメール、J:COM NET、コミュファ光、ピカラ光、CPIなど複数のメールサービスが含まれており、共通基盤に起きた不正アクセスが広範囲に影響する構図となっています。

    利用者は、各事業者の公式案内を確認し、対象となるメールパスワードを速やかに変更することが重要です。同じパスワードを他サービスで使い回している場合は、あわせて変更し、不審なメールや偽のパスワード変更案内にも注意が必要です。

    企業にとっては、今回の事案を「大手通信会社の情報漏えい」として見るだけでは不十分です。第三者製ソフトウェアの脆弱性、外部委託先の管理、共通基盤への依存、休眠アカウントの扱い、インシデント発生時の連絡体制など、自社のセキュリティ運用を見直すきっかけにすべきです。 サイバー攻撃は、自社の真正面から来るとは限りません。取引先、委託先、クラウドサービス、共通基盤を経由して影響が及ぶ時代だからこそ、企業にはサプライチェーン全体を見据えたセキュリティ対策が求められています。

    【参考情報】

    編集責任：木下

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

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

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

  • 2026年7月1日（水）13:00～14:00「ランサムウェア対策は「侵入前提」で考える―最新事例から学ぶ、企業に求められるリスク把握と対策の考え方―」
  • 2026年7月8日（水）13:00～14:00「企業は何から対策すべきか？― OWASP Top 10:2025から読み解く、最新のセキュリティリスクと対策の考え方 ―」
  • 2026年7月15日（水）14:00～15:00「AI事業者ガイドライン第1.2版に基づくセキュリティ対策の実践ポイント～生成AIからAIエージェントへ～」
  • 2026年7月22日（水）14:00～15:00「そのIT資産、本当に把握できていますか？～見落としがちなセキュリティリスクと対策の第一歩～」

    • 最新情報はこちら

    Security 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サイトでの番号盗用によるものとされています*2。

    これらの事例から分かるのは、クレジットカード情報漏洩が例外的な事故ではなく、現実的には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に戻る

    投稿日:

    企業のセキュリティ成熟度 vol.1

    Share

    企業のセキュリティ成熟度チェック

    40項目で自社のセキュリティ対策状況を可視化
    優先的に取り組むべき課題を整理

    このようなお悩みはありませんか？

    • 自社のセキュリティ対策レベルがわからない
    • どこに課題があるかわからない
    • セキュリティ対策の状況を客観的に確認したい

    本資料では、40項目のチェックシートを通じて
    セキュリティ対策状況の可視化と改善優先度の整理を支援します。

    資料イメージ

    BBSecセキュリティ成熟度チェック_チェックの概要イメージ
    資料概要
    BBSecセキュリティ成熟度チェック_チェックシートイメージ
    40項目のチェックシート
    BBSecセキュリティ成熟度チェック_スコア判定と改善アクション
    スコア判定と改善アクション

    診断結果の次の一手をお考えの方へ

    vol.1「企業のセキュリティ成熟度チェック」で現状を把握した後は、結果に応じた対策の優先順位を整理することが重要です。vol.2「セキュリティ成熟度別ロードマップ」では、成熟度に応じて何から取り組むべきか、どのような順番で対策を進めるべきかを解説しています。チェック結果を具体的な改善アクションにつなげたい方は、ぜひあわせてご活用ください。

    セキュリティ成熟度別ロードマップページリンクボタン

    無料で資料をダウンロード

    企業のセキュリティ成熟度チェックがダウンロードできるURLをお送りいたします。
    ダウンロードご希望の方は下記の申し込みフォームからお申し込みください。

    関連サービス

    チェック結果を次のアクションにつなげませんか？

    チェック結果を踏まえ、優先的に取り組むべき対策や改善の進め方について
    専門家がご相談を承ります。自社に適した対策の整理にぜひご活用ください。

    Security NEWS TOPに戻る