2020年から2022年まで毎年4月に開催していたMicrosoft 365 Virtual Marathonというオンラインイベントがあったのですが、その中で私は「失敗しない条件付きアクセス」というシリーズを発表していました。
条件付きアクセスは企業での導入も一巡し、
・ 条件付きアクセスを見直したい
・ 条件付きアクセスの運用を引き継ぎたい
などの声が聞こえてくるようになりました。
そうした方にお役に立てればと思い、これまでのイベントでお話しした内容を2025年版に書き換えて、まとめ記事を書くことにしました。
条件付きアクセスとは
Microsoft Entra IDはクラウドサービスを連携させ、シングルサインオンを実現することができるサービスです。一方でクラウドサービスへのアクセスは誰でもアクセスできるのではなく、一定のアクセス制御をしたいと考えると思います。
そんなときに条件付きアクセスはそのアクセス制御を行うための機能としてMicrosoft Entra IDから設定して利用します。
アクセス制御機能そのものはMicrosoft Entra IDでクラウドサービスを連携させるときに利用するエンタープライズアプリケーションという設定からユーザーやグループの単位で設定できます。
しかし、ゼロトラスト全盛のこの世の中ではもっと色々な要素をもとにアクセス制御したいと考えると思うのです。IPアドレスでアクセス制御したい、特定デバイスからだけアクセスさせたいなど、あると思うのでエンタープライズアプリケーションとは別に条件付きアクセスではご覧のような設定項目用意して多彩なアクセス制御ができるようになっています。
条件付きアクセスの設定は大まかにいうと
・ユーザー/グループの設定
・アクセス制御対象となるクラウドサービス (クラウドアプリ) の設定
・それ以外の条件設定
・以上の条件を満たしたときの許可/拒否設定
から構成されます。実際の画面はこんな感じです。
これらを設定した「かたまり」をポリシーと呼ぶのですが、ポリシーは条件項目を除く、すべての項目を必ず設定しなければなりません。ちょっと実例を挙げてみてみましょう。
例：管理者は多要素認証を必須とする
Microsoft Entra IDでグローバル管理者などの割り当てがされているユーザーは大事なユーザーなので多要素認証を必須にしたい、よくある話だと思います。それを条件付きアクセスで設定するとこんな感じになります。
ユーザーのところにはロール(管理者権限)が割り当てられたユーザー、クラウドサービス(アプリ)はすべて、そして許可/拒否設定は多要素認証に成功すれば許可するように構成しました。このようにポリシーを作るときは、条件以外の項目は必ず設定しなければなりません。
例：ブラウザーからのみOffice 365へのアクセスを許可
次の例は条件の項目も使ってアクセス制御するパターンで、ブラウザーからのみOffice 365へのアクセスを許可する設定です。条件付きアクセスは許可/拒否の欄を見てもらうとわかるのですが、単純に拒否する設定はあるけど、単純に許可する設定はないんですね。
だから「ブラウザーだったら許可」ではなく「ブラウザー以外は拒否」というルールを作ります。
単純に許可するルールが作れないのは「条件付き」アクセスなので、条件を設けてその条件をクリアしないとアクセスできないようにさせることが目的の機能だからなんです。ファイアウォールルールみたいに「許可するものを決めて、それ以外はすべて拒否」というルールの作り方とは異なるのです。
これが条件付きアクセスを難しくしている部分なんですよね..
例：Windows PCがブラウザーアクセスしたときのみOffice 365へのアクセスを許可
今度は前の例の応用編で「Windows PCだったら」という条件を加えてみました。
なんとなくOS種類の欄に「Windows以外だったら」という条件を入れておけば良さそうな気がしますが、これは誤りです。
今回設定したい条件が
・ブラウザー以外のアクセスは拒否
かつ
・Windows以外のアクセスは拒否
の場合、必要な設定を全部ひとつのポリシーにまとめて入れてしまうと条件項目内の複数の条件はAND条件で処理されますので
・ブラウザー以外かつWindows以外のアクセスは拒否
となってしまうです。
両者は似ているように見えますが、上記のポリシーだと次のような場合はアクセス拒否されないのです。
・macOSでブラウザーアクセスした場合
・WindowsでOfficeアプリからアクセスした場合
ブラウザーを使っていればOS関係なくブロックしたいし、Windows以外のOSを使っていればクライアントアプリの種類は関係なくブロックしたい。
このような時はブラウザー以外またはWindows以外のアクセスは拒否と設定することが必要なのです。ひとつのポリシーに必要な設定を全部入れてしまうのではなく、ポリシーを2つに分けて作ります。
例：社内からのアクセスは Windows と iOS のみ、
社外からのアクセスは iOS のみOffice 365へのアクセスを許可
だんだん複雑になってきましたね。
でももう一つだけお付き合いください。
Windows PCは社内で使うもの、外出先ではiPhone使いなさいっていうパターンがあったとしましょう。この場合はポリシーをどうやって作りますか？
私はこう考えました。
・WindowsとiOS以外はすべて拒否
・Windowsデバイスは社内以外のIPアドレスからは拒否
そうすれば社内からのアクセスは Windows と iOS のみ、社外からのアクセスは iOS のみアクセスできるようになりますよね
でもこのパターンって色々トラブルが起きるのです。
次からはその点についてみてみましょう。
例：IT担当者が緊急対応できなくなった！
前のポリシーではユーザーとクラウドサービスは「すべて」になっていました。しかしヒューマンエラーでポリシー設定を間違えたら、誰もどのクラウドサービスにも (もちろんMicrosoft Entra管理センターにも！) アクセスできなくなります。
また、ありがちなケースとして外出先からIT担当者緊急対応しなければならない場合とかも出てくると思います。そんな時にWindowsデバイスは社内からしかアクセスできないポリシーを作られたら困るのです。
だから「すべてのユーザー」は「管理者以外のすべてのユーザー」として管理者だけこのルールから除外するように構成します。
例：社内IPアドレスが固定されていない！
条件項目の[場所]の設定はIPアドレスを決め打ちで入れます。
だから社内からインターネットに出ていくときのIPアドレスが固定アドレスでなければ、知らない間にIPアドレスが勝手に変わってしまい、ある日突然アクセスできなくなるなんて問題が起きるのです。
こうなると社内って定義が難しくなってくるので、そのようなときはクラウドプロキシを使ってIPアドレス(範囲)を固定させておけば、クラウドプロキシ経由でアクセスしたときだけアクセス許可するという、なんとなくの問題解決ができると思います。
(ポリシー1については前回から変更がないので省略しました)
そもそもやりたいことってなんだっけ？
ここまで条件付きアクセスを利用するための機能の話をしましたが、ここまで面倒なことをしてやりたいことって「信頼できるアクセスを認める」ってことだったのではないでしょうか？その会社が会社支給のデバイスを配って利用してもらっているのであれば、考え方のひとつとしてIPアドレスで制限するのではなく、デバイスの種別でアクセスする方法を考えてもよいのです。
会社支給のデバイスを定義する方法としては
・Microsoft Entra IDに登録されたデバイスを会社支給とみなす
・Microsoft Intuneに登録されたデバイスを会社支給とみなす (後で触れます)
このいずれかの方法を利用して条件付きアクセスを設定すれば「信頼できるアクセスを認める」に相当するような設定になるのではないかと思います。ちなみにMicrosoft Entra IDに登録されたデバイスを会社支給とみなすポリシー設定はこちら
ポリシーをシンプルに
ここまでの内容を見ていただいて気が付いた方もいると思います。
条件付きアクセスポリシーはシンプルに構成しないと永続的な運用は無理だなと。
じゃあどうすればシンプルになるのでしょうか？
いろんな考え方が存在すると思いますが、ここでは取り上げたいのは「評価軸を決めること」です。何もないところからポリシーを作成すると、1つ目に作成したポリシーと2つ目に作成したポリシーの間に整合性の問題はないか？など気になるのです。条件付きアクセスでは複数のポリシーを作成しても、それぞれのポリシーには優先順位という考え方がないので、すべてのポリシーが評価対象になります。そのため20個のポリシーを作成すれば、20個のポリシーすべてが評価対象になるのです。20個全部が割り当てられた結果、なにが適用されるかってわかると思います？
だからこそ評価軸を決めてから作成すべきポリシーを細分化していくのです。
上の図は2019年にマイクロソフトの製品開発チームが公表したベストプラクティスポリシーです。この図では全員(ロックダウンポリシーグループ部分)、管理者(特権アカウント部分)、通常ユーザー、ゲスト、緊急管理者(Break Glassアカウント部分)のようにユーザー種別を軸にしてそれぞれのユーザー種別で別々のポリシーを作成するように構成しているのです。
そうすれば誰に何が割り当てられるかわかりやすくなると思います。
ベストプラクティスポリシー
ベストプラクティスポリシーを順番に見てみましょう。
(と言いたいのですが、2019年と2025年では条件付きアクセスでできることも変わっているのでちょっと私のほうで手を加えました)
まず全員一律設定するポリシーから。
このポリシーではレガシー認証 (基本認証) のような多要素認証を使わないでアクセス可能なサービスへのアクセスをブロックしています (証券会社の口座が乗っ取られる事件もこれが原因でしたよね)。このようにセキュリティ上の理由から全員に適用すべき設定などはこの領域を使います。
次に管理者を対象としたポリシー。
管理者は多要素認証を必須とします(ホントは全員に必須にしてほしいけど)。
次にゲストユーザーを対象としたポリシー。
ゲストユーザーが弊社のクラウドサービスにアクセスする場合、弊社が定める利用規約 (ToU) に沿ってアクセスしてほしいので利用規約画面を出しておいて同意したらクラウドサービスへアクセスできるようにします。利用規約設定はMicrosoft Entra管理センターから事前に作成しておくと、条件付きアクセスポリシー設定の許可/拒否設定から選択できるようになります。
最後に通常ユーザーの場合。
通常ユーザーの取り扱いは会社によって異なるけど、会社支給のデバイスからのアクセスだけを許可するのであればIntune登録 (Intuneの話はあとでします) またはEntra登録/参加/ハイブリッド参加のみを許可するように構成します。ちなみにMSさんのベストプラクティスだと要MFAと書いてあるのですが、これは普段使いの会社支給デバイスが使えなくなってしまったときの緊急対応として多要素認証がちゃんとできれば会社支給デバイスでなくても良いよという設定になっています。
ここまでで見てもらったベストプラクティスは皆の会社のベストプラクティスではなく、あくまでもシンプルにポリシーを作成・運用するための考え方をお伝えしたのです。
実際、R001の要MFAはいらないよね？とか、クラウドサービスの種類ごとにアクセス制御設定は変えたいよね？とか会社ごとに異なるニーズがあるはずです。
そうしたものは何もないところから設計するのではなく、こうしたベストプラクティスから自分の会社のベストプラクティスを作り上げてください。
ベストプラクティスを作り上げたい、練り直したいなどのご要望がありましたら、私が直接会社に伺ってレクチャーをしながら御社の環境に合わせたベストプラクティスを作り上げていく超実践講座もありますので、ご興味があればお問い合わせください。
Microsoft Intuneと連携して利用する
ここからは条件付きアクセスの基本機能と組み合わせて利用可能な機能を見てみます。
条件付きアクセスは条件付きアクセスの中にある設定項目だけが条件として設定可能な項目というわけではなく、ほかのクラウドサービスから得られた情報をもとにアクセス制御することができます。その方法のひとつとして、Microsoft Intuneの情報を活用する方法があります。
条件付きアクセスではMicrosoft Intuneに登録されていないデバイスをブロックすることができる話をしました。この設定ですが、もうちょっと厳密に話をすると以下の3つの条件を満たすデバイスだけがアクセスを許可するものになっています。
１．Microsoft Entra IDに登録していること
(登録/参加/ハイブリッド参加いずれもOK)
２．Microsoft Intuneに登録していること
３．コンプライアンスポリシーに準拠していること
コンプライアンスポリシーとはMicrosoft Intuneで設定可能なポリシーで会社で定める条件に準拠しているかをチェックするためのポリシー設定です。ここでチェックしたポリシーのチェック結果に基づいて条件付きアクセスではアクセス制御できるので、言い方を換えればコンプライアンスポリシーは条件付きアクセスの拡張機能って言い方ができると思います。
コンプライアンスポリシーを使ったアクセス制御
コンプライアンスポリシーは Microsoft Intune管理センター画面の [デバイス] – [コンプライアンス] から設定できるポリシーでOS種類別に異なるポリシーが作成できます。
例えばWindowsの場合で話をすると、BitLockerが有効であるか？OSのバージョンが24H2以上であるか？ウイルス対策ソフトが有効であるか？などの条件を設定し、その結果に基づいて準拠/非準拠の判定を行います。
なかでも汎用性が高いのがカスタムコンプライアンスと呼ばれる設定で、Windows PowerShellを使って特定の機能のチェックを行うことができます。
PowerShellを使えば、なんでもチェックできるので「レジストリの設定がxxxxだったら」とか「特定のセキュリティソフトがインストールされていたら」とか好きなことをチェックできます。ただし気を付けたいのはコンプライアンスのチェックは常にリアルタイムでチェックするわけではないということです。準拠/非準拠の判定はリアルタイムで行われるわけではないので、その点を踏まえて何をチェックするかを決めていくとよいでしょう。
Microsoft Entra ID P2と連携して利用する
条件付きアクセスの設定自体はMicrosoft Entra ID P1のライセンスがあれば利用できますが、P2までのライセンスを持っているとリスクベースの条件付きアクセスができます。
Entraユーザーによるサインインをチェックして不正アクセスの疑いのあるサインインを検出したり、ユーザーそのものが侵害されている疑いのあるものを検出するサービスとしてMicrosoft Entra Identity Protectionと呼ばれるサービスがありますが、このサービスを条件付きアクセスと組み合わせたものがリスクベースの条件付きアクセスです。
リスクにはサインインリスクとユーザーリスクがあり、それぞれのリスクはIdentity Protectionで不正アクセスを検知すると、検知した事象に対して高・中・低のようなリスクレベルを自動的に設定します。そのレベルが一定以上のものの時に条件付きアクセスで拒否したり、追加で多要素認証を要求したりすることができます。
ただリスクレベルはどのような時に、どのレベルのものが出力されるかわからないので、一律で拒否するような運用をしてしまうと誤検知の時に面倒なことになります。
Microsoft Defender for Cloud Appsと連携して利用する
条件付きアクセスでアクセス制御ができるクラウドアプリはエンタプライズアプリケーションに登録されたアプリであることが前提条件ですが、その中でもSAMLプロトコルを利用してシングルサインオン設定をしているとき限定で利用可能な連携がMicrosoft Defender for Cloud Apps (MDA) と連携する方法です。
条件付きアクセスの設定を行う際、これまで許可/拒否の設定でアクセス制御を行ってきましたが、許可/拒否の設定の代わりにセッションという項目を利用することができます。
このセッション項目の中に用意されているのが [アプリの条件付きアクセス] と呼ばれるもので、この項目を有効にするとアクセス許可/拒否の判断をMDAに丸投げすることができます。
MDAではアクセスポリシーまたはセッションポリシーと呼ばれるポリシーを作成して条件設定ができ、
アクセスポリシーではクラウドアプリへのアクセスの許可/拒否設定
セッションポリシーではクラウドアプリへのアクセス中の特定操作の制限
を設定できます。
アクセスポリシーの場合、基本的には条件付きアクセスの中で設定できるようなことと同じようなことが設定できるのですが、アクセスポリシーならでの設定としては証明書がインストールされているか？を条件にアクセス制御することができます。
あらかじめ認証局のルート証明書をMDAに登録しておき、その認証局から発行された証明書を各デバイスにインストールしておくことで、証明書の有無をもとにアクセス制御できるのです。
一方のセッションポリシーはクラウドアプリへのアクセスそのものは許可するのだけれども
クラウドアプリの画面内での印刷やコピペなどの操作をブロックするという設定ができます。
物理デバイスにコピペできなくするってシンクライアント的な発想の機能なので、
VDIを導入したいけどコストが.. なんて方にはお勧めだったりします。
ちなみにSharePoint OnlineとExchange Onlineの場合はMDAを利用しなくてもSharePoint OnlineとExchange Onlineのコピペなどを禁止するように設定することが可能です。
Microsoft 365 の機能を活用したベストプラクティスポリシー
ここまでのところで Microsoft 365 E3やE5のライセンスで提供される機能を条件付きアクセスと組み合わせて利用する方法を見てきたので、これを踏まえたベストプラクティスポリシーを見てみましょう。
ここからお見せするポリシーは私がオリジナルで作ったものなので異論・反論大歓迎ですｗ
参考までに条件付きアクセスの標準機能だけで作ったポリシーはこんな感じでした。
まず最初にIntuneのカスタマイズをしましょう。
Microsoft 365使うならIntuneを使って管理するのは当然だよね？ということで、Intuneに準拠しているデバイスであることを前提にしてみました。コンプライアンスポリシーで設定する条件はここでは特に指定しません (会社によってやりたいことも違うでしょうから)。
一方、万が一Intune登録していないデバイスからのアクセスがあった時のためにMFAを通過すればアクセスできるオプションは残してあります。
次にMDAとの連携パターンを入れたポリシーを作ってみます。MSアプリ ＝ Office 365 の場合、ブラウザーからアクセスするパターンとOutlookなどのアプリからアクセスするパターンがあります。
アプリからアクセスするデバイス
＝ アプリをインストールしているデバイス
＝ 会社支給デバイス
と考えました。一方、ブラウザーからアクセスは会社支給のデバイスでなくてもアクセスできてしまう可能性があると考え、MDAのセッションポリシーを使ってコピペとダウンロードを禁止するポリシーを作ってみました。
同じようなことはその他のクラウドサービスに対して設定していただいても良いでしょう。
ただし、SAML連携していることが前提条件であることをお忘れなく。
デバイス種類ごとに条件付きアクセスポリシーを設定する
ここまでは機能をベースに必要なポリシー設定を見てきましたが、最後に視点を変えてデバイス種類ごとに必要な条件付きアクセスポリシーについて考えてみたいと思います。
業務利用のデバイスを大きく分類すると次の3つにわけることができると思います。
・COBO＝会社支給のデバイスで業務以外の利用を禁止
・COPE＝会社支給のデバイスだけどガチガチな管理はせず、個人利用も許容
・BYOD＝個人所有のデバイス
これらをOS種類別にして、それぞれをMicrosoft 365の持つ機能で分類しようとするとこんな感じの分類ができるかと思います。※BYODデバイスをIntune登録するのか？という点については賛否ありますが..
ここからCOBO, COPE, BYOD すべてのアクセスを許可するのであれば単純にIntune登録されていればアクセスを許可するとポリシー設定すればOKです。
一方、COBO, COPEだけ認めてBYOD禁止という運用をするのであれば、ここで書いた分類のうち、COBO, COPEだけ認めるポリシーを作ります。
上の画面でCOBO, COPEにあって、BYODにないものってなんだかわかりますか？
それは所有権が会社なのか？個人なのか？という点です。
こちらの画面はIntune管理センター画面です。Intuneに登録されたデバイスはどのように登録されたかによって必ず所有権が企業(会社)または個人に分かれて登録されます。
Intuneにデバイスを登録する際、COBO, COPEに書いた登録方法を採用すると所有権が会社として設定されます。それに対してBYODに書いた登録方法を採用すると所有権が個人として設定されます。これを利用して所有権が会社のデバイスだけを許可する設定を作ります。
以上を踏まえてポリシーを以下のように作るとIntune登録されていないデバイスはブロックされ、さらに所有権が個人のものがブロックされるので、所有権＝会社のデバイスだけがアクセスできるようになります。
まとめ
ここまでのところで条件付きアクセスについて、Microsoft 365 Virtual Marathonセミナーで解説した内容を2025年版としてまとめ記事を書いてみました。企業の要望によって、ここに書いてある通りのポリシーの作り方をすることが正解とは限らないこともあるでしょう。
しかしこのような基本的な考え方をもとにご自身の企業における状況を照らし合わせていけば、何をすべきかのヒントが得られるのではないかと思います。
