次の方法で共有

リスク ポリシーを構成して有効にする

  • [アーティクル]

Microsoft Entra 条件付きアクセスには、2 つの種類の設定可能なリスク ポリシーがあります。 これらのポリシーを使用すると、リスクへの対応を自動化し、リスクが検出されたときにユーザーが自己修復を行えるようにできます。

条件としてリスクを示す条件付きアクセス ポリシーのスクリーンショット。

許容されるリスク レベルの選択

組織は、ユーザー エクスペリエンスとセキュリティ態勢のバランスを考慮しながら、アクセスの制御に要求するリスクのレベルを決定する必要があります。

リスク レベル高でアクセスの制御を適用することを選択すると、ポリシーがトリガーされる回数が減り、ユーザーにとっての手間が最小限になります。 しかし、これは低と中のリスクをポリシーから排除するため、攻撃者が侵害された ID を悪用するのを防げない可能性があります。 必要なアクセス管理に「低」のリスク レベルを選択すると、発生するユーザー割り込みが増えます。

構成済の信頼されたネットワークの場所は、Microsoft Entra ID 保護によって一部のリスク検出に使用され、偽陽性を低減します。

次のポリシー構成には、危険なユーザーとログインに対して再認証を求めるログログイン頻度のセッション制御が含まれます。

Microsoft の推奨

Microsoft は、以下のリスク ポリシー構成で組織を保護することを推奨しています。

  • ユーザー リスクのポリシー
    • ユーザーのリスク レベルが高のときは、セキュリティで保護されたパスワード変更を要求します。 ユーザーがパスワード ライトバックで新しいパスワードを作成してリスクを修復できるためには、その前に Microsoft Entra 多要素認証が必要です。
    • セルフサービスパスワードリセットを使用した安全なパスワード変更は、リスクレベルに関係なく、ユーザーリスクを自己修復する唯一の方法です。
  • サインインのリスク ポリシー
    • サインイン リスク レベルが中または高のときは Microsoft Entra 多要素認証を要求し、ユーザーが登録済みの認証方法のいずれかを使って証明し、サインイン リスクを修復できるようにします。
    • 多要素認証の成功は、リスク レベルに関係なく、サインイン リスクを自己修復する唯一の方法です。

リスク レベルが低い場合にアクセス制御を要求すると、中または高よりも多くの手間とユーザーへの割り込みが発生します。 安全なパスワード変更や多要素認証などの自己修復オプションの許可ではなく、アクセスのブロックを選択すると、ユーザーと管理者がさらに影響を受けます。 ポリシーを構成するときは、これらの選択をよく考えてください。

リスク修復

組織は、リスクが検出された場合にアクセスをブロックすることを選択できます。 ブロックすると、正当なユーザーが必要な操作を実行できなくなる場合があります。 より適切な解決策は、ユーザーが自己修復できるようにする、ユーザーおよびサインインのリスクベースの条件付きアクセス ポリシーを構成することです。

警告

ユーザーは、修復が必要な状況に直面する前に Microsoft Entra 多要素認証に登録する必要があります。 オンプレミスから同期されるハイブリッド ユーザーの場合は、パスワード ライトバックが有効になっている必要があります。 登録されていないユーザーはブロックされ、管理者の介入が必要になります。

危険なユーザー ポリシーの修復フローの外部でのパスワード変更 (パスワードが分かっていて、新しいパスワードに変更したい場合) は、セキュリティで保護されたパスワード変更の要件を満たしていません。

ポリシーを有効にする

組織は、以下の手順を使用して条件付きアクセスにリスクベース ポリシーをデプロイすることを選択できます。または、条件付きアクセス テンプレートを使用できます。

組織は、これらのポリシーを有効にする前に、すべてのアクティブなリスクを調査して修復する手順を踏む必要があります。

ポリシーの除外

条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。

  • ポリシー構成の誤りによるロックアウトを防ぐための緊急アクセスまたはブレークグラス アカウント。 すべての管理者がロックアウトされるというごくまれなシナリオにおいて、緊急アクセス用管理アカウントは、ログインを行い、アクセスを復旧させるための手順を実行するために使用できます。
  • サービス アカウントとサービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにログインするときにも使用されます。 サービス プリンシパルによる呼び出しは、ユーザーにスコーピングされる条件付きアクセス ポリシーによってブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
    • 組織がスクリプトまたはコードでこれらのアカウントを使用している場合、マネージド ID に置き換えることを検討してください。

条件付きアクセスでのユーザー リスク ポリシー

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
  2. 保護>条件付きアクセス を参照します。
  3. [新しいポリシー] を選択します。
  4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
  5. [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
    1. [Include](含める) で、 [すべてのユーザー] を選択します。
    2. [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
    3. 完了 を選択します。
  6. [Cloud アプリまたはアクション]>[含める] で、[すべてのリソース] (旧称 "すべてのクラウド アプリ") を選択します。
  7. [条件]>[ユーザー リスク] で、[構成] を [はい] に設定します。
    1. [ポリシーを適用するために必要なユーザー リスク レベルを構成する] で、[高] を選びます。 このガイダンスは Microsoft の推奨事項に基づいており、組織ごとに異なる場合があります
    2. 完了 を選択します。
  8. [アクセス制御]>[許可] で、 [アクセス権の付与] を選択します。
    1. [認証強度を要求する] を選択し、一覧から組み込みの認証強度である [多要素認証] を選択します。
    2. [パスワードの変更を必須にする] を選択します。
    3. [選択] を選択します。
  9. [セッション] で
    1. [サインインの頻度] を選択します。
    2. [毎回] が選択されていることを確認します。
    3. [選択] を選択します。
  10. 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
  11. [作成] を選択して、ポリシーを作成および有効化します。

管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。

パスワードレスのシナリオ

パスワードレス認証方式を採用している組織の場合は、次の変更を行います。

パスワードレスのユーザー リスク ポリシーを更新する

  1. [ユーザー] で:
    1. [含む] の [ユーザーとグループ] を選んで、パスワードレス ユーザーを対象にします。
  2. [アクセス制御]> パスワードレス ユーザーのアクセスを [ブロック] します。

ヒント

パスワードレス方式のデプロイ中に、一定期間、2 つのポリシーが必要になる場合があります。

  • 1 つは、パスワードレス方法を使用していないユーザーに対して自己修復を可能にするものです。
  • もう 1 つは、高リスクのパスワードレス ユーザーをブロックするものです。

パスワードレス ユーザー リスクを修復しブロックを解除する

  1. 管理者は、あらゆるリスクを調査し修復する必要があります。
  2. ユーザーのブロックを解除します。

条件付きアクセスのサインイン リスク ポリシー

  1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
  2. 保護>条件付きアクセス を参照します。
  3. [新しいポリシー] を選択します。
  4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
  5. [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
    1. [Include](含める) で、 [すべてのユーザー] を選択します。
    2. [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
    3. 完了 を選択します。
  6. [Cloud アプリまたはアクション]>[含める] で、[すべてのリソース] (旧称 "すべてのクラウド アプリ") を選択します。
  7. [条件]>[ログイン リスク] で、[構成] を [はい] に設定します。
    1. [このポリシーを適用するサインイン リスク レベルを選択します] で、 [高] と [中] を選択します。 このガイダンスは Microsoft の推奨事項に基づいており、組織ごとに異なる場合があります
    2. 完了 を選択します。
  8. [アクセス制御]>[許可] で、 [アクセス権の付与] を選択します。
    1. [認証強度を要求する] を選択し、一覧から組み込みの認証強度である [多要素認証] を選択します。
    2. [選択] を選択します。
  9. [セッション] で
    1. [サインインの頻度] を選択します。
    2. [毎回] が選択されていることを確認します。
    3. [選択] を選択します。
  10. 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
  11. [作成] を選択して、ポリシーを作成および有効化します。

管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。

パスワードレスのシナリオ

パスワードレス認証方式を採用している組織の場合は、次の変更を行います。

パスワードレス サインイン リスク ポリシーを更新する

  1. [ユーザー] で:
    1. [含む] の [ユーザーとグループ] を選んで、パスワードレス ユーザーを対象にします。
  2. [このポリシーを適用するサインイン リスク レベルを選択します] で、[高] を選択します。
  3. [アクセス制御]> パスワードレス ユーザーのアクセスを [ブロック] します。

ヒント

パスワードレス方式のデプロイ中に、一定期間、2 つのポリシーが必要になる場合があります。

  • 1 つは、パスワードレス方法を使用していないユーザーに対して自己修復を可能にするものです。
  • もう 1 つは、高リスクのパスワードレス ユーザーをブロックするものです。

パスワードレス サインイン リスクを修復しブロックを解除する

  1. 管理者は、あらゆるリスクを調査し修復する必要があります。
  2. ユーザーのブロックを解除します。

リスク ポリシーを条件付きアクセスに移行

Microsoft Entra ID 保護で有効なレガシ リスク ポリシーが存在する場合は、次のようにそれらを条件付きアクセスに移行することを計画する必要があります。

警告

Microsoft Entra ID Protection で構成された従来のリスク ポリシーは、2026 年 10 月 1 日に廃止されます。

条件付きアクセスへの移行

  1. レポート専用モードの条件付きアクセスで、ユーザー リスクベースとサインイン リスクベースの同等のポリシーを作成します。 Microsoft の推奨事項と組織の要件に基づき、前の手順または条件付きアクセス テンプレートを使用してポリシーを作成することができます。
    1. 管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。
  2. ID Protection の古いリスク ポリシーを無効にします。
    1. [保護]>[Identity Protection] に移動し、> または [サインインのリスク] ポリシーを選択します。
    2. [ポリシーの適用] を [無効] に設定します。
  3. 条件付きアクセスで必要な場合は、他のリスク ポリシーを作成します。

関連するコンテンツ