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

  • [アーティクル]

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

  • サインイン リスク ポリシー
  • ユーザー リスクのポリシー

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

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

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

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

Identity Protection で構成済みのセキュリティで保護されたネットワークの場所を使用することで、リスクを検出して偽陽性を減らすことができます。

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

Microsoft の推奨

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

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

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

リスク修復

組織は、リスクが検出された場合にアクセスをブロックすることを選択できます。 ブロックすると、正当なユーザーが必要な操作を実行できなくなる場合があります。 より適切な解決策は、Microsoft Entra の多要素認証とセキュリティで保護されたパスワード変更を使用して自己修復できるようにすることです。

警告

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

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

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

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

警告

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

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

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

ポリシーを有効にする

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

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

ポリシーの除外

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

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

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

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

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

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

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

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

関連するコンテンツ