Microsoft Entra ID で回復性があるアクセス制御管理戦略を作成する

多要素認証や 1 つのネットワークの場所などの単一のアクセス制御に依存して IT システムをセキュリティ保護している組織では、その単一のアクセス制御が使用不能になったり誤って構成された場合に、アプリやリソースへのアクセス障害の影響を受けやすくなります。 たとえば、自然災害によって、広範囲の通信インフラストラクチャや企業ネットワークを使用できなくなる可能性があります。 このようなが中断のため、エンド ユーザーや管理者がサインインできなくなることがあります。

このドキュメントでは、次のようなシナリオで、予期されていない中断の間のロックアウトのリスクを軽減する回復性を提供するために、組織で採用する必要がある戦略に関するガイダンスを示します。

• 組織では、リスク軽減戦略またはコンティンジェンシー計画を実装することで、中断の前にロックアウトのリスクを軽減する回復性を向上させることができます。
• 組織では、リスク軽減戦略とコンティンジェンシー計画を導入することで、中断の間に選択したアプリとリソースへのアクセスを続けることができます。
• 組織では、中断の後、実装されているコンティンジェンシーをロールバックする前に、ログなどの情報が保持されるようにする必要があります。
• 防止戦略や代替計画を実装していない組織でも、中断に対処する緊急オプションを実装できる場合があります。

重要なガイダンス

このドキュメントで重要なことは次の 4 つです。

• 緊急アクセス用アカウントを使用して、管理者のロックアウトを回避する。
• ユーザーごとの MFA ではなく条件付きアクセスを使用して、MFA を実装する。
• 複数の条件付きアクセス制御を使用して、ユーザーのロックアウトを軽減する。
• 複数の認証方法または同等の手段をユーザーごとにプロビジョニングして、ユーザーのロックアウトを軽減する。

中断する前

発生する可能性があるアクセス制御の問題への対応において、組織が主眼にする必要があるのは、実際の中断を軽減することです。 軽減策には、実際のイベントに対する計画に加えて、アクセス制御と運用が中断の間に影響を受けないようにする戦略の実装が含まれます。

回復性があるアクセス制御が必要な理由

ID は、アプリとリソースにアクセスするユーザーのコントロール プレーンです。 ID システムでは、どのユーザーが、どのような条件の下で (アクセス制御や認証の要件など)、アプリケーションにアクセスできるかが制御されます。 不測の事態のため、ユーザーの認証に対して 1 つ以上の認証要件またはアクセス制御要件を使用できないと、次の問題の一方または両方が組織に発生する可能性があります。

• 管理者のロックアウト: 管理者は、テナントまたはサービスを管理できません。
• ユーザーのロックアウト: ユーザーは、アプリまたはリソースにアクセスできません。

管理者ロックアウトのコンティンジェンシー

Microsoft は、組織が グローバル管理者 ロールが永続的に割り当てられる 2 つのクラウド専用の緊急アクセス アカウントを作成することを推奨しています。 このようなアカウントは高い特権を持っており、特定のユーザーには割り当てられません。 これらのアカウントは、通常のアカウントを使用できない、または他のすべての管理者が誤ってロックアウトされたという緊急または "ブレーク グラス" のシナリオに限定されます。これらのアカウントは、緊急アクセス アカウントに関するレコメンデーションに従って作成する必要があります。

ユーザー ロックアウトの軽減

ユーザー ロックアウトのリスクを緩和するには、アプリやリソースへのアクセス方法をユーザーが選択できる、複数の制御を備えた条件付きアクセス ポリシーを使用します。 たとえば、MFA でのサインイン、または、マネージド デバイスからのサインイン、または、企業ネットワークからのサインインをユーザーが選択できるようにすることで、いずれかのアクセス制御を利用できない場合でも、ユーザーには作業を続けるための他のオプションがあります。

Microsoft のレコメンデーション

組織の既存の条件付きアクセス ポリシーに次のアクセス制御を組み込みます。

• さまざまな通信チャネルに依存するユーザーごとに、複数の認証方法をプロビジョニングします。たとえば、Microsoft Authenticator アプリ (インターネット ベース)、OATH トークン (デバイス上で生成)、SMS (電話) が挙げられます。
• Windows 10 デバイスに Windows Hello for Business を展開し、デバイスのサインインから直接 MFA 要件を満たします。
• Microsoft Entra ハイブリッド参加 または Microsoft Intune を介して信頼できるデバイスを使用します。 信頼できるデバイスを使用すると、信頼できるデバイス自体でポリシーの強力な認証要件を満たすことができ、ユーザーに MFA チャレンジを行う必要がないので、ユーザー エクスペリエンスが向上します。 その場合、新しいデバイスを登録するとき、および信頼されていないデバイスからアプリやリソースにアクセスするときに、MFA が必要になります。
• 固定の MFA ポリシーの代わりに、ユーザーまたはサインインにリスクがあるときにアクセスを禁止する Microsoft Entra ID Protection のリスクに基づくポリシーを使用します。
• Microsoft Entra 多要素認証 NPS 拡張機能を使用して VPN アクセスを保護している場合、VPN ソリューションを SAML アプリ としてフェデレーションすることを検討し、以下に推奨されるようにアプリのカテゴリを決定します。

次の例では、アプリやリソースにアクセスするユーザーに対して回復性があるアクセス制御を提供するために作成する必要があるポリシーについて説明します。 この例では、アクセスを許可する対象のユーザーを含むセキュリティ グループ AppUsers、コア管理者を含むグループ CoreAdmins、緊急アクセス用アカウントを含むグループ EmergencyAccess が必要です。 この例のポリシー セットでは、AppUsers で選択されているユーザーが、信頼できるデバイスから接続している場合、または MFA などの強力な認証を提供する場合に、選択されたアプリへのアクセスをユーザーに許可します。 緊急アカウントとコア管理者は除外されます。

条件付きアクセス緩和ポリシーの設定:

• ポリシー 1:ターゲット グループ外のユーザーにアクセスをブロックする
  • ユーザーとグループ:すべてのユーザーを含める。 AppUsers、CoreAdmins、EmergencyAccess を除外する
  • クラウド アプリ:すべてのアプリを含める
  • 条件:(なし)
  • 許可の制御:ブロック
• ポリシー 2:MFA または信頼済みデバイスを要求して、AppUsers にアクセスを許可する。
  • ユーザーとグループ:AppUsers を含める。 CoreAdmins、EmergencyAccess を除外する
  • クラウド アプリ:すべてのアプリを含める
  • 条件:(なし)
  • 許可の制御: アクセスを許可する、多要素認証が必要、デバイスの準拠が必要。 複数の制御の場合:選択した制御のいずれかが必要。

ユーザー ロックアウトのコンティンジェンシー

または、組織でコンティンジェンシー ポリシーを作成することもできます。 コンティンジェンシー ポリシーを作成するには、ビジネス継続性、運用コスト、財務コスト、セキュリティ リスクの間のトレードオフ条件を定義する必要があります。 たとえば、ユーザーのサブセット、アプリのサブセット、クライアントのサブセット、または場所のサブセットに対してのみ、コンティンジェンシー ポリシーをアクティブにする場合があります。 コンティンジェンシー ポリシーでは、緩和策が実装されていない場合の中断時に、管理者とエンド ユーザーに対して、アプリとリソースへのアクセスが許可されます。 Microsoft では、コンティンジェンシー ポリシーを使用しない場合はレポート専用モードで有効にしておき、ポリシーをオンにすることが必要になった場合に備えて、管理者がそれらの潜在的な影響を監視できるようにすることをお勧めしています。

中断中の危険な状態を理解することは、リスクを軽減するのに役立ち、計画プロセスの重要な一部です。 コンティンジェンシー計画を作成するには、まず、組織での次のビジネス要件を決定します。

1. 事前にミッション クリティカルなアプリを決定します。低いリスク/セキュリティ体制であっても、アクセス権を付与する必要があるアプリは何ですか。 そのようなアプリの一覧を作成し、すべてのアクセス制御が失われた場合であってもそれらのアプリの実行を継続する必要があることを、他の利害関係者 (ビジネス、セキュリティ、法律、リーダーシップ) が全員同意していることを確認します。 最終的に次のカテゴリに該当する可能性があります。
   • カテゴリ 1: ミッション クリティカルなアプリ: 数分より長く使用不可能になることはできません。たとえば、組織の収益に直接影響するアプリなどです。
   • カテゴリ 2: 重要なアプリ: 数時間以内にアクセス可能になる必要があります。
   • カテゴリ 3: 優先順位の低いアプリ: 数日間停止しても許容されます。
2. カテゴリ 1 と 2 のアプリについては、許可するアクセス レベルの種類を事前に計画することを推奨します。
   • フル アクセスまたは制限されたセッション (ダウンロードの制限など) を許可しますか。
   • アプリ全体へのアクセスは許可せず、アプリの一部へのアクセスを許可しますか。
   • アクセス制御が復元されるまで、情報ワーカーのアクセスを許可し、管理者のアクセスをブロックしますか。
3. このようなアプリについては、Microsoft では、意図的に開くアクセス手段と閉じるアクセス手段を計画することも推奨しています。
   • ブラウザーのみのアクセスは許可し、オフライン データを保存できるリッチ クライアントはブロックしますか。
   • 企業ネットワーク内のユーザーに対してのみアクセスを許可し、外部のユーザーはブロックしますか。
   • 中断中は、特定の国または地域からのアクセスのみを許可しますか。
   • 代わりのアクセス制御が利用できない場合、特にミッション クリティカルなアプリの場合に、コンティンジェンシー ポリシーに対するポリシーを失敗させますか、それとも成功させますか?

Microsoft のレコメンデーション

コンティンジェンシー条件付きアクセス ポリシーは、Microsoft Entra 多要素認証、サードパーティ MFA、リスクベースまたはデバイスベースの制御を省略する バックアップ ポリシー です。 コンティンジェンシー ポリシーが有効になっている場合の予期しない中断を最小限に抑えるために、ポリシーを使用しないときはレポート専用モードのままにしておく必要があります。 管理者は、条件付きアクセスに関する分析情報のブックを使用して、コンティンジェンシー ポリシーの潜在的な影響を監視できます。 組織でコンティンジェンシー計画の有効化が決定されたときに、管理者はそのポリシーを有効にし、通常の制御に基づくポリシーを無効にできます。

• 1 つの資格情報の種類または 1 つのアクセス制御メカニズムの中断によってアプリへのアクセスが影響を受ける場合は、フォールバック ポリシーのセットを構成します。 サードパーティの MFA プロバイダーを必要とするアクティブなポリシーに対するバックアップとして、制御としてドメイン参加を必要とするポリシーをレポート専用状態で構成します。
• パスワードのガイダンス に関するホワイト ペーパーに記載の方法に従って、MFA が必要ないときに、パスワードを推測する悪意のあるユーザーのリスクを緩和します。
• Microsoft Entra セルフサービス パスワード リセット (SSPR) および Microsoft Entra パスワード保護 をデプロイし、ユーザーが禁止する一般的なパスワードや用語を使用しないようにします。
• 単にフル アクセスにフォールバックするのではなく、特定の認証レベルが満たされていない場合、アプリ内でアクセスを制限するポリシーを使用します。 例:
  • Exchange および SharePoint に制限されたセッション要求を送信するバックアップ ポリシーを構成します。
  • 組織で Microsoft Defender for Cloud Apps を使用している場合、Defender for Cloud Apps を使用するポリシーにフォールバックし、読み取り専用アクセスは許可するが、アップロードは許可しないことを検討してください。
• 中断中にポリシーを簡単に見つけられるよう、ポリシーに名前を付けます。 ポリシー名には次の要素を含めます。
  • ポリシーのラベル番号。
  • 表示するテキスト。このポリシーは緊急時のみを対象としています。 次に例を示します。ENABLE IN EMERGENCY
  • 適用される中断。 次に例を示します。During MFA Disruption
  • ポリシーをアクティブ化する順序を示す、シーケンス番号。
  • 適用されるアプリ。
  • 適用されるコントロール。
  • 必要な条件。

コンティンジェンシー ポリシーの場合、この命名基準は次のようになります。

EMnnn - ENABLE IN EMERGENCY: [Disruption][i/n] - [Apps] - [Controls] [Conditions]

次に例を示します。例 A - ミッション クリティカルなコラボレーション アプリへのアクセスを復元するコンティンジェンシー条件付きアクセス ポリシーは、企業の一般的なコンティンジェンシーです。 このシナリオの組織では、一般に、すべての Exchange Online と SharePoint Online のアクセスには MFA が必要であり、このケースでの中断は、顧客の MFA プロバイダーが停止状態にあることです (Microsoft Entra 多要素認証、オンプレミス MFA プロバイダー、サード パーティ MFA を問いません)。 このポリシーでは、信頼できる Windows デバイスからアプリへの、特定の対象ユーザーのアクセスを、信頼できる企業ネットワークからアプリにアクセスしている場合にのみ許可することによって、この停止状態を緩和します。 また、緊急アカウントとコア管理者はこれらの制限から除外されます。 これにより、対象ユーザーは Exchange Online と SharePoint Online へのアクセスが許可されますが、その他のユーザーは障害のためにアプリにまだアクセスできません。 この例では、名前付きのネットワークの場所 CorpNetwork、対象ユーザーを含むセキュリティ グループ ContingencyAccess、コア管理者を含むグループ CoreAdmins、緊急アクセス用アカウントを含むグループ EmergencyAccess が必要です。 コンティンジェンシーでは、必要なアクセスを提供するために 4 つのポリシーが必要です。

例 A - ミッションクリティカルなコラボレーション アプリへのアクセスを復元するコンティンジェンシー条件付きアクセス ポリシー:

• ポリシー 1:Exchange と SharePoint に対するドメイン参加済みデバイスが必要
  • 名前: EM001 - 緊急時に有効: MFA 中断 [1/4] - Exchange SharePoint - Microsoft Entra ハイブリッド参加が必要
  • ユーザーとグループ:ContingencyAccess を含める。 CoreAdmins、EmergencyAccess を除外する
  • クラウド アプリ:Exchange Online と SharePoint Online
  • 条件:Any
  • 許可の制御:ドメインへの参加が必要
  • 状態:レポート専用
• ポリシー 2:Windows 以外のプラットフォームをブロック
  • 名前:EM002 - ENABLE IN EMERGENCY:MFA Disruption[2/4] - Exchange SharePoint - Block access except Windows
  • ユーザーとグループ:すべてのユーザーを含める。 CoreAdmins、EmergencyAccess を除外する
  • クラウド アプリ:Exchange Online と SharePoint Online
  • 条件:デバイス プラットフォームは、Windows 以外のすべてのプラットフォームを含む
  • 許可の制御:ブロック
  • 状態:レポート専用
• ポリシー 3:CorpNetwork 以外のネットワークをブロック
  • 名前:EM003 - ENABLE IN EMERGENCY:MFA Disruption[3/4] - Exchange SharePoint - Block access except Corporate Network
  • ユーザーとグループ:すべてのユーザーを含める。 CoreAdmins、EmergencyAccess を除外する
  • クラウド アプリ:Exchange Online と SharePoint Online
  • 条件:場所は、CorpNetwork 以外のすべての場所を含む
  • 許可の制御:ブロック
  • 状態:レポート専用
• ポリシー 4:EAS を明示的にブロックする
  • 名前:EM004 - ENABLE IN EMERGENCY:MFA Disruption[4/4] - Exchange - Block EAS for all users
  • ユーザーとグループ:すべてのユーザーを含める
  • クラウド アプリ:Exchange Online を含める
  • 条件:クライアント アプリ:Exchange Active Sync
  • 許可の制御:ブロック
  • 状態:レポート専用

アクティブ化の順序:

1. 既存の MFA ポリシーから ContingencyAccess、CoreAdmins、EmergencyAccess を除外します。 ContingencyAccess に含まれるユーザーが SharePoint Online と Exchange Online にアクセスできることを確認します。
2. ポリシー 1 を有効化: 除外グループに含まれないドメイン参加済みデバイスのユーザーが、Exchange Online と SharePoint Online にアクセスできることを確認します。 除外グループに含まれるユーザーが、任意のデバイスから SharePoint Online と Exchange にアクセスできることを確認します。
3. ポリシー 2 を有効化: 除外グループに含まれないユーザーが、自分のモバイル デバイスから SharePoint Online と Exchange Online にアクセスできないことを確認します。 除外グループに含まれるユーザーが、任意のデバイス (Windows/iOS/Android) から SharePoint と Exchange にアクセスできることを確認します。
4. ポリシー 3 を有効化: 除外グループに含まれないユーザーが、 ドメイン参加済みコンピューターであっても、企業ネットワーク外から SharePoint および Exchange にアクセスできないことを確認します。 除外グループに含まれるユーザーが、任意のネットワークから SharePoint と Exchange にアクセスできることを確認します。
5. ポリシー 4 を有効化: すべてのユーザーが、モバイル デバイス上のネイティブ メール アプリケーションから Exchange Online にアクセスできないことを確認します。
6. SharePoint Online と Exchange Online に対する既存の MFA ポリシーを無効にします。

次の例、例 B - Salesforce へのモバイル アクセスを許可するコンティンジェンシー条件付きアクセス ポリシーでは、ビジネス アプリのアクセスを復元します。 このシナリオの顧客は、通常、営業社員に対し、準拠しているモバイル デバイスから (Microsoft Entra ID でシングルサイン オンを構成された) Salesforce へのアクセスのみを許可する必要があります。 このケースでの中断は、デバイスのコンプライアンスの評価に関する問題が発生しているためであり、営業チームが取引成立のために Salesforce にアクセスする必要がある時間的制約のある場面で障害が発生しています。 これらのコンティンジェンシー ポリシーでは、取引成立の流れを途切れさせず、ビジネスが中断しないよう、モバイル デバイスから Salesforce へのクリティカルなユーザー アクセスが許可されます。 この例では、SalesforceContingency にアクセスを維持する必要があるすべての営業社員が含まれ、SalesAdmins に Salesforce の必要な管理者が含まれます。

例 B - コンティンジェンシー条件付きアクセス ポリシー:

• ポリシー 1:SalesContingency チームに含まれないすべてのユーザーをブロックする
  • 名前:EM001 - ENABLE IN EMERGENCY:Device Compliance Disruption[1/2] - Salesforce - Block All users except SalesforceContingency
  • ユーザーとグループ:すべてのユーザーを含める。 SalesAdmins と SalesforceContingency を除外する
  • クラウド アプリ:Salesforce。
  • 条件:なし
  • 許可の制御:ブロック
  • 状態:レポート専用
• ポリシー 2:(攻撃対象領域を減らすため) モバイル以外の任意のプラットフォームからのセールス チームをブロックする
  • 名前:EM002 - ENABLE IN EMERGENCY:Device Compliance Disruption[2/2] - Salesforce - Block All platforms except iOS and Android
  • ユーザーとグループ:SalesforceContingency を含める。 SalesAdmins を除外する
  • クラウド アプリ:Salesforce
  • 条件:デバイス プラットフォームは、iOS と Android 以外のすべてのプラットフォームを含む
  • 許可の制御:ブロック
  • 状態:レポート専用

アクティブ化の順序:

1. Salesforce に対する既存のデバイス コンプライアンス ポリシーから SalesAdmins と SalesforceContingency を除外します。 SalesforceContingency グループに含まれるユーザーが Salesforce にアクセスできることを確認します。
2. ポリシー 1 を有効化: SalesContingency に含まれないユーザーが Salesforce にアクセスできないことを確認します。 SalesAdmins と SalesforceContingency に含まれるユーザーが Salesforce にアクセスできることを確認します。
3. ポリシー 2 を有効化: SalesContingency グループに含まれるユーザーが、Windows/Mac のラップトップからは Salesforce にアクセスできないが、モバイル デバイスからはアクセスできることを確認します。 SalesAdmin が任意のデバイスから Salesforce にアクセスできることを確認します。
4. Salesforce に対する既存のデバイス コンプライアンス ポリシーを無効にします。

オンプレミス リソースからのユーザー ロックアウト用のコンティンジェンシー (NPS 拡張機能)

Microsoft Entra 多要素認証 NPS 拡張機能を使用して VPN アクセスを保護している場合、VPN ソリューションを SAML アプリ としてフェデレーションすることを検討し、以下に推奨されるようにアプリのカテゴリを決定します。

VPN やリモート デスクトップ ゲートウェイなどのオンプレミス リソースを MFA を使用して保護するために Microsoft Entra 多要素認証 NPS 拡張機能をデプロイしている場合は、緊急時に MFA を無効にする準備ができているかどうかを事前に検討する必要があります。

このケースでは、NPS 拡張機能を無効にすることができ、その結果、NPS サーバーではプライマリ認証のみが検証され、ユーザーに MFA は適用されません。

NPS 拡張機能を無効にする:

• HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters レジストリ キーをバックアップとしてエクスポートします。
• Parameters キーではなく、"AuthorizationDLLs" と "ExtensionDLLs" のレジストリ値を削除します。
• ネットワーク ポリシー サービス (IAS) を再起動して変更を有効にします。
• VPN のプライマリ認証が成功するかどうかを確認します。

サービスが回復し、ユーザーに再び MFA を適用する準備が整えば、NPS 拡張機能を有効にします。

• バックアップの HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters からレジストリ キーをインポートします。
• ネットワーク ポリシー サービス (IAS) を再起動して変更を有効にします。
• VPN のプライマリ認証とセカンダリ認証が正常に実行されるかどうかを確認します。
• NPS サーバーと VPN ログを見直して、緊急期間中にサインインしたユーザーを特定します。

フェデレーションされている場合、またはパススルー認証を使用している場合でも、パスワード ハッシュ同期をデプロイする

ユーザーのロックアウトは、次の条件が満たされる場合にも発生します。

• 組織で、パススルー認証またはフェデレーションによるハイブリッド ID ソリューションが使用されている。
• オンプレミスの ID システム (Active Directory、AD FS、依存コンポーネントなど) を使用できない。

回復性を向上させるには、組織でパスワード ハッシュ同期を有効にする必要があります。そうすれば、オンプレミスの ID システムがダウンした場合は、パスワード ハッシュ同期の使用に切り替えることができます。

Microsoft のレコメンデーション

組織でフェデレーションまたはパススルー認証が使用されているかどうかにかかわらず、Microsoft Entra Connect ウィザードを使用してパスワード ハッシュ同期を有効にします。

中断の間

緩和プランを実装することを選択した場合、単一のアクセス制御の中断を自動的に回避することができます。 一方、コンティンジェンシー プランを作成することを選択した場合は、アクセス制御の中断中、コンティンジェンシー ポリシーをアクティブ化することができます。

1. 対象ユーザーに対して特定ネットワークから特定アプリへのアクセスを許可するコンティンジェンシー ポリシーを有効にします。
2. 通常の制御に基づくポリシーを無効にします。

Microsoft のレコメンデーション

中断の間に軽減とコンティンジェンシーのどちらを使用するかによっては、組織でパスワードだけによるアクセスが許可される可能性があります。 保護がないことは、慎重に検討すべき重大なセキュリティ リスクです。 組織では次のようにする必要があります。

1. 変更管理戦略の一環として、アクセス制御が完全に動作するようになったら直ちに、実装したコンティンジェンシーをロールバックできるように、すべての変更と以前の状態を文書化します。
2. MFA を無効にしている間は、悪意のあるユーザーがパスワード スプレーやフィッシング攻撃を使用してパスワードを取得しようとするものと想定します。 また、悪意のあるユーザーが、以前はどのリソースにもアクセスが許可されなかったパスワードを既に入手していて、この期間にアクセスを試みるかもしれません。 管理職などの重要なユーザーについては、MFA を無効にする前に、それらのユーザーのパスワードをリセットすることで、このリスクを軽減することができます。
3. すべてのサインイン アクティビティをアーカイブし、MFA が無効にされていた期間に誰がアクセスしたかを識別します。
4. この期間中に報告されたすべてのリスク検出をトリアージします。

中断の後

中断の原因となったサービスが復元された後、アクティブ化されたコンティンジェンシー計画の一部として行われた変更を元に戻します。

1. 通常のポリシーを有効にします
2. コンティンジェンシー ポリシーをレポート専用モードに戻すことができないようにします。
3. 中断中に行って文書化した他のすべての変更をロールバックします。
4. 緊急アクセス用アカウントを使用した場合は、緊急アクセス用アカウントの手順の一部として、忘れずに資格情報を再生成し、新しい資格情報の詳細を物理的にセキュリティ保護します。
5. 不審なアクティビティのため、中断後も引き続き報告されたすべてのリスク検出をトリアージします。
6. 一連のユーザーを対象に発行されたすべての更新トークンを取り消し ます。 すべての更新トークンの取り消しは中断中に使用された特権アカウントについて重要であり、そうすることで、強制的に再認証が行われ、復元されたポリシーの制御に対応します。

緊急時のオプション

緊急事態が発生し、組織で以前に緩和策またはコンティンジェンシー プランを実施したことがない場合で、既に条件付きアクセス ポリシーを使用して MFA を適用しているときは、ユーザー ロックアウトのコンティンジェンシー セクションのレコメンデーションに従います。 組織でユーザーごとの MFA レガシ ポリシーを使用している場合は、次の代替手段を検討します。

• 企業ネットワークに送信 IP アドレスがある場合は、それを信頼できる IP として追加し、企業ネットワークに対してのみ認証を有効にできます。
• 送信 IP アドレスのインベントリがない場合、または企業ネットワークの内部と外部でアクセスを有効にする必要があった場合は、0.0.0.0/1 と 128.0.0.0/1 を指定することにより、IPv4 アドレス空間全体を信頼できる IP アドレスとして追加できます。

さらに学ぶ

• Microsoft Entra 認証に関するドキュメント
• Microsoft Entra ID で緊急アクセス用管理アカウントを管理する
• Microsoft Entra ID でネームド ロケーションを構成する
• Microsoft Entra ハイブリッド参加済みデバイスを構成する方法
• Windows Hello for Business のデプロイ ガイド
  • パスワードのガイダンス - Microsoft Research
• Microsoft Entra 条件付きアクセスの条件とは
• Microsoft Entra 条件付きアクセスのアクセス制御とは
• 条件付きアクセスのレポート専用モードとは