条件付きアクセス制御設定で考慮すること

Microsoft Entra IDの条件付きアクセス制御設定は柔軟性が高く、シンプルな構成から複雑な構成まで幅広く対応できます。

条件付きアクセス制御設定は概念が広く、他システムを含めた設計思想が絡みます。正解が1つではないことから整理が抽象的に終わってしまい、ゴールが曖昧になりがちです。

しかし、要件が曖昧なまま実装を進めると、後から例外対応に追われるリスクがあります。そこで本記事では、設計段階で考慮すべきポイントを整理しました。

本記事の対象は、条件付きアクセス制御の設計者とレビュー担当者になります。基本ルール、設計の進め方についての工夫や注意点を分かりやすく解説します。

条件付きアクセス制御設定の基本ルールには以下があります。

条件付きアクセス制御を利用するには、Microsoft Entra ID P1またはP2ライセンスが必要です。

ライセンスがないアカウントを条件付きアクセス制御の適用範囲にした場合、ライセンス違反になる可能性があります。テナント上のすべてのユーザーにライセンス適用が出来ない場合は、ライセンスが適用されているユーザーのみ条件付きアクセス制御の対象とする構成にするのが良いでしょう。

条件付きアクセス制御設定機能に注目すると、Microsoft Entra ID P2ライセンスでは、ユーザーリスクとサインインリスクの判定結果によるアクセス条件を構成できます。

Intuneのライセンスがある場合、組織が想定しているセキュリティ設定が適用されているかを条件にアクセス条件を構成可能です。Intuneでは、さらにMDEと組み合わせをしてデバイスのリスクレベルを条件にセキュリティ設定の判定をすることができます。

MDCAのライセンスがある場合、クラウドアプリのセッションリスクやリアルタイム制御（コンテンツのダウンロード禁止など）を条件に利用することが可能です。

本記事では、Microsoft Entra ID P1ライセンスに限定するため、連携できるライセンスに関する詳細については割愛します。

ユーザー、クラウドアプリケーションなどのリソース、場所、デバイスなどで指定できます。

条件の適用範囲は、対象と対象外を定義でき、対象外が優先されます。

許可と拒否が重複した場合、拒否のルールが優先されます。

条件をまとめたものをポリシーと仮定した場合、ポリシーは集約して評価されます。実行順序や優先順位の設定機能はありません。ポリシーの組み合わせの結果が最終的な動作になります。

以下のようにポリシー内の条件をすべて満たす構成の場合、テナントAとテナントBの構成内容の結果は同じです。

条件はサインイン時に評価されます。条件の適用範囲の場合、生体認証や証明書などのあらかじめ設定した条件を満たせないとアクセス許可されません。条件の適用範囲に一致するものがない場合、パスワード認証を通過すればサインインが可能になります。

なお、サインイン時の評価は初回認証での話です。他にもトークンと呼ばれるアクセスの有効期限を更新する場合、特定のアプリや機能での操作時（認証コンテキスト要求）でも評価されます。こういった機能の詳細については本記事では割愛します。

条件の適用範囲は、まず広い範囲から決定し、その後により細かい範囲を設定します。

適用範囲としては以下がありますが、要望から要件に落とし込む際に検討する項目となるため、要望時点では考慮は後回しで問題ありません。基本設計をする際に考慮を行います。