Claude Mythos時代の脆弱性対応…「パッチ後回し」が危ないワケと3つの計画

個人情報保護委員会は何を求めた？「措置」と「例示」の違い

　個人情報保護委員会は今回、大規模漏えい事案を踏まえた注意喚起とあわせて、「WARNING～不正アクセスによる個人データ漏えい防止のための注意喚起～」（以下、WARNING）を改訂した。公表された文書は2つある。注意喚起の別紙は、2027年4月に確定予定のガイドライン見直しを先取りし、技術的安全管理措置の改訂案を示した。改訂版WARNINGは、漏えい等報告の分析から9つの事例を類型化し、原因と対策例を整理している。

　ガイドライン（通則編）の安全管理措置は、「講じなければならない措置」と、それを実践する「手法の例示」で構成される。前者に従わなければ法違反と判断される可能性がある。

　後者は例であり、すべてを実施しなくても直ちに法違反となるわけではないが、満たせば十分というわけでもない。手法は、漏えい時に本人が受ける影響や、個人データの性質・量に応じて決めるものとされる。

　注意喚起の別紙は、不正アクセスなどを早期に検知し、組織内ネットワークで被害拡大を防止できるよう運用することを講じなければならない措置として掲げ、その手法の例示に停止・隔離とアカウントの無効化を挙げた。

　求められているのは「止めること」そのものではなく、被害の広がりを止められる状態を平時から作っておくことである。

　WARNINGは何かを命じる文書ではないが、挙げられた「原因」は、措置が不十分と判断され得る典型例として読むべきだろう。主な改訂点を下表に示す。

事例	改訂版での主な追加箇所
総論	・セキュリティ対策は「どれか一つを講じればよい」のではなく、多層的に講ずる必要があると明記 ・経営層を交えて、組織体制の問題点と、漏えい等が起きた場合に生じ得る損害などを評価することを求める記述を追加 ・事例数を8から9に拡大
事例1 脆弱性が放置された事例	【原因】 ・保守契約はあったが、委託業務の内容に脆弱性対応が含まれていなかった ・脆弱性情報は収集していたが、対策を講じる際の役割分担が決まっていなかった 【対策例】 ・洗い出すIT資産に「外部の事業者から貸与されている物」を含める ・脆弱性には「速やかに」対処する
事例2 脆弱性への対応が遅れた事例	【原因】 ・社内ネットワーク内の利用ならリスクは小さいと考え、サポート期限切れの機器を使い続けた 【対策例】 ・外部からの侵入を想定し、社内ネットワーク上の機器にも脆弱性対策を徹底する ・脆弱性には「速やかに」対処する
事例3 不正ログインの事例	【原因】 ・ログの保存・監視のルールがなく、不正アクセスの検知が遅れた 【対策例】 ・ログの保存期間を定め、定期的に分析する ・多要素認証などの採用を独立した項目にし、基準を「取り扱う個人データの性質及び量」に変更
事例4 グループ会社や海外拠点が狙われた事例	【原因】 ・海外拠点に置かれた貸与品のVPN装置が台帳に載っておらず、存在を把握できていなかった 【対策例】 ・洗い出すIT資産に「外部の事業者から貸与されている物」を含める
事例5 グループ会社間のアクセス制御不備があった事例	追加項目なし。 対策例の「必要最小限のアクセス制御」と「各社業務システムの分離独立」を2項目に分けて整理された
事例6 個人領域に保存したデータの漏えい事例	【対策例】 ・従業者に、日頃から個人データの取り扱いに関する規律・ルールを周知し、徹底を促す
事例7 グループ会社への監督が不十分な事例	【原因】 ・グループ全体のセキュリティポリシーが改訂されたのに、子会社が対応できていなかった 【対策例】 ・監督の表現を「必要かつ適切な監督」に改め、仕組みの構築を「考えられる」から「構築する」に変更
事例8 利用するクラウドサービスからの漏えい事例	実質的な追加なし（表現の調整のみ）
事例9（新設） APIが悪用される事例	【原因】 ・管理対象から漏れたAPIがあった ・パラメータの書き換えで他ユーザーのデータにアクセスできた ・レスポンスに不要な情報があり、IDも連番だったため、仕様を推測しやすかった ・レートリミット（アクセス回数制限）がなかった 【対策例】 ・APIを定期的に棚卸しする ・認証に加え、認可（アクセス権限の確認）を都度行う ・レスポンスに不要な情報を含めず、IDはUUIDなどのランダム値にする ・レートリミットを実装する

【次ページ】【筆者検証】接続10分でBotが着弾…ハニーポットで見た実態