セキュリティと Microsoft Teams

重要

Teams サービス モデルは、お客様の利便性向上のために変更される可能性があります。 たとえば、Teams を使用するユーザーのパフォーマンスと認証の回復性を向上させるために、既定のアクセスや更新トークンの有効期限が変更される場合があります。 このような変更は、Teams の安全性と設計による高い信頼性を保つことを目的に行われます。

Microsoft Teams は、Microsoft 365 サービスおよび Office 365 サービスの一部として徹底的な防御によるサービス レベルのセキュリティ、サービス内の顧客コントロール、セキュリティ強化、運用上のベスト プラクティスなど、すべてのセキュリティ ベスト プラクティスとプロシージャに従っています。詳細については、Microsoft セキュリティ センターを参照してください。

設計による高い信頼性

Teams は、Microsoft セキュリティ開発ライフサイクル (Security Development Lifecycle: SDL) に記載されている「Microsoft 信頼できるコンピューティングのセキュリティ開発ライフ サイクル」に準拠して設計、開発されました。より安全な統合コミュニケーション システムを作成するうえでの最初のステップは、脅威モデルを設計し、各機能を設計時にテストすることでした。複数のセキュリティ関連強化機能がコーディング過程と実践に組み込まれています。ビルド時に使われるツールは、製品にコードが最終的にチェックインされる前にバッファ オーバーランなどの潜在的なセキュリティ上の脅威を検出します。すべての未知のセキュリティ脅威を防ぐように設計することは不可能です。完全なセキュリティを保証できるシステムはありません。しかし、製品開発では安全な設計の原則が初期段階から採用されているので、Teams にはアーキテクチャの基礎の一部として業界の標準的なセキュリティ技術が組み込まれています。

既定による高い信頼性

Teams におけるネットワーク通信は、既定で暗号化されています。すべてのサーバーで証明書の使用を必須にし、OAuth、トランスポート層セキュリティ (TLS)、セキュア リアルタイム転送プロトコル (SRTP) 使用すると、すべての Teams データがネットワーク上で保護されます。

Teams の一般的なセキュリティ上の脅威に対する対処方法

このセクションでは、Teams サービスのセキュリティに対するより一般的な脅威と、Microsoft がそれらの脅威の軽減に用いる方法を明らかにします。

危害を受けたキーによる攻撃

Teams は、Windows Server オペレーティング システムで PKI の機能を使用して、TLS 接続の暗号化に使用されるキー データを保護します。メディアの暗号化に使用されるキーは、TLS 接続を介して交換されます。

ネットワークのサービス拒否攻撃

分散型サービス拒否 (DDOS) 攻撃は、有効なユーザーによるネットワークの正常な使用または機能が、攻撃者によって妨害された場合に発生します。サービス拒否攻撃により、攻撃者は以下のことを行うことができます。

  • 攻撃対象のネットワークで実行されているアプリケーションまたはサービスに対して無効なデータを送信して、そのようなアプリケーションまたはサービスが正常に機能するのを妨害する。
  • 大量のトラフィックを送信してシステムを過負荷状態にして、適正な要求に対するシステムの応答を停止または低速化する。
  • 攻撃の証拠を隠蔽する。
  • ユーザーがネットワーク リソースにアクセスできないようにする。

このような攻撃を緩和するため、Teams は Azure DDOS ネットワーク保護を実行し、同じエンドポイント、サブネット、およびフェデレーション エンティティからのクライアント要求を調整します。

盗聴

傍受は、攻撃者がネットワーク内のデータ パスにアクセスし、トラフィックを監視および読み取る機能を持っている場合に発生します。傍受はスニッフィングやスヌーピングとも呼ばれます。トラフィックがプレーン テキストの場合、攻撃者は、ネットワークのパスにアクセスしたときにトラフィックを読み取ることができます。例としては、データ パス上のルーターを制御することによって実行される攻撃があります。

Teams は、Microsoft 365 と Office 365 内の通信には相互 TLS (MTLS) およびサーバー間 (S2S) OAuth (他のプロトコルの中でも) を使用し、クライアントからサービスへの通信にも TLS 使用します。 ネットワーク上のすべてのトラフィックは暗号化されています。

これらの通信方法は、1 回の会話の時間内に盗聴を達成することを困難または不可能にします。 TLS はすべての関係者を認証し、すべてのトラフィックを暗号化します。 TLS は傍受を防ぎませんが、攻撃者は、暗号化を破らない限りトラフィックを読み取ることはできません。

NAT 周辺のリレーを使用したトラバーサル (TURN) プロトコルは、リアルタイム メディア通信に使用されます。TURN プロトコルでは、トラフィックの暗号化は必須ではなく、送信する情報は、メッセージの整合性によって保護されます。傍受にさらされているにもかかわらず、パケットのソースと宛先のアドレスを見るだけで、送信する情報 (つまり、IP アドレスとポート) を直接抽出できます。Teams サービスは、クリア テキストで送信されることのない TURN パスワードをはじめとするいくつかのアイテムから得られるキーを使用して、メッセージのメッセージ整合性を確認することにより、データが有効であることを確保します。メディア トラフィックには SRTP を使用し暗号化されています。

ID スプーフィング (IP アドレス スプーフィング)

スプーフィングは、権限をもたない攻撃者がネットワーク、コンピューター、ネットワーク コンポーネントの IP アドレスを特定して使用することで行われます。攻撃が成功すると、攻撃者は、IP アドレスによって通常どおりに識別されたエンティティのように操作することが可能になります。

TLS はすべての関係者を認証し、すべてのトラフィックを暗号化します。TLS を使用すると、攻撃者が特定の接続 (たとえば、相互 TLS 接続など) で IP アドレスのスプーフィングを実行するのを防げます。攻撃者がドメイン ネーム システム (DNS) サーバーのアドレスを偽装する可能性は残ります。ただし、Teams の認証は証明書を使用して実行されるため、攻撃者が通信でいずれかの関係者にスプーフィングを実行するために必要な有効な情報を入手することはありません。

中間者攻撃

中間者攻撃は、攻撃者が 2 人の通信ユーザー間の通信を双方に気づかれることなく攻撃者のコンピューターを介するように再ルーティングすることで行われます。攻撃者は、目的の受信者に到達する前にトラフィックをモニターし読み取ることができます。通信中の各ユーザーは、意図したユーザーとだけ通信していると考えながら、知らずのうちに攻撃者にトラフィックを送信し、攻撃者からトラフィックを受信します。このシナリオは、攻撃者が Active Directory ドメイン サービスを変更して信頼するサーバーとして攻撃者のサーバーを追加したり、クライアントがサーバーに接続する際に攻撃者経由で接続するように DNS 構成を変更したり、他の手段を使用できる場合に発生します。

Teamsのオーディオ、ビデオ、アプリケーション共有に参加している2つのエンドポイント間のメディアトラフィックに対する中間者攻撃は、安全なリアルタイム転送プロトコル (SRTP) を使用してメディアストリームを暗号化することで防ぐことができます。 暗号化鍵は、TLS 1.2 と AES-256 (GCMモード) で暗号化された UDP または TCP チャネルを利用する独自のシグナリングプロトコル (Teams Call Signaling プロトコル) を介して 2 つのエンドポイント間でネゴシエートされます。

リアルタイム トランスポート プロトコル (RTP) リプレイ攻撃

リプレイ アタックは、二者間の有効なメディア伝送が傍受され、有害な目的のために再伝送されると生じます。 Teams は、受信者がすでに受信したRTPパケットのインデックスを保持して、インデックスにすでにリストされているパケットと新しい各パケットを比較できるようにすることで、リプレイ攻撃から伝送を保護する安全なシグナリングプロトコルで SRTP を使用します。

SPIM

SPIM は、スパムのようですが、インタンス メッセージ形式の迷惑な商用インスタント メッセージまたはプレゼンス サブスクリプション要求です。それ自体はネットワークを侵害するものではありませんが、少なくとも迷惑なものであり、リソースの可用性および生産性を低下させ、結果としてネットワークの侵害を招く可能性があります。SPIM の一例として、ユーザーが要求を送信することで相互に SPIM を送るケースがあります。ユーザーは相互にブロックして SPIM を防ぐことができますが、フェデレーションの場合、悪意のある人物による連携された SPIM 攻撃が確立されると、パートナーからのフェデレーションを無効にしない限り、対処が困難になるおそれがあります。

ウイルスとワーム

ウイルスは、より多くの類似したコード単位数を再現することを目的とするコードの単位数です。ウイルスは、有効に機能するためにホスト (ファイル、電子メール、プログラムなど) を必要とします。ウイルスと同様に、ワームは、より類似したコード単位を再現するコードの単位ですが、ウイルスとは異なりホストを必要としません。ウイルスとワームは、クライアント間でファイルを転送しているとき、または他のユーザーから URL が送信されたときに主に出現します。ウイルスがコンピューター上に存在する場合、そのウイルスは、たとえば、無断でユーザー ID を使用してインスタント メッセージを送信する可能性があります。定期的なウイルス スキャンなどの標準的なクライアント セキュリティのベスト プラクティスは、この問題を軽減します。

Teams のセキュリティ フレームワーク

Teams は、ゼロ トラストや最小特権アクセスの原則などのセキュリティのアイデアを支持しています。 このセクションでは、Microsoft Teams のセキュリティ フレームワークを形成する基本要素の概要を取り上げます。

主要な要素:

  • Azure Active Directory (Azure AD)、 ユーザーアカウントに対して、単一の信頼できるバックエンド リポジトリを提供します。 ユーザー プロフィール情報は、Microsoft Graph のアクションを通して Azure AD に保存されます。
    • ネットワーク トラフィックをトレースする際に発生する可能性がある複数のトークンが発行されることがあります。 これには、チャットや音声トラフィックを調べているときにトレースで示されることがある Skype トークンが含まれます。
  • トランスポート層セキュリティ (TLS) は、移動中のチャネルを暗号化します。 認証は、証明書に基づく相互 TLS (MTLS) を使用するか、Azure AD に基づくサービス間認証を使用して行われます。
  • ポイント間の音声、ビデオ、アプリケーション共有のストリームは、セキュア リアルタイム転送プロトコル (SRTP) で暗号化され、整合性がチェックされます。
  • トレースに OAuth トラフィックが表示されます。特に、投稿からファイルに移動する場合など、Teams のタブを切り替える際のトークン交換とアクセス許可のネゴシエーションに関するものです。 タブの OAuth フローの例については、こちらのドキュメントを参照してください。
  • Teams ではユーザーの認証に業界標準のプロトコルができる限り使用されます。

次のセクションでは、これらの主要なテクノロジについて説明します。

Azure Active Directory

Azure Active Directory は、Microsoft 365 および Office 365 のディレクトリ サービスとして機能します。すべてのユーザーおよびアプリケーションのディレクトリ情報とポリシー割り当てが格納されます。

Teams でのトラフィック暗号化

この表は、主なトラフィックの種類と、暗号化に使用されるプロトコルを示しています。

トラフィックの種類 暗号化方式
サーバー間 TLS (MTLS またはサービス間 OAuth を使用)
クライアントからサーバー (インスタント メッセージングやプレゼンスなど) TLS
メディア フロー (メディアのオーディオとビデオの共有など) TLS
メディアの音声とビデオの共有 SRTP/TLS
シグナリング TLS
クライアント間の強化された暗号化 (エンドツーエンド暗号化通話など) SRTP/DTLS

証明書失効リスト (CRL) 配布ポイント

Microsoft 365 および Office 365 のトラフィックは TLS/HTTPS 暗号化チャネル経由で行われます。つまり、すべてのトラフィックの暗号化に証明書が使用されます。Teams では、すべてのサーバー証明書に 1 つ以上の CRL 配布ポイントが含まれている必要があります。CRL 配布ポイント (CDP) とは、証明書の発行後にそれが失効していないこと、および証明書が有効期限内にあることを確認するために、CRL をダウンロードできる場所です。CRL 配布ポイントは、URL として証明書のプロパティに記述され、セキュア HTTP です。Teams サービスは、すべての証明書認証で CRL を確認します。

拡張キーの使用方法

Teams サービスのすべてのコンポーネントでは、サーバー認証用の拡張キー使用法 (EKU) をサポートするために、すべてのサーバー証明書が必要です。 サーバー認証用に EKU フィールドを構成することは、サーバーの認証に対して、その証明書が有効であることを意味します。この EKU は、MTLS には不可欠です。

Teams の TLS

Teams データは、Microsoft サービス、サービス間、およびクライアントとサービス間で、転送中および保存中に暗号化されます。 Microsoft は、TLS や SRTP などの業界標準テクノロジを使用してこれを実行し、転送中のすべてのデータを暗号化します。 転送中のデータには、メッセージ、ファイル、会議、およびその他のコンテンツが含まれます。 エンタープライズ データも、Microsoft サービスの保存中に暗号化されるので、組織は電子情報開示などの方法でセキュリティとコンプライアンスの責務に対応するために、必要に応じてコンテンツを復号化することができます。 Microsoft 365 の暗号化の詳細については、「Microsoft 365 の暗号化」を参照してください

TCP データ フローは TLS を使用して暗号化され、MTLS およびサービス間 OAuth プロトコルは、サービス、システム、およびクライアント間のエンドポイント認証された通信を提供します。 Teams は、これらのプロトコルを使用して、信頼されたシステムのネットワークを形成し、このネットワーク上のすべての通信が暗号化されるようにします。

TLS 接続の場合、クライアントはサーバーからの有効な証明書を要求します。証明書が有効であると見なされるためには、証明書の発行元の証明機関 (CA) がクライアントからも信頼されていること、およびサーバーの DNS 名が証明書の DNS 名に一致していることが必要です。証明書が有効な場合、クライアントは証明書内の公開キーを使用して、通信に使う対称暗号化キーを暗号化し、証明書の最初の所有者だけが、その秘密キーを使用して通信の内容を暗号化することができます。この接続は信頼済みと見なされ、それ以降は他の信頼されたサーバーやクライアントからチャレンジされません。

TLS の使用は、盗聴と中間者攻撃の両方を防ぐのに役立ちます。中間者攻撃では、攻撃者は 2 つのネットワーク エンティティ間の通信を、双方に気付かれることなく、攻撃者のコンピューターを経由して再ルーティングします。2 つのエンドポイント間の公開鍵暗号を使用して調整された暗号を用いてアプリケーション層に対する中間者攻撃のリスクを部分的に軽減するのが、TLS および Teams の信頼済みサーバーの仕様です。攻撃者は、対応する秘密キーを持ち、通信を復号化するためにクライアントが通信しているサービス名に対して発行された、有効で信頼できる証明書を所有している必要があります。

Teams および Microsoft 365 での暗号化

Microsoft 365 内には、複数の暗号化レイヤーが機能しています。 Teams での暗号化は、組織のコンテンツを保護するために、その他の Microsoft 365 の暗号化と連携します。 この記事では、Teams に固有の暗号化テクノロジについて説明します。 Microsoft 365 での暗号化の概要については、「Microsoft 365 での暗号化」を参照してください。

メディアの暗号化

Teams の通話フローは、HTTPS 経由の セッション記述プロトコル (SDP) RFC 8866 オファーと応答モデルに基づいています。 呼び出し先が着信呼び出しを受け入れると、呼び出し元と呼び出し先はセッション パラメーターに同意します。

メディア トラフィックは、RTP トラフィックに対して機密性、認証、リプレイ攻撃保護を提供する RTP (Real-Time Transport Protocol) のプロファイルである SRTP (Secure RTP) を使用して、呼び出し元と呼び出し先との間で暗号化され、フローします。SRTP は、安全な乱数ジェネレータによって生成されたセッション キーを使用し、シグナリング TLS チャネルを使用して交換します。ほとんどの場合、クライアントからクライアントへのメディア トラフィックは、クライアントからサーバーへの接続シグナリングを介してネゴシエートされ、クライアントからクライアントへ直接移動する場合は、SRTP を使用して暗号化されます。

通常の呼び出しフローでは、暗号化キーのネゴシエーションは、通話シグナリング チャネルを介して行われます。 エンドツーエンドの暗号化された通話では、シグナリング フローは通常の 1 対 1 の Teams 通話と同じです。 ただし、Teams は DTLS を使用して、両方のクライアント エンドポイントで生成された通話ごとの証明書に基づいて暗号化キーを派生させます。 DTLS はクライアント証明書に基づいてキーを派生するため、キーが Microsoft に知られることはありません。 両方のクライアントがキーに同意すると、メディアは SRTP 経由でこの DTLS ネゴシエートされた暗号化キーを使用してフローを開始します。

呼び出し元と呼び出し先の間の中間者攻撃から保護するために、Teams は、呼び出し元と呼び出し先のエンドポイント通話証明書の SHA-256 拇印から 20 桁のセキュリティ コードを派生させます。 呼び出し元と呼び出し先は、20 桁のセキュリティ コードを相互に読み取って一致するかどうかを確認することで、それを検証できます。 コードが一致しない場合、呼び出し元と呼び出し先の間の接続は中間者攻撃によって傍受されています。 通話が侵害された場合、ユーザーは手動で通話を終了できます。

Teams では、資格情報に基づくトークンを使用して、TURN によるメディア リレーに対するアクセス権をセキュリティで保護します。 メディア リレーは、TLS によってセキュリティが保護されたチャネルを介してトークンを交換します。

連邦情報処理規格 (FIPS)

Teams では、暗号化キーの交換に FIPS 準拠アルゴリズムを使用します。 FIPS 実装の詳細については、「連邦情報処理規格 (FIPS) 文書 140-2」をご覧ください。

ユーザー認証とクライアント認証

信頼できるユーザーとは、Microsoft 365 または Office 365 で Azure AD によって資格情報が認証された者を指します。

認証では、ユーザーの資格情報が信頼されたサーバーまたはサービスに渡されます。Teams では、ユーザーの状態や場所に応じて、次の認証プロトコルを使用します。

  • 先進認証 (MA) は、クライアントとサーバー間の通信用に Microsoft が OAUTH 2.0 を実装したものです。 多要素認証や条件付きアクセスなどのセキュリティ機能を有効にします。 MA を使用するには、オンライン テナントとクライアントの両方で MA を有効にする必要があります。 PC とモバイルの Teams クライアントと Web クライアントすべてが、MA をサポートしています。

注意

Azure AD の認証および承認の方法の詳細については、この記事の概要セクションと「Azure AD での認証の基本」セクションを参照してください。

チーム認証は、Azure AD および OAuth を通して行います。 認証プロセスは、次のように単純化できます。

  • [ユーザー サインイン] > [トークンの発行] > 次の要求では、発行されたトークンを使用します。

クライアントからサーバーへの要求は、OAuth を使用して Azure AD によって認証および承認されます。 フェデレーション パートナーによって発行された有効な資格情報を持つユーザーは信頼され、ネイティブ ユーザーと同じプロセスで認証を受けることができます。 ただし、管理者がさらに制限を課すこともできます。

メディア認証には、ICE プロトコルおよび TURN プロトコルでも、IETF TURN RFC に記載されているとおり、ダイジェスト認証が使用されます。

Windows PowerShell と Teams 管理ツール

Teams では、IT 管理者は Microsoft 365 管理センターまたはテナント リモートPowerShell (TRPS) を使用してサービスを管理できます。テナント管理者は最新認証を使用して TRPS への認証を行います。

インターネット境界で Teams へのアクセスを設定する

Teams が正しく機能するために (たとえば、ユーザーが会議に参加できるなど)、顧客は Teams クラウド内のサービスへの発信 UDP および TCP トラフィックが許可されるようにインターネット アクセスを設定する必要があります。詳しくは、「Office 365 URL および IP アドレス範囲」を参照してください。

UDP 3478 から 3481 と TCP 443

UDP 3478 から 3481 および TCP 443 ポートは、クライアントが音声視覚サービスを要求するために使用されます。 クライアントは、この 2 つのポートを使用して、メディア フローを有効にするための UDP ポートと TCP ポートをそれぞれ割り当てます。 これらのポートのメディア フローは、TLS で保護されたシグナリング チャネルを介して交換されるキーで保護されます。

Teams のフェデレーション保護

フェデレーションによって、他の組織との通信で、IM やプレゼンスを共有することができます。Teams では、フェデレーションは既定で有効です。ただし、テナント管理者は、Microsoft 365 管理センターを介してフェデレーションを制御できます。

Teams 会議への脅威に対応する

Teams の会議に参加する人と提示する情報にアクセスできる他の人を制御するための 2 つのオプションがあります。

  1. ロビー の設定を使用して会議に参加する人を制御できます。

    [会議のオプション] ページで使用可能な [ロビーをバイパスするユーザー] 設定オプション 会議に直接参加するユーザー タイプ ロビーに入るユーザー タイプ
    自分の組織のユーザー - テナント内
    - テナントのゲスト
    - フェデレーション
    - 匿名
    - PSTN ダイヤルイン
    自分の組織および信頼できる組織のユーザー - テナント内
    - テナントのゲスト
    - フェデレーション
    - 匿名
    - PSTN ダイヤルイン
    すべてのユーザー - テナント内
    - テナントのゲスト
    - フェデレーションの匿名
    - PSTN ダイヤルイン
  2. 2 番目の方法は 構造化された会議 (発表者は行うべきことをすべて実行でき、出席者のエクスペリエンスは制御されます)。 構造化された会議に参加する場合、発表者は会議で出席者が行えることを制御できます。

    アクション 発表者 出席者
    話す、ビデオを共有する Y Y
    会議のチャットに参加する Y Y
    会議のオプション設定を変更する Y N
    他の参加者をミュートする Y N
    他の参加者を削除する Y N
    コンテンツを共有する Y N
    ロビーの他の参加者を許可する Y N
    他の参加者を発表者または出席者にする Y N
    録画を開始または停止する Y N
    他の参加者が PowerPoint を共有しているときに制御を取得する Y N

Teams は、エンタープライズ ユーザーにリアルタイムな会議の作成と参加の機能を提供します。エンタープライズ ユーザーは、Azure AD、Microsoft 365、または Office 365 のアカウントを持たない外部ユーザーをこれらの会議に招待し参加させることもできます。外部パートナーにより雇用され、安全で認証された ID を持つユーザーは会議に参加することもできます。また、権限を与えた場合は発表者になることもできます。匿名ユーザーは発表者として会議を作成したり会議に参加したりすることはできませんが、参加後に発表者に昇格させることはできます。

匿名ユーザーが Teams 会議に参加できるようにするには、Teams 管理センターの参加者の会議設定を有効にする必要があります。

注意

匿名ユーザー とは、組織のテナントで認証されていないユーザーのことです。 このコンテキストでは、すべての外部ユーザーは匿名と見なされます。 認証されたユーザーには、テナント ユーザーとテナントのゲスト ユーザーが含まれます。

外部ユーザーが Teams 会議に参加できるようにすると役立つことがありますが、セキュリティ上のリスクを伴います。 このリスクに対処するために、Teams は以下の保護を提供します。

  • 会議の制御特権を参加者の役割に応じて割り当てます。

  • 参加者の種類別に特定の会議へのアクセスを制限できます。

  • 会議をスケジュールできるのは、AAD アカウントと Teams ライセンスを持つユーザーに限定されます。

  • 匿名ユーザーつまり認証されていないユーザーがダイヤルインの会議に参加するには、いずれかの会議アクセス番号にダイヤルします。 [発信者がロビーをバイパスすることを常に許可する (Always allow callers to bypass the lobby)] 設定が [有効 (On)] になっている場合、発表者または認証されたユーザーが会議に参加するまで待つ必要があります。

    注意事項

    匿名ユーザー (明示的に招待されてないユーザー) が会議に参加することを望まない場合は、会議セクションの [参加者][匿名ユーザーが会議に参加できます]オフ に設定します。

また、ダイヤルイン発信者が会議の最初のユーザーになるための設定を開催者が構成することもできます。 この設定はユーザーの電話会議設定で構成し、対象ユーザーによってスケジュールされているすべての会議に適用されます。

注意

Teams におけるゲスト アクセスと外部アクセスについて詳しくは、こちらの記事を参照してください。 ゲスト ユーザーまたは外部ユーザーが Teams にログインするときに表示され、使用できる機能が取り上げられています。

会議を録画しているときに、コンテンツにアクセスするアクセス許可マトリックスを表示したい場合は、こちらの記事とそのマトリックスを参照してください。

参加者の役割

会議参加者は 3 つのグループに分類され、以下のようにそれぞれに独自の特権と制限があります。

  • 開催者 会議を一時的にまたはスケジュールに基づいて作成するユーザー。開催者は認証されたテナント ユーザーでなければならず、会議に関するすべてのエンド ユーザー関連の設定を制御できます。
  • 発表者 サポートされている任意のメディアを使用して会議で発表することが承認されているユーザー。定義上、会議の開催者は発表者でもあり、別の発表者を指定します。発表者の指定は、会議の予約時に行うことも、会議中に行うこともできます。
  • 参加者 会議に招待されているが、発表者になることは承認されていないユーザー。

発表者は、会議中に参加者を発表者に昇格することもできます。

参加者の種類

会議の参加者は、場所と資格情報によっても分類されます。これらどちらの特性を使用しても、特定の会議にアクセスできるユーザーを決定できます。ユーザーは次のカテゴリに大きく分類できます。

  • テナントに属するユーザー。これらのユーザーは、テナントの Azure Active Directory に資格情報を持っています。

    自分の組織内のユーザー - これらのユーザーは、テナントの Azure Active Directory に資格情報を持っています。 自分の組織内のユーザー には、招待されたゲスト アカウントも含まれます。

    リモート ユーザー - これらのユーザーは企業ネットワークの外部から参加しています。自宅や外出先で作業している従業員や、サービス規約に基づいて企業の資格情報を与えられている信頼できる仕入先の従業員などを含めることができます。リモート ユーザーは会議を作成して参加し、発表者として行動できます。

  • テナントに属さないユーザー。これらのユーザーは、テナントの Azure AD に資格情報を持っていません。

    フェデレーション ユーザー - フェデレーション ユーザーはフェデレーション パートナーの有効な資格情報を持っているので Teams によって認証済みユーザーとして扱われますが、会議開催者のテナントに対しては依然外部として扱われます。 フェデレーション ユーザーは会議に参加し、その後発表者になることができますが、フェデレーションされた企業では会議を作成することはできません。

    匿名ユーザー - 匿名ユーザーは、Active Directory ID を持たず、テナントとフェデレーションされません。

多くの会議には、外部ユーザーが関係します。 また、そうした顧客は、外部ユーザーに会議への参加を許可する前に、そのユーザーの身元を再確認することも求めています。 次のセクションでは、Teams で会議へのアクセスを明示的に許可されたユーザー タイプに制限し、すべてのユーザー タイプで会議に参加するために適切な 資格情報 の提示を求める方法について説明します。

参加者の許可

注意事項

匿名ユーザー (明示的に招待されてないユーザー) が会議に参加することを望まない場合は、会議セクションの [参加者][匿名ユーザーが会議に参加できます][オフ] に設定します。

Teams では、匿名ユーザーはロビーと呼ばれる待機エリアに転送できます。 発表者は、このようなユーザーの会議への参加を 許可 するか、拒否 できます。 こうしたユーザーがロビーに転送されると、発表者と出席者にそのことが通知され、匿名ユーザーは承認または拒否されるまで、あるいは接続がタイムアウトになるまで待つ必要があります。

既定の設定では、PSTN からダイヤルインする参加者は認証ユーザーが会議に参加すると直接会議に入りますが、このオプションを変更してダイヤルイン参加者も強制的にロビーに転送することができます。

会議の開催者は、ロビーで待たずに参加者が会議に参加できるかどうかを制御します。各会議は、次のいずれかの方法でアクセスできるように設定できます。

既定値は次のとおりです。

  • 自分の組織内のユーザー - 組織外のすべてのユーザーは、許可されるまでロビーで待機します。
  • 自分の組織と信頼できる組織のユーザー - 認証されたユーザーと、外部アクセス許可リストに含まれる Teams および Skype for Business のドメインからの外部ユーザーは、ロビーをバイパスできます。他のすべてのユーザーは、許可されるまでロビーで待機します。
  • 全員 - 認証ユーザーが会議に参加すると、会議参加者すべてはロビーをバイパスします。

発表者の機能

会議の開催者は、会議中に参加者が出席できるかどうかをコントロールします。各会議は、発表者を次のいずれかのオプションに制限するように設定できます。

  • 自分の組織内のユーザー - ゲストを含むすべてのテナント ユーザーが情報を提示できます。
  • 自分の組織と信頼できる組織のユーザー - ゲストを含むテナント ユーザーすべては情報を提示でき、外部アクセス許可リストに含まれる Teams および Skype for Business のドメインからの外部ユーザーも情報を提示できます。
  • 全員 - 会議の参加者すべてが発表者になります。

会議中に変更する

会議中に会議のオプションを変更できます。 変更が保存されると、実施中の会議にて数秒以内で確認できます。 その後の会議すべてに対しても有効です。

Top 12 tasks for security teams to support working from home (在宅勤務をサポートするためにセキュリティ チームが行う 12 の主なタスク)

Microsoft Trust Center

Microsoft Teams で会議の設定を管理する

VPN スプリット トンネリングを使用してリモート ユーザーの Microsoft 365 または Office 365 の接続を最適化する

Teams での会議の録画、録画が保存されている場所、および録画にアクセスできるユーザー