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 に同期されます。
証明書の登録フェーズ
このフェーズでは、証明書を使用した展開でのみ必要です。証明書は、organizationの公開キー インフラストラクチャ (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) で、デバイスは 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 コンテナーは、キー マテリアルまたはデータの論理グループです。 コンテナーは、organizationの IdP に登録されているデバイスでのみ、organizationの資格情報を保持します。
注
ディスク、レジストリ、またはその他の場所に物理コンテナーはありません。 コンテナーは、関連項目のグループ化に使用される論理ユニットです。 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 に応じて、対称キーまたは非対称キーを使用できます。 Work の証明書ベースのWindows Helloの場合、コンテナーのロックが解除されると、ユーザー ID キーまたはキー ペアへのアクセスを必要とするアプリケーションはアクセスを要求できます。 ユーザー ID キーは、このデバイスから IdP に送信される認証要求またはトークンの署名または暗号化に使用されます。 通常、ユーザー ID キーは有効期間が長くなりますが、認証キーよりも有効期間が短くなる可能性があります。 Microsoft アカウント、Active Directory アカウント、Microsoft Entra アカウントはすべて、非対称キー ペアを使用する必要があります。 デバイスは公開キーと秘密キーを生成し、公開キーを IdP に登録し (後で検証するために保存します)、秘密キーを安全に格納します。 organizatrons の場合、ユーザー ID キーは次の 2 つの方法で生成できます。
- ユーザー ID キーペアは、organizationの証明機関 (CA) に関連付けることができます。 このオプションにより、既存の PKI を保持する組織は、必要に応じてその PKI を使い続けられます。 VPN ソリューションなどの多くのアプリケーションでは証明書の使用が必要であるため、このモードでWindows Helloを展開すると、証明書ベースの機能を維持しながら、ユーザー パスワードからすばやく移行できるようになります。 このオプションを使用すると、organizationが保護されたコンテナーに他の証明書を格納することもできます。 たとえば、ユーザーが 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 ではなく指紋センサー モジュールで照合を完了する機能があります。 これらのセンサーは、データベース ファイルではなく指紋モジュールに生体認証データを格納します。 詳細については、「セキュリティ強化サインイン (ESS)Windows Hello」を参照してください。
キー同期
ハイブリッド環境ではキー同期が必要です。 ユーザーがWindows Hello for Business資格情報をプロビジョニングした後、キーはMicrosoft Entra IDから Active Directory に同期する必要があります。
ユーザーの公開キーは、Active Directory の msDS-KeyCredentialLink ユーザー オブジェクトの属性に書き込まれます。 同期は、接続同期Microsoft Entraによって処理されます。
証明書の登録
証明書のデプロイでは、キーを登録した後、クライアントによって証明書要求が生成されます。 要求は証明機関 (CRA) に送信されます。 CRA は、証明書要求を検証し、エンタープライズ PKI を使用してそれを満たす、Active Directory フェデレーション サービス (AD FS) (AD FS) サーバー上にあります。
証明書は、ユーザーの 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 キーは、多要素認証 (MFA) 要件Microsoft Entra満たし、リソースにアクセスするときにユーザーに表示される MFA プロンプトの数を減らします。
詳細については、「 プライマリ更新トークンとは」を参照してください。
Windows Hello for Businessとパスワードの変更
ユーザー アカウントのパスワードを変更しても、Windows Hello for Businessはキーまたは証明書を使用するため、サインインやロック解除には影響しません。
次のステップ
多数の組織のニーズと要件に対応するために、Windows Hello for Businessにはさまざまな展開オプションが用意されています。 Windows Hello for Businessデプロイを計画する方法については、以下を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示