Windows Hello for Business のしくみ
Windows Hello for Business は、複数のテクノロジを連携させる必要がある分散システムです。 Windows Hello for Business のしくみの説明を簡略化するために、展開プロセスの時系列順を表す 5 つのフェーズに分割します。
注
これらのフェーズのうち 2 つは、特定のデプロイ シナリオでのみ必要です。
展開シナリオについては、「 Windows Hello for Business の展開を計画する」の記事で説明されています。
デバイス登録フェーズ
このフェーズでは、ID プロバイダー (IdP) に ID を登録し、IdP に関連付けて認証できるようにします。
プロビジョニング フェーズ
このフェーズでは、ユーザーは 1 つの形式の認証 (通常はユーザー名/パスワード) を使用して認証を行い、新しい Windows Hello for Business 資格情報を要求します。 プロビジョニング フローでは、公開キーと秘密キーのペアを生成する前に、認証の 2 番目の要素が必要です。 公開キーは IdP に登録され、ユーザー アカウントにマップされます。
キー同期フェーズ
一部のハイブリッド展開で必要なこのフェーズでは、ユーザーの公開キーが Microsoft Entra ID から Active Directory に同期されます。
証明書の登録フェーズ
このフェーズでは、 証明書を使用した展開でのみ必要です。証明書は、組織の公開キー 基盤 (PKI) を使用してユーザーに発行されます。
認証フェーズ
この最後のフェーズでは、ユーザーは生体認証または PIN を使用して Windows にサインインできます。 使用されるジェスチャに関係なく、認証は Windows Hello for Business 資格情報のプライベート部分を使用して行われます。 IdP は、プロビジョニング フェーズ中に登録された公開キーにユーザー アカウントをマッピングすることで、ユーザー ID を検証します。
次のセクションでは、これらの各フェーズについてより深い分析情報を提供します。
デバイスの登録
Windows Hello for Business 展開に含まれるすべてのデバイスは、 デバイス登録と呼ばれるプロセスを通過する必要があります。 デバイス登録を使用すると、デバイスを関連付け、IdP に対する認証を行うことができます。
- クラウドおよびハイブリッド展開の場合、ID プロバイダーは Microsoft Entra ID で、デバイスはデバイス登録サービスに登録されます
- オンプレミス展開の場合、ID プロバイダーは Active Directory フェデレーション サービス (AD FS) で、デバイスは AD FS でホストされている Enterprise Device Registration Service に登録されます
デバイスが登録されると、IdP は、ユーザーがサインインするときにデバイスの認証に使用される ID をデバイスに提供します。
登録の種類はさまざまで、 結合の種類として識別されます。 詳細については、「 デバイス ID とは」を参照してください。
詳細なシーケンス図については、 デバイスの登録のしくみに関するページを参照してください。
プロビジョニング
Windows Hello プロビジョニングは、デバイスの登録が完了すると、デバイスが Windows Hello を有効にするポリシーを受け取った後にトリガーされます。 すべての前提条件が満たされている場合は、クラウド eXperience Host (CXH) ウィンドウが起動され、ユーザーがプロビジョニング フローを通過します。
注
展開の種類に応じて、Windows Hello for Business プロビジョニングは次の場合にのみ起動されます。
- デバイスが Windows Hello ハードウェア要件を満たしている
- デバイスが Active Directory または Microsoft Entra ID に参加している
- ユーザーは、Active Directory または Microsoft Entra ID で定義されたアカウントでサインインします
- Windows Hello for Business ポリシーが有効になっている
- ユーザーがリモート デスクトップ経由でマシンに接続されていない
特定の展開の種類の追加の前提条件については、「 Windows Hello for Business の展開を計画する」の記事を参照してください。
プロビジョニング フェーズ中に、 Windows Hello コンテナー が作成されます。 Windows Hello コンテナーは、 キー マテリアルまたはデータの論理グループです。 コンテナーは、組織の IdP に 登録されている デバイスにのみ組織の資格情報を保持します。
注
ディスク、レジストリ、またはその他の場所に物理コンテナーはありません。 コンテナーは、関連項目のグループ化に使用される論理ユニットです。 Windows Hello が格納するキー、証明書、資格情報は、実際のコンテナーやフォルダーを作成せずに保護されます。
プロビジョニング フェーズに関連する手順を次に示します。
- [CXH] ウィンドウで、ユーザーは MFA を使用して IdP に対する認証を求められます
- MFA が成功した後、ユーザーはバイオ ジェスチャ (使用可能な場合) と PIN を指定する必要があります
- PIN の確認後、Windows Hello コンテナーが作成されます
- 公開キーと秘密キーのペアが生成されます。 キー ペアは、トラステッド プラットフォーム モジュール (TPM) (使用可能な場合)、またはソフトウェアにバインドされます
- 秘密キーはローカルに保存され、TPM によって保護され、エクスポートできません
- 公開キーは IdP に登録され、ユーザー アカウントにマップされます
- デバイス登録サービスは、Microsoft Entra ID でユーザー オブジェクトにキーを書き込みます
- オンプレミスのシナリオでは、AD FS によって Active Directory にキーが書き込まれます
次のビデオは、パスワードでサインインした後の Windows Hello for Business 登録手順を示しています。
詳細と詳細なシーケンス図については、 プロビジョニングのしくみに関するページを参照してください。
Windows Hello コンテナーの詳細
プロビジョニング フェーズ中に、Windows Hello によってデバイスに新しい公開キーと秘密キーのペアが生成されます。 TPM によって秘密キーが生成され、保護されます。 デバイスに TPM がない場合、秘密キーは暗号化され、ソフトウェアに格納されます。 この初期キーは、 保護機能キーと呼ばれます。 プロテクター キーは、1 つのジェスチャに関連付けられます。ユーザーが PIN、指紋、顔を同じデバイスに登録した場合、これらのジェスチャにはそれぞれ一意の保護機能キーがあります。
保護機能キーは 、認証キーを安全にラップします。 認証キーは、 ユーザー ID キーのロックを解除するために使用されます。 各コンテナーの認証キーは 1 つのみですが、このキーを別の固有な保護機能キーでラップして複数のコピーを作成できます。
各保護機能は、認証キーの独自のコピーを暗号化します。 暗号化の実行方法は、保護機能自体にかかります。 たとえば、PIN 保護機能は、PIN をエントロピとして使用して TPM シール操作を実行するか、TPM が使用できない場合は、PIN 自体から派生したキーを使用して認証キーの対称暗号化を実行します。
重要
キーは、構成されたポリシー設定に基づいて、ハードウェア (TPM 1.2 または 2.0) またはソフトウェアで生成できます。 ハードウェアでキーが生成されるようにするには、ポリシー設定を構成する必要があります。 詳細については、「 ハードウェア セキュリティ デバイスを使用する」を参照してください。
個人用 (Microsoft アカウント) アカウントと職場または学校 (Active Directory または Microsoft Entra ID) アカウントでは、キーに 1 つのコンテナーが使用されます。 すべてのキーは、ユーザーのプライバシーを確保するために、ID プロバイダーのドメインで分離されます。
Windows Hello では 、管理キーも生成されます。 管理キーは、必要に応じて資格情報をリセットするために使用できます。 たとえば、 PIN リセット サービスを使用する場合などです。 保護機能キーに加えて、TPM が有効なデバイスは、TPM の構成証明を含むデータ ブロックを生成します。
コンテナーに格納されているキー マテリアルへのアクセスは、PIN または生体認証ジェスチャによってのみ有効になります。 プロビジョニング中に行われる 2 段階認証では、IdP とユーザーの間に信頼された関係が作成されます。 これは、公開キーと秘密キーのペアの公開部分が ID プロバイダーに送信され、ユーザー アカウントに関連付けられている場合に発生します。 ユーザーがデバイス上でジェスチャを入力すると、ID プロバイダーは、Windows Hello キーとジェスチャーの組み合わせのために、検証済みの ID であることを認識します。 その後、Windows がリソースとサービスにアクセスできるようにする認証トークンが提供されます。
コンテナーには、いくつかの種類のキー マテリアルを含めることができます。
- 認証キー。これは常に非対称公開秘密キーのペアです。 このキーのペアは登録時に生成されます。 ユーザーの PIN または生体認証ジェスチャを使用して、アクセスするたびにロックを解除する必要があります。 認証キーは、ユーザーが PIN をリセットするまで存在し、その時点で新しいキーが生成されます。 新しいキーが生成されると、以前に保護されていた古いキーのすべてのキー マテリアルを復号化し、新しいキーを使用して再暗号化する必要があります
- 1 つまたは複数の ユーザー ID キー。 これらのキーは、使用する IdP に応じて、対称キーまたは非対称キーを使用できます。 証明書ベースの Windows Hello for Work の場合、コンテナーのロックが解除されると、ユーザー ID キーまたはキー ペアへのアクセスを必要とするアプリケーションはアクセスを要求できます。 ユーザー ID キーは、このデバイスから IdP に送信される認証要求またはトークンの署名または暗号化に使用されます。 通常、ユーザー ID キーは有効期間が長くなりますが、認証キーよりも有効期間が短くなる可能性があります。 Microsoft アカウント、Active Directory アカウント、Microsoft Entra アカウントはすべて、非対称キー ペアを使用する必要があります。 デバイスは公開キーと秘密キーを生成し、公開キーを IdP に登録し (後で検証するために保存します)、秘密キーを安全に格納します。 組織の場合、ユーザー ID キーは次の 2 つの方法で生成できます。
- ユーザー ID キー ペアは、組織の証明機関 (CA) に関連付けることができます。 このオプションにより、既存の PKI を保持する組織は、必要に応じてその PKI を使い続けられます。 VPN ソリューションなど、多くのアプリケーションで証明書の使用が必要であることを考えると、このモードで Windows Hello を展開すると、証明書ベースの機能を維持しながら、ユーザー パスワードからすばやく切り替えることができます。 このオプションを使用すると、組織は保護されたコンテナーに他の証明書を格納することもできます。 たとえば、ユーザーが RDP 経由で認証できるようにする証明書などです。
- IdP はユーザー ID キー ペアを直接生成できるため、PKI がない環境や必要な環境での Windows Hello の迅速かつ低オーバーヘッドの展開が可能になります。
ユーザー ID キーは、サービスに対するユーザーの認証に使用されます。 たとえば、nonce に署名して秘密キーを所有していることを証明します。これは、登録済みの公開キーに対応します。 Active Directory、Microsoft Entra ID、または Microsoft アカウントを持つユーザーには、自分のアカウントにキーが関連付けられています。 キーを使用して、ドメイン コントローラー (Active Directory シナリオ)、またはクラウド (Microsoft Entra ID と MSA シナリオ) に対して認証することで、Windows デバイスにサインインできます。
Windows Hello は、FIDO2 認証システムとして使用して、WebAuthn をサポートするすべての Web サイトに対して認証することもできます。 Web サイトまたはアプリケーションは、API を使用して、ユーザーの Windows Hello コンテナーに FIDO ユーザー ID キーを作成できます。 その後の訪問時に、ユーザーは Windows Hello PIN または生体認証ジェスチャを使用して、Web サイトまたはアプリに対して認証を行うことができます。
Windows Hello for Business のサポートで Windows が TPM を使用する方法の詳細については、「 Windows でトラステッド プラットフォーム モジュールを使用する方法」を参照してください。
生体認証データ ストレージ
Windows Hello をサポートするために使われる生体認証データは、ローカル デバイスにのみ保存されます。 ローミングは行われず、外部デバイスやサーバーに送信されることはありません。 このような分離は、潜在的な攻撃を防ぐために役立ちます。攻撃者が生体認証データを盗もうとしても、侵入先として狙いやすいデータの集約場所がないためです。 攻撃者がデバイスから生体認証データを取得できたとしても、生体認証センサーで認識できる生の生体認証サンプルに戻すことはできません。
各センサーには、テンプレート データが格納されている独自の生体認証データベース ファイルがあります (パス C:\WINDOWS\System32\WinBioDatabase)。 各データベース ファイルには、システムに対して暗号化された一意のランダムに生成されたキーがあります。 センサーのテンプレート データは、CBC チェーン モードの AES を使用して、データベースごとのキーで暗号化されます。 ハッシュは SHA256 です。
注
一部の指紋センサーには、OS ではなく指紋センサー モジュールで照合を完了する機能があります。 これらのセンサーは、データベース ファイルではなく指紋モジュールに生体認証データを格納します。 詳細については、「 Windows Hello Enhanced Security Sign-in (ESS)」を参照してください。
キー同期
ハイブリッド環境ではキー同期が必要です。 ユーザーが Windows Hello for Business 資格情報をプロビジョニングした後、キーは Microsoft Entra ID から Active Directory に同期する必要があります。
ユーザーの公開キーは、Active Directory の msDS-KeyCredentialLink ユーザー オブジェクトの属性に書き込まれます。 同期は Microsoft Entra Connect Sync によって処理されます。
証明書の登録
証明書のデプロイでは、キーを登録した後、クライアントによって証明書要求が生成されます。 要求は証明機関 (CRA) に送信されます。 CRA は Active Directory フェデレーション サービス (AD FS) サーバー上にあり、証明書要求を検証し、エンタープライズ PKI を使用してそれを満たします。
証明書は、ユーザーの Hello コンテナーに登録されます。これは、オンプレミスのリソースに対する認証に使用されます。
認証
Windows Hello 資格情報は、証明書または非対称キー ペアに基づいています。 Windows Hello 資格情報と、それらの資格情報を使用して取得されたトークンは、デバイスにバインドされます。
認証は、次の組み合わせによる 2 要素認証です。
- デバイスに関連付けられているキーまたは証明書
- その人が知っているもの (PIN) または
- その人が何か (生体認証)
PIN エントリと生体認証ジェスチャはどちらも、Id プロバイダーに送信されるデータに暗号化的に署名するために秘密キーを使用するように Windows をトリガーします。 IdP は、ユーザーの ID を検証し、ユーザーを認証します。
資格情報の PIN またはプライベート部分は IdP に送信されることはなく、PIN はデバイスに格納されません。 PIN とバイオ ジェスチャは、資格情報のプライベート部分を使用する操作を実行するときに 、ユーザーが提供するエントロピ です。
ユーザーが保護されたキーマテリアルにアクセスする場合、認証プロセスは、ユーザーが PIN または生体認証ジェスチャを入力してデバイスのロックを解除することから始まります。これは、 キーを解放するプロセスと呼ばれることもあります。 ドアのロックを解除する物理的な鍵を使用する場合を考えてみてください。ドアのロックを解除する前に、ポケットまたは財布から鍵を取り出す必要があります。 ユーザーの PIN は、デバイス上のコンテナーの保護機能キーのロックを解除します。 そのコンテナーのロックが解除されると、アプリケーション (したがって、ユーザー) は、コンテナー内に存在するすべてのユーザー ID キーを使用できます。
これらのキーは、IdP に送信される要求に署名し、指定されたリソースへのアクセスを要求するために使用されます。
重要
キーはロック解除されますが、アプリケーションではそのキーを使用できません。 アプリケーションは特定の API を使って、特定の動作にキー マテリアルが必要な操作を要求できます (たとえば、電子メール メッセージの暗号化の解除または Web サイトへのサインイン)。 これらの API を介したアクセスでは、ユーザー ジェスチャによる明示的な検証は必要ありません。また、キー マテリアルは要求側のアプリケーションに公開されません。 代わりに、アプリケーションは、認証、暗号化、または暗号化解除を求め、Windows Hello レイヤーは、実際の作業を処理し、結果を返します。 必要に応じて、アプリケーションはロック解除されたデバイス上でも強制的に認証を要求できます。 PIN の再入力または認証ジェスチャの実行を求めるメッセージが表示されます。ここでは、機密性の高いデータまたは操作の保護レベルをさらに追加します。 たとえば、デバイスのロックを解除するために同じアカウントと PIN またはジェスチャが既に使用されていた場合でも、特定の操作が実行されるたびに再認証を要求するようにアプリケーションを構成できます。
詳細と詳細なシーケンス図については、 認証のしくみに関するページを参照してください。
プライマリ更新トークン
シングル サインオン (SSO) は、特定のアプリケーションにアクセスするために取得された特別なトークンに依存します。 Kerberos を使用する従来の Windows 統合認証ケースでは、トークンは Kerberos TGT (チケット許可チケット) です。 Microsoft Entra ID および AD FS アプリケーションの場合、このトークンは プライマリ更新トークン (PRT) です。 これは、ユーザーとデバイスの両方に関する要求を含む JSON Web トークン です。
PRT は、サインイン中またはロック解除時に、Kerberos TGT の取得と同様の方法で最初に取得されます。 この動作は、Microsoft Entra 参加済みデバイスと Microsoft Entra ハイブリッド参加済みデバイスの両方に当てはまります。 Microsoft Entra ID に登録されている個人用デバイスの場合、PRT は最初に 職場または学校アカウントの追加時に取得されます。 個人用デバイスの場合、デバイスのロックを解除するアカウントは職場アカウントではなく、コンシューマー アカウント (Microsoft アカウント) です。
SSO には PRT が必要です。 これを行わないと、ユーザーはアプリケーションにアクセスするたびに資格情報の入力を求められます。 PRT には、デバイスに関する情報も含まれています。 アプリケーションでデバイス ベースの条件付きアクセス ポリシーが設定されている場合、PRT アクセスは拒否されません。
ヒント
Windows Hello for Business キーは、Microsoft Entra 多要素認証 (MFA) の要件を満たし、リソースにアクセスするときにユーザーに表示される MFA プロンプトの数を減らします。
詳細については、「 プライマリ更新トークンとは」を参照してください。
Windows Hello for Business とパスワードの変更
Windows Hello for Business ではキーまたは証明書が使用されるため、ユーザー アカウントのパスワードを変更してもサインインやロック解除には影響しません。
ただし、ユーザーがパスワードを変更する必要がある場合 (パスワードの有効期限ポリシーなど)、Windows Hello でサインインするときにパスワード変更要件が通知されることはありません。 これにより、Active Directory で保護されたリソースに対する認証が失敗する可能性があります。 この問題を軽減するには、次のいずれかのオプションを検討してください。
- ユーザー アカウントのパスワードの有効期限を無効にする
- パスワードの有効期限ポリシーの代わりに、PIN の有効期限ポリシーを採用することを検討してください
- パスワードの有効期限が組織の要件である場合は、パスワードを定期的に変更するか、認証エラー メッセージを受信するタイミングをユーザーに指示します。 ユーザーは次の方法でパスワードをリセットできます。
- Ctrl Alt + + Del パスワード>の変更オプションを使用する
- 自分のパスワードでサインインします。 パスワードを変更する必要がある場合、Windows はユーザーに更新を求めるメッセージを表示します
重要
ユーザーのパスワードを変更するには、デバイスがドメイン コントローラーと通信できる必要があります。
次のステップ
さまざまな組織のニーズと要件に対応するために、Windows Hello for Business にはさまざまな展開オプションが用意されています。 Windows Hello for Business の展開を計画する方法については、次を参照してください。