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