何が問題になるか
場面
顧客情報が抜き取られたと、外部から指摘されることがあります。画面の改ざんがなくても、公開しているウェブシステムや社内向けのシステムの既知の脆弱性、設定の不備、管理用APIの権限の不備を突き、正規の操作に見せかけて情報を取り出す手口があります。スマートフォンアプリを解析して、APIの接続先や鍵を割り出す例もあります。
JPCERT/CCは2026年10月8日、国内組織への不正アクセスによる個人情報の漏えいが相次いでいるとして注意喚起を出しました。見た目に異常がないことは、漏えいがないことの根拠になりません。
法律の整理
不正の目的をもって行われたおそれがある行為による個人データの漏えい等は、そのおそれの段階を含めて、個人情報保護委員会への報告と本人への通知の対象になります。報告は速報と確報に分かれ、確報は発覚日から、60日以内です。この類型には人数の要件がなく、漏れた項目が氏名・連絡先・予約内容にとどまっても対象になります。
個人情報保護法第26条は、第1項で、規則で定める事態が生じたときは「当該事態が生じた旨を個人情報保護委員会に報告しなければならない」と定めています。第2項で、本人への通知を義務づけています。個人情報保護委員会は、報告が必要な場合として「不正の目的をもって行われたおそれがある」行為による漏えい等を挙げています。
会社が備えること
確認すること
- 公開を続けるか止めるか（止める前にログを保全します）
- アクセスログ・APIのログ・データベースのログの保全
- 管理画面・APIの鍵（トークン）・管理者アカウントの棚卸し
- 既知の脆弱性の更新状況
- 非公開のものを含むすべてのAPIで、許可された利用者だけが使える設定になっているか
技術的な調査は保守の委託先か調査会社に頼み、依頼前に保全の指示を受けます。端末の切り離しや証拠の保全など、最初の数時間の動きは不正アクセスを受けたことが分かりました。最初の数時間で何をすべきですかにまとめています。
対応
保守・開発を委託している場合は、契約上、脆弱性への対応・更新・ログの保全・事故時の協力が誰の義務かを確認します。定めがなければ協力を求めつつ、費用と責任の分担は原因が分かった後に協議します。委託先やクラウド側で漏えいが起きたときの自社の責任は利用しているクラウドサービス・委託先で漏えいが起きました。自社の責任はありますかで扱っています。
本人への通知には、漏れた情報がフィッシングや詐欺に使われるおそれがあるため、注意を呼びかける内容を入れます。JPCERT/CCも、対策に「平時からの顧客への二次被害防止等の呼びかけ（多要素認証など）」を挙げています。進める順番は報告・通知・公表の順番にまとめています。
平時の備えとして、個人情報保護法第22条は、個人データを「利用する必要がなくなったときは」「遅滞なく消去するよう努めなければならない」と定めています。業務上不要なサービスや管理機能のインターネット公開は止めます。APIの利用者とトークンには必要最小限の権限だけを与えて有効期限を設け、不要になったトークンは速やかに無効化できるようにします。社内向けのシステムも同じ点検の対象にします。
ご相談で伺うこと
- 指摘を受けた日時と内容
- 対象のシステムと個人データの項目
- 保守・開発の委託先と契約の定め
- ログの保存状況と取った措置