🐥

Azure ADの「クロステナントのアクセス設定」（前編）

2022/03/03に公開

Azure

Azure AD

tech

はじめに

2022年2月に、下記のような機能がパブリックプレビューになりました。

Azure ADのクロステナントでのアクセス、すなわちB2Bでのゲストユーザーを利用したアクセスに関するいくつかの課題を解決するものになります。日本語サポートの中の人のブログがありますので、こちらを見ていただくのがもちろん良いのですが…

これまで、私の見て来た環境で「ココが制御出来たら嬉しいのにな～」と思っていた点が2点解決されていそうでしたので、試してみたいと思います。
私が制御したかったのは、サポートブログから引用すると下記の通りです。

承認された外部ユーザーのみがアプリとリソースにアクセスでき、組織の承認されたユーザーのみが外部アプリとリソースにアクセスできるようにしたい。
パートナーからの MFA クレームを信頼し、ホームディレクトリ (外部ユーザーがメンバーとして所属するディレクトリ) で MFA を実行した外部ユーザーが、リソースディレクトリ (外部ユーザーがゲストして招待されたディレクトリ) で再び MFA を要求されないようにしたい。

ゲストユーザーを利用する場面

Azure ADの単位

Azureの公式ドキュメントを見ると、エンタープライズで利用する場面での「マイクロソフトの考えるベストプラクティス」では【1 組織（≒会社）＝1 Azure ADテナント】を基本として考え,
サブスクリプションを【システムや課金部署の単位、本番/開発といった面で分離する】といった方針で書かれているようです。

理想

しかし現実的には、自組織内の利用に限ったとしても、Azure ADの設定変更をテストしたり、本番／開発ユーザーの権限分離を間違えづらくするために、本番向け／開発向けのAzure ADテナントを分離することが多いように思います。（個人の意見です）

現実

ゲストユーザーの出番

各AzureADテナントにユーザーを作成し、そのすべてのパスワードやMFAデバイスを管理する…となるととてもではないですがやっていけません。
とすると上の図のように「ユーザーは開発環境に作る」「本番環境にはゲスト招待し、ゲストユーザーは参照だけ許可する」「更新用ユーザーはそれぞれの環境に作り、別の統制を効かせる」といった使い方をする方も多いのではないでしょうか。

課題と新機能

しかしこういったゲストユーザー構成を取ると、冒頭に書いたような課題が発生します。

ゲスト招待は特定のAzureADテナント間のみに限りたい

これまで、ゲストユーザーとして招待する組織の制限はかけられなかったので、「どこの馬の骨か知れないユーザー」をウッカリゲスト招待してしまうということや、
また逆に「どこのAzureADか知れないところにゲスト招待され、自組織の情報をウッカリ横流しできてしまう」なんてこともあり得ました。
ゲストユーザーは自組織のユーザーではないので、人事異動等に基づいて自動的に作成・削除・権限変更を行うといった運用が難しく、棚卸もある程度人力でやる必要が出てきてしまう、運用上の制約となってしまいます。

AWSでは「IAMロールをAssumeRole出来るのは特定の組織・アカウントからのみ」といった制限が出来ますし、Azureユーザーとしては当然制限したかったものと思います。

今回の新機能では、ゲスト招待元・招待先を制限することができるとのこと。

MFAを両方のAADで求められる

先ほどのような構成で利用する場合、何も考えずにAADを構成し条件付きアクセスやセキュリティデフォルトを使ったMFAを強制すると、

1回目：Contso-dev.comにサインインするとき
2回目：Contso-prd.comにディレクトリを切り替えるとき

の計2回、MFAでの認証を求められます。また、この①-②の認証で画面を出してみると分かるのですが、どちらのAzureADで聞かれているのか見分けがつきません。（おそらく）
本来、MFA認証で確認しているのは「ユーザー本人であることの正当性」でしかないので、ホームディレクトリとリソースディレクトリと2回認証を受けても、特に意味は無くどちらか一方で認証されていれば十分です。

今回の新機能では、この図の「Contoso-dev」（ホームディレクトリ）でMFAが済んでいれば、「Contso-prd.com」（リソースディレクトリ）にアクセスするときはMFAを不要にする、という設定が出来るようです。

動きの確認

ということで課題の1つ目「ゲスト招待は特定のAzureADテナント間のみに限りたい」が解消しているかどうか、検証していきます。※課題の2つ目は、また次回。

ゲスト元・先の制限設定

まずAzureAD＞External Identities＞クロステナントアクセス設定 (プレビュー)に移動します。

既定の設定

「既定の設定」タブ＞「規定値の設定」ボタンから「アクセスのブロック」を全てのユーザー・グループに設定します。

送信（自テナントのユーザーを外テナントにゲストとして送り込む）も受信（他テナントのユーザーを自テナントにゲストとして招待する）も、既定で「ブロック」にすることで、このテナントのユーザーはゲストとして他のテナントで使うこともできず、他のテナントからゲスト招待することもできなくなります。

組織の追加

「組織の追加」タブ＞「＋組織の追加」より、許可対象にするAzureADテナントを指定します。
Tenant IDか、ドメイン名を入力します。XXXXXX.onmicrosoft.comであれば覚えていると思いますので、ドメイン名が楽ですね。

続けて、「受信アクセス」「送信アクセス」のリンクから、「設定のカスタマイズ」・「アクセスの許可」を選択して保存します。

例えば↓の設定で言えば、「DirectoryBからゲストユーザーを受け入れる」という設定になりますね。

これで「特定の組織に対しては、ゲストの送信・受信が可能になり、その他のテナントとはゲストのやりとりが出来ない」という制御になりました。

検証

それでは動きを確認します。

検証構成

下記のように3AADにユーザーを作成し、ゲストユーザーの招待を相互に行います。

結果は単純で、期待通りの制御となりました。

例えば、userA@dirA.onmicrosoft.comでAzureポータルにサインインし、その後DirectoryBに切り替えるというのは許可されていますが、

許可されていない動きをすると、下記のようにブロックされます。

UserAでDirectoryCへのアクセス
UserCでDirectoryAへのアクセス

おわりに

以上のように、期待通りの制御が出来ることが分かりました。
クラウドでは簡単に設定を変更できてしまうため、悪意の有無に関わらずウッカリ緩い設定をしてしまうことがあり得ます。1つ設定をミスっても致命的にならないように（今回で言えば間違ったユーザーをゲスト招待してしまってもアクセスを許可させないように）、多重で守っておくのが良いかと思います。

また、今回のような構成にするとゲスト元・先両方でMFAでの認証を求められ、うっとおしい…という課題があります。次回は、このMFAの制御について確認していきます。