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