本人確認の構成要素と対策基準（本編３章の解説）

本章では、ガイドライン本編の第３章「本人確認における脅威と対策」に関する解説、補足、参考情報を示します。

なお、政府情報システムにおいて主要な選択肢となる本人確認手法の具体例については「別紙１身元確認手法の具体例」及び「別紙２当人認証手法の具体例」をご覧ください。

身元確認（Identity Proofing）に関する解説

身元確認は、申請者から属性情報を収集することで申請者を一意に識別するとともに、収集した属性情報が真正かつ申請者自身のものであることを本人確認書類により検証することで、申請者が実在かつ生存する人物であることを確認するプロセスです。

ここでは、ガイドライン本編の記載内容のうち、実際の検討において特に留意いただきたい事項について解説します。

身元確認において収集する属性情報の考え方

身元確認において申請者から収集すべき属性情報は、以下の３つの条件を満たす必要があります。

第一に、その対象手続が扱う母集団の中で申請者を一意に識別できること。これには複数の属性を組み合わせる場合もあります。
第二に、その対象手続や行政サービスを提供するために必要な属性が全て含まれていること。申請者の一意な識別には必要のない情報であっても、サービス提供に必要な情報は身元確認で収集する必要があります。
第三に、必要最小限であること。プライバシー保護や個人情報保護の観点からは、申請者から収集する属性情報は必要最小限としなければなりません[^7]。

身元確認において利用可能とする本人確認書類の考え方

対象手続の身元確認においてどのような本人確認書類を利用可能とすべきかについては、次のような多角的な観点から検討することが望まれます。検討の際には、「別紙１　身元確認手法の具体例」の第２章も参考としてください。

対象手続の利用者層：申請者や利用者の様々な属性によって、本人確認書類の取得可否や所持率・普及率が異なります。対象手続が想定している申請者層・利用者層を踏まえた検討が必要です。
必要な属性情報：本人確認書類によって収集できる属性情報が異なるため、「身元確認において収集する属性情報」の検討結果を踏まえ、その属性情報を収集可能な本人確認書類を選択する必要があります。
求められる保証レベル：本人確認書類が備える機能によって、実現可能な身元確認保証レベルが異なるため、対象手続に求められる保証レベルを満たすことのできる本人確認書類を選択する必要があります。
信頼可能な発行元：対象手続にとって、本人確認書類の発行元は信頼可能な組織である必要があります。「公的機関により発行されたもの」を条件とする場合が多いですが、公的機関以外が発行した本人確認書類についても、その発行元が信頼できると判断できる場合には、受け入れ可能とするケースもあります。
対象手続の根拠法令等：行政手続の場合、利用可能な本人確認書類の条件が根拠法令等によって定められている場合があります。

なお、「４.３　身元確認手法の選定の考え方（本編４．２関連）」で示すように、多くの手続・サービスにおいては、マイナンバーカードを基本としつつ、マイナンバーカード以外の代替手法についても併用を検討することになると想定されます。

ビデオベースの身元確認手法における脅威

ビデオベースの身元確認手法では、「プレゼンテーション攻撃」や「ビデオインジェクション攻撃」と呼ばれる、この手法で特有の脅威の考慮が必要です。これらの攻撃への対策は、身元確認に利用する端末やアプリケーションの仕様によって異なるほか、日々進歩する生成AIが攻撃の高度化に関係しているため、本解説書の執筆時点（2026年2月時点）では一律の対策基準を示すことが難しい状況です。

そのため、ビデオベースの身元確認手法の採用を検討する際には、その時点の最新の脅威と対策技術の動向を確認し、必要な対策を判断してください。

プレゼンテーション攻撃とは

印刷した写真、タブレット端末に映した映像等を身元確認時にカメラに映すことで、攻撃者が自身の容貌を偽装する攻撃のことを指します。カメラ等のセンサに偽造物等を提示（プレゼンテーション）する攻撃であるため、プレゼンテーション攻撃と呼ばれます。静止画や事前に撮影された動画だけでなく、AI技術を活用しリアルタイムに顔を入れ替えられた映像が用いられる場合もあります。また、攻撃者が精巧に作られた3Dマスクを被ってカメラ越しの身元確認を突破しようとする攻撃例もあります。

プレゼンテーション攻撃は攻撃方法が単純であり、偽装された映像には不自然な点が比較的生じやすい攻撃と言えます。その一方で、身元確認を行うデバイスを侵害せずに攻撃が行われるため、デバイス側のセキュリティ機能による防止・検知が難しいという特徴があります。

ビデオインジェクション攻撃とは

攻撃者がカメラや映像処理の途中で偽の映像データを注入することで、本来撮影した映像ではない別の映像データを送信する攻撃です。プレゼンテーション攻撃と同じく、AI技術を活用しリアルタイムに顔を入れ替えられた映像が用いられる場合もあります。

プレゼンテーション攻撃と異なり、デバイス側を侵害して偽のデータを注入する必要があるため、デバイス側のセキュリティ機能による防御や検知による対策を検討することができます。一方、映像の不自然さによる検知はプレゼンテーション攻撃よりも一般に難しくなります。

身元確認におけるプライバシー面の考慮事項

行政機関等における身元確認では、２．４ 3)で示したとおり所掌事務又は業務に必要な場合に限り、利用目的が特定された形で、必要最小限の個人情報を取得することとなります[^8]。連携モデル、非連携モデルのどちらの場合であっても、民間事業者が委託先としてステークホルダーに加わる場合があるため、「誰が」「どのような利用目的」で身元確認のために個人情報を取得するのかを、サービス・業務企画のできるだけ早い段階でのプライバシー影響評価（PIA）等により把握し、リスクを整理することが大切です。

当人認証（Authentication）に関する解説

当人認証は、対象手続を利用しようとする申請者が、あらかじめ登録されている者と同一の人物であること（当人性）を確認することです。

ここでは、ガイドライン本編の記載内容のうち、実際の検討において特に留意いただきたい事項について解説します。

リアルタイムフィッシングについて

「２.１　本人確認に関する直近の動向」でも述べたとおり、昨今は「リアルタイムフィッシング」と呼ばれる攻撃手法が増加しています。

従来の（リアルタイムでない）フィッシングは、利用者を偽サイト上に誘導することによるパスワード等の窃取と、窃取したパスワード等を悪用して実際に不正アクセスを試みる攻撃が独立して非同期的に（ばらばらに）行われることが一般的でした。このような攻撃に対しては、有効期限の短いワンタイムパスワード認証を組み合わせることで、事後的に不正アクセスを試みられた場合でもワンタイムパスワードは期限切れ（又は時間経過による不一致）となるため、不正アクセスを防ぐ対策として機能していました。

しかしながら、リアルタイムフィッシングでは、利用者が偽サイトに入力したパスワード等を、攻撃者がリアルタイムに正規サイトに中継して不正アクセスを試みます。このため、有効期限の短いワンタイムパスワードであっても、利用者の入力と攻撃者の不正利用のタイミングが一致してしまうことで、不正アクセスを防ぐことが困難です。こうした高度な攻撃手法に対抗するためには、フィッシング耐性のある認証方式の導入が重要となります。

「フィッシング耐性」を実現できる手段について

当人認証がフィッシングへの耐性を備えることを「フィッシング耐性」と呼びます。本解説書の執筆時点（2026年2月時点）で厳密なフィッシング耐性を有する当人認証手法は、「パスキー」と「PKI（公開鍵基盤）をベースとした認証」の２つが現実的な選択肢です。

「パスキー」について

パスキーは、Webサイトから利用者のWebブラウザ等に送られてくるデータ等に、利用者側の鍵（秘密鍵）でデジタル署名を行い、Webサイト側にあらかじめ登録されている対となる鍵（公開鍵）によってデジタル署名の検証を行うことで、利用者側が本物の鍵を持っていることを確認する仕組みです。

パスキーは、そのドメインに紐づけられたものしか使うことができないようにWebブラウザ等によって制御されます。そのため、たとえ利用者がフィッシングメールに騙されて偽サイトにアクセスしてしまっても、偽サイトのドメインでは正規のパスキーを使うことはできません。これにより、パスキーはフィッシングへの耐性をもつ方式とされています。

「PKI（公開鍵基盤）をベースとした認証」について

PKIをベースとした認証では、利用者に紐づくクライアント証明書を用いたmTLS（Mutual TLS、相互TLS）を行うことで、フィッシング耐性を備えた当人認証を実現できることが知られています。mTLSでは、サーバ側だけでなくクライアント側（利用者側）にも証明書を発行し、通信の際に双方が互いの証明書を検証することで認証を行う仕組みです。クライアント側とサーバ側の双方で証明書を保持することから、mTLSと呼ばれます。利用者が正規の証明書を保持していない限り認証が成立せず、偽サイトが中継しようとした場合でもフィッシングを防ぐことができます。

ただし、クライアント証明書と鍵ペアを格納したICカードやUSBキー等をあらかじめ利用者側に配付する必要があります。

アカウントの回復手法について

当人認証の検討においては、利用者が認証に用いるデバイス等を紛失した場合や、サービスへの不正アクセスを検知した場合等に備えて、アカウントの停止（ロック）と、停止状態からの回復手段を設けておく必要があります。

このとき、採用している当人認証手法よりも強度の低いアカウント回復手段を設けてしまうと、そこを不正アクセス攻撃の起点とされる懸念があるため、アカウント回復手段については十分な注意を払った検討が必要です。

例えば、フィッシング耐性のある「パスキー」を当人認証手法として採用していたとしても、利用者側の操作ミス等によってパスキーを喪失した際のアカウント回復手段が「パスワード認証＋ワンタイムパスワード認証」であった場合、利用者に対して「パスキーを再設定してください」といったフィッシングメールが送られ、騙された利用者が偽サイト上でパスワードとワンタイムパスワードを入力してしまうと、リアルタイムフィッシングによって攻撃者にアカウントを乗っ取られてしまう可能性があります。

したがって、ガイドライン本編ではアカウント回復手段の検討においては、「採用している当人認証手法と同等以上の強度の手法を選択すること」を求めており、具体的な手法の例として以下を示しています。万能な手法は存在せず、いずれの手法も一長一短であるため、対象手続の特性や求められる保証レベルに応じた検討が求められます。

身元確認の再実施

アカウント回復が必要となった場合に、身元確認の再実施を求める方法です。十分な保証レベルの身元確認を行うことで、前述するアカウントの乗っ取りのような脅威を防ぐことができます。ただし、身元確認の再実施は運用負担増やコスト増につながる場合があるほか、利便性への影響についても考慮が必要です。

主な特徴と考慮事項は次のとおりです。

アカウント回復に起因する脆弱性を生みにくく、リカバリ用の仕組みを別途構築する必要がない。
一方、身元確認は一般的にサービス提供側の負担の高い作業であるため、アカウント回復のための身元確認の再実施が大量に必要となるとシステムの運用負担やコスト増の原因となる。
身元確認の再実施は、一般に利用者側にとっても時間や手間がかかる作業であり、利便性が高い方法とは言えない場合もあるため、サービスからの離脱を招く（紙・郵送による申請の方が面倒がないと判断され、オンライン手続を諦めてしまう）きっかけになってしまう可能性も懸念される。

予備の認証器の登録

アカウント回復が必要となったときに備えて、複数の認証器（予備の認証器）をあらかじめ登録しておく方法です。

主な特徴と考慮事項は次のとおりです。

サービス提供側は複数の認証器の登録に対応する必要があるが、「ア　身元確認の再実施」よりは低コストで済む可能性がある。また、利用者側にとっても、「ア　身元確認の再実施」よりは利便性が高い。
認証器の追加登録や変更が行われた際には、登録されている利用者の連絡先に対してその旨を通知するとともに、変更が有効となるまで一定の時間を設けることで、攻撃が行われた場合でも正規の利用者が検知しサービス側に連絡する猶予が生まれ、アカウントの乗っ取り攻撃のリスクを低減することができる。
ただし、①同程度の認証強度をもち、②同時に紛失するリスクが低く、③多くの利用者が利用できる、という条件を満たす複数の認証器の組み合わせは限られる[^9]。
複数の認証器の登録を強制すると利用者の利便性の低下につながり、登録を任意とすると別のアカウント回復手段も必要となる。また、利用者が全ての認証器を喪失した場合のアカウント回復方法は別途用意する必要がある。

リカバリーコードの事前発行

アカウントの登録時に、アカウント回復用のリカバリーコードを発行しておき、アカウント回復が必要となった際にはリカバリーコードの入力を求める方法です。運用の負担や制約が比較的少ない方法と考えられますが、フィッシングに脆弱な点には考慮が必要です。

主な特徴と考慮事項は次のとおりです。

リカバリーコードは登録時に一度だけ発行される仕組みであるため、後述する「リカバリーコードの必要時発行」と比べると、攻撃者が能動的に不正入手できる手段が比較的少ない。
「イ　予備の認証器の登録」と異なり、基本的にはどのような利用者に対しても適用できる。
利用者はリカバリーコードを適切に保管しておかなければならないが、アカウント回復の作業は「ア　身元確認の再実施」よりは簡易で済む。
利用者がリカバリーコードを紛失した場合のアカウント回復方法は別途用意する必要がある。
リカバリーコード入力はフィッシングには脆弱であり、「あなたのアカウントが停止されました。以下のリンクからリカバリーコードを入力してください。」といったフィッシングメールによって窃取されてしまう懸念がある。

リカバリーコードの必要時発行

アカウント回復が必要となったタイミングで、利用者の求めに応じて登録されている連絡先（住所、電子メールアドレス、携帯電話番号等）に対してリカバリーコードを送信し、その入力を求める方法です。「ウ　リカバリーコードの事前発行」よりも利便性が高い方法ですが、連絡先が乗っ取られた場合のリスクの考慮が必要です。

主な特徴と考慮事項は次のとおりです。

「ウ　リカバリーコードの事前発行」と比べて、利用者はリカバリーコードを保管する必要がないという利点がある。
リカバリーコードの連絡先となる電子メールアドレスや携帯電話番号が攻撃者に乗っ取られた場合、リカバリーコードも不正に入手され、アカウントが連鎖的に乗っ取られるリスクがある。

「ウ　リカバリーコードの事前発行」と同様に、フィッシングには脆弱である。

パスワード認証に関する留意事項

パスワード認証は「当人認証保証レベル1」に該当する手法です。現時点で多くの行政情報システムで使用されている当人認証手法ですが、「パスワードの使い回し」というサービス提供側でのコントロールが難しい脅威があり、フィッシングに対しても脆弱です。このため、満たすべき当人認証保証レベルが2以上であるシステムの場合、パスワードはもはや採用を検討すべき手法ではありません[^10]。

民間サービスでは、パスキーへの転換が進む等、パスワードレス化の流れが加速しています。また、米国NIST SP 800-63B-4ではパスワード認証に関する要求事項が更に厳格化されており、仮に採用する場合でも、その実装に当たっては十分な検討が求められます。

当人認証におけるプライバシー面の考慮事項

なりすまし等によって不正アクセスを受けた場合、登録されているアカウント情報や身元確認情報が漏えいしたときの影響を、事前にPIA等を実施してリスク分析・評価し、適切に当人認証保証レベルを決定することが大切です。

また、当人認証に係る利用目的の範囲とならないような利用や、認証器に含まれる情報によって利用者を不適切に名寄せ・分析することがないようにするなど、当人認証の利用目的についても事前にリスク分析・評価が実施されることが推奨されます。

フェデレーション（Federation）に関する解説

フェデレーションにおける主な脅威の解説

前述のとおり、フェデレーションを使った連携モデルには多くのメリットがあります。他方、フェデレーションには特有の脅威や考慮事項もあり、適切な実装・運用がなされなかった場合にはリスクにつながります。

ガイドライン本編では、主な脅威として「保証レベルの齟齬」と「アサーションに関する攻撃」を示しています。これらの脅威を理解した上で、フェデレーションの適切な実装や運用を行うことが必要です。

保証レベルの齟齬

フェデレーションにおいて、対象手続（依拠当事者[^11]）が本来必要とする保証レベルと、IDプロバイダで実際に実施されている本人確認手法が満たす保証レベルとの間に不一致が生じることを指します。

IDプロバイダが提供する本人確認手法の仕様や保証レベルを依拠当事者側が十分に把握できていなかったり、フェデレーションによる運用開始後にIDプロバイダ側の本人確認手法の仕様や運用が変更されたりすることで、齟齬が生じる可能性があります。保証レベルの齟齬が生じた場合、依拠当事者側が本来検知しなければならない攻撃を検知できず、攻撃の起点として悪用されるリスクがあります。

このような保証レベルの齟齬を防ぐためには、依拠当事者側が要求する保証レベルとIDプロバイダによって提供される保証レベルの一致を「信頼関係の確立」プロセスによって確認・合意することが必要です。また、合意事項が認識なく変更されることを防ぐため、本人確認に関する機能、仕様、運用等に変更が生じる場合はIDプロバイダから依拠当事者に事前共有することを定めたり、合意事項が実際に実装されていることを定期的に検査したりするなどの対策も考えられます。

アサーションに関する攻撃

IDプロバイダから依拠当事者に対して発行されるアサーションが、盗聴・窃取・偽造・改ざん・再利用されることで、アサーションに含まれる利用者の個人情報を窃取されたり、アサーションを使って依拠当事者に対するなりすまし等の攻撃が行われたりする懸念があります。

アサーションに関する攻撃への対策は、IDプロバイダと依拠当事者との間で安全な連携のための設定を行った上で、詳細についてはフェデレーションプロトコルの技術標準に則って実装することが一般的です。

フェデレーションに関する主要な技術標準

フェデレーションを実現するための主要な技術標準として、OpenID ConnectとSAML（Security Assertion Markup Language）があります。これらの標準を適切に活用することで、フェデレーションの安全性と利便性を高めることが可能となります。

なお、どちらの標準を採用するかはIDプロバイダ側の対応状況等に依存しますが、後述するフェデレーションのトランザクションの開始に関する対策基準を満たすためには、OpenID Connectを候補とすることが推奨されます。

SAMLを利用する際の留意事項について

ガイドライン本編では、アサーションに関する攻撃への基本的な耐性を確保するため、フェデレーションのトランザクションは依拠当事者側から開始することを原則としています。

フェデレーションによる連携は、ID プロバイダが依拠当事者に対してアサーションを発行することによって行うこと。

アサーションに関する攻撃への基本的な耐性を確保するため、**フェデレーションのトランザクションは原則として依拠当事者側から開始すること。**ただし、連携が閉域網内で行われる場合など第三者による攻撃のリスクが低いとみなせる場合には、IDプロバイダ側からトランザクションを開始する方式としてもよい。

（ガイドライン本編「表３-15 アサーションに関する対策基準」より）

しかしながら、SAMLではフェデレーショントランザクションを依拠当事者側ではなくIDプロバイダ側から開始する方式での実装も少なくありません。

SAMLを利用する場合には、上記の対策基準を満たすために依拠当事者側からフェデレーショントランザクションを開始する方式での実装とするか、閉域網内で連携を行う等攻撃リスクが低いとみなせる環境においてIDプロバイダと連携する必要がある点に留意してください。