はじめに
本記事では、マルチクラウド環境における Azure Active Directory (Azure AD) の活用例として、リスクのあるゲストユーザーを自動的にブロックし復旧まで行ってくれる便利な機能について解説します。
Azure AD Premium Plan 2 に含まれる ID 保護機能 (Identity Protection) が必要となりますので、ライセンスをお持ちの方または興味のある方向けの記事となります。
前回までの記事において、Azure AD B2B のゲストユーザーに対して SaaS アプリを展開するシナリオおよび手法について解説しました。
ゲストに対して SaaS アプリを素早く展開できることは便利ですが、一方で、組織 (Azure AD) 内で ID 管理をしていないユーザーが脅威にさらされていないか気になりますよね。
ゲストユーザーのなりすましをはじめとするサインインの不正な試行に対しては、下記両方の対策が有効です。
- 多要素認証を必須とする
- ゲストがサインインしたタイミングでリスクを検知しアクセスをブロックする
1 点目の多要素認証については、前回の記事で具体的な設定方法を紹介しました。
2 点目のリスク検知とアクセスをブロックする機能について、リスクの検出シミュレーションを安全な環境で実行した際の設定と結果を共有していきます。また、後半で ID 保護機能を導入する前に留意しておきたいことについて記載しました。環境に合わせた運用を検討する時の参考としていただければと思います。
リスクの検出シミュレーション
リスクの検出シミュレーションは、下記の記事を参考に、匿名 IP アドレスを再現しました。
次の手順を完了するには、以下を使用する必要があります。
・匿名 IP アドレスをシミュレートするための Tor Browser。 組織が Tor Browser の使用を制限している場合は、仮想マシンの使用が必要になることがあります。
・まだ Azure AD Multi-Factor Authentication に登録されていないテスト アカウント。
匿名 IP からサインインをシミュレートするには、次の手順を実行します。
1. Tor Browser を使用して https://myapps.microsoft.com に移動します。
2. 匿名 IP アドレスからのサインイン レポートに表示するアカウントの資格情報を入力します。
10 ～ 15 分以内に Identity Protection ダッシュボードにサインインが表示されます。
本記事では 1 つのリスク検出のシミュレーションを行いましたが、Azure AD の ID 保護機能が定義しているリスク一覧は下記から参照いただけます。攻撃の傾向に合わせて、継続的に機能が追加されています。直近では、2021 年 11 月に「異常なトークン」「通常とは異なるサインイン プロパティ」を新たに検知可能となり、資格情報を悪用する典型的な攻撃に対して対処しています。
上記手順を参考に、SaaS アプリを割り当てられているゲストユーザーが、Tor Browser (ブラウザ) を利用して SaaS アプリへログインを試みました。この時に ID 保護機能がどのように効果を発揮するか見ていきましょう。
リスクのあるゲストユーザーのアクセスをブロックする
リスクのあるゲストユーザーのアクセスをブロックするためには、SaaS アプリを管理しているリソーステナント側の、ID 保護機能のサインインリスクポリシーを有効化します。Azure Portal へ管理者としてログインし、下記の通り設定を行います。
シミューレションのため、対象ユーザーは個別に指定しましたが、実際の環境では「すべてのユーザー」あるいは「特定のグループに所属するユーザー」を使うことが多いでしょう。サインインリスクは、"低"以上としていますが、検出されるリスクのレベルに応じてポリシーの適用可否を決められます。アクセスのブロックによって業務に支障が出ることが懸念される場合、多要素認証を要求するように設定することも可能です。
サインイン リスク ポリシーが適用される設定を行った後で、実際に Tor Browser から SaaS アプリへアクセスすると、ユーザーのログイン操作で下記のとおりブロックされました。
ゲストユーザーが Azure AD で管理されていないアカウントの場合、メールのワンタイム パスコードによる認証をする場合があります。このケースでもサインイン リスク ポリシーが適用されたら、アクセスがブロックされます。その時に、ワンタイム パスコードの通知メールは送信されません。
サインイン リスク ポリシーを解除しない限り、シミュレーションのシナリオにおいてゲストユーザーが自動的にブロックされる動作が継続します。
リソーステナント側の Azure Portal へログインすると、ID 保護機能の危険なサインインとして記録が確認できます。
また、ホームテナント側の Azure Portal へ管理者としてログインし、ID 保護機能の危険なサインインを確認するとリソーステナントと同様に記録が残っていることが分かります。
リスクのあるユーザーを復旧する
危険なサインインが記録されたことで、ユーザー自身がブロックされ、ホームテナントの Office 365 へログインできなくなる場合があります。
この動作は、ユーザーが所属するホームテナント側の ID 保護機能の設定によるものであり、ユーザー リスク ポリシーのアクセスのブロック設定を行っている場合にホームテナントの Office 365 へログインできなくなります。
ホームテナントでは、危険なサインインに加えて、危険なユーザーとして記録が残っていることが確認できました。
ユーザー自身がブロックされた場合は、パスワードリセットによって解除を行います。管理者によるパスワードリセットの他に、ユーザーがセルフサービスでパスワードリセットを行えば、ヘルプデスクなどの運用を通さずに復旧まで完了させることも可能です。
管理者による確認を行った上で、ブロックを解除する方法には、リスクを無視するというボタンを押す選択肢もあります。この方法では、パスワードを変更せずにブロックを解除することが出来ます。
ユーザー自身によるセルフサービスパスワードリセット後は、危険なユーザーの一覧へ表示されなくなります。
留意しておきたいこと
今回の記事におけるリスク検出シミュレーションに関して、2 つの留意点があります。情報セキュリティの観点からは、システムの利用者が必要な時に情報へアクセスが行えることが重要ですので、設計を行った上で機能を導入していただければと思います。
- ①リスクレベルの設定値
シミュレーションでは、ポリシーのリスクレベルの設定値を「低以上」で設定していました。運用におけるマイクロソフトの推奨値は下記となります。
リスクの計算方法に関する具体的な詳細は公開されていないため、アクセスがブロックされる頻度をコントロールするための検討を行うと良いでしょう。
サインイン リスク ポリシー：リスクレベル [中以上] に設定
ユーザー リスク ポリシー：リスクレベル [高] に設定
- ②アクセスのブロックだけではなく修復までを考慮した運用
先述した通り、アクセスのブロックによって業務に支障が出ることが懸念される場合、多要素認証またはパスワード変更を要求するように設定することが可能です。Azure AD Multi-Factor Authentication (MFA) による多要素認証、セルフサービス パスワード リセット (SSPR) を事前に機能として有効化し、ユーザー登録を済ませておけば、自己修復による迅速な対応を実現できます。
このような理由から、マイクロソフトは下記の設定を推奨しています。
サインイン リスク ポリシー：[多要素認証を要求する] に設定
ユーザー リスク ポリシー：[パスワードの変更が必要] に設定
一方、ゲストへ多要素認証を要求することについて、サポート面を含めた運用を定めることが難しいケースもあります。
上記①の点と合わせて、ゲストに対する SaaS アプリの展開を最大限活用でき、最低限の安全を確保するための設定を行いましょう。
本記事におけるシミュレーションにおいて、サインイン リスク ポリシーを Azure AD MFA による多要素認証の要求へ変更した後は、ユーザーへ下記のように疑わしい行動が検出されたことが表示がされ、それをユーザーが確認した上であれば多要素認証を行いアクセスができることを確認できました。
まとめ
本記事では、マルチクラウド環境における Azure AD の活用例として、リスクのあるゲストユーザーを自動的にブロックし修復まで行ってくれる便利な機能を紹介しました。
Azure AD Premium Plan2 のライセンスをお持ちの方、または興味のある方は是非実装を検討していただきたい機能です。
最後まで読んでいただきありがとうございました。どれか 1 つでも活用していただける情報があれば幸いです。
次回は Azure セキュリティに関する記事を年明けに公開予定です。
チーム活動として行っているこのブログ記事について、まとめページを作成しています。よろしければ、こちらのページから記事の一覧を参考してください。
＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。