Microsoft マネージド ポリシー
2023 年 10 月の Microsoft Digital Defense Report で言及があったように
...デジタルの平和に対する脅威により、テクノロジへの信頼が低下し、あらゆるレベルでサイバー防御を改善する緊急の必要性が強調されました。
...Microsoft では、10,000 人を超えるセキュリティ専門家が毎日 65 兆を超えるシグナルを分析しており、サイバーセキュリティにおける最も影響力のある分析情報の一部を推進しています。 協力することで、革新的なアクションと集団防御を通じて、サイバー回復力を構築することができます。
この作業の一環として、Microsoft マネージド ポリシーを世界中の Microsoft Entra テナントで使用できるようにします。 これらの簡素化された条件付きアクセス ポリシーでは、多要素認証が必要となるアクションが実行されます。最近の調査によれば、これによって侵害のリスクを 99% 以上低減できます。
最低でも条件付きアクセス管理者ロールが割り当てられている管理者は、[保護]>> の下にある [Microsoft Entra 管理センター] でこれらのポリシーを参照できます。
管理者は、ポリシーの [状態] (オン、オフ、またはレポート専用) と [除外 ID] (ユーザー、グループ、ロール) を [編集] できます。 組織では、他の条件付きアクセス ポリシーと同じように、これらのポリシーから中断アクセス アカウントまたは緊急アクセス アカウントを除外する必要があります。 Microsoft マネージド バージョンで許可されている基本ポリシーよりも多くの変更を加える必要がある場合には、組織はこれらのポリシーを複製できます。
これらのポリシーが [レポート専用] の状態のままである場合は、テナントで導入されてから 90 日以内に Microsoft によって有効にされます。 管理者は、これらのポリシーをすぐにオンにするか、ポリシーの状態をオフに設定してオプトアウトするかを選択できます。 お客様には、ポリシーが有効になる 28 日前に、電子メールと メッセージ センター による投稿で通知が行われます。
Note
場合によっては、ポリシーが 90 日より早く有効になる場合があります。 これがテナントに適用される場合は、Microsoft マネージド ポリシーに関して受信した電子メールと M365 メッセージ センターの投稿に記載されます。 また、Microsoft 管理センターのポリシーの詳細にも記載されます。
ポリシー
これらの Microsoft マネージド ポリシーを使用すると、管理者はユーザーを除外したり、[レポート専用] モードから [オン] または [オフ] に切り替えたりするなどの簡単な変更を行うことができます。 組織は、Microsoft マネージド ポリシーの名称変更や削除を行うことはできません。 管理者が条件付きアクセス ポリシーの扱いに慣れれば、ポリシーを複製してカスタム バージョンを作成することもできます。
脅威は時間と共に進化しているため、Microsoft では今後、これらのポリシーを変更して、新機能の活用や機能の改善を行う可能性があります。
Microsoft 管理ポータルにアクセスする管理者に対する多要素認証
このポリシーは、高い特権をもつと見なされる 14 の管理者ロールを対象としています。これらは Microsoft 管理ポータル グループにアクセスするロールであり、これに対しては多要素認証の実行が要求されます。
このポリシーは、セキュリティの既定値群が有効になっていない Microsoft Entra ID P1 テナントおよび P2 テナントを対象とします。
ヒント
多要素認証を必要とする Microsoft が管理するポリシーは、2024 年 10 月に段階的なロールアウトを開始した 2024 に行われた Azure サインインの必須多要素認証の発表とは異なります。 その適用の詳細については、「Azure およびその他の管理ポータルの必須多要素認証の計画」を参照してください。
ユーザーごとの多要素認証ユーザーに対する多要素認証
このポリシーは、ユーザーごとの MFA のユーザーをカバーしています。これは Microsoft が推奨しなくなった構成です。 条件付きアクセスは、多くの追加機能を備えた、優れた管理者エクスペリエンスを提供します。 すべての MFA ポリシーを条件付きアクセスに統合すると、MFA を要求する対象を絞り込むことができ、セキュリティ態勢を維持しながらエンド ユーザーの抵抗を軽減できます。
このポリシーの対象は次のとおりです。
- Microsoft Entra ID P1 と P2 でライセンスを取得した組織のユーザー
- セキュリティの既定値が有効になっていない組織
- MFA がユーザーごとに有効または適用された数が500人未満の組織
このポリシーをより多くのユーザーに適用するには、ポリシーを複製して割り当てを変更します。
ヒント
上部にある [編集] 鉛筆を使用して、Microsoft が管理するユーザーごとの多要素認証ポリシーを変更すると、[更新に失敗しました] というエラーが発生する可能性があります。 この問題を回避するには、ポリシーの [除外された ID] セクションの [編集] を選びます。
危険なサインインに対する多要素認証と再認証
このポリシーは、すべてのユーザーを対象とし、リスクの高いサインインを検出するときに MFA と再認証を必要とします。この場合のリスクが高いということは、ユーザーがサインインした方法が通常とは異なることを意味します。 このようなリスクの高いサインインには: 非常に異常な移動、パスワード スプレー攻撃、トークン リプレイ攻撃などがあります。 これらのリスク定義の詳細については、「リスク検出とは」に関する記事を参照してください。
このポリシーは、セキュリティの既定値群が有効になっていない Microsoft Entra ID P2 テナントを対象とします。
- P2 ライセンスが MFA に登録されたアクティブ ユーザーの合計数以上の場合、ポリシーはすべてのユーザーに適用されます。
- MFA に登録されたアクティブ ユーザーが P2 ライセンスを超えた場合は、使用可能な P2 ライセンスに基づいて制限付きセキュリティ グループにポリシーを作成して割り当てます。 ポリシーのセキュリティ グループのメンバーシップを変更できます。
攻撃者がアカウントを引き継ぐのを防ぐために、Microsoft は危険なユーザーが MFA に登録することを許可しません。
セキュリティの既定値群のポリシー
セキュリティの既定値群を使用してアップグレードする場合は、次のポリシーを使用できます。
レガシー認証をブロックする
このポリシーは、レガシ認証プロトコルがアプリケーションにアクセスするのをブロックします。 レガシ認証とは、次によって行われる認証要求を指します。
- 先進認証を使用していないクライアント (Office 2010 クライアントなど)
- IMAP、SMTP、POP3 などの古いメール プロトコルを使用しているクライアント
- レガシ認証を使用したサインインの試行はすべてブロックされます。
セキュリティ侵害とされるサインイン試行の多くはレガシ認証です。 レガシ認証では多要素認証がサポートされていないため、攻撃者は古いプロトコルを使用して MFA 要件を回避できます。
Azure の管理に多要素認証を要求する
このポリシーは、次のような Azure Resource Manager API を使用して管理されているさまざまな Azure サービスにアクセスしようとしているすべてのユーザーを対象としています。
- Azure portal
- Microsoft Entra 管理センター
- Azure PowerShell
- Azure CLI
これらのリソースのいずれかにアクセスしようとすると、ユーザーはアクセスを取得する前に MFA を完了する必要があります。
管理者に多要素認証を要求する
このポリシーは、高い特権を持つと見なされる 14 の管理者ロールのいずれかを持つすべてのユーザーを対象としています。 これらの高い特権を持つアカウントには強力な権限があるため、アプリケーションにサインインするたびに MFA が必要になります。
すべてのユーザーに多要素認証を要求する
このポリシーは組織内のすべてのユーザーを対象としており、サインインするたびに MFA を要求します。 ほとんどの場合、セッションはデバイスに保持され、ユーザーが別のアプリケーションと対話するときに MFA を完了する必要はありません。
ポリシーの効果を確認する方法
管理者は、[サインインに対するポリシーの影響] セクションを参照して、環境内のポリシーの効果の概要を簡単に確認できます。
管理者は、Microsoft Entra サインイン ログを詳細に確認して、組織内でこれらのポリシーが機能していることを確認できます。
- Microsoft Entra 管理センターにレポート閲覧者以上でサインインしてください。
- [ID]>[監視と正常性]>[サインイン ログ] の順に移動します。
- 確認する特定のサインインを見つけます。 フィルターと列を追加または削除して、不要な情報を除外します。
- 次のフィルターを追加して、範囲を絞り込みます。
- 関連付け ID: 調査対象の特定のイベントがある場合。
- 条件付きアクセス: ポリシーの失敗/成功を表示します。 フィルターの範囲を設定して、失敗のみを表示するように結果を制限します。
- ユーザー名: 特定のユーザーに関連する情報を表示します。
- 日付: 対象の期間に範囲を設定します。
- 次のフィルターを追加して、範囲を絞り込みます。
- ユーザーのサインインに対応するサインイン イベントが見つかったら、[条件付きアクセス] タブを選択します。[条件付きアクセス] タブには、サインインが中断される原因となった特定のポリシーが表示されます。
- さらに調査するには、 [ポリシー名] をクリックして、ポリシーの構成にドリルダウンします。 [ポリシー名] をクリックすると、選択したポリシーのポリシー構成ユーザー インターフェイスが表示され、レビューおよび編集できます。
- 条件付きアクセス ポリシーの評価に使用された クライアント ユーザーとデバイスの詳細は、サインイン イベントの [基本情報] 、 [場所] 、 [デバイス情報] 、 [認証の詳細] 、 [追加情報] タブでも参照できます。
一般的な質問
条件付きアクセスとは
条件付きアクセスは、組織がリソースにアクセスするときにセキュリティ要件を適用できるようにする Microsoft Entra の機能です。 条件付きアクセスは一般的に、多要素認証、デバイス構成、ネットワークの場所の要件を適用するために使用されます。
これらのポリシーは、論理的な 'if-then' ステートメントと考えることができます。
If 割り当て (ユーザー、リソース、条件) が true の場合は、then ポリシーのアクセス制御 (許可またはセッション) を適用します。 If Microsoft 管理ポータルのいずれかにアクセスする管理者である場合は、then 多要素認証を実行して、実際に自分であることを証明する必要があります。
さらに変更を加えたい場合はどうすればよいですか?
管理者は、ポリシー一覧ビューの [複製] ボタンを使用してポリシーを複製して、これらのポリシーをさらに変更できます。 この新しいポリシーは、他の条件付きアクセス ポリシーと同じ方法で、Microsoft の推奨する位置から開始して構成できます。 これらの変更によってセキュリティ体制を誤って下げないように注意してください。
これらのポリシーの対象となる管理者ロールは何ですか?
- グローバル管理者
- アプリケーション管理者
- 認証管理者
- 課金管理者
- クラウド アプリケーション管理者
- 条件付きアクセス管理者
- Exchange 管理者
- ヘルプデスク管理者
- パスワード管理者
- 特権認証管理者
- 特権ロール管理者
- セキュリティ管理者
- SharePoint 管理者
- ユーザー管理者
多要素認証に別のソリューションを使用する場合
多要素認証 外部認証方法を使用して完了、Microsoft が管理するポリシーの MFA 要件を満たします。
フェデレーション ID プロバイダー (IdP) を介して多要素認証が完了すると、構成によっては Microsoft Entra ID MFA 要件を満たす場合があります。 詳細については、「フェデレーション IdPからの MFA 要求を使用して Microsoft Entra ID 多要素認証 (MFA) コントロールを満たす」を参照してください。
Certificate-Based 認証を使用する場合
テナントの Certificate-Based 認証 (CBA) の構成に応じて、単一要素または多要素として機能できます。
- 組織で CBA が単一要素として構成されている場合、ユーザーは MFA を満たすために 2 つ目の認証方法を使用する必要があります。 単一要素 CBA を使用して MFA に対して許可される認証方法の組み合わせの詳細については、単一要素証明書ベースの認証を使用した MFA の
を参照してください。 - 組織で CBA が多要素として構成されている場合、ユーザーは CBA 認証方法で MFA を完了できます。
Note
CBA は Microsoft Entra ID で MFA 対応の方法と見なされるため、CBA 認証方法のスコープ内のユーザーは、MFA を使用して新しい認証方法を登録する必要があります。 他の登録済み認証方法を使用せずに単一要素 CBA ユーザーに MFA を登録するには、「オプション」を参照してください。単一要素証明書を使用して MFA 機能を取得するオプション。
カスタム コントロールを使用する場合
カスタム コントロールは、多要素認証要求要件を満たしていません。 組織でカスタム コントロールを使用している場合は、カスタム コントロールの代わりに外部認証方法に移行すべきです。 外部認証プロバイダーは、外部認証方法をサポートし、統合に必要な構成ガイダンスを提供する必要があります。