--- type: guideline title: 本人確認の構成要素と対策基準（本編３章の解説） source: デジタル庁 ds_code: ds-512 category: trust-identity updated: 2026-02-24 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a5e604f3/20260224_resources_standard_guideline_identityverification.zip --- # 本人確認の構成要素と対策基準（本編３章の解説） 本章では、ガイドライン本編の第３章「本人確認における脅威と対策」に関する解説、補足、参考情報を示します。 なお、政府情報システムにおいて主要な選択肢となる本人確認手法の具体例については「別紙１ 身元確認手法の具体例」及び「別紙２ 当人認証手法の具体例」をご覧ください。 ## 身元確認（Identity Proofing）に関する解説 身元確認は、申請者から属性情報を収集することで申請者を一意に識別するとともに、収集した属性情報が真正かつ申請者自身のものであることを本人確認書類により検証することで、申請者が実在かつ生存する人物であることを確認するプロセスです。 ここでは、ガイドライン本編の記載内容のうち、実際の検討において特に留意いただきたい事項について解説します。 ### 身元確認において収集する属性情報の考え方 身元確認において申請者から収集すべき属性情報は、以下の３つの条件を満たす必要があります。 - 第一に、その対象手続が扱う母集団の中で申請者を一意に識別できること。これには複数の属性を組み合わせる場合もあります。 - 第二に、その対象手続や行政サービスを提供するために必要な属性が全て含まれていること。申請者の一意な識別には必要のない情報であっても、サービス提供に必要な情報は身元確認で収集する必要があります。 - 第三に、必要最小限であること。プライバシー保護や個人情報保護の観点からは、申請者から収集する属性情報は必要最小限としなければなりません[^7]。
![](../assets/ds-512-ch01-image3.png)

図 ３‑1　身元確認において収集する属性情報が満たすべき基本条件

### 身元確認において利用可能とする本人確認書類の考え方 対象手続の身元確認においてどのような本人確認書類を利用可能とすべきかについては、次のような多角的な観点から検討することが望まれます。検討の際には、「別紙１　身元確認手法の具体例」の第２章も参考としてください。 - **対象手続の利用者層**：申請者や利用者の様々な属性によって、本人確認書類の取得可否や所持率・普及率が異なります。対象手続が想定している申請者層・利用者層を踏まえた検討が必要です。 - **必要な属性情報**：本人確認書類によって収集できる属性情報が異なるため、「身元確認において収集する属性情報」の検討結果を踏まえ、その属性情報を収集可能な本人確認書類を選択する必要があります。 - **求められる保証レベル**：本人確認書類が備える機能によって、実現可能な身元確認保証レベルが異なるため、対象手続に求められる保証レベルを満たすことのできる本人確認書類を選択する必要があります。 - **信頼可能な発行元**：対象手続にとって、本人確認書類の発行元は信頼可能な組織である必要があります。「公的機関により発行されたもの」を条件とする場合が多いですが、公的機関以外が発行した本人確認書類についても、その発行元が信頼できると判断できる場合には、受け入れ可能とするケースもあります。 - **対象手続の根拠法令等**：行政手続の場合、利用可能な本人確認書類の条件が根拠法令等によって定められている場合があります。 なお、「[４.３](#身元確認手法の選定の考え方本編４２関連)　[身元確認手法の選定の考え方（本編４．２関連）](#身元確認手法の選定の考え方本編４２関連)」で示すように、多くの手続・サービスにおいては、マイナンバーカードを基本としつつ、マイナンバーカード以外の代替手法についても併用を検討することになると想定されます。 ### ビデオベースの身元確認手法における脅威 ビデオベースの身元確認手法では、「プレゼンテーション攻撃」や「ビデオインジェクション攻撃」と呼ばれる、この手法で特有の脅威の考慮が必要です。これらの攻撃への対策は、身元確認に利用する端末やアプリケーションの仕様によって異なるほか、日々進歩する生成AIが攻撃の高度化に関係しているため、本解説書の執筆時点（2026年2月時点）では一律の対策基準を示すことが難しい状況です。 そのため、ビデオベースの身元確認手法の採用を検討する際には、その時点の最新の脅威と対策技術の動向を確認し、必要な対策を判断してください。 #### プレゼンテーション攻撃とは 印刷した写真、タブレット端末に映した映像等を身元確認時にカメラに映すことで、攻撃者が自身の容貌を偽装する攻撃のことを指します。カメラ等のセンサに偽造物等を提示（プレゼンテーション）する攻撃であるため、プレゼンテーション攻撃と呼ばれます。静止画や事前に撮影された動画だけでなく、AI技術を活用しリアルタイムに顔を入れ替えられた映像が用いられる場合もあります。また、攻撃者が精巧に作られた3Dマスクを被ってカメラ越しの身元確認を突破しようとする攻撃例もあります。 プレゼンテーション攻撃は攻撃方法が単純であり、偽装された映像には不自然な点が比較的生じやすい攻撃と言えます。その一方で、身元確認を行うデバイスを侵害せずに攻撃が行われるため、デバイス側のセキュリティ機能による防止・検知が難しいという特徴があります。 #### ビデオインジェクション攻撃とは 攻撃者がカメラや映像処理の途中で偽の映像データを注入することで、本来撮影した映像ではない別の映像データを送信する攻撃です。プレゼンテーション攻撃と同じく、AI技術を活用しリアルタイムに顔を入れ替えられた映像が用いられる場合もあります。 プレゼンテーション攻撃と異なり、デバイス側を侵害して偽のデータを注入する必要があるため、デバイス側のセキュリティ機能による防御や検知による対策を検討することができます。一方、映像の不自然さによる検知はプレゼンテーション攻撃よりも一般に難しくなります。 ### 身元確認におけるプライバシー面の考慮事項 行政機関等における身元確認では、２．４ 3)で示したとおり所掌事務又は業務に必要な場合に限り、利用目的が特定された形で、必要最小限の個人情報を取得することとなります[^8]。連携モデル、非連携モデルのどちらの場合であっても、民間事業者が委託先としてステークホルダーに加わる場合があるため、「誰が」「どのような利用目的」で身元確認のために個人情報を取得するのかを、サービス・業務企画のできるだけ早い段階でのプライバシー影響評価（PIA）等により把握し、リスクを整理することが大切です。

（解説）身元確認におけるプライバシー侵害の可能性

必要以上の取得について

個人情報保護法や根拠法令等に従って個人情報を取得する上では、利用目的を達成する上で必要最小限の取得が求められますが、「念のため」と必要以上に身元確認情報を求めることは、利用者に無用な不信感を与える可能性があります。

不適切な長期保存について

行政機関等の場合は、公文書管理の観点から適切に保存期間を決定し保存する必要がありますが、不必要に保有することは情報漏えい時のリスクが高まります。民間事業者の事例では、サービス退会者の本人確認書類（運転免許証等の画像）が漏えいして問題となったものもあります。

目的外利用について

例えば、身元確認のためと明示して電話番号やメールアドレスを取得した場合、その電話番号やメールアドレスを使って身元確認とは関係のないお知らせやマーケティングを行ってしまうと、利用者の想定とは異なり目的外の利用となるためプライバシーの侵害にあたる可能性があります。

委託の範囲外での個人情報等の利用について

連携モデル、非連携モデルを問わず、外部民間事業者が行政機関等からの委託を受け、身元確認を実施する場合があります。外部民間事業者は行政機関等からの個別契約等によって、当該行政機関等の身元確認に係る委託の範囲での個人情報等の取扱いとすることが必要となります。

上記とは別に、身元確認を行う外部民間事業者が、利用者から直接的に当該外部民間事業者の利用規約やプライバシーポリシーに記載された利用目的によって各種個人情報等を取得し、行政機関等へは身元確認の結果のみを伝える場合、身元確認の過程において収集された個人情報等は当該外部民間事業者の利用目的の範囲で取り扱われることとなるため、行政機関等はPIA等を実施し当該外部民間事業者のリスク分析・評価を十分に実施することが望まれます。
## 当人認証（Authentication）に関する解説 当人認証は、対象手続を利用しようとする申請者が、あらかじめ登録されている者と同一の人物であること（当人性）を確認することです。 ここでは、ガイドライン本編の記載内容のうち、実際の検討において特に留意いただきたい事項について解説します。 ### リアルタイムフィッシングについて 「[２.１](#本人確認に関する直近の動向2026年初頭)　[本人確認に関する直近の動向](#本人確認に関する直近の動向2026年初頭)」でも述べたとおり、昨今は「リアルタイムフィッシング」と呼ばれる攻撃手法が増加しています。 従来の（リアルタイムでない）フィッシングは、利用者を偽サイト上に誘導することによるパスワード等の窃取と、窃取したパスワード等を悪用して実際に不正アクセスを試みる攻撃が独立して非同期的に（ばらばらに）行われることが一般的でした。このような攻撃に対しては、有効期限の短いワンタイムパスワード認証を組み合わせることで、事後的に不正アクセスを試みられた場合でもワンタイムパスワードは期限切れ（又は時間経過による不一致）となるため、不正アクセスを防ぐ対策として機能していました。 しかしながら、リアルタイムフィッシングでは、利用者が偽サイトに入力したパスワード等を、攻撃者がリアルタイムに正規サイトに中継して不正アクセスを試みます。このため、有効期限の短いワンタイムパスワードであっても、利用者の入力と攻撃者の不正利用のタイミングが一致してしまうことで、不正アクセスを防ぐことが困難です。こうした高度な攻撃手法に対抗するためには、フィッシング耐性のある認証方式の導入が重要となります。

参考情報：フィッシングの進化と被害事例

金融取引や行政手続がオンラインで完結する現代において、最も基本的かつ深刻な脅威の一つとして拡大し続けているのがフィッシングです。フィッシングとは、実在する銀行、クレジットカード会社、ECサイト、あるいは公的機関を装ってメールやSMSを送信し、本物そっくりに作られた「偽のWebサイト（フィッシングサイト）」へ誘導する手口です。その目的は、ID/パスワード等の認証情報、クレジットカード番号、銀行口座情報等を入力させ、盗み出すことにあります。

リアルタイムフィッシング

フィッシングは進化しており、「中継サーバ」を用いたリアルタイムフィッシングにより、従来安全とされてきた「多要素認証」すらも突破されてしまいます。攻撃者は、利用者と正規サイトの間に「中継サーバ」として割り込み、利用者が偽サイトに入力したIDやパスワード、ワンタイムパスワード（OTP）をリアルタイムで正規サイトに転送することで、認証を突破してしまいます。

「攻撃の流れ」

![](../assets/ds-512-ch01-image4.png)

この手法により、利用者は「正しい手続をしている」と思い込んだまま、攻撃者によって不正にログインされてしまいます。攻撃者は不正ログイン後に、利用者に対して認証失敗画面を表示することで、利用者は攻撃に気づきにくくなります。

被害事例

フィッシングの脅威は、認証情報の窃取にとどまらず、個人の預金等の資産そのものを狙う段階へと深刻化しています。ここでは、日本国内で発生した被害事例を紹介します。

「インターネットバンキングの不正送金被害」

一つ目は、銀行口座から預金が不正に送金される被害です。警察庁の発表によると、2023年から2024年にかけてインターネットバンキングに係る不正送金被害が過去最悪のペースで急増しました。銀行を装い、「取引制限のお知らせ」などのメールで偽サイトへ誘導し、認証情報を盗み取る手口が横行しています。特筆すべきは、個人だけでなく法人口座も標的になり始めている点です。法人口座は送金限度額が高く設定されていることが多いため、一件あたりの被害額が数百万〜数千万円にのぼるケースもあり、企業の存続に関わる重大なリスクとなっています。

「ネット証券を標的とした資産収奪」

二つ目は、ネット証券会社を装った攻撃です。攻撃により、認証情報だけでなく、出金に必要な「取引パスワード」までもが盗まれています。さらに、株式や投資信託を勝手に大量に購入することで、短時間のうちに株価をつり上げ、攻撃者が利益を得る事例が発生しました。本被害における補償についても話題に上がり、近年で大きく取り挙げられた事例となりました。
### 「フィッシング耐性」を実現できる手段について 当人認証がフィッシングへの耐性を備えることを「フィッシング耐性」と呼びます。本解説書の執筆時点（2026年2月時点）で厳密なフィッシング耐性を有する当人認証手法は、「パスキー」と「PKI（公開鍵基盤）をベースとした認証」の２つが現実的な選択肢です。 #### 「パスキー」について パスキーは、Webサイトから利用者のWebブラウザ等に送られてくるデータ等に、利用者側の鍵（秘密鍵）でデジタル署名を行い、Webサイト側にあらかじめ登録されている対となる鍵（公開鍵）によってデジタル署名の検証を行うことで、利用者側が本物の鍵を持っていることを確認する仕組みです。 パスキーは、そのドメインに紐づけられたものしか使うことができないようにWebブラウザ等によって制御されます。そのため、たとえ利用者がフィッシングメールに騙されて偽サイトにアクセスしてしまっても、偽サイトのドメインでは正規のパスキーを使うことはできません。これにより、パスキーはフィッシングへの耐性をもつ方式とされています。

参考情報：パスワードと比較したパスキーの真の価値

昨今のフィッシングと被害の増加を受けて、フィッシングへの耐性が高いと言われているパスキーへの注目が世界的に高まっています。

パスキーはWebサイトのドメインと紐づけて管理され、異なるドメインでは使うことができないよう制御されます。これによって利用者が偽サイトに誘導されてしまった場合でもログインに必要な情報の窃取を防ぎ、フィッシングを防ぐことができる仕組みとなっています。

Webサイトのドメインを用いて判定するという仕組みについては、一般的な「パスワードマネージャー」でも同じではないかと考える方もいらっしゃるかもしれません。確かにパスキーでなくパスワードを用いていて、ブラウザがドメインで正規のサイトかを判定し、正規のサイトであればパスワードを自動で入力するのであれば、フィッシングへの耐性はパスキー同様にあると捉えられます。

しかしながら、パスワードマネージャーのパスワードはパスキーと比べて幾つかの難点があります。そもそも、Webサイト側からは利用者がパスワードをパスワードマネージャーに保管させて使うことを確認することも強制することもできません。また、同じパスワードを複数のWebサイトで用いてしまっている場合は、たとえパスワードマネージャーに保管していて入力を任せていたとしても、Webサイト側が攻撃者に侵害された場合にパスワードを盗み取られる可能性があります。攻撃者がIDとパスワードの組合せを盗み取って、様々なWebサイトに当該のIDとパスワードを入力してログインを試行するパスワードリスト攻撃によって、既に多くの被害が生じています。パスキーは、Webサイトごとに異なる鍵を使うだけでなく、さらには利用者側とWebサイト側では異なる鍵をそれぞれ持ち合わせるため、Webサイト側が攻撃者に侵害されて盗まれた鍵を不正ログインに使うことはできません。

また、パスワードマネージャーは通常パスワードとWebサイトのドメインを紐づけて管理しますが、利用者が手動のコピー＆ペーストをすれば、紐づけられていないドメインのWebサイトにもパスワードを入力できてしまうため、フィッシングサイトにもパスワードを入力できてしまいます。パスキーでは、登録しているWebサイト以外にはパスキーを使えないように制御されるため、フィッシングサイトによる情報窃取を防ぐことができます。

他方で、パスキーを使えない利用者側の環境もあることや、Webサイト側の改修が必要となるためパスキーの導入が進まないという場合もあります。とはいえ、総合的に見てもセキュリティと、利便性の向上という観点でもパスワードに比べてパスキーに優位性があります。
#### 「PKI（公開鍵基盤）をベースとした認証」について PKIをベースとした認証では、利用者に紐づくクライアント証明書を用いたmTLS（Mutual TLS、相互TLS）を行うことで、フィッシング耐性を備えた当人認証を実現できることが知られています。mTLSでは、サーバ側だけでなくクライアント側（利用者側）にも証明書を発行し、通信の際に双方が互いの証明書を検証することで認証を行う仕組みです。クライアント側とサーバ側の双方で証明書を保持することから、mTLSと呼ばれます。利用者が正規の証明書を保持していない限り認証が成立せず、偽サイトが中継しようとした場合でもフィッシングを防ぐことができます。 ただし、クライアント証明書と鍵ペアを格納したICカードやUSBキー等をあらかじめ利用者側に配付する必要があります。 ### アカウントの回復手法について 当人認証の検討においては、利用者が認証に用いるデバイス等を紛失した場合や、サービスへの不正アクセスを検知した場合等に備えて、アカウントの停止（ロック）と、停止状態からの回復手段を設けておく必要があります。 このとき、採用している当人認証手法よりも強度の低いアカウント回復手段を設けてしまうと、そこを不正アクセス攻撃の起点とされる懸念があるため、アカウント回復手段については十分な注意を払った検討が必要です。 例えば、フィッシング耐性のある「パスキー」を当人認証手法として採用していたとしても、利用者側の操作ミス等によってパスキーを喪失した際のアカウント回復手段が「パスワード認証＋ワンタイムパスワード認証」であった場合、利用者に対して「パスキーを再設定してください」といったフィッシングメールが送られ、騙された利用者が偽サイト上でパスワードとワンタイムパスワードを入力してしまうと、リアルタイムフィッシングによって攻撃者にアカウントを乗っ取られてしまう可能性があります。 したがって、ガイドライン本編ではアカウント回復手段の検討においては、「採用している当人認証手法と同等以上の強度の手法を選択すること」を求めており、具体的な手法の例として以下を示しています。万能な手法は存在せず、いずれの手法も一長一短であるため、対象手続の特性や求められる保証レベルに応じた検討が求められます。 #### 身元確認の再実施 アカウント回復が必要となった場合に、身元確認の再実施を求める方法です。十分な保証レベルの身元確認を行うことで、前述するアカウントの乗っ取りのような脅威を防ぐことができます。ただし、身元確認の再実施は運用負担増やコスト増につながる場合があるほか、利便性への影響についても考慮が必要です。 主な特徴と考慮事項は次のとおりです。 - アカウント回復に起因する脆弱性を生みにくく、リカバリ用の仕組みを別途構築する必要がない。 - 一方、身元確認は一般的にサービス提供側の負担の高い作業であるため、アカウント回復のための身元確認の再実施が大量に必要となるとシステムの運用負担やコスト増の原因となる。 - 身元確認の再実施は、一般に利用者側にとっても時間や手間がかかる作業であり、利便性が高い方法とは言えない場合もあるため、サービスからの離脱を招く（紙・郵送による申請の方が面倒がないと判断され、オンライン手続を諦めてしまう）きっかけになってしまう可能性も懸念される。

参考情報：マイナンバーカードを活用した身元確認の再実施について

従来の「対面による身元確認」や「ビデオベースの身元確認」といった手法では、身元確認の再実施はサービス提供側・利用者側の双方にとって負担の高いプロセスでしたが、マイナンバーカードによる身元確認を行う場合については、従来よりも簡便に身元確認を再実施できる可能性があります。

例として「実物のマイナンバーカードの券面事項入力補助AP」を用いる場合（かつ、容貌確認が不要な場合）であれば、利用者側は実物のマイナンバーカードと暗証番号さえあれば、身元確認の再実施をオンラインで即座に実施することができます。
#### 予備の認証器の登録 アカウント回復が必要となったときに備えて、複数の認証器（予備の認証器）をあらかじめ登録しておく方法です。 主な特徴と考慮事項は次のとおりです。 - サービス提供側は複数の認証器の登録に対応する必要があるが、「ア　身元確認の再実施」よりは低コストで済む可能性がある。また、利用者側にとっても、「ア　身元確認の再実施」よりは利便性が高い。 - 認証器の追加登録や変更が行われた際には、登録されている利用者の連絡先に対してその旨を通知するとともに、変更が有効となるまで一定の時間を設けることで、攻撃が行われた場合でも正規の利用者が検知しサービス側に連絡する猶予が生まれ、アカウントの乗っ取り攻撃のリスクを低減することができる。 - ただし、①同程度の認証強度をもち、②同時に紛失するリスクが低く、③多くの利用者が利用できる、という条件を満たす複数の認証器の組み合わせは限られる[^9]。 - 複数の認証器の登録を強制すると利用者の利便性の低下につながり、登録を任意とすると別のアカウント回復手段も必要となる。また、利用者が全ての認証器を喪失した場合のアカウント回復方法は別途用意する必要がある。 #### リカバリーコードの事前発行 アカウントの登録時に、アカウント回復用のリカバリーコードを発行しておき、アカウント回復が必要となった際にはリカバリーコードの入力を求める方法です。運用の負担や制約が比較的少ない方法と考えられますが、フィッシングに脆弱な点には考慮が必要です。 主な特徴と考慮事項は次のとおりです。 - リカバリーコードは登録時に一度だけ発行される仕組みであるため、後述する「リカバリーコードの必要時発行」と比べると、攻撃者が能動的に不正入手できる手段が比較的少ない。 - 「イ　予備の認証器の登録」と異なり、基本的にはどのような利用者に対しても適用できる。 - 利用者はリカバリーコードを適切に保管しておかなければならないが、アカウント回復の作業は「ア　身元確認の再実施」よりは簡易で済む。 - 利用者がリカバリーコードを紛失した場合のアカウント回復方法は別途用意する必要がある。 - リカバリーコード入力はフィッシングには脆弱であり、「あなたのアカウントが停止されました。以下のリンクからリカバリーコードを入力してください。」といったフィッシングメールによって窃取されてしまう懸念がある。 #### リカバリーコードの必要時発行 アカウント回復が必要となったタイミングで、利用者の求めに応じて登録されている連絡先（住所、電子メールアドレス、携帯電話番号等）に対してリカバリーコードを送信し、その入力を求める方法です。「ウ　リカバリーコードの事前発行」よりも利便性が高い方法ですが、連絡先が乗っ取られた場合のリスクの考慮が必要です。 主な特徴と考慮事項は次のとおりです。 - 「ウ　リカバリーコードの事前発行」と比べて、利用者はリカバリーコードを保管する必要がないという利点がある。 - リカバリーコードの連絡先となる電子メールアドレスや携帯電話番号が攻撃者に乗っ取られた場合、リカバリーコードも不正に入手され、アカウントが連鎖的に乗っ取られるリスクがある。 - 「ウ　リカバリーコードの事前発行」と同様に、フィッシングには脆弱である。 ### パスワード認証に関する留意事項 パスワード認証は「当人認証保証レベル1」に該当する手法です。現時点で多くの行政情報システムで使用されている当人認証手法ですが、「パスワードの使い回し」というサービス提供側でのコントロールが難しい脅威があり、フィッシングに対しても脆弱です。このため、満たすべき当人認証保証レベルが2以上であるシステムの場合、パスワードはもはや採用を検討すべき手法ではありません[^10]。 民間サービスでは、パスキーへの転換が進む等、パスワードレス化の流れが加速しています。また、米国NIST SP 800-63B-4ではパスワード認証に関する要求事項が更に厳格化されており、仮に採用する場合でも、その実装に当たっては十分な検討が求められます。

参考情報：パスワード認証に関する米国NISTの要求事項

2025年8月に改定第4版が発行された米国NIST SP 800-63B-4では、パスワード認証の実装に関して以下のような要求事項が求められています。

政府情報システムにおいてパスワード認証の仕様や実装を検討する際にも、これらの要求事項を参考とすることが望まれます。

  • パスワードの長さは、単要素認証として利用する場合は15文字以上、多要素認証の一要素として利用する場合は8文字以上としなければならない。また、設定可能なパスワードの最大長は少なくとも64文字とすべきである。

  • パスワード設定時に異なる文字種を混在させることを強制してはならない1。

  • 利用者に対して、定期的なパスワードの変更を求めてはならない2。 ただし、パスワードが侵害された証拠がある場合には、パスワードの変更を求めなければならない。

  • パスワードを思い出すための「ヒント」や「秘密の質問」は実装してはならない3。

  • パスワードマネージャーや自動入力機能（オートフィル機能）を利用できるようにしなければならない。パスワードの「貼り付け」についても、自動入力ができない場合を考慮して許可すべきである。

（NIST SP 800-63B-4 「3.1.1. Passwords」より抜粋・要約）

  1. 異なる文字種の混在を強制させることは、攻撃者が予測しやすいパスワードの設定を誘導してしまう弊害があると言われています。↩︎

  2. 定期的な変更も、利用者が覚えやすいパスワードを設定しやすくなり、攻撃者が予測しやすいパスワードの設定を誘導してしまう弊害があると言われています。ただし、複数人で共用するアカウントの場合については、パスワードの定期変更が有効に機能する場合もあります。↩︎

  3. 「ヒント」や「秘密の質問」は、パスワードが本来もつ空間を狭めることで攻撃者の予測可能性を高めてしまったり、本来は秘密情報ではない情報（例：母親の旧姓等）を設定することで、認証に必要な情報を別の手段で調査・推測されてしまったりする懸念があります。↩︎

### 当人認証におけるプライバシー面の考慮事項 なりすまし等によって不正アクセスを受けた場合、登録されているアカウント情報や身元確認情報が漏えいしたときの影響を、事前にPIA等を実施してリスク分析・評価し、適切に当人認証保証レベルを決定することが大切です。 また、当人認証に係る利用目的の範囲とならないような利用や、認証器に含まれる情報によって利用者を不適切に名寄せ・分析することがないようにするなど、当人認証の利用目的についても事前にリスク分析・評価が実施されることが推奨されます。

当人認証におけるプライバシー侵害の可能性

個人情報漏えいの影響について

例えば、登録されているアカウント情報や身元確認情報に生体認証情報や要配慮個人情報（病気、障害の有無等）のような機微性の高い情報が存在する場合、漏えいが起こった際に容易には回復できないプライバシー面への影響が懸念されるため、適切な当人認証手法を検討する必要があります。

目的外利用や不適正な利用について

例えば、どのような行政手続や行政サービスを利用しているか等、認証器の情報から不必要な名寄せや追跡を行うことは、利用者のプライバシーへの影響が懸念され、目的外利用や不適正な利用とみなされる可能性があります。

委託の範囲外での個人情報等の利用について

連携モデル、非連携モデルを問わず、外部民間事業者が行政機関等からの委託を受け、当人認証を実施する場合があります。外部民間事業者は行政機関等からの個別契約等によって、当該行政機関等の当人認証に係る委託の範囲での個人情報等の取扱いとすることが必要となります。

上記とは別に、当人認証を行う外部民間事業者が、利用者から直接的に当該外部民間事業者の利用規約やプライバシーポリシーに記載された利用目的によって各種個人情報等を取得し、行政機関等へは当人認証の成功・失敗の結果（およびその理由）のみを伝える場合、当人認証の過程において収集された個人情報等は当該外部民間事業者の利用目的の範囲で取り扱われることとなるため、行政機関等は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プロバイダと連携する必要がある点に留意してください。