すごい情報量。まだ斜め読みなので、あとでもう一回読もう / 国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた - piyolog - https://piyolog.hatenadiary.jp/entry/2026/10/11/004353 「特定の脆弱性だけを探すのではなく、サイトやAPIの不備を広く探る動きが見えてきている」…この辺が従来からバージョンアップしているみたい #fedibird
国内で相次ぐ不正アクセスに対する注意喚起についてまとめてみた
2026年10月7日から9日にかけて、個人情報保護委員会、JPCERT/CC、国家サイバー統括室、IPAなどの各機関が、国内組織で相次ぐ不正アクセスによる個人情報の漏えいを受けた注意喚起を公表しました。ここでは関連する情報をまとめます。 ### BIツールや従業員向けシステムも被害に JPCERT/CCは10月8日に公開した注意喚起で、「2026年9月前後」に国内組織で不正アクセスによる個人情報等の漏えい被害が相次いでいるとした。複数の製品やサービスで被害が発生している中、「技術的な情報の共有が不足しており、把握している情報は限定的かつ断片的」とも記している。同注意喚起は、普段から断続的、散発的に発生しているランサムウェア攻撃等とは別に、大量の個人情報等の漏えいにつながっている「特に増加している恐れのある攻撃類型」を取り上げるもの。(出典: 7) 被害に遭ったのは一般利用者向けのアプリに限らない。BIツールや従業員向け管理システムなど、管理、運用側で不特定多数の利用者からのアクセスを想定していないシステムでも、内部に保存していた情報が漏えいしたケースがある。(出典: 7) 国家サイバー統括室は10月9日、大量の個人情報を取り扱う事業者等の情報システムが不正アクセスにより侵入され、個人情報を含むデータが窃取される「事案を複数確認」しているとした。(出典: 9) IPAは同日、「現段階では、特定のプロダクトやサービスの脆弱性を狙った攻撃とは断定されておらず」、公表事例の傾向から外部公開しているアプリケーションやサービスの侵害、アカウントの侵害が起点となっていることがうかがえるとした。(出典: 13) 金融庁は、運転免許証等の本人確認書類の画像情報を含む顧客情報等が漏洩するサイバーインシデントが発生しているとしている。(出典: 14) ### JPCERT/CCが示した4つの攻撃類型 JPCERT/CCは注意喚起の中で、寄せられた情報などに基づく攻撃手法と痕跡を4つのケースとして示した。同注意喚起は「すべての事案で同一の攻撃手法が使用されていることを示すものではありません」と限定しており、今後の状況を踏まえて情報を追加する可能性があるとしている。(出典: 7) ##### ケースA さまざまなソフトウェアの既知の脆弱性を探索し攻撃試行するもの。一つの共通するソフトウェアの脆弱性を悪用しているのではなく、標的ごとに既知の脆弱性の有無をスキャンして悪用を試行したり、脆弱性ではないものの機器の管理不備等を悪用した攻撃(環境設定ファイルやバックアップファイルの窃取など)を試みたりしている可能性がある。 ##### ケースB API経由での不正な操作。アプリの管理用APIへの不正なリクエストによって情報の不正な書き換え等が発生しているものがあり、JPCERT/CCは次のような手口の複数の報告を受けている。 * (a)一般公開しているスマートフォンアプリを解析し、APIのエンドポイントやキーを特定する * (b)本来画面操作では実行できない内部APIに対する攻撃。具体的には、ユーザー権限の変更、不正なアカウントの作成、ヘッダーの有無の切り替えや不正な形式の認証トークンの付与による応答の違いの確認、NoSQLインジェクションによるブラインド探索を通じたアカウント情報の特定 * (c)他のシステムの侵害で窃取したAPIキーを使用する ##### ケースC MetabaseのSQLインジェクションの脆弱性(CVE-2026-72898)。この脆弱性もAPIへの不正なリクエストを通じて悪用される。(出典: 7) Metabaseは8月6日に公表。Metabaseによるとこの脆弱性を悪用したゼロデイ攻撃が確認されている。JPCERT/CCは8月14日に注意喚起を公表している。(出典: 1) ##### ケースD 10月9日に追加。公開Webサーバーからアクセス可能なアプリケーションサーバー上にWARファイルが設置される事案を確認している。WARファイルに含まれるJSPファイルは簡易Webシェルとして動作し、特定のクエリパラメーターを取得してシェルコマンドとして実行する機能を持つ。9月ごろには、掲載された不審なアクセス元からWebシェルへのGETおよびPOSTリクエストでの繰り返しアクセスが確認されている。 個人情報保護委員会は10月7日に改訂したWARNINGで、漏えい等報告を受けた事案を分析して問題点を九つの事例に類型化した。事例9「APIが悪用される事例」は、APIの設計、設定不備により、ログイン後のパラメータの書き換えで他のユーザー情報を取得できる状態となっていたもの。(出典: 5) JPCERT/CCが注意喚起の参考情報に挙げた、セキュリティ企業3社の専門家が共同でまとめた資料(以下、専門家の共同資料)は、事案対応やログ分析から得られた情報として、特定の脆弱性だけを探すのではなく、サイトやAPIの不備を広く探る動きが見えてきているとしている。スマートフォンアプリの解析で取り出したAPIキーを使い、正規のアクセスに見える形でAPIを呼び出すケースがあり、狙われている問題として必要以上の情報を返すAPI、過剰な権限を持つAPI、会員向け機能に匿名ユーザーでもアクセスできてしまう問題などを挙げる。一部は管理画面の弱いパスワードを使った攻撃や既知の脆弱性の悪用も確認しているという。*1 (出典: 15) 別のセキュリティ企業は10月9日、専門家の共同資料が公開した2件のIPアドレスを起点に、自社が観測した通信(9月18日から10月8日)を調査した結果(以下、観測レポート)を公表した。同一とみられる攻撃者が約40分間で326のIPアドレスを使い分け、これらのIPアドレスから約40分間に1,200件を超えるアクセスが行われる攻撃を複数回確認したとしている。IPアドレスが異なってもリクエストの中で同一の識別子が使い回されていたことから、同一の攻撃者によるものと判断したという。保存されているログの範囲はサービスや環境によって異なり、観測期間全体のデータを網羅したものではなく、特に9月18日から28日は一部の環境のデータに限られるとしている。(出典: 16) 観測レポートが攻撃の流れの一例として示すのは次の5段階。(出典: 16) * SQLインジェクションでログイン認証を回避できないか、情報を窃取できないかを探索 * 回避できないと分かると、攻撃者が事前に作成していたとみられるアカウントでログイン * ログイン後の機能で、改めてSQLインジェクションが可能かを探索 * ポイント制度のあるサイトでは、他の利用者のポイントを窃取できないかを探索 * 一通り試し終えると執拗には攻撃せずに引き上げる。別の日に同じサイトを攻撃する動きは確認されていない 1つのIPアドレスあたりのアクセス数も少ないため、特定のIPアドレスからのアクセス数やツール特有のパターンに頼った監視だけでは見逃すおそれがあるとしている。(出典: 16) ### 政府機関等の動き 10月上旬、デジタル大臣、官房長官、関係閣僚が会見で相次ぐ流出に言及し、10月8日には首相の国会答弁と関係省庁会議があった。個人情報保護委員会が7日、JPCERT/CCと警察庁が8日、国家サイバー統括室、総務省、経済産業省、IPA、金融庁が9日に、それぞれ注意喚起を公表している。 日付 | 主体 | 動き ---|---|--- 10月2日 | デジタル大臣 | 会見で漏えい等の件数に言及(出典: 2) 10月6日 | デジタル大臣 | 会見で国民に3つの対策を呼びかけ(出典: 3) 同日 | 官房長官 | 会見で「大変深刻に受け止めている」と述べ、手口や傾向の分析を通じた被害の全体像の把握に努めているとした。被害を受けた場合の所管省庁や警察への通報、相談を呼びかけ(出典: 18, 19) 10月7日 | 個人情報保護委員会 | 第371回委員会で注意喚起とWARNING改訂を議題とし、同日公表(出典: 4, 5, 6) 10月8日 | 警察庁長官 | 定例会見で、現時点で事案の背景や相互の関連性は明らかではないとしたうえで、捜査を推進し実態解明を進める必要があると述べた。金融機関などでの本人確認の徹底が重要だと指摘(出典: 21, 22) 同日 | 首相 | 衆院本会議の代表質問への答弁で、国家サイバー統括室を中心に情報を整理、分析し、幅広い事業者に注意喚起を行う方針を示した(出典: 17, 23) 同日 | 政府 | 全府省庁を集めた関係省庁会議を開催。被害状況や攻撃手法の情報を国家サイバー統括室に集約し、事業者への注意喚起を出す方針(出典: 11, 24, 25) 同日 | JPCERT/CC、警察庁 | 注意喚起を公表(出典: 7, 8) 10月9日 | 自由民主党 | 午前に開いた国家サイバーセキュリティ戦略本部の会合で、政府から現状の説明を受け、侵入後に大量流出の前に検知して被害を抑える手法の共有などを要請(出典: 28, 29) 同日 | 総務大臣 | 閣議後会見で、所管の事業者と地方公共団体を対象に同日注意喚起を行うと説明(出典: 11) 同日 | 経済産業大臣 | 閣議後会見で、所管の約1000の業界団体を通じて注意喚起を行うと説明(出典: 26) 同日 | 金融担当大臣 | 閣議後会見で、本人確認はICチップ情報の読み取りで行うなど適切に実施する必要があると述べた(出典: 27) 同日 | 国家サイバー統括室、総務省、経済産業省、IPA、金融庁 | 注意喚起を公表(出典: 9, 10, 12, 13, 14) 同日 | 個人情報保護委員会 | 注意喚起の掲載ページに解説動画を追加(出典: 4) デジタル大臣は10月2日の会見で、個人情報取扱事業者等での、不正アクセスによる攻撃を含む、不正の目的をもって行われたおそれによる漏えい等の件数について、令和6年度は7,604件、令和7年度は3,822件と説明した。このことから「必ずしも増加傾向にあるわけではない」と考えているとしたうえで、件数自体は多数みられており、今後の動向には注意が必要だとした。(出典: 2) 運転免許証の画像が流出した事案を受けて、複数の県の公安委員会が運転免許証の再交付に応じている。住所変更や紛失などの場合に限られる再交付を、情報が流出した可能性がある人を対象に認める運用で、愛知県は10月1日、新潟県は10月2日に始めた。再交付では顔写真と免許証番号を変更できる。(出典: 20, 30) ### 各機関の注意喚起 各機関が公表した注意喚起や依頼の宛先と、求めた内容を整理する。(出典: 3, 4, 5, 7, 8, 9, 10, 12, 13, 14) 日付 | 機関 | 宛先 | 求めた内容 ---|---|---|--- 10月6日 | デジタル大臣(記者会見) | 国民 | パスワードの使い回しをやめる、多要素認証の利用、不審なメールやSMSへの注意 10月7日 | 個人情報保護委員会 | 個人情報取扱事業者 | 別紙に示した技術的安全管理措置を踏まえた取り扱い、不要な個人データの消去、WARNING改訂版の参照 10月8日 | JPCERT/CC(9日に更新) | 国内組織 | 攻撃手法と痕跡に基づく点検、API経由のアクセスへの対策、具体的な情報の提供 10月8日 | 警察庁 | 個人、企業や団体、本人確認を行う事業者 | 基本的なセキュリティ対策の再確認、本人確認の徹底 10月9日 | 国家サイバー統括室 | 大量の個人情報や機微な情報を扱う事業者等、経営層 | ウェブシステムの管理、サプライチェーン、データ管理の対策の検討、被害組織による技術的な情報の共有 10月9日 | 総務省 | 所管事業者と関係団体、事業者 | 国家サイバー統括室と同内容の注意喚起、経営層のリーダーシップによる対策の強化 10月9日 | 経済産業省 | 関係各位(情報提供の依頼は所管業界の事業者) | 国家サイバー統括室、JPCERT/CC、個人情報保護委員会の注意喚起の参照、サプライチェーン全体での対策、被害発生時の情報提供 10月9日 | IPA | 経営者 | 外部公開アプリケーション等の点検、対策の見直し 10月9日 | 金融庁 | 金融機関等 | サイバーセキュリティ対策の点検、非対面の本人確認の徹底 個人情報保護委員会の注意喚起は、2026年9月16日の第369回委員会で決議した個人情報保護法ガイドライン別添(安全管理措置)の見直し予定の内容を先取りして、別紙で技術的安全管理措置を示したもの。見直しの内容の確定は2027年4月を予定している。(出典: 4) 金融庁は、2027年4月1日施行の犯罪収益移転防止法施行規則の改正で画像送信を受ける方法が廃止され、ICチップ情報の読取に原則一本化されることについて、施行日を待たず可及的速やかに対応するよう求めた。(出典: 14) 国家サイバー統括室は、経営層に対し、サイバー攻撃の手法がAIの悪用を含めて高度化、巧妙化しているとして、対策を経営課題と位置づけるよう求めている。*2 (出典: 9) 経済産業省は、被害発生時に提供された情報を事業者の同意なく公表しないとしている。(出典: 12) ### 対策項目ごとに見た各機関の記載 各機関の文書が挙げた対策を項目ごとに整理し次の表にまとめた。総務省、経済産業省、金融庁は国家サイバー統括室などの文書を参照させる形をとっており、表ではそれぞれの文書自体に記載がある項目に○を付けている。各組織における項目詳細は出典先を参照のこと。(出典: 4, 5, 7, 8, 9, 10, 12, 13, 14) *3 対策の項目 | 個人情報保護委員会 | JPCERT/CC | 警察庁 | 国家サイバー統括室 | 総務省 | 経済産業省 | IPA | 金融庁 ---|---|---|---|---|---|---|---|--- 侵害の痕跡がないか調査、点検する | ○ | ○ | | ○ | | | ○ | 脆弱性に対応する | ○ | ○ | ○ | ○ | ○ | ○ | ○ | 外部への公開範囲を見直す | ○ | ○ | | ○ | | | ○ | APIの管理状況やアクセス制御を見直す | ○ | ○ | | | | | ○ | 大量アクセスを制限する | ○ | ○ | | | | | | 自組織のシステムの認証を強化する | ○ | | ○ | ○ | ○ | | ○ | 権限の付与を見直す | ○ | ○ | | ○ | | | ○ | 不要になったデータを残さない | ○ | ○ | | ○ | | | ○ | 保存データを暗号化する | | | | ○ | | | ○ | 通信を暗号化する | ○ | | | ○ | | | | ログを取得し一定期間保管する | ○ | | | ○ | | | ○ | 不正アクセスを検知する仕組みを整える | ○ | ○ | | ○ | | | | インシデント発生時の対応 | ○ | ○ | | ○ | | | ○ | ○ 漏えいした情報の悪用を防ぐ | ○ | ○ | ○ | ○ | ○ | | | ○ 委託先を含めて管理する | ○ | | | ○ | ○ | ○ | ○ | ○ 経営層が関与する | ○ | | | ○ | ○ | ○ | ○ | ○ 被害や攻撃に関する情報を提供、共有する | | ○ | | ○ | | ○ | | 各組織発出内容を横断的にまとめた推奨策は以下の通り。 ##### 推奨策(1) 直近1カ月のログから点検を始める IPAは「速やかに行うべき点検」として、外部公開しているアプリケーションと利用している外部サービスのログを挙げる。(出典: 13) * 直近1カ月、その後3カ月と段階的に対象範囲を広げてログを確認する。異常の見分け方はエラーの出力量や平時との差異など(IPA、外部公開しているアプリケーションについて)(出典: 13) * ログイン失敗の量のほか、ログイン元IPアドレスやログイン時間等を平時と比較し、作ったはずのないアカウントや、無効化されているはずのアカウントの有効化がないかを確認する(IPA、利用している外部サービスについて)(出典: 13) * 不審な通信や大量のアクセスの痕跡がないか、アクセスログ等を点検、分析する(国家サイバー統括室、推奨)(出典: 9) * ログを定期的に分析し、不正アクセスの発生や兆候を早期に検知する(個人情報保護委員会の別紙、手法の例示)(出典: 4) 専門家の共同資料は、直近1か月を目安としたアクセスログの点検で調べる動きとして、次などを挙げる。(出典: 15) * 同じIPアドレスからのAPIへの大量アクセス * 403、404、503などのエラー応答の急増 * 一般利用者に許していない管理機能の利用 * データベースの高負荷やセッションの大量消費が、アクセスの増加などと同時に起きていないか * ログイン試行の増加 JPCERT/CCは、ケースAからDそれぞれに不審な送信元IPアドレスを掲載し、ケースBとCにはUser-Agentの例も載せている。10月9日にはケースAとBのIPアドレスの追加とケースDの追記があり、侵害調査への活用を呼びかけている。10月9日の更新時点で掲載されているものは次のとおり。ケースBとCのIPアドレスには「調査時点では正規利用されている可能性もあります」との注記が付く。(出典: 7) ケース | 不審な送信元IPアドレス | 悪用、観測の時期 ---|---|--- A | 20.210.128[.]125 | 10月7日ごろ B | 3.112.252[.]14、54.95.112[.]6、69.10.51[.]162、172.86.91[.]7、210.149.87[.]120 | 9月ごろ B | 136.117.40[.]140、136.85.58[.]5 | 8月28日ごろ(10月9日追記分) B | 31.76.91[.]2、141.11.187[.]186、207.241.172[.]54 | 10月9日追記分 C | 213.163.202[.]171、221.216.140[.]49、221.216.140[.]129 | 8月上旬から9月上旬 D | 124.133.237[.]18 | 9月ごろ User-Agentの例は次のとおり。(出典: 7) * ケースB * curl/7.88.1 * python-requests/2.34.2 * Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36 * ケースC * python-requests/2.33.1 * Metabase-GHSA-vwf4/2.0 観測レポートも、観測したUser-AgentとJA4 fingerprintの例を掲載している。いずれも正規の利用者が使っている可能性があるとして、ログ調査の手がかりとして使い、遮断等の判断は前後の通信内容とあわせて行うよう求めている。ログ調査の観点としては、通常と異なるHTTPレスポンスコードの偏りとレスポンスサイズの違いを挙げる。なお、以下のUser-Agentに含まれるURLは、リンクにならないよう「hxxps」「[.]」に置き換えて記載した。(出典: 16) * User-Agentの例 * curl/7.81.0 * Dart/3.11 (dart:io) * Dalvik/2.1.0 * Dalvik/2.1.0 (Linux; U; Android 13; SM-S918B Build/TP1A.220624.014) * sqlmap/1.10.9#pip (hxxps://sqlmap[.]org) * Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120 Safari/537.36 * Mozilla/5.0 * Mozilla/5.0 (Linux; Android 13; SM-G991B Build/TP1A.220624.014; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/110.0.5481.153 Mobile Safari/537.36 Device/Samsung,SM-G991B,13 MEApp/3.0.8 * EmoPar/13.2.13 (Linux; U; Android 14; SH-51B Build/UKQ1.231003.002) * JA4 fingerprintの例 * t13d3113h2_e8f1e7e78f70_ce5650b735ce * t13d1813h1_85036bcba153_d339722ba4af * t13i3112h2_e8f1e7e78f70_ce5650b735ce * t12d280700_d943125447b4_3c5a66c06c35 * t13d4312h1_c7886603b240_b26ce05bbdd6 * t13d311100_e8f1e7e78f70_24695f2957a7 IPAは、今後不審なIPアドレスやログの痕跡等が公表される可能性があるとして、当面の情報収集の強化も求めている。(出典: 13) ##### 推奨策(2) 外部公開の入口を塞ぐ **脆弱性への対応** * 修正プログラムやアップデートを適用する(国家サイバー統括室、IPA、JPCERT/CC、個人情報保護委員会の別紙の手法の例示)(出典: 4, 7, 9, 13) * 修正プログラムの適用は、インターネットに公開されていない内部のサーバー等も対象に含める。サポートが終了した製品やバージョンは使わず、定期的に脆弱性診断を実施する(国家サイバー統括室)(出典: 9) * 管理対象のIT資産を洗い出し、脆弱性情報を収集、分析して、脆弱性へ速やかに対処する(個人情報保護委員会のWARNING、事例1、2の対策例)(出典: 5) * ケースCのMetabaseは修正版を適用する(JPCERT/CCの8月の注意喚起)(出典: 1) **外部への公開範囲を絞る対策** * 利用していないシステムや機能を停止、削除し、不要なポート、プロトコル、サービス等を無効化する(国家サイバー統括室)(出典: 9) * 業務上必要のないサービスや機能(管理機能など)がインターネットに公開されている場合は公開を停止する。サービスの利用地域が限定される場合は、アクセス元の地域を制限する(JPCERT/CC、汎用的な対策)(出典: 7) * アクセスを最小化する。例えば事前に許可した特定のIPアドレスからのみに限定する方法(個人情報保護委員会の別紙、手法の例示)(出典: 4) API経由の不正アクセスについては、個人情報保護委員会が事例9の原因として次を挙げる。(出典: 5) * 管理対象から漏れているAPIが存在した * URLや会員ID等のパラメータを書き換えることで、他ユーザーのデータにアクセス可能な状態だった * レスポンスに不要な情報が含まれていたことや、会員ID等が連番となっていたことから、攻撃者によるAPIの仕様等の推測が容易だった * 大量アクセスを制御するためのアクセス回数制限(レートリミット)がなかった 個人情報保護委員会が追加したAPI悪用事例（出典: 5） 事例9の対策例、JPCERT/CCが「API経由のアクセスへの対策」として挙げる項目、IPAの記載は次のとおり。JPCERT/CCは、詳細についてOWASPのガイドライン等を参考にするとしている。 * 管理対象のAPIを把握する。個人情報保護委員会は定期的なAPIの棚卸しを、IPAは点検後の対策として「API連携等アプリケーション構成要素単位での管理状況の見直し」を挙げる。(出典: 5, 13) * 認可とアクセス制御を行う。個人情報保護委員会は、認証(本人確認)に加え、認可(そのユーザーが当該データにアクセスする権限を有するかの確認)を都度行う仕組みの実装を挙げる。JPCERT/CCは、非公開APIを含む各エンドポイントでアクセス制御を実施し、許可された利用者やHTTPメソッドからのアクセスのみを受け付けるとしている。(出典: 5, 7) * レート制限を設ける。個人情報保護委員会は、短時間での大量アクセスを検知、遮断するための「アクセス回数制限(レートリミット)」の実装を挙げる。JPCERT/CCは、単位時間あたりのリクエスト件数の制限に加え、ログイン、パスワードリセット、SMS送信、検索処理など負荷や悪用のリスクが高い機能には個別の制限を設定するとしている。(出典: 5, 7) * レスポンスとIDの設計を見直す。個人情報保護委員会は、不要な情報をレスポンスに含めない設計と、会員IDや管理番号へのランダムな値(UUID等)の採用を挙げる。(出典: 5) * APIトークンの有効期限を設定する。JPCERT/CCは、適切な有効期限を設定して長期間有効なトークンの使用を避け、不要または漏えいが疑われるトークンは速やかに無効化できるようにするとしている。(出典: 7) ##### 推奨策(3) アカウントの認証と権限を見直す **認証の強化** * 推測されやすいパスワードの使用を禁止し、多要素認証を導入する(国家サイバー統括室)(出典: 9) * 組織外ネットワークからのアクセス、管理者権限でのアクセス、重要な個人データへのアクセスで、フィッシングに耐性のあるものを含む多要素認証を導入する(個人情報保護委員会の別紙、手法の例示)(出典: 4) * パスワードの強度を確保する(警察庁、企業や団体向け)(出典: 8) 権限の最小化とアカウントの棚卸し。国家サイバー統括室は「必要以上の権限が付与されている場合、不正アクセス時に大量の情報が一度に取得されるおそれがあります」としている。(出典: 9) * 管理者アカウントの利用者とアクセス権を必要最小限にし、閲覧権限と更新権限を分離する。退職者、異動者や利用されていないもの等の不要なアカウントは速やかに無効化し、アカウントや権限設定を定期的に確認する(国家サイバー統括室)(出典: 9) * 外部公開アプリケーションのアカウントへの権限付与を見直す。利用している外部サービスは、アカウント付与の範囲とアカウント棚卸の運用を見直す(IPA、点検後の対策)(出典: 13) * ユーザーIDに付与するアクセス権限を最小化し、アクセス権限を棚卸しする(個人情報保護委員会の別紙、手法の例示)(出典: 4) * API利用者やAPIトークンに必要最小限の権限のみを付与する(JPCERT/CC、API経由のアクセスへの対策)(出典: 7) ##### 推奨策(4) 保有データを減らして保護する 国家サイバー統括室は保有データについて、「万が一情報漏えいが発生した場合でも、保有する情報が少なければ被害の拡大を抑えることが可能」としている。(出典: 9) * 保管している個人データの必要性を法令等の根拠とともに確認する。個人情報保護法第22条は利用する必要がなくなった個人データを遅滞なく消去するよう努めることとしており、消去が徹底されず漏えい等事案がより深刻化する事例にも接しているという(個人情報保護委員会)(出典: 4) * 保有する情報資産を把握し、利用目的を終えた情報を速やかに削除し、法令上の保存期間を経過した情報を適切に廃棄する(国家サイバー統括室)(出典: 9) * 保有情報を再点検する。点検後の対策として、データ保有の是非とデータ保管場所を再検討する(IPA)(出典: 13) * 保存データと通信経路を暗号化し、パスワードや認証情報を平文で保存せず、バックアップデータを適切に保護する(国家サイバー統括室)(出典: 9) * 通信の経路又は内容を暗号化する。SSL/TLS、S/MIME等(個人情報保護委員会の別紙、手法の例示)(出典: 4) ##### 推奨策(5) 侵入後の検知体制を点検する 国家サイバー統括室は「侵入を完全に防ぐことは困難です。不審な挙動の早期発見と迅速な対応が被害発生及び拡大の防止につながります」としている。(出典: 9) **ログの取得と保管、不正アクセスの検知** * 個人情報や業務情報へのアクセス記録を取得し、ログを一定期間保管する(国家サイバー統括室)(出典: 9) * 外部公開アプリケーション、外部サービス、データアクセスそれぞれのログ取得内容と保持期間を見直す(IPA、点検後の対策)(出典: 13) * 認証ログ、アクセスログ、操作ログ、通信ログ等を一定の期間保管し、漏えい、滅失、毀損、改ざん、不正消去等から保護する(個人情報保護委員会の別紙、手法の例示)(出典: 4) * 不審な通信や大量のアクセスを監視し、侵入検知と防御のシステムを活用し、パターンファイル等を定期的に更新し、外部からの異常な認証試行を把握する(国家サイバー統括室)(出典: 9) * IDSやIPS、EDR等を導入する(個人情報保護委員会の別紙、手法の例示)(出典: 4) * 不正アクセス検知体制を点検する(JPCERT/CC、汎用的な対策)(出典: 7) **検知後の初動と被害拡大の防止** * インシデントが起きた場合の対応態勢を整備し、事業継続計画等にサイバーセキュリティを組み入れる(国家サイバー統括室)(出典: 9) * 検知時の初動対応と、Webサーバー等が侵害された後の横展開対策を見直す(JPCERT/CC、汎用的な対策)(出典: 7) * 侵害を受けた、またはそのおそれがある情報システムを停止、隔離し、アカウントを無効化するなどして被害拡大を防ぐ(個人情報保護委員会の別紙、手法の例示)(出典: 4) * インシデントが起きた場合の対応態勢も含めて、サイバーセキュリティ対策を点検する(金融庁、金融機関等向け)(出典: 14) * 点検で異常なログやアカウントが見つかった場合、速やかにセキュリティインシデントと判定してインシデント対応を進め、情報漏えいの可能性を考慮して専門のセキュリティベンダーに詳細調査を依頼する(IPA、強く推奨)(出典: 13) **漏えいした情報の悪用防止** * 脆弱性等によりID、パスワードが漏えいした可能性がある場合は、初期化するか利用者に変更を案内する(個人情報保護委員会のWARNING、事例3の対策例)(出典: 5) * 漏えい発生時を想定し、平時から顧客に二次被害防止等を呼びかける。例として多要素認証(JPCERT/CC、汎用的な対策)(出典: 7) * 本人確認を行う事業者は、犯罪収益移転防止法等に基づく本人確認を徹底する(警察庁)(出典: 8) * 本人確認書類の画像や顧客の容貌の画像に不自然な点がないかを改めて確認する(金融庁)(出典: 14) **情報の提供と共有** * 不審なアクセスや侵害が疑われる事象、攻撃手法、侵害原因などに関する具体的な情報があれば提供する(JPCERT/CC)(出典: 7) * 被害にあった組織は、技術的な情報を国家サイバー統括室、所管省庁、専門機関等に速やかに共有する(国家サイバー統括室)(出典: 9) * 被害発生時に担当課室へ速やかに一報し、時系列、被害状況、攻撃種別などを可能な範囲で提供する(経済産業省、所管業界の事業者向け)(出典: 12) ##### 推奨策(6) 対策を委託先と経営層まで広げる **委託先を含む管理** * 委託先のセキュリティ対策状況を把握し、委託契約でセキュリティ要件を明確化し、委託先への提供情報を必要最小限にする(国家サイバー統括室)(出典: 9) * 自社のみならずサプライチェーン全体でセキュリティを管理するという認識を持つ(経済産業省)(出典: 12) * サードパーティリスク管理も含めて、サイバーセキュリティ対策を点検する(金融庁、金融機関等向け)(出典: 14) * 委託先がグループの親会社であっても通常の外部委託先と同じ基準で必要かつ適切な監督を行う(事例7)。クラウドサービスはセキュリティ対策を利用規約や安全性評価に関する資料等により確認して選定する(事例8)(個人情報保護委員会のWARNING、対策例)(出典: 5) **経営層の関与** * 経営層がリーダーシップを発揮して対策を進める(IPA、金融庁、総務省)(出典: 10, 13, 14) * 組織のトップが主導し、「ゼロトラスト」へ移行する(経済産業省)(出典: 12) * 経営層を交えて現状の組織体制の問題点や漏えい等が発生した場合に生じ得る損害等を評価し、組織的に対応する(個人情報保護委員会のWARNING)(出典: 5) ### 利用者に求められた基本的な行動 デジタル大臣は10月6日の記者会見で、流出した情報が氏名や住所、電話番号、メールアドレスだけでなく、ID、パスワード、クレジットカード情報、運転免許証等に及ぶ場合があり、なりすましや不正送金、詐欺等の二次被害につながるおそれがあると説明したうえで、国民に次の3つの対策を求めた。(出典: 3) 1. パスワードの使い回しをやめ、サービスごとに異なるパスワードを設定する 2. 自ら設定が可能なサービスで、多要素認証(スマートフォン認証やワンタイムパスワード等)を積極的に利用する 3. 不審なメールやSMSに注意し、記載されたリンクを安易に開くことなく、公式ウェブサイトや公式アプリからアクセスする 警察庁のサイバー警察局便りも個人向けに、情報流出元の企業をかたる偽メールの可能性があるとしてメール内のリンクを安易にクリックしないこと、安全なパスワードを設定して使いまわさないこと、警察庁推奨アプリのインストールを挙げる。(出典: 8) ### AIの関与を断定できる痕跡は未確認 専門家の共同資料は、執筆者が推測を多分に交えると断った箇所で、「一連の事案でAIが使われたと断定できるログや痕跡は確認されていません」としている。同じ箇所で、サイトごとに機能や不備を調べる調査を広い範囲で繰り返すうえで人間が手作業で行うのは現実的ではなく、「AIの活用を否定する方が難しい状況であると考えています」とも記している。(出典: 15) 観測レポートは、観測した攻撃について、人手とは考えにくいアクセス量でありながらツール特有の機械的な規則性がなく、応答を見ながら手を変えていたことから、AIエージェントまたはそれに近い仕組みによる攻撃である可能性があるとしている。そのうえで、「これは観測された振る舞いからの推測であり、AIの利用を直接示す痕跡を確認したものではありません」と記している。(出典: 16) 共通ソフトウェアの未知の脆弱性(ゼロデイ)がAIによって発見され、悪用されているのではないかという懸念については、「現時点ではそのような状況は確認されていません」とする。(出典: 15) ### 参考情報 #### 関係機関の公表 * [1] 2026年8月14日 JPCERT/CC「MetabaseのSQLインジェクションの脆弱性（CVE-2026-72898）に関する注意喚起」 * [2] 2026年10月2日 デジタル庁「古川大臣記者会見（令和8年10月2日）」 * [3] 2026年10月6日 デジタル庁「古川大臣記者会見（令和8年10月6日）」 * [4] 2026年10月7日 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について（注意喚起）」(10月9日に解説動画を追加) * [5] 2026年10月7日 個人情報保護委員会「WARNING 不正アクセスによる個人データ漏えい防止のための注意喚起」(2024年12月11日公表、2026年10月7日改訂) * [6] 2026年10月7日 個人情報保護委員会「第371回 個人情報保護委員会」 * [7] 2026年10月8日 JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(10月9日更新) * [8] 2026年10月8日 警察庁「サイバー警察局便り 2026 Vol.19「情報流出に注意！」」 * [9] 2026年10月9日 内閣官房国家サイバー統括室「不正アクセスによる漏えい等の事案を踏まえた対応について」 * [10] 2026年10月9日 総務省「不正アクセスによる情報漏えい等の事案を踏まえた対応について（注意喚起）」 * [11] 2026年10月9日 総務省「藤井総務大臣閣議後記者会見の概要（令和8年10月9日）」 * [12] 2026年10月9日 経済産業省「不正アクセスによる情報漏えい等の事案を踏まえた注意喚起及び情報提供に係る協力依頼」 * [13] 2026年10月9日 IPA「不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について」 * [14] 2026年10月9日 金融庁「現下の情勢を踏まえたサイバーセキュリティ対策の強化と各種取引申込等における対応について（注意喚起）」 #### 企業の公開資料 * [15] 2026年10月7日 マクニカ セキュリティ研究センター「相次ぐWEBシステムからの情報漏洩事案について」(10月8日にJPCERT/CCの注意喚起の公開を追記) * [16] 2026年10月9日 サイバーセキュリティクラウド「国内で相次ぐ不正アクセス、AIエージェントによる攻撃の可能性 約40分間で326のIPアドレスを使い分け、1,200件超のアクセスを繰り返す」 #### 政党の公表 * [17] 2026年10月8日 チームみらい「【全文】チームみらい 衆議院本会議 代表質問（2026年10月8日）」 #### 報道 * [18] 2026年10月6日 産経新聞「木原官房長官、相次ぐ企業の情報流出「大変深刻」 手口分析や被害把握急ぐ考え示す」 * [19] 2026年10月6日 日本経済新聞「相次ぐサイバー攻撃企業被害、官房長官「大変深刻に受け止めている」」 * [20] 2026年10月7日 中日新聞「タイムズカー情報漏えい、免許証番号変更し再交付 愛知県公安委員会、県警への相談受け」 * [21] 2026年10月8日 熊本日日新聞「サイバー攻撃、実態解明へ 警察庁長官「捜査を推進」」(共同通信配信) * [22] 2026年10月8日 毎日新聞「相次ぐサイバー攻撃と情報流出 警察庁長官「解明進める必要」」 * [23] 2026年10月8日 日本経済新聞「サイバー攻撃急増、高市首相「企業に注意喚起」 被害情報分析へ」 * [24] 2026年10月8日 Impress Watch「サイバー攻撃多発で緊急の関係省庁会議 国家サイバー統括室で情報集約」 * [25] 2026年10月9日 電波新聞「不正アクセスによる情報流出が多発、政府が関係省庁会議 対策強化へ情報集約」 * [26] 2026年10月9日 ニューズウィーク日本版「経産省、不正アクセス続発で業界団体に注意喚起へ＝赤沢経産相」(ロイター配信) * [27] 2026年10月9日 時事通信「セキュリティー対策の点検要請 免許証画像も確認徹底を―金融庁」 * [28] 2026年10月9日 日本経済新聞「サイバー攻撃増、政府が企業に注意喚起 自民党は官民連携の強化要請」 * [29] 2026年10月9日 産経新聞「自民、AIを悪用したサイバー攻撃への対策強化を政府に要請 相次ぐ企業不正アクセス受け」 * [30] 2026年10月10日 FNNプライムオンライン「「しっかり釈明を」“タイムズカー”会員情報流出…特例措置で運転免許証“再交付”も「今回のことは重大な事案」新潟」 ### 更新履歴 * 2026年10月11日 新規作成 *1:専門家の共同資料が「重点的に確認するIPアドレス」とする2件は、JPCERT/CCがケースBの不審な送信元IPアドレスとして掲載したものにも含まれる。 *2:原文: 「AIの悪用を含むサイバー攻撃の手法が高度化・巧妙化する中」。 *3:個人情報保護委員会の列は注意喚起(別紙を含む)とWARNINGを対象とした。総務省の列は、同省が国家サイバー統括室と同内容の注意喚起として文面に挙げた項目に○を付けた。空欄はその文書に記載がないことを示し、対策が不要という意味ではない。
piyolog.hatenadiary.jp
