条件付きアクセスのデプロイを計画する
アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。 条件付きアクセス ポリシーによって、優れた構成柔軟性が提供されます。 ただし、この柔軟性は、慎重に計画して、望ましくない結果を避ける必要があることも意味します。
Microsoft Entra の条件付きアクセスは、ユーザー、デバイス、場所などのシグナルを組み合わせて、意思決定を自動化し、リソースに関する組織のアクセス ポリシーを適用します。 このような条件付きアクセス ポリシーは、セキュリティと生産性のバランスを取り、必要なときはセキュリティ制御を適用し、不要なときはユーザーの邪魔にならないようにするために役立ちます。
条件付きアクセスは、Microsoft のゼロ トラスト セキュリティ ポリシー エンジンの基礎です。
Microsoft では、Microsoft Entra ID P1 または P2 を利用しないテナントでも基本レベルのセキュリティが有効であることを保証するセキュリティの既定値群を提供しています。 条件付きアクセスを使用すると、セキュリティの既定値群と同じ保護を提供するが、きめ細かな制御が可能なポリシーを作成できます。 条件付きアクセス ポリシーを作成するとセキュリティの既定値群を有効にできなくなるため、条件付きアクセスとセキュリティの既定値群を組み合わせることは想定されていません。
前提条件
- Microsoft Entra ID P1、P2、または試用版のライセンスが有効になっている稼働中の Microsoft Entra テナント。 必要に応じて、無料で作成できます。
- 条件付きアクセス ポリシーに Microsoft Entra ID Protection のリスクを含めるには、Microsoft Entra ID P2 が必要です。
- 条件付きアクセスに関与する管理者は、実行しているタスクに応じて、次のロールの割り当てを 1 つ持っている必要があります。 最小特権のゼロ トラスト原則に従う場合は、Privileged Identity Management (PIM) を使用して、Just-In-Time で特権ロールの割り当てをアクティブ化することを検討してください。
- 条件付きアクセス ポリシーと構成を読み取る
- 条件付きアクセス ポリシーを作成または変更する
- 実際のユーザーにデプロイする前に、ポリシーが期待どおりに機能することを確認できるテスト ユーザー (管理者以外)。 ユーザーを作成する必要がある場合は、クイックスタート: Microsoft Entra ID への新しいユーザーの追加に関する記事を参照してください。
- テスト ユーザーが属するグループ。 グループを作成する必要がある場合は、「Microsoft Entra ID でグループを作成してメンバーを追加する」をご覧ください。
変更の連絡
コミュニケーションは、新しい機能の成功に必要不可欠です。 ユーザー エクスペリエンスがどのように変わるのか、いつ変わるのか、および問題が発生したときにサポートを受ける方法について、ユーザーに事前に連絡する必要があります。
条件付きアクセス ポリシーのコンポーネント
条件付きアクセス ポリシーは、誰がリソースにアクセスできるか、どのようなリソースにアクセスできるか、それはどのような条件かについての質問に答えるものです。 ポリシーは、アクセスを許可するか、セッション制御を使用してアクセスを制限するか、またはアクセスをブロックするように設計できます。 条件付きアクセス ポリシーを作成するには、次のような if-then ステートメントを定義します。
| 割り当てが満たされた場合 | アクセス制御を適用する |
|---|---|
| 財務のユーザーが給与処理アプリケーションにアクセスしている場合 | 多要素認証および準拠しているデバイスを要求する |
| 財務に属していないメンバーが給与処理アプリケーションにアクセスしている場合 | アクセスのブロック |
| ユーザー リスクが高い場合 | 多要素認証とセキュリティで保護されたパスワードの変更を要求する |
ユーザーの除外
条件付きアクセス ポリシーは強力なツールであり、次のアカウントをポリシーから除外することをお勧めします。
- ポリシーの構成ミスによるロックアウトを防ぐため、緊急アクセス または break-glass アカウント。 万一、すべての管理者がロックアウトされるシナリオでは、緊急アクセス管理アカウントを使用してログインし、アクセスを回復するための手順を実行できます。
- 詳細は、「Microsoft Entra ID で緊急アクセス用アカウントの管理」の記事を参照してください。
- サービス アカウント および Service プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにログインするときにも使用されます。 サービス プリンシパルによる呼び出しは、ユーザーにスコーピングされる条件付きアクセス ポリシーによってブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
- 組織がスクリプトまたはコードでこれらのアカウントを使用している場合、マネージド ID に置き換えることを検討してください。
適切な質問をする
ここでは、割り当てとアクセス制御に関する一般的な質問をいくつか示します。 ポリシーを構築する前に、ポリシーごとに質問に対する回答を文書化します。
ユーザーまたはワークロード ID
- どのユーザー、グループ、ディレクトリ ロール、またはワークロード ID がポリシーに含まれますか? または、除外されますか?
- どのような緊急アクセス用のアカウントまたはグループをポリシーから除外する必要がありますか?
クラウド アプリまたはアクション
このポリシーは、いずれかのアプリケーション、ユーザー操作、または認証コンテキストに適用されますか? はいの場合:
- このポリシーはどのようなアプリケーションまたはサービスに適用されますか?
- どのようなユーザー アクションがこのポリシーの対象となりますか?
- このポリシーはどのような認証コンテキストに適用されますか?
アプリケーションのフィルター
アプリケーションを個別に指定する代わりに、アプリケーションのフィルターを使用して含めたり除外したりすると、組織が次のことを行うのに役立ちます。
- 任意の数のアプリケーションを簡単にスケーリングして対象を設定する。
- 同様のポリシー要件でアプリケーションを簡単に管理する。
- 個々のポリシーの数を減らす。
- ポリシーの編集中のエラーを減らす。ポリシーからアプリケーションを手動で追加または削除する必要はありません。 属性を管理するだけです。
- ポリシー サイズの制約を取り除く。
条件
- ポリシーに含める、またはポリシーから除外するデバイス プラットフォームはどれですか?
- 組織の既知のネットワークの場所は何ですか?
- ポリシーにどの場所を含め、どの場所を除外しますか?
- どのクライアント アプリの種類をポリシーに含め、どれを除外しますか?
- 特定のデバイス属性を対象とする必要がありますか?
- Microsoft Entra ID 保護を使用する場合、サインインまたはユーザーのリスクを組み込みますか?
コントロールをブロックまたは許可する
次の 1 つ以上を必須としてリソースへのアクセスを許可しますか?
- 多要素認証
- デバイスが準拠としてマーク済みであること
- Microsoft Entra ハイブリッド参加済みデバイスの使用
- 承認済みクライアント アプリの使用
- アプリ保護ポリシー適用済み
- パスワードの変更
- 利用規約に同意済み
アクセスのブロックは強力なコントロールであり、適用するには適切な知識が必要です。 ブロック ステートメントのあるポリシーには予想外の副作用が含まれることがあります。 大規模にコントロールを有効にする前に、適切なテストと検証が不可欠です。 管理者は、変更を行うにあたり、条件付きアクセスのレポート専用モードや条件付きアクセスの What If ツールなどのツールを使う必要があります。
セッション制御
クラウド アプリに次のアクセス制御を適用しますか?
- アプリによって適用される制限を使用する
- アプリの条件付きアクセス制御を使用する
- サインインの頻度を適用する
- 永続的ブラウザー セッションを使用する
- 継続的アクセス評価をカスタマイズする
ポリシーの組み合わせ
ポリシーを作成して割り当てるときは、アクセス トークンのしくみを考慮する必要があります。 アクセス トークンでは、要求を行っているユーザーが認可および認証されているかどうかに基づいて、アクセスを許可または拒否します。 要求元は、自分が本人であることを証明できる場合、保護されたリソースまたは機能にアクセスできます。
条件付きアクセス ポリシー条件によってアクセス制御がトリガーされない場合、既定でアクセス トークンが発行されます。
このポリシーは、アプリでアクセスをブロックするのを妨げるものではありません。
たとえば、次のような簡略化されたポリシーの例を考えてみます。
ユーザー: 財務グループ
アクセス: 給与処理アプリ
アクセス制御: 多要素認証
- ユーザー A は財務グループに属しており、給与処理アプリにアクセスするには多要素認証を実行する必要があります。
- ユーザー B は財務グループに属しておらず、アクセス トークンが発行され、多要素認証を実行せずに給与処理アプリにアクセスできます。
財務グループの外部のユーザーが給与処理アプリにアクセスできないようにするには、次の簡略化されたポリシーのような、他のすべてのユーザーをブロックするポリシーを別途作成することができます。
ユーザー: すべてのユーザーを含める/財務グループを除外する
アクセス: 給与処理アプリ
アクセス制御: アクセスをブロックする
これで、ユーザー B が給与処理アプリにアクセスしようとすると、ブロックされます。
Recommendations
条件付きアクセスの使用と他のお客様のサポートについて学習したことを考慮して、学習内容に基づいていくつかの推奨事項を次に示します。
条件付きアクセス ポリシーをすべてのアプリに適用する
すべてのアプリに少なくとも 1 つの条件付きアクセス ポリシーが適用されていることを確認してください。 セキュリティの観点から、 すべてのリソース (旧称 "すべてのクラウド アプリ") を含むポリシーを作成し、ポリシーを適用したくないアプリケーションを除外することをお勧めします。 このプラクティスにより、新しいアプリケーションをオンボードするたびに条件付きアクセス ポリシーを更新する必要がなくなります。
ヒント
1 つのポリシーでブロックとすべてのアプリを使用する場合は特に注意してください。 これにより、管理者がロックアウトされる可能性があります。また、Microsoft Graph などの重要なエンドポイントに対しては除外を構成できません。
条件付きアクセス ポリシーの数を最小限にする
アプリごとにポリシーを作成するのは効率的ではなく、管理が困難になります。 条件付きアクセスでは、テナントあたりポリシーが 195 個に制限されています。 この 195 個のポリシー制限には、レポート専用モード、オン、オフなど、あらゆる状態の条件付きアクセス ポリシーが含まれます。
アプリを分析し、同じユーザーに対して同じリソース要件があるアプリケーションにそれらをグループ化することをお勧めします。 たとえば、すべての Microsoft 365 アプリまたはすべての HR アプリで同じユーザーに対して同じ要件がある場合、1 つのポリシーを作成し、それが適用されるすべてのアプリを含めます。
条件付きアクセス ポリシーは JSON ファイルに含まれており、このファイルには、1 つのポリシーで超えることはないと想定されるサイズ上限が設定されています。 ポリシーで長い GUID の一覧を使用すると、この制限に達する可能性があります。 これらの制限が発生した場合は、次のような代替手段をお勧めします。
- グループまたはロールを使用して、各ユーザーを個別に一覧表示する代わりに、ユーザーを含めるか除外します。
- アプリケーションを個別に指定する代わりに、アプリケーションのフィルターを使用して、アプリケーションを含めたり除外したりします。
レポート専用モードの構成
既定では、テンプレートから作成された各ポリシーはレポート専用モードで作成されます。 意図した結果を得るために、各ポリシーを有効にする前に、組織で使用状況をテストおよび監視することをお勧めします。
レポート専用モードでポリシーを有効にします。 レポート専用モードでポリシーを保存すると、サインイン ログでリアルタイム サインインへの影響を確認できます。 サインイン ログから、イベントを選択し、[レポート専用] タブに移動して、各レポート専用ポリシーの結果を確認します。
分析情報とレポートのブックで、条件付きアクセス ポリシーの全体的な影響を確認できます。 ブックにアクセスするには、Azure Monitor のサブスクリプションが必要であり、サインイン ログを Log Analytics ワークスペースにストリーミングする必要があります。
中断に対する計画を立てる
予期しない中断が発生した場合のロックアウトのリスクを軽減するために、組織の回復性戦略を計画します。
保護されたアクションを有効にする
保護されたアクションを有効にすると条件付きアクセス ポリシーの作成、変更、または削除を試みる場合に、セキュリティの別の層が設定されます。 組織では、ポリシーを変更する前に、新しい多要素認証またはその他の許可制御を要求できます。
ポリシーの名前付け基準を設定する
名前付け基準があると、Azure 管理ポータルでポリシーを開かなくても、ポリシーを見つけてその用途を理解することができます。 以下を示すようにポリシーの名前を設定することをお勧めします。
- シーケンス番号
- 適用先のクラウド アプリ
- 応答
- 適用されるユーザー
- 適用されるタイミング
例: 外部ネットワークから Dynamics CRP アプリにアクセスするマーケティング ユーザーに対して MFA を要求するポリシーは次のようになります。
わかりやすい名前は、条件付きアクセスの実装の概要を把握するのに役立ちます。 シーケンス番号は、会話でポリシーを参照する必要がある場合に便利です。 たとえば、管理者と電話で話す場合、問題を解決するためにポリシー CA01 を開くように依頼できます。
緊急アクセス制御の名前付け基準
アクティブ ポリシーに加えて、機能停止や緊急状況のシナリオでセカンダリの回復性があるアクセス制御として機能する停止時のポリシーを実装します。 コンティンジェンシー ポリシーの命名規則には、以下を含める必要があります。
- 他のポリシーから名前が目立つようにするため、先頭に ENABLE IN EMERGENCY (緊急時に有効化)。
- 適用する必要のある中断の名前。
- 管理者がポリシーを有効にする順序を理解できるようにするための、順序シーケンス番号。
例: 次の名前は、このポリシーが、MFA の中断時に有効にする 4 つのポリシーのうちの最初のものであることを示しています。
- EM01 - ENABLE IN EMERGENCY: MFA Disruption [1/4] - Exchange SharePoint: Require Microsoft Entra hybrid join For VIP users.
サインイン元の国/リージョンとして想定されない国をブロックします。
Microsoft Entra ID では、ネームド ロケーションを作成できます。 許可されている国/リージョンのリストを作成してから、これらの "許可されている国/リージョン" を除外したネットワーク ブロック ポリシーを作成します。 比較的狭い地域を拠点としている顧客の場合、このオプションを選ぶとオーバーヘッドが軽減されます。 緊急アクセス アカウントは必ずこのポリシーから除外してください。
条件付きアクセス ポリシーをデプロイする
準備ができたら、条件付きアクセス ポリシーを段階的にデプロイします。
条件付きアクセス ポリシーをビルドする
有利なスタートを切るには、条件付きアクセス ポリシー テンプレートと Microsoft 365 組織の一般的なセキュリティ ポリシーに関する記事を参照してください。 これらのテンプレートは、Microsoft の推奨事項をデプロイするのに便利な方法です。 緊急アクセス アカウントは必ず除外してください。
ポリシーの影響を評価する
次のツールを使用して、変更の前後の両方でポリシーの効果を評価することをお勧めします。 シミュレートされた実行により、条件付きアクセス ポリシーの影響を把握できますが、適切に構成された開発環境での実際のテスト実行に代わるものではありません。
- レポート専用モードと、条件付きアクセスに関する分析情報とレポートのブック。
- What If ツール
ポリシーをテストする
ポリシーの除外条件を必ずテストしてください。 たとえば、MFA を必要とするポリシーからユーザーまたはグループを除外する可能性があります。 他のポリシーの組み合わせでは、除外されたユーザーに MFA を要求する可能性があるため、それらのユーザーに MFA を求めるプロンプトが表示されるかどうかをテストする必要があります。
テスト ユーザーを使用して、テスト計画で各テストを実行します。 テスト計画は、予想される結果と実際の結果を比較するために重要です。 次の表は、いくつかのテスト ケースの例の概要です。 実際の条件付きアクセス ポリシーを構成する方法に基づいて、このシナリオと予想される結果を調整します。
| ポリシー | シナリオ | 予測される結果 |
|---|---|---|
| リスクの高いサインイン | ユーザーが未承認のブラウザーを使用してアプリにサインインする | サインインがユーザーによって実行されなかった確率に基づいてリスク スコアを計算します。 ユーザーは MFA を使用した自己修復を要求されます |
| デバイス管理 | 承認済みユーザーが承認済みデバイスからサインインしようとする | アクセスが許可されます |
| デバイス管理 | 承認済みユーザーが承認されていないデバイスからサインインしようとする | アクセスはブロックされます |
| 危険なユーザーのパスワード変更 | 承認されたユーザーが、侵害された資格情報でサインインしようとする (リスクの高いサインイン) | ユーザーはパスワードを変更するよう求められるか、ポリシーに基づいてアクセスがブロックされます |
運用環境でデプロイする
ユーザーがレポート専用モードを使用して影響を確認したら、管理者は [ポリシーの有効化] トグルを [レポート専用] から [オン] に移動できます。
ポリシーをロールバックする
新しく実装したポリシーをロールバックする必要がある場合は、次の 1 つ以上のオプションを使用します。
ポリシーを無効にする。 ポリシーを無効にすると、ユーザーがサインインしようとしたときにポリシーが適用されなくなります。 ポリシーを使用したい場合には、いつでも戻ってそのポリシーを有効にできます。
ポリシーからユーザーまたはグループを除外する。 ユーザーがアプリにアクセスできない場合、そのユーザーをポリシーから除外することを選択できます。
注意事項
ユーザーを信頼できる状態でのみ、除外は控えめに使用してください。 ユーザーはできるだけ早くポリシーまたはグループに追加し直す必要があります。
ポリシーが無効にされたり不要になったりした場合は、削除します。
条件付きアクセス ポリシーのトラブルシューティングを行う
ユーザーが条件付きアクセス ポリシーに関する問題を抱えている場合は、トラブルシューティングを容易にするために次の情報を収集します。
- ユーザー プリンシパル名
- ユーザー表示名
- オペレーティング システム名
- タイム スタンプ (おおよその時刻でもかまいません)
- ターゲット アプリケーション
- クライアント アプリケーションの種類 (ブラウザーとクライアント)
- 相関 ID (この ID はサインインに固有です)
ユーザーが [詳細] リンクを含むメッセージを受信した場合、それらのユーザーはこの情報の大部分を収集できます。
情報を収集した後、次のリソースを参照してください。
- 条件付きアクセスでのサインインの問題 – エラー メッセージと Microsoft Entra のサインイン ログを使用して、条件付きアクセスに関連する予期しないサインイン結果について理解してください。
- What-If ツールの使用 - ポリシーが特定の状況でユーザーに適用された理由や適用されなかった理由、ポリシーが既知の状態で適用されるかどうかについて理解してください。