
※この記事は、2026年10月14日時点の公表情報にもとづく、一般的な点検の整理です。個別の状況に応じた判断は、専門家にご相談ください。
注意喚起が、組織に求めていること
2026年10月、JPCERTコーディネーションセンター(JPCERT/CC)が10月8日に、個人情報保護委員会が10月7日に、相次いで注意喚起を公表しました。背景は、なぜ今、個人情報の流出が相次いでいるのかで整理しています。
個人情報保護委員会は、2027年4月に確定予定のガイドラインの見直し案を、先行して示したと報じられています。例として挙げられているのは、アクセス権限の最小化、フィッシングへの耐性を含む多要素認証、脆弱性への対応、ログの保存と分析、侵入を検知する仕組み(IDS/IPSやEDR)、侵害されたシステムの隔離などです。また、不正アクセスによる漏えいを防ぐための既存の注意喚起文書に、**「APIが悪用される事例」**が追加され、典型例が9つに整理されたとのことです。
この記事では、これらを、自分の組織で、今週から確認できる点検リストに落とし込みます。
特に注意したい:「想定していない入口」
JPCERT/CCが強調しているのは、被害が、一般の利用者向けアプリだけでなく、**「管理・運用側で、不特定多数の利用者からのアクセスを想定していないシステム」**にも及んでいる点です。
- BI(分析)ツール
- 従業員向けの管理システム
- 管理用のAPI・管理機能
「社内の人しか使わない」「URLを知らなければ、見られない」と思っていたものが、インターネットに公開されていたために、狙われるケースです。
点検の全体像
| 領域 |
確認すること |
| 公開範囲 |
管理機能や、分析ツールなどが、インターネットに公開されていないか |
| API |
呼び出し回数の制限、アクセス制御、トークンの権限と有効期限があるか |
| 認証 |
管理者アカウントに、多要素認証が設定されているか |
| 権限 |
アカウントと権限が、棚卸しされているか(退職者・使い回し・過剰な管理者権限) |
| 脆弱性 |
使っているソフトウェアと機器の、修正プログラムが適用されているか |
| 委託先 |
委託先・利用サービスを含めた、管理ができているか |
| ログと検知 |
不審なアクセスを、検知し、追跡できるか |
| データ |
持ちすぎていないか。保存期間を過ぎたデータを、消しているか |
| 事故への備え |
連絡体制、初動の手順、二次被害を防ぐ周知の準備があるか |
点検リスト(12項目)
次の項目に、「はい」と答えられるかを、確認してください。
公開範囲
- 管理機能や分析ツール、従業員向けシステムが、インターネットから、アクセスできる状態になっていないか(必要ない場合は、公開を止める)
- 公開しているサービスのうち、使っていないもの・古いものは、残っていないか
API
- APIに、単位時間あたりの呼び出し回数の制限があるか(特に、ログイン・パスワード再設定・SMS送信・検索など、悪用されやすい機能)
- 非公開のAPIを含め、各APIで**アクセス制御(誰が、何をできるか)**が実施されているか
- APIトークンに、必要最小限の権限と、適切な有効期限があり、漏えいが疑われる時に、すぐ無効にできるか
認証と権限
- 管理者アカウントに、多要素認証が設定されているか(可能なら、フィッシングに強い方式)
- 退職者・異動者のアカウントや、使われていないアカウントが、残っていないか。共有アカウントは、使われていないか
脆弱性と構成
- 使っているソフトウェア、VPN機器などの通信機器の、修正プログラムが適用されているか。そもそも、何を使っているのかを、把握できているか
- 設定ファイルやバックアップファイルが、外から取得できる場所に、置かれていないか
委託先・検知・データ
- 委託先・利用サービスに、渡している情報の範囲と、事故の時の連絡体制が、把握できているか
- 不審なアクセスを検知するログや仕組みがあり、侵害された時に、他へ広がらないようにする対策があるか
- 法令や契約で定めた保存期間を過ぎたデータや、利用目的を終えたデータを、残していないか
「いいえ」や「分からない」が出た項目が、最初に取り組む場所です。「分からない」こと自体が、リスクだと考えてください。
優先順位の目安
すべてを一度にやるのは、現実的ではありません。次の順に、進められます。
| 時期 |
取り組むこと |
| 今週 |
公開されているものの棚卸し(項目1・2)。管理者アカウントの多要素認証の確認(6) |
| 今月 |
アカウント・権限の棚卸し(7)。修正プログラムの適用状況の確認(8)。APIの制限と権限の確認(3〜5) |
| 今期 |
委託先の管理の見直し(10)。ログと検知(11)。不要なデータの削除ルール(12) |
「入れているから、大丈夫」を確認する
セキュリティの見直しで、繰り返し感じるのは、「入れているから、大丈夫」と思われていたものを、確認してみると、穴があったということです。ファイアウォールの設定を確認すると、過去の改修で追加したまま残った、不要なルールが、穴になっていたケースを、多く見てきました。定期的な棚卸しが、欠かせません。
同じように、「動いているから触れない」システムの、古い部分や、担当者しか分からない設定が、リスクの温床になります(技術的負債とは)。完全にゼロにするより、どこに借金があるのかを、把握しておくことが大切です(SBOMとは、最小権限の原則とは)。
バックアップについても、「取っている」ことと、「復元できる」ことは、別です。事故の時に、本当に戻せるかを、確認しておいてください(RTO・RPOとは)。
事故に備えて、準備しておくこと
どれだけ対策をしても、被害をゼロにはできません。起きた時に、すぐ動ける準備も、重要です。
- 連絡体制:誰が、誰に、何を、いつまでに連絡するか
- 初動の手順:被害の拡大を止める(アカウントの停止、システムの隔離など)、ログを保全する
- 二次被害を防ぐ周知の準備:漏えいの公表時に、「お詫びや補償を装った詐欺」に注意するよう、顧客に呼びかける文面
- 多要素認証の案内:顧客の側でも、不正ログインを防げるよう、設定を促す
- 報告の要否の確認:個人情報保護法に基づく、個人情報保護委員会への報告・本人への通知が必要になる場合があるため、判断の手順を、あらかじめ決めておく
JPCERT/CCは、侵害が疑われる場合の、相談や情報提供も受け付けています。
小さな組織の、最初の3つ
人手が限られている場合は、次の3つから始めてください。
- 公開されているものを、洗い出す:管理画面、分析ツール、使っていない古いサービスが、外から見えていないか
- 管理者アカウントの、多要素認証と棚卸し:誰が、管理者権限を持っているか。使われていないアカウントは、ないか
- 修正プログラムの適用と、不要データの削除:古いまま放置されているものはないか。持ちすぎているデータはないか
自組織の状況を、一緒に整理したい方へ
どこから手をつければよいか、自分たちだけでは判断が難しい場合は、状況の整理から、ご相談に応じます。アカウント、権限、バックアップ、更新の運用などの現状を洗い出し、優先順位をつけて、無理なく続けられる形に整えます。
→ IT環境の棚卸し・セキュリティの見直しを相談する
まとめ
- 注意喚起の要点は、APIの制限と権限、不要な機能の非公開、多要素認証、脆弱性への対応、ログと検知、データを持ちすぎないこと
- 被害は、**管理系・分析ツールのような「想定していない入口」**にも及んでいる
- 点検リストの**「分からない」が、最初に取り組む場所**
- 最初の3つは、公開の棚卸し・管理者アカウントの多要素認証・修正プログラムの適用と不要データの削除
- 起きた時に動けるよう、連絡体制と初動の手順も、あらかじめ決めておく
この特集の記事(個人情報流出)
関連する用語
参考にした情報
- JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」(JPCERT-AT-2026-0030、2026年10月8日公開・9日更新):https://www.jpcert.or.jp/at/2026/at260030.html
- 個人情報保護委員会「大規模な漏えい等事案を踏まえた対応について(注意喚起)」(2026年10月7日):https://www.ppc.go.jp/files/pdf/261007_houdou.pdf
- OWASP「Top 10 API Security Risks 2023」(JPCERT/CCが参考情報として紹介):https://api-security.owasp.org/editions/2023/en/0x11-t10/
- OWASP「REST Security Cheat Sheet」(同):https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
※法令上の報告義務の要件などは、個人情報保護委員会の最新の案内をご確認ください。