【要点抽出】NIST SP800-63-4

ニキヌス

今回は認証系の知見が詰まったNIST SP800-63を読んでいきます。

https://csrc.nist.gov/pubs/sp/800/63/4/ipd

はじめに

本noteでは、OpenIDファウンデーションジャパンによる翻訳版を読んでいます。ただ、翻訳版ではあえて正確に伝えるために単語を英語のまま表記しているのに対し、本noteでは読みやすさのために私なりの便宜的な日本語をあてはめています。
そうした箇所は、「身元確認（Identity Proofing）」といった形で、便宜的な日本語+括弧書きで元の英語　という形で記しています。

何の本？

SP800-53と同様、NISTのSP800シリーズの一つで、Digital Identity Guidelinesというタイトルがついています。
第4版にあたるSP800-63-4のドラフト版が22年12月に出ています。
その翻訳版を、「⺠間事業者向けデジタル本⼈確認ガイドライン 第1.0版」でもお世話になったOpenIDファウンデーションジャパンが出しているので、今回はこちらを読みます。
https://openid-foundation-japan.github.io/800-63-4/index.ja.html

構成は？

SP800-63は、以下の4冊構成です。今回はSP800-63を読みます。

  • 63：リスクアセスメントの方法論やAssurance Levelの選び方

  • 63A：識別（Identity）に関する要件

  • 63B：認証（Authentication）に関する要件

  • 63C：フェデレーションに関する要件

本書（SP800-63）の構成は以下の通りです。

  1. Purpose

  2. Introduction

  3. Definitions and Abbreviations

  4. Digital Identity Model

  5. Digital Identity Risk Management

前提知識

本書に入る前に、知っておいた方が捗るポイントを書きます。

全般にわたってInformative（前提的に知っておいてね的なもの）と、Normative（こうすべし的なもの）が区別されて書かれています。
本書は５．だけがNormativeで、他はInformativeです。

Normativeなセクションには、要件の強度を表す記法が定められています。
・SHALL／SHALL NOT
　絶対やれ、絶対やるな　最も厳しい
・SHOUD／SHOUD NOT
　他にも色々選択肢が考えられるけど特にこれがいいと思う。
　できてなくても怒らないけどおすすめ。
・MAY／MAY NOT
　やってもいい、やらなくてもいい程度。まぁいいんじゃないですか的な。
・CAN／CANNOT
　やったほうがいいかどうかではなく、できる（能力がある）かどうか。

２．Introduction

名前の通り前置き的な内容なので多くは割愛しますが、知っておきたいポイントは以下です。

  • 本書で「人」に触れる時は個人を意味し、法人は指さないとしています。

  • 本書はDigital Identityのタイトルの通り、物理的なアクセスに関する話はスコープ外としています。

  • 63A、B、Cの位置づけ（構成は？を参照）や、Digital Identityの世界で考慮すべき4つの要素（Security, Privacy, Equity, Usability)について触れています。
    このうちEquityは初登場する用語で、直訳すると「公平」です。
    本書では、 有色人種、宗教的少数派、LGBTQ+、障害を持つ方などに対しても、一貫した体系的かつ公正で公平な扱いを考慮することを求めています。例えば、宗教などの理由で顔を出せない人に対して「顔認証を前提とする当社のサービスは使わせません」みたいなことはしないように、皆が使えるにしようね。的な観点かと思います。

３．Definitions and Abbreviations

用語一覧なので割愛します

４．Digital Identity Model

３．は割愛したものの、この先に進む上で最低限理解しておかねばならない役割や機能があります。
このセクションでは最初にその5つのキーワードを示しています。

【注意】以下の解説は、おそらくDigital Identityのプロが見ると「違う」と言いたくなる部分があると思います。あくまで私がざっくり理解するために表現した結果なので、正確な情報を知りたい方は原文をご参照ください。

Subject
認証のプロセスを試みる主体です。アクセスしてくるヤツです。
本当は、Subjectは人だけでなく物の場合もありますが、ここでは分かりやすさのために「人」前提で書きます。
Subjectは、その状態により3つの呼び名を持ちます。

  • Applicant
    まだサービスのアカウントを持っていない状態    。
    これからIdentity Proofing（身元確認）をする。
    銀行でいえば「あの～口座つくりたいんですけど」な人。
    #ここでは便宜上「登録希望者」と呼んでおきます

  • Subscriber
    サービスのアカウントを持った状態    。
    銀行でいえば口座を持ってる人。
    #ここでは便宜上「登録済利用者」と呼んでおきます

  • Claimant
    サービスを使うために、認証を試みている状態    。
    銀行でいえばATMに暗証番号を入れようとしている人。
    #ここでは便宜上「認証希望者」とか呼んでおきます」

    補足として、Subsciberは、身元確認や認証が終わった人。というくくりのようです。

Credential Service Provider (CSP)
登録希望者（Applicant）の身元確認をしたり、登録済利用者のアカウント（Subscriber Account）にAuthenticator（例えばパスワード。実際には多分ハッシュ化したパスワード）を紐づけたりします。
「お客様台帳を管理する役割」的なイメージです。

Verifier
認証希望者（Claimant）のAuthenticatorが提示してきた認証情報（例えばパスワード）をチェックして認証します。一般に「認証システム」「認証基盤」とか呼ばれるのはCSPとVerifierをまとめたものかなと思います。

Relying Party (RP)
サービスの提供者です。RP自身は認証機能を持たないので、ユーザ(Claimant）からアクセス要求が来たら「認証してきてよ」とVerifierに行くように仕向けます。

Identity Provider (IdP)
これはフェデレーション方式の時に登場します。
実体はCSP + Verifierであり、認証機能と、RPに対してアサーション（ユーザの認証情報や、アトリビュートと呼ばれるユーザの属性情報等を集めたもの）を連携する役割を持ちます。

これらの役割は、以下の図のように連携して動作します。
1つ目の図がフェデレーション無し、2つ目がフェデレーション有りです。

Figure 1. Non-federated Digital Identity Model Example より


Figure 2. Federated Digital Identity Model Exampleより

この後、本セクションでは「Enrollment and Identity Proofing」「Authentication and Lifecycle Management」「Federation and Assertions」（つまりSP800-63A、63B、63Cで扱うそれぞれの処理）の概要説明がありますが、次回以降のnoteで触れます。

５．Digital Identity Risk Management

本書では唯一Normativeとされているセクションです。
タイトルの通り、Digital Identityにおけるリスクマネジメントの進め方を解説しています。
リスクマネジメントを行う目的は、識別・認証・フェデレーションに関して「どれだけしっかりやらねばならんか」のレベル感の見極めです。
SP800-63A,63B,63CでAAL,IAL,FALといった分類が登場し、AAL1～3みたいな感じでレベル感と要件が定義されています。
自分の認証システムはAALいくつの要件なの？IALいくつなの？といったことを最初に知る必要があるのです。

リスクマネジメントは以下4ステップで構成されます。

（１）初期影響評価(Impact Assessment）の実施
（２）初期 Assurance Levels の選択
（３）Assurance Level の決定の調整と文書化
（４）継続的な評価と改善
　　　#本noteでは（３）に混ぜて記載

（１）初期影響評価(Impact Assessment）の実施

考えている認証システムに問題があった場合、誰にどんな影響をどの程度及ぼすか？を考えます。
「誰に」については、自組織だけでなく利用者である個人を必ず含めます（SHALL）。他にも影響を受けそうな登場人物がいる場合はそれらも洗い出し（SHOULD）、文書化します（SHALL）。
「どんな影響」については、様々な観点から掘り下げます。
本書では以下6つのカテゴリを少なくとも評価することとしています（SHALL）。

  • Damage to mission delivery / ミッション遂行に対する損害

  • Damage to trust or reputation / 信用や評判に対する損害

  • Loss of sensitive information / 機密情報の損失

  • Damage to or loss of economic stability / 経済的安定の損害又は損失

  • Loss of life or damage to safety, health, or environmental stability / 生命の損失, 安全・健康・環境的安定に対する損害

  • Noncompliance with laws, regulations, and/or contractual obligations / 法律, 規制, 契約上の義務のすべて, または一部の不履行

「どの程度」については、High/Moderate/Lowの3段階による定性的評価です。Highは「深刻または壊滅的」、Moderateは「重大な」、Lowは「限定的」という意味です。
本書では、さきほどの6カテゴリごとにHigh～Lowとはこんな状態という例を挙げてますが、抽象的な世界なので具体的な判断基準は組織やミッションによると思います。
つまり、これを表にすると、こうなります。

Table 1 Impact Categories より

ここまでに洗い出した情報や定義をもとに、「誰に」「どんな影響を」「どの程度」の影響を与えるか決めていく影響分析（Impact Analysis）を、Indentity Proofing、Authentication、Federationそれぞれに対して行います。
例えば、Indentity Proofingの影響例は以下です。
2点目は4版から加わったEquityの考え方が表れています。

  • サービスを異なる Subject に提供してしまうことによる影響 (例: Attacker が他人になりすませてしまう)

  • Identity Proofing の過程で Subject が受ける偏見を含む障壁のために, 適格な Subject にサービスが提供されないことによる影響.

  • Identity Proofing プロセスをサポートするための過剰な情報収集と保持の影響.

（２）初期 Assurance Levels の選択

先ほど評価した影響度をもとに、Assurance Levelを決めます（SHALL）。
Assurance Levelとは以下の3つです。

  • IAL：Identity ProofingのAssurance Level。
    登録希望者（Applicant）が提示してくる身元確認のための証明物をどの程度しっかり確認するのか。

  • AAL：AuthenticationのAssurance Level。
    認証希望者（Claimant）が提示してくるパスワードなどの認証情報をどの程度しっかり確認するのか。

  • FAL：FederationのAssurance Level。
    フェデレーションプロセスそのものの頑強性。
    FALは、フェデレーション方式を採用していない場合は決める必要はありません。

上記のxALはそれぞれ3つのレベルが決められています。
ここは第3版から結構変わっていて、読んでもイメージがつかなかったものもありますので、誤りがあるかもしれません。
詳細は原文をご確認ください。

IALのレベルは以下です。
(IALはSP800-63の記載よりも63Aが分かりやすかったので、そちらを参考にしています）

  • IAL０：登録希望者（Applicant）の自己申告のみ。身元確認や実在性の確認はしない（※）

  • IAL１：登録希望者（Applicant)が提出する、身元を証明するモノ（Identity Evidence・例えば免許証など）が有効であることを信頼できるソースに確認（Validation）することで、身元確認や実在性の確認を行う。

  • IAL２：IAL1より強力なエビデンスを用いて身元確認や実在性の確認を行う（具体的な記述は無し）

  • IAL３：訓練を受けたCSP担当者が、対面または対面と同等レベルに保護されたオンラインセッション（Supervised Remote Identity Proofing Session）を通して身元確認や実在性の確認を行う

    ※IALに限り、IAL0というレベルが登場します。これは第3版まではなかったため、あえて身元を証明しないケースを定義したようです。

AALのレベルは以下です。

  • AAL１：１要素認証を用いる

  • AAL２：２要素認証を用いる

  • AAL３：フィッシング耐性を持つ認証要素を用いる

FALのレベルは以下です。

  • FAL１：IdPが発行するアサーションを、登録済利用者（Subscriber）経由でRPに提出し、RPはそれを確認する

  • FAL２：IdPが発行するアサーションを、直接RPに連携する。

  • FAL３：Idpが発行するアサーションに加えて、登録済利用者（Subscriber）がRPに対して直接追加の認証を行う。

xALのレベルの選び方について、IALを例に記載します。
前提として、そもそもRPにとって身元確認が必ずしも必須とは限りません。
サービスの重要性によって、身元確認しない、あるいは自己申請を信じるようなパターン（メールアドレスだけでユーザ登録するようなケース）もありえます。
身元確認が必要だと判断した場合は、それが失敗した時の影響を検討し、その大きさに応じて、つまりリスクベースアプローチによってIALを決めます（SHALL）。
影響度がLowならIAL１，ModerateならIAL２、HighならIAL３といった形です。
この考え方はAAL、FALでも同様です。

（３）Assurance Levelの決定の調整と文書化

先ほど決めたxALは初期Assurance Levelと呼ぶものですが、本書ではこれを継続的に調整することを求めています。
この際、ガバナンスの効いた体制下で（SHALL）、xALの選択による影響を部門横断的に評価し（SHOULD）、xALを修正すると決めた際の妥当性を含む調整プロセス全てを文書化します（SHALL）。
Assurance Levelの調整は、少なくとも、２．で述べた4つの要素（Security, Pricacy, Equity, Usability）への影響を評価する必要があります（SHALL）。

Assurance Levelが決まったら、原則的にはそれぞれのレベルに求めらる要件を満たす必要があります（SHOULD)。しかし、これが満たせない場合は、代替策（Compensating Controls）を講じる手もあります（MAY）。
Normative要件から逸脱する場合は、その理由と、元々の要件が意図していたリスクに対してどんな代替策を選択するか、あるいは残存リスクが残る場合はその内容を文書化します（SHALL）。
あるいは、Normative要件に追加してプラスαの対策を講じる場合もあります。こうした補足的な対策（Supplemental Controls）についても、上述の「４つの要素」への影響を評価します（SHALL）。

こうした一連のリスクマネジメントプロセスの結果を文書化します。文書には少なくとも以下が含まれます。

  • 初期影響調査の結果

  • 初期の xAL 評価

  • 調整された xAL と当初評価された xAL が異なる場合, 調整されたxALとその根拠

  • すべての代替策とその比較可能性, または代替策に関連する残存リスク

  • すべての補足的な対策

リスクマネジメント全般に言える話として、一度やったら終わりではなく、継続的に見直す必要があります。
また、セキュリティチームや脅威インテリジェンスチーム等、様々なチームからのインプット（IoC等）を得ることで認証まわりの仕組みはより強固に守ることができるため、横連携を大切にすることも書かれています（SHOULD）。

次回以降、SP800-63A、B、Cをそれぞれ読んでいきます。
SP800-63-4：こちら（この記事）
SP800-63A-4：こちら
SP800-63B-4（前編）：こちら
SP800-63B-4（後編）：こちら
SP800-63C-4（前編）：こちら
SP800-63C-4（後編）：こちら

＊＊＊はじめての方へ＊＊＊
これは何のnoteだ？と思われた方はこちらをご覧ください。
これまでにまとめたガイドライン類の一覧はこちら

この記事が気に入ったらサポートをしてみませんか？