onmicrosoft.comがバレると何が困る?
前回のエントリの続きです。
onmicrosoft.comをどうしても隠蔽したい – ぷりどうぐ
前回のエントリの結論：xxx.onmicrosoft.comを隠し通すのは難しい
onmicrosoft.comがバレると何が困る?
困る事もありますが、別にそうじゃなくても既にバレてるので困らないこともあります。
Office 365 を利用している事がバレる
xxx.onmicrosoft.comがバレる = Office 365を使っている事がバレるので、フィッシングメール送って偽のログイン画面に誘導できたりする。ただOffice 365利用しているかどうかは会社のメールアドレスを知っていればnslookupで一発で調べられるので、xxx.onmicrosoft.comを隠しててもバレます。
結論：どっちにしてもバレてるので無影響
AADログインIDのonmicrosoft.comドメイン部分がバレる
会社のログイン用ドメインはメールアドレスと同じ場合が多いので当然外部にバレてるとして(※)、新たにxxx.onmicrosoft.comのドメインがバレると、xxx.onmicrosoft.com を利用したユーザーIDを探してログイン施行することが出来ます。企業のもつアカウントの99%くらいは会社ドメインのログインIDなので問題なさそうなのですが、xxx.onmicrosoft.comを持つIDはシステム導入時やテスト時に作ったまま放置しているアカウントだったりして無防備なことが多いので、事実上、問題になる事があります。
※ まれに「悪意のある外部ユーザーからログイン施行されないため、ログインする会社ドメインをメールアドレスと別のものにしたい」という要望を受けますが、ゼロトラスト理論を考えるとそれこそ隠し通すことが難しく、ユーザー利便性だけが低下するのでやめた方がいいと思われます。
結論：アカウントが存在する場合は問題あり
onmicrosoft.comのセカンダリメールアドレスがバレる
Office 365 の仕様上、各ユーザーのセカンダリメールアドレスに[ユーザーID]@xxx.onmicrosoft.comというメールアドレスが付与されるので、スパムメールを送りやすくなります。とはいえ、セカンダリメールアドレスを指定しなくても普通に会社ドメインのメールアドレス[ユーザーID]@xxx.co.jpにメールを送り付ければいいので、onmicrosoft.comがバレたことによって新しく困る事ではありません。
結論：どちらにしろメールは受信できてしまうので、無影響
SharePointサイトのURLがバレる
会社のイントラのURLがバレるので気持ち悪い、という意見。とはいえ、SharePoint外部共有やTeams外部招待、OneDriveファイル共有を許可している会社なら、自サイトへのユーザーアクセスを許可しているわけで、今更会社のイントラURLバレを気にするのもナンセンスかと思います。
SharePoint外部共有とかしてないから、イントラのURLがバレるのが気持ち悪い！というのは感覚としては分かりますが、メールと違って権限管理をすれば外部から見れないので全く実害はないです。
※ むしろメアドさえ知ってれば誰でもメールを送れてしまうメールの仕組みがすごい
結論：デフォルトで外部の人は見れないから、バレたところで無影響
結論まとめ
AADログインIDのonmicrosoft.comドメイン部分がバレるのが、onmicrosoft.comがバレることによる新たなデメリットと考えます。
ログインIDがonmicrosoft.comのアカウントってどんなの?
xxx.onmicrosoft.comを利用したユーザーIDを抹殺すればよいですが、そんなことはできるのでしょうか?どのようなアカウントがonmicrosoft.comを使うのでしょうか?
認証回避
結論から言うと、一般ユーザーアカウントに対して多要素認証などを仕掛けている場合に、多要素認証トラブル時のシステム復旧用に、多要素認証を回避するためのアカウントを用意するパターンでonmicrosoft.comドメインを使う場合があります。
フェデレーション認証環境の場合
O365の世界でフェデレーション認証は認証ドメイン単位で設定するので、例えば会社ドメインはフェデレーション認証、としてしまうと、緊急回避用アカウントは会社ドメイン以外で作成する必要があります(※) ここで、既定で用意されているxxx.onmicrosoft.comを認証用ドメインとすることがあります。
以下の記事でもそれが推奨されています。
緊急アクセス用管理者アカウントの管理 – Azure Active Directory | Microsoft Docs
※ 緊急回避用アカウントを会社ドメインで作成しつつ、フェデレーション先のIdPで多要素認証をかけないこともできるが、どちらにせよIdP自体が死んだときは影響あり
AzureAD認証環境の場合
AzureAD認証環境の場合、認証制御はEM+Sの機能で行います。EM+Sの制御単位はユーザー個別orセキュリティグループであり、認証ドメインがなんであるかは関係ありません。よって、緊急回避用アカウントを会社ドメインで作成しても問題ありません。
結論
- フェデレーション認証環境の場合は、会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要がある
- AzureAD認証環境の場合、会社ドメインで緊急回避用アカウントを作成すればよいので、onmicrosoft.comでログイン可能なアカウントを抹殺できる
一歩進んで考察
さて、フェデレーション認証環境ではonmicrosoft.comのアカウントが必ず必要なのでしょうか?会社ドメイン以外のドメインで、緊急回避用アカウントを作成する必要があるという条件を満たせばいいので、例えば @hogehogetest36512345678.com というドメインを取得し、Office 365 に紐づけ、emergencyadmin@hogehogetest36512345678.com みたいなアカウントを作成し、、この条件を満たせますよね。
よって、ADFS環境でonmicrosoft.comの緊急回避用アカウントを作成する必要はなく、会社ドメインとは別の、AzureAD認証を利用するドメインを用意すれば、ADFS環境でもonmicrosoft.comも抹殺できます。
しかし果たしてこれに本質的な意味はあるのでしょうか?
emergencyadmin@hogehogetest36512345678.comと、
emergencyadmin-hogehogetest36512345678@xxx.onmicrosoft.comは「複雑で推測されにくい」という点で、何が違うのでしょうか?
上司に「なんでhogehogetest36512345678.comってドメイン取るの?」って聞かれて、ロジカルに答えられるでしょうか?
hogehogetest36512345678.comのドメインを維持する労力や、ドメイン失効リスクの方が、onmicrosoft.comを利用されるリスクよりも高いんじゃないでしょうか?
相次ぐドメイン事件、目的のWebサイトが表示されない原因 | 日経 xTECH（クロステック）
と考えると、素直にxxx.onmicrosoft.comのドメインを利用し、緊急回避用アカウントのIDを複雑にすることで(もちろんパスワードも)十分に要件を満たせるのではないでしょうか?
AzureADの素のセキュリティ
EM+S使わないと脆弱だ！みたいな説もありますが、AAD素の機能でそれなりのセキュリティレベルは担保しています。例えばID/Passwordを複雑にする、という対策は、IdPが総当たり攻撃を許してしまえば全くの無力ですが、当然その対策はされています。
詳しくは以下エントリを読んでもらいたいし、私も昔に説明エントリ書いてました。
Azure AD と AD FS のベスト プラクティス: パスワード スプレー攻撃の防御 – Japan Azure Identity Support Blog
Azure AD スマートロックアウトのカスタマイズ機能について-ぷりどうぐ
よって、IDもパスワードも複雑にしておけばまず大丈夫、と言えるでしょう。
結論
- ADFS環境でもonmicrosoft.comのログインIDは抹殺できるが、ナンセンスで無意味なので、onmicrosoft.comのIDを抹殺する意味はない。
- AzureADのセキュリティ機能を信用し、辞書攻撃にヒットしないようなID/Passwordを作れば、AzureADが総当たり攻撃には対応してくれる。