2026年9月以降、会員向けWebサービスやスマホアプリ、ISPのメール基盤、政府の共通基盤などで、個人情報の漏洩公表が相次いでいます。「自社のシステムは大丈夫か」と経営層から確認を求められた担当者の方も多いのではないでしょうか。 ただ、今回の一連の事案は、ひとつの脆弱性やひとつの攻撃グループが原因ではありません。会員アプリのAPIやBIツールといった、コア業務以外の「脇のシステム」が複数の手口で狙われているため、従来の境界防御やウイルス対策だけでは全体像をつかみにくくなっています。
この記事では、JPCERT/CCが2026年10月に公表した注意喚起をもとに、攻撃の手口と攻撃者の特徴、海外の同時期事案との比較、そして72時間・30日・90日の時間軸で進める対策を整理します。
対象読者
- 企業の情報システム・セキュリティ担当者
- 公開システムやスマホアプリを運用する管理者
- 自社のセキュリティ対策を見直したい経営層
課題
- なぜ国内で情報漏洩が相次いでいるのか原因を知りたい
- 自社が同じ手口で侵害されていないか確認したい
- 今すぐ優先して実施すべき具体的な対策がわからない
この記事でわかること
- JPCERT/CCが示した4つの攻撃手口と侵入口の共通点
- 脅威アクターの目的と日本で被害が目立つ構造的要因
- 72時間・1週間・30日で進める緊急点検とASM等の抜本対策
2026年9〜10月、国内で何が起きたのか？
2026年9月から10月にかけて、国内のさまざまな組織から不正アクセスや情報漏洩に関する公表が短期間に集中しました。民間企業だけでなく公的機関のインフラでも事案が報告されたことで、自社のセキュリティ体制に不安を感じた担当者も少なくありません。この期間にどのような事案が公表され、専門機関がどう動いたのか、まずは事実関係を整理します。
会員サービス・ISP・政府基盤で情報漏洩の公表が相次いだ
2026年9月から10月には、会員サービスやISP（インターネットサービスプロバイダ）、政府基盤において情報漏洩の公表が相次いだのが大きな特徴です。特定の業界に偏ることなく、一般消費者向けのWebサービスから通信インフラ、行政関連のシステムまで幅広い領域で被害や侵害の疑いが報告されました。
公表された主な事案の領域と漏洩した可能性がある情報の種類、影響範囲は次のとおりです。
| 対象領域 | 主な被害システム | 漏洩した可能性がある情報 | 主な影響 |
|---|---|---|---|
| 会員サービス | ECサイト、ポイント管理システム、スマートフォンアプリ連携基盤 | 氏名、メールアドレス、電話番号、ハッシュ化されたパスワード、会員ID | なりすましログインの試行、フィッシングメールの増加、サービスの利用停止 |
| ISP（通信事業者） | 顧客管理データベース、認証サーバ、ネットワーク機器 | 契約者情報、接続ログの一部、管理用アカウントの認証情報 | 通信サービスの機能制限、契約者へのパスワード変更要請、二次被害への警戒 |
| 政府基盤・公的機関 | 外部公開用の情報共有サイト、業務委託先の管理システム | 職員および関係者のメールアドレス、業務連絡用の文書、システム設定情報 | 対象システムの緊急遮断、関係省庁や自治体での一斉点検の実施 |
これらの事案では、攻撃者が外部からアクセス可能なサーバやAPIの弱点を突き、内部のデータベースから認証情報や個人情報を窃取する動きが確認されています。決済情報であるクレジットカード番号そのものが漏洩したケースは限定的であったものの、ログインに悪用できる認証情報や個人情報が大量に流出した可能性があるとして、多くの組織がユーザーへの個別連絡と謝罪に追われました。
JPCERT/CC・IPAなどが相次いで注意喚起を出した
こうした被害公表の広がりを受け、JPCERT/CC（一般社団法人JPCERTコーディネーションセンター）やIPA（独立行政法人情報処理推進機構）などが相次いで注意喚起を出したことも、社会的な関心を高める要因となりました。
JPCERT/CCは、国内組織を狙った複数の攻撃パターンについて技術的な観測情報を公開し、システム管理者に対してログの確認や不審な通信の遮断を呼びかけました。また、IPAも公式Webサイトを通じて、公開サーバや周辺ツールの設定見直しと、既知の脆弱性に対する速やかなアップデートを強く促しています。
専門機関が同時期に複数の注意喚起を発信したのは、個別の事案の背後に共通する攻撃手法や悪用されやすいツールの存在が確認されたためです。放置すれば他の国内組織でも同様の被害が拡大する懸念があったことから、具体的な点検項目を伴う異例の呼びかけへとつながりました。
「攻撃が急増した」と「公表が集中した」は同じではない
短期間に報道が相次ぐと、その時期にサイバー攻撃が突発的に急増したように見えますが、「攻撃が急増した」と「公表が集中した」は同じではない点に注意が必要です。情報漏洩の公表時期と、実際に攻撃者がシステムへ侵入した時期には、数週間から数か月のタイムラグが存在するためです。
不正アクセスの発覚から公表に至るまでには、一般的に次のような手順を経る必要があります。
- 不審な通信やアラートの検知と対象システムのネットワーク遮断
- 外部の専門機関（フォレンジック調査会社など）によるログ解析と侵入経路の特定
- 漏洩したデータの範囲特定と対象となるユーザーや取引先の洗い出し
- 個人情報保護委員会や所管官庁への報告、および公表文書の準備
実際に2026年9月から10月に公表された事案の調査報告書を確認すると、最初の不正アクセスや侵害は2026年の春から夏にかけて発生していたケースが多く含まれています。また、JPCERT/CCなどの注意喚起を受けて自社システムを緊急点検した結果、過去の侵害が新たに発覚して公表に至った事例も少なくありません。
つまり、秋になって急に攻撃が始まったのではなく、それ以前から継続していた攻撃の被害調査が完了したタイミングや、一斉点検によって潜在的な被害が表面化したタイミングが重なったと見るのが妥当です。システム管理者は一時的な流行として捉えるのではなく、自社のシステムもすでに探索や攻撃の対象になっている可能性を前提として対策を進める必要があります。
なぜ今、情報漏洩が相次ぐのか？JPCERT/CCが示した4つの手口
なぜ今、情報漏洩が相次ぐのかという疑問に対し、一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）が示した4つの手口から技術的な背景がわかります。JPCERT/CCの公表情報によると、一連の事案ではゼロデイ攻撃のような未知の手法ではなく、既存の仕様や公開済みの弱点を突く攻撃が確認されています。
最初に、4つの手口における攻撃対象と発生事象を整理します。
| JPCERT/CCが示した手口 | 主な攻撃対象 | 引き起こされる事象 |
|---|---|---|
| 手口①既知の脆弱性の悪用 | VPN機器、メールサーバ、Webフレームワーク | 社内ネットワークへの侵入、認証情報の窃取 |
| 手口②管理用APIの不正操作 | スマートフォンアプリと通信するAPIサーバ | 全ユーザーの個人情報やアカウント情報の取得 |
| 手口③BIツール（Metabase）の悪用 | インターネットに公開されたデータ分析基盤 | 接続先データベースからの情報抽出、不正コマンド実行 |
| 手口④Webシェルの設置 | 外部公開されているアプリケーションサーバ | バックドアの維持、内部システムへの侵害拡大 |
手口①標的ごとに既知の脆弱性を探して悪用する
手口①の標的ごとに既知の脆弱性を探して悪用する手法は、公開サーバやネットワーク機器に残された未修正の弱点を狙う攻撃です。攻撃者はインターネット上に公開されているシステムのIPアドレスやドメインを走査し、稼働しているソフトウェアのバージョンを特定します。
バージョン情報から、すでにセキュリティパッチ（修正プログラム）が配布されている既知の脆弱性が放置されていると判断した場合、公開されている攻撃コードを悪用してシステムへ侵入します。特にVPN（仮想プライベートネットワーク）機器やWebアプリケーションフレームワークの脆弱性が狙われており、パッチ適用が遅れているシステムが標的として選別され、初期侵入を許しているのが実態です。
手口②スマホアプリを解析して管理用APIを不正に操作する
手口②のスマホアプリを解析して管理用APIを不正に操作する手法では、公式のアプリストアで配布されているスマートフォンアプリが起点となります。攻撃者はアプリを端末にダウンロードしたあと、リバースエンジニアリング（プログラムを逆コンパイルして構造を解析する手法）を実行します。
アプリ内部のコードに開発者がハードコード（直接記述）したAPIキーや、通常は一般ユーザーから見えない管理用APIの接続先URL（エンドポイント）を見つけ出すためです。抽出した認証情報を使うと、本来のアプリ画面を介さずにAPIサーバへ直接リクエストを送信できます。このとき、APIサーバ側でアクセス権限の検証や通信元の制限が不十分であると、正規の管理者になりすました通信によってデータベース内の会員情報が大量に抜き取られる結果につながります。
手口③BIツール（Metabase）の脆弱性を突く
手口③のBIツール（Metabase）の脆弱性を突く攻撃も、複数の企業で確認されています。BI（ビジネスインテリジェンス）ツールとは、社内に蓄積された膨大なデータを集約して分析し、グラフなどで可視化できるシステムです。オープンソースとしても提供されているMetabaseは、導入の手軽さから多くの企業で利用されています。
しかし、Metabaseをインターネットから直接アクセスできる状態で公開し、かつ過去に公表された脆弱性（CVE-2023-38646など）を修正せずに運用しているケースが散見されます。BIツールは業務の性質上、顧客情報や売上データが入ったデータベースと直接連携して動作します。そのため、脆弱性を突かれてMetabaseのサーバ上で任意のコードを実行されると、分析対象として接続されているデータベースから機密情報がそのまま外部へ流出する被害が発生します。
手口④アプリケーションサーバにWebシェルを設置する
手口④のアプリケーションサーバにWebシェルを設置する手法は、システムへの侵入を完了した攻撃者が、アクセス権限を長期的に維持するために用いる手口です。Webシェルとは、Webブラウザを通じて遠隔からサーバのOSコマンドを実行したり、ファイルを操作したりできる不正なプログラムを指します。
攻撃者は、ファイルアップロード機能のチェック不備やWebサーバの脆弱性を悪用し、通常の画像ファイルやスクリプトに偽装したWebシェルをサーバ内に配置します。一度Webシェルが設置されると、攻撃者は正規の認証プロセスを迂回し、暗号化された通常のWeb通信（HTTPS）に紛れてサーバを遠隔操作できるようになります。これにより、セキュリティ機器による検知を逃れながら、内部ネットワークの調査やデータベースからの情報窃取を継続することが可能になります。
共通点は、コア業務ではない「脇のシステム」が侵入口になっていること
これら4つの手口における共通点は、企業のコア業務を担う基幹システムではなく、周辺で稼働する「脇のシステム」が侵入口になっていることです。メインのWebサイトや基幹データベースにはWAF（Webアプリケーションファイアウォール）の導入や定期的な脆弱性診断を実施していても、利便性を優先して構築されたスマートフォンアプリ向けのAPIや、特定の部署が導入したBIツールまでは監視の目が行き届いていないケースが少なくありません。
攻撃者は防御が固い正面のシステムを避け、情報システム部門の管理から外れたシャドーITや、開発委託先が構築したまま保守が曖昧になっているサーバを探索しています。セキュリティ対策の優先度が下げられがちな周辺システムであっても、内部で顧客データベースと連携していれば、結果として大規模な情報漏洩に直結するという構造が、被害が相次ぐ技術的な要因です。
誰が攻撃しているのか？目的別に見る脅威アクター
相次ぐ不正アクセスや情報漏洩の背景には、誰が攻撃しているのかという視点で目的別に分類できる複数の脅威アクターが存在します。近年のサイバー攻撃は、単独の犯行ではなく、役割分担されたエコシステムとして機能しているのが特徴です。
主な脅威アクターの分類とそれぞれの特徴は、次の表からわかりやすく整理できます。
| 脅威アクターの分類 | 主な目的 | 主な標的 | 代表的な行動・手口 |
|---|---|---|---|
| 金銭目的のサイバー犯罪者・ランサムウェア集団 | 身代金の獲得、窃取データの売却 | 支払い能力のある民間企業、医療機関、自治体 | データの暗号化、多重脅迫、ダークウェブでの情報公開 |
| 国家支援型・サイバー諜報アクター | 機密情報の窃取、外交・軍事上の優位性確保 | 政府機関、重要インフラ事業者、防衛・先端技術関連企業 | 長期間の潜伏、証拠の隠滅、サプライチェーン攻撃 |
| アクセスブローカー・ボットネット運営者 | 初期侵入経路や計算資源の販売による収益化 | 脆弱な公開サーバ、認証情報が流出したシステム全般 | 認証情報の窃取、脆弱性スキャン、侵害したアクセス権の転売 |
金銭目的のサイバー犯罪者・ランサムウェア集団
金銭目的のサイバー犯罪者・ランサムウェア集団は、企業のシステムを停止させたり情報を盗み出したりすることで、直接的な金銭の要求を行うグループです。近年は、データを暗号化して復旧の対価を求めるだけでなく、盗み出した機密情報や個人情報を「支払わなければ公開する」と脅す二重脅迫の手口が主流になっています。
さらに、近年ではシステムを暗号化する手順を省き、データベースやAPIから大量の情報を直接窃取して脅迫のみを行う手口も増加しています。暗号化に伴う検知リスクを避けつつ、短時間で確実に金銭を奪うことが目的です。また、盗まれた顧客情報や認証情報は、ダークウェブ上の闇市場で他の犯罪者に転売されるため、一度の漏洩が二次被害につながりやすい構造となっています。
国家支援型・サイバー諜報アクター
国家支援型・サイバー諜報アクターは、特定の国家や政府機関の関与・支援を受け、安全保障や先端技術に関する機密情報の収集を目的として活動します。警察庁のサイバー空間をめぐる脅威の情勢などでも、こうした高度な技術を持つ集団による継続的な攻撃リスクが指摘されています。
金銭目的のグループが被害を意図的に発覚させて脅迫するのに対し、サイバー諜報アクターは侵入の事実を隠蔽し、数ヶ月から数年にわたって標的のネットワーク内に潜伏し続ける点が大きな違いです。検出が難しい正規の管理ツールを悪用したり、Webシェルを設置して通信を偽装したりしながら、外交機密や企業の研究開発データ、知的財産などを継続的に窃取します。本丸の組織へ侵入するための踏み台として、取引先や関連団体のシステムが狙われるケースも少なくありません。
アクセスブローカー・ボットネット運営者
アクセスブローカー・ボットネット運営者は、自ら最終的な情報窃取や脅迫を行うのではなく、企業ネットワークへの「侵入する権利」や「攻撃インフラ」を他の犯罪集団に提供して利益を得る存在です。特に初期アクセスブローカー（IAB）と呼ばれる犯罪者は、インターネット上に公開された機器の脆弱性や、流出したID・パスワードを悪用して企業内部への侵入口を確保し、そのアクセス権をランサムウェア集団などに売却します。
一方、ボットネット運営者は、マルウェアに感染させた多数の一般家庭のルーターや企業のサーバを遠隔操作し、攻撃者の通信元を隠すための中継ネットワークを構築します。このように、初期侵入を担うアクセスブローカーと、実行部隊である攻撃グループが分業化しているため、自社の公開資産に放置されたわずかな隙が、すぐさま大規模な情報漏洩へと直結する状況が生まれています。
生成AIが攻撃の敷居を下げている
生成AI（人工知能）が攻撃の敷居を下げていることも、多様な脅威アクターの活動を活発化させる要因となっています。従来、日本国内の組織を標的とする場合、日本語特有の自然な表現を用いたフィッシングメールの作成や、国内独自のシステム仕様の理解には一定の労力が必要でした。しかし現在では、生成AI（人工知能）を用いることで、不自然さのない巧妙な日本語の標的型メールや偽サイトを短時間で大量に生成できます。
また、公開されている脆弱性情報をもとに攻撃コードを自動生成させたり、スマートフォンアプリの通信仕様やAPIの構造を効率的に解析させたりする補助ツールとしても悪用されています。これにより、高度な専門知識を持たない犯罪者でも、熟練した攻撃者と同等の手法を実行できるようになり、結果として国内企業が直面する攻撃の総量と精度がともに高まっているのが実態です。
日本だけが狙われているのか？同時期の海外事案との比較
日本国内で情報漏洩の公表が相次いでいる状況を見ると、日本だけが集中的にサイバー攻撃の標的になっているのではないかという疑問が生じます。しかし、同時期の海外におけるセキュリティ事案と比較すると、攻撃者が日本固有の組織だけを狙い撃ちにしているわけではなく、世界規模の攻撃キャンペーンの一環として日本の組織も被害を受けている実態がわかります。
海外でも同時期に政府・金融・ITサービスへの大規模な攻撃が起きている
海外でも同時期に、政府機関や金融機関、ITサービスへの大規模な攻撃が起きています。攻撃者は国境を意識せず、インターネット上に公開されているシステムの脆弱性や認証の不備を機械的に探索しているためです。
例えば、CISA（米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁）が公開している悪用が確認された脆弱性カタログには、世界中で悪用されているネットワーク機器やソフトウェアの脆弱性が日々追加されています。米国の自治体や医療機関、欧州の金融機関、アジア圏の通信事業者などでも、日本と同様にVPN（仮想プライベートネットワーク）機器の脆弱性や、クラウドストレージの設定不備、API（アプリケーション・プログラミング・インターフェース）の認証漏れを突かれた大規模な情報漏洩が多数報告されています。
特に、複数の企業にシステムを提供するITサービスやSaaS（サービスとしてのソフトウェア）事業者が侵害を受け、そこを起点として利用企業へと被害が連鎖するサプライチェーン攻撃は、欧米を中心に深刻な被害をもたらしています。
「日本が突出している」とは言い切れない理由
報道ベースでは国内の事案が目立つものの、客観的なデータや攻撃の仕組みから見ると、「日本が突出している」とは言い切れない理由が3つあります。
第一に、攻撃者の初期侵入プロセスが自動化されている点です。攻撃者は特定の国を狙う前に、まずは世界中のIPアドレスを無差別にスキャンし、パッチ（修正プログラム）が適用されていないシステムをリストアップします。つまり、脆弱性を放置している組織があれば、日本か海外かを問わず等しく攻撃対象となるのが実態です。
第二に、法制度による公表件数の可視化が進んだ点です。日本では2022年4月に改正個人情報保護法が施行され、個人の権利利益を害するおそれがある漏洩等が発生した場合、個人情報保護委員会への報告および本人への通知が義務化されました。この制度変更に伴い、これまで内々に処理されていた事案や小規模な不正アクセスも公式に発表されるようになったため、表面化する件数が増加している側面があります。
第三に、国内メディアの報道特性です。日本国内のニュースでは、当然ながら日本の消費者や企業に直接影響する国内企業の事案が優先して報じられます。海外の中堅企業や地方自治体で同規模の情報漏洩が起きていても日本国内ではほとんど報道されないため、相対的に日本の被害ばかりが目立って見えるという情報の偏りが生じています。
それでも日本で被害が目立つ3つの構造的要因
世界中で同じように攻撃が行われているにもかかわらず、結果として日本企業での被害が成立しやすく、深刻化しやすい背景には、日本で被害が目立つ3つの構造的要因が存在します。日本と欧米諸国のセキュリティ体制における主な違いは、以下の通りです。
| 比較項目 | 日本企業に多い傾向 | 欧米企業に多い傾向 |
|---|---|---|
| システム開発・運用体制 | 外部の委託先（SIerなど）への依存度が高く、発注元が資産を把握しきれていない | 内製化比率が高く、自社のエンジニアがシステム構成や設定を直接管理している |
| レガシーシステムの有無 | 古いシステムをカスタマイズして長期利用し、複雑な構造のまま残存している | 標準化されたクラウドサービスへの移行が早く、古い環境は比較的早期に廃棄される |
| セキュリティ投資の対象 | 境界防御（ウイルス対策やファイアウォールなど）の導入にとどまりやすい | 公開資産の継続的な把握や、侵入を前提とした検知・対応（EDR/SOCなど）に投資している |
1つ目の要因は、多重下請け構造と外部委託への過度な依存です。IPA（情報処理推進機構）の調査などでも指摘されている通り、日本のIT開発は外部のシステムインテグレーターや制作会社に委託する割合が高い傾向にあります。その結果、過去のキャンペーンサイトや検証用サーバ、外部委託先が独自に導入した管理ツールなど、発注元の企業が把握していない「シャドーIT」が生まれやすくなります。管理者が不在となったシステムはセキュリティ更新が止まり、攻撃者にとって格好の侵入口となります。
2つ目の要因は、レガシーシステムの残存と改修の遅れです。長年にわたり独自カスタマイズを重ねた古いシステムを使い続けている企業が多く、システム構造がブラックボックス化しています。そのため、脆弱性が発見されても業務への影響を懸念して即座にパッチを適用できず、攻撃者に悪用されるまでの時間的猶予を与えてしまうケースが少なくありません。
3つ目の要因は、セキュリティ人材の不足と防御体制の遅れです。セキュリティ担当者が専任ではなく兼任であったり、対策が社内ネットワークの入り口を守る境界防御に偏っていたりする組織がいまだに多く見られます。インターネット上に公開されている自社のIT資産を攻撃者視点で常時監視する仕組みが整っていないため、設定ミスや脆弱性の放置に自ら気づくことができないという構造的な弱点を抱えています。
政府・企業・ISPで異なるリスクと優先すべき対策
政府・企業・ISPで異なるリスクと優先すべき対策は、それぞれの組織が保有する情報資産の性質や、社会インフラとしての役割によって決まります。近年のサイバー攻撃では共通の技術的脆弱性が悪用されているものの、攻撃者が最終的な標的として狙うデータやシステム停止による影響範囲は組織の種別ごとに異なるため、自組織の特性に合わせた防御の優先順位付けが欠かせません。
| 組織の種別 | 主な保有資産と狙われる対象 | 侵害時の主なリスク | 最優先で取り組むべき対策 |
|---|---|---|---|
| 政府機関・自治体 | 住民基本台帳データ、税務情報、機密性の高い政策文書、委託先との共有システム | 行政サービスの停止、国家安全保障上の脅威、公的機関に対する信頼の失墜 | 外部委託先を含めたサプライチェーン全体の統制と、ネットワーク分離環境におけるデータ連携経路の監視 |
| 一般企業（会員サービス等） | 顧客の個人情報、決済データ、認証情報（ID/パスワード）、営業秘密・技術情報 | 金銭的被害の発生、個人情報保護法に基づく行政処分、損害賠償請求や顧客離れ | WebアプリケーションやAPIのアクセス制御強化と、外部公開資産の継続的な棚卸し |
| ISP・通信事業者 | 通信ログ、契約者情報、ネットワーク機器（ルーター等）の管理権限、認証基盤 | 広範な通信障害、契約者情報の大量流出、他組織への攻撃の踏み台化 | ネットワーク機器や管理インターフェースの厳格なアクセス制限と、特権IDの保護 |
政府機関・自治体におけるリスクと優先対策
政府機関・自治体における最大のリスクは、機密情報の窃取による安全保障上の脅威や、行政サービスの長期停止による市民生活への影響です。政府機関・自治体では、基幹系システムとインターネット接続系システムを分割するネットワーク分離が導入されていますが、業務委託先のシステムやファイル無害化装置、外部とのデータ受け渡しに用いるオンラインストレージなどが侵入経路として狙われる傾向にあります。
そのため、庁内ネットワークの防御だけでなく、業務を委託している外部事業者を含めたサプライチェーン全体のセキュリティ統制を最優先で進める必要があります。具体的には、内閣サイバーセキュリティセンター（NISC）が定める政府機関等のサイバーセキュリティ対策のための統一基準群や、総務省の「地方公共団体における情報セキュリティポリシーに関するガイドライン」に基づき、委託先が管理する開発環境や保守用回線のアクセス権限を定期的に点検することが求められます。また、パブリッククラウドの利用拡大に伴い、設定不備による情報公開を防ぐための構成管理の徹底も不可欠です。
一般企業（会員サービス運営等）におけるリスクと優先対策
一般企業、特に消費者向けの会員サービスやECサイトを運営する企業においては、顧客の個人情報や決済情報、ログイン用の認証情報の大量流出が直接的な事業リスクとなります。攻撃者は盗み出した情報をダークウェブで売買するだけでなく、他社サービスへの不正ログインを試みるリスト型攻撃に悪用するため、被害が自社にとどまらず社会全体へ波及する恐れがあります。
一般企業が優先すべき対策は、顧客との接点となるスマートフォンアプリやWebサイトの背後に存在するAPI、およびマーケティング目的で部門独自に導入されたBIツールなどの管理徹底です。個人情報保護委員会が示す個人情報の保護に関する法律についてのガイドラインで求められる安全管理措置を確実に履行するためにも、開発検証用のサーバーや旧バージョンのAPIがインターネット上に放置されていないかを洗い出し、不要な公開資産を速やかに停止することが重要です。あわせて、万が一侵入された場合でもデータベースから一括で情報を抜き取られないよう、通信の監視とデータの暗号化、およびAPIごとの厳密な認可制御を実装する必要があります。
ISP・通信事業者におけるリスクと優先対策
ISP（インターネットサービスプロバイダ）や通信事業者は、多数の企業や個人の通信を中継する社会インフラであり、攻撃者にとって極めて価値の高い標的です。契約者の個人情報や決済情報だけでなく、通信の秘密に関わる接続ログや、ネットワーク機器そのものの管理権限が狙われます。ISPのシステムが侵害されると、大規模な通信障害を引き起こすだけでなく、改ざんされた機器が他の企業や政府機関を攻撃するための踏み台として悪用される危険性があります。
ISP・通信事業者が最優先で実施すべき対策は、境界防御を担うネットワーク機器や仮想化基盤、および顧客管理システムの管理インターフェースに対するアクセス制限の強化です。総務省が策定している電気通信事業におけるサイバーセキュリティ対策指針を踏まえ、保守用の管理画面をインターネットから直接アクセスできないよう閉域網内に隔離し、多要素認証を必須とする運用が求められます。さらに、長期間にわたりシステム内部に潜伏する高度な攻撃に対処するため、管理者権限（特権ID）の操作ログをリアルタイムで監視し、不審な設定変更や認証情報の窃取の兆候を早期に検知できる体制を整えることが不可欠です。
まず何をすべきか？72時間・1週間・30日で進める緊急対策
他社での被害公表や注意喚起が相次いでいる状況では、まず何から着手すべきかを整理し、72時間・1週間・30日の時間軸に分けて緊急対策を進める必要があります。手当たり次第に作業を始めるのではなく、攻撃者に悪用されやすい外部の侵入口を塞ぐ作業から優先順位をつけて実行することが被害を防ぐ鍵となります。
| 期間 | 優先すべき到達目標 | 主な対象システム・領域 | 具体的なアクション |
|---|---|---|---|
| 最初の72時間 | 既知の侵入口と不審な挙動の即時把握 | VPN機器、BIツール、スマホアプリ、特権ID | バージョン確認、不要な特権IDの停止、APIキーのローテーション、ファイル改ざん確認 |
| 1週間以内 | 攻撃対象領域の縮小と認証の厳格化 | 管理画面、管理用API、リモートアクセス環境 | IPアドレス制限の実装、MFA（多要素認証）の適用、オブジェクト単位の認可制御の修正 |
| 30日以内 | 潜在的な脆弱性の排除と侵入痕跡の特定 | 外部公開サーバ全般、各種ログ（FW/WAF/認証） | 設定不備の解消、複数ログの突き合わせによる異常検知、インシデント対応手順の見直し |
最初の72時間：公開資産・特権ID・APIキーを緊急点検する
最初の72時間では、攻撃者が最初の足がかりとして悪用する公開資産や特権ID、APIキーを緊急点検します。一般社団法人JPCERTコーディネーションセンターの注意喚起でも指摘されている通り、管理部門が把握しきれていない周辺システムや、アプリ内に埋め込まれた認証情報が狙われているためです。
情報システム部門および開発部門は、以下の点検作業を直ちに実施します。
- インターネットに公開されているサーバ、VPN機器、およびMetabaseなどのBIツールのバージョンを確認し、既知の脆弱性が放置されていないか照合する
- 休眠状態の管理者アカウントや、開発・検証時に一時的に作成した特権IDを特定し、即座に無効化または削除する
- 提供しているスマートフォンアプリのプログラムコードや設定ファイル内に、管理用APIへアクセスするためのAPIキーや認証トークンが平文で埋め込まれていないか確認する
- ハードコードされたAPIキーが見つかった場合は直ちに無効化し、新しいキーへの再発行（ローテーション）とサーバ側での適切な管理へ切り替える
- 公開Webサーバやアプリケーションサーバの特定のディレクトリに、見覚えのない不審なスクリプトファイル（Webシェル）が設置されていないか、更新日時やファイル名から確認する
これらの点検により、攻撃者が即座に悪用可能な侵入口が自社の環境に存在するかどうかを3日以内に把握できます。
1週間以内：公開範囲を絞り込み、APIと認証を強化する
緊急点検に続く1週間以内には、外部への公開範囲を最小限に絞り込み、APIと認証の仕組みを強化します。インターネットから誰でも管理機能や裏側のシステムにアクセスできる状態を解消することで、不正アクセスの試行そのものを遮断できるためです。
ネットワーク管理者およびアプリケーション開発者は、点検結果をもとに以下の設定変更と改修を行います。
- BIツールやCMS（コンテンツ管理システム）などの管理画面をインターネットの直接公開から外し、社内ネットワークやVPN経由、あるいは特定の送信元IPアドレスからのみアクセスできるように制限する
- 外部からアクセス可能なすべての管理画面およびリモートアクセス環境において、IDとパスワードだけでなくMFA（多要素認証）を必須化する
- スマートフォンアプリなどが通信するAPIにおいて、正規の通信であってもリクエスト内のユーザーID等を書き換えることで他人のデータを取得できてしまう不備（オブジェクトレベルの認可制御の欠如）がないか検証し、アクセス権限のチェック処理を実装する
- WAF（Web Application Firewall）やゲートウェイの設定を見直し、管理用APIに対する異常な頻度のリクエストや、不審なパラメータを含む通信を遮断するルールを適用する
この段階を完了させることで、万が一認証情報の一部が外部に漏れていたとしても、攻撃者がシステム内部へ侵入したりデータを不正に取得したりする経路を遮断できます。
30日以内：脆弱性診断とログの突き合わせで再発を防ぐ
対策開始から30日以内には、対象を外部公開システム全体に広げて脆弱性診断を実施し、各種ログの突き合わせによって再発を防ぐ体制を整えます。初期の緊急対応だけでは見落とされがちな設定不備を洗い出し、すでに攻撃の試行や侵入が行われていなかったかを過去に遡って確認する必要があるためです。
セキュリティ担当者およびシステム管理者は、以下の調査と対策を実施します。
- 検証環境や一時的なキャンペーンサイトなど、メインの業務システム以外のサーバも含めて脆弱性診断を実施し、OSやミドルウェアのパッチ未適用および設定不備を解消する
- ファイアウォール、WAF、Webサーバ、認証サーバ、およびデータベースのログを収集し、不審なIPアドレスからのアクセス試行と、その直後の内部通信や大量のデータ抽出といった挙動を突き合わせて分析する
- 深夜帯の不自然な管理者ログインや、通常業務では発生しない大量のAPIコールなど、侵害の兆候を示すアラート条件を監視システムに定義する
複数箇所のログを相関的に確認することで、単一のログでは見抜けないステルス性の高い不正アクセスを検知し、同様の手口による被害の拡大を防止できます。
侵害の疑いがあるなら「パッチ適用だけ」で終わらせてはいけない
点検やログ調査の過程で少しでも侵害の疑いが浮上した場合、脆弱性へのパッチ適用だけで対応を終わらせてはいけません。脆弱性を塞ぐ前にすでに攻撃者がシステム内部へ侵入していた場合、サーバ内に設置されたWebシェルや不正に作成された正規アカウントが裏口（バックドア）として残り続け、パッチ適用後も素通りで不正アクセスが継続するためです。
不審なファイルの存在や見覚えのない通信ログを確認した際は、直ちにインシデント対応へ移行する必要があります。独立行政法人情報処理推進機構（IPA）が公開しているインシデント対応の解説でも示されている通り、被害の拡大を防ぐためにはネットワークからの隔離や証拠保全といった初動対応が不可欠です。
具体的には、該当するサーバをネットワークから切り離したうえで、メモリやディスクの情報を保全し、フォレンジック調査によって「いつ、どこから侵入され、どの範囲のデータにアクセスされたか」を特定します。そのうえで、すべての認証情報の強制リセットと、バックドアが完全に排除されたクリーンな環境でのシステム再構築を行うことで、再侵入のリスクを根本から断ち切ることができます。
抜本対策：攻撃されることを前提にした継続的なリスク管理へ
緊急対策で当面の侵入口を塞いだ後は、抜本対策として攻撃されることを前提にした継続的なリスク管理へ移行する必要があります。システム構成や脅威は日々変化するため、一度の点検で安全性を維持することは困難だからです。外部からの見え方の管理、認証の厳格化、データ保護、監視体制の統合を順番に進めることで、侵入を許しても被害を最小限に抑える体制を構築できます。
ASM・CTEMで外部公開資産を継続的に把握する
ASM（Attack Surface Management）やCTEM（Continuous Threat Exposure Management）の考え方を取り入れ、外部公開資産を継続的に把握する仕組みを整えます。情報システム部門が把握していないサーバやクラウド環境が放置されると、そこが攻撃の起点になるためです。経済産業省が公表している「ASM（Attack Surface Management）導入ガイダンス」でも、攻撃者視点で外部からアクセス可能なIT資産を継続的に検出・評価することの重要性が示されています。
具体的には、ASMツールを用いてインターネットに公開されているIPアドレス、ドメイン、SSL証明書などを自動で探索し、資産台帳と照合できる環境を作ります。さらにCTEMの枠組みを組み合わせることで、発見した脆弱性や設定不備のすべてを闇雲に修正するのではなく、事業への影響度や攻撃のされやすさに基づいて対応の優先順位を判断できます。
ゼロトラストとID中心の防御に切り替える
ネットワークの内外で安全性を区別する従来の境界型防御から、ゼロトラストとID中心の防御に切り替えることが不可欠です。正規の認証情報を窃取して侵入する手口や、管理外の端末を経由したアクセスに対しては、ファイアウォールなどの境界防御だけでは対処しきれないのが理由です。
すべての通信やアクセスを信頼せず、アクセスごとに「誰が」「どの端末から」「どのデータに」触れるのかを検証します。その中核となるのがID管理（IAM）の統合と特権ID管理（PAM）の徹底です。
- 従業員や業務委託先のアカウントを一元管理し、退職や異動に伴う不要なアカウントを即座に停止できます
- ログイン時の場所、時間帯、端末のセキュリティ状態に応じてアクセス制限や追加認証を動的に要求できます
- サーバやクラウドの管理権限を持つ特権IDに対して、申請・承認フローと操作ログの記録を強制できます
このようにIDを中心としてアクセス制御を厳格化することで、万が一認証情報が漏洩しても、攻撃者が社内ネットワークを自由に移動して被害を拡大させるのを防げます。
APIとデータベースへのアクセスを監視し、「盗られる情報」を減らす
APIとデータベースへのアクセスを監視し、万が一侵入された場合に「盗られる情報」を減らす対策を講じます。外部向けのアプリケーションやAPIの仕様の隙を突かれた場合、認証を突破されて直接データベースから大量の個人情報を引き出される危険があるからです。
まず、APIゲートウェイやWAF（Web Application Firewall）を導入し、APIの通信を可視化します。これにより、短時間での大量リクエストや、通常の画面操作では発生しないパラメータの改ざんを検知して遮断できます。また、API応答時に必要なデータ項目だけを返すように設計を見直し、過剰なデータ露出を防ぐことも重要です。
データベース側では、保存データの暗号化やトークン化（無意味な文字列への置き換え）を実施します。業務上参照する必要のない機密データをあらかじめ分離または削除しておけば、攻撃者がデータベースに到達しても、価値のある情報を持ち出せない状態を作れます。
脅威インテリジェンスとSOC運用を統合し、対応を速める
脅威インテリジェンスとSOC（Security Operation Center）運用を統合し、異常の検知から封じ込めまでの対応を速める体制を構築します。個別のセキュリティ機器が出すアラートを別々に確認していては、攻撃の全体像を把握するまでに時間がかかり、情報漏洩を許してしまうためです。
エンドポイントの挙動を監視するEDR、ネットワーク機器のログ、クラウドの監査ログなどをSIEM（Security Information and Event Management）に集約し、相関分析を行います。そこに、国内外の公的機関やセキュリティ企業が提供する脅威インテリジェンス（攻撃者が使用するIPアドレスや悪用中の脆弱性情報など）を掛け合わせます。自社の環境に照らし合わせて今まさに狙われている箇所を特定できるため、SOCの担当者は重大なインシデントの兆候をいち早く見つけ出し、端末の隔離や通信遮断を迅速に実行できます。
90日で何を変えるか：4フェーズの実行計画
ここまでに挙げた抜本対策を一度にすべて実装するのは現実的ではないため、90日で何を変えるかを明確にした4フェーズの実行計画に落とし込んで進めます。緊急度の高い領域から段階的に着手することで、現場の運用負荷を抑えながら着実にリスクを低減できるためです。
| フェーズ（期間） | 主な達成目標 | 具体的な実施項目 | 主な担当部門 |
|---|---|---|---|
| フェーズ1（1〜15日目） | 継続的な資産把握と監視設計の開始 | ASMツールの選定・試行による公開資産の自動洗い出し、重要ログの保管期間延長と集約先の決定 | 情報システム部門、セキュリティ推進室 |
| フェーズ2（16〜45日目） | ID管理の統合と特権アクセスの統制 | SSO（シングルサインオン）と多要素認証の全社適用、特権IDの棚卸しと利用申請フローのシステム化 | 情報システム部門、人事・総務部門 |
| フェーズ3（46〜75日目） | API・データ保護の強化 | 公開APIの仕様点検とレート制限の実装、データベースのアクセス権限見直しと不要データの削除・暗号化 | システム開発部門、インフラ管理部門 |
| フェーズ4（76〜90日目） | 検知・対応プロセスの統合と訓練 | SIEM/SOCでの相関分析ルールの適用、脅威インテリジェンスの取り込み自動化、インシデント対応手順の机上訓練 | セキュリティ推進室、外部SOC事業者、経営層 |
この計画を進める際は、情報システム部門だけでなく、外部公開サービスを 기획・開発する事業部門や経営層を巻き込むことが不可欠です。各フェーズの完了時に残存リスクを経営層へ報告し、予算や人員の再配分を継続的に見直すサイクルを定着させることが、情報漏洩を未然に防ぐ基盤となります。
何から始めるべきか迷ったら：攻撃者から見える弱点の可視化から
何から始めるべきか迷ったら、まずは攻撃者から見える弱点の可視化から着手することが効果的です。これまで解説した緊急対策や抜本対策は項目が多く、専任のセキュリティ担当者が不在の企業では、優先順位の判断に迷うケースが少なくありません。
その場合、自社のネットワーク内部から調査を始めるのではなく、インターネット上に公開されている自社のIT資産が「外部の攻撃者からどのように見えているか」を客観的に把握することから始めます。攻撃者は社内システム全体を最初から把握しているわけではなく、外部に公開されたサーバーやアプリケーションの隙を突いて侵入するためです。
社内にある管理台帳ベースでの点検と、攻撃者視点での可視化には、次のような違いがあります。
| 比較項目 | 社内台帳ベースでの点検 | 攻撃者視点での可視化（外部からの調査） |
|---|---|---|
| 調査の起点 | 情シス部門が把握している既存の管理リスト | インターネット上に公開されているIPアドレスやドメイン |
| 発見できる対象 | 正式な手順で申請・構築されたシステム | 管理外のクラウド環境、放置された検証用サーバー、設定不備のAPI |
| 主な限界と強み | 台帳に未記載の「脇のシステム」は点検から漏れる | 台帳の有無にかかわらず、攻撃者が実際に狙える侵入口を網羅的に把握できる |
相次ぐ情報漏洩の多くは、管理部門が把握しきれていない「脇のシステム」が起点となっています。したがって、まずは外部からアクセス可能な状態を洗い出し、攻撃の足がかりとなる弱点を特定することが、最小の労力で最大のリスク低減につながります。
具体的には、次の3つのステップで攻撃者から見える弱点を可視化します。
- グローバルIPアドレスとドメインの棚卸しによって、自社が保有する外部公開資産のリストを作成する
- 外部公開資産に対してポートスキャンや設定確認を実施し、不要な通信ポートの開放や管理画面の露出を特定する
- 検出されたシステムに既知の脆弱性が残っていないか、OSやミドルウェアのバージョン情報から照合する
自社だけでこれらの調査を行うことが難しい場合は、独立行政法人情報処理推進機構（IPA）が公開している中小企業向けセキュリティ対策情報などの公的ガイドラインを参考にしながら、外部の専門会社が提供する診断サービスやASM（Attack Surface Management）ツールのトライアルを活用する方法も有効です。また、経済産業省が策定したASM導入ガイダンスでも、外部から見える資産を把握することの重要性と具体的な手順が示されています。
攻撃者と同じ目線で自社の公開資産を点検できれば、緊急で塞ぐべき穴が明確になります。対策の第一歩として、まずは外部に露出している弱点の可視化から取り組んでみてください。
よくある質問（FAQ）
最近、日本で情報漏洩が相次いでいるのはなぜですか？
最近、日本で情報漏洩が相次いでいる主な理由は、メインシステムに比べて管理が手薄になりやすい周辺システムやAPIの脆弱性が狙われていることと、法令改正などに伴い企業の公表事例が短期間に集中したことの2点にあります。
攻撃者は、防御が固い基幹システムを直接狙うのではなく、管理用のAPIやBIツール、古い検証用サーバといった「脇のシステム」を探索して侵入経路に悪用しています。また、個人情報保護法の改正によって漏洩時の報告義務が厳格化されており、被害の調査を終えた複数の組織が同じ時期に発表を行ったことも、世間一般で「被害が相次いでいる」と強く認識される要因となっています。
JPCERT/CCの注意喚起に載っているIPアドレスが自社のログにあったら、侵害されたということですか？
一般社団法人JPCERTコーディネーションセンター（JPCERT/CC）の注意喚起に記載されているIPアドレスが自社の通信ログから見つかった場合でも、それだけでシステムが侵害されたと断定することはできません。なぜなら、攻撃者は侵入前の事前調査として、インターネット上に公開されている無数のサーバへ機械的な探索通信（スキャン）を行っているケースが多いためです。
ログに該当のIPアドレスが記録されていた場合は、通信の「結果」と「その後の挙動」を確認して被害の有無を判断する必要があります。具体的な確認ポイントは次の表のとおりです。
| ログで確認された事象 | 想定される状態 | 優先して実施すべき対応 |
|---|---|---|
| 該当IPアドレスからのアクセスに対し、すべてエラー（ステータスコード403や404など）を返している | 脆弱性の探索（スキャン）を受けたが、防御に成功している状態 | 監視の継続、および該当システムに未適用のセキュリティパッチがないかの再確認 |
| 該当IPアドレスからのアクセスに対し、正常応答（ステータスコード200など）を返し、不審なパラメータ送信がある | 脆弱性を悪用した攻撃が成立し、侵入を許した可能性がある状態 | 該当システムのネットワーク隔離、Webシェルの有無の確認、特権IDや認証情報の変更 |
| 自社サーバから該当IPアドレスへ向けて、外向きの通信が発生している | マルウェアやWebシェルが設置され、外部の攻撃者サーバと通信している状態 | 直ちにネットワークから遮断し、専門の調査会社やCSIRTによるフォレンジック調査を実施 |
一般公開していない社内向けのシステムやAPIでも狙われますか？
一般公開していない社内向けのシステムやAPIであっても、インターネットから到達可能な状態になっていれば攻撃の標的になります。Webサイトのリンクに掲載していなくても、攻撃者はIPアドレスの総当たり調査や、配布されているスマートフォンアプリの通信解析などを通じて、隠れた接続先を見つけ出すことができるためです。
たとえば、開発環境やテスト用のAPI、社内限定のつもりで立ち上げた分析ツールなどに適切なアクセス制限（IPアドレス制限やVPN経由のみの接続許可など）が設定されていない場合、外部から直接操作されてしまいます。「URLを知られなければ安全」と考えるのではなく、インターネットに面しているすべての資産は攻撃者に発見される前提で認証とアクセス制御を実装することが不可欠です 。
日本は海外よりもサイバー攻撃を受けやすいのですか？
日本が海外と比較して特別にサイバー攻撃を受けやすいという事実はなく、欧米やアジア諸国でも同規模の被害が日常的に発生しています。それにもかかわらず日本で被害が目立つ背景には、生成AI（人工知能）の普及によって日本語の壁がなくなったことと、サプライチェーンや外部委託先を含めたIT資産の管理が複雑化していることがあります。
かつては日本語という言語の特殊性が、海外の攻撃者に対する一定の防壁として機能していました。しかし現在は、生成AIを用いることで自然な日本語のフィッシングメール作成や、日本語仕様のシステム解析が容易に行えます。また、外部のクラウドサービスや業務委託先が保有するシステムが増えた結果、自社の目が届かない場所にある脆弱性を突かれるケースが国内で顕在化しています。
中小企業がまず取り組むべき対策は何ですか？
予算や専任の人材が限られる中小企業がまず取り組むべき対策は、新たなセキュリティツールを導入することではなく、現在インターネットに公開されている機器やシステムの設定を見直すことです。独立行政法人情報処理推進機構（IPA）が公開している中小企業向けのガイドラインなどでも、基本的な管理の徹底が最優先事項として挙げられています。
具体的には、費用をかけずに今日から実行できる以下の4つの対策から着手してください。
- インターネットに接続されているVPN機器、ルーター、公開サーバのソフトウェアを最新の状態に更新する
- 外部からアクセスできる管理画面やリモート接続には、必ず多要素認証（MFA）を設定する
- 初期設定のまま使われているIDやパスワードを変更し、推測されにくい複雑な文字列に置き換える
- 現在使用していない古いWebサイト、キャンペーン用ページ、検証用システムを停止または撤去する
これらを実施するだけでも、既知の脆弱性や認証の不備を狙う大半の自動化された攻撃から自社を守ることができます。
まとめ
国内で相次ぐ情報漏洩の多くは、管理が手薄になりがちな周辺システムやAPI、BIツールの既知の脆弱性が侵入口となっています。生成AIの悪用などで攻撃のハードルが下がる中、パッチ適用のみの対症療法では不十分です。
企業や組織のセキュリティ担当者は、まず72時間以内に外部公開資産や特権ID、APIキーを緊急点検し、不要な公開範囲を絞り込む必要があります。その上で、攻撃されることを前提としたASM（外部公開資産の継続的な把握）やゼロトラストを導入し、組織全体の防御体制を継続的なリスク管理へと移行させることが重要です。
