安全管理措置の見直しで何が変わる？認証・ID管理の実務対応

2026年10月、個人情報保護委員会が安全管理措置の見直し内容を示し、事業者に求められる認証・アクセス制御の水準を引き上げる方向性が明らかになりました。見直しの確定は2027年4月を予定していますが、同委員会は近時の大規模な漏えい事案を踏まえ、確定を待たずに内容を先取りする形で公表しています。本記事では、同時期に相次いだ公的機関の注意喚起をあわせて整理し、認証基盤の設計・運用で具体的に何に着手すべきかを解説します。

安全管理措置の見直しが前倒しで示された背景

2026年9月前後から、大量の個人データを取り扱う事業者への不正アクセスが相次ぎました。タイムズカーでは本人確認書類の画像が約160万アカウント分流出し、Gyazoではユーザー関連データ約2,362万件と画像メタデータ約4.9億件が、手間いらずでは最大約445万人分の予約者情報が対象となっています（詳細は2026年9月のIDニュースまとめで整理しています）。10月に入ってからもブックオフグループで最大約643万件、コミューンの「Commune」で約30万7,000人分の漏えいが公表されました。

一連の漏えい事案を受け、10月7日から9日にかけて複数の公的機関が相次いで注意喚起を公表しています。

公表日	機関	要点
10月7日	個人情報保護委員会	大規模な漏えい等事案を踏まえた対応について（注意喚起）。2027年4月に確定予定の安全管理措置の見直し内容を先取りして提示し、あわせてWARNINGを改訂した
10月8日・9日	JPCERT/CC	直近で相次いでいる国内組織における不正アクセスに関する注意喚起。2026年9月前後に被害が相次いでいるとして、確認された4つの攻撃ケースを公表した
10月9日	内閣官房 国家サイバー統括室	不正アクセスによる漏えい等の事案を踏まえた対応について。ウェブシステム等の適切な管理、サプライチェーンを通じた侵害への対策、データの適切な管理の3点を柱に対策を求めた
10月9日	IPA	不正アクセスによる漏えい等の事案を踏まえ、速やかに実施すべき対策等について。外部公開アプリケーションの認証機能強化とアカウントへの権限付与の見直しを挙げた
10月9日	金融庁	現下の情勢を踏まえたサイバーセキュリティ対策の強化と各種取引申込等における対応について（注意喚起）。金融機関等にサードパーティリスク管理とインシデント対応態勢の点検を要請した

このほか、警察庁・総務省・経済産業省も同時期に注意喚起を公表しています。国家サイバー統括室は「サイバー攻撃による被害は、もはや情報システム部門だけの問題ではありません」として、経営層に対策強化を直接求めました。

技術的安全管理措置は5項目へ：新設された「不正アクセス等の検知等」

個人情報保護委員会の注意喚起で最も重要なのは、ガイドライン（通則編）別添に定める技術的安全管理措置の構成が変わる点です。従来の4項目に「不正アクセス等の検知等」が加わり、次の5項目となります。

講じなければならない措置	内容
（1）アクセス制御	担当者および個人データを取り扱う情報システムの範囲を限定するために、適切なアクセス制御を行う
（2）アクセス者の識別と認証	個人データを取り扱う情報システムを使用する者が正当なアクセス権を有する者であることを、識別した結果に基づき認証する
（3）外部からの不正アクセス等の防止	個人データを取り扱う情報システムを外部からの不正アクセスまたは不正ソフトウェアから保護する仕組みを導入し、適切に運用する
（4）情報システムの使用に伴う漏えい等の防止	情報システムの使用に伴う個人データの漏えい等を防止するための措置を講じ、適切に運用する
（5）不正アクセス等の検知等	個人データを取り扱う情報システムに対する不正アクセス等が発生した場合に早期に検知等するための措置を平時から講じ、組織内ネットワークにおける被害拡大を防止できるよう適切に運用する

見直し後の技術的安全管理措置で押さえるべきは、5項目が「講じなければならない措置」であり、従わなかった場合に法違反と判断される可能性があるという位置づけです。一方、各項目にぶら下がる「手法の例示」は文字どおり例を示したものであって、すべてを実施しなければ直ちに法違反となるわけではなく、適切な手法が例示の内容に限られるわけでもありません。したがって実務上は、自社が取り扱う個人データの性質と量に照らして、例示をどこまで実装するかを判断する作業が必要になります。

新設された5項目めは、侵入を防ぐ対策だけでは不十分であり、侵入された後に早期に検知して被害の横展開を止める運用までが求められるという考え方を明示したものです。

認証・ID管理に関わる5つの要求水準

「手法の例示」のうち、認証・認可・ID管理の設計に直接関わる部分を5つに整理します。

フィッシング耐性のある多要素認証を、従業者と利用者の双方に

例示では、組織外ネットワークからのアクセス、管理者権限でのアクセス、重要な個人データへのアクセスにおいて、識別・認証手法を複数組み合わせる多要素認証（フィッシングに耐性のあるものを含む）の導入が挙げられています。注目すべきは、従業者だけでなく「情報システムを使用する従業者以外の者」、すなわち顧客や会員に対しても、同一・類似パスワードの使い回しをしないよう周知したうえで多要素認証（フィッシングに耐性のあるものを含む）を導入するという例示が置かれた点です。パスキーをはじめとするフィッシング耐性のある認証方式は、従業員向けの社内システムだけでなく、BtoC サービスの会員認証でも標準的な選択肢として位置づけられたことになります。

特権アカウントの限定と、アクセス権限の定期的な棚卸し

アクセス制御の例示では、ユーザーIDに付与するアクセス権限の最小化に加え、特権アカウントを割り当てる従業者・利用する端末・利用する場面を最小限に限定することが求められています。さらに、人事異動や退職などの組織体制の変更に伴う権限変更を適切に行い、アクセス権限について定期的に監査する棚卸しの実施が例示されました。国家サイバー統括室も、退職者・異動者や利用されていないアカウントを速やかに無効化すること、閲覧権限と更新権限を適切に分離することを挙げています。

動的コンテキストを評価してアクセス可否を判断する

今回の見直しで新しく踏み込んだのが、組織内外からのアクセスについて、アクセス要求ごとにアクセス元の場所・アクセス時間・デバイスのセキュリティ状態等の動的コンテキストを評価し、リスクに応じてアクセスの可否を判断する仕組みを導入するという例示です。固定的な権限付与だけでは足りず、リスクベース認証や継続的なアクセス評価といったゼロトラストの考え方が、ガイドラインの手法例示の水準に入ってきたことを意味します。

認証に加えて、認可を都度確認する

改訂された WARNING では、事例9として「APIが悪用される事例」が新たに追加されました。スマートフォンアプリやWebサービスで利用するAPIの設計・設定不備により、攻撃者が当該サービスにログインした後、パラメータを書き換えることで本来は取得できない他のユーザー情報を取得できる状態になっていた、という類型です。

原因として挙げられているのは、管理対象から漏れたAPIの存在、URLや会員ID等のパラメータ書き換えで他ユーザーのデータにアクセスできる状態、レスポンスへの不要な情報の混入と会員IDの連番採用による仕様推測の容易さ、そしてレートリミットの不在です。対策例では、定期的なAPIの棚卸しに加え、認証（本人確認）だけでなく認可（そのユーザーが当該データにアクセスする権限を有するかの確認）を都度行う仕組みの実装、会員IDや管理番号へのランダムな値（UUID等）の採用、レートリミットの実装が示されました。

JPCERT/CCが公表した攻撃ケースにも、公開されているスマートフォンアプリを解析してエンドポイントを特定し、画面操作では実行できない内部APIに対して攻撃を行う手口が含まれています。ログイン画面の認証をいくら強化しても、API側で認可判定を行っていなければ、正規ユーザーとしてログインした攻撃者に他人のデータを取得されます。認証と認可は別の制御であるという原則が、監督官庁の文書で明示的に問われた形です。

不要になった個人データを消去する

個人情報保護法第22条は、利用する必要がなくなった個人データを遅滞なく消去するよう努めなければならないと定めています。今回の注意喚起では、この対応が徹底されず漏えい等事案がより深刻化した事例に接しているとして、保管している個人データの必要性を法令等の根拠とともに確認するよう改めて求められました。退会者を含むアカウント情報と本人確認書類の画像が大量に漏えいした9月の事案を踏まえると、eKYCで取得した券面画像の保持期間は優先的に点検すべき対象です。クラウド上のデータを消去する際に、提供事業者が用意する方法や暗号化消去など容易に復元できない手段を採用することも例示されています。

2027年4月に向けて着手すべきこと

見直しの確定は2027年4月ですが、確定を待つ理由はありません。（1）〜（4）は現行のガイドラインでも「講じなければならない措置」であり、新設される（5）も法第23条が定める安全管理措置義務を具体化する項目として追加されるため、確定前から対応しておくべきです。認証基盤の観点では、次の順序で着手することを推奨します。

はじめに、自社が保有する個人データの棚卸しと保持期間の確認を行います。本人確認書類の画像や退会者のデータなど、消去すべきものが残っていないかを法令上の根拠とあわせて点検する作業は、漏えい時の被害規模を直接左右するため最も費用対効果が高い対策です。次に、管理者権限と特権アカウントの範囲を見直し、棚卸しの運用を定例化します。そのうえで、顧客向け認証のフィッシング耐性を高める施策としてパスキーの導入を検討し、並行してAPI単位の認可判定とレートリミットの実装状況を確認します。最後に、認証ログ・アクセスログ・操作ログ・通信ログの保存期間を定め、定期的な分析と異常検知の体制を整えます。

マイナンバーカードの公的個人認証（JPKI）を使う本人確認であれば、券面画像を保持せずに身元確認を完結できるため、保有データの最小化と本人確認の厳格化を同時に満たせます。身元確認の方式そのものを見直すことは、安全管理措置への対応としても有効な選択肢です。

スタジオメッシュは、本人確認・認証・ID管理の設計から運用までを支援しています。マイナンバーカードを使った本人確認の組み込みはマイナブリッジ、パスキー導入や権限設計・API認可の見直しはサービス紹介をご覧のうえ、お気軽にご相談ください。