Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SP800-63-4 Digital Identity Guidelines (Main)

Noboru Kurumai
January 09, 2024
60

SP800-63-4 Digital Identity Guidelines (Main)

OpenID BizDay #16 - NIST SP800-63-4 (Draft) で発表したスライドです
https://openid.connpass.com/event/274482/

Noboru Kurumai

January 09, 2024
Tweet

Transcript

  1. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. ⾃⼰紹介

    1 ໊લɿ ंҪ ొ /PCPSV,VSVNBJ ϙδγϣϯɿ γχΞιϦϡʔγϣϯΤϯδχΞ ܦྺɿ ɾύοέʔδιϑτ։ൃ ɾΫϥ΢υαʔϏεΤϯδχΞ ɾ$JSDMF$* ɾ5SBOTNJU4FDVSJUZ ݱࡏ
  2. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. NIST

    SP800-63とは(Abstract) n 本ガイドライン群は, Digital Identity サービスを実装する連邦機関に対する技術的要 件を提供するものであり, それ以外の条件下での標準仕様の開発・利⽤に対する制約を 意図したものではない. n 本ガイドライン群は, 政府機関がネットワークを介して提供する情報システムを利⽤す るユーザー (従業員, 委託先, 私⼈など) の Identity Proofing および Authentication について⾔及している. それぞれのガイドラインが Identity Proofing, Registration, Authenticator, Management Process, Authentication Protocol, Federation および 関連する Assertion の各エリアにおいて技術要件を定義する. n 本ドキュメントの発⾏をもって, 本ドキュメントは既存の NIST Special Publication 800-63-3 を置き換えるものとする. 2 現時点ではまだドラフト版で、2023年3⽉24⽇ 11:59(EST)までコメントを受け付けている
  3. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. NIST

    SP800-63の全体 n SP800-63-4 Digital Identity Guidelines n SP800-63A Enrollment & Identity Proofing n SP800-63B Authentication & Lifecycle Management n SP800-63C Federation & Assertions 3
  4. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. Digital

    Identity Guidelines(⽬次) 1. Purpose 2. Introduction 3. Definitions 4. Model 5. DIRM (Digital Identity Risk Management) 6. References A) Definitions B) Change Log 4
  5. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 4.

    Model 5 informative A.1. Definitions Subject ⼈間, 組織, デバイス, ハードウェア, ネットワー ク, ソフトウェア, サービスなど. Applicant Enrollment および Identity Proofing のプロセス を受けている Subject. Subscriber CSPアイデンティティサービスに Enrollment さ れた個⼈ Claimant 1つ以上の Authentication Protocol により Identity を検証される Subject. Non-federated Digital Identity モデル Definitions
  6. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 4.

    Model 6 informative A.1. Definitions Credential Service Provider (CSP) 信頼されたエンティティで, Identity サービスへ の Applicant の Identity Proofing や, Subscriber Account への Authenticator の登録 などの機能を持つ. CSP は独⽴した第三者となる ことがある. Verifier Authentication Protocol を利⽤して, Claimant が1つまたは2つの Authenticator を 所有, 管理し ていることを検証し, Claimant の Identity を検 証する主体. Verifier は上記の⽬的のため, Authenticator と Identity を紐付ける Credential を確認し, そのステータスをチェック する必要がある場合もある. Relying Party (RP) Subscriber の Identity に関する Verifier の Assertion を信頼して, Transaction 処理や情報ま たはシステムへのアクセスを許可したりする主体. Federated Digital Identity モデル
  7. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 4.

    Model 8 informative SP800-63A Enrollment & Identity Proofing SP800-63B Authentication & Lifecycle Management SP800-63C Federation & Assertions
  8. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 2.

    Introduction n 2.1 Scope & Applicability l 利⽤者層 (市⺠, ビジネス・パートナー, 政府機関など) に関係 なく, 何らかのレベルの Digital Identity が必要なすべてのオ ンライン Transaction に適⽤される. l 国家安全保障システムに関連するものや、物理的なアクセスは スコープ外だが、IoTなどへの適⽤可能性を残すために、出来 る限り⼀般的なSubjectに⾔及している 9 informative
  9. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 2.

    Introduction n 2.2 How to Use this Suite of SPs l 本ガイドライン群は, Digital Identity を個別要素ごとに分割することで, Authentication の誤りがもたらすネガティブインパクトの軽減に寄与する l SP800-63: Risk Assessment の⽅法論、アイデンティティフレームワー クの概観、Assurance Levelの選択⽅法 l SP800-63A: IAL(Identity Assurance Level ) ▪ Identity Proofing プロセス(IAL0〜IAL3) l SP800-63B: AAL(Authenticator Assurance Level) ▪Authentication プロセス(AAL1〜AAL3) l SP800-63C: FAL(Federation Assurance Level) ▪RP が Federated Protocol で接続されている場合の Federation プロセス (FAL1〜FAL3) 10 informative
  10. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 2.

    Introduction n 2.3 Enterprise Risk Management Requirements and Considerations l Security ▪不正アクセス、なりすましなどのデジタルアイデンテ ィティセキュリティリスクの評価と管理 l Privacy ▪PIIを処理するときのプライバシー関連の問題を引き 起こす可能性への考慮 l Equity ▪LGBTQ+や障害者、地⽅に住む⼈々などを含むすべて の個⼈に対する公正で公平な扱い l Usability ▪特定の⽬標を達成できる程度への考慮 11 informative A.1. Definitions Equity EO 13985 によると, Equity とは, ⿊⼈, ラテンア メリカ⼈, 先住⺠, アジア系アメリカ⼈, 太平洋諸 島⺠, その他の有⾊⼈種など, これまで⼗分なサー ビスを受けてこなかったコミュニティに属する個 ⼈を含め, すべての個⼈を⼀貫して公平, 公正, か つ公平に扱うことを指す. 宗教的少数派の⼈々, レ ズビアン, ゲイ, バイセクシャル, トランスジェン ダー, クィア (LGBTQ+) の⼈々, 障害者, 地⽅に 住む⼈々, その他根強い貧困や不平等から悪影響 を受ける⼈々など. Usability 特定のユーザーが特定の利⽤コンテキストにおい て, 効果的, 効率的かつ⼗分に特定の⽬的を果たす ためにプロダクトを利⽤しうる度合い.
  11. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 5.

    Digital Identity Risk Management n Digital Identity の Risk Management の4つのステップ 1. 初期 Impact Assessment の実施 l 影響カテゴリーに対して、アイデンティティシステムの各機能の障害がもたらす影響の評価 l 影響カテゴリーと影響レベルの整理 2. 初期 Assurance Levels の選択 l 影響カテゴリーと影響レベルに対するAssurance Levelの決定 3. Assurance Level の決定の調整(Tailor)と⽂書化 l Privacy, Equity, Usability, 及び脅威に関する詳細なアセスメント l 初期Assurance Levelの調整 l Digital Identity Acceptance Statementの作成 4. 継続的な評価と改善 l 多様な事実に基づく Identity システムのパフォーマンスに関する情報の収集 l 選択した Assurance Level およびコントロールがミッション, ビジネス, およびセキュリティ のニーズを満たしているかどうかを判断し、継続的に⾒直す 12 normative
  12. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 5.

    Digital Identity Risk Management n 組織は, 組織のプロセス, ガバナンス, 及び企業 Risk Management のプラクティスとの統合に合わせて, この全体的 なアプローチを適応及び修正すべき(SHOULD)である. n 最低限, 組織は, 運⽤⽅法や実現⼿段にかかわらず, 各ステップを 確実に実⾏し, 各ステップの normative な義務及び成果を完了 し, ⽂書化しなければならない (SHALL). 13 normative
  13. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 1.

    初期 Impact Assessment n Identity Proofing, Authentication, および Federation が失敗した場合の潜在的な悪影響 の特定 1. 影響を受ける主体の特定, l 影響評価には, 組織⾃⾝に加えて(省略)個⼈を含めなくてはいけない(SHALL). 2. 被害を評価する対象となる⼀連の影響カテゴリーの特定, 3. 影響カテゴリーのそれぞれについて, 潜在的な被害を特定, l 各 Assurance Level, IAL, AAL, および FAL (Federated Identityを受け⼊れる, または Asserting する場 合) は個別に評価しなくてはいけない(SHALL). 4. 障害が発⽣した場合に, それらの潜在的な被害が与える影響のレベルの特定, ならびに 5. 各タイプの障害 (Proofing, Authentication, Federation) の影響の評価と, 影響を受け るすべての主体への影響レベルの評価. 15 normative
  14. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 2.

    初期 Assurance Levels の選択 n 組織 RP は, サイバーセキュリティリスクとミッションの必要性に基づいて, 以下の個 々の初期 Assurance Level を選択しなければならない(SHALL). n IAL: 個⼈の Identity を確信を持って決定するための Identity Proofing プロセスの頑 強性. IAL は潜在的 Identity Proofing の失敗を軽減することを⽬的に選択される. n AAL: Authentication プロセス⾃体, および Authenticator と特定個⼈の識別⼦の紐 付けの頑強性. AAL は Authentication 失敗を軽減することを⽬的に選択される. n FAL: IdP から RP に Authentication および Attribute 情報 (該当する場合) を伝達す るために使⽤される Federation プロセスの頑強性. すべての Digital システムが Federated Identity アーキテクチャーを採⽤する訳ではないため, FAL はオプション である. FAL は Federation の失敗を軽減することを⽬的に選択される. 17 normative
  15. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 3.

    Assurance Level の決定の調整(Tailor)と⽂書化 n 調整は, 最初に評価した Assurance Level を修正し, または継続的な詳細な影 響と Risk Assessment に基づき, 代替の管理策を実施するプロセスを提供す る. 組織は, このガイドラインで定義された評価済み Assurance Level を実施 するべきである(SHOULD). n しかし, 本ガイドラインは, 組織が特定のミッションのニーズを満たし, 独⾃の リスク選好及び考慮事項に対処できるよう, 柔軟性を提供するものである. し たがって, 組織は, xALの調整プロセスを確⽴し, ⽂書化しなければならない (SHALL). 最⼩限のこのプロセスは以下の通り: 18 normative
  16. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 3.

    Assurance Level の決定の調整(Tailor)と⽂書化 n Document Results - The Digital Identity Acceptance Statement n Statement には, 最低限, 以下を含めること: l 初期影響調査の結果 l 初期の xAL 評価, l 調整された xAL と当初評価された xAL が異なる場合, 調整されたxALとその根拠, l すべての代替策とその⽐較可能性, または代替策に関連する残存リスク l すべての補⾜的な対策 19 normative
  17. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 4.継続的な評価と改善

    n 脅威をもたらす主体は適応し, ユーザーの期待とニーズは変化し, ミッション は進化する. このように Risk Assessment と Identity ソリューションは, 定 められたあとに忘れ去られるものではない. n 常に変化する環境に対応するために, 組織は Identity システムとインタラク ションする⼈々からのインプットを活⽤する継続的な評価および改善プログラ ムを実施するべきである(SHOULD). n これらのプログラムは, アプリケーション・パフォーマンス測定基準, 脅威イ ンテリジェンス, 不正分析, Equityへの影響の評価, Privacy 影響分析, および ユーザーの⼊⼒からのフィードバックを考慮すべきである(SHOULD). 20 normative
  18. Copyright 2013 OpenID Foundation Japan - All Rights Reserved. 5.5

    Cyber, Fraud, and Identity Program Integrity n 通常, Identity ソリューションは, 重要なビジネスまたはサービス機能のフロ ントドアである. n したがって, 孤⽴した状態で運⽤するべきではない. Identity 機能をサイバー セキュリティ・チーム, 脅威インテリジェンス・チーム, およびプログラム・ インテグリティ・チームと緊密に連携させることにより, ビジネス機能をより 完全に保護し Identity ソリューション機能を常に向上させることができる. n 組織は, 重要なセキュリティおよび不正⾏為の関係者間で情報を交換するため の⼀貫したメカニズムを確⽴するべきである(SHOULD). n CSP などの⽀援サービス・プロバイダーが外部にある場合, 複雑になる可能性 があるが, 上記のような項⽬は契約上および法的な仕組みの中で考慮されるべ きである(SHOULD). 21 normative