次の方法で共有


Microsoft Entra ID で耐フィッシング パスワードレス認証の展開を計画する

環境内で耐フィッシング パスワードレス認証を展開して運用化する場合は、ユーザーペルソナベースのアプローチをおすすめします。 耐フィッシング パスワードレスのメソッドは、特定のユーザーペルソナに対しては、他の方法よりも効果的です。 この展開ガイドは、環境内のユーザー ペルソナにとって意味のあるメソッドとロールアウト計画の種類を確認するのに役立ちます。 耐フィッシング パスワードレスの展開のアプローチには、一般的に 6 つの手順があります。これはおおよそ順番に従って流れますが、他の手順に移る前に 100% 完了している必要はありません。

ユーザー ペルソナを決定する

組織に関連するユーザー ペルソナを決定します。 ペルソナごとにニーズが異なるため、この手順はプロジェクトにとって非常に重要です。 組織内で少なくとも 4 つの汎用ユーザー ペルソナを検討して評価することを、マイクロソフトはおすすめします。

ユーザー ペルソナ 説明
インフォメーション ワーカー
  • 例としては、マーケティング、財務、人事といった、オフィスの生産性スタッフなどが挙げられます。
  • その他の種類のインフォメーション ワーカーには、役員や、特別な管理策を必要とするその他の機密性の高いワーカーなどが考えられます
  • 通常、モバイルおよびコンピューティング デバイスと 1 対 1 のリレーションシップがあります
  • 特にモバイルについては、各自がデバイスを持ち込む (BYOD) 場合があります
  • フロントライン ワーカー
  • 例としては、小売店作業員、工場作業員、製造作業員などが挙げられます。
  • 通常は、共有デバイスまたはキオスク上でのみ作業します
  • 携帯電話は持ち込み不可の場合があります
  • IT プロ/DevOps ワーカー
  • 例としては、オンプレミスの Active Directory の IT 管理者、Microsoft Entra ID、またはその他の権限を持つアカウントなどが挙げられます。 その他の例としては、自動化を管理および展開する DevOps ワーカーや DevSecOps ワーカーがあります。
  • 通常は、「ノーマル」のユーザー アカウントと 1 つ以上の管理アカウントを含む、複数のユーザー アカウントを持ちます
  • リモート デスクトップ プロトコル (RDP) や Secure Shell Protocol (SSH) などのリモート アクセス プロトコルを一般的に使用して、リモート システムを管理します
  • Bluetooth が無効になっているロックダウンされたデバイスで作業する場合があります
  • セカンダリ アカウントを使用して、非対話型の自動化やスクリプトを実行する場合があります
  • 高度規制ワーカー
  • 例としては、行政命令 14028 の要件の対象となる米国連邦政府職員、州政府および地方政府職員、または特定のセキュリティ規制の対象となる作業員が含まれます。
  • 通常はデバイスと 1 対 1 のリレーションシップにありますが、デバイスの認証のために特定の規制管理策を満たす必要があります
  • セキュリティで保護された領域では、携帯電話が許可されない場合があります
  • インターネットに接続されていないエアギャップ環境にアクセスする場合があります
  • Bluetooth が無効になっているロックダウンされたデバイスで作業する場合があります
  • 耐フィッシング パスワードレス認証を組織全体に広く展開することを、マイクロソフトはおすすめします。 従来、インフォメーション ワーカーは、開始にあたって最も難易度の低いユーザー ペルソナです。 IT プロに影響を与える問題を解決する際は、インフォメーション ワーカーのセキュアな認証情報のロールアウトを遅らせないでください。 「完璧を求めすぎない」アプローチを取りつつ、可能な限りセキュアな認証情報を展開します。 耐フィッシング パスワードレス認証情報を使用してサインインするユーザーが増えるほど、環境の攻撃面を減らすことができます。

    ペルソナを定義したときは、各ペルソナをそのユーザー ペルソナ専用の Microsoft Entra ID グループに配置することを、マイクロソフトはおすすめします。 これらのグループは、以降の手順でさまざまな種類のユーザーに認証情報をロール アウトし、耐フィッシング パスワードレス認証情報の使用を開始するときに使用します。

    デバイスの準備を計画する

    耐フィッシング パスワードレス展開を成功させる上で、デバイスは不可欠な側面です。耐フィッシング パスワードレス認証情報の目標の 1 つとして、最新のデバイスのハードウェアで認証情報を保護することがあるためです。 まず、Microsoft Entra ID の FIDO2 のサポートについて理解してください。

    各オペレーティング システムがサポートする最新バージョンのパッチを適用し、耐フィッシング パスワードレスに対するデバイスの準備が整っていることを確認します。 デバイスでは以下以降のバージョンが稼働していることを、マイクロソフトはおすすめします。

    • Windows 10 22H2 (Windows Hello for Business の場合)
    • Windows 11 22H2 (パスキー使用に最適なユーザー エクスペリエンスを求める場合)
    • macOS 13 Ventura
    • iOS 17
    • Android 14

    これらのバージョンは、パスキー、Windows Hello for Business、macOS プラットフォーム認証情報などのネイティブ統合された機能に最適なサポートを提供します。 古いオペレーティング システムでは、耐フィッシング パスワードレス認証をサポートするために、FIDO2 セキュリティ キーなどの外部認証子が必要になる場合があります。

    耐フィッシング認証情報をユーザーに登録する

    耐フィッシング パスワードレスの展開プロジェクトで最初に行う重要なエンドユーザー向けアクティビティは、認証情報の登録とブートストラップです。 このセクションでは、移植可能ローカルの認証情報のロールアウトについて説明します。

    認証情報 説明 メリット
    移植可能 デバイスをまたいで使用できます。 移植可能な資格情報を使用すると、別のデバイスにサインインすることや、他のデバイスに認証情報を登録することができます。 デバイス間で使用でき、多くのシナリオで耐フィッシング認証を提供できるため、ほとんどのユーザーにとって最重要で登録するべき認証情報のタイプです。
    ローカル ローカル認証情報を使用すると、Windows Hello for Business 生体認証認識を使用して同じ PC 上の Microsoft Edge ブラウザーでアプリにサインインするなど、外部ハードウェアに依存することなくデバイス上の認証を行えます 移植可能な認証情報と比較して、主に次の 2 つの利点があります。
  • 冗長性を提供します。 ユーザーがポータブル デバイスを紛失した場合、自宅に忘れてきた場合、または他の問題が発生した場合、ローカル認証情報は、コンピューティング デバイスで引き続き作業するためのバックアップの方法を提供します。
  • 優れたユーザー エクスペリエンスを提供します。 ローカル認証情報を使用すると、ユーザーは携帯電話をひっぱり出すことや QR コードのスキャンなど、認証に時間がかかって流れを損なうようなタスクを実行する必要がなくなります。 ローカルで利用できる耐フィッシング認証情報は、ユーザーが定期的に使用するデバイスに簡単にサインインするのに役立ちます。
    • 新規ユーザーの場合、既存の企業の認証情報を持たないユーザーは登録とブートストラップのプロセスが引き受け、その ID が検証されます。 これにより、最初の移植可能な認証情報がブートストラップされ、その移植可能な認証情報を使用して、各コンピューティング デバイス上の他のローカル認証情報がブートストラップされます。 登録後、管理者は Microsoft Entra ID のユーザーに耐フィッシング認証を実施できます。
    • 既存ユーザーの場合、このフェーズでは、ユーザーが既存のデバイスで耐フィッシング パスワードレスに直接登録するか、既存の MFA 認証情報を使用して耐フィッシング パスワードレス認証情報をブートストラップします。 最終的な目標は新規ユーザーと同じです。ほとんどのユーザーは 1 つ以上の移植可能な認証情報を持ち、次いで各コンピューティング デバイス上でローカル認証情報を持つ必要があります。 既存のユーザーに対して耐フィッシング パスワードレスを展開する管理者である場合は、スキップして「オンボーディング手順 2: 移植可能な認証情報のブートストラップ」セクションに進むことができます。

    開始する前には、テナント内のエンタープライズ ユーザーに対しパスキーやその他の認証情報を有効にすることを、マイクロソフトはおすすめします。 より強力な認証情報を自分で登録することにユーザーが意欲を示す場合、許可することが有益です。 少なくとも、パスキー (FIDO2) ポリシーを有効にして、好みに応じてユーザーがパスキーとセキュリティ キーを登録できるようにする必要があります。

    このセクションでは、フェーズ 1 から 3 について説明します。

    計画されたプロセスの最初の 3 つのフェーズを示す図。

    ユーザーには、少なくとも 2 つの認証方法が登録されている必要があります。 別のメソッドを登録すると、デバイスの紛失や盗難などによりメインのメソッドに問題が発生した場合でも、ユーザーはバックアップのメソッドを利用できます。 たとえば、携帯電話とワークステーション (Windows Hello for Business でローカルに) の両方にパスキーを登録することがおすすめです。

    ユーザーは少なくとも 2 つの認証方法を登録しておくことを常におすすめします。 これにより、デバイスの紛失や盗難などによりメインのメソッドに問題が発生した場合でも、ユーザーはバックアップのメソッドを利用できるようになります。 たとえば、携帯電話とワークステーション (Windows Hello for Business でローカルに) の両方にパスキーを登録することがおすすめです。

    このガイダンスは、Microsoft Entra ID で現状サポートされるパスキーに合わせて作成されています。これには、Microsoft Authenticator のデバイス バインド パスキーや、物理セキュリティ キーのデバイス バインド パスキーなどがあります。 Microsoft Entra ID には、同期されたパスキーのサポートが追加される予定です。 詳細については、「パブリック プレビュー: Microsoft Entra ID でサポートされるパスキーの拡張」を参照してください。 同期されたパスキーが利用可能になったときは、本ガイドもそのガイダンスを含める形で更新されます。 たとえば前図のフェーズ 3 について、まったく新しい認証情報をブートストラップするよりも、同期で実行できれば、多くの組織にとってメリットがあります。

    オンボーディング手順 1: 本人確認

    ID が証明されていないリモート ユーザーにとって、エンタープライズ オンボーディングはかなりの困難になります。 Microsoft Entra Verified ID は、高保証 ID 検証を必要とするお客様を支援します。 ユーザー ID の信頼を確立する方法として、政府発行の ID に基づく構成証明を使用できます。

    このフェーズでは、ユーザーは本人確認パートナー サービスに誘導される場合があります。 ユーザーは、組織が決定した証明プロセスと、組織が選択した検証パートナー サービスを経由します。 このプロセスを終えると、最初の移植可能な認証情報のブートストラップに使用できる一時アクセス パス (TAP) がユーザーに付与されます。

    Microsoft Entra Verified ID のオンボーディングと TAP 発行を有効にするには、次のガイドを参照してください。

    Microsoft Entra Verified ID は、Microsoft Entra Suite ライセンスの一部です。

    組織によっては、ユーザーをオンボードして最初の認証情報を発行するために、Microsoft Entra Verified ID 以外の方法を選択する場合もあります。 このような組織には、引き続き TAP を使用すること、またはユーザーがパスワードなしでオンボードできるようにする別の方法を使用することを、マイクロソフトはおすすめします。 たとえば、Microsoft Graph API (プレビュー) を使用して FIDO2 セキュリティ キーをプロビジョニングすることができます。

    オンボーディング手順 2: 移植可能な認証情報をブートストラップする

    既存のユーザーを耐フィッシング パスワードレス認証情報にブートストラップするには、まず、ユーザーが従来の MFA に既に登録されているかどうかを特定します。 従来の MFA 方法が登録されているユーザーは、耐フィッシング パスワードレスの登録ポリシーの対象とすることができます。 従来の MFA を使用して、最初の移植可能な耐フィッシング認証情報を登録し、必要に応じてローカル認証情報の登録に進むことができます。

    新規ユーザーまたは MFA を持たないユーザーの場合は、ユーザーに一時アクセス パス (TAP) を発行するプロセスを実行します。 TAP の発行は、新規ユーザーに最初の認証情報を与えるのと同じ方法で、または Microsoft Entra Verified ID 統合を使用して行えます。 ユーザーが TAP を取得することで、最初の耐フィッシング認証情報をブートストラップする準備が整います。

    ユーザーの最初のパスワードレス認証情報は、他のコンピューティング デバイスでの認証に使用できる移植可能な認証情報であることが重要です。 たとえばパスキーは、iOS 電話でローカルに認証することに使用できますが、クロスデバイス認証フローを使用して Windows PC で認証するために使用することもできます。 このクロスデバイス機能により、移植可能なパスキーを使用して Windows PC 上で Windows Hello for Business をブートストラップできます。

    また、ユーザーに可能な限りスムーズなユーザー エクスペリエンスを提供するためには、ユーザーが定期的に作業する各デバイスにローカルで利用可能な認証情報が設定されていることも重要です。 ローカルで使用可能な認証情報を使用すると、ユーザーが複数のデバイスを使用する必要がなく、手順が少なくなるため、認証に必要な時間が短縮されます。 手順 1 の TAP を使用して、その他の認証情報をブートストラップできる移植可能な認証情報を登録すると、ユーザーは所有するデバイスの多くで耐フィッシング認証情報をネイティブに使用できます。

    次の表に、さまざまなペルソナの推奨事項を一覧で示します。

    ユーザー ペルソナ おすすめの移植可能な認証情報 代替の移植可能な認証情報
    インフォメーション ワーカー パスキー (Authenticator アプリ) セキュリティ キー、スマート カード
    フロントライン ワーカー セキュリティ キー パスキー (Authenticator アプリ)、スマート カード
    IT プロ/DevOps ワーカー パスキー (Authenticator アプリ) セキュリティ キー、スマート カード
    高度規制ワーカー 認定資格証 (スマート カード) パスキー (Authenticator アプリ)、セキュリティ キー

    次のガイダンスを使用して、組織の関連するユーザー ペルソナに対して推奨される代替の移植可能な認証情報を有効にします。

    メソッド ガイダンス
    パスキー
  • アプリでパスキーをブートストラップする際は、Microsoft Authenticator に直接サインインすることを、マイクロソフトはおすすめします。
  • ユーザーは TAP を使用して、iOS または Android デバイスで直接 Microsoft Authenticator にサインインできます。
  • Microsoft Entra ID では、既定ではパスキーが無効になっています。 パスキーは、認証方法ポリシーで有効にすることができます。
  • Android または iOS デバイスの Authenticator にパスキーを登録する。
  • セキュリティ キー
  • Microsoft Entra ID では、既定ではセキュリティ キーがオフになっています。 FIDO2 セキュリティ キーは、認証方法ポリシーで有効にすることができます。
  • ユーザーに代わって Microsoft Entra ID プロビジョニング API にキーを登録することを検討してください。 詳細については、「Microsoft Graph API を使用して FIDO2 セキュリティ キーをプロビジョニングする (プレビュー)」をご覧ください。
  • スマート カード/証明書ベースの認証 (CBA):
  • 証明書ベースの認証は、パスキーやその他のメソッドよりも設定が複雑です。 必要な場合のみ使用を検討してください。
  • Microsoft Entra 証明書ベースの認証を設定する方法
  • ユーザーが多要素認証を間違いなく完了してサインインできるように、オンプレミス PKI ポリシーと Microsoft Entra ID CBA ポリシーを設定してください。 通常、この設定にはスマート カード ポリシー オブジェクト識別子 (OID) と、必要に応じたアフィニティ バインディングの設定が必要です。 より高度な CBA 設定については、「認証バインド ポリシーの概要」を参照してください。
  • オンボーディング手順 3: コンピューティング デバイスでローカル認証情報をブートストラップする

    ユーザーが移植可能な認証情報を登録すると、定期的に使用する各コンピューティング デバイスで、他の資格情報についても 1 対 1 のリレーションシップでブートストラップできるようになり、日常のユーザー エクスペリエンスにメリットをもたらします。 このタイプの認証情報は、インフォメーション ワーカーと IT プロでは一般的ですが、デバイスを共有するフィールド ワーカーではそうではありません。 デバイスの共有のみ行うユーザーは、移植可能な認証情報しか使用しないべきです。

    組織はこの段階で、各ユーザー ペルソナに対しどのタイプの認証情報が優先されるか決定する必要があります。 マイクロソフトのおすすめ:

    ユーザー ペルソナ おすすめのローカル認証情報 - Windows おすすめのローカル認証情報 - macOS おすすめのローカル認証情報 - iOS おすすめのローカル認証情報 - Android おすすめのローカル認証情報 - Linux
    インフォメーション ワーカー Windows Hello for Business プラットフォーム シングル サインオン (SSO) セキュア エンクレーブ キー パスキー (Authenticator アプリ) パスキー (Authenticator アプリ) N/A (代わりに移植可能な認証情報を使用する)
    フロントライン ワーカー N/A (代わりに移植可能な認証情報を使用する) N/A (代わりに移植可能な認証情報を使用する) N/A (代わりに移植可能な認証情報を使用する) N/A (代わりに移植可能な認証情報を使用する) N/A (代わりに移植可能な認証情報を使用する)
    IT プロ/DevOps ワーカー Windows Hello for Business プラットフォーム SSO セキュア エンクレーブ キー パスキー (Authenticator アプリ) パスキー (Authenticator アプリ) N/A (代わりに移植可能な認証情報を使用する)
    高度規制ワーカー Windows Hello for Business または CBA プラットフォーム SSO セキュア エンクレーブ キーまたは CBA パスキー (Authenticator アプリ) または CBA パスキー (Authenticator アプリ) または CBA N/A (代わりにスマート カードを使用する)

    次のガイダンスを使用して、組織の関連するユーザー ペルソナに対して、環境内で推奨されるローカル認証情報を有効にします。

    メソッド ガイダンス
    Windows Hello for Business
  • Windows Hello for Business の展開には Cloud Kerberos Trust メソッドを使用することを、マイクロソフトはおすすめします。 詳細については「Cloud Kerberos Trust の展開ガイド」を参照してください。 Cloud Kerberos Trust メソッドは、ユーザーが オンプレミスの Active Directory から Microsoft Entra ID に同期されるすべての環境に適用されます。 これは、Microsoft Entra 参加済みまたは Microsoft Entra ハイブリッド参加済みの PC 上の同期済みユーザーを支援します。
  • Windows Hello for Business は、PC 上の各ユーザーが、自分自身としてその PC にサインインしている場合しか使用しないようにするべきです。 共有ユーザー アカウントを使用するキオスク デバイスでは使用しないでください。
  • Windows Hello for Business では、デバイスあたり最大 10 人のユーザーがサポートされます。 共有デバイスでより多くのユーザーをサポートする必要がある場合は、セキュリティ キーなどの移植可能な認証情報を代わりに使用します。
  • 生体認証はオプションですが、推奨されます。 詳細については、「ユーザーによる Windows Hello for Business のプロビジョニングと使用について準備する」を参照してください。
  • プラットフォーム SSO セキュア エンクレーブ キー
  • プラットフォーム SSO では、3 つの異なるユーザー認証方法 (セキュア エンクレーブ キー、スマート カード、パスワード) がサポートされています。 セキュア エンクレーブ キー メソッドを展開して、Windows Hello for Business を Mac にミラーリングします。
  • プラットフォーム SSO では、Mac が モバイル デバイス管理 (MDM) に登録されている必要があります。 Intune の具体的な手順については、「 Microsoft Intune で macOS デバイスのプラットフォーム SSO を設定するを参照してください。
  • Mac で別の MDM サービスを使用する場合は、MDM ベンダーのドキュメントを参照してください。
  • パスキー
  • Microsoft Authenticator でパスキーをブートストラップする際は、(クロスデバイスの登録オプションではなく) 同じデバイスの登録オプションを選択することを、マイクロソフトはおすすめします。
  • ユーザーは、iOS または Android デバイスで直接 Microsoft Authenticator にサインインする際は、TAP を使用します。
  • Microsoft Entra ID は、既定ではパスキーが無効になっており、認証方法ポリシーから有効にできます。 詳細については、「Microsoft Authenticator でパスキーを有効にする」を参照してください。
  • Android または iOS デバイスの Authenticator にパスキーを登録する。
  • ペルソナ固有の考慮事項

    各ペルソナには、耐フィッシング パスワードレス展開中に共通して発生する固有の課題と考慮事項があります。 対応が必要となるペルソナを特定するときは、展開のプロジェクト計画策定にこれらの考慮事項を組み込む必要があります。 次のリンクには、各ペルソナに固有のガイダンスがあります。

    耐フィッシング認証情報の使用を促進する

    この手順では、ユーザーが耐フィッシング認証情報を簡単に導入できるようにするための方法について説明します。 展開戦略をテストし、ロールアウトの計画を立て、エンド ユーザーに計画を伝える必要があります。 次に、組織全体で耐フィッシング認証情報を実施する前に、レポートを作成して進行状況を監視することができます。

    テスト展開の戦略

    前の手順で作成した展開戦略は、一連のテスト ユーザーとパイロット ユーザーでテストすることを、マイクロソフトはおすすめします。 このフェーズには、次の手順が記載されます。

    • テスト ユーザーと早期導入者の一覧を作成します。 これらのユーザーは、IT 管理者だけでなく、様々なユーザー ペルソナを代表する必要があります。
    • Microsoft Entra ID グループを作成し、テスト ユーザーをグループに追加します。
    • Microsoft Entra ID で 認証方法ポリシーを有効にし、テスト グループの範囲を有効にしているメソッドに設定します。
    • 認証方法活動記録レポートを使用して、パイロット ユーザーの登録ロールアウトを測定します。
    • 条件付きアクセス ポリシーを作成して、各オペレーティング システムの種類に対して耐フィッシング パスワードレス認証情報の使用を実施し、パイロット グループを対象にします。
    • Azure Monitor と Workbooks を使用して、実施の成功を測定します。
    • ロールアウトの成功に関するフィードバックをユーザーから収集します。

    ロールアウト戦略を計画する

    使用の促進は、展開の準備が最も整っているユーザー ペルソナに基づいて行うことを、マイクロソフトはおすすめします。 通常、これはこの順序でユーザーに展開することを意味しますが、組織によっては変更される場合があります。

    1. インフォメーション ワーカー
    2. フロントライン ワーカー
    3. IT プロ/DevOps ワーカー
    4. 高度規制ワーカー

    以下のセクションを使用して、各ペルソナ グループのエンド ユーザーのコミュニケーションを作成し、パスキー登録機能のスコープとロールアウトを行い、ロールアウトの進行状況を追跡するためのユーザー レポートと監視を行います。

    エンド ユーザー コミュニケーションを計画する

    マイクロソフトはエンド ユーザー向けのコミュニケーション テンプレートを提供しています。 認証ロールアウト資料には、耐フィッシング パスワードレス認証の展開についてユーザーに通知するカスタマイズ可能なポスターと電子メール テンプレートが含まれています。 次のテンプレートを使用して、耐フィッシング パスワードレス展開について理解できるように、ユーザーとのコミュニケーションを行います。

    できるだけ多くのユーザーを捉えられるように、コミュニケーションは繰り返し行う必要があります。 たとえば、組織では、次のようなパターンを使用して、さまざまなフェーズとタイムラインのコミュニケーションを行うことを選択できます。

    1. 実施まで 60 日: 耐フィッシング認証方法の価値を伝え、ユーザーに積極的に登録することを促します
    2. 実施まで 45 日: メッセージを繰り返します
    3. 実施まで 30 日: 30 日後に耐フィッシングの実施が始まることを伝え、ユーザーに積極的に登録することを促します
    4. 実施まで 15 日: メッセージを繰り返し、ヘルプ デスクへの連絡方法を通知します
    5. 実施まで 7 日: メッセージを繰り返し、ヘルプ デスクへの連絡方法を通知します
    6. 実施まで 1 日: 24 時間後に実施されることを通知し、ヘルプ デスクへの連絡方法を通知します

    ユーザーとはメール以外のチャンネルを通してコミュニケーションを行うことを、マイクロソフトはおすすめします。 その他のオプションとしては、Microsoft Teamsメッセージ、休憩室のポスター、選ばれた従業員が同僚にプログラムを推奨するトレーニングを受けるチャンピオン プログラムなどがあります。

    レポートと監視

    Microsoft Entra ID レポート (認証方法アクティビティMicrosoft Entra 多要素認証のサインイン イベント詳細) は、導入の測定と促進に役立つ技術的およびビジネス上の分析情報を提供します。

    認証方法アクティビティ ダッシュボードから、登録と使用状況を表示できます。

    • 登録には、耐フィッシング パスワードレス認証や、その他の認証方法を利用できるユーザーの数が表示されます。 ユーザーが登録した認証方法と、各メソッドの最近の登録を示すグラフを表示できます。
    • 使用は、サインインに使用された認証方法を表示します。

    ビジネスおよびテクニカル アプリケーションのオーナーは、組織の要件に基づいてレポートを所有および受信する必要があります。

    • 認証方法の登録活動記録レポートを使用して、耐フィッシング パスワードレス認証情報のロールアウトを追跡します。
    • 認証方法によるサインイン活動記録レポートとサインイン ログを使用して、耐フィッシング パスワードレス認証情報のユーザー導入を追跡します。
    • サインイン活動記録レポートを使用すると、さまざまなアプリケーションへのサインインに使用された認証方法を追跡できます。 ユーザー行を選択し、[認証の詳細] を選択して、認証方法とそれに対応するサインイン アクティビティを表示します。

    Microsoft Entra ID では、次の条件では監査ログにエントリが追加されます。

    • 管理者が認証方法を変更した場合。
    • ユーザーが、Microsoft Entra ID 内で資格情報に対して何らかの種類の変更を行った場合。

    Microsoft Entra ID では、ほとんどの監査データが 30 日間保持されます。 監査、傾向分析やその他のビジネス ニーズに応じて、保持期間を長くすることをおすすめします。

    Microsoft Entra 管理センターまたは API の監査データにアクセスし、解析システムにダウンロードします。 データ保持期間を長くする必要がある場合は、Microsoft Sentinel、Splunk、Sumo Logic などのセキュリティ情報イベント管理 (SIEM) ツールでログをエクスポートして実行します。

    ヘルプ デスクチケットのボリュームを監視する

    IT ヘルプ デスクは、デプロイがどの程度進んでいるかについて非常に重要なシグナルを提供できるため、耐フィッシング パスワードレス展開を実行するときは、ヘルプ デスク チケットの量を追跡することを、マイクロソフトはおすすめします。

    ヘルプ デスクチケットの量が増えるほど、展開、ユーザー コミュニケーション、実施アクションのペースを遅くする必要があります。 チケットの量が減ると、これらのアクティビティのペースを再度上げることができます。 このアプローチを使用するには、ロールアウト計画の柔軟性を維持する必要があります。

    たとえば、特定の日付ではなく日付の範囲が設定されたウェーブで展開と実施を実行するようにします。

    1. 6 月 1 日から 15 日: ウェーブ 1 コーホートの登録の展開とキャンペーン
    2. 6 月 16 日から 30 日:ウェーブ 2 コーホートの登録の展開とキャンペーン
    3. 7 月 1 日から 15 日: ウェーブ 3 コーホートの登録の展開とキャンペーン
    4. 7 月 16 日から 31 日: ウェーブ 1 コーホートの実施を有効にする
    5. 8 月 1 日から 15 日: ウェーブ 2 コーホートの実施を有効にする
    6. 8 月 16 日から 31 日: ウェーブ 3 コーホートの実施を有効にする

    これらの異なるフェーズを実行する際に、ヘルプ デスク チケットを開いた量に従い速度を低下させ、量が落ち着いたら再開することが必要になる場合があります。 この戦略を実行するには、ウェーブごとに Microsoft Entra ID セキュリティ グループを作成し、各グループをポリシーに一度に 1 つずつ追加することを、マイクロソフトはおすすめします。 このアプローチは、サポート チームに過度の負荷を与えることを回避するのに役立ちます。

    サインインに対して耐フィッシング メソッドを実施する

    このセクションでは、フェーズ 4 について説明します。

    展開の実施フェーズをハイライトした図。

    耐フィッシング パスワードレス展開の最終フェーズでは、耐フィッシング認証情報の使用を実施します。 Microsoft Entra ID でこれを行うための主要なメカニズムは、条件付きアクセス認証の強度です。 ユーザー/デバイス ペアの方法論に基づいて各ペルソナに実施するアプローチを、マイクロソフトはおすすめしています。 たとえば、実施のロールアウトは次のパターンに従うことが考えられます。

    1. Windows および iOS のインフォメーション ワーカー
    2. macOS および Android のインフォメーション ワーカー
    3. iOS および Android の IT プロ
    4. iOS と Android の FLW
    5. Windows および macOS の FLW
    6. Windows および macOS の IT プロ

    テナントからのサインイン データを使用して、すべてのユーザーとデバイスのペアのレポートを作成することを、マイクロソフトはおすすめします。 Azure Monitor や Workbooks などのクエリ ツールを使用できます。 少なくとも、これらのカテゴリに一致するすべてのユーザー/デバイス ペアを特定するようにしてください。

    ユーザーごとに、作業に定期的に使用するオペレーティング システムのリストを作成します。 そのユーザー/デバイス ペアに対する耐フィッシング サインイン実施の準備状況に、リストをマッピングします。

    OS の種類 実施の準備完了 実施の準備ができていない
    Windows 10 以降 Windows Server 8.1 以前
    iOS 17 以降 16 以前
    Android 14 以降 13 以前
    macOS 13 以降 (Ventura) 12 以前
    VDI 条件次第1 条件次第1
    その他 条件次第1 条件次第1

    1デバイスのバージョンをすぐに実施する準備ができていないユーザー/デバイスの各ペアについては、耐フィッシングを実施する必要性に対処する方法を特定します。 古いオペレーティング システム、仮想デスクトップ インフラストラクチャ (VDI)、Linux、その他のオペレーティング システムについては、次のオプションを検討します。

    • 外部ハードウェアを使用して耐フィッシングを実施する – FIDO2 セキュリティ キー
    • 外部ハードウェアを使用して耐フィッシングを実施する - スマート カード
    • クロスデバイス認証フローのパスキーなど、リモート認証情報を使用して耐フィッシングを実施する
    • RDP トンネル内のリモート認証情報を使用して耐フィッシングを実施する (特に VDI の場合)

    重要なタスクは、特定のプラットフォームでどのユーザーとペルソナが実施の準備ができているか、データを通して測定することです。 「止血」のための実施が準備できているユーザー/デバイス ペアに対し実施のアクションを開始し、環境内で発生するフィッシング可能な認証の数を減らします。

    次に、ユーザー/デバイス ペアに準備作業が必要な場合ついて、他のシナリオに進みます。 組織全体に耐フィッシング認証が実施されるまで、ユーザー/デバイス ペアのリストを通して作業を進めます。

    Microsoft Entra ID グループのセットを作成して、実施を段階的にロールアウトします。 ウェーブ ベースのロールアウト アプローチを使用した場合は、前の手順のグループを再利用します。

    特定の条件付きアクセス ポリシーで各グループを対象にします。 このアプローチは、ユーザー/デバイス ペアによって実施の管理策を段階的にロールアウトするのに役立ちます。

    ポリシー ポリシーが対象とするグループ名 ポリシー – デバイス プラットフォームの条件 ポリシー – 許可の管理策
    1 Windows の耐フィッシング パスワードレスに対応するユーザー Windows 認証強度が必要 - 耐フィッシング MFA
    2 macOS の耐フィッシング パスワードレスに対応するユーザー macOS 認証強度が必要 - 耐フィッシング MFA
    3 iOS の耐フィッシング パスワードレスに対応するユーザー iOS 認証強度が必要 - 耐フィッシング MFA
    4 Android の耐フィッシング パスワードレスに対応するユーザー Android 認証強度が必要 - 耐フィッシング MFA
    5 その他の耐フィッシング パスワードレスに対応するユーザー Windows、macOS、iOS、Android を除くすべて 認証強度が必要 - 耐フィッシング MFA

    それぞれのデバイスとオペレーティング システムについて準備ができているか、またはその種類のデバイスを持っていないかを判定して、各ユーザーを各グループに追加します。 ロールアウトの終わりには、すべてのユーザーがいずれかのグループに属している必要があります。

    パスワードレス ユーザーのリスクに対応する

    Microsoft Entra ID 保護は、組織が ID ベースのリスクを検出、調査、修復するのために役立ちます。 Microsoft Entra ID 保護は、耐フィッシング パスワードレス認証情報の使用に切り替えた後でも、ユーザーにとって重要で有用な検出結果を提供します。 たとえば、耐フィッシング ユーザーに関連する検出結果には、次のようなものがあります。

    • 匿名 IP アドレスからのアクティビティ
    • ユーザーに対するセキュリティ侵害を管理者が確認しました
    • 異常なトークン
    • 悪意のある IP アドレス
    • Microsoft Entra の脅威インテリジェンス
    • 疑わしいブラウザー
    • 中間攻撃者
    • プライマリ更新トークン (PRT) へのアクセス試行の可能性
    • その他: riskEventType にマッピングされたリスク検出数

    Microsoft Entra ID 保護ユーザーが耐フィッシング パスワードレス ユーザーを保護するために、次のアクションを実行することを、マイクロソフトはおすすめします。

    1. Microsoft Entra ID 保護展開ガイダンスを確認する: ID 保護の展開を計画する
    2. リスク ログを SIEM にエクスポートするように設定する
    3. 中程度のユーザーリスクを調査して対処する
    4. 高リスクの ユーザーをブロックするように条件付きアクセス ポリシーを設定する

    Microsoft Entra ID 保護を展開した後は、条件付きアクセス トークン保護の使用を検討してください。 ユーザーが耐フィッシング パスワードレス認証情報でサインインするにつれ、攻撃と検出が進化し続けます。 たとえば、ユーザーの認証情報を簡単にフィッシングできなくなった場合、攻撃者はユーザー デバイスからトークンを流出させる試みに移行する可能性があります。 トークン保護は、発行先のデバイスのハードウェアにトークンをバインドすることで、このリスクの軽減に役立ちます。

    次のステップ

    Microsoft Entra ID での耐フィッシング パスワードレス認証の展開における特定のペルソナに関する考慮事項