一般的な条件付きアクセス ポリシー: すべてのユーザーに対して MFA を必須にする

Microsoft の ID セキュリティ責任者、Alex Weinert は彼のブログ投稿「Your Pa$$word doesn't matter」で次のように言っています。

「重要なのはパスワードではなく、MFA です!」 私たちの研究によると、MFA を使用すると、アカウントは 99.9% 以上侵害されにくくなります。

この記事のガイダンスは、組織が環境に適した MFA ポリシーを作成する際に役立ちます。

ユーザーの除外

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

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

アプリケーションの除外

組織には、使用中のクラウド アプリケーションが多数あります。 これらのアプリケーションすべてで、同等のセキュリティが必要なわけではありません。 たとえば、給与と勤怠のアプリケーションには MFA が必要でも、カフェのアプリケーションでは必要ない可能性があります。 管理者は、ポリシーから特定のアプリケーションを除外することを選択できます。

サブスクリプションのライセンス認証

サブスクリプションのアクティブ化機能を使用して、ユーザーが Windows のあるバージョンから別のものに "ステップアップ" できるようにし、条件付きアクセス ポリシーを使用してアクセスを制御する組織では、[除外されたクラウド アプリの選択] を使用して、次のいずれかのクラウド アプリを条件付きアクセス ポリシーから除外する必要があります。

• ユニバーサル ストア サービス API と Web アプリケーション、AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f。

• ビジネス向け Windows ストア、AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f。

アプリ ID は両方のインスタンスで同じですが、クラウド アプリの名前はテナントによって異なります。

条件付きアクセス ポリシーでの除外の構成の詳細については、「アプリケーションの除外」を参照してください。

デバイスが長時間オフラインになっているとき、この条件付きアクセスの除外が適用されていない場合、デバイスは自動的に再アクティブ化されないことがあります。 この条件付きアクセスの除外を設定すると、サブスクリプションのアクティブ化が引き続きシームレスに機能するようになります。

KB5034848 以降の Windows 11 バージョン 23H2 から、サブスクリプションのアクティブ化を再アクティブ化する必要があるときに、トースト通知による認証を求められます。 トースト通知には、次のメッセージが表示されます。

お使いのアカウントには認証が必要です

職場または学校アカウントにサインインして、情報を確認してください。

また、[アクティブ化] ウィンドウに次のメッセージが表示される場合があります。

職場または学校アカウントにサインインして、情報を確認してください。

通常、認証のプロンプトは、デバイスが長時間オフラインになっている場合に発生します。 この変更により、KB5034848 以降の Windows 11 バージョン 23H2 の条件付きアクセス ポリシーを除外する必要がなくなります。 トースト通知によるユーザー認証のプロンプトが望ましくない場合でも、条件付きアクセス ポリシーは KB5034848 以降の Windows 11 バージョン 23H2 で使用できます。

テンプレートのデプロイ

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

条件付きアクセス ポリシーを作成する

次の手順は、すべてのユーザーに対して多要素認証の実行を必須にする条件付きアクセス ポリシーを作成するのに役立ちます。

1. 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
2. 保護>条件付きアクセス を参照します。
3. [新しいポリシーの作成] を選択します。
4. ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
5. [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
   1. [Include](含める) で、 [すべてのユーザー] を選択します。
   2. [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
6. [ターゲット リソース]>[クラウド アプリ]>[対象] で、[すべてのクラウド アプリ] を選択します。
   1. [除外] で、多要素認証を必要としないアプリケーションを選択します。
7. [アクセス制御]>[許可] で、[アクセス権の付与]、[多要素認証を要求する] の順に選択し、[選択する] を選択します。
8. 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
9. [作成] を選択して、ポリシーを作成および有効化します。

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

ネームド ロケーション

組織では、条件付きアクセス ポリシーに「ネームド ロケーション」と呼ばれる既知のネットワークの場所を組み込むことができます。 こうしたネームド ロケーションには、メイン オフィスの場所のような信頼できる IPv4 ネットワークを含めることができます。 ネームド ロケーションの構成の詳細については、Microsoft Entra 条件付きアクセスの場所条件の概要に関する記事を参照してください。

上記のポリシーの例では、組織は自社のネットワークからクラウド アプリにアクセスする場合に多要素認証を必要としないことを選択できます。 この場合、次の構成をポリシーに追加できます。

1. [割り当て] で、 [条件]>[場所] を選択します。
   1. [はい] を構成します。
   2. [任意の場所] を含めます。
   3. [すべての信頼できる場所] を除外します。
   4. [Done] を選択します。
2. [Done] を選択します。
3. ポリシーの変更を保存します。

次のステップ

条件付きアクセス テンプレート

条件付きアクセスのレポート専用モードを使用して、新しいポリシー決定の結果を判断します。