ゼロから始める Intune 入門②条件付きアクセス

さて、前回は Intune ってそもそも何？というところと、コンプライアンスポリシーで準拠、非準拠の判定ができるというところを紹介しました。今回は条件付きアクセスについてです。

条件付きアクセスって何？

どちらかというと Entra の機能なのですが、 Intune 側からも設定できます。

あるアクセスについて「ダメです」と拒否したり「○○を満たせたらいいよ」と許可したりできます。

ところで、あなたが建物の管理人だったとします。この建物には会議室と金庫があります。入り口にいると、人がやってきました。顔がサングラスやマスクでおおわれており、よく見えません。中に入れますか？

入れませんよね。誰だかわかりませんし。

でもよく見ると、建物の入館証を持っています。中に入れますか？

多分入れませんよね。入館証の持ち主本人かわかりませんし。

マスクとサングラスを外してもらうと、よく見る従業員であり、入館証の写真とも一致します。
中に入れるでしょうか？

会議室には入れるかもしれませんが金庫には入れませんよね。

実は従業員が役員であり、金庫の前の指紋認証をしたら金庫の扉があきました。

それであればまあ、入れますよね。

と、このようにこの人が「誰」で「それを示す証拠」もあって、かつ「認証」もクリアできて、「何（どこ）にアクセス」しようとして…と「条件」を確認したうえで追加の要件を満たしていればアクセスしていいよ、とするのが「条件付きアクセス」です。逆に「出禁」になっている人がいたら問答無用で追い返す（禁止）も可能です。

条件付きアクセスポリシー

条件付きアクセスの基本は「ポリシー」です。ルールに合致したアクセスだった場合（これを「割り当て」という）、許可か禁止かを決めます（これをアクセス制御という）。許可の場合も基本的には追加で何かを要求します。

• ルールに合致しなかった場合、ポリシーは適用されません。たとえば社長が来たら入館証の提示もいらずに顔パス・・・みたいなこともできます。
• 複数ポリシーを作った場合、複数のルール（割り当て）に合致した場合、すべてのポリシーが適用されます。どれか一つでも拒否とみなされればアクセスできません。

割り当て

一つずつ見ていきましょう。

ユーザー

まずはユーザーです。これはシンプルに、このポリシーの対象となるのは誰ですか？ということです。

全てのユーザーとすることもできますし、特定のユーザー、特定のグループとすることもできます。または外部のユーザーに限定して適用…とすることもできます。
さらに「対象外」のユーザーも設定できます。以下の例だと「すべてのユーザーに適用するけど、竹内由香さんだけ除外」みたいなことができるわけですね。

ターゲットリソース

次に、ターゲットリソースですが、リソース（クラウドアプリ）とユーザー操作、認証コンテキストの3種類があります。
ユーザー操作…デバイスを登録・参加させたりセキュリティ情報を登録したりといった「操作」に対して適用
認証コンテキスト…別途触れますが、興味のある方はこちらをご確認ください。

ここではおそらく一番触れる（と思われる）「リソース」について説明します。
かっこ書きであるとおり「クラウドアプリ」にアクセスする場合、ポリシーを適用（割り当て）しますよ、ということです。クラウドアプリって何かというと、Entraで認証してアクセスする（アプリ、リソース、サービス）のことです。それってOffice 365のこと？もちろん、Office 365も含みますが、その他会社（テナント）で利用しているアプリも含みます。例えばSalesforceを利用していればそれも対象に含めることができます。

具体的に見ていきましょう

ターゲットリソースを選択し、このポリシーが適用される対象を選択する「リソース（以前のクラウドアプリ）」を選択します。「選択」をクリックすると、右ペインにリソースの一覧が表示されます。
検索ペインに適当に Teams とか Forms とか Sway とか 365サービスを入れていただければ該当するサービス（リソース）がでてくるとおもいます。

これは、 Entra ID に登録されているアプリのサービスプリンシパルになります。Entra管理センターから、エンタープライズアプリをクリックして「エンタープライズアプリケーション」のフィルタを解除していただければ同じリストを見ることができます（ややこしい・・・）

「Office 365」というのもありまして、こちらを選択すると SharePoint, Teams, Exchange 等が一通り含まれます。

「選択」の上に「フィルターの編集」というのもありますが、こちらはEntra IDで「カスタムセキュリティ属性」というものを定義してあげて、各アプリに手動で属性及び値を設定していきます。その属性値によってアプリをフィルタすることができます。

ネットワーク

次に「ネットワーク」を見ていきます。これは要するに「Aさんが日本からアクセスしてきた場合」「Aさんがフランスからアクセスしてきた場合」で条件を変えたい場合などに使います。

あらかじめ条件付きアクセスの「ネームドロケーション」という項目でロケーションを定義しておきます。

「国をIPアドレス帯で指定」「国をGPS座標で指定」「会社等をIPアドレス帯で指定」などが可能です。

条件

割り当ての最後は「条件」を指定します（条件付きアクセスの条件…）

「ユーザーのリスク」「サインインのリスク」「インサイダーのリスク」はそれぞれEntra ID Protection及び Purview Insider Risk Management で評価されるリスクです。
デバイスプラットフォームはユーザーがアクセスに利用しているデバイスが何なのかを指定できます。

ユーザーと同様「対象」と「対象外」を設定できるので、「WindowsとiOSだけ対象」「Windows 以外対象」といった指定が可能です。
「場所」は「ネットワーク」と一緒です。

クライアントアプリはその名の通り、どんなアプリを使ってリソースにアクセスしようとしているの？ということを選択できます。

先進認証の場合「ブラウザー」をつかっているか「アプリ」（＝モバイルアプリ＆デスクトップクライアントアプリ）の2択です。例えばTeamsだと、TeamsのURL か「Teamsデスクトップアプリ＆Teamsモバイルアプリ」のどっち？ということになります。「iPhone のTeamsアプリ」を指定したい場合は前述のデバイスプラットフォームと組み合わせて指定することになります。

レガシ認証クライアントは例えば以下のようなものが該当します。
Exchange ActiveSync クライアント…iOS標準メールアプリ、Android標準メールアプリ
その他のクライアント…古いOutlookやEWSを使うアプリ
たとえばiOS標準メールアプリじゃなくてOutlookを使ってほしい場合などは、条件付きアクセスポリシーが有効そうです。

残りの設定は以下の通りです
デバイスのフィルター…deviceIDやdeviceNameで特定の端末を指定したり除外したりできる
認証フロー…入力が制限されている（サイネージのような）とか、セッション情報を他のデバイスに転送する（デスクトップアプリにQRコードが表示されそれをモバイル端末で読み込んでモバイルでログイン状態を引き継ぐとか）といったものを制御するときに利用します。

アクセス制御

さて、ここまで「割り当て」を説明してきました。これらを設定することによりこのポリシーの対象となるアクセスを特定することができます。
「開発部門のメンバーが Windows を使ってブラウザー経由で Office 365 に社内からアクセスしようとしたとき」
「営業部門以外のメンバーが macOS か iPhone を使って Salesforce に社外からアクセスしようとしたとき」
といった具合ですね。

許可

じゃあこれをどうするの？ブロックするの？許可するの？というのが次の項目になります。

まず「アクセスのブロック」を考えます。これは「割り当て」で対象となったアクセスを「禁止」するということなので簡単です。次に「アクセス権の付与」ですが、これはアクセスしてもいいよ、という許可を意味しますが、そのままアクセスを許可するわけではありません。
上記の項目に該当する要件を追加で要求します。（いずれのチェックボックスもチェックを付けず、後述のセッションも設定しなければそのポリシーは作成・保存できません）

• 多要素認証を要求する

これは電話やAuthenticatorによる認証を要求する、ということになります。いわゆる「しっているもの（パスワード）」以外に「もっているもの」を要求するということですね。

• 認証強度が必要

上に少し似ていますが、Entraの「認証方法」→「認証強度」で定義したポリシーを適用します。

• デバイスは準拠しているとしてマーク済みである必要があります

前回触れた、Intuneのコンプライアンスポリシーで「準拠」と認定されたデバイスである必要があります。
実はコンプラポリシーはこれのために作ったということですね。

• Microsoft Entra ハイブリッド参加済みデバイスが必要

デバイスがEntraだけでなくオンプレのドメインにも参加している必要があるということです。（この段階でWindowsしかアクセスできないということになります）

• 承認されたクライアントアプリが必要です

該当するアプリでのアクセスしか認めません。こちらはAndroid/iOS用です。

• アプリの保護ポリシーが必要

Intune MAMでは「アプリ保護ポリシー」が設定できますが、それを設定しているアプリである必要があるということです。

• パスワードの変更を必須にする

多要素認証・認証強度と併用して、リスクの高いアクセスの場合にパスワードの変更を要求する、というものです。常に毎回毎回変更しなきゃダメというわけではありません。

そして、これらのコントロールは複数選択することが可能です。複数選択した場合「いずれか」なのか「すべて」なのかを指定できます。例えば

「多要素認証を要求し、かつ準拠デバイスでなければならない」
「アプリの保護ポリシーが適用されているか、承認されたクライアントアプリであるかのどちらか」

ということです。

注意
たとえば、「ハイブリッド参加が必要」「承認されたクライアントアプリが必要」をチェックし「すべてが必要」を選んだ場合、前者はWindowsのみ、後者はAndroid/iOSのみとなり矛盾してしまいます。その場合、ブロックされます。

セッション

こちらはセッション単位でより細かい制御を行うためのものです。詳細はこちらをご確認ください。たとえば、「重要システムなので1時間ごとに再認証を要求します」「BYOD端末からのダウンロードをブロックします」などが実現可能です。

まとめ

Intuneで「準拠」「非準拠」のマークを行い、条件付きアクセスでは実際に準拠であることを要求するとか、追加でどんな条件を必要とするのか、等を指定することができます。

警告
安易にすべてのユーザーに適用するポリシーを作成しないよう注意してください。場合によってはグローバル管理者がポリシーの対象となってアクセスがブロックされてしまいます。

ポリシーを新規に作成する場合には、「レポート専用」で作成し、サインインログを確認し想定しないユーザー・アクセスがポリシーの対象になっていないか確認してから、有効化（オン）にしましょう。

サインインログでレポート専用ポリシーが「成功」したか「失敗」したかを確認できます。