passkeys-fido2

Microsoft Entra ID のパスキーと FIDO2

パスキーと FIDO2 セキュリティキーは、真にフィッシング耐性を備えた Entra ID の認証方法で唯一のものです。このスキルでは、実践的な展開方法を取り上げます。ユーザー層に適したパスキーの種類を選び、一時アクセスパスを使って登録を開始し、条件付きアクセスの認証強度で適用した後、従来の方法を廃止します。

使用する場面

Entra テナントをパスワード＋SMS／アプリのプッシュ通知から、パスワードレスでフィッシング耐性のある認証へ移行するときに使用します。認証方法の選定、登録キャンペーン、条件付きアクセスによる適用、従来の認証方法の廃止計画に利用します。

このスキルは使用しないでください。一般的な条件付きアクセスのポリシー作成（conditional-access-mfa）、Windows Hello for Business のデスクトップ設計全般（windows-hello）、または Verified ID の資格情報発行（entra-verified-id）には使用しません。

パスキーの種類 — ユーザー層ごとに選択

種類	保存場所	最適な対象
Microsoft Authenticator のデバイスバインド型パスキー	iOS／Android アプリ、ハードウェアに紐付け、同期されない	BYOD の割合が高い従業員、現場作業者
同期型パスキー（Apple iCloud Keychain、Google、1Password 経由の Windows Hello など）	OS のキーチェーン、ユーザーのデバイス間で同期	iOS／macOS／Windows が管理されているナレッジワーカー
ハードウェア FIDO2 セキュリティキー（YubiKey、Feitian など）	取り外し可能、アテステーション対応	特権管理者、共有ワークステーションのユーザー、規制対象の職務
Windows Hello for Business	デバイスごと、TPM に紐付け	Windows ワークステーションの主なサインイン方法（windows-hello を参照）

目安： 標準的なユーザー層には、Authenticator のデバイスバインド型パスキーを使用します。管理者と Tier 0 にはハードウェアキーを使用します。MDM／ポリシーで許可される Mac／iPhone ユーザーには、OS のキーチェーンによる同期型パスキーを使用します。

アプローチ

1. 認証方法を有効にします。 Entra → Authentication methods で、次の方法を有効にします。

   • Passkey (FIDO2)。アテステーションの適用を明示的に決定します（詳細は以下を参照）。
   • パスキー機能を含む Microsoft Authenticator。
   • Temporary Access Pass。 まずパイロットグループを対象に展開します。

2. アテステーションポリシー。 FIDO2 登録にアテステーションを必須にするかどうかを決定します。

   • Enforce attestation = Yes：許可リストに登録した AAGUID（認証器モデル）のみ登録できます。強力な制御が可能ですが、新しいデバイスモデルを許可リストに追加する必要があるため、運用負荷が高くなります。
   • Enforce attestation = No：あらゆる FIDO2 認証器（プラットフォームプロバイダーが同期するパスキーを含む）を登録できます。手間は少なくなりますが、制御性も低下します。 特権を持つユーザーには、適用を有効にしてハードウェアキーを許可リストに登録します。従業員には制限を緩和します。

3. Temporary Access Pass による初期登録。 すべてのユーザーが、パスワードを使わずに最初のパスキーを登録できる方法を用意する必要があります。TAP は、期限付きで一度限り（または利用回数を制限した）使用できるコードです。

   • 新入社員：人事／オンボーディングのフローで TAP を発行します。
   • 登録キャンペーンの対象となる既存ユーザー：本人確認後にヘルプデスクが TAP を発行します。
   • デバイス紛失時の復旧：本人確認の後に TAP を再発行します（Verified ID の利用を検討してください）。

4. 登録キャンペーン。 組み込みの registration campaign を使い、サインイン時に Authenticator パスキーを設定するようユーザーに促します。60～90 日間実施し、導入状況を測定します。周知施策として、メール 3 通と Teams バナーを組み合わせます。

5. Conditional Access — authentication strength。 次の対象に Phishing-resistant MFA の authentication strength を要求する CA ポリシーを作成します。

   • すべての管理者ロール（Global Admin、Privileged Role Admin など）。
   • 特権アプリケーション（Azure portal、Entra admin center、Exchange admin、GitHub Enterprise のサインイン）。
   • 影響の大きいデータアプリ（SAP、人事、財務）。 影響範囲を限定するため、テナント全体ではなく、アプリごとに展開します。

6. 脆弱な方法を廃止します。

   • SMS と音声通話 — Authentication methods policy で MFA 方法として無効にします。必要な場合に限り、SSPR では引き続き利用できます。
   • 数値照合なしの Authenticator プッシュ通知 — 数値照合は現在デフォルトで有効です。適用されていることを確認します。
   • 従来の MFA 登録ページ — 統合登録に移行します（かなり前からデフォルトです）。 手順：まず「セカンダリ」に設定し、この方法に依存しているユーザーがいないかサインインログを監視してから、無効にします。

7. ライフサイクル。

   • デバイス紛失時：ユーザーの認証方法から登録済みの認証器を取り消し、新しい TAP を発行します。ユーザーは再登録します。
   • 異動時：パスキーはユーザー ID に紐付いているため、そのまま保持されます。CA strength は次回のサインイン時に再評価されます。
   • 退職時：通常のオフボーディングで ID を取り消すと、パスキーは使えなくなります。

8. レポート。 Entra → Monitoring → Authentication methods activity で、次の項目を追跡します。

   • フィッシング耐性のある方法を 1 つ以上登録しているユーザーの割合。
   • フィッシング耐性のある方法を使用したサインインの割合。
   • アプリケーションごとの方法の使用状況。 目標：60 日以内に管理者の 100％、12 か月以内に全従業員の 90％がフィッシング耐性のある方法を利用すること。

ガードレール

• 登録率が十分に高くなる前に、フィッシング耐性のある CA を強制しないでください。 月曜日の午前9時にロックアウトが発生します。フェーズ：まず登録キャンペーンを実施し、その後、グループごとに強制します。
• TAP は、本人確認済みのチャネルから発行する必要があります（強固な本人確認を行うヘルプデスク、Verified ID、対面）。TAP が漏えいすると、パスワードレス認証を迂回されます。
• **同期されたパスキーはデバイスの信頼境界を越えます。**個人用 Mac からサインインするユーザーも、会社用 Mac と同じパスキーを使用します。それが脅威モデルに合わない場合は、機密性の高いユーザーにはデバイスに紐づくパスキーまたはハードウェアキーを使用してください。
• **アテステーションの許可リストには、ライフサイクル管理が必要です。**新しい YubiKey モデルが登場すると、新しい AAGUID が追加されます。調達プロセスに組み込んでください。
• **番号照合 MFA はフィッシング耐性がありません。**MFA 疲労を狙ったスパムは防げますが、リアルタイムの AiTM プロキシには突破されます。混同しないでください。
• **「念のため」の SMS フォールバックは、この取り組みを台無しにします。**攻撃者はフォールバックを狙います。フィッシング耐性のある CA の対象者については削除してください。
• **緊急アクセス用アカウントを対象に含めたまま、条件付きアクセスの「認証強度：フィッシング耐性あり」を展開しないでください。**緊急アクセス用アカウントは必ず除外してください。

よくあるアンチパターン

• 「登録キャンペーンなしで、初日から管理者にパスキーを必須にする」 — 最も困るタイミングで管理者がロックアウトされます。
• 「全員に対して SMS を MFA のバックアップとして永久に許可する」 — SIM スワップや誘導型攻撃は、最も弱い方式を狙います。初日から Tier 0 では削除してください。
• 「MFA なしではアクセスできないユーザーのメールボックスに TAP をメールで送る」 — 鶏が先か卵が先かという状態になります。本人確認を行うヘルプデスクのチャネルを使用してください。
• 「アテステーションを強制し、許可リストにない最新の YubiKey モデルを使う」 — 調達当日に問題が発覚します。許可リストを維持してください。
• 「個人用 iCloud 上の同期パスキーを Global Admin に使わせる」 — 管理者の認証情報が個人のスマートフォンに保存されます。管理者にはハードウェアキーとデバイスに紐づくパスキーを使用してください。
• 「番号照合 MFA をフィッシング耐性ありと呼ぶ」 — そうではありません。AiTM に突破されます。
• 「従業員の登録率が95％に達する前に、テナント全体でパスワードサインインを無効にする」 — 未登録のユーザーがロックアウトされます。まずアプリごとに CA を適用し、監視してください。

プロンプトの例

• 25,000人のユーザーを対象とした12か月間のパスキー展開計画を立ててください。パイロット、キャンペーン、CA の強制、レガシー方式の廃止を含めます。
• アテステーションを強制して300人の管理者にハードウェア FIDO2 キーを配布し、AAGUID の許可リストを作成してください。
• Global Administrators と Azure portal にフィッシング耐性のある MFA を要求する条件付きアクセス ポリシーを作成してください。
• 規制対象のユーザーグループで、SMS MFA を90日以内に Authenticator のパスキーに置き換えてください。
• 人事のオンボーディングフローを通じて Temporary Access Pass を発行し、新入社員を初期設定してください。
• 成功指標とロールバック計画を含むパスキー登録キャンペーンを作成してください。
• スマートフォンと唯一の FIDO2 キーを紛失したユーザーを復旧してください。本人確認を含むランブックを作成します。
• Mac を多用するクリエイティブ職の従業員向けに、デバイスに紐づくパスキーと同期パスキーを比較してください。

Microsoft Learn

• Entra のパスキーの概要：https://learn.microsoft.com/entra/identity/authentication/concept-authentication-passwordless
• Microsoft Authenticator のパスキー：https://learn.microsoft.com/entra/identity/authentication/how-to-enable-authenticator-passkey
• FIDO2 セキュリティキー：https://learn.microsoft.com/entra/identity/authentication/concept-authentication-passwordless#fido2-security-keys
• アテステーションと AAGUID：https://learn.microsoft.com/entra/identity/authentication/concept-fido2-compatibility
• Temporary Access Pass：https://learn.microsoft.com/entra/identity/authentication/howto-authentication-temporary-access-pass
• CA の認証強度：https://learn.microsoft.com/entra/identity/authentication/concept-authentication-strengths
• 登録キャンペーン：https://learn.microsoft.com/entra/identity/authentication/how-to-mfa-registration-campaign
• 番号照合 MFA：https://learn.microsoft.com/entra/identity/authentication/how-to-mfa-number-match
• SMS／音声通話の廃止：https://learn.microsoft.com/entra/identity/authentication/how-to-authentication-methods-manage