Teamsの外部・ゲストアクセスを許可したくない、あなたへ

皆さんこんにちは。国井です。

リモートワークが続き、お取引先のお客様とMicrosoft Teamsでやり取りすることが多くなりました。しかし、お取引先の会社にとっては私は社外の人間。
私がお取引先の会社のTeamsでやり取りしようとすると、社外の人間をお通しするための設定をしなければなりません。ところがこの設定、なかなか嫌われるんですよね。しかも「社外」の定義にも色々あってわけわからん、という声を聞くので私なりにまとめてみました。
正直、私自身もこの闇を解明しきったわけではないので、間違っているところはあるかもしれないです(というか多分あるはずなので、ご指摘くださいw)。

Teamsの会議に社外の人間を招き入れる場合、匿名アクセス、外部アクセス、ゲストアクセスの3種類があるので、ここから見ていきましょう。

匿名アクセス

匿名アクセスは文字通り匿名でのアクセスです。Teamsで[予定表]から新しい会議を作成した場合、Teams会議に参加するためのリンクを生成され、あらかじめ指定したメールアドレスに送信されますが、このリンクをクリックすれば誰でも(指定したメールアドレスじゃなくても)会議に参加できます。
余談ですけど、私がオンライントレーニングを行うときにも使うことがあるのですが、匿名で入ってくる人は参加時に自分の名前を自由に設定して入れるので、本当の参加者なのか?というのがわからないんですよね。

image
もちろん会議に入室するときには会議を開く人が承認しないと入れないので(設定で承認なしでも入れるようにすることも可能)、zoom bombingみたいな攻撃は防げます。
2020年8月25日追記
承認された匿名ユーザーが別の匿名ユーザーを承認できるようになっているそうです。
シモヤマさんありがとうございます!

匿名アクセスをブロックするときはTeams管理センターの会議 > 会議設定から[匿名ユーザーが会議に参加できます]をオフにしてください。

image

外部アクセス

外部アクセスはTeamsやSkype for Business、Skypeのアカウントを持っている他社のユーザーによるアクセスです。他社のAzure ADユーザーはもちろんのこと、マイクロソフトのサービスにアクセスするためのアカウントを持っているユーザーということのようです。
匿名アクセスと異なる点は認証を行ったユーザーだけが会議に参加できる点がです。そのため、匿名アクセスをブロックし、外部アクセスを有効にしている場合は事前に自身のAzure ADユーザーでサインインしていないとTeams会議に参加できなくなります。

ちなみに外部アクセスをブロックするときは
Teams管理センターの組織全体の設定 > 外部アクセスから設定をオフにしてください。

image

ゲストアクセス

ゲストアクセスは自社のAzure ADのゲストユーザーとして登録済みのユーザーによるアクセス方法です。ゲストアクセスの場合は外部アクセスと比べてTeams上でできることが大きく増えるので、定期的なコラボレーションを行う場合はゲストアクセスを利用すべきと思います。
外部アクセスとゲストアクセスの違いはこちらで解説しています。

ゲストユーザーは予定表から設定する[新しい会議]で参加者を登録する方法と、チームのメンバーとしてユーザーを登録して会議を設定する方法のどちらも利用できることも特徴のひとつです。

ちなみにゲストアクセスをブロックするときはTeams管理センターの組織全体の設定 > ゲストアクセスから設定をオフにしてください。

image

ゲストアクセスとはAzure AD B2Bのゲストユーザーを事前に作っておき、そのユーザーアカウントを使って接続することです。そのため、Teams管理センターで許可するように設定していたとしても、Azure AD管理センターからゲストユーザーそのものの利用を無効にしてしまえば、結局ゲストアクセスはできなくなる点にも注意してください。

Azure ADのゲストユーザーの無効化設定はAzure AD管理センター画面からユーザー設定 > 外部ユーザー設定 で定義できます。

image

■【参考情報】Microsoft Teams でのゲスト アクセスを承認する
https://docs.microsoft.com/ja-jp/microsoftteams/teams-dependencies

制限を設定してみた

匿名アクセス、外部アクセス、ゲストアクセスの3種類があることをここまで見てきましたが続いて特定の制限を設定したらどうなるか見てみましょう。
Teams管理センターで設定した内容は設定が反映されるまで時間がかかるので、全部のパターンを試せませんでしたが、ちょろっと設定してみたらこんな感じになりました。

匿名アクセス 外部アクセス ゲストアクセス
×

上記のパターンの場合、どこの会社のユーザーであれAzure ADユーザーであれば会議に参加できました。ただし、会議は予定表から設定する[新しい会議]で参加者を登録すること、InPrivateブラウズを使っていないことが条件としてありました。

匿名アクセス 外部アクセス ゲストアクセス
× ×

上記のパターンの場合、会議を作成するユーザーが所属するAzure ADディレクトリにゲストユーザーとしてユーザーが登録されている場合に限り、会議に参加できました。
ゲストユーザーはAzure AD管理センターからゲストユーザーを作っただけではダメで、きちんと招待メールのリンクをクリックして招待の承諾を受けていることが条件になります。
招待の承諾についてはこちらに解説がありました。

また、面白かったのは外部アクセスに相当するユーザーがこの状態のときに無理やりアクセスしようとすると、主催者の承認待ちを表すメッセージが表示されたまま、そこから先に何も起きない点です。外部アクセスは×なわけだから承認待ちとか言わないでダメと言ってくれればいいのに。意地悪な人ね。

Teamsアプリから会議に参加

実際に使っていて不思議だったのはTeamsアプリから会議に参加するときです。
Teamsのアプリで画面右上に自分が今、どのディレクトリに接続しているか?というのがわかると思うのですが(下画面参照)
これでどこを選択しているかによって、接続状況が変わったりします。
例えば、AとBという2つのテナントがあって、自分のテナントがAだとしましょう。
テナントBに私のゲストユーザーを作ってもらったら、テナントAのユーザー(私)はテナントBのTeamsでゲストアクセスの扱いで会議ができるようになります。しかし、私のTeamsの下画面で(ゲスト)と表示されているほう(つまりテナントB)を選択していると、テナントBの会議に参加するときに匿名アクセス扱いされてしまうのです。

image

会議に参加するのにTeamsのサインアップは必要?

不要です。そのために匿名アクセスがあるのですから。では匿名アクセスが無効になっている場合はサインアップしたらアクセスできるようになるか?と言われれば答えはYESです。
なぜなら
https://www.microsoft.com/ja-jp/microsoft-365/microsoft-teams/group-chat-software?rtc=1

image

にアクセスして、サインアップを行うとTeamsのライセンスが付与されると同時にサインアップに使われたアカウントはマイクロソフトアカウントになるからです。
マイクロソフトアカウントでサインインしてTeams会議に参加するユーザーは「外部アクセス」に当たりますから、外部アクセスが有効なテナントであれば、アクセスできるようになります。

匿名アクセス、外部アクセス、ゲストアクセス、どれを認めるか?

やっと今日の本題です。
最近、Teamsで会議を行うときに匿名アクセス、外部アクセス、ゲストアクセスのどれをどのように認めるか?という話が出てくるのですが、全部OKとしている会社を除くと次の3つのケースがあるようです。それぞれの私の所感も含めてどうぞ。

ケース1:会社のリソースに社外の人間を入れたくない

Office 365のテナントという会社の境界に社外の人間を入れたくない、というケースです(匿名、外部、ゲスト、全部ダメというパターン)。このケースの場合、理由を聞くと論理的な答えが返ってくることは少なく、「なんとなく」という答えが返ってくることが多いんですよね。
この答えに至る背景にはネットワークを境界とするセキュリティの考え方があるんですよね。この場合は考え方から変えてもらうしかないんだけど、このままではコロナ禍で社外の人と会議もできなくなるはずなので、どこかで方針転換されるんじゃないかと願っています。

ケース2:Teamsでの会議のみ可

テレワーク前提のこの時世なので外部アクセス(匿名?)としてのTeams会議は認めます。
だけど、ゲストアクセスは認めないという運用です。
外部アクセスとゲストアクセスの違いは前に紹介したサイトにも出ていますが、ゲストアクセスができないと、ファイルを共有できないなどの問題が出てきます。
これを使う理由ってわからないでもないんですよね。だって会議は映像と音声だけなので、録画していない限り、情報が漏えいする心配は少ない。だけどファイルのような永続的に残り続けるものはリスクがあるから共有したくない。
だけど、このルールを会社で作ってしまったものだから、後でファイルを共有する必要が出てくると「じゃあ後でメール添付でお送りしますね」となるのです。それでもってPPAPやられたら、もう最悪。PPAPの問題はいっぱいあるけど、現実的な一番の問題はウイルス対策機能をすり抜けてしまうことです。「暗号化しなければならないから」という、あなたの会社のエゴを押し通したお陰で、受け取る側は迷惑していることにいい加減気づいてほしいものです。

ケース3:相手テナントへのゲストアクセスは認めない

自分の会社をA社としましょう。A社のユーザーとB社のユーザーで会議をするときに、A社のテナントにB社のユーザーをゲストユーザーになることは認めますが、B社のテナントにA社のユーザーをゲストユーザーにすることはA社のポリシー的にNGというパターン。

自分の会社のテナントにゲストユーザーが増える分には自分の会社で状況が把握できるからいいけど、相手の会社のテナントに自分の会社のゲストユーザーが作られたら、その管理(特にログ管理)はもう自分たちでできなくなるから許さん!という理屈なのでしょう。
理屈はわかります。だけど逆の立場からしてみると「自分の会社のためなら相手の会社など、どうでもよい」と言っているように聞こえてならないのです。
#と言いつつ「うちのポリシーなので」と言われれば、なんでも言われた通りにする、業界の底辺にいる私w(ホントに「だめだこりゃ」というポリシーを押し付けられたときは笑って過ごして次から一緒に仕事しませんけどね)
サイバーセキュリティ経営ガイドラインでも経営者が認識すべき3原則に「自社は勿論のこと、ビジネスパートナーや委託先も含めたサプライチェーンに対するセキュリティ対策が必要」とあるように「自分の会社でコントロールできないからダメ」ではなく、サプライチェーン全体でのセキュリティ対策の徹底を目指して信頼できるパートナーを作っていくのが本来のあるべき姿と思うのです。

参考までに、A社のテナントにB社のユーザーをゲストユーザーとして追加した場合、
B社のユーザーはB社のテナントで一度サインインを行い、OAuth2.0を使ってA社のアプリ(この場合はTeams)にアクセスします。このとき、OAuth2.0でID連携をするのが初めてであれば、相手のテナントに受け渡しをするユーザープロファイルの情報については画面で確認できますので、リスク範囲はある程度把握できるようになっています。

■ ■ ■

ここまで私が遭遇した3つのパターンを見てきましたが、どうして外部ユーザーやゲストユーザーを認めないという発想になるかといえば、境界型防御の考え方に基づいてTeamsを利用しているからなのではないかと思うのです。
すべての会社で、外部アクセスやゲストアクセスを認めるべきだと言うつもりはないですが、盲目的に境界型防御の発想で「外の人間はダメ」という考えを改める時期に来ているのではないでしょうか。

この辺の考え方についてはMSさんで提供しているAzure AD Webinar Season4 「Azure AD アーキテクチャ概要 – Azure AD を設計するためのガイドライン」などが役に立ちますので、参考にされると良いと思います。