OneDrive for Business上のコンテンツやSharePoint Onlineのチームサイトを他組織のユーザと共有をするB2Bシナリオで利用している企業・組織が増えている中、Office365（およびそのID基盤であるAzure AD）の構造上の問題により、意図しないアクセス権を外部ユーザへ付与してしまう場合があるので、注意喚起の意味で本エントリを書きます。
[3/7 Update]
一部修正が行われ、ポータルからのディレクトリ構成情報へのアクセスがデフォルトでブロックされるようになりました。
詳しくはこちらをご覧ください。
http://idmlab.eidentity.jp/2017/03/office365.html
現在、この課題については米国マイクロソフトのAzure AD開発チームへエスカレーションしており早期の改善を求めていますが、場合によっては長期化する可能性もあるため、自組織でOffice365を管理しており、外部ユーザとのコンテンツ共有をエンドユーザへ開放している管理者は一読の上、対応を行うことをお勧めします。
（いわゆる製品やサービスの脆弱性の類ではないため）
◆課題の概要
OneDrive for Business上のコンテンツ共有やSharePoint Onlineのチームサイトへの招待を受けた外部ユーザは、共有されたコンテンツ以外にも、「Azure AD上ですべてのユーザに対して割り当てを行われたアプリケーションや、Azure Portalを経由したディレクトリ情報へのアクセスが許可されてしまいます。かつ、事前に共有した本人および管理者がこのことに気が付くことはほぼ不可能です（どこにもそのような記述はないため）」。これは招待されたユーザが自組織でOffice365やAzure ADを使っておらず個人でマイクロソフトアカウントを使っている場合においても発生します。
◆実際の動き
実際にどのような動きになるのか、動画を撮っていますので、まずはこちらをご覧ください。わかりにくいですが、以下が環境です。
＜組織「eIdentity」：招待する側＞
・Office365を運用しています
・一般ユーザ「test001@ems.adfs20.net」でOneDrive for Businessで外部ユーザ「test001@gapps21.adfs20.net」に対してコンテンツを共有します
・Azure AD上で「ts2016」というアプリケーションをAll Usersグループに対して公開しています
＜組織「InternetWeek」：招待される側＞
・Office365は使っていませんが、Azure ADを利用しています
（マイクロソフトアカウントの場合も同じ動きになります）
・「test001@gapps21.adfs20.net」という一般ユーザが所属しています
単純にeIdentityテナントのユーザでOneDrive for Businessでフォルダを共有しただけなのに、共有前はInternetWeekテナントのユーザがアクセス出来なかったts2016アプリへアクセスが出来てしまい、かつAzure Portal経由でeIdentityディレクトリの構成情報（ドメイン一覧）が参照できてしまっています。
※アプリケーションのURLを知らなくてもアクセスパネル（https://myapps.microsoft.comへアクセスすると利用できるアプリケーション一覧が表示されてしまいます。
※SharePoint Onlineのチームサイトへの招待の場合は、アプリケーションアクセスは出来ませんが、Azure Portal経由でのディレクトリ情報の参照は可能な状態になります。
（「All Usersグループ」へ自動追加されないため）
ディレクトリ上（ドメイン一覧）の参照
アプリケーションへのアクセス
上記のスクリーンショットはいずれもゲストユーザによりアクセスした状態で撮っています。
管理者としては、特定のコンテンツのみの共有なら、、という気持ちで許可した外部共有がこのような形で他の情報へのアクセスへ影響を与えるということは意図していないことが多いと思われるため、非常に大きな問題となる可能性があります。
◆なぜ発生するのか
OneDrive for BusinessやSharePoint Onlineで外部ユーザを招待すると、招待されたユーザが招待したOffice365側のAzure AD上にゲストユーザとして登録されます。これはAzure AD B2Bで外部ユーザを招待するのと同じ動作であり、Office365が内部的にAzure AD B2Bの機能を利用しているために発生しています。
そして現状では、ゲストとして登録されたユーザは、
１．ディレクトリへのサインイン（認証）
２．ディレクトリ上の自プロファイルへのアクセス
に加えて、
３．ディレクトリ構成情報へのアクセス（少なくともドメイン一覧の参照）
４．（場合により）All Usersグループへの自動登録
が行われてしまいます。
１、２については本来のゲストユーザとしてアクセスを行うために最低限必要な機能なので、仕方がありませんが、問題は３、４です。
◆Office365/Azure ADの内部構造の課題
ここまで見てきたとおり、Azure ADにゲストとして登録された外部ユーザが想定以上に権限を持ってしまっていることが根本的な課題です。少なくとも、
・自プロファイル以外のディレクトリ情報へのアクセス
・ディレクトリに登録されたアプリケーションへのアクセス
はデフォルトでは禁止されるべきでしょう。
早々にマイクロソフトが対応してくれることを望みます。
◆推奨される対応
このような状況なので管理者が出来ることと出来ないことがあるのですが、少なくとも以下の対応をしておくべきでしょう。１．ゲストユーザが自ディレクトリ上に存在するかどうかの確認
まず、自ディレクトリ上にゲストユーザが存在しているかどうかは定期的に確認をしておくべきでしょう。
以下のAzure Active DirectoryのPowerShellを使い、以下のコマンドレットを実行することでゲストの存在を確認できます。
Get-MsolUser | Where-Object { $_.userType -eq 'Guest' }
２．All Usersではなく、自ディレクトリ上の本来のメンバだけが含まれるグループの作成
動的メンバシップグループをカスタムで作成し、userType=Memberのユーザだけが所属する様に構成することで自ディレクトリ上で作成されたユーザのみが含まれるグループを作成することが可能です。
逆にuserType=Guestだけが含まれるグループを作成するとゲストだけが含まれるグループを作成することが出来ます。
３．All Usersグループへ割り当てられているアプリケーションの割り当て変更
All Usersグループへのアプリケーション割り当ては非常に便利なので使ってしまいがちなのですが、ここは先の２で作成したメンバだけが所属しているグループへの付け替えを検討しましょう。
こうしておけば、Azure ADからプロビジョニングを行っているアプリケーションであっても、ゲストユーザはプロビジョニングされませんし、アクセスパネル（https://myapps.microsoft.com）にもアプリケーションは出てきませんので安心です。
＜変更前＞
＜変更後＞
４．アプリケーション側でしっかり認可を行う
この問題は最終的にはアプリケーションの作りに依存するので、認証されただけでは利用できないようにアプリケーションを構成する（きちんと認可する）ことが最も大切です。
例えば、今回の動画の中でアクセスしている「ts2016」というアプリケーションはディレクトリ上にユーザが存在していれば使える、という簡易な実装にしてしまっているためゲストであっても使えてしまいます。
しかし、アプリケーション側の実装で、認証されてアクセスしてきたユーザへのアクセス制御を他の属性（所属など）を用いてしっかりと管理を行うことで、少なくとも重要なデータへのアクセスを防ぐことが出来ます。
５．ポータルへのアクセスを禁止する（要注意：影響度大）
設定を間違えると管理者でさえ管理ポータルへアクセスできなくなったり、他のAPIを使うアプリケーションへのアクセスが一切できなくなるので、この設定を行う場合は十分にテストを行った上で慎重に実施してください。著者は一切責任をとれません。
かなり強引なやり方ですが、条件付きアクセスを利用してゲストユーザからWindows Azure Service Management APIへのアクセスをブロックしてしまえば管理ポータルへのアクセスが出来なくなります。
以下の条件付きアクセスポリシーを作成します。
・Users and groups：All Guests（先ほど作成したゲストだけのグループ）
・Cloud apps：Windows Azure Service Management API
・Grant：Block access
・Enable policy：On
このポリシーを有効にすると、管理ポータルへアクセスしようとするとアクセスがブロックされます。
ディレクトリを切り替えようとすると、
アクセスがブロックされます。
◆今後の対応
現状、この動作はサービスの仕様の問題であり、いわゆるバグ等の不具合には該当しないためサービスのエンハンス要求を挙げている状態です。この状態で出来ることは管理者の自衛が中心となりますので、動作および自テナントの状態をよく理解して運用をしていってください。
今後、動作に変更などあれば本ブログでも更新情報を発信していきたいと思います。
投稿
