セキュリティと Microsoft Teams

  • [アーティクル]
  • 適用対象:
    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 の認証は証明書を使用して実行されるため、攻撃者は通信の当事者の 1 人を偽装するために必要な有効な情報を持たないようにします。

中間者攻撃

中間者攻撃は、攻撃者が 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 でのフィッシング攻撃は、金銭的にも安心にもコストがかかります。 これらの攻撃は、パスワード、コード、クレジット カード番号、その他の重要な情報などの情報を偽の Web サイトリンクや添付ファイルを介して、ユーザーをだまして公開することで動作します。これは、無害に見えるが、クリックすると危険なソフトウェアをダウンロードできる添付ファイルです。 これらの攻撃の多くはユーザーをターゲットにしているため、アクセスが多い価値の高いターゲットであっても、広範な攻撃を受ける可能性があります。 ただし、Teams 管理者とユーザーの両方に対してフィッシング対策戦略があります。

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

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

主要な要素:

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

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

Microsoft Entra ID

Microsoft Entra ID は、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のMicrosoft Entra ID によって認証されたユーザーです。

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

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

注意

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

Teams 認証は、Microsoft Entra ID と OAuth を使用して実行されます。 認証プロセスは、次のように単純化できます。

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

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

メディア認証には、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 会議への脅威に対応する

エンタープライズ ユーザーは、リアルタイム会議を作成して参加し、Microsoft Entra ID、Microsoft 365、または Office 365 アカウントを持たない外部ユーザーを招待して、これらの会議に参加できます。

外部ユーザーを Teams 会議に参加させることは便利ですが、セキュリティ 上のリスクも発生します。 これらのリスクに対処するために、Teams では次のセーフガードが使用されます。

会議の前:

  1. 会議への参加を許可する 外部参加者の種類 を決定します。

    • 匿名アクセス を使用すると、(1) Team にサインインしていない認証されていないユーザー (通常はブラウザーの会議リンクを介して参加) と (2) オーガナイザーと組織との外部アクセスを確立していない外部テナントからの認証されたユーザーの会議参加を許可します。

    • 外部アクセスを使用すると、認証された外部ユーザーと組織が、より多くの特権で会議に参加できるユーザーを決定できます。 これらのユーザーは、信頼できる組織に属していると見なされます。

    • ゲスト アクセス を使用すると、組織外のユーザーのゲスト アカウントを作成して、チーム、チャネル内のドキュメント、リソース、チャット、アプリケーションにアクセスしながら、企業データを制御できます。

注意

組織との外部アクセス権を持たないユーザーと組織は匿名と見なされます。 匿名参加をブロックした場合、会議に参加できません。

外部アクセスは双方向で有効にする必要があります。両方の組織は相互外部アクセスを許可する必要があります。

注意

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

  1. 会議に直接参加できるユーザーと、開催者、共同開催者、または発表者会議の役割を持つ認証されたユーザーがロビーで承認されるまで待機する必要があるユーザーを決定します。

  2. 匿名ユーザーとダイヤルイン発信者が、組織のユーザー、信頼された組織のユーザー、ゲスト アクセス権を持つユーザーが通話に参加する前に会議を開始できるかどうかを決定します。

注意

会議のスケジュール設定は、組織から認証されたユーザー、または組織へのゲスト アクセス権を持つユーザーに制限されます。

会議中:

  1. 特定 の参加者会議ロール を割り当てて、会議コントロール権限を決定します。 会議の参加者は、それぞれ独自の特権と制限を持つグループに分類 されます。ここで説明します。

注意

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

会議の実行中に次の変更を行います。

注意

Teams の管理者設定の変更には、最大 24 時間かかることがあります。

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

Microsoft Trust Center

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