条件付きアクセスのデプロイを計画する

アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。 条件付きアクセス ポリシーを使用すると、構成の柔軟性が大幅に向上します。 ただし、この柔軟性は、望ましくない結果を回避するために慎重に計画する必要があるということです。

Microsoft Entra 条件付きアクセス は、ユーザー、デバイス、場所などのシグナルを組み合わせて決定を自動化し、リソースに対して組織のアクセス ポリシーを適用します。 これらの条件付きアクセス ポリシーは、必要に応じてセキュリティ制御を適用し、そうでない場合はユーザーの邪魔にならないようにすることで、セキュリティと生産性のバランスを取るのに役立ちます。

条件付きアクセスは、Microsoft の ゼロ トラスト セキュリティ ポリシー エンジンの基礎となります。

Microsoft では、Microsoft Entra ID P1 または P2 のないテナントの基本的なレベルのセキュリティを保証するセキュリティ の既定値 を提供しています。 条件付きアクセスを使用すると、セキュリティの既定値と同じ保護を提供するポリシーを作成できますが、細分性が高くなります。 条件付きアクセス ポリシーを作成するとセキュリティの既定値を有効にできないため、条件付きアクセスとセキュリティの既定値は組み合わされません。

前提条件

• Microsoft Entra ID P1、P2、または試用版ライセンスが有効になっている、動作中の Microsoft Entra テナント。 必要に応じて、無料で作成できます。
  • 条件付きアクセス ポリシーに Microsoft Entra ID Protection のリスクを含めるには、Microsoft Entra ID P2 が必要です。
• 条件付きアクセスを操作する管理者は、実行しているタスクに応じて、次のいずれかのロールの割り当てが必要です。 最小限の特権のゼロ トラスト原則に従う場合は、Privileged Identity Management (PIM) を使用して、特権ロールの割り当てをジャスト イン タイムでアクティブ化することを検討してください。
  • 条件付きアクセス ポリシーと構成を読み取ります。
    • セキュリティリーダー
  • 条件付きアクセス ポリシーを作成または変更します。
    • 条件付きアクセス管理者
• 実際のユーザーに展開する前に、ポリシーが期待どおりに動作することを確認するテスト ユーザー (管理者ではありません)。 ユーザーを作成する必要がある場合は、クイックスタート: Microsoft Entra ID への新しいユーザーの追加に関する記事を参照してください。
• テスト ユーザーを含むグループ。 グループを作成する必要がある場合は、「Microsoft Entra ID でグループを作成してメンバーを追加する」をご覧ください。

変更の連絡

コミュニケーションは、新しい機能の成功に必要不可欠です。 エクスペリエンスがどのように変化するか、いつ変更されるか、問題が発生した場合のサポートを受ける方法をユーザーに知らせます。

条件付きアクセス ポリシーのコンポーネント

条件付きアクセス ポリシーは、リソースにアクセスできるユーザー、アクセスできるリソース、およびどのような条件下でアクセスできるかを決定します。 ポリシーでは、アクセスの許可、セッション制御によるアクセスの制限、またはアクセスのブロックを行うことができます。 条件付きアクセス ポリシーを作成するには、次のような if-then ステートメントを定義します。

ユーザーの除外

条件付きアクセス ポリシーは強力なツールです。 ポリシーから次のアカウントを除外することをお勧めします。

• ポリシー構成の誤りによるロックアウトを防ぐための緊急アクセスまたはブレークグラス アカウント。 すべての管理者がロックアウトされる可能性が低いシナリオでは、緊急アクセス管理者アカウントを使用してサインインし、アクセスを回復できます。
  • 詳細は、「Microsoft Entra ID で緊急アクセス用アカウントの管理」の記事を参照してください。
• サービス アカウントとサービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型アカウントです。 通常、アプリケーションへのプログラムによるアクセスを許可するためにバックエンド サービスによって使用されますが、管理目的でシステムにサインインするためにも使用されます。 サービス プリンシパルによって行われた呼び出しは、ユーザーを対象とする条件付きアクセス ポリシーによってブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
  • 組織がスクリプトまたはコードでこれらのアカウントを使用している場合は、 それらをマネージド ID に置き換えます。

適切な質問をする

割り当てとアクセス制御に関する一般的な質問を次に示します。 作成する前に、各ポリシーの回答を記録します。

ユーザーまたはワークロード ID

• どのユーザー、グループ、ディレクトリ ロール、またはワークロード ID がポリシーに含まれますか? または、除外されますか?
• ポリシーから除外する必要がある緊急アクセスアカウントまたはグループは何ですか?

クラウド アプリまたはアクション

このポリシーは、アプリケーション、ユーザーアクション、または認証コンテキストに適用されますか? そうすれば：

• ポリシーはどのアプリケーションまたはサービスに適用されますか?
• どのようなユーザー アクションがこのポリシーの対象となりますか?
• このポリシーはどのような認証コンテキストに適用されますか?

アプリケーションのフィルター

アプリケーションを個別に指定する代わりに、アプリケーションのフィルターを使用して含めたり除外したりすると、組織が次のことを行うのに役立ちます。

• 任意の数のアプリケーションを簡単にスケーリングしてターゲットに設定する
• 同様のポリシー要件を使用してアプリケーションを管理する
• 個々のポリシーの数を減らす
• ポリシーの編集中のエラーを減らす: ポリシーに対して手動でアプリケーションを追加または削除する必要はありません。 属性を管理するだけです。
• ポリシー サイズの制約を克服する

条件

• ポリシーに含める、またはポリシーから除外するデバイス プラットフォームはどれですか?
• 組織の既知のネットワークの場所は何ですか?
  • ポリシーにどの場所を含め、どの場所を除外しますか?
• どのクライアント アプリの種類をポリシーに含め、どれを除外しますか?
• 特定のデバイス属性を対象とする必要がありますか?
• Microsoft Entra ID Protection を使用する場合は、サインインまたはユーザー リスクを組み込みますか?

コントロールをブロックまたは許可する

次の 1 つ以上を必須としてリソースへのアクセスを許可しますか?

• 多要素認証
• デバイスが準拠としてマーク済みであること
• Microsoft Entra ハイブリッド参加済みデバイスの使用
• 承認済みクライアント アプリの使用
• アプリ保護ポリシー適用済み
• パスワードの変更
• 利用規約に同意済み

ブロック アクセス は強力な制御です。 影響を理解している場合にのみ適用します。 ブロック ステートメントを含むポリシーには、意図しない副作用がある可能性があります。 大規模なコントロールを有効にする前に、テストと検証を行います。 ポリシーの影響モードまたはレポート専用モードを使用して、変更を加えたときの潜在的な影響を把握します。

セッション制御

クラウド アプリに次のアクセス制御を適用しますか?

• アプリによって適用される制限を使用する
• アプリの条件付きアクセス制御を使用する
• サインインの頻度を適用する
• 永続的ブラウザー セッションを使用する
• 継続的アクセス評価をカスタマイズする

ポリシーの組み合わせ

ポリシーを作成して割り当てるときは、アクセス トークンのしくみを検討してください。 アクセス トークンは、要求を 行うユーザーが承認および認証されているかどうかに基づいて、アクセスを許可または拒否します。 要求者が自分が自分の主張する人物であることを証明した場合は、保護されたリソースまたは機能を使用できます。

条件付きアクセス ポリシー条件によってアクセス制御がトリガーされない場合、アクセス トークンは既定で発行されます。

このポリシーでは、アプリが単独でアクセスをブロックすることを防ぐことはありません。

たとえば、次のような簡略化されたポリシーの例を考えてみます。

ユーザー: 財務グループ
アクセス: 給与処理アプリ
アクセス制御: 多要素認証

• ユーザー A は財務グループに属しており、給与処理アプリにアクセスするには多要素認証を実行する必要があります。
• ユーザー B は財務グループに属しておらず、アクセス トークンが発行され、多要素認証を実行せずに給与処理アプリにアクセスできます。

財務グループの外部のユーザーが給与計算アプリにアクセスできないようにするには、別のポリシーを作成して、次の簡略化されたポリシーのように、他のすべてのユーザーをブロックします。

ユーザー: すべてのユーザーを含める/財務グループを除外する
アクセス: 給与処理アプリ
アクセス制御: アクセスをブロックする

これで、ユーザー B が PAYROLL アプリにアクセスしようとすると、ブロックされます。

推奨事項

条件付きアクセスと他のお客様のサポートに関する経験に基づいて、いくつかの推奨事項を次に示します。

条件付きアクセス ポリシーをすべてのアプリに適用する

すべてのアプリに少なくとも 1 つの条件付きアクセス ポリシーが適用されていることを確認してください。 セキュリティの観点からは、すべてのリソース (以前は "すべてのクラウド アプリ") を含むポリシーを作成することをお勧めします。 このプラクティスにより、新しいアプリケーションをオンボードするたびに条件付きアクセス ポリシーを更新する必要がなくなります。

条件付きアクセス ポリシーの数を最小限にする

各アプリのポリシーを作成することは効率的ではなく、ポリシーの管理が困難になります。 条件付きアクセスには、テナントあたり 195 ポリシーの制限があります。 この 195 ポリシーの制限には、レポート専用モード、オン、オフなど、あらゆる状態の条件付きアクセス ポリシーが含まれます。

アプリを分析し、同じユーザーに対して同じリソース要件でグループ化します。 たとえば、すべての Microsoft 365 アプリまたはすべての HR アプリに同じユーザーに対して同じ要件がある場合は、1 つのポリシーを作成し、適用されるすべてのアプリを含めます。

条件付きアクセス ポリシーは JSON ファイルに含まれており、そのファイルには 1 つのポリシーが通常超えないサイズ制限があります。 ポリシーで長い GUID の一覧を使用すると、この制限に達する可能性があります。 これらの制限が発生した場合は、次の方法を試してください。

• グループまたはロールを使用して、各ユーザーを個別に一覧表示するのではなく、ユーザーを含めたり除外したりします。
• アプリケーションを個別に指定する代わりに、アプリケーションのフィルターを使用して、アプリケーションを含めたり除外したりします。

レポート専用モードの構成

レポート専用モードでポリシーを有効にします。 レポート専用モードでポリシーを保存すると、サインイン ログのリアルタイム サインインに対する影響が表示されます。 サインイン ログからイベントを選択し、[ レポートのみ ] タブに移動して、各レポート専用ポリシーの結果を表示します。

Insights ブックと Reporting ブックで、条件付きアクセス ポリシーの集計効果を表示します。 ブックにアクセスするには、Azure Monitor のサブスクリプションが必要であり、サインイン ログを Log Analytics ワークスペースにストリーミングする必要があります。

中断に対する計画を立てる

組織の 回復性戦略を計画 することで、予期しない中断時のロックアウトのリスクを軽減します。

保護されたアクションを有効にする

保護されたアクションを有効にして、条件付きアクセス ポリシーの作成、変更、または削除を試みる別のセキュリティレイヤーを追加します。 組織では、ポリシーを変更する前に、新しい多要素認証またはその他の許可制御を要求できます。

ゲスト ユーザー設定の構成

知っていて関係がある外部組織の場合は、ゲストが条件付きアクセス ポリシーに提示する多要素認証、デバイス コンプライアンス、またはハイブリッド デバイス要求を信頼できます。 詳細については、「 B2B コラボレーションのテナント間アクセス設定の管理」を参照してください。 B2B ユーザーが Microsoft Entra ID Protection を使用する方法に関連するいくつかの注意事項があります。詳細については、「 B2B ユーザー向けの Microsoft Entra ID Protection」を参照してください。

ポリシーの名前付け基準を設定する

名前付け標準は、ポリシーを開かずにポリシーを見つけて目的を理解するのに役立ちます。 表示するポリシーに名前を付けます。

• シーケンス番号
• 適用先のクラウド アプリ
• 応答
• 適用されるユーザー
• 適用されるタイミング

例: 外部ネットワークから Dynamics CRP アプリにアクセスするマーケティング ユーザーに対して MFA を要求するポリシーは次のようになります。

わかりやすい名前を付けると、条件付きアクセスの実装の概要を把握できます。 シーケンス番号は、会話でポリシーを参照する必要がある場合に役立ちます。 たとえば、電話で管理者と話すときに、問題を解決するためにポリシー CA01 を開くように依頼できます。

緊急アクセス制御の名前付け基準

アクティブ ポリシーに加えて、機能停止や緊急状況のシナリオでセカンダリの回復性があるアクセス制御として機能する停止時のポリシーを実装します。 コンティンジェンシー ポリシーの名前付け標準には、次のものが含まれている必要があります。

• 他のポリシーから名前が目立つようにするため、先頭に ENABLE IN EMERGENCY (緊急時に有効化)。
• 適用する必要がある中断の名前。
• 管理者が、どの順序ポリシーを有効にすべきかを把握するのに役立つ順序付けシーケンス番号。

例: 次の名前は、MFA の中断が発生した場合に有効にする 4 つのポリシーの最初のポリシーであることを示しています。

• EM01 - 緊急時に有効化: MFAの障害 [1/4] - Exchange SharePoint: VIPユーザーにはMicrosoft Entraのハイブリッド参加が必要です。

サインイン元の国/リージョンとして想定されない国をブロックします。

Microsoft Entra ID を使用すると、 名前付きの場所を作成できます。 許可されている国/地域の一覧を作成し、これらの "許可された国/地域" を除外として使用してネットワーク ブロック ポリシーを作成します。 このオプションを選択すると、地理的に小さい場所に基づく顧客のオーバーヘッドが少なくなります。 このポリシーから緊急アクセスアカウントを除外してください。

条件付きアクセス ポリシーをデプロイする

準備ができたら、条件付きアクセス ポリシーを段階的にデプロイします。 次のような主要な条件付きアクセス ポリシーから始めます。 多くのポリシーは、 条件付きアクセス ポリシー テンプレートとして使用できます。 既定では、テンプレートから作成された各ポリシーはレポート専用モードです。 各ポリシーを有効にする前に、目的の結果を確認するために、使用状況をテストして監視します。

次の 3 つのフェーズでポリシーを展開し、セキュリティの強化とユーザーの中断を最小限に抑えます。 組織は、サイズ、複雑さ、変更管理機能に基づいてタイムラインを調整できます。

フェーズ 1: 基礎 (第 1~2 週)

ベースライン のセキュリティ制御を確立し、MFA の適用に備える。 前提 条件： 適用ポリシーを有効にする前に、ユーザーが MFA に登録できることを確認します。

フェーズ 2: コア認証 (第 2 ~ 3 週)

すべてのユーザーとゲストに MFA を適用し、アプリ保護ポリシーを使用してモバイル デバイス を保護します。 主な影響: ユーザーは、すべてのサインインに MFA を使用し、承認されたアプリとモバイル デバイス上のアプリ保護を使用する必要があります。 通信計画が実行され、サポート リソースが使用可能であることを確認します。

フェーズ 3: 高度な保護 (第 3 ~4 週)

リスクベースのポリシーと高度な攻撃防止コントロールを追加します。 ライセンス要件: リスクベースのポリシーには、Microsoft Entra ID P2 ライセンスが必要です。

ポリシーの影響を評価する

使用可能なツールを使用して、変更の前後にポリシーの効果を確認します。 シミュレートされた実行では、条件付きアクセス ポリシーがサインインにどのように影響するかを把握できますが、適切に構成された開発環境での実際のテスト実行は置き換わりません。

管理者は、ポリシー の影響モードまたはレポート専用モードを使用してポリシー設定を確認できます。

ポリシーをテストする

ポリシーの除外条件を必ずテストしてください。 たとえば、MFA を必要とするポリシーからユーザーまたはグループを除外する可能性があります。 他のポリシーの組み合わせでそれらのユーザーに MFA が必要な場合があるため、除外されたユーザーに MFA の入力を求められるかどうかをテストします。

テスト ユーザーを使用して、テスト 計画の各テストを実行します。 テスト計画は、予想される結果と実際の結果を比較するのに役立ちます。

運用環境でデプロイする

ポリシーへの影響またはレポート専用モードを使用して設定を確認したら、[ポリシーを有効にする] トグルを [レポートのみ] から [オン] に移動します。

ポリシーをロールバックする

新しく実装されたポリシーをロールバックする必要がある場合は、次の 1 つ以上のオプションを使用します。

• ポリシーを無効にする。 ポリシーを無効にすると、ユーザーがサインインしようとしたときにポリシーが適用されなくなります。 ポリシーを使用する場合は、いつでも元に戻ってポリシーを有効にすることができます。

• ポリシーからユーザーまたはグループを除外する。 ユーザーがアプリにアクセスできない場合は、ポリシーからユーザーを除外します。

  注意事項

  ユーザーが信頼されている場合にのみ、除外を慎重に使用してください。 できるだけ早くユーザーをポリシーまたはグループに追加し直します。

• ポリシーが無効になっており、不要になった場合は、 削除します。

削除されたポリシーを復元する

条件付きアクセスまたは場所が削除された場合は、30 日間の論理的な削除期間内に復元できます。 条件付きアクセス ポリシーと名前付き場所の復元の詳細については、 削除からの回復に関する記事を参照してください。

条件付きアクセス ポリシーのトラブルシューティングを行う

ユーザーが条件付きアクセス ポリシーに問題がある場合は、トラブルシューティングに役立つ情報を収集します。

• ユーザー プリンシパル名
• ユーザー表示名
• オペレーティング システム名
• タイムスタンプ (おおよその時間で問題ありません)
• ターゲット アプリケーション
• クライアント アプリケーションの種類 (ブラウザーまたはクライアント)
• 相関 ID (この ID はサインインに固有です)

ユーザーが [詳細 ] リンクを含むメッセージを受け取った場合は、この情報の大部分を収集できます。

情報を収集したら、次のリソースを参照してください。

• 条件付きアクセスに関するサインインの問題 – エラー メッセージと Microsoft Entra サインイン ログを使用した条件付きアクセスに関連する予期しないサインイン結果について説明します。
• What-If ツールの使用 - 特定の状況でポリシーがユーザーに適用されるかどうか、または既知の状態でポリシーが適用されるかどうかを確認する理由を学びます。

関連するコンテンツ

• 多要素認証の詳細
• Microsoft Entra ID Protection についてさらに知る
• Microsoft Graph API を使用して条件付きアクセス ポリシーを管理する