ホワイトペーパー高保証エンタープライズFIDO認証

エディター

ショーン・ミラー、RSA

要約

企業は、特に現在パスワードに依存している場合は、パスキーの使用を検討する必要があります。 これらの認証情報をパスキーに置き換えることで、企業はフィッシングのリスクをすぐに軽減し、認証情報の再利用を排除し、認証サービスのセキュリティを向上させることができます。 さまざまなタイプのFIDOオーセンティケーターを使用して、利便性とセキュリティのバランスを取りながらユーザーのニーズを満たすことができます。 高レベルの ID 保証、内部セキュリティポリシー、または規制要件を必要とする企業の場合、適切なパスキーのタイプを決定するために、追加の調査が必要です。 企業全体と組織の一部の両方を見ることが重要です。なぜなら、高い保証要件が企業全体に適用されるとは限らないからです。

多くの高保証シナリオでは、構成証明 デバイス固定パスキー の方が望ましい場合があります。 高保証要件を持つ証明書利用者は、すべての種類の認証子を受け入れ、構成証明の特性に基づいて認証フローを適応させるか、またはユーザー エクスペリエンスが低下するリスクを冒して、証明されていない認証子または許容できない認証子からの登録を拒否するかを決定する必要があります。

聴衆

このホワイトペーパーは、FIDO認証を企業全体に展開し、ライフサイクル管理ポリシーを定義することを検討しているIT管理者およびエンタープライズセキュリティアーキテクトを対象としています。 このホワイトペーパーでは、多要素認証MFAのさまざまなユースケースと、管理者が利用できる 認証器 の選択肢の概要を説明します。 その目的は、管理者が特定の環境に適した認証子タイプを選択するのを支援することです。 特に、医療、政府機関、金融機関など、資格情報の管理に厳しい要件がある企業など、より高いレベルのセキュリティを必要とする企業は、このホワイトペーパーをお読みください。

読者は、FIDOアーキテクチャ、証明書利用者、プロトコルを理解しており、このホワイトペーパーで使用されている主要な概念を紹介する「FIDO EDWG 2023 Papers – Introduction」を読んだことを前提としています。

1. イントロダクション

このドキュメントでは、高保証環境のエンタープライズユーザー向けのパスキーのデプロイに焦点を当てています。
読者は、ここで一連の論文の紹介を見つけることができます。 入門ホワイトペーパーでは、低保証から高保証までの一連のユースケースをカバーするシリーズのすべての資料への追加の説明とリンクを提供します。 ほとんどの企業では、これらのペーパーの 1 つ以上にわたるユース ケースが存在する可能性が高く、読者はデプロイ環境に関連するホワイト ペーパーを確認することをお勧めします。

このホワイトペーパーでは、高保証環境にいるとはどういうことか、そしてそれがFIDOの使用方法にどのように影響するかについて考察します。 具体的には、このドキュメントでは、パスワードのみの認証の課題に対処し、パスワードを使用してユーザーを認証する代わりに、より強力でフィッシングに強い代替手段としてパスキーを提案しています。 さらに、このドキュメントでは、IT およびセキュリティの専門家が高保証認証シナリオの規制要件とセキュリティ要件に確実に準拠するために考慮すべき導入に関する考慮事項をいくつか紹介します。 このホワイトペーパーでは、デバイスの登録、登録済みデバイスの使用、紛失したデバイスの回復の対処の使用例について説明します。

パスキーを環境で許可するかどうかを決定する際の重要な部分は、構成証明に基づいています。 認証は、登録プロセスの一部として資格情報に提供でき、証明書利用者は、使用されている認証子の出所として信頼できます。 高保証エンタープライズ シナリオでは、常に構成証明を要求する必要があります。 資格情報に関連付けられている構成証明から検出できる内容、または構成証明の欠如は、登録を受け入れるかどうかに関するポリシーの決定を促進するのに役立ちます。 構成証明がないと、証明書利用者が資格情報を許可すべきかどうかを決定するのが難しくなる可能性があります。 登録を完全に拒否してユーザーエクスペリエンスが低下する場合もあれば、企業が高保証要件を満たすためにFIDO認証とともに追加の条件付き多要素認証(MFA)を採用する場合もあります。 認証により、企業は認証子の出所、製造タイプ、認証、および機能に関する保証を持ち、多くの場合、これらの保証を MFA デバイスとして信頼でき、認証子のロックを解除するための資格情報や PIN などの複数の要素を提供できます。

同期パスキーは、多くのユースケースで適切に機能し、企業のセキュリティ要件や規制要件によっては、一部の高保証シナリオでも機能します。 同期されたパスキーは、その回復性と使いやすさから魅力的です。ただし、資格情報が存在する場所と、それらを制御するユーザーも変更されます。 この外部からの資格情報の制御を考えると、企業が MFA メソッドのライフサイクル管理を制御できる 同期パスキー には、追加の MFA が必要になる場合があります。

このホワイトペーパーの残りの部分では、 認証器 Assurance Levels [7] と FIDO Certified 認証器 Levels [8] に基づいて高い保証要件を持つ企業や組織について説明します。

2. パスキー の使用例

このセクションでは、企業または組織におけるパスキーに関するユースケースに焦点を当てます。 企業では、 同期パスキー が、デバイスの登録、デバイスの使用、紛失したデバイスの回復を簡単かつ便利に行うために非常にうまく機能する多くのユースケースがあります。これは、認証情報が他のデバイスで利用可能であるためです。 組織は、 同期パスキー のすべての利点を確認して、それらが組織に適しているかどうかを判断することを強くお勧めします。 ただし、 同期パスキーの使用は便利ですが、高い保証を必要とする企業や組織のセキュリティ要件(AAL3要件など)をすべて満たしているとは限りません。 AAL3レベルにはいくつかの要件がありますが、最も重要なのはハードウェアベースの認証子の使用です。 認証器 保証レベル(AAL)[7]のさまざまなレベルの詳細については、NISTを参照してください。 多くの場合、AAL3 は、医療、政府、金融など、より高いレベルのセキュリティを必要とする企業や組織に適用され、資格情報の制御、特にデバイスにバインドされ、コピーされないという厳しい要件があります。

2.1. 参加登録
企業または組織は、まず、自社の環境でサポートするデバイスと、デバイスのプロビジョニングを管理する方法を検討する必要があります。 たとえば、ユーザーが自分のデバイス (携帯電話など) を持ち込むことができる環境を組織がサポートしている場合や、PIN の長さ、特定のユーザー プレゼンス機能、さらには特定のハードウェア モデルなどの特定のセキュリティ要件を満たす発行済みデバイスに対して非常に厳しい要件がある場合があります。 最後に、組織は、パスキーを複数のデバイスに配置できるようにするか、1つのデバイスのみに配置できるようにするかを検討する必要があります。 これには、セキュリティと復旧の両方への影響があり、考慮する必要があります。

組織によっては、認証情報をデバイスに縛られ、まったくコピーできないというユースケースがある場合があり、その場合、 同期パスキー は推奨されません。 組織は、従来のMFAメカニズムと並行して 同期パスキー を許可し、パスワードをパスキーに置き換えることを選択できます。 ただし、組織が資格情報を保存できる場所について厳しい要件がある場合は、 デバイス固定パスキーに使用を制限することを詳しく検討する必要があります。 これらの要因によって、組織が登録を管理する方法が決まります。 これらすべてのケースは、パスキーの種類を制限する必要がある場合に、信頼する側に負担をかけます。

証明書利用者は、登録プロセス中に、FIDO L1+認定を満たすか、またはそれを超える認証子を要求するなど、いくつかの要件が満たされているかどうかを確認する必要がある場合があります[8]。 認証器がこれらの要件に準拠しているかどうかを評価するには、認証器は、検証および検査できる認証を提供する必要があります。 オーセンティケータがL1+の要件を満たしていない場合、クレデンシャルの出所について何も証明できないため、証明書利用者は登録を拒否せざるを得ないかもしれませんし、高保証の要件を満たすために追加のMFAを使用した実装を検討することもできます。

構成証明が提供されている場合、証明書利用者は、それがデバイスの種類と、企業または組織の要件を満たしているかどうかを確認できます。 証明書利用者は、認証子の一意の識別子に基づいて制限することもできます (構成証明が使用可能な場合)。 この一意の識別子は、 認証器 Attestation Globally Unique Identifier(AAGUID)と呼ばれ、 FIDO Alliance Metadata Service[2]に対して詳細を検索するために使用でき、登録されているデバイスのタイプ、認証レベル、および提供される機能を理解できます。

エンタープライズ構成証明は、登録時に活用できる別の形式の構成証明です。 これは、一部の認証ベンダーによって実装され、組織に固有の追加情報が追加されます。 この追加情報を構成証明の一部として含め、許可された認証子を絞り込むと、登録エクスペリエンスをさらに向上させるために使用できます。

同様に、資格情報がバックアップの対象であるかどうか、および/またはバックアップされているかどうかについてのフラグがある場合があります。 ただし、これらのフラグは、デバイスが認定されていることを証明しないと信頼できません。 証明書利用者は、この情報と実行時に提供される他の情報に基づいて、登録を許可するか拒否するかを決定する場合があります。

残念ながら、証明書利用者が資格情報の登録に失敗した場合、ユーザーはステップ 1 で別の認証子を使用して登録プロセスを再度繰り返す必要があります。 WebAuthn [5] は、適切な認証子を識別するためのプリフライトメカニズムをサポートしていませんが、 信頼利用者は、登録前にユーザーにフィードバックを提供して、 受け入れ可能な認証子を特定できるかもしれません。 登録に失敗した後、ユーザーのオーセンティケーターの選択をガイドするための追加のガイダンスを提供できます。 このガイダンスは、登録時に認証子が拒否された理由、RP の要件を満たす認証子、および通信構成証明に関するブラウザーで義務付けられたオプションの管理に関するガイダンスを明示的に指定する必要があります。

信頼者(Relying Party)は、認証子の要件を記述する際に、より規範的であることが必要であり、これにより、エンドユーザーが要件を満たす認証子のみを選択でき、信頼者からこの負担を取り除くことができる、はるかに優れたユーザー体験が可能になります。 これらの変更はWebAuthnに提案されていますが、プラットフォームベンダーの支持はまだ集まっていません。

企業にとっての別のアプローチは、エンドユーザーに公開される登録ユースケースを提供しないことかもしれません。 代わりに、企業は、デバイスがユーザーにプロビジョニングされる前に、デバイスを登録するライフサイクルを管理します。 同様に、企業は、承認された認証子のみがプロビジョニングおよび登録されるように、何らかの形式の監視付き登録エクスペリエンスを提供する場合があります。 これにより、上記のユーザーエクスペリエンスの多くの落とし穴が回避されますが、企業のライフサイクル管理の負担は大きくなります。

2.2. Sign In
資格情報が登録されると、認証時に必要なときにFIDO資格情報にアクセスできます。 アプリケーションは、WebAuthn ブラウザ API またはプラットフォーム パスキー API を利用して、登録済みデバイスを使用して FIDO 認証を実行します。 登録されたデバイスのタイプに応じて、PINの入力やユーザープレゼンスチャレンジなど、認証には複数の要素が関与します。 これらのインタラクションの要件は、ユーザーが本人であり、どのユーザーにもなりすましていないという高レベルの保証があることです。 これらの要件は、デバイスが企業または組織の要件を満たすことが許可されていることを確認するために、登録プロセス中に適用する必要があります。

このユースケースでの 同期パスキー と デバイス固定パスキー の唯一の違いは、認証する必要があるものだけです。 デバイス固定パスキーの場合、登録プロセス中に使用された元のハードウェアデバイスが必要です。 同期されたパスキーは、パスキープロバイダーがホストするアカウントにアクセスできる複数のデバイスからアクセスできます。 さらに、 同期パスキー の一部は、登録後に共有される場合があります。 証明書利用者には、現在の仕様で共有資格情報を識別するメカニズムがないため、 同期パスキーのライフサイクルを理解して管理するのが難しくなっています。

ホワイトペーパー「Choosing FIDO Authenticators for Enterprise Use Cases」[4]では、いくつかのエンタープライズユースケースが取り上げられています。 組織は、FIDOがどのように活用されているかを評価するために、これらを確認する必要があります。 特に、FIDOを第1要素(パスワードレス)または第2要素として依存することを計画している組織は重要な決定事項であり、ホワイトペーパーは、組織が本当に高い保証を必要とするものを理解するのに役立つ可能性があります。 たとえば、特定のプロジェクトがある場合や、政府や規制の要件によって推進される業界全体にユースケースが適用される場合があります。 たとえば、従業員は同期されたパスキーを使用してラップトップにアクセスできる場合がありますが、その後、特定のクリアランス レベルの特定の従業員に制限された特定のアプリケーションにサインインするには、デバイスにバインドされたパスキーを使用する必要があります。

2.3. Recovery/Lost Device
リカバリは、同期されたパスキーが威力を発揮する場所です。 資格情報を保持しているFIDOデバイスを紛失した場合、同じプラットフォームアカウントを共有する別のデバイスから資格情報にアクセスできます。 これは便利ですが、パスキーは関連付けられているプラットフォームアカウントと同じくらい安全であることを意味します。 企業は、組織外のサービスに依存する前に、ベンダーのソリューションを調べて、その安全性を理解する必要があります。 たとえば、ベンダーが知らないキーを使用したエンドツーエンドの暗号化を提供しますか? ユーザーのアカウントを保護するために、MFAなどのどのような追加手段が使用されますか? アカウントの復旧にはどのようなプロセスが使用されますか? エンド ユーザーはこのような問題について心配していないかもしれませんが、これらの詳細は組織のセキュリティ管理者にとってセキュリティ上の懸念事項である可能性があります。 組織のセキュリティ要件を調べて、外部の関係者が資格情報を保存および管理できるかどうかを確認する必要があります。 さらに、証明書利用者は、認証を必要としないため、プラットフォーム、ローミング認証システム、ブラウザプラグインなど、資格情報の発行者が誰であるか、または何であるかを知ることができません。 その結果、証明書利用者は、高い保証を提供しながら資格情報へのアクセスを回復する方法についてのガイダンスを提供できません。 FIDO 資格情報の回復以外のアカウント回復の代替手段として、ユーザーの ID を確認し、新しいデバイスと資格情報を発行する必要があります。 最後に、synced を使用する場合のプロバイダからのパスキーの回復は、証明書利用者には認識されません。 これは、企業が気づいていない潜在的な攻撃を表しています。

デバイス固定パスキーの場合、回復プロセスはより複雑であり、新しいデバイスを発行し、場合によっては古いデバイスのアクセスを取り消すために、ヘルプデスク[6]の関与が必要になる可能性があります。 これは、利便性よりもセキュリティファーストのアプローチであり、企業や組織がデバイスを持つユーザーを制御できるようにします。 これは、エンドユーザーがアクセスを回復する前に、追加の手順が必要であることを意味します。 ただし、これにより、企業は資格情報のライフサイクルをより詳細に制御できるため、企業は任意の時点で認証子を取り消したり期限切れにしたり、資格情報がコピーされたり、企業の制御外に存在しなかったりすることを保証できます。 一部の企業では、ユーザーが自己回復できるように複数のデバイスをプロビジョニングすることでこれを解決しています。 最終的には、リカバリモデルに関してビジネス上の決定を下す必要があります。 場合によっては、ユーザーが新しいデバイスを受け取るまでアクセスをブロックすることが適切であり、セキュリティが低いモデルよりも生産性が低下します。 企業が登録エクスペリエンスの管理を選択した場合、登録手順で強調表示される追加の負担は、復旧/交換エクスペリエンスに直接影響します。

2.4. Unregistering
ある時点で、従業員はプロジェクトまたは企業全体を去ります。 企業は、資格情報を制御し、アクセスが不可能になるように使用を登録解除する必要があることを確認します。 これは、企業が資格情報のライフサイクルと管理を完全に制御できない 同期パスキー に関しては、より大きな考慮事項です。 同期パスキー に追加の MFA が必要な場合、企業は MFA の側面を制御し、関連する要素を期限切れにして認証を許可しなくすることができます。 デバイスにバインドされたパスキー環境では、デバイスを物理的に提出してコピーが作成されていないことがわかっているか、デバイスを無効化/期限切れにして後続の認証試行が失敗するかにより、デバイスの登録解除をはるかに制御できます。

資格情報のライフサイクルでは、従業員のステータスの変更 (休職や組織からの離職など) や、資格情報の紛失や侵害の可能性などにより、資格情報を無効化または削除する機能が必要です。 これらの場合、パスキー はパスワードと異なります。これは、ユーザーが証明書利用者ごとに 1 つのパスワードしか持たないことが想定されるパスワードとは対照的に、ユーザーが証明書利用者に登録されている複数のパスキーを持つ場合があるためです。 ユーザーとエンタープライズが永続的に分離されている場合、ユーザー アカウントを無効にしたり、サービスで資格情報をローテーションしたりすることが、ユーザーが認証できなくなるようにするための標準的な方法です。 離職が一時的なもの (休職など) の場合、企業は、ユーザーのすべての資格情報をローテーションするか、ユーザーが戻るまでユーザー アカウントを無効にするかを選択できます。

資格情報が失われた場合、次の手順はデプロイ シナリオによって異なります。 デバイス固定パスキー を持つユーザーがセキュリティ キーを紛失した場合は、サービスによって資格情報が取り消される必要があります。 同期されたパスキーは、さらなる課題を生み出します。 デバイスが侵害された場合、デバイスに存在するすべての資格情報 (異なるパスキー プロバイダーに存在する資格情報を含む) は、侵害されたものとして扱われ、RP によって取り消される必要があります。 ユーザーのパスキー プロバイダー アカウントが侵害された場合は、プロバイダーに保存されている影響を受ける資格情報を取り消す必要があります。 これらのシナリオでの失効を容易にするために、RP は、登録時にユーザーが資格情報に名前を付けたり、その他の方法で識別したりできるようにして、可能な限り特定の資格情報の取り消しを容易にする必要があります。 管理制御では、ハードウェア セキュリティ キーまたはパスキー プロバイダーの同期ファブリックから資格情報の秘密キー マテリアルを削除するのではなく、RP から資格情報を削除することに焦点を絞る必要がありますが、これは不可能な場合があります。

3. デプロイメント戦略

高保証環境では、企業はすべての認証子の配布と廃止を管理することになりがちです。 デバイスにバインドされたパスキーは、IT部門によって管理され、個人にプロビジョニングされます。 証明書利用者は、構成証明を確認し、企業または組織によって管理されている認証子の登録のみを許可する必要があります。 構成証明がない場合、またはセキュリティ要件を満たしていない場合、登録は失敗します。 オーセンティケーターのプールを管理するプロセスを確立して、個人が退職したり、高レベルのアクセスが不要になったときにオーセンティケーターが廃止されるようにする必要があります。 最後に、組織または企業は、紛失/盗難にあったデバイスを回復するためのプロセスがどのように見えるかを定義する必要があります。 ビジネスの継続性に対するアクセスの重要性によっては、特定の個人に対して複数のハードウェア デバイスが発行され、常にアクセスが確保される場合があります。

4. まとめ

パスキーが従来のパスワードに代わる強力なフィッシング対策であることに異論はありません。 エンタープライズ環境では、セキュリティ要件と規制要件を確認して、 同期パスキー が機能するかどうか、 デバイス固定パスキーの使用を必要とする内部セキュリティポリシー、規制、コンプライアンス要件などのより厳しい制約があるかどうかを判断することが重要です。 どちらのアプローチでも、企業はFIDO資格情報の登録、管理、および回復がどのように管理されるかを理解するために時間を費やす必要があります。 これには、資格情報の保存 (外部)、紛失した資格情報の回復、従業員の退職時のデバイスの登録解除などの重要な使用例が含まれます。 企業の要件に基づいて、パスキーはカスタマイズなしで機能する場合もあれば、企業が認証エクスペリエンスをより管理し、特定のデバイスにフィルタリングするための投資が必要な場合もあります。

5. 次のステップ: 今すぐ始めましょう

• FIDO標準を使用します。
• 証明書利用者が何をサポートしているかを考え、エンタープライズのセキュリティ要件を検討します。
• パスキー はパスワードよりもはるかに安全です。 パスキーのアイコンは、それをサポートしている Web サイトやアプリケーションで探してください。

パスキーの詳細については、 FIDO Alliance のサイト[3]をご覧ください。

6. 参考文献

[1] FIDOのエンタープライズでの パスキー の展開 – はじめに
[2] FIDO Alliance メタデータサービス – https://fidoalliance.org/metadata/
[3] パスキー (パスキー 認証) –
https://fidoalliance.org/passkeys/#:~:text=Can%20FIDO%20Security%20Keys%20サポート、検出可能な%20credentials%20with%20user%20verification。
[4] FIDO Alliance ホワイトペーパー: エンタープライズユースケース向けの FIDO オーセンティケーターの選択 –
https://fidoalliance.org/white-paper-choosing-fido-authenticators-for-enterprise-use-cases/
[5] WebAuthn – https://fidoalliance.org/fido2-2/fido2-web-authentication-webauthn/
[6] FIDOアカウント回復のベストプラクティス –
https://media.fidoalliance.org/wp-content/uploads/2019/02/FIDO_Account_Recovery_Best_Practices-1.pdf
[7] NIST 認証器 保証レベル – https://pages.nist.gov/800-63-3-Implementation-Resources/63B/AAL/
[8] FIDO認定 認証器 レベル – https://fidoalliance.org/certification/authenticator-certification-levels/

7. 謝辞

グループディスカッションに参加した、またはこのペーパーのレビューに時間を割いて意見を提供してくださったすべての FIDO Alliance メンバーに感謝します。

• マシュー・エステス、アマゾン ウェブ サービス
• ジョン・フォンタナ、ユビコ
• リューイスラム、ダッシュレーン
• Dean H. Saxe氏、Amazon Web Services、FIDO Enterprise Deployment Working Group共同議長
• ヨハネス・ストックマン、Okta
• シェーン・ウィーデン、IBM
• Khaled Zaky、アマゾン ウェブ サービス
• FIDO Enterprise Deployment Groupのメンバー