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

  • [アーティクル]

アプリとリソースに関する組織のアクセス戦略を実現するために、条件付きアクセスのデプロイを計画することが重要です。 条件付きアクセス ポリシーによって、優れた構成柔軟性が提供されます。 ただし、この柔軟性は、慎重に計画して、望ましくない結果を避ける必要があることも意味します。

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

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

条件付きアクセスの概要を示す図。

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

前提条件

変更の連絡

コミュニケーションは、新しい機能の成功に必要不可欠です。 ユーザー エクスペリエンスがどのように変わるのか、いつ変わるのか、および問題が発生したときにサポートを受ける方法について、ユーザーに事前に連絡する必要があります。

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

条件付きアクセス ポリシーは、誰がリソースにアクセスできるか、どのようなリソースにアクセスできるか、それはどのような条件かについての質問に答えるものです。 ポリシーは、アクセスを許可するか、セッション制御を使用してアクセスを制限するか、またはアクセスをブロックするように設計できます。 条件付きアクセス ポリシーを作成するには、次のような if-then ステートメントを定義します。

割り当てが満たされた場合 アクセス制御を適用する
財務のユーザーが給与処理アプリケーションにアクセスしている場合 多要素認証および準拠しているデバイスを要求する
財務に属していないメンバーが給与処理アプリケーションにアクセスしている場合 アクセスのブロック
ユーザー リスクが高い場合 多要素認証とセキュリティで保護されたパスワードの変更を要求する

ユーザーの除外

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

  • 緊急アクセス用アカウントまたは非常用アカウント。テナント全体でアカウントがロックアウトされるのを防ぎます。 発生する可能性は低いシナリオですが、すべての管理者がテナントからロックアウトされた場合に、ご自身の緊急アクセス用管理アカウントを使用してテナントにログインし、アクセスの復旧手順を実行できます。
  • サービス アカウントとサービス プリンシパル (Microsoft Entra Connect 同期アカウントなど)。 サービス アカウントは、特定のユーザーに関連付けられていない非対話型のアカウントです。 これらは通常、アプリケーションへのプログラムによるアクセスを可能にするバックエンド サービスによって使用されますが、管理目的でシステムにサインインする場合にも使用されます。 プログラムでは MFA を完了できないため、このようなサービス アカウントは対象外とする必要があります。 サービス プリンシパルによる呼び出しは、ユーザーをスコープとする条件付きアクセス ポリシーではブロックされません。 ワークロード ID の条件付きアクセスを使用して、サービス プリンシパルを対象とするポリシーを定義します。
    • 組織のスクリプトまたはコードでこれらのアカウントが使用されている場合は、それをマネージド ID に置き換えることを検討してください。 これらの特定のアカウントは、一時的な回避策として、ベースライン ポリシーの対象外にすることができます。

適切な質問をする

ここでは、割り当てとアクセス制御に関する一般的な質問をいくつか示します。 ポリシーを構築する前に、ポリシーごとに質問に対する回答を文書化します。

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

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

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

このポリシーは、いずれかのアプリケーション、ユーザー操作、または認証コンテキストに適用されますか? はいの場合:

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

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

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

条件

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

Microsoft Entra ID P2 ライセンスを持つ組織では、条件付きアクセス ポリシーにユーザーとサインインのリスクを含めることができます。 これらを追加すると、ユーザーまたはサインインが危険と見なされる場合にのみ、多要素認証またはセキュリティで保護されたパスワードの変更を要求することで、セキュリティ対策の摩擦を軽減することができます。

リスクとポリシーでの使用の詳細については、記事「リスクとは」を参照してください。

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

次の 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 の推奨事項をデプロイするのに便利な方法です。 緊急アクセス アカウントは必ず除外してください。

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

次のツールを使用して、変更の前後の両方でポリシーの効果を評価することをお勧めします。 シミュレートされた実行により、条件付きアクセス ポリシーの影響を把握できますが、適切に構成された開発環境での実際のテスト実行に代わるものではありません。

ポリシーをテストする

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

テスト ユーザーを使用して、テスト計画で各テストを実行します。 テスト計画は、予想される結果と実際の結果を比較するために重要です。 次の表は、いくつかのテスト ケースの例の概要です。 実際の条件付きアクセス ポリシーを構成する方法に基づいて、このシナリオと予想される結果を調整します。

ポリシー シナリオ 予測される結果
リスクの高いサインイン ユーザーが未承認のブラウザーを使用してアプリにサインインする サインインがユーザーによって実行されなかった確率に基づいてリスク スコアを計算します。 ユーザーは MFA を使用した自己修復を要求されます
デバイス管理 承認済みユーザーが承認済みデバイスからサインインしようとする アクセスが許可されます
デバイス管理 承認済みユーザーが承認されていないデバイスからサインインしようとする アクセスはブロックされます
危険なユーザーのパスワード変更 承認されたユーザーが、侵害された資格情報でサインインしようとする (リスクの高いサインイン) ユーザーはパスワードを変更するよう求められるか、ポリシーに基づいてアクセスがブロックされます

運用環境でデプロイする

ユーザーがレポート専用モードを使用して影響を確認したら、管理者は [ポリシーの有効化] トグルを [レポート専用] から [オン] に移動できます。

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

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

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

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

    注意事項

    ユーザーを信頼できる状態でのみ、除外は控えめに使用してください。 ユーザーはできるだけ早くポリシーまたはグループに追加し直す必要があります。

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

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

ユーザーが条件付きアクセス ポリシーに関する問題を抱えている場合は、トラブルシューティングを容易にするために次の情報を収集します。

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

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

エラー メッセージの例と詳細のスクリーンショット。

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

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

関連するコンテンツ