Windows Hello for Business、ハードウェア キー、SSO

Microsoft環境でIDを管理している方は、おそらく聞いたことがあるでしょう。 Windows Hello、Windows Hello for Business、キー ハードウェア およびSSOしかし、数多くの略語、信頼の種類、そして要件の中で、混乱してしまうことはよくあります。さらに、従来のActive Directoryとのハイブリッド展開では、単純なPINや生体認証ログインと比較して、WHfBが真に何を提供するのかを理解することが、プロジェクトをスムーズに進めるか、それとも常に頭を悩ませ続けることになるかの分かれ道となる可能性があります。

この記事では、それがどのように機能するかを詳しく説明します。 Windows Hello for Business (WHfB) では、ハードウェア キーはどのような役割を果たし、シングル サインオン (SSO) はどのように実現されますか? そして、家庭向けWindows Helloとの違いについても解説します。内部フェーズ（デバイス登録、プロビジョニング、キー同期、証明書、認証）、展開モデル（クラウドのみ、ハイブリッド、オンプレミス）、信頼の種類、PKI要件、ライセンス、実際の展開における課題、そしてこれらすべてがFIDO2やパスワードレスセキュリティといった最新のアプローチとどのように連携するかについても解説します。

Windows HelloとWindows Hello for Business：何が本当に変わるのか

Windows Hello（シンプルに言えば）は、PINまたは生体認証でログインするためのユーザーエクスペリエンスです。 Windowsデバイス上で動作するWindows Hello for Business（WHfB）は、家庭環境と職場環境の両方を想定して設計されています。一方、Windows Hello for Business（WHfB）は、Active DirectoryとMicrosoft Entra IDと統合された強力なID機能を追加するエンタープライズ拡張機能です。

どちらの方法でも、 PIN、指紋、顔認証がサポートされています TPM コンピュータにログインするための認証です。従来のローカルドメインで認証することも可能です。WHfBの大きな違いは、 エンタープライズレベルの暗号化認証情報ユーザーとデバイスにリンクされ、ポリシーによって管理され、ローカルおよびクラウド リソースでの SSO に使用できるキー ペアまたは証明書。

「通常の」Windows Helloは基本的に そのデバイス上で便利なジェスチャーでパスワードを置き換えるWHfB は、ID プロバイダー (AD、Microsoft Entra ID、または AD FS) が認識、保存し、アクセス トークンを発行してセキュリティを適用するために使用する強力な資格情報を生成します。 条件付きアクセス、厳格な KDC 検証、PRT、クラウドでの Kerberos その他の高度なコントロール。

論理的な疑問は、もし既にドメインに参加しているデバイスがあり、Intuneで管理され、TPMと生体認証を備え、パスワードハッシュ同期を介してクラウドにSSOしている場合、 WHfB を追加すると具体的に何が得られますか? 答えは、キーがどのように構築され検証されるか、デバイスがどのようにリンクされるか、そしてそのセキュリティをローカル ログインだけでなくエコシステム全体に拡張できるかどうかにあります。

基本アーキテクチャ: Windows Hello for Business のフェーズ

WHfB は、複数のコンポーネントに依存する分散システムです。 デバイス、TPM、アイデンティティプロバイダ、PKI、ディレクトリ同期、SSOメカニズム迷わずに理解するためには、その操作を実装の 5 つの時系列フェーズに分けると役立ちます。

1. デバイス登録

パズルの最初のピースは アイデンティティプロバイダ（IdP）へのデバイス登録この手順により、デバイスをディレクトリ内の ID に関連付け、ユーザーがログインしたときに自動的に認証できるようになります。

クラウドのみまたはハイブリッド環境では、 IdPはMicrosoftです。IDを入力してください。 デバイスはデバイス登録サービスに登録されます（Microsoft Entraに参加、ハイブリッド参加、または登録済み）。純粋にローカルなシナリオでは、IdPは通常 AD FS とエンタープライズデバイス登録サービス.

この登録が完了すると、IdPはチームを割り当てます デバイスとディレクトリの信頼を確立するために使用される一意のID 連続認証において。この記録は「デバイス参加タイプ」によって分類され、デバイスがローカルドメイン、Entra ID、ハイブリッド、あるいは単に個人として登録されているかを判断します。

2. プロビジョニング: Windows Hello コンテナの作成

デバイスが登録されると、フェーズが始まります 企業向け Windows Hello 認証情報のプロビジョニングここで、いわゆる Windows Hello コンテナーが作成され、そのコンピューター上のユーザーのすべての暗号化マテリアルが論理的にグループ化されます。

典型的な調達フローは、以下の主要なステップを踏んでおり、常に 初期認証 弱い認証情報（ユーザー名とパスワード）の場合:

• ユーザーはIdPでMFAを使用して認証します (Microsoft Enter MFA または他の互換性のある方法、あるいはローカル環境の AD FS の MFA アダプター)。
• 2つ目の要素を克服した後、 PINと、互換性のあるハードウェアが利用可能な場合は生体認証ジェスチャー （足跡、顔、虹彩）。
• PINを確認すると、Windowsは Windows Hello コンテナ そのチームのそのアカウントに対して。
• そのコンテナ内には、 暗号鍵ペア（公開鍵と秘密鍵）TPM が存在する場合は TPM にリンクされ、それがない場合はソフトウェアによって保護されます。
• La 秘密鍵はデバイス上に残り、エクスポートすることはできませんTPM と PIN/生体認証プロテクターによって保護されたままになります。
• La 公開鍵はIdPに登録されている これはユーザー オブジェクトにリンクされています。Microsoft ログイン ID ではユーザーに書き込まれ、フェデレーション ローカル シナリオでは AD FS によって Active Directory に転送されます。

コンテナには、 管理キーこれはPINのリセットなどのシナリオに役立ちます。TPM搭載デバイスでは、TPM証明書を含むデータブロックも保存されます。すべてのデータは、ユーザーがジェスチャー（PINまたは生体認証）を実行した場合にのみロック解除され、この最初のMFAの組み合わせによって、ユーザー、デバイス、IdP間の信頼が確立されます。

3. コンテナ内のキー: 認証とユーザー識別子

Windows Helloコンテナ内には、異なる役割を持ついくつかの種類のキーがあり、 PINベースまたは生体認証による暗号化:

• 認証キー登録時に生成される非対称鍵のペア。PINまたは生体認証ジェスチャーで常にロック解除する必要があります。PINが変更された場合、他の素材がリサイクルされる際の基盤となります。
• ユーザー識別子キーIDキーは、IDプロバイダー（IdP）とモデル（キーまたは証明書）に応じて、対称または非対称になります。IDキーは、IDプロバイダーへのリクエストやトークンの署名または暗号化に使用されます。エンタープライズ環境では、通常、IDキーは非対称キーペアとして生成され、公開鍵はIdPに登録されます。

これらのユーザー識別子キーは、主に次の 2 つの方法で取得できます。 企業PKIと連携して証明書を発行する （例えば、 VPN、RDP または証明書ベースの Kerberos 認証）を使用するか、PKI を使用しないシナリオで IdP によって直接生成されます（純粋キー モデル）。

同じインフラで、 FIDO2/WebAuthn 認証システムとしての Windows Hello 互換性のあるアプリケーションやウェブサイトで使用できます。サイトはWindows Helloコンテナ内にFIDO認証情報を作成できます。その後のアクセスでは、ユーザーはパスワードを入力せずにPINまたは生体認証で認証できます。

4. ハイブリッド環境でのキー同期

共存するハイブリッドアーキテクチャでは Microsoft ログイン ID と Active Directoryクラウドにキーを登録するだけでは不十分です。プロビジョニング後、WHfBの公開キーをローカルディレクトリに同期して有効にする必要があります。 オンプレミスのリソースに対する認証とSSO.

このようなシナリオでは、Microsoft Entra Connect Syncが対応します。 公開鍵をmsDS-KeyCredentialLink属性にコピーします。 Active Directory内のユーザーオブジェクトの同期は、ドメインコントローラーがTPMに保存されている秘密鍵を使用してデバイスによって生成された署名を検証するために重要です。

5. 証明書の登録（必要な場合のみ）

一部のモデル（ 証明書の信頼組織は、鍵に加えて、ユーザーに認証証明書を発行する必要があります。その場合、追加のフェーズが開始されます。 証明書の登録.

公開鍵を登録した後、クライアントは 証明書要求 証明書レジストリ機関（CRA）にリクエストを送信します。CRAは通常、フェデレーション展開でAD FSに統合されています。CRAは企業PKIを使用してリクエストを検証し、 Helloコンテナ内に保存される証明書を発行します、まだ証明書に依存しているローカル リソースの認証に再利用できます。

認証、秘密鍵、SSO：これらがどのように組み合わさるのか

登録とプロビジョニングのフェーズが完了すると、ユーザーの日常生活は非常にシンプルになります。 デバイス上の秘密鍵を「解放」するジェスチャー（PINまたは生体認証）興味深いのは、舞台裏で何が起きているかです。

ユーザーがコンピュータのロックを解除すると、WindowsはWHfB認証情報の秘密部分を使用して IdP に送信されるデータを暗号的に署名するこのプロセスは、ユーザーオブジェクトに保存されている公開鍵を用いて署名を検証します。PINと秘密鍵はデバイスから外部に漏洩することがないため、フィッシングや従来の認証情報の盗難に対する耐性を備えています。

Microsoft Enter IDシナリオでは、認証を完了すると、 プライマリリフレッシュトークン（PRT）ユーザーとデバイスの情報を含むJSONウェブトークン。クラウドアプリケーションへのSSOの基盤となり、Microsoft Kerberosまたはキー同期と組み合わせることで、ローカルリソースへのSSOも実現します。

PRTがなければ、ユーザーが有効なWHfB認証情報を持っていても、 シングルサインオンが使えなくなります。 各アプリで継続的に認証が必要になります。そのため、デバイスベースであれリスクベースであれ、条件付きアクセスポリシーでは通常、PRTの存在と有効性が考慮されます。

Active Directoryの場合、キーまたは証明書の信頼を使用する場合、WHfBは 仮想スマートカードユーザーは KDC からの nonce またはチャレンジに署名し、ドメイン コントローラは証明書またはキーを検証して Kerberos TGT チケットを発行し、Kerberos と統合されたローカル サービスへの SSO を有効にします。

内部セキュリティ：生体認証、TPM、攻撃からの保護

WHfBの柱の一つは、 生体認証データはデバイスから外に出ることはありませんセンサーによって生成されたテンプレートは、ローカルに保存されます。 データベース データベースごとに一意のキーを使用して暗号化され (たとえば、パス C:\WINDOWS\System32\WinBioDatabase)、CBC モードの AES とハッシュ関数として SHA-256 で保護されます。

つまり、たとえ攻撃者がそれらのファイルにアクセスできたとしても、 ユーザーの顔や指紋の画像を再構築できませんでした。また、他のデバイスで使用することもできません。さらに、各センサーは独自のストレージを保持しているため、生体認証テンプレートが一箇所に集約されて盗難される可能性も低減されます。

Windows Hello for Business の PIN は、従来のパスワードよりも強力に保護されています。ネットワークを経由せず、ローカルで検証され、TPM によってセキュリティ対策が強化されます。 間違った試行が多すぎるためブロックされるこれにより、ブルートフォース攻撃や辞書攻撃は無効になります。また、PINが盗まれたとしても、認証情報はハードウェアに紐付けられているため、その特定のデバイスでのみ有効となります。

現代の脅威に直面する（メールがフィッシングかどうかを見分ける方法（パスワードの再利用、大量の認証情報の盗難）WHfBは デバイスにリンクされた公開鍵暗号これにより、共有秘密の漏洩を設計上回避できます。これは、NIST 800-63Bなどの規制の標準および推奨事項、そしてゼロトラスト・セキュリティ・モデルに完全に適合しています。

導入モデル: クラウド、ハイブリッド、オンプレミス

WHfBはトポロジーの面で柔軟性がありますが、その柔軟性は一定の複雑さを伴います。大まかに言えば、異なる方法で組み合わせる3つのデプロイメントモデルがあります。 Microsoft Entra ID、Active Directory、PKI、フェデレーション.

クラウドのみのモデル

ほぼ100％が Microsoft 365 関連するローカルインフラストラクチャがない場合、最も単純なモデルは Microsoftに接続されたデバイスのみのクラウド。サインインこのシナリオでは、

• すべてのユーザーとデバイスは Microsoft エントラ ID.
• デバイスとキーの登録はクラウドで直接行われます。
• エンタープライズPKIは不要 ドメイン コントローラ証明書も使用できません。
• SSO は、アプリケーションの PRT および Microsoft Entra トークンに基づいています。

これはクラウドファースト企業にとって最も直接的な選択肢であり、 インフラコストが低く、導入が比較的簡単オンプレミスのリソースが利用できない、または最小限である場合に最適です。

ハイブリッドモデル：最も一般的なケース

大多数の企業は、その中間に位置します。 過去の Active Directory と Microsoft ログイン ID の同期WHfB はここで活躍しますが、適切に計画されていない場合は構成の問題が最も多く発生する場所でもあります。

ハイブリッド環境では、アイデンティティはMicrosoft Entra Connect Syncと同期され、 展開モデル（ハイブリッド）と信頼の種類（クラウド Kerberos、キー、または証明書）目標は通常、次のものを提供することです。

• クラウドサービスへのSSO (SharePointの オンライン、Teams、OIDC/SAML アプリケーション)。
• ローカルリソースへの透過的なアクセス （株、 apps Kerberos、VPN、RDP)。
• レガシー アプリケーションを維持しながら、パスワードを段階的に廃止するルートです。

ハイブリッド シナリオにおける信頼の主なタイプは次のとおりです。

• クラウド上のKerberosMicrosoft Entra Kerberosは、追加の公開鍵基盤（PKI）を必要とせずに、Active Directory用のTGTを発行します。これは、既存のFIDO2基盤を活用し、Active Directoryとの公開鍵の同期を必要としないため、最も最新かつシンプルなハイブリッドモデルです。
• キートラストユーザーはデバイスにバインドされたキーを使用して Active Directory に認証します。ドメイン コントローラーには特定の証明書が必要です。ドメイン コントローラーには PKI が必要ですが、ユーザー証明書には必要ありません。
• 証明書の信頼性ユーザー認証証明書が発行され、Kerberos TGT を取得するために使用されます。これには、完全な PKI、CRA としての AD FS、そしてより高度な構成が必要です。

適切なタイプの信頼を選択することが重要です。 どれも本質的に「安全」ではないただし、コスト、複雑さ、インフラストラクチャ要件はそれぞれ異なります。クライアントとサーバーのWindowsバージョンが最小要件を満たしている場合、クラウドでKerberosを利用することが、新規導入における最適な選択肢となることがよくあります。

純粋なローカルモデル

規制上の制約が厳しい組織や、クラウドを導入していないかほとんど導入していない組織では、WHfB の導入を選択できます。 100% ローカル、Active Directory と AD FS でサポートこのモデルでは、

• デバイス登録は管理されます AD FS.
• 認証はキーベースまたは証明書ベースで行うことができますが、常に エンタープライズPKI.
• MFA オプションには、AD FS 用のアダプターや、オンプレミスに統合された Azure MFA Server (既にレガシ) などのソリューションが含まれます。

このアプローチは、 認証データの完全な制御ただし、これには相当のメンテナンス作業 (PKI、AD FS、ドメインに参加していないコンピューターからアクセス可能な CRL の公開など) が必要であり、すべての組織が長期的にそれを引き受けたいと思うわけではありません。

アクセス可能な PKI、ドメイン コントローラ証明書、CRL

証明書（ユーザー、ドメインコントローラ、またはその両方）に依存するモデルでは、PKIが信頼の中心となります。WHfBでは、 KDCの厳格な検証 Microsoft Enter に参加しているデバイスがローカル ドメインに対して認証する場合。

実際には、ドメイン コントローラー証明書は次のようないくつかの技術的条件を満たす必要があります。 Kerberos認証テンプレートに基づいてデバイスの信頼できるルートCAによって発行され、「KDC認証」EKU、正しいDNS名、署名アルゴリズムとしてRSA 2048およびSHA-256が使用されますその他の要件の中でも。

さらに、デバイスが 証明書の失効を確認するここにCRLの典型的な問題があります。Microsoft Entraにのみ参加しているデバイスは、まだ認証されていない場合はActive DirectoryのLDAPパスを読み取ることができないため、CRL配布ポイントを公開する必要があります。 認証なしでアクセス可能なHTTP URL.

これには、Web サーバー (IIS など) の準備、仮想ディレクトリ (cdp) の作成、および権限の調整が含まれます。 NTFS 共有リソースから、 ストレージ オフラインキャッシュでは、CAが共有リソース上のCRLを公開し、HTTP経由で公開するように設定します。完了したら、 ドメインコントローラ証明書を更新する 新しい CDP を含め、エンタープライズ ルート証明書が Microsoft Entra に参加しているデバイス (Intune と「信頼された証明書」プロファイルを使用) に展開されるようにします。

ディレクトリ同期、MFA、デバイス構成

Windows Hello for Businessのエンドユーザーエクスペリエンスは、主に以下の要素によって決まります。 ディレクトリ同期、MFA、ポリシー構成がどのように統合されるか.

ハイブリッド展開では、Microsoft Entra Connect Syncはアカウントを同期するだけでなく、 msDS-KeyCredentialLinkのような重要な属性AD での認証に必要な WHfB 公開鍵が含まれています。Azure MFA サーバーを備えたオンプレミス環境では、同期を使用してユーザーを MFA サーバーにインポートし、その後、クラウド サービスに照会して検証を行います。

多要素認証に関しては、組織にはいくつかのオプションがあります。 クラウドまたはハイブリッド シナリオ向けの Microsoft Entra MFAEntra ID の外部認証またはフェデレーションを介して統合された外部メソッド、およびオンプレミス環境の AD FS 用のサードパーティ製 MFA アダプター。フェデレーションドメインの FederatedIdpMfaBehavior フラグは、Entra ID がフェデレーション IdP によって実行される MFA を受け入れるか、要求するか、または無視するかを決定します。これは、WHfB プロビジョニングが正しく機能するために非常に重要です。

機器のWHfB設定は次のように行うことができます。 グループポリシー（GPO）またはMDM経由のCSP （例：Intune）。現代の組織では、自動 WHfB 登録の有効化、初回ログイン時の MFA の強制、PIN の複雑さに関するポリシーの定義、受け入れる生体認証方法の制御（認定センサー、赤外線カメラのみなど）などが一般的です。

並行して、回復体験を考慮することが重要です。 セルフサービスPINリセット、FIDO2キーなどの代替方法、および BitLocker暗号化 デバイスの紛失や盗難の際に保存データを保護します。

ライセンス、システム要件、および実際の制限

よくある誤解の一つは、常にWHfBを使う必要があるということだ Microsoft ID P1またはP2を入力してください実際には、WHfB のコア機能は無料の Entra ID レベルで利用可能であり、パスワードレス プロビジョニングに必要な多要素認証もプレミアム ライセンスなしで有効にできます。ただし、自動 MDM 登録、高度な条件付きアクセス、遅延デバイス ライトスルーなどの機能には、より上位のレベルが必要です。

オペレーティングシステムに関しては、Windowsのほぼすべての最新クライアントバージョンがWHfBをサポートしていますが、 クラウドにおけるKerberosの信頼には具体的な最低限の要件が必要 （例えば、特定のパッチまたは特定のバージョンのWindows 10 21H2など） Windows 11サーバー側では、サポートされているバージョンの Windows Server は通常 DC として機能できますが、クラウド内の Kerberos 部分ではドメイン コントローラーの特定のバージョンと更新プログラムが必要です。

技術的な側面以外にも、非常に現実的な課題があります。共有機器では、 WHfBはデバイスとユーザーに特化したもので、定期的に適合するTPM 2.0 または生体認証センサーのないハードウェア、または古いフリートの更新、PKI の導入、2012 DC のアップグレードにかかるコストにより、WHfB を短期的に完全に導入することが魅力的でない環境。

場合によっては、合理的な道筋としては WHfBを他のパスワードレス要素と組み合わせる （FIDO2キー、スマートカード、電話認証）を使用して共有ワークステーション、非Windowsプラットフォーム、またはモバイル性の高いユーザーをカバーし、WHfBを主要な認証システムとして残します。 ラップトップ Entra またはハイブリッドにリンクされている企業。

全体像を見ると、Windows Hello for Businessは「便利なPIN」以上のものを提供します。 ハードウェアにバインドされた非対称認証情報、厳格な KDC 検証、Microsoft Entra ID および Active Directory との緊密な統合、および安全な SSO のための堅牢なフレームワーク クラウドでもオンプレミスでも利用可能です。ただし、基本的なWindows Helloと比較した際の真の価値は、出発点によって異なります。最新のPKIとDCを備えたクラウドファースト環境やハイブリッド環境では、セキュリティと管理の飛躍的な向上が労力を明らかに上回ります。一方、インフラストラクチャの準備がほとんど整っておらず、近代化計画もない非常に古いドメインでは、WHfBの可能性を最大限に活用する前に、まずハードウェア、PKI、アクセス制御を進化させる方が理にかなっているかもしれません。