デジタル庁の新本人確認ガイドライン「DS-511」を読み解く

第4回:本人確認の継続的統制とは何か――例外措置と回復フローの設計

  • 2026-06-04

強い本人確認や認証を導入したのに、不正や事故がなくならない。そうしたケースでは、方式そのものよりも、例外時の回復経路や運用中の劣化が弱点になっていることが少なくありません。これに対してデジタル庁の「DS-511行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」(以下、DS-511)は、本人確認を導入時のチェックリストで終わらせず、例外ケースと改善プロセスまで含めて設計対象にする考え方を示しました。また「DS-512行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン 解説書」(以下、DS-512)ではその背景と具体像を解説し、実務上どこで設計が崩れやすいのかを可視化しました。

通常フローがいかに堅牢でも、紛失、故障、端末変更、問い合わせ、苦情、誤操作といった局面でより弱い経路が残っていれば、攻撃者はそこを狙います。本人確認の実効強度は最も厳しい経路ではなく、最も弱い経路で決まるからです。

例外措置やアカウント回復を「運用部門の細かな調整事項」と見なさないことが重要です。

1. なぜ本人確認は「導入」ではなく「継続統制」なのか

DS-511は、本人確認手法の検討を一度きりの方式選定として扱っていません。図表1のとおり、保証レベルの判定、本人確認手法の評価、補完的対策、例外措置の検討に続き、「継続的な評価と改善」を正式なプロセスとして位置づけています。つまり、本人確認は「要件を決めて終わり」ではなく、運用期間中に評価して、必要があれば見直す前提の仕組みとし、作り上げる必要があります。

この発想が重要なのは、本人確認の失敗が導入時には見えにくいからです。利用開始後に初めて、離脱率、失敗率、問い合わせ件数、苦情、不正兆候、制度変更、脅威変化が表面化します。当初は妥当だった方式でも、環境が変わればボトルネックになります。そこでDS-511は評価のために必要な情報をあらかじめ定義し、問い合わせ履歴、監視で検知したイベントやインシデント、脅威動向などを運用期間中に収集・蓄積するよう求めています。

米国国立標準技術研究所のガイドライン「NIST SP 800-63-4」でも同様に、本人確認や認証を含むデジタルアイデンティティ管理については、運用しながら継続的に見直すべき課題として扱われています。そのため組織は、継続的な評価と改善の仕組みを整え、利用者からの意見やヘルプデスク対応状況、脅威情報、不正対策の指標、プライバシー評価、顧客体験の評価といった情報を継続的に活用することが求められます。ここで示されているのは、本人確認や認証の品質は方式名だけで決まるのではなく、運用の中でどれだけ状況を把握し、学習し、改善できるかによって左右されるということです。

図表1:継続評価の項目例

区分

指標

何を見るための指標か

身元確認

完了率・失敗率

本人確認が最後まで完了しているか、どの段階で失敗が多いかを見る。

途中離脱率

失敗ではなく、手続が難しくて途中でやめてしまう人が増えていないかを見る。

認証・回復

アカウント回復依頼件数

回復依頼が増えていないかを確認し、認証の使いにくさや攻撃の兆候がないかを見る。

不正対策

確認された不正件数・不正の疑い件数

なりすましや不正アクセスが、どの経路で起きているかを把握する。

利用者対応

問い合わせ件数・解決までの時間

利用者がどこでつまずいているか、解決までに時間がかかりすぎていないかを見る。

救済申立て件数・解決までの時間

誤判定や救済不足が繰り返し起きていないか、救済が適切に機能しているかを見る。

デジタルアイデンティティのサービスを運用する際は、これらの指標にチャネル別・手法別・利用者属性別の分解を加えると運用改善に結びつきやすいと考えられます。

2. 例外措置と回復フローが、なぜ全体の弱点になるのか

上述したとおり、設計上見落とされやすいのが異常系フローです。DS-511は、異常時の例外措置に本来の手法との保証レベル差がある場合、なりすまし等の攻撃の起点として悪用されるおそれがあると警告しています。つまり、通常時の本人確認を厳密にしても、例外時に弱い経路を残せば、そこが全体の入り口になるということです。

DS-512は、アカウント回復の代表的な手段として、身元確認の再実施、予備認証器の登録、リカバリーコードの事前発行、必要時発行を整理した上で、それぞれの弱点を説明しています。リカバリーコード入力はフィッシングに脆弱であり、必要時発行は利便性が高い反面、登録済み連絡先が乗っ取られた場合には連鎖的なアカウント奪取につながり得ます。

DS-511も、アカウント回復手段には採用している当人認証手法と同等以上の強度を選ぶよう求めており、アカウント回復は単なる使い勝手改善ではなく、本人確認や認証をやり直す「本番の入り口」として扱うべきとされています。実務的には、回復フローは身元確認と認証の再実施、あるいは代替経路の設計そのものです。通常時よりも弱い確認で認証器を再設定できるなら、そのシステムは表面上「回復」に見えても、別のオンボーディング経路を持っているのと同じです。したがって、設計レビューでは通常フローだけでなく、紛失、故障、端末変更、誤登録、ロックアウト、窓口救済、代理対応まで含めて、一つの本人確認体系として見なければなりません。

通常フローと比較して、例外・回復フローでは「急ぐ」「代替する」「人手で救済する」といった判断が入りやすくなります。DS-511が重視するのは、この差分を設計時に明示し、必要であれば補完策や公開範囲の制御まで含めて統制することです。

3. CISOが運用部門と握るべき、継続統制の論点

では、何を継続的な統制の対象にすべきでしょうか。

第一に、どの例外を認め、どの例外は認めないかを明文化することです。これは、例外措置が現場判断で広がり、本来より弱い経路が知らないうちに常態化するのを防ぐためです。DS-511でも、本来の手法と例外措置の保証レベルに差があると、なりすまし等の攻撃の起点として悪用されるおそれがあるとしています。

第二に、通常フローとの差分をどこまで許容するか、そしてその差分を補完的対策で埋めるのか、それとも残して受け入れるリスクとして扱うのかを決めることです。これは、例外時の経路が全体の強度を下げる隠れた弱点にならないようにするためです。DS-511は、補完的対策の検討や例外措置の検討を、本人確認手法の選定と一続きのプロセスとして位置づけています。

第三に、監視と改善の仕組みを持つことです。これは、導入した本人確認や認証の方式が実際に機能しているかを運用の中で見続け、問題があれば修正できるようにするためです。NIST SP 800-63-4は、継続的な評価と改善の仕組みを整え、利用者からの意見、ヘルプデスク対応状況、脅威情報、不正対策の指標、顧客体験の評価、プライバシー評価などを継続的に取り込むことを求めています1。併せて、推奨指標として身元確認の完了率・失敗率、途中離脱率、アカウント回復依頼件数などを挙げています。

第四に、改善内容を文書化することです。これは、なぜその方式を採用したのか、どの例外を認めたのか、どの補完的対策で不足を埋めるのかを関係者が共有し、後から見直せるようにするためです。DS-511は、本人確認手法の検討結果を文書化して管理し、継続的な評価と改善に活用することを求めています。DS-512の検討用ワークシートも、検討結果を標準化された様式で文書化し、関係者との共有や今後の評価・改善に活用することを目的としています。

重要なのは、本人確認の継続的な統制は、ID・アクセス管理の担当だけで完結しないという点です。不正対策、利用者対応、ヘルプデスク、法務、外部のIDプロバイダやベンダー、場合によっては事業部門まで含めて、一貫した情報共有と改善の循環が必要になります(図表2)。

図表2:継続統制のガバナンス

本人確認の継続統制は、単独のIAM(IDアクセス管理)チームでは完結しないものであり、方式の評価や救済、脅威監視、問い合わせ対応、契約運用をつなぐ横断的な運用が必要となります。

まとめ

本人確認の設計は、通常時の最短経路だけを最適化しても完成しません。紛失、故障、誤操作、問い合わせ、苦情、不正の兆候、制度や脅威の変化まで含めて初めて、実際の運用が見えてきます。この点で、DS-511が例外措置と継続評価を正式なプロセスに組み込み、DS-512が回復手段の類型と弱点を整理し、NIST SP 800-63-4が指標と救済対応をデジタルアイデンティティの仕組み全体の一部として位置づけているのは、非常に参考になります。

本人確認の成熟度を「どれだけ強い方式を採ったか」で測らないことです。

むしろ、例外時にどこで詰まり、どこで弱くなり、どこで救済し、どの指標で見直すかが文書化されているかどうかで測るべきです。

平常時だけでなく、失敗時にも説明可能な強度になっているか。その問いに答えられる時、本人確認は初めて「導入済みの機能」から「生きた統制」へ変わることでしょう。

執筆者

小林 公樹

パートナー, PwCコンサルティング合同会社

Email

柴田 健久

ディレクター, PwCコンサルティング合同会社

Email

島﨑 岳歩

シニアマネージャー, PwCコンサルティング合同会社

Email

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

{{filterContent.facetedTitle}}

{{contentList.dataService.numberHits}} {{contentList.dataService.numberHits == 1 ? 'result' : 'results'}}
{{contentList.loadingText}}

本ページに関するお問い合わせ