ホワイトペーパー:パスキーによるパスワード + OTP 認証の置き換え

9月 17, 2024

エディター

フスナン・バジュワ、アイデンティティを超えて
ジョシュ・シグナ、ユビコ
ジン・グー、アイデンティティを超えて

要約

このホワイトペーパーでは、クレデンシャルスタッフィングのリスクを軽減するためにSMS OTPなどの第2要素を実装している企業向けに、パスワード+OTPをパスキーに置き換えるためのガイダンスを提供します。

聴衆

このホワイトペーパーは、多要素認証 (MFA) サインインプロセスのデプロイと保守を担当する ISRM および IT スタッフを対象としています。

1. イントロダクション

従業員の保護を目指す多くの企業は、パスワードの認証の追加要素として、SMSとアプリケーションベースのワンタイムパスコード(OTP)を導入しています。このホワイトペーパーは、パスキーによるFIDO認証への移行を検討している組織を対象としています。このホワイトペーパーでは特にOTPに焦点を当てていますが、アプリケーションベースのOTPやプッシュ通知など、フィッシング可能なセカンドファクターを使用するあらゆるシステムに議論と推奨事項を一般化できます。

このホワイトペーパーでは、セキュリティ、ユーザー体験、導入の容易さの観点から、パスワードやパスキーに追加する認証器としてのOTPを比較しています。また、OTPからパスキーへの移行に関する一般的なガイダンスを提供し、組織全体のセキュリティ体制を強化しながら、ユーザーエクスペリエンスを向上させる。このホワイトペーパーのガイダンスでは、計画、ユースケースの特定と文書化、パイロットの考慮事項、導入とトレーニングのガイダンスなど、パスキーに移行するための主要な手順について説明します。このドキュメントは、内部認証、外部認証、サードパーティおよび B2B 認証戦略など、低保証のユースケースを対象としています。組織が通常、パスワードの 2 番目の要素として OTP を実装していることを考えると、このドキュメントでは、OTP へのすべての参照がパスワードの 2 番目の要素として使用されると想定する必要があります。

このドキュメントでは、特定のベンダーのテクノロジーや実装については説明しません。中程度または高保証のユースケースに関するガイダンスについては、FIDO アライアンスが発行した追加のホワイトペーパー[1]を参照してください。このドキュメントは一連のホワイトペーパーの一部であるため、読者は入門ドキュメント[2]から始めることをお勧めします。

ホワイトペーパーをダウンロード

2. OTP MFA とパスキー: パスキーを選ぶ理由

パスキーは、OTP と比較して、セキュリティ、ユーザーエクスペリエンス、導入の容易さにいくつかの利点をもたらします。

2.1 セキュリティ

OTPベースのMFAは、クレデンシャルの詰め込みと再利用のリスクを軽減するために広く採用されています。SMSおよび認証アプリケーションベースのOTPは、比較的低コストで、幅広いユーザーとユースケースに展開しやすいため、最も一般的に展開されるソリューションです。しかし、このタイプのMFAは比較的単純であるため、シークレットジェネレータと検証IDプロバイダー(IDP)との間に双方向通信が存在しないため、ソーシャルエンジニアリングや多くのMFAバイパスツールキットに対して脆弱になります。つまり、エンドユーザーやIDPの知らないうちにOTPが第三者によって傍受され、使用される可能性があります。

さらに、OTP ベースの MFA では、組織が管理したり、セキュリティ体制を可視化したりできないデバイスに対する信頼が必要です。これは、組織がエンドユーザーに頼って、自分のデバイスのセキュリティを維持し、フィッシングの試みを見分ける能力を維持していることを意味します。ユーザートレーニングはこれらの攻撃の一部に対処するのに役立ちますが、安全な接続や使い慣れたURLのチェックなどの従来のガイダンスは、依然として常に警戒するユーザーベースに依存しています。

パスキーは、フィッシングやリプレイに強いサインインを提供し、ユーザーの認知的負荷を軽減し、組織の全体的なセキュリティ体制を強化します。これは、パスキーが、信頼者のドメインを対象とする暗号チャレンジ/レスポンスプロトコルを実装するために実現されます。その後、オーセンティケーターは、生体認証証明やPINなどの安全な動作に依存して、ユーザーフレンドリーなエクスペリエンスを維持しながら、オーセンティケーターの資格情報のロックを解除します。パスキーを使用すると、組織はパスワードレスのシナリオで強力な第 1 要素認証を持つか、従来の MFA ワークフローで強力な第 2 要素を持つことができます。

2.2 ユーザーエクスペリエンス

パスキーは、次のようないくつかの方法で、パスワードやOTPよりもユーザーエクスペリエンスを向上させます。
パスキーはセルカバレッジが不十分な場合でも機能しますが、SMS OTPはモバイルネットワーク接続を必要とします。たとえば、ユーザーは飛行機内でワイヤレスアクセスを持つことができますが、SMS の使用は許可されていません。この場合、SMS OTPは配信できませんが、パスキーは認証に使用できます。
AutoFill UI は、モバイルデバイスとデスクトップのブラウザ内でのシームレスな統合を可能にします。
ログインが最大4倍速く、コード配信を待つ必要はありません[3]
パスワードやコードの入力ミスに対する保護
パスキーは、生体認証証明 (顔または指紋) などの認証の一般的な動作に基づいて構築されます。

2.3 デプロイの容易さ

一部の零細企業、中小企業、大規模で専任のサポートスタッフがいない企業では、エンドユーザーに専用の
認証ハードウェアトークンは、障害を引き起こす可能性があります。これには、OTPハードウェアトークンとFIDOセキュリティキーの両方が含まれます。歴史的に、SMS/アプリベースのOTPの展開の容易さは、それらをより好ましい選択肢にしました。調達、ロジスティクス、および構成は、運用チームとITチームが常に戦っている戦いです。FIDO2エコシステムのアップデートにより、オーセンティケーターのランドスケープが拡大したことで、この問題は軽減され、さまざまなデバイスをパスキーストアとして使用できるようになりました。

これらすべてが組み合わさると、パスキーの展開は、いくつかの理由からSMS OTPと比較してはるかに簡単で低コストであることを意味します。
SMS の統合は必要ありません。企業は、モバイルキャリアやサードパーティのSMSベンダーとのインターフェースを設定または保守する必要がないため、展開の複雑さが軽減されます。
企業はSMS OTPに関連する取引ごとの手数料を支払う必要がないため、認証の総所有コストを削減できます。
FIDO認証ではパスキーを使用します。パスキーは、さまざまなデバイスやアプリケーションに簡単に実装できます。
SMS OTPは、キャリア固有のAPIまたは標準化されていないサードパーティベンダーのAPIに依存しているため、ベンダーロックインや相互運用性の欠如のリスクが高まります。
時刻の同期は必要ありません。パスキーは、SMS の時間制限付き OTP(TOTP)の時刻同期要件を回避します。コードは短時間で入力する必要はなく、SMS の配信可能性の問題によってログインが失敗することはありません。

パスキーを使用したFIDO認証は、オペレーティングシステム(OS)およびブラウザプロバイダーによって採用されています。ほとんどの主要ベンダーによるこの既存のOSサポートは、ほとんどの場合、ラップトップ、電話、テーブルなどの企業内の既存のハードウェアを活用して、コストのかかる更新や交換なしでパスキーを使用してFIDOをデプロイできることを意味します。

場合によっては、企業はiPadなどの共有のシングルユーザーデバイスを使用します。これらのユースケースでは、デバイスのどのユーザーも資格情報にアクセスできるため、統合プラットフォーム認証システムに保存されているパスキーは適切でない場合があります。このような場合、組織はローミング認証子 (ハードウェアセキュリティキー) を使用して、共有デバイスで使用するパスキーを生成して保存する必要があります。これにより、使いやすさと利便性は同じです。ユーザーのこれらのハードウェアキーを購入して管理するには、追加の費用がかかる場合があることに注意してください。多くの場合、ハードウェアキーを使用すると、ユーザーがアカウントからロックアウトされるリスクを減らすために、バックアップとして 2 つ目のハードウェアキーをユーザーに発行する必要があります。

3. OTPからパスキーへの移行のための展開戦略

3.1 デプロイメント・モデルの特定

パスキーの導入を成功させるための計画を立てるには、組織では、ユーザーとユーザーがその役割で使用するコンピューティングデバイスのニーズを考慮して、スタッフのパスキーの有用性を最大限に引き出す必要があります。少なくとも、パスキーの展開を計画する際には、可能な限り幅広いユーザーがパスキーにアクセスできるようにするために、次の質問を考慮する必要があります。

どのようなコンピューティングデバイスを使用していますか?
ユーザーはラップトップまたはデスクトップコンピューターで作業していますか?モバイルデバイス?錠剤。
デバイスはシングルユーザーデバイスですか、それともマルチユーザー(共有など)デバイスですか?
デバイスは会社によってプロビジョニングされていますか、それともユーザーは職場で自分の個人用デバイスを使用していますか?
USBポート、Bluetooth、NFCの使用に制限はありますか?
インターネットへのアクセスに制限はありますか?
ユーザーは一般的に手袋やマスクを着用しているため、デバイス上の生体認証の使用が制限されていますか?

前の質問に対する回答に基づいて、組織はユーザーのパスキーを保存するためのいくつかのタイプの認証子の1つを選択できます。パスキーの柔軟性は、組織がセキュリティ体制とUXのニーズに応じて組み合わせることができることを意味します。このシリーズの他のドキュメントでは、各タイプの認証子について詳しく説明します。

3.2 デプロイメントテスト

デプロイメント・モデルを決定し、アプリケーションが統合されたFIDOサーバーをデプロイした後、組織はパイロット・グループを使用して、ユーザーによる登録、認証、およびリカバリ・プロセス(以下を参照)をテストすることをお勧めします。次に、パイロットからのフィードバックを使用してプロセスを改善し、パイロットの人々から提起された問題に対処してから、パスキーの広範な展開に着手します。

3.3 ユーザーエクスペリエンス

3.3.1 登録

企業は、以前のFIDOホワイトペーパーで述べたように、ユーザーがパスキーに正確かつ安全に関連付けられていることを確認するために、信頼性の高い登録プロセスを実装する必要があります。登録エクスペリエンスは、ユーザーがパスキーを初めて操作するため、考慮することが重要です。ここでは、登録エクスペリエンスの設計に関して考慮すべき要素をいくつか紹介します。

IDプルーフィング – 登録プロセスの開始時に物理的またはリモートでユーザーに身元を証明させることは、強力で悪用に強いプロセスを確保するために推奨されます。これには、最終的なSMS OTPが含まれる場合があります。
セルフサービス登録 – ユーザーは既存の資格情報を使用して、新しいパスキーをブートストラップします。
監視付き登録 – IT/ヘルプデスクと協力して登録します。これにより、元の Creds のフィッシングに対して脆弱なセルフサービスモデルに関連するリスクが軽減されます。
事前にプロビジョニングされた資格情報 – 高労力、高保証ですが、資格情報をユーザーの手に渡すためのメカニズムが必要です。
リモートユーザー – セルフサービスまたは事前プロビジョニングされていますが、初めてデバイスのロックを解除するためにユーザーに PIN を提供するメカニズムが必要です。

3.3.2 サインイン

パスキーを使用したFIDOデプロイメントを設計する最初のステップは、ユーザーベース、一般的な作業パラダイム、利用可能なデバイス(電話、タブレット、ラップトップ、デスクトップ)を理解することです。ユーザーの既存のデバイスと連携するユーザーフレンドリーなワークフローを実現することは、ロールアウトを成功させるための中核であるため、この手順は重要です。

一般的なユーザーの環境と同等の提案には、次のものがあります。

主にモバイルデバイスまたはタブレットを操作するユーザーがいる環境 – 組み込みのロック解除機能を調べます。
混在デバイス環境またはさまざまなSaaSツールに依存する環境 – IDPが提供するSSOを活用するか、柔軟なログインワークフローを構築します。
共有アカウント – FIDO RPは、1つのログインに複数の資格情報を関連付けることができるように構成できます。調べる
クロスデバイスハイブリッド認証またはローミングオーセンティケーター。

3.3.3 リカバリー

認証プロセスは、その最も弱い点と同じくらい強力であるため、攻撃者がリカバリプロセスを悪用してシステムを危険にさらすことがよくあります。同期されたパスキーは、パスキープロバイダーから復元することでデバイスの紛失や意図しないワイプに耐えることができる耐久性のある資格情報であり、ユーザーの新しい資格情報を確立するためにアカウントの回復を実行する必要性を減らすことができます。パスキーを使用すると、ユーザーは資格情報を失う頻度が少なくなることが期待されます。ただし、パスキーまたはパスキーへのアクセスが失われ、アカウントの回復が必要になる場合があります。

バックアップまたはリカバリできないデバイス固定パスキーを使用するパスキーの実装では、バックアップ認証方法(バックアップ認証子の使用など)を使用してアカウントの回復を実行し、新しい認証子の登録をブートストラップする必要があります。バックアップ認証メカニズムが利用できない場合、組織はリカバリへの代替パスを提供する必要があります。組織は、アカウントリカバリーシステムの設計と実装にリスクベースのアプローチを取る必要があります。具体的な実装の詳細は、組織の要件によって大きく異なります。一般に、復旧メカニズムは、ユーザーが復旧しようとしている認証情報よりも弱い要因に依存しないようにする必要があります。パスキーを再登録する必要がある場合、組織は、そのユーザーに登録されなくなったパスキーの使用を防ぐためのメカニズムを自動または手動で設計する必要があります。

同期パスキーを使用するパスキーの実装については、新しいデバイスのブートストラップ/登録プロセスを文書化し、プロバイダーアカウントの完全な回復または交換のためのリスク回避プロセス(IDプルーフィングを含む)を構築してください。これらの壊滅的なイベントは低いはずですが、それでもユーザーにこのプロセスを経てもらう必要があるかもしれません。適切なプロセスを事前に知っておくことで、組織は操作から保護され、作業イベントが停止されます。

アカウントの復旧に関するその他の考慮事項については、 FIDO アライアンスの FIDO 証明書利用者向けの推奨アカウント復旧プラクティスを参照してください。[5]

3.4 管理者に関する考慮事項:

実装と導入のメトリックの監視は、デプロイの成功を確保し、パスキーを使用したFIDO認証のセキュリティ上の利点を確実に実現するために重要です。以下は、エンタープライズパスキーの移行の成功を示すメトリクスとプロセスの推奨事項です。

3.4.1 使用状況の監視と可視性

管理者は、グループまたはその他のセグメンテーション構造を使用して、ユーザーとアプリケーションのサブセットをパスキーに適切に移行できるようにすることを強くお勧めします。パイロット集団は慎重に構築し、組織内のさまざまなエンドユーザーの種類とレベルで構成する必要があります。移行前と移行後の両方で以下の項目の使用状況を監視することで、プログラムの有効性に関する重要な洞察が得られ、重要な調整を導きます。

デバイスの登録:
- ユーザーが最初のデバイスを登録するのにどれくらいの時間がかかりましたか?
セキュリティイベント:
- オンボーディング時のデバイスはどこにありましたか?
- 正しいユーザーがオンボーディングされていることを確認するために、どのようなID証明アプローチが使用されましたか?
- マネージャー、IT サポート、またはピア承認ワークフローが使用された場合、誰が構成証明を提供しましたか?
- 以前は存在しなかった時間帯やデバイスの位置情報の異常はありますか?
ユーザー認証:
- ユーザーは正常に認証できましたか?
- 日常的な認証パターンに、問題や摩擦の増加を示唆する観察可能な変化はありますか?
- 曜日と時間帯の分析は何か問題を示唆していますか?
キー管理:
- キーは期待どおりに使用され、既知のデバイスからのみ使用されていますか?一部のオーセンティケーターは、オーセンティケーターの ID の主要な出所と保証を提供するデバイス構成証明をサポートしています。パスキーのソースが実装にとって重要なセキュリティ制御である場合は、選択した認証子ソリューションがこの種の構成証明をサポートしているかどうかを必ず確認してください。
- 個人のアカウントにはいくつのキーが関連付けられていますか?通常のガイダンスでは、ユーザーのアカウントに関連付けられているパスキーの数は、ユーザーが利用するデバイスの数に近いと想定します。たとえば、ユーザーがAndroidスマートフォンとWindowsラップトップを使用している場合、ユーザーのアカウントに関連付けられたパスキーが2つから3つあり、各プラットフォームの認証システムに1つずつ保存され、場合によってはセキュリティキーからのバックアップが1つ表示されることが予想されます。このシナリオでは、アカウントに5〜6個のパスキーが登録されている場合、調査して過剰なキーを削除する必要があります。すべての組織の過剰の定義は異なる場合があり、環境からの観察に基づいて定義する必要があります。また、デプロイメントによっては、パスキー認証を有効にしたアプリケーションの数も考慮してください。SSO 統合の認証情報としてパスキーをデプロイした場合、ユーザーはデバイスごとに 1 つのパスキーしか持つことができません。アプリケーションごとにパスキーをデプロイした場合、アプリケーションごとにデバイスごとに 1 つのパスキーが存在する可能性があります。組織は、各ユーザーに関連付けられたキーの数を監視し、このデータをパスキー管理に通知するためのコンテキストとして使用することをお勧めします。
管理/サービス/非常用アカウントに関連付けられているキーは誰ですか?管理アクセスを通常のユーザーアクセスから分離することがベストプラクティスであるのと同様に、管理アカウント用に個別のパスキーのセットを生成することもお勧めします。共有する場合は、ローテーション、監視、および適切なクリーンアップの実践を必ず含めてください。
パスキーはどのように削除されますか?従業員が会社を辞めたり、別の役割に異動したりした場合は、そのアカウントを無効にするか、削除するか、アクセスを評価して審査する必要があります。法的要件によりこれが合理的でない場合は、無効化プロセスの一環として、アカウントの不正アクセスを防ぐために、パスキーを速やかに削除する必要があります。同様に、ユーザーがデバイスの紛失や盗難を報告した場合は、それらのデバイスに関連付けられているパスキーもすべて削除する必要があります。
互換性の保証:
- アプリケーションとエンドポイントプラットフォームの組み合わせで、認証イベントに異常な変化や減少が見られますか?
- パスキー認証のすべての呼び出し方法は、アップグレード後を含め、継続的に機能していますか?