すべてのユーザーに多要素認証を要求する
Microsoft の ID セキュリティ責任者、Alex Weinert は、パスワードは関係ないに関する彼のブログ投稿で次のように言っています。
「重要なのはパスワードではなく、MFA です!」 私たちの研究によると、MFA を使用すると、アカウントは 99.9% 以上侵害されにくくなります。
認証強度
この記事のガイダンスは、組織が認証強度を使用して環境の MFA ポリシーを作成するのに役立ちます。 Microsoft Entra ID には、3 つの組み込みの認証強度が用意されています。
- 多要素認証の強度 (制限の緩い) がこの記事で推奨されます
- パスワードレス MFA 強度
- フィッシングに強い MFA 強度 (最も制限が厳しい)
組み込み強度のいずれかを使用するか、必要な認証方法に基づいてカスタム認証強度を作成できます。
外部ユーザーのシナリオでは、ユーザーがホーム テナントまたはリソース テナントのどちらで MFA を完了しているかにより、リソース テナントが受け入れることができる MFA 認証方法が異なります。 詳細については、外部ユーザーの認証強度に関するページを参照してください。
ユーザーの除外
条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。
- ポリシー構成の誤りによるロックアウトを防ぐための緊急アクセスまたはブレークグラス アカウント。 すべての管理者がロックアウトされるというごくまれなシナリオにおいて、緊急アクセス用管理アカウントは、ログインを行い、アクセスを復旧させるための手順を実行するために使用できます。
- 詳細は、「Microsoft Entra ID で緊急アクセス用アカウントの管理」の記事を参照してください。
- サービス アカウントとサービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにログインするときにも使用されます。 サービス プリンシパルによる呼び出しは、ユーザーにスコーピングされる条件付きアクセス ポリシーによってブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
- 組織がスクリプトまたはコードでこれらのアカウントを使用している場合、マネージド ID に置き換えることを検討してください。
テンプレートのデプロイ
組織は、このポリシーをデプロイするのに以下に示す手順を使用するか、条件付きアクセス テンプレートを使用するかを選ぶことができます。
条件付きアクセス ポリシーを作成する
次の手順は、認証強度ポリシーを使用してすべてのユーザーに対して多要素認証の実行を必須にする条件付きアクセス ポリシーを作成するのに役立ちます。
警告
外部認証方法を使用する場合、現在は認証強度と互換性がないため、多要素認証を要求するという許可の制御を使用する必要があります。
- 条件付きアクセス管理者以上として Microsoft Entra 管理センターにサインインします。
- [保護]>[条件付きアクセス]>[ポリシー] に移動します。
- [新しいポリシー] を選択します。
- ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
- [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
- [Include](含める) で、 [すべてのユーザー] を選択します。
- [対象外] で、[ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
- ゲスト ユーザーをゲスト ユーザー固有のポリシーで対象にしている場合は、そのゲスト ユーザーを除外することを選択できます。
- [ターゲット リソース]>[リソース] (以前の [クラウド アプリ])>[含める] で、[すべてのリソース] (以前の [すべてのクラウド アプリ]) を選択します。
- [除外] で、多要素認証を必要としないアプリケーションを選択します。
- [アクセス制御]>[許可] で、 [アクセス権の付与] を選択します。
- [認証強度を要求する] を選択し、一覧から組み込みの [多要素認証強度] を選びます。
- [選択] を選択します。
- 設定を確認し、 [ポリシーの有効化] を [レポート専用] に設定します。
- [作成] を選択して、ポリシーを作成および有効化します。
管理者は、レポート専用モードを使用して設定を確認したら、[ポリシーの有効化] トグルを [レポートのみ] から [オン] に移動できます。
ネームド ロケーション
組織では、条件付きアクセス ポリシーにネームド ロケーションと呼ばれる既知のネットワークの場所を組み込むことができます。 こうしたネームド ロケーションには、メイン オフィスの場所のような信頼された IP ネットワークを含めることができます。 ネームド ロケーションの構成の詳細については、Microsoft Entra 条件付きアクセスの場所条件の概要に関する記事を参照してください。
上記のポリシーの例では、組織は自社のネットワークからクラウド アプリにアクセスする場合に多要素認証を必要としないことを選択できます。 この場合、次の構成をポリシーに追加できます。
- [割り当て] で、[ネットワーク] を選択します。
- [はい] を構成します。
- [任意のネットワークまたは場所] を含めます。
- [すべての信頼できるネットワークと場所] を除外します。
- ポリシーの変更を保存します。
アプリケーションの除外
組織には、使用中のクラウド アプリケーションが多数ある可能性があります。 これらのアプリケーションすべてに、同等のセキュリティが必要なわけではありません。 たとえば、給与と勤怠のアプリケーションには 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 で使用できます。