Microsoft 365 組織の一般的なセキュリティ ポリシー
組織では、組織に Microsoft 365 を展開する際に配慮すべきことが多くあります。 この記事で参照されている条件付きアクセス、アプリ保護、デバイス コンプライアンス ポリシーは、Microsoft の推奨事項とゼロ トラストの 3 つの基本原則に基づいています。
- 明示的に検証する
- 最小特権を使う
- 侵害を想定する
組織は、これらのポリシーをそのまま使用することも、ニーズに合わせてカスタマイズすることもできます。 可能であれば、運用ユーザーにロールアウトする前に、非運用環境でポリシーをテストします。 テストは、ユーザーに与える可能性がある影響を特定して伝えるために不可欠です。
これらのポリシーは、デプロイのユーザー体験の時点に基づいて、次の 3 つの保護レベルにグループ化されます。
- 開始点 - 多要素認証、セキュリティで保護されたパスワード変更、アプリ保護ポリシーを導入する基本的なコントロール。
- エンタープライズ - デバイス コンプライアンスを導入する拡張コントロール。
- 特殊なセキュリティ - 特定のデータ セットまたはユーザーに対して多要素認証を毎回要求するポリシー。
次の図は、各ポリシーが適用される保護のレベルと、ポリシーが PC または電話とタブレット、または両方のカテゴリのデバイスに適用されるかどうかを示しています。
この図は PDF ファイルとしてダウンロードできます。
ヒント
デバイスが対象のユーザーによって所有されていることを保証するために、Intune にデバイスを登録する前に、多要素認証 (MFA) の使用を要求することをお勧めします。 デバイス コンプライアンス ポリシーを適用する前に、Intune にデバイスを登録する必要があります。
前提条件
アクセス許可
- 条件付きアクセス ポリシーを管理するユーザーは、条件付きアクセス管理者、セキュリティ管理者、またはグローバル管理者として Azure portal にサインインできる必要があります。
- アプリ保護とデバイス コンプライアンス ポリシーを管理するユーザーは、Intune 管理者またはグローバル管理者として Intune にサインインできる必要があります。
- 構成の表示のみが必要なユーザーには、セキュリティ閲覧者またはグローバル閲覧者のロールを割り当てることができます。
ロールとアクセス許可の詳細については、「Microsoft Entra ビルトイン ロール」の記事を参照してください。
ユーザーの登録
使用を要求する前に、ユーザーが多要素認証に登録されていることを確認します。 Microsoft Entra ID P2 を含むライセンスがある場合は、Microsoft Entra ID Protection 内の MFA 登録ポリシーを使用して、ユーザーの登録を要求できます。 Microsoft では、登録を促進するために、ダウンロードしてカスタマイズできる通信テンプレートを提供しています。
グループ
これらの推奨事項の一部として使用されるすべての Microsoft Entra グループは、"セキュリティ グループではなく" Microsoft 365 グループとして作成する必要があります。 この要件は、後で Microsoft Teams と SharePoint でドキュメントをセキュリティで保護する際に秘密度ラベルを展開する場合に重要です。 詳細については、「Microsoft Entra ID でのグループとアクセス権について説明します」の記事を参照してください
ポリシーの割り当て
条件付きアクセス ポリシーは、ユーザー、グループ、管理者の役割に割り当てることができます。 Intune アプリ保護およびデバイス コンプライアンス ポリシーは、"グループにのみ" 割り当てることができます。 ポリシーを構成する前に、含めるユーザーと除外するユーザーを特定する必要があります。 通常、開始点の保護レベルのポリシーは、組織内のすべてのユーザーに適用されます。
ユーザーがユーザー登録を完了した後に MFA を要求するためのグループの割り当てと除外の例を次に示します。
| Microsoft Entra 条件付きアクセス ポリシー | 含む | 含めない | |
|---|---|---|---|
| 開始ポイント | 中または高のサインイン リスクに多要素認証を要求する | すべてのユーザー |
|
| Enterprise | 低、中、または高のサインイン リスクに多要素認証を要求する | "経営幹部グループ" |
|
| 特殊なセキュリティ | 常に多要素認証を要求する | "極秘プロジェクトの Buckeye グループ" |
|
グループとユーザーにより高いレベルの保護を適用する場合は注意してください。 セキュリティの目的は、ユーザー エクスペリエンスに不必要な摩擦を加えないことです。 たとえば、"極秘プロジェクトの Buckeye グループ" のメンバーは、プロジェクトの特殊なセキュリティ コンテンツに取り組んでいない場合でも、サインインするたびに MFA の使用を要求されます。 過度のセキュリティ上の摩擦は疲労につながる可能性があります。
Windows Hello for Business や FIDO2 セキュリティ キーなどのパスワードレス認証方法を有効にして、特定のセキュリティ コントロールによって引き起こされる摩擦を軽減することを検討できます。
緊急アクセス アカウント
すべての組織には、使用を監視し、ポリシーから除外する緊急アクセス アカウントが少なくとも 1 つ必要です。 これらのアカウントは、他のすべての管理者アカウントと認証方法がロックアウトされた場合、または使用できなくなった場合にのみ使用されます。 詳しくは、「Microsoft Entra ID で緊急アクセス用管アカウントを管理する」をご覧ください。
除外
条件付きアクセスの除外用に Microsoft Entra グループを作成することをお勧めします。 このグループは、アクセスの問題のトラブルシューティングを行う際にユーザーにアクセス権を与える手段を提供します。
警告
このグループは、一時的なソリューションとしてのみ使用することをお勧めします。 このグループの変更を継続的に監視および監査し、除外グループが意図したとおりにのみ使用されていることを確認します。
この除外グループを既存のポリシーに追加するには:
- Azure portal に、条件付きアクセス管理者、セキュリティ管理者、または全体管理者としてサインインします。
- [Microsoft Entra ID]>[セキュリティ]>[条件付きアクセス] に移動します。
- 既存のポリシーを選択します。
- [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
- [除外] で、[ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用のアカウントおよび条件付きアクセス除外グループを選択します。
展開
この表に示されている順序で、開始点ポリシーを実装することをお勧めします。 ただし、エンタープライズ向けの MFA ポリシーと特殊なセキュリティ レベルの保護は、いつでも実装できます。
開始ポイント
| ポリシー | 詳細 | ライセンス |
|---|---|---|
| ログインリスクが中程度または高レベルの場合はMFAが必要 | Microsoft Entra ID Protection のリスク データを使用して、リスクが検出された場合にのみ MFA を要求します | Microsoft 365 E5 または E5 Security アドオンがインストールされた Microsoft 365 E3 |
| 最新の認証をサポートしていないクライアントのブロック | 先進認証を使用しないクライアントでは、条件付きアクセス ポリシーをバイパスできるため、それらをブロックすることが重要です。 | Microsoft 365 E3 または E5 |
| リスクの高いユーザーはパスワードを変更する必要があります | アカウントに対してリスクの高いアクティビティが検出された場合、サインイン時にユーザーにパスワードの変更を強制します。 | Microsoft 365 E5 または E5 Security アドオンがインストールされた Microsoft 365 E3 |
| データ保護のアプリケーション保護ポリシーを適用する | プラットフォームごとに 1 つの Intune アプリ保護ポリシー (Windows、iOS/iPadOS、Android)。 | Microsoft 365 E3 または E5 |
| 承認されたアプリとアプリ保護ポリシーを要求する | iOS、iPadOS、または Android を使用して、電話とタブレットのモバイル アプリ保護ポリシーを適用します。 | Microsoft 365 E3 または E5 |
Enterprise
| ポリシー | 詳細 | ライセンス |
|---|---|---|
| サインイン リスクが "低"、"中"、または "高" の場合に MFA を要求する | Microsoft Entra ID Protection のリスク データを使用して、リスクが検出された場合にのみ MFA を要求します | Microsoft 365 E5 または E5 Security アドオンがインストールされた Microsoft 365 E3 |
| デバイス コンプライアンス ポリシーを定義する | 最小構成要件を設定します。 プラットフォームごとに 1 つのポリシー。 | Microsoft 365 E3 または E5 |
| 準拠した PC とモバイル デバイスが必要です | 組織にアクセスするデバイスの構成要件を適用します | Microsoft 365 E3 または E5 |
特殊なセキュリティ
| ポリシー | 詳細 | ライセンス |
|---|---|---|
| 常に MFA を要求する | ユーザーは、組織のサービスにサインインするたびに MFA を実行する必要があります | Microsoft 365 E3 または E5 |
アプリ保護ポリシー
アプリ保護ポリシーでは、許可されるアプリと、組織のデータで実行できるアクションを定義します。 多くの選択肢があり、混乱を招く可能性があります。 次のベースラインは、ニーズに合わせて調整できる Microsoft の推奨構成です。 従うテンプレートは 3 つ用意されていますが、ほとんどの組織はレベル 2 と 3 を選択すると考えています。
レベル 2 は、開始点またはエンタープライズ レベルのセキュリティを考慮する内容にマップされ、レベル 3 は特殊なセキュリティに対応付けられます。
レベル 1 のエンタープライズ基本データ保護 – Microsoft では、エンタープライズ デバイスの最小データ保護構成としてこの構成をお勧めします。
レベル 2 のエンタープライズ強化データ保護 – Microsoft では、ユーザーが機密情報にアクセスするデバイスには、この構成をお勧めします。 この構成は、職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。 一部のコントロールは、ユーザー エクスペリエンスに影響を与える可能性があります。
レベル 3 のエンタープライズの高いデータ保護 – Microsoft では、大規模またはより高度なセキュリティ チームを持つ組織が実行するデバイス、または他に類を見ないほどリスクが高い特定のユーザーまたはグループ (不正開示によって組織に重大な物的損失が発生する機密性の高いデータを処理するユーザー) には、この構成をお勧めします。 十分な資金がある高度な敵対者によって標的にされる可能性が高い組織は、この構成を目指す必要があります。
アプリ保護ポリシーを作成する
次の方法でデータ保護フレームワークの設定を使用して、Microsoft Intune 内のプラットフォーム (iOS および Android) ごとに新しいアプリ保護ポリシーを作成します。
- Microsoft Intune でアプリ保護ポリシーを作成して展開する方法に関するページの手順に従って、ポリシーを手動で作成します。
- Intune の PowerShell スクリプト を使用して、サンプルの Intune App Protection ポリシー構成フレームワーク JSON テンプレート をインポートします。
デバイス コンプライアンス ポリシー
Intune デバイス コンプライアンス ポリシーでは、デバイスが準拠していると判断されるために満たす必要がある要件を定義します。
PC、電話、またはタブレット プラットフォームごとにポリシーを作成する必要があります。 この記事では、次のプラットフォームの推奨事項について説明します。
デバイス コンプライアンス ポリシーを作成する
デバイス コンプライアンス ポリシーを作成するには、Microsoft Intune 管理センター にサインインし、[デバイス]>[コンプライアンス ポリシー]>[ポリシー] に移動します。 [ポリシーを作成する] を選択します。
Intune でコンプライアンス ポリシーを作成するステップ バイ ステップ ガイダンスについては、「Microsoft Intune でコンプライアンス ポリシーを作成する」を参照してください。
iOS/iPadOS の登録とコンプライアンス設定
iOS/iPadOS では、いくつかの登録シナリオがサポートされています。そのうちの 2 つについては、このフレームワークの一部として説明します。
- 個人所有デバイスのデバイス登録 - これらのデバイスは個人所有であり、仕事用と個人用の両方で使用されます。
- 会社所有デバイスの自動デバイス登録 - これらのデバイスは会社所有で、1 人のユーザーに関連付けられており、個人的に使用されるのではなく仕事専用です。
ゼロ トラスト ID とデバイス アクセス構成に関する記事で概説されている原則を使用します。
- 開始点とエンタープライズの保護レベルは、レベル 2 の強化されたセキュリティ設定と密接に対応付けられています。
- 特殊なセキュリティ保護レベルは、レベル 3 の高いセキュリティ設定に密接に対応付けられています。
個人登録デバイスのコンプライアンス設定
- 個人用の基本セキュリティ (レベル 1) – Microsoft では、ユーザーが職場または学校のデータにアクセスする個人デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成を行うには、パスワード ポリシー、デバイス ロック特性を適用し、信頼されていない証明書などの特定のデバイス機能を無効にします。
- 個人用の強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報にアクセスするデバイスには、この構成をお勧めします。 この構成では、データ共有コントロールが適用されます。 この構成は、デバイス上の職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。
- 個人用の高いセキュリティ (レベル 3) – Microsoft では、他に類を見ないほどリスクが高い特定のユーザーまたはグループ (不正開示によって組織に重大な物的損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスには、この構成をお勧めします。 この構成では、より強力なパスワード ポリシーが適用され、特定のデバイス機能が無効になり、追加のデータ転送制限が適用されます。
自動デバイス登録のコンプライアンス設定
- 監視対象の基本セキュリティ (レベル 1) – Microsoft では、ユーザーが職場または学校のデータにアクセスする監視対象デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成を行うには、パスワード ポリシー、デバイス ロック特性を適用し、信頼されていない証明書などの特定のデバイス機能を無効にします。
- 監視対象の強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報にアクセスするデバイスには、この構成をお勧めします。 この構成では、データ共有コントロールが適用され、USB デバイスへのアクセスがブロックされます。 この構成は、デバイス上の職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。
- 監視対象の高いセキュリティ (レベル 3) – Microsoft では、他に類を見ないほどリスクが高い特定のユーザーまたはグループ (不正開示によって組織に重大な物的損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスには、この構成をお勧めします。 この構成では、より強力なパスワード ポリシーが適用され、特定のデバイス機能が無効になり、追加のデータ転送制限が適用され、アプリは Apple の Volume Purchase Program からインストールする必要があります。
Android の登録とコンプライアンス設定
Android Enterprise では、いくつかの登録シナリオがサポートされています。そのうちの 2 つについては、このフレームワークの一部として説明します。
- Android Enterprise 仕事用プロファイル – この登録モデルは、通常、個人所有のデバイスに使用されます。IT は、仕事用と個人用データの間に明確な分離境界を提供したいと考えています。 IT によって制御されるポリシーにより、仕事用データを個人プロファイルに転送できなくなります。
- Android Enterprise フル マネージド デバイス – これらのデバイスは会社所有で、1 人のユーザーに関連付けられており、個人的に使用されるのではなく仕事専用です。
Android Enterprise セキュリティ構成フレームワークは、いくつかの異なる構成シナリオに編成され、仕事用プロファイルとフル マネージド シナリオのガイダンスを提供します。
ゼロ トラスト ID とデバイス アクセス構成に関する記事で概説されている原則を使用します。
- 開始点とエンタープライズの保護レベルは、レベル 2 の強化されたセキュリティ設定と密接に対応付けられています。
- 特殊なセキュリティ保護レベルは、レベル 3 の高いセキュリティ設定に密接に対応付けられています。
Android Enterprise 仕事用プロファイル デバイスのコンプライアンス設定
- 個人所有の仕事用プロファイル デバイスで使用できる設定のため、基本セキュリティ (レベル 1) のオファリングはありません。 使用可能な設定では、レベル 1 とレベル 2 の違いは正当化されません。
- 仕事用プロファイルの強化されたセキュリティ (レベル 2)– Microsoft では、ユーザーが職場または学校のデータにアクセスする個人デバイスの最小セキュリティ構成として、この構成をお勧めします。 この構成では、パスワード要件が導入され、仕事用と個人用データが分離され、Android デバイス構成証明が検証されます。
- 仕事用プロファイルの高いセキュリティ (レベル 3) – Microsoft では、他に類を見ないほどリスクが高い特定のユーザーまたはグループ (不正開示によって組織に重大な物的損失が発生する機密性の高いデータを処理するユーザー) によって使用されるデバイスには、この構成をお勧めします。 この構成では、Mobile Threat Defense または Microsoft Defender for Endpoint の導入、Android の最小バージョンの設定、より強力なパスワード ポリシーの適用、仕事用と個人用の分離のさらなる制限が行われます。
Android Enterprise フル マネージド デバイスのコンプライアンス設定
- フル マネージドの基本セキュリティ (レベル 1) – Microsoft では、エンタープライズ デバイスの最小セキュリティ構成としてこの構成をお勧めします。 この構成は、職場または学校のデータにアクセスするほとんどのモバイル ユーザーに適用されます。 この構成では、パスワード要件が導入され、Android の最小バージョンが設定され、特定のデバイス制限が適用されます。
- フル マネージドの強化されたセキュリティ (レベル 2) – Microsoft では、ユーザーが機密情報にアクセスするデバイスには、この構成をお勧めします。 この構成では、より強力なパスワード ポリシーが適用され、ユーザー/アカウントの機能が無効になります。
- フル マネージドの高いセキュリティ (レベル 3) - Microsoft では、他に類を見ないほどリスクが高い特定のユーザーまたはグループによって使用されるデバイスには、この構成をお勧めします。 これらのユーザーは、不正開示によって組織に重大な物的損失が発生する可能性がある機密性の高いデータを処理することがあります。 この構成では、Android の最小バージョンが増え、Mobile Threat Defense または Microsoft Defender for Endpoint が導入され、追加のデバイス制限が適用されます。
Windows 10 以降で推奨されるコンプライアンス設定
次の設定は、Windows 10 以降のデバイスのコンプライアンス ポリシー作成プロセスに関する記事の手順 2: コンプライアンス設定で構成されます。 これらの設定は、ゼロ トラスト ID とデバイス アクセス構成に関する記事で説明されている原則と一致します。
[デバイスの正常性] > [Windows 正常性構成証明サービスの評価ルール] については、次の表を参照してください。
| プロパティ | 値 |
|---|---|
| BitLocker が必要 | 必須 |
| デバイス上でセキュア ブートの有効化が必要 | 必須 |
| コードの整合性が必要 | 必須 |
[デバイス プロパティ] で、IT とセキュリティ ポリシーに基づいてオペレーティング システムのバージョンに適切な値を指定します。
[Configuration Manager のコンプライアンス] では、Configuration Manager を使用した共同管理環境を使っている場合は、[必須] を選択し、それ以外の場合は [構成されていません] を選択します。
[システム セキュリティ] については、次の表を参照してください。
| プロパティ | 値 |
|---|---|
| モバイル デバイスのロック解除にパスワードを必要とする | 必須 |
| 単純なパスワード | ブロック |
| パスワードの種類 | デバイスの既定値 |
| パスワードの最小文字数 | 6 |
| パスワードが要求されるまでの非アクティブな最大時間 | 15 分 |
| パスワードの有効期限 (日) | 41 |
| 再利用を防止する前のパスワードの数 | 5 |
| デバイスがアイドル状態から戻るときにパスワードを要求する (モバイルとホログラフィック) | 必須 |
| デバイス上のデータ ストレージの暗号化を要求する | 必須 |
| ファイアウォール | 必須 |
| ウイルス対策 | 必須 |
| スパイウェア対策 | 必須 |
| Microsoft Defender マルウェア対策 | 必須 |
| Microsoft Defender マルウェア対策の最小バージョン | Microsoft では、最新バージョンから 5 つ以下のバージョンをお勧めします。 |
| Microsoft Defender マルウェア対策の最新の署名 | 必須 |
| リアルタイム保護 | 必須 |
Microsoft Defender for Endpoint の場合
| プロパティ | 値 |
|---|---|
| デバイスがマシン リスク スコア以下である必要がある | Medium |
条件付きアクセス ポリシー
Intune でアプリ保護とデバイス コンプライアンス ポリシーが作成されたら、条件付きアクセス ポリシーを使用して適用を有効にすることができます。
サインイン リスクに基づいて MFA を要求する
「一般的な条件付きアクセス ポリシー: サインイン リスク ベースの多要素認証」の記事のガイダンスに従って、サインイン リスクに基づいて多要素認証を要求するポリシーを作成します。
ポリシーを構成するときは、次のリスク レベルを使用します。
| 保護レベル | 必要なリスク レベル値 | アクション |
|---|---|---|
| 開始ポイント | [高]、[中] | 両方ともオンにします。 |
| Enterprise | 高、中、低 | 3 つすべてをオンにします。 |
多要素認証をサポートしていないクライアントをブロックする
「一般的な条件付きアクセス ポリシー: レガシ認証をブロックする」の記事のガイダンスに従って、レガシ認証をブロックします。
リスクの高いユーザーはパスワードを変更する必要があります
「一般的な条件付きアクセス ポリシー: ユーザー リスクベースのパスワード変更」の記事のガイダンスに従って、資格情報が侵害されたユーザーにパスワードの変更を要求します。
このポリシーは、組織固有の用語に加えて、既知の脆弱なパスワードとそのバリエーションを検出してブロックする Microsoft Entra パスワード保護と共に使用します。 Microsoft Entra パスワード保護を使用すると、変更されたパスワードがより強力になります。
承認されたアプリとアプリ保護ポリシーを要求する
Intune で作成されたアプリ保護ポリシーを適用するには、条件付きアクセス ポリシーを作成する必要があります。 アプリ保護ポリシーを適用するには、条件付きアクセス ポリシーと対応するアプリ保護ポリシーが必要です。
承認されたアプリと APP 保護を必要とする条件付きアクセス ポリシーを作成するには、モバイル デバイスで承認済みのクライアント アプリまたはアプリ保護ポリシーを要求するに関する記事の手順に従います。 このポリシーでは、アプリ保護ポリシーによって保護されているモバイル アプリ内のアカウントのみから Microsoft 365 エンドポイントにアクセスできます。
iOS および Android デバイス上の他のクライアント アプリのレガシ認証をブロックすると、これらのクライアントでは条件付きアクセス ポリシーをバイパスできなくなります。 この記事のガイダンスに従っている場合は、先進認証をサポートしていないクライアントのブロックを既に構成しています。
準拠している PC とモバイル デバイスを 要求する
リソースにアクセスするデバイスが組織の Intune 準拠ポリシーに準拠しているとマークされていることを要求する条件付きアクセス ポリシーを作成するには、次の手順に従います。
注意事項
このポリシーを有効にする前に、デバイスが準拠していることを確認します。 そうしないと、ユーザー アカウントが条件付きアクセス除外グループに追加されるまで、ロックアウトされ、このポリシーを変更できなくなる可能性があります。
- Azure portal にサインインします。
- [Microsoft Entra ID]>[セキュリティ]>[条件付きアクセス] に移動します。
- [新しいポリシー] を選択します。
- ポリシーに名前を付けます。 ポリシーの名前に対する意味のある標準を組織で作成することをお勧めします。
- [割り当て] で、 [ユーザーまたはワークロード ID] を選択します。
- [Include](含める) で、 [すべてのユーザー] を選択します。
- [除外] で、 [ユーザーとグループ] を選択し、組織の緊急アクセス用または非常用アカウントを選択します。
- [Cloud apps or actions](クラウド アプリまたはアクション)>[Include](含める) で、 [すべてのクラウド アプリ] を選択します。
- 特定のアプリケーションをポリシーから除外する必要がある場合は、 [除外されたクラウド アプリの選択] で [除外] タブから選択して [選択] を選びます。
- [アクセス制御]>[付与] で
- [デバイスは準拠としてマーク済みである必要があります] を選択します。
- [選択] を選択します。
- 設定を確認し、 [Enable policy](ポリシーの有効化) を [オン] に設定します。
- [作成] を選択して、ポリシーを作成および有効化します。
Note
ポリシーで [すべてのユーザー] と [すべてのクラウド アプリ] に対して [デバイスは準拠しているとしてマーク済みであることが必要] を選択した場合でも、新しいデバイスを Intune に登録できます。 [デバイスは準拠としてマーク済みである必要がある] コントロールにより、Intune の登録や Microsoft Intune Web Company Portal アプリケーションへのアクセスはブロックされません。
サブスクリプションのライセンス認証
サブスクリプションのアクティブ化機能を使用してユーザーが Windows をあるバージョンから別へと "ステップアップ" できるようにする組織は、ユニバーサル ストア サービス API と Web アプリケーション (AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f) をデバイスのコンプライアンス ポリシーから除外できます。
常に MFA を要求する
「一般的な条件付きアクセス ポリシー: すべてのユーザーに対して MFA を必須にする」の記事のガイダンスに従って、特殊なセキュリティ レベルのユーザーが常に多要素認証を実行するように要求します。
警告
ポリシーを構成するときは、特殊なセキュリティを必要とするグループを選択し、[すべてのユーザー] を選択する代わりにこれを使用します。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示