条件付きアクセスについて書いてみる
お約束
これは2025/1時点の情報を基に記載しています。
記載内容は個人の私見に基づくものです。
正確な情報が知りたい方は公式ドキュメントを参照してください。
条件付きアクセスとは
Microsof Entra ID P1以上のライセンスで使用可能な、アクセス制御機能です。
条件付きアクセスについては、MSサポートチームのブログがとても分かりやすいので、まずこちらを読むことをお勧めします。
このブログで重要なのは以下文章だと思っています
条件付きアクセスには明示的に許可するという機能や制御はありません。「指定した条件に合ったサインインに対してポリシーを適用し、制御を適用する」という仕組みであり、ポリシーの条件に合わないサインインに対しては、何らの制御も適用されません。
この記事の対象ユーザー
条件付きアクセスを使っているが、いまいちわかりづらいと思っている人（実際分かりづらいです）向けに、こういう考え方もあるという内容で書いています。
あくまで私が最近こういう考えだと分かりやすいかなと思った内容で書いており、細かいポリシーの作り方などは書いていません。ネット上には条件付きアクセスについての紹介情報は大量にあるので、いろいろと参考にするといいと思います。
条件付きアクセスの設定画面
新規作成する場合、この画面で構成を組んでいきます。
基本的な流れとして、制御対象ユーザーを指定して、どのサービスを制御するか指定して、どういう条件なら制御するかを指定します。
最後に指定した条件のユーザーを「ブロック」するか、「許可」するかのどちらにするか指定します。
ただし、「許可」にする場合は何らかの許可条件を付けなければなりません。
条件付きアクセスの考え方
条件付きアクセスは上述したように「ユーザー」が「サービス」にアクセスすることを制御する機能です。
しかし、設定するのは「管理者」になります。つまり、「管理者」が制御対象である「ユーザー」にどういうアクセスをさせたいかを設定する機能と考えれば分かりやすいと思います。
「管理者」視点で作る条件付きアクセスポリシー
条件付きアクセスは前述したようにアクセス制御の仕組みです。「管理者」はアクセス対象のサービスを守らなければなりません。
条件付きアクセスの説明をしているドキュメントの多くは、「ユーザー」がどの「サービス」に対してアクセスするのを制御する、という説明が多いです。
しかし、実際にサービスを守る設定をするのは「管理者」ですから、「ユーザー」を主体として考えるのではなく、「管理者」が、管理対象のサービスに対して、どのような条件でならアクセスを許可するのか、を指定するものだという考え方もありだと思います。
では、実際にこの考えで作ってみましょう。
「管理者」はサービスを守るため、サービスを使うためのアクセスルートを決めていきます。
例えば、あるサービスへのアクセスは、条件として「Windowsからのみ」のアクセスに制限したいとします。さらに許可条件として「Intune登録済み端末」、且つ、「多要素認証を必須」にします。
このように、条件と許可条件でサービスへアクセスするルートを決めます。
そして、アクセスルールが決まったら、それ以外のアクセスルートを全てブロックします。
上述したサポートチームのブログにある、「ポリシーの条件に合わないサインインに対しては、何らの制御も適用されません。」というのは、指定した条件のアクセスルートだけを制御しても、それ以外のルートががら空きになるので、条件以外のルートをブロックしないといけないということだと思います。
図にするとこんな感じです。
| 条件 | 許可orブロック | 許可条件 |
|---|---|---|
| Windowsからのみ | 許可 | Intune登録済み端末 and 多要素認証 |
| Windows以外 | ブロック | ー |
最後に、このアクセスルートで制御したいユーザーを決め、実際のポリシーを作成します。
ポリシーは出来るだけシンプルに
条件付きアクセスポリシーを作成する際は、組織のセキュリティ要件に沿ったうえで、出来るだけシンプルな構成にすることをお勧めします。
条件を複数にするほどブロックが大変になる
シンプルにする理由の一つとして、アクセスルートを複雑にするほど、ブロックポリシーの作成が大変になるというものがあります。
例えば、社給端末（Intune登録済み端末）だけにアクセスさせたい場合には、許可条件として「デバイスは準拠しているとしてマーク済みである必要があります」という許可条件を付けます。
実際にポリシーとして作るとこんな感じです。
このポリシーが有効になった場合、社給端末（Intune登録済み端末）からでないとすべてのサービス（Entra IDで認証するサービス）にアクセス出来なくなります。
条件を指定せず、許可条件だけにした場合は、許可条件が満たされないとアクセスが出来なくなります。つまり、条件を指定しないとブロックポリシーは必要ないので、ポリシーは１つで済みます。
では、これに条件を付けていきましょう。
まず、対象OSを「Windows」に限定します。
この場合、「Windows」以外のOSにはアクセス制御が効かなくなりますので、アクセスをブロックするためにWindows以外を条件としたブロックポリシーを作らなければなりません。ポリシーは2つになります。
さらに、社内からのアクセス（社内ネットワークからインターネットに出る際のグローバルIPを指定）を条件に加えます。
こうなると、ブロックポリシーは2つ必要になります。
- 「Windows」以外を条件としたブロックポリシー
- 「Windows」、且つ、「社内ネットワーク以外」を条件としたブロックポリシー
このように条件が増えるほど、アクセスルート以外をふさぐためのブロックポリシーが増えていきます。（これが結構面倒なのです）
最後に
今回は条件付きアクセスを書いてみました。便利な機能ですが、凝った制御をすればするほど分かりづらくなります。
せっかくのアクセス制御もブロック漏れで穴があると台無しになってしまいます。
作成や変更の際には十分ご注意ください。また、管理者の方向けとして、ご自身で作成していないポリシー（前任者から引き継いだポリシー等）の動きはきちんと把握しておくことをお勧めします。
「条件付きアクセスについて書いてみる」はこの1回で終わるつもりですが、新機能や興味深い内容があれば別途書くかもしれません。
Discussion