第3回：本人確認をどう連携させるか――DS-511、512とNIST 800-63-4にみるフェデレーション設計

第2回

フェデレーションとは、アイデンティティプロバイダが身元確認や当人認証を実施、属性情報などの確認結果をまとめた「アサーション」と呼ばれる証明情報を別のサービスに安全に渡し、当該サービスがそれを信頼して利用者を扱う仕組みです。

このフェデレーションを使用したアイデンティティ連携について、多くの企業では開発コストやユーザー獲得のしやすさの観点から語られています。こうした観点がビジネスにおいて重要なのは間違いありません。一方でフェデレーションの使用には考慮すべき事項が非常に多く、デジタル庁が公表した「DS-511行政手続等での本人確認におけるデジタルアイデンティティの取扱いに関するガイドライン」（以下、DS-511）や、米国国立標準研究所のガイドライン「NIST 800-63-4」では、身元確認、当人認証、属性連携、アサーション流通をまたぐ信頼連鎖を実現するための重要な設計ポイントとして、フェデレーションを取り上げています。

このうちDS-511では、本人確認の構成要素に「身元確認」「当人認証」「フェデレーション」を挙げた上で、フェデレーションの実装モデルとして連携モデル、非連携モデルを整理しました（図表1）。

図表1：連携モデル、非連携モデル

また、「DS-512行政手続等での本人確認におけるデジタルアイデンティティの取扱に関するガイドライン 解説書」（以下、DS-512）はDS-511の解説書として、なぜフェデレーションを概念として追加したのか、なぜ連携モデルを第一候補とするのか、そしてどのような前提や留意点があるのかを補っています。なお、NIST側でもIAL（アイデンティティ保証レベル）、AAL（認証保証レベル）の他にFAL（Federation Assurance Level：フェデレーションの保証レベル）を分けて扱うことで、身元確認や認証が十分でもフェデレーションが弱ければ全体が崩れることを明確にしています。

1. 見直しの出発点は、「連携すれば楽になる」で止めないこと

DS-511がフェデレーションを独立した構成要素として整理したことには、大きな意味があると考えられます。従来、認証連携は実装方式や運用の話として扱われがちでした。しかし実際には、外部のアイデンティティプロバイダを使う場合、リライングパーティー（アイデンティティプロバイダに本人確認を依拠し、フェデレーションを受ける側）が受け取るのは「その人が本人であるらしい」という曖昧な印象ではなく、身元確認や当人認証の結果、属性情報、保証レベルといった構造化された情報です。ここで押さえておきたいのは、連携は利便性を高める一方、何をどの条件で信頼するのかを事前に合意しなければ新たなリスクを生むということです。

DS-512は、政府情報システムで「連携モデル」を第一候補として検討する方針を補足し、その理由として利用者の利便性向上、セキュリティ強化、コスト削減を挙げています。一度行った身元確認結果や認証基盤を複数サービスで使えるなら、利用者はサービスごとに書類提示や認証器管理を繰り返さずに済みますし、運営側も本人確認機能をサービスごとに重複実装せずに済みます。NIST 800-63-4もまた、フェデレーションは重複しがちであり、コストと時間のかかる本人確認プロセスを減らし、利用者体験を改善する側面があると述べています。

ただしここで押さえておきたいのは、連携モデルが常に正解だと主張しているわけではないということです。DS-511/512では、対象手続に適したプロバイダが存在することを前提としています。必要な保証レベルを満たすアイデンティティプロバイダがないなら、非連携モデルや組み合わせモデルを選ぶべきです。つまりフェデレーションは、実務的には「使えるなら使うべき近道」ではなく、「依拠先の保証を信頼できる時に限り、合理的になる設計選択」だと言えます。

2. フェデレーションで本当に難しいのは、接続ではなく保証の管理

フェデレーションの難所は、SSOを成立させることではありません。DS-511とDS-512がフェデレーション領域で特に注意すべきと整理しているのは、保証レベルの齟齬とアサーションに関する攻撃です。前者は、リライングパーティーが必要とする強度と、アイデンティティプロバイダ側で実施している身元確認や認証の保証が一致していない状態を指します。後者は、アサーションの盗聴、窃取、偽造・改ざん、再利用といった、連携そのものを標的にした攻撃です。

なお、身元確認や認証を強くしても、それだけで安心できるわけではありません。NISTでは、IAL、AAL、FALを分けて扱います。つまり、誰の実在性をどう確かめたか、どの認証器で本人性を確認したか、そしてその結果をリライングパーティーにどう安全に渡すかは、別々に評価しなければならないとしています。フェデレーションが弱ければ、身元確認と認証が強くても、最後の受け渡しで全体が崩れてしまいます。

DS-511も、リライングパーティーが受け取ったアサーションについて、想定するアイデンティティプロバイダから発行されたものであること、第三者により偽造・改ざんされていないこと、自身が要求したリクエストに対して発行されたこと、自身宛てであること、再利用ではないこと、有効期限内であることを検証するよう求めています。NIST SP 800-63Cも同様に、署名、受け取り先の限定（アサーションが特定のサービス宛てであること）、再利用防止（同じ証明情報がもう一度使い回されないこと）を重視し、FAL2以上ではトランザクションがリライングパーティーからの開始であること¹、1つの証明情報を1つのサービス宛てに限定すること²を要求に置いています。実務的には、フェデレーションは「つながっているか」よりも「その接続がどの条件で信頼できるか」が問われる領域だと捉えると、実態に近いと言えます。

これらのことを考えるとフェデレーションのリスク（図表2）は接続の遮断そのものより、保証の意味づけと保護の運用がずれることにあると考えられます。

3. 導入前に握るべきは、プロトコルより責任分界である

ここまで見てきた観点を踏まえると、フェデレーション設計はプロトコル実装の話よりも、むしろ責任分界の話に近いと言えます。

では、フェデレーションの導入前に何を詰めておくべきでしょうか。ここでいくつか紹介します（図表3）。

まず重要なのは、どの属性を連携し、どの水準の保証レベルを最低条件とするかです。これはリライングパーティーが必要とする信頼水準と、アイデンティティプロバイダ側が実際に提供できる保証水準のずれを避けるためです。NIST SP 800-63Cは、リライングパーティーが受け入れる最低限のxALを定め、アイデンティティプロバイダがその結果を証明情報に含めて返す考え方を示しています。

第二に、識別子、鍵、証明情報の検証、有効期間、再利用防止、受け取り先の限定といった、フェデレーションの基礎条件を定めることです。これは、証明情報の改ざん、取り違え、使い回しを防ぎ、連携そのものの安全性を確保するためです。NIST SP 800-63Cでも、FALに応じて受け取り先の限定や再利用防止を求めています。

第三に、保証レベルや運用に変更が生じた場合の通知と合意です。これは当初合意していた信頼条件が、仕様変更や運用変更によって崩れてしまうことを防ぐためです。DS-511では、連携モデルの採用にあたり、対象手続が必要とする保証レベルを満たすアイデンティティプロバイダが存在することを前提に、アイデンティティプロバイダとの信頼関係の確立プロセスで正確性や保証レベルを確認・合意することを求めています。

第四に、障害や不正の兆候が出たときの情報共有です。これは、障害や侵害の影響を早期に把握し、被害拡大を防ぎ、関係者が役割分担に沿って対応できるようにするためです。NIST SP 800-63-4は、デジタルアイデンティティのリスク管理を、情報セキュリティ、不正対策、プライバシー、顧客体験をまたいで捉えるべきだとしています。外部のアイデンティティプロバイダに依拠する場合でも、リライングパーティー側においては依拠条件を定義し、受け取る情報を検証し、異常時の運用を設計する責任が残ります。

フェデレーションは、技術接続の前に「誰が何を担うか」を定義しない限り、便利な仕組みであっても統制としては不安定となるため、これらの論点を設計時に明確にすることが非常に重要です。

まとめ

本人確認を自前で実施するかフェデレーションを使用するかという問いは、実は入り口にすぎません。本当に重要な論点は、本人確認という機能を誰が担い、その結果をどの保証と条件の下で受け取るかです。DS-511はフェデレーションを本人確認の構成要素として明示し、DS-512はその意味と実装上のガイドを示しています。

保証レベルの齟齬を防ぎ、アサーションを守れるか。必要以上の属性を流さず、変更や障害の時にも信頼関係を維持できるか。こうした問いに向き合えて初めて、フェデレーションは単なる接続ではなく、説明責任のある信頼連鎖になります。自社の設計がそこまで言語化できているかどうかが、導入判断の本当の分かれ目となるでしょう。

第4回

¹ 出典：NIST SP 800-63C, FAL2“The federation transaction SHALL be initiated by the RP.”

² NIST SP 800-63C, FAL2“At FAL2, the assertion SHALL be audience restricted to a single RP.”

³ IAL、AAL、FALをまとめて指す表現