セキュリティチームのぐっちーです。
皆様は、「Microsoft Teams Connect」という機能をご存知でしょうか？これは、異なる組織のTeamsの「チャンネル」を接続することで、円滑な外部組織とのコミュニケーションを実現する機能で、1年ほど前に提供予定として発表されていました。TeamsはSlackに比べて、外部共有に課題がありますが、この機能が提供されることで改善されることが期待されています。
そんな機能がついに先日リリースされたので、本ブログでは検証した結果をまとめていきます。
本ブログの内容は、2022年4月10日時点までの情報を元に作成しておりますが、クラウドサービスの仕様変更等に伴い、将来的に状況が変化することがあります。仕様変更が確認できた場合は可能な限り修正をしますが、最新の情報でない可能性があることをご留意ください。
Teamsの外部共有事情
本題に入る前に、Teamsの外部共有事情について簡単にまとめたいと思います。
前提としてSlackでは「Slack Connect」という機能があり、違うテナント（ワークスペース）のチャンネル同士を接続して、シームレスなコラボレーションを行うことができます。クラウドネイティブのSlackでは、この機能を利用してお客様と繋がりまくっています。
一方、今までTeamsにはこれに該当する機能はありませんでした。そのため、基本的にTeamsは社内に閉じた使われ方をするか、「ゲストアカウント」を作成して、社外ユーザーとコミュニケーションを取る必要がありました。
ただ、「ゲストアカウント」は利便性において課題があり、例えばユーザーが「自社Teams（通常アカウント）」と「他社Teams（ゲストアカウント）」の両方を利用している場合は、毎回テナントの切り替えが必要となります。私は前職でTeamsをガンガン利用していましたが、このテナントの切り替えが手間だったのを今でも覚えています。
また、チームにゲストユーザーを招待した場合、「パブリックチャンネルと参加しているプライベートチャンネルの情報は全て見えてしまう」という仕様であるため、公開範囲を誤る等のセキュリティ上のリスクが介在しています。
そんな中、登場した「Microsoft Teams Connect」は、テナント切り替えを不要とし、これまで利便性の悪かったTeamsのユーザー体験をガラッと変えるポテンシャルがある機能です。前置きが長くなりましたが、ここから検証の内容に移っていきます。
設定方法
前提
「Microsoft Teams Connect」には、複数の共有パターンがあるのですが、今回は「異なる組織のチーム同士を繋げるパターン」の設定方法をまとめています。今回のユースケースでは「テナントA」のチームで作成したチャンネルに、「テナントB」のチームを招待するというケースを想定しています。
共有チャネルのポリシーを設定
Teamsの管理センターで共有チャンネルのポリシーを設定します。私のテナントではデフォルトで許可をされていましたが、これがオフになっていると、「Teams Connect」を利用することはできません。
AzureAD B2B直接接続の設定
AzureADクロステナントアクセスポリシーで「AzureAD B2B 直接接続（B2B Direct Connect）」を構成します。当社のすかんくが「Azure AD 間の B2B コラボレーション」に関して記事を書いておりますが、厳密には別機能です。（設定箇所は近くにあるので混同しやすいですが。）
まず、[Azure Active Directory 管理センター] > [External Identities] > [クロステナントアクセス設定] に、コラボレーションする組織を双方の環境で追加します。ここで入力するのはテナントIDか [XXX].onmicrosoft.com といったプライマリドメインです。
次に、設定した組織に対してのインバウンドとアウトバウンドのアクセスをそれぞれ設定していきます。
「AzureAD B2B 直接接続（B2B Direct Connect）」はTeams Connectのセキュリティの鍵を握る機能です。設定の際にはアクセス許可の範囲に配慮しながら設定するようにしてください。
尚、私も簡単に触ってはいますが、様々なユースケースを定義しての深い検証はできておりません。今後も触っていく中で検証して、適宜アップデートしたいと思います。
共有チャンネル（Shared Chanel）を作成し、外部ユーザーを招待
共有チャンネル（Shared Chanel）を作成し、外部ユーザーを招待します。まずは、Teamsの共有チャネルを作成します。自分が管理権限を持っているチームにおいて、[チャンネルの「・・・」ボタン] > [チャンネルを追加] を押下して、チャンネルを作成します。その時に、下記の図のように[共有済み]のチャンネルを選択し、[作成]を押下します。
すると、チャンネルが新規に作成され、下記の図のようにチャンネルにユーザーを招待する画面が出てきます。ここで、外部組織のユーザーを招待したいところですが、今回のユースケースの「異なる組織のチーム同士を繋げるパターン」の設定はここではありません。スキップしましょう。
次に、接続したい外部組織のチームの「チーム管理者」に招待を送ります。接続したいチャンネルで[チャンネルを共有]を押下し、オプションでは[チームと]を選択します。後続の画面では、接続したい外部組織のチームの「チーム管理者」のメールアドレスを入力します。
今回は「チームと」を選びましたが、他の選択肢の挙動は「他の組織のチームとの接続以外の機能」の項にまとめています。
すると、招待された側のテナントに招待をされた旨の通知メッセージが届きます。
承認すると、どのチームにチャンネルを追加するかを選択する画面に遷移します。ここで今回接続したいチームを選択しましょう。
たとえ「チーム」に所属していたとしても、「チーム管理者」の権限がないと、Teams Connectを構成することはできません。
最後に、招待する側のテナント（テナントA）で最終的な承認を行います。[チャンネルを管理] > [招待の送信] から最終的な承認を行うことで、Teams Conectが構成されます。
動作確認
招待する側の目線では、作成したチャンネルに、「テナントB（招待された側）」のユーザーが現れて、チャットを行うことができます。招待された側の目線では、Teams Connectを構成する中で選択したチームに新たなチャンネルが出現し、招待したテナントのユーザーとコミュニケーションを取ることができます。
メリットや気になる点 等
UXが劇的に改善
「劇的に」の部分は完全に主観ですが、Teamsを利用した異なる組織とのコラボレーションがシームレスとなることは間違いありません。以前私は、Teamsのデスクトップアプリ版で自社のTeamsにログインし、ブラウザ版で他社（お客様）のTeamsにログインするという使い分けをしてきましたが、そのような使い分けや、テナントの切り替えが不要となったことは画期的だと思います。
他の組織のチームとの接続以外の機能
先ほどの手順では、共有チャンネルに招待する際に「チームと」共有（異なる組織のチームとコラボレーション）を選択して検証しましたが、今回のアップデートでは他にも「ユーザーと」と「自分が所属するチームと」というオプションがあります。
ユーザーと
「チームと」の共有は異なる組織のチーム同士をチャンネルを通じて接続しましたが、この「ユーザーと」はユーザー個人をチャンネルに招待する設定です。この設定で招待しても、招待されたユーザーはテナントの切り替えをすることなくアクセスが可能です。
自分が所属するチームと
一方、「自分が所属するチームと」というオプションは、端的にいうと「社内のチーム同士を接続する」設定です。下記の図では「taguchi-test」というチームと「taguchi-test-3」というチームを連結しております。
Teamsは「チームが増えすぎてしまう問題」が頻繁に発生しています。例えば、「開発部」と「管理部」というチームがあったとしても、それらの部が連絡を取り合うために、新しく「開発部-管理部」というチームを作成するというのは良くある話です。このようにTeamsのチームは無限増殖しやすいです。
そこでこの機能を使えば、作成するチームを抑えることが可能となるケースもあるかなと思いますので、個人的にはこの設定も激アツだと思っています。
勝手に共有チャネル接続を増やされる問題について
この機能が出るまで、ユーザーが勝手に共有チャネルを増やし、意図しない組織と連携する懸念がないかなと少し不安でした。その懸念に対しては、「AzureAD B2B 直接接続（B2B Direct Connect）」の適切な運用が解決策になるかなと思います。
デフォルトでは、「AzureAD B2B 直接接続（B2B Direct Connect）」はインバウンドもアウトバウンドもオフに設定されており、オフの状態ではTeams Connectを構成することはできません。また、新規で構成する際にも、必要最小限となるように構成することでリスク回避できかなと思います。
また別の角度で見ると、Teams Connectを設定するには「チーム管理者」の権限が必要なので、「チーム管理者」の権限を最小化していくことでも、リスクを軽減させられると思います。
招待された側はチャンネル名は変更できない
Slackでは、Slack Connectを利用した際に、招待したテナントも招待されたテナントもチャンネル名は変更可能で、変更したテナント名は相手のテナントに同期されません。そのため、チャンネル名を「A社共有チャンネル」など相手の会社名だけを指定しても、双方のユーザーにとって利便性を損ねることはありません。
一方、Teamsでは招待された側はチャンネル名は変更できない仕様になっています。
そのため、チャンネル名は A社-B社共有チャンネルなど、コラボレーションをする双方の組織が認識可能な名前をつけることをお勧めします。
残課題（次回以降の検証）
セキュリティリスク
「Microsoft Teams Connect」のアップデート（2022/4/7）を見つけて日が浅いので、どのようなセキュリティリスクがあるか、またどのような対処が可能なのか、まだはっきりとわかっていません。とりあえず、「勝手に共有チャンネル接続を増やされる問題」についてはざっくりと記載しましたが、それ以外については、今後使い込んで研究したいと思います。検証を重ね、このブログをアップデートするか、新しくブログを書きたいと思います。
Mioと組み合わせてどうなるか？
SlackとTeamsの投稿を同期するMio という製品があり、当社でも以前検証してブログにしています。そんなMioを使って、下記の図のように、Slackを利用している組織とTeamsを利用している組織がシームレスにやりとりできる世界がきたらすごく面白いなと考えています。
当社はメインのコミュニケーションツールとして、Slackを使っており、お客様もSlackユーザーが多数派ですが、様々な制約により、Slackが使えないお客様がいます。そういうお客さんにはメールなどでやり取りをするわけですが、Teams ConnectとMioなどを使ってシームレスにやり取りができたら嬉しいなと思ってはいます。
ただし、「Mioがダウンした時、メッセージがロストしない？」とか「情報の転送にあたるけど、セキュリティポリシーの兼ね合いは大丈夫？」とか「UI/UXはどんなもんなの？」など、乗り越える壁がたくさんありそうなので、一筋縄では行かなそうですね。
他のMS製品との食い合わせ（SharePoint、eDiscovery、MIP等）
Microsoft 365を利用していると、ライセンスによっては沢山の高度なセキュリティ機能であったり沢山のアプリケーションが利用できます。そのうち、Teamsに関係ありそうな製品として、SharePoint、eDiscovery、Microsoft Information Protection（MIP）、Microsoft 365 DLP、Microsoft Defender for Cloud Apps 等がパッと浮かびますが、それらとの食い合わせについてはまだ検証ができていません。
異なるテナント同士を繋げるため、何らかの影響があると思いますので、時間のある時に検証してアウトプットしたいなと思います。
他社製品との食い合わせ
Teamsと連携する他社製品との食い合わせも、検証が必要です。例えば、Teams上のファイルをBoxに格納する「Box for Teams」などは、Teams Connectと同時に利用した際に、どのような化学反応が起きるかは、確認せねばなりません。
おわりに
当社はSlackを利用しており、Teamsをほぼ利用していないのですが、Teamsをメインに利用されている方にとってはインパクトのあるアップデートではないかなと思います。まだ登場したての機能かつパブリックプレビューなので、まだまだこれからという立ち位置ですが、生産性向上に欠かせない機能だと思いますので、今後も注視したいと思います。
今回のブログで深堀できていない面は、今後検証してアウトプットにしたいと思っていますが、気になる点がありましたら、ユースケースを添えてコメントをいただけるとありがたいです！！
