はじめに
Azure AD Identity Protection (以降 Identity Protection と呼称)は Azure AD Premium P2 ライセンスで利用できる Identity に関するリスクを検知、特定、保護する Azure AD の機能の一つで、Azure Advanced Threat Protection (Azure ATP) や Microsoft Cloud App Security (MCAS) とも連携して Identity を守ります。
一方、条件付きアクセスは Azure AD Premium P1 ライセンスで利用できる機能でユーザー、場所、デバイス、アプリケーションなどを対象に ID を保護する Azure AD の機能の一つで Azure AD で最も多く利用されている機能の一つでもあります。
この条件付きアクセスは Azure AD Premium P1 ライセンスの機能ですが、P2 のライセンスを持っているテナントの場合、「条件」として「サインインのリスク」という項目が選べるようになっており、設定対象のユーザーがサインインのリスクを検出した時に、「アクセス制御」で設定した制御が可能になっています。
-参考情報
サインイン リスク
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/conditional-access/concept-conditional-access-conditions#sign-in-risk
条件付きアクセスで設定できる「サインインのリスク」の実体は「Identity Protection」で、Identity Protection 自体が P2 ライセンスの機能になるので、P2 を持ってないと条件付きアクセスで「サインインのリスク」の機能が使えないのはそういう理由があります。
今回は Identity Protection で利用できる「サインイン リスク ポリシー」と条件付きアクセスで利用できる「サインインのリスク」をそれぞれ設定した状態でサインイン リスクを検知した際に、どのような動作になるかについて確認を行いました。
やってみる
まず前提として覚えていただきたいこととして、 Azure AD のサインイン ログは Azure AD が認証する際に「対話型サインイン」を試行した際に記録されます。
「対話型サインイン」というのは Azure AD の認証画面で「ユーザー名」と「パスワード」を入力して認証するイメージです。
この「対話型サインイン」を試行した際に IP アドレスを隠して「匿名 IP アドレス」としてアクセスした場合に「Identity Protection」が「リアルタイム」にリスクとして検出されます。
逆に言うと既に Azure AD から PRT などのトークンを発行された状態でユーザーがそのトークンを使ってサインインする(非対話型)際には Azure AD のサインイン ログには記録されません。
また、Identity Protection のリアルタイムで検出しない、「漏洩した資格情報」などの「オフライン」系のリスクについてはサインインしたタイミングではリスクが評価されない(できない)ので、「オフライン系」のリスクも検出されません。
サインイン リスクはユーザーが「対話型サインイン」を試行した際に「リアルタイム」系のリスクを検知した際に評価の対象となることを押さえておいてください。
上述の前提を把握いただいた上で、以下 3 パターンの動作検証を行ってみます。
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | |
| 2 | test003 | ブロック | test003 | 多要素認証要求 | |
| 3 | test003 | 多要素認証要求 | test003 | ブロック |
No.1 の検証目的は、Identity Protection と条件付きアクセスで異なるユーザーに対して異なる制御を設定した時に、それぞれが独立して動作するかの確認。
No.2 の検証目的は、Identity Protection と条件付きアクセスで同一のユーザーに対して「ブロック」と「多要素認証」を設定した時にどちらの制御が効くのかの確認。
No.3 の検証目的は、No.2 で設定した制御を Identity Protection と条件付きアクセスで入れ替えた時に No.2 と同じ動作になるかどうかの確認。
No.1 の検証
まず設定を行います。
Identity Protection のサインイン リスク ポリシーを以下のように設定しました。
ユーザー (test003)
条件 (リスク中以上)
制御 (ブロック)
条件付きアクセスのポリシーは以下のように設定しました。
ユーザー (test005)
条件 (サインインのリスクレベル「中」以上)
アクセス制御 (多要素認証を要求)
サインイン リスクを疑似的に発生させるためには Tor ブラウザーを利用することで簡単にできます。
Microsoft の公開情報にもリアルタイム系のリスクである「匿名 IP アドレスを」シミュレートするためには Tor ブラウザーを利用すると書いてありますので参考にしてみてください。
-参考情報
Identity Protection でのリスク検出のシミュレーション 匿名 IP アドレス
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-simulate-risk#anonymous-ip-address
ちなみに匿名 IP アドレスとは文字通りアクセス元の IP アドレスを隠してどこからアクセスしてきたのかを分からなくすることです。
Tor ブラウザーの本来の目的はインターネットを利用する際にプライバシーを保護するために開発されたものですが、自分の会社もしくは B2B 経由で利用しているビジネス パートナーがわざわざ自分の Azure AD テナント上のアプリケーションに匿名 IP アドレスでアクセスする必要があるでしょうか？
そのため上記のようなビジネス シーンにおいては Identity Protection は「匿名 IP アドレス」としてリスクとして判定します。
それでは test003 ユーザーで Tor ブラウザーを利用してアクセス パネル (myapps.microsoft.com) にサインインしてみます。
想定ではサインインしたタイミングでサインイン リスクが検出され Identity Protection によりアクセスがブロックされることが期待される動作です。
想定通りリスクとして検出されサインインがブロックされました。
下記画面ショットは「Identity Protection」がサインイン リスクとして検出した結果ブロックした画面になります。
次に、同じやり方で test005 ユーザーでアクセス パネル (myapps.microsoft.com) にサインインしてみます。
想定ではサインインしたタイミングでサインイン リスクが検出され条件付きアクセスにより多要素認証が要求されることが期待される動作です。
結果は、多要素認証は要求されず、test005 もブロックされてしまいました。
これはどういう事でしょうか…。Identity Protection と条件付きアクセスの制御はたとえ UPN が違っていても別々の制御方法が設定できないということでしょうか。
また、制御方法が「ブロック」と「多要素認証」で被っている場合は「ブロックが優先」されるようです。
これは、Microsoft の公式 Blog にもそのように書いてあります。あくまで「条件付きアクセス」の中での話だと思っていましたが、「Idenitity Protection」のポリシーの場合においても同様の動作になるようです。
-参考情報
Azure AD の条件付きアクセスに関する Q&A
URL:https://jpazureid.github.io/blog/azure-active-directory/qanda-conditional-access/
Q. どのような順序でアクセス制御が適用されますか。
A. ブロックが常に優先されます。これに次いで、次のような順序でアクセス制御が強制されます。
多要素認証
承認されたクライアント アプリ / アプリの保護ポリシー
マネージド デバイス (準拠済み / Hybrid Azure AD Join)
カスタム コントロール (利用規約を含む)
セッション制御 (ブラウザー セッションの有効期限など)
No.1 の検証結果は以下のようになりました。
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | test003 だけでなく test005 もブロックされる |
| 2 | test003 | ブロック | test003 | 多要素認証要求 | |
| 3 | test003 | 多要素認証要求 | test003 | ブロック |
No.2 の検証
ここで No.2 と No.3 をそれぞれ No.3 と No.4 に繰り下げて No.2 に No.1 の逆パターンを試してみます。
この場合想定される動作としては、「ブロック」が優先されて、test003 も多要素認証が要求されずにブロックされるはずです。
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | test003 だけでなく test005 もブロックされる |
| 2 | test003 | 多要素認証 | test005 | ブロック | |
| 3 | test003 | ブロック | test003 | 多要素認証要求 | |
| 4 | test003 | 多要素認証要求 | test003 | ブロック |
一度 test003 と test005 のパスワードをリセットした後に、No.2 を試してみます。
まず、Identity Protection のアクセス制御を「アクセスのブロック」から「多要素認証を要求する」に変更します。
条件付きアクセスの方は「多要素認証を要求する」から「アクセスのブロック」に変更します。
まずは test005 ユーザーで Tor ブラウザーを利用してアクセス パネル (myapps.microsoft.com) にサインインしてみます。
想定ではサインインしたタイミングでサインイン リスクが検出され条件付きアクセスによりアクセスがブロックされることが期待される動作です
想定通り条件付きアクセスによりブロックされました。
なぜ条件付きアクセスでブロックされたか分かったかというと、文言が No.1 と異なっています。
上記画面ショットは「アクセス条件を満たしていません。」と書いています、これは条件付きの条件を満たしていないため、アクセス制御で設定した「アクセスのブロック」が発動したことを意味します。
ブロックの画面を見比べてみましょう。
下記は Identity Protection によりブロックされた画面です。
下記は条件付きアクセスでブロックされた画面です。明らかに異なりますね。
つまり No.2 の検証の test005 は条件付きアクセスでブロックされたことが分かります。
では次に同じやり方で test003 ユーザーでアクセス パネル (myapps.microsoft.com) にサインインしてみます。
サインインしたタイミングでサインイン リスクが検出され Identity Protection により多要素認証を要求されるかブロックされるかどちらの動作になるのかを確認します。
test003 もブロックされましたが、条件付きアクセスではなく Identity Protection でブロックされました。
これはちょっと想定外の動作です。
想定では「条件付きアクセス」でブロックされると思っていました。
同じユーザーで複数回検出させているので、Identity Protection の AI が test003 は危険なユーザーと判定されてしまっていて正常な結果を得られていないと思いましたので、No.2 の検証を以下のユーザーに変更して試してみます。
(No.3 と No.4 も同じ事象になりかねないのですべて異なるユーザーで試してみます)
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | test003 だけでなく test005 もブロックされる |
| 2 | test013 | 多要素認証 | test012 | ブロック | |
| 3 | test014 | ブロック | test014 | 多要素認証要求 | |
| 4 | test015 | 多要素認証要求 | test015 | ブロック |
No.2 のテストとして test012 を条件付きアクセスポリシーのユーザーに追加します。アクセス制御は「アクセスのブロック」です。
No.2 のテストとして test013 を追加します。
Identity Protection のアクセス制御は「多要素認証を要求する」です。
条件付きアクセスで test012 がブロックされるのは検証しなくても分かるので、test013 がサインインしたタイミングでサインイン リスクが検出され Identity Protection により多要素認証を要求されるかブロックされるかどちらの動作になるのかを確認します。
結果、test003 と同じように一度もリスクを検知していない test013 においても Identity Protection では「多要素認証を要求する」アクセス制御にしているにもかかわらず、Idenitity Protection によりブロックされました。
ちなみに test012 で検証してみたところ、「条件付きアクセス」のポリシーでブロックされました。
ここまで来ると全く規則性が見いだせなくなってきましたが、No.2 までの検証結果をまとめると以下のとおりになります。
分かったこととしては、どちらか一方のポリシーに制御として「ブロック」があるとその時点で「ブロック」されることが確定するようです。
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | test003 だけでなく test005 もIdentity Protection でブロックされる |
| 2 | test013 | 多要素認証 | test012 | ブロック | test013 は Identity Protection でブロックされ、test012 は条件付きアクセスでブロックされる |
| 3 | test014 | ブロック | test014 | 多要素認証要求 | |
| 4 | test015 | 多要素認証要求 | test015 | ブロック |
No.3 の検証
こうなると No.3 と No.4 は明らかにブロックされるのでしょう、Identity Protection でブロックされるのか条件付きアクセスでブロックされるのかの違いの確認だけになりそうですがせったくなので試してみます。
test014 を Identity Protection のサインイン リスク ポリシーのユーザーに追加します。
アクセス制御を「アクセスのブロック」として設定します。
条件付きアクセスのユーザーにも test014 を追加します。
アクセス制御を「多要素認証を要求する」を設定します。
それでは test014 ユーザーで Tor ブラウザーを利用してアクセス パネル (myapps.microsoft.com) にサインインしてみます。
想定ではサインインしたタイミングでサインイン リスクが検出され Identity Protection によりアクセスがブロックされることが期待される動作です
想定通り、Identity Protection でブロックされました。
同一ユーザーに対して異なるアクセス制御を設定されている場合には「ブロック」が優先されるという条件付きアクセスのルールに則っていますね。
Identity Protection もそのルールに従うことが確認できました。
No.4 の検証
最後に No.4 の検証として test015 ユーザーで試してみます。
test015 を Identity Protection のサインイン リスク ポリシーのユーザーに追加します。
アクセス制御を「多要素認証を要求する」として設定します。
条件付きアクセスのユーザーにも test015 を追加します。
アクセス制御を「アクセスのブロック」を設定します。
それでは test015 ユーザーで Tor ブラウザーを利用してアクセス パネル (myapps.microsoft.com) にサインインしてみます。
想定ではサインインしたタイミングでサインイン リスクが検出され条件付きアクセスによりアクセスがブロックされることが期待される動作です。
想定通り、条件付きアクセスででブロックされました。
これですべての検証が完了しました。No.3 と No.４ の結果をまとめると以下のとおりになります。
| No | Identity Protection割り当てユーザー | Identity Protection制御 | 条件付きアクセス割り当てユーザー | 条件付きアクセス制御 | 結果 |
|---|---|---|---|---|---|
| 1 | test003 | ブロック | test005 | 多要素認証要求 | test003 だけでなく test005 もIdentity Protection でブロックされる |
| 2 | test013 | 多要素認証 | test012 | ブロック | test013 は Identity Protection でブロックされ、test012 は条件付きアクセスでブロックされる |
| 3 | test014 | ブロック | test014 | 多要素認証要求 | Identity Protection でブロックされる |
| 4 | test015 | 多要素認証要求 | test015 | ブロック | 条件付きアクセスでブロックされる |
まとめ
検証して分かったことは、まず、サインイン リスクをベースにした制御をする場合には、「Identity Protection」のサインイン リスク ポリシーか条件付きアクセスの「サインインのリスク」を両方設定するのではなく、どちらかに必ず寄せて運用する ということです、間違いなく混乱します。
次に、仮に双方のポリシーを設定してしまっている環境下で制御対象に同一ユーザーが存在している場合には「ブロック」が優先されるということです。
これは条件付きアクセス ポリシーが複数存在している場合にも当てはまる動作なのでイメージしやすいと思います。
また、公開情報にも書いてあるとおり、サインイン リスク ポリシーは「アクセスをブロック」するのではなく「多要素認証を要求する」を推奨しています。
-参考情報
方法:リスク ポリシーを構成して有効にする ポリシーを有効にする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/identity-protection/howto-identity-protection-configure-risk-policies#enable-policies
[アクセス] - Microsoft で推奨しているのは、 [アクセスを許可] と [多要素認証が必要です] を設定することです。
理由はサインイン リスクのあるアクセスが試行された時に「アクセスをブロック」することは確かに効果はありますが一時しのぎにしかなりません、結局パスワードを変更しない限りは悪意のあるアクターにサインインされてしまう可能性が残っているためです。
そういう意味でも条件付きアクセスで「サインインのリスク」を設定している状態で Identity Protection のサインイン リスク ポリシーを設定すると「アクセスがブロック」される動作が起こりうるので重複しないようにきちんと管理する必要があります。
(条件付きアクセスで設定している場合は Identity Protection 側でサインイン リスク ポリシーが設定できないように画面がグレーアウトするような動作になれば間違いが起こらなくて良さそうですね…その逆も然り。)
今回の記事が少しでも参考になれば幸いです。