- Windows Hello for Business では、ジェスチャーと信頼シグナルを組み合わせて 2 つの要素を要求することができます。
- Bluetooth、IP、Wi-Fi のベンダー リスト (GUID) と XML ルールを構成します。
- Intune またはポリシー経由で展開され、登録時に MFA が必要になります。
- HelloForBusiness イベントは監査とインシデント解決を促進します。
Windows Helloによる多要素認証 ユーザーエクスペリエンスを損なうことなく、Windowsのログインセキュリティを新たなレベルに引き上げることができます。PINや生体認証だけに頼るのではなく、複数の要素と信頼シグナルの組み合わせでデバイスのロックを解除することを要求し、社内規制や業界規制にも準拠できます。
Microsoft サインイン ID (旧 Azure AD) または Microsoft 365Windows Hello for Business で多要素ロック解除(MFA)を有効にすると、覗き見や認証情報の共有を防ぐ確実な方法となります。さらに、ジェスチャー(PIN、顔、指紋)はデバイスに紐付けられ、デバイス外に漏れることがないため、フィッシング対策が強化され、シングルサインオンも向上します。 apps そしてブラウザ。
Windows Hello for Business による多要素ロック解除は、具体的に何を解決するのでしょうか?
Windows Hello for Businessは、単一の認証情報(PINまたは生体認証)でロックを解除できます。 デバイスにアクセスできないようにする機能です。これは便利ですが、誰かが誤ってPIN番号を解読した場合、アクセスを試みる可能性があります。多要素ロック解除を有効にすると、デスクトップへのアクセスを許可する前に、少なくとも1つのジェスチャー(例:指紋)と信頼できる信号(例:企業ネットワークまたはBluetooth近接通信)を組み合わせる必要があります。
目的は、単一の要素では不十分なシナリオをカバーすることです。PIN だけでは十分ではないと考えている組織、資格情報の共有を防止したいデバイス、2 要素認証が必要な環境、そして非常に重要な点として、サードパーティのカスタム ソリューションに頼らずにネイティブの Windows ログイン エクスペリエンスを維持したいと考えている組織。
HelloのMFAを使用すると、コンテキストポリシーを表現できます (例えば、デバイスが社内Wi-Fiに接続されている、または近くでペアリングされたスマートフォンが検出された場合など)。これにより、ユーザーがポリシーで定義された有効な2要素を入力しない限り、オフィス外からのログインが防止されます。
さらに、Windows Hello は日常生活で実用的なメリットをもたらします。: ジェスチャーはデバイスにバインドされており、フィッシングに耐性があり、一度入力するとブラウザとのSSOを容易にし、 VPN 組織の摩擦とサポートへのチケットを削減します。
アーキテクチャとフロー: 第 1 および第 2 の認証情報プロバイダー
多要素ロック解除は2つのカテゴリーのプロバイダーによってサポートされています: 最初のロック解除資格情報プロバイダーと2番目のロック解除要素プロバイダー。各プロバイダーは一意のGUIDで識別され、Windowsではユーザーがログインを完了するために、各カテゴリの少なくとも1つのプロバイダーの要件を満たす必要があります。
政治は3つの部分から成り立っている1) 最初の要素のプロバイダーのリスト、2) 3 番目の要素のプロバイダーのリスト、および XNUMX) 環境が期待どおりであるかどうかを判断するために XNUMX 番目の要素の一部として評価される信頼シグナル ルール (含まれている場合)。
実際には、ユーザーは最初の要素としてジェスチャーを提示します (例:指紋)と、2つ目の要素(例:企業ネットワークトークン、または許可されている場合はPIN自体)の認証が必要です。Windowsは、両方の認証条件が満たされた場合にのみデスクトップのロックを解除します。
重要なニュアンスに注意してください: 同じプロバイダーが両方のリストに存在することは可能ですが、特定の資格情報は、同じロック解除中に 1 つの要素のみをカバーできます。つまり、各要素はログイン試行ごとに 1 回のみ使用できます。
サポートされているプロバイダーと GUID: PIN、生体認証、信頼トークン
Windows Hello for Businessは複数の認証情報プロバイダーを認識しますそれぞれGUIDで表されます。サポートされているものとその識別子は次のとおりです。
| 資格情報プロバイダー | GUID |
|---|---|
| PIN | {D6886603-9D2F-4EB2-B667-1971041FA96B} |
| 指紋 | {BEC09223-B018-416D-A0AC-523971B639F5} |
| 顔認識 | {8AF662BF-65A0-4D0A-A540-A338A999D36F} |
| 信頼信号(Bluetooth 近接、ネットワークなど) | {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD} |
- カテゴリ別のデフォルト値最初の要素リストには、デフォルトでPIN、指紋、顔が含まれます。2番目の要素リストには、デフォルトでトラストトークンとPINが含まれます。これにより、「指紋 + 企業ネットワーク」や「顔 + PIN」といった、ごく一般的なシナリオに対応できます。
- GUIDのコンマ区切りリスト: 有効にしたいGUIDを両方のリストに設定できます。順序は必須ではありません。プロバイダーが両方のリストに表示されていても、その使用はロック解除の試行ごとに1回だけカウントされます。
- 関連する制限: 信頼できるシグナル プロバイダーは、2 番目の要素の一部としてのみ宣言できます。最初のロック解除要素として含めることは無効です。
信頼できる信号ルール: Bluetooth、IPConfig、Wi-Fi
信頼シグナルはXMLルールを使用して定義されます シグナルプロバイダーは、デバイスが目的のコンテキストを満たしているかどうかを判断します。各ルールは要素で囲まれています。 rule 属性付き schemaVersion (現在のバージョンは 1.0).
ルールの基本構造 (最小):
<rule schemaVersion=\"1.0\">
</rule>
各ルールには少なくとも1つの要素がある signal とともに type と value またはタイプに応じてサブ要素。サポートされているタイプは以下のとおりです。 bluetooth, ipConfig y wifi.
Bluetooth: 要素自体の属性で定義されます signalネストされた要素は必要なく、短い終了タグを使用できます。
| 属性 | 勇気 | 必須 |
|---|---|---|
| type | bluetooth |
はい |
| シナリオ | Authentication |
はい |
| デバイスクラス | 番号(例:電話の場合は512) | いいえ |
| rssi最小値 | 数値(例:-10) | いいえ |
| rssiMaxDelta | 数値(例:-10) | いいえ |
Bluetooth信号の例 ペアリングされた携帯電話に近接している場合:
<rule schemaVersion=\"1.0\">
<signal type=\"bluetooth\" scenario=\"Authentication\" classOfDevice=\"512\" rssiMin=\"-10\" rssiMaxDelta=\"-10\"/>
</rule>
デバイスクラス デフォルト値は Telephone で、次のクラス テーブルに基づいています。
| 説明 | 勇気 |
|---|---|
| いくつかの | 0 |
| パソコン | 256 |
| 電話 | 512 |
| LAN/ネットワーク アクセス ポイント | 768 |
| オーディオ/ビデオ | 1024 |
| ペリフェリコス | 1280 |
| 画像 | 1536 |
| ウェアラブル型 | 1792 |
| おもちゃ | 2048 |
| 健康状態/ステータス | 2304 |
| 分類されていない | 7936 |
rssiMinとrssiMaxDelta デバイスが「十分に近い」かどうかを判断するのに役立ちます。 -10 機器を邪魔することなくオフィス内を移動でき、 rssiMaxDelta=-10 信号が 10 度以上弱くなったときにブロックするように Windows に指示します。
RSSIスケールを覚えておいてください: 相対的な値であり、信号強度が低下すると減少します。0は-10より強く、-10は-60より強く、デバイスが遠ざかっていることを示します。
IPConfig: 1つ以上のサブ要素で定義され、各サブ要素は文字列値を持ちます。ポートとプレフィックスは使用できず、CIDR表記が適用される場合はCIDR表記が使用されることが多いです。
<ipv4Prefix>192.168.100.0/24</ipv4Prefix>
<ipv4Gateway>192.168.100.10</ipv4Gateway>
<ipv4DhcpServer>192.168.100.10</ipv4DhcpServer>
<ipv4DnsServer>192.168.100.10</ipv4DnsServer>
<ipv6Prefix>21DA:D3::/48</ipv6Prefix>
<ipv6Gateway>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6Gateway>
<ipv6DhcpServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DhcpServer>
<ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>
<dnsSuffix>corp.contoso.com</dnsSuffix>
Wi-Fi: は次のようなサブ要素で宣言されます SSID (必須)、BSSID (オプション)、セキュリティ タイプ、信頼されたルート証明書、および最小信号品質。
| フィールド | 説明 |
|---|---|
ssid |
ワイヤレスネットワーク名(必須) |
bssid |
住所(リンク先) マック アクセスポイントから(オプション) |
security |
オープン、WEP、WPA パーソナル、WPA エンタープライズ、WPA2 パーソナル、WPA2 エンタープライズのいずれか |
trustedRootCA |
ルート証明書のフィンガープリント(スペース区切りの16進数) |
sig_quality |
必要な信号品質(0~100) |
エンタープライズセキュリティを備えた Wi-Fi の例:
<rule schemaVersion=\"1.0\">
<signal type=\"wifi\">
<ssid>contoso</ssid>
<bssid>12-ab-34-ff-e5-46</bssid>
<security>WPA2-Enterprise</security>
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
<sig_quality>80</sig_quality>
</signal>
</rule>
ルールの組み合わせと例: 単純なルールを定義したり、OR (個別) または AND (複合要素) タイプのロジックを使用して複数のルールを作成したりできます。
<!-- Ejemplo 1: IPConfig con prefijo y DNS -->
<rule schemaVersion=\"1.0\">
<signal type=\"ipConfig\">
<ipv4Prefix>10.10.10.0/24</ipv4Prefix>
<ipv4DnsServer>10.10.0.1</ipv4DnsServer>
<ipv4DnsServer>10.10.0.2</ipv4DnsServer>
<dnsSuffix>corp.contoso.com</dnsSuffix>
</signal>
</rule>
<!-- Ejemplo 2: OR entre IPConfig y Bluetooth para teléfonos -->
<rule schemaVersion=\"1.0\">
<signal type=\"ipConfig\">
<dnsSuffix>corp.contoso.com</dnsSuffix>
</signal>\n</rule>
<rule schemaVersion=\"1.0\">
<signal type=\"bluetooth\" scenario=\"Authentication\" classOfDevice=\"512\" rssiMin=\"-10\" rssiMaxDelta=\"-10\"/>
</rule>
<!-- Ejemplo 3: AND entre IPConfig y Bluetooth -->
<rule schemaVersion=\"1.0\">
<and>
<signal type=\"ipConfig\">
<dnsSuffix>corp.microsoft.com</dnsSuffix>
</signal>
<signal type=\"bluetooth\" scenario=\"Authentication\" classOfDevice=\"512\" rssiMin=\"-10\" rssiMaxDelta=\"-10\"/>
</and>
</rule>
<!-- Ejemplo 4: Wi‑Fi como señal de confianza -->
<rule schemaVersion=\"1.0\">
<signal type=\"wifi\">
<ssid>contoso</ssid>
<bssid>12-ab-34-ff-e5-46</bssid>
<security>WPA2-Enterprise</security>
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
<sig_quality>80</sig_quality>
</signal>
</rule>
展開方法: Intune/CSP、グループポリシー、登録エクスペリエンス
- 多要素ロック解除を設定するには 主なアプローチは2つあります。Microsoft Intune (CSP) 経由の構成プロファイルとグループポリシーです。デバイス管理のニーズに最適な方法を選択し、第一要素と第二要素の GUID リストとシグナルルールを適用してください。
- 重要: Windows Hello のプロビジョニングには MFA が必要です 登録時に、PIN を作成して生体認証を記録する前に、ユーザーがこの手順を完了するためのアクティブな方法 (認証アプリ、SMS、または FIDO2 キー) を持っていることを確認してください。
- パスワードでログインした後の一般的な登録フロー:彼なら ハードウェア サポートされている場合は、生体認証ジェスチャ(顔認証または指紋認証)の設定を求めるメッセージが表示されます。ウィザードでは、組織のアカウントでWindows Helloを使用するように求められ、MFAチャレンジが有効化されます。検証が完了すると、PINが作成され、複雑さのポリシーに従って確認されます。
- OOBE(オーバー・ザ・トップ・エクスペリエンス)シナリオ: ユーザーはデバイスを Microsoft Enter ID に参加させ、参加中に MFA の入力を求められます。Intune によって Hello for Business ポリシーが適用され、デスクトップに入る前に Hello の登録が完了します。
- 登録すると、ユーザーはジェスチャーを使って Hello for Business を必要とするデバイスやリソースにアクセスするには、PIN、顔、または指紋のいずれかの認証が必要です。これらのジェスチャーは登録されたデバイスでのみ機能するため、ローカルセキュリティが強化されます。
Windows Hello と Web サービスでの 2FA 設定 (WebAuthn)
SMS、モバイルアプリ、セキュリティキーによる2FAをすでにお持ちの場合追加のログイン方法としてWindows Helloデバイスを追加できます。サポートされているログインでは、物理的なパスコードやキーの代わりに、指紋センサーまたは顔認証を使用できます。
セットアップは簡単基本方式で2FAを有効にした後、セキュリティプロファイルに移動し、「Windows Helloを使用する」方式を追加してください。このオプションは、WebAuthnをサポートするブラウザでのみ表示されます。セットアップ中に、後で区別できるようにデバイスに名前を付けてください。
次回ログイン時に「Hello」を選択できるようになります 2要素認証として。ご希望の場合は、オプトアウトしてSMS、認証アプリ、またはハードウェアキーを使用することもできます。ポリシーで許可されている限り、柔軟性は常に維持されます。
技術ノート: Windows Hello は WebAuthn 標準を使用して統合されているため、互換性のあるポータルやアプリケーションで正しく動作するには最新のブラウザーが必要です。
大学や企業環境において また、Hello で起動すると、ユーザーはメイン ブラウザーと VPN で自動的に認証されるため、内部サービスで 2 番目の要素を繰り返し入力する必要性が軽減されることも注目に値します。
円を閉じるためにHello for Business を、明確に定義された信頼シグナル、登録時の MFA の要求、イベントの監視と組み合わせることで、セキュリティと利便性の優れたバランスが実現されるとともに、規制要件に準拠し、ユーザーが抵抗なく受け入れるネイティブの Windows 起動エクスペリエンスも提供されます。
バイトの世界とテクノロジー全般についての情熱的なライター。私は執筆を通じて自分の知識を共有するのが大好きです。このブログでは、ガジェット、ソフトウェア、ハードウェア、技術トレンドなどについて最も興味深いことをすべて紹介します。私の目標は、シンプルで楽しい方法でデジタル世界をナビゲートできるよう支援することです。