Okta FastPassは、フィッシング耐性のあるOktaの認証者で、iOS、macOS、Windows、Androidのデバイスで利用可能です。数年前、一部のお客様から、特定のWindows仮想環境でFastPassが正常に機能しないという報告がありました。そこで、問題の特定と解決に着手したところ、興味をそそる課題であることがわかりました。
このブログ投稿では、Windows版のOkta VerifyとFastPassに焦点を当てて、一部の仮想環境で動作しなかった理由と、Oktaのエンジニアが創造性を発揮して技術的課題を解決し、仮想環境で認証者を利用できるようにした経緯について解説します。
FastPassの詳細については、FastPassへのディープダイブとFastPassテクニカルホワイトペーパーをご覧ください。
仮想環境でFastPassが機能しなかった理由
FastPassが仮想環境でうまく機能しなかった理由は主に2つあります。1つ目はデバイスへの依存関係に関する問題、2つ目はWindows Helloによるユーザー検証に関する問題です。これらの問題について詳しく説明する前に、仮想環境の種類とそれぞれの違いについて確認しておきましょう。
VDIとは
VDIとは、Virtual Desktop Infrastructure（仮想デスクトップ基盤）の略で、ユーザーがデスクトップ形式の仮想マシンにアクセスできるように設計された、あらゆる仮想化インフラストラクチャを指す総称です。VDIという用語は、そのインフラストラクチャ自体を指す場合と、ユーザーが接続する仮想デスクトップそのものを指す場合の両方に使われます。
VDIの種類
主に3種類のVDIがあります。
- 永続型（Persistent）
- 非永続型（Non-persistent）
- レイヤー型（Layered）
永続型VDI（Persistent VDI）
永続型VDIとは、VDIの状態とユーザーのすべてのデータがセッション間で維持されるタイプのことです。たとえば、ユーザーが自分のノートPC上に仮想マシンを作成すると、それは永続的なVDIのように機能します。ユーザーが接続すると毎回、デスクトップの状態とすべてのデータが維持されます。
複数のユーザーと複数の仮想マシンが存在する環境では、通常、ユーザーは特定のマシンに静的に割り当てられます。つまり、ユーザーはログオンするたびに同じ仮想マシンに接続します。このため、永続型VDIは、静的VDIと呼ばれることもあります。
非永続型VDI（Non-persistent VDI）
非永続型VDIでは、仮想マシンの状態（ユーザーの全データなど）は、セッション間で維持されません。各セッションの終了後に仮想マシンは消去されるか、クリーンなマスターイメージの状態に復元されます。ほとんどの環境では、新しい仮想マシンのプールが用意されており、その中からユーザー用のマシンがランダムに割り当てられます。そのため非永続型VDI環境では、ユーザーはログオンするたびに異なる仮想マシンに接続する可能性があります。
レイヤー型VDI（Layered VDI）
一部のインフラプロバイダーは、永続型と非永続型を組み合わせたハイブリッド型のVDIを提供しています。これらの環境は通常、複数の明確なレイヤーに分割されていて、ユーザーレイヤー、アプリケーションレイヤー、マシンレイヤーなどがあります。そのため、このような環境は「レイヤー型VDI」と呼ばれます。レイヤー型VDI環境では、ユーザーは非永続型の仮想マシンに接続しますが、ユーザープロファイルサービスによってユーザーのデータが同期されて、セッション間で維持されます。非永続型VDIと同様に、ユーザーはログオンするたびに異なる仮想マシンに接続する可能性があります。しかし、永続型VDIと同じように、ユーザーのデータはセッション間で維持されます。
レイヤー型VDI環境は、ユーザーが実質的に複数の仮想マシン間を移動する形になるため、サポートが最も難しい仮想環境です。ここでは、まずレイヤー型VDIをサポートするうえでの技術的課題に焦点を当て、その後、静的（永続型）VDIのサポートにも共通する課題と解決策について簡単に説明します。
レイヤー型VDIのサポート
レイヤー型VDI環境をサポートするために、対処する必要のあるOkta VerifyとFastPassのコンポーネントが4つありました。
- PoP暗号キーペアを保護するために使用されるサービスアカウント
- TPMで保護された暗号キー
- Okta Verifyにローカル保存される認証情報
- Oktaバックエンドに送信されるデバイス識別情報
以下では、各コンポーネントについて詳しく見ていきます。
Okta Verifyサービスアカウント
Okta Verifyが認証に使用する暗号キーペアの1つに、所有証明（Proof-of-Possession：PoP）キーペアがあります。PoPキーは、ユーザー操作を伴わないサイレントな一要素認証に使用されるため、ユーザーの知らないところで別のプロセスにアクセス・利用されないよう保護する必要があります。従来、Okta VerifyはPoPキーを保護するためにローカルのWindowsアカウントを作成していました。このアカウントはOkta Verifyサービスアカウント（またはサンドボックスアカウント）と呼ばれます。PoPキーの操作時、Okta Verifyはこのサービスアカウントになりすまして処理を行います。しかし、このアカウントはローカルユーザーアカウントなので、レイヤー型VDI環境ではユーザーとともに仮想マシン間を移動できません。
解決策：仮想環境でPoPキーを保護するため、パスコードによるキー保護を採用しました。アプリケーション起動時に、Okta Verifyはキー保護用のパスコードを生成します。Okta VerifyがWin32 APIを使用してPoPキーを作成する際、NCryptSetProperty関数とNCRYPT_PIN_PROPERTY識別子を用いてキーハンドルにPINプロパティを設定し、キー保護用パスコードを提供します。このプロパティを設定すると、オペレーティングシステムは指定したキー保護用パスコードで保護されたキーを作成します。作成後にキーを使用する際には、正しいパスコードを提供する必要があります。こうして、このマシン上でキー保護用パスコードを持たない他のプロセスが、PoPキーを読み込んだり使用したりすることを防止できます。
TPMで保護された暗号キー
Okta Verifyは、利用可能な場合、作成した暗号キーをマシンのTrusted Platform Module（TPM）によって保護します。多くの仮想環境でも仮想TPMが備わっているため、Okta Verifyは暗号キーをTPMで保護できます。ただしレイヤー型VDI環境では、Okta VerifyはTPMを使ってキーを保護することができません。Okta VerifyがTPMでキーを保護する場合、それらのキーは暗号的にそのTPMにバインドされます。レイヤー型VDI環境のように、Okta Verifyが別のTPMを持つ別のマシンへ移動すると、作成したキーにアクセスできなくなり、ユーザー認証も行えなくなります。
解決策：レイヤー型VDI環境では、Okta Verifyは暗号キーをソフトウェアキーストレージプロバイダーに、エクスポートできない形式で保存します。ソフトウェアキーストレージプロバイダーは、Windowsオペレーティングシステムによって提供・実装されており、キーをユーザーのディレクトリ内にファイルとして保存します。レイヤー型VDIのユーザープロファイル同期サービスがユーザーのディレクトリを同期する際、ソフトウェアキーストアに保存されているそのユーザーのすべてのキーも同期されます。詳細については、Microsoftのキーストレージに関するドキュメントをご覧ください。
Okta Verifyの認証情報
Okta Verifyは、アプリケーションリソースを保護するために使用するアプリケーション認証情報を、Windowsの資格情報マネージャーに保存します。Okta Verifyは、この認証情報のPersistプロパティを常にCRED_PERSIST_LOCAL_MACHINEに設定していたため、認証情報はローカルマシンに保存されていました。ローカルに保存された認証情報は、別の仮想マシン上のOkta Verifyからはアクセスできません。
解決策：レイヤー型VDI環境において、認証情報をユーザープロファイルとともに仮想マシン間で移動できるようにするため、PersistプロパティにCRED_PERSIST_ENTERPRISEを設定するようにしました。
デバイス情報
Okta Verifyは、2つのデバイス識別情報を収集して、Oktaバックエンドに報告します。
- デバイス名
- デバイスのセキュリティ識別子（SID）
レイヤー型VDI環境では、どちらのデバイス識別子もセッションごとに変わる可能性があるため、認証の失敗などの予期しない動作が発生する場合がありました。
解決策：レイヤー型VDI環境で一貫したデバイス識別情報を報告するために、セッション間で変化しないユーザーのSIDを基準となる識別子として使用します。そこからデバイス名を生成し、デバイスのSIDとしてそのまま報告する仕組みにしました。
上記の項目に対応したことで、Okta Verifyは仮想環境に対応できるようになりました。しかし、FastPassはまだ完全には対応できておらず、ユーザーはまだユーザー検証を完了できなかったため、さらに対応作業が必要でした。
仮想環境でのユーザー検証
ユーザー検証とは、認証者（Okta FastPassなど）が、ユーザーが実際に存在し、本人であることを確認するプロセスです。
FastPassはユーザー検証にWindows Helloを使用しており、ユーザーはPINまたは生体認証によって本人確認を行うことができます。しかし、ほとんどの仮想マシンにはWindows Helloが搭載されていません。仮想環境でもユーザー検証を伴う二要素認証を完了できるように、Okta Verify Passcode機能を導入しました。
FastPassの登録
FastPassの登録時に、ユーザーはOkta Verify内で8桁のパスコードを作成するように求められます。
Okta Verifyがユーザー検証用の暗号キーペアを作成する際には、同じWin32 APIを使用してキーハンドルにNCRYPT_PIN_PROPERTYを設定し、その値にユーザーのパスコードを指定します。この指定によって、ユーザーのパスコードが提供された場合にのみ、ユーザー検証用のキーにアクセスできるようになります。Okta Verifyは、ユーザーのパスコードを保存しません。Win32 APIを通じてオペレーティングシステムに渡すだけです。
FastPass認証
認証時に、Okta Verifyはユーザーにパスコードの入力を求め、ユーザーの検証を完了させます。
Okta Verifyがユーザー検証用のキーを読み込み、認証チャレンジ用のJWTに署名する際には、再度キーハンドルにNCRYPT_PIN_PROPERTYを設定し、ユーザーが入力したパスコードを指定します。オペレーティングシステムは検証処理を行い、ユーザーが正しいパスコードを入力したことを確認します。
間違ったパスコード
ユーザーが間違ったパスコードを入力した場合、認証リクエストが失敗するまでに最大2回再試行できます。
Okta Verifyはユーザーのパスコードを保存していないため、誤ったパスコードを直接検出できません。その代わりに、キーストレージプロバイダーから返されるエラーを処理して、ユーザーが入力したパスコードが誤っているかどうかを判断し、「パスコードが正しくありません」というエラーをユーザーに表示します。課題は、返されるエラーがキーストレージプロバイダーによって異なる点にあります。
キーがソフトウェアプロバイダーに保存されている場合、キーを開いてキーハンドルにNCRYPT_PIN_PROPERTYを誤った値で設定すると、エラーコードNTE_INCORRECT_PASSWORD（0x80090033）が返されます。この方法で、ユーザーが間違ったパスコードを入力したことを簡単に検出できます。
ただし、TPMの動作は異なります。まず、キーを開き、キーハンドルにNCRYPT_PIN_PROPERTYを誤った値に設定しても、エラーコードは返されません。代わりに、キーハンドルがデータのハッシュ化などに使用されてから、後でエラーコードが返されます。次に、返されるエラーコードはNTE_INCORRECT_PASSWORDではなく、NTE_PERM（つまり、アクセス拒否、0x80090010）です。
アクセス拒否エラーは、さまざまな状況で発生し得る一般的なエラーであるため、すべてのアクセス拒否エラーをユーザーによるパスコードの誤入力として単純に処理することはできません。逆に、操作のコンテキストに基づいてアクセス拒否エラーを処理する必要があります。ユーザー検証用のキーを使用しようとした際にアクセス拒否エラーを受け取った場合、そのキーがユーザーの設定したパスコードで保護されていることがわかっていれば、そのエラーを誤ったパスコードとして扱い、ユーザーにパスコードの再入力を許可します。
静的VDIのサポート
静的VDIは比較的容易にサポートできました。動作は物理マシンと非常によく似ています。レイヤー型VDIのサポートにおける課題を解決した後は、その解決策の一部を静的VDIのサポートにも再利用できました。静的VDIをサポートするうえでの主な課題はユーザー検証です。この課題に対処するため、静的VDIでもユーザー検証にOkta Verify Passcodeを使用しています。
非永続型VDIのサポートに関する注意
Okta Verifyは非永続型VDIではサポートされていません。これは、ユーザーのOkta Verifyデータを含め、ユーザーデータがセッション間で維持されないためです。ユーザーが非永続型VDI上でFastPassの登録を試みても、そのVDIからログオフして再度ログオンすると、登録情報は失われます。
仮想環境向けのOkta Verifyの設定
管理者が仮想環境向けにOkta Verifyを設定できるよう、新たにAuthenticatorOperationModeという設定フラグを追加しました。このフラグには3つの値があります。
- ノーマル
- VirtualDesktopStatic
- VirtualDesktopLayered
仮想環境向けのOkta Verifyの設定について詳しくは、ドキュメントをご覧ください。
また、管理者がOkta Verifyの構成で、ユーザー検証にOkta Verify Passcodeを使用する設定にできるよう、新たにUserVerificationTypeというインストーラーフラグを追加しました。このフラグには2つの値があります。
- Windows Hello
- OktaVerifyPasscode
管理者の負担を軽減するため、AuthenticatorOperationModeの設定値に応じてUserVerificationTypeのデフォルト値が自動的に調整されるようにしています。
- モードがNormalの場合、UserVerificationTypeのデフォルトはWindowsHello
- モードがVirtualDesktopStaticまたはVirtualDesktopLayeredの場合、UserVerificationTypeのデフォルトは OktaVerifyPasscodeになります。
仮想環境でOkta Verifyを実行し、ユーザー検証にOkta Verify Passcodeを使用するには、管理者はAuthenticatorOperationModeを適切に設定するだけで済みます。UserVerificationTypeは自動的にOkta Verify Passcodeに設定されます。
Okta Verifyでユーザー検証タイプを設定する方法について詳しくは、ドキュメントをご覧ください。
新しいインストーラーフラグに関する注記
AuthenticatorOperationModeとUserVerificationTypeのインストーラーフラグは、Okta Verifyの中核機能を変更するため、これらの値はインストール時に一度だけ設定されます。インストール後に値を変更しても反映されません。これは、Okta Verifyが不適切に動作するのを防ぐために必要な措置です。しかし最近では一部のお客様から、インストール後にユーザー検証タイプを別の方式へ移行したいというご要望が寄せられています。
物理マシンでWindows Helloの代わりにOkta Verify Passcodeを使用する
管理者がユーザーにWindows Helloを使用させたくない場合や、物理マシンであってもユーザーがWindows Helloを利用できない場合があります。そのため、Okta Verify Passcode機能は物理マシンでも動作するよう設計されています。物理マシンでOkta Verify Passcodeによるユーザー検証を有効にするために、UserVerificationTypeをAuthenticatorOperationModeとは独立して設定できます。
詳細については、ドキュメントをご覧ください。
お試しください
ご興味をお持ちでしたら、ぜひお試しください。Windows版Okta Verifyの最新バージョンは、管理者ダッシュボードからダウンロードしてインストールできます。仮想環境向けのOkta Verifyの構成方法とユーザー検証タイプの構成方法については、必ずガイドラインに従ってください。
このブログ記事についてのご質問は、eng_blogs@okta.comまでご連絡ください。
Oktaの洞察力に富んだエンジニアリングブログで、知識をさらに深めてください。
Oktaの情熱的で優秀なエンジニアチームで働きませんか？採用情報ページをご覧ください。
Oktaは、最新かつ高度なアイデンティティ管理の可能性を解き放ちます。詳細は、セールス担当者にお問い合わせください。
