安全性和 Microsoft Teams

Microsoft Teams 是 Microsoft 365 和 Office 365 服務的一部分，其會遵循所有安全性最佳做法和程序，例如透過深度防禦達到服務等級的安全性、服務中的客戶控制、強化安全性及最佳營運做法。 如需詳細資訊，請參閱 Microsoft 信任中心。

從設計上值得信賴

Teams 在設計和開發時就符合 Microsoft 高可信度電腦運算安全性開發週期 (SDL) 的規範，相關說明請參閱 Microsoft 安全性開發週期 (SDL)。 建立更安全整合通訊系統的第一步是設計威脅模型，並在設計每一項功能時同步測試。 程式碼撰寫和慣例已內建許多安全性相關的改進。 在程式碼移轉至最終產品之前，建置階段工具會偵測緩衝區溢位和其他潛在的安全性威脅。 設計時不可能預防到所有未知的安全性威脅。 沒有任何系統可以保證絕對的安全性。 不過，由於從開發產品起就採用安全設計原則，因此 Teams 納入了業界標準安全技術來作為其架構的基礎。

透過預設而值得信賴

Teams 中的網路通訊預設會進行加密。 透過要求所有伺服器使用憑證，並使用 OAUTH、傳輸層安全性 (TLS)、安全即時傳輸通訊協定 (SRTP)，所有的 Teams 資料都會在網路上受到保護。

Teams 如何處理常見的安全性威脅

本節列出 Teams 服務安全性較為常見的威脅，以及 Microsoft 如何緩解這些威脅。

盜取金鑰攻擊

Teams 會使用 Windows Server 作業系統中的 PKI 功能，來保護用於 TLS 連線加密的金鑰資料。 用於媒體加密的金鑰會透過 TLS 連線來交換。

網路拒絕服務攻擊

當攻擊者妨礙有效使用者正常使用網路並使網路失去功能時，就表示發生了分散式阻斷服務 (DDOS) 攻擊。 藉由使用拒絕服務攻擊，攻擊者可以：

• 對受攻擊網路上所執行的應用程式和服務傳送無效資料，以干擾其正常功能。
• 傳送大量流量，讓系統超載直到其停止回應或只能緩慢回應合法要求。
• 隱藏攻擊證據。
• 妨礙使用者存取網路資源。

Teams 會執行 Azure DDOS 網路保護，並對來自相同端點、子網路和同盟實體的用戶端要求進行節流，藉此來緩解這些攻擊。

竊聽

當攻擊者獲得網路中資料路徑的存取權，並有能力監視及讀取流量時，就會發生竊聽。 竊聽也稱為探查或窺探。 如果流量是純文字，攻擊者就能在獲得路徑的存取權時讀取流量。 藉由控制資料路徑上的路由器來執行攻擊便是其中一例。

Teams 使用相互 TLS (MTLS) 和伺服器對伺服器 (S2S) OAuth (在其他通訊協定之間) 進行 Microsoft 365 和 Office 365 內的伺服器通訊，同時也使用從用戶端到服務的 TLS。 網路上的所有流量都已加密。

這些通訊方式使在單一交談期間內的竊聽變得難以達成或不可能達成。 TLS 會對各方實施驗證，並加密所有流量。 TLS 雖然不會妨礙竊聽，但除非加密遭到破解，否則攻擊者將無法讀取流量。

在 NAT 周遭使用轉送的周遊 (TURN) 通訊協定會用於即時媒體用途。 TURN 通訊協定不會要求流量必須加密，而是會透過郵件完整性來保護所傳送的資訊。 此通訊協定雖對竊聽不設防，但其所傳送的資訊 (也就是 IP 位址和連接埠) 可藉由查看封包的來源和目的地位址，就能直接擷取到。 Teams 服務可確保資料的有效性，其方法是使用衍生自少數幾個項目、絕對不會以純文字傳送的金鑰 (包括 TURN 密碼) 來檢查郵件的完整性。 SRTP 則可用於媒體流量，而且也會進行加密。

身分識別詐騙 (IP 位址詐騙)

當攻擊者識別、然後使用網路、電腦或網路元件的 IP 位址並未經授權就使用時，就表示發生詐騙。 如果攻擊成功，攻擊者就能假裝自己是經過該 IP 位址正常識別的實體。

TLS 會對各方實施驗證，並加密所有流量。 使用 TLS 可防止攻擊者對特定連線 (例如相互 TLS 連線) 執行 IP 位址詐騙。 攻擊者仍可詐騙網域名稱系統 (DNS) 伺服器的位址。 不過，由於 Teams 中的驗證會使用憑證來執行，因此攻擊者不會擁有在通訊中詐騙其中一方所需的有效憑證。

中間人攻擊

當攻擊者在通訊使用者雙方不知情的情況下，透過攻擊者的電腦來重新路由傳送兩位使用者之間的通訊，就表示發生了中間人攻擊。 攻擊者可在流量傳送給預期的收件者之前，監視並讀取流量。 通訊中的每個使用者都會在不知情的情況下傳送流量給攻擊者，以及接收來自攻擊者的流量，卻又認為他們在與預期的使用者通訊。 如果攻擊者能修改 Active Directory 網域服務並將其伺服器新增為信任的伺服器、或修改 DNS 設定，或使用其他方式讓用戶端透過攻擊者以其方式連線到伺服器，就會發生此情況。

透過使用安全即時通訊協定 (SRTP) 來加密媒體串流，可防止對參與 Teams 音訊、視訊和應用程式共用中兩個端點間的媒體流量遭到「中間人」攻擊。 加密金鑰會透過專有信號通訊協定 (Teams 通話信號協定) 在兩個端點之間協商，該協定使用 TLS 1.2 和 AES-256 (在 GCM 模式中) 加密的 UDP 或 TCP 通道。

即時傳輸通訊協定 (RTP) 重新執行攻擊

當兩方之間的有效媒體傳輸遭到惡意攔截並重新傳輸時，就會發生重播攻擊。 Teams 將 SRTP 並與安全訊號通訊協定結合使用，該通訊協定透過讓接收者保有已收到 RTP 封包的索引，並將每個新封包與索引中已列出的每個封包進行比較，從而保護傳輸免於遭受重新執行攻擊。

Spim

Spim 是未經同意的商業立即訊息或目前狀態訂閱要求 (例如垃圾郵件)，但形式為立即訊息。 Spim 本身雖然不會危害網路，但卻很煩人，且會降低資源可用性和生產力，並可能導致網路遭到危害。 例如，使用者傳送要求來對彼此進行 Spim 攻擊。 使用者雖可彼此封鎖以避免 Spim 攻擊，但如果在同盟時惡意角色建立了協調一致的 Spim 攻擊，則除非您停用合作夥伴的同盟，否則將難以解決該問題。

病毒與蠕蟲

病毒是一個程式碼單位，其目的是重現更多類似的程式碼單位。 若要發生作用，病毒需要有宿主，例如檔案、電子郵件或程式。 和病毒一樣，蠕蟲也是一種程式碼單位，它可以產生更多類似的程式碼單位，但不像病毒一樣需要宿主。 病毒和蠕蟲主要會在用戶端之間的檔案傳輸過程中，或在其他使用者傳送 URL 時現身。 舉例來說，如果電腦上有病毒，病毒就可以使用您的身分識別，並以您的名義傳送立即訊息。 標準用戶端安全性最佳做法 (例如定期掃描病毒) 可緩解此問題。

網路釣魚嘗試

Teams 中的網路釣魚攻擊是價格高貴且安心的。 這些攻擊的運作方式是誘騙使用者透過偽造的網站連結，以及看似不必要但按一下可下載有危險軟體的附件，揭露密碼、代碼、信用卡號碼及其他重要資訊。 因為許多這類攻擊的目標使用者，即使是具有大量存取權的高價值目標，它們也可能很普遍。 不過，Teams 系統管理員和使用者都有反網路釣魚策略。

• Teams 的安全性最佳做法，每個人都應該知道並使用

  • 使用者可以瞭解如何發現並保護自己免于網路釣魚

• 如果貴組織中的使用者收到來自外部寄件者的網路釣魚訊息，租使用者系統管理員可以 使用圖形 API 「RemoveAllAccessForUser」從使用者的檢視中移除此訊息。

• 適用於 Office 365 的 Microsoft Defender也保護 Teams

  • 攻擊模擬可協助系統管理員訓練 Teams 使用者並保護易受攻擊者
  • 而且 Teams 使用者也有可疑的訊息報告

Teams 的安全性架構

Teams 認可安全性構想，例如 [零信任] 和最低權限存取的原則。 本節概述組成 Microsoft Teams 安全性架構的基本元素。

核心元素如下：

• Microsoft Entra識別碼，為使用者帳戶提供單一信任的後端存放庫。 使用者設定檔資訊會透過 Microsoft Graph 的動作儲存在Microsoft Entra識別碼中。
  • 如果您追蹤網路流量，可能會發現多個已核發的權杖。 包括可能會在查看聊天和音訊流量時於追蹤內看到的 Skype 權杖。
• 傳輸層安全性 (TLS) 會加密運行中頻道。 驗證會使用共同的 TLS (MTLS) 、根據憑證，或是使用以Microsoft Entra ID 為基礎的服務對服務驗證。
• 系統會使用安全即時傳輸通訊協定 (SRTP) 加密點對點音訊、視訊和應用程式共用串流，並進行完整性檢查。
• 您將會在追蹤內查看 OAuth 流量，特別是在 Teams 中切換索引標籤時而涉及的權杖交換和交涉權限時，例如要從「貼文」移至「檔案」。 如需索引標籤的 OAuth 流量範例，請參閱此文件。
• Teams 會盡可能使用業界標準通訊協定來驗證使用者。

以下各節會討論其中的某些核心技術。

Microsoft Entra識別碼

Microsoft Entra識別碼可做為 Microsoft 365 和 Office 365 的目錄服務。 它會儲存所有使用者和應用程式目錄資訊和原則指派。

Teams 中的流量加密

此表格顯示主要的流量類型，以及用於加密的通訊協定。

憑證撤銷清單 (CRL) 發佈點

Microsoft 365 和 Office 365 流量會透過 TLS/HTTPS 加密通道來進行，也就是說，系統會使用憑證來加密所有流量。 Teams 要求所有伺服器憑證都包含一或多個 CRL 發佈點。 您可以從 CRL 發佈點 (CDP) 來下載 CRL，以便驗證憑證自發行以來尚未遭到撤銷，且憑證仍在有效期限內。 CRL 發佈點是安全的 HTTP，會以 URL 的形式註明在憑證的屬性中。 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 可同時防範竊聽和中間人攻擊。 發生中間人攻擊時，攻擊者會在網路實體雙方不知情的情況下，透過攻擊者的電腦來重新路由傳送兩者之間的通訊。 TLS 與 Teams 的信任伺服器規格透過在兩個端點之間使用公開金鑰加密來進行加密協調，部分緩解了應用程式層受到中間人攻擊的風險。 攻擊者必須擁有對應私密金鑰的有效且受信任的憑證，並核發給用戶端正在通訊的服務名稱，才能解密通訊。

Teams 和 Microsoft 365 中的加密

Microsoft 365 中存在多層加密。 Teams 中的加密與 Microsoft 365 加密的其餘部分配合運作，以保護貴組織內容。 本文描述了 Teams 特定的加密技術。 如需 Microsoft 365 中加密的概觀，請參閱 Microsoft 365 中的加密。

媒體加密

Teams 中的通話流程基於 HTTPS 上的 工作階段描述通訊協定 (SDP) RFC 8866方案和接聽模型。 被呼叫者接受來電後，呼叫者和被呼叫者就工作階段參數達成一致。

媒體流量由呼叫者和被呼叫者使用安全 RTP (SRTP) 進行加密，並在雙方之間流動。SRTP 是即時傳輸通訊協定 (RTP) 的設定檔，可為 RTP 流量提供機密性、驗證和重播攻擊防護。 SRTP 使用由安全亂數產生器所產生，並透過訊號 TLS 通道來進行交換的工作階段金鑰。 在大多數情况下，用戶端對用戶端媒體流量透過用戶端對伺服器連線訊號進行交涉，并在用戶端直接導向至用戶端時，會使用 SRTP 加密。

在正常通話流程中，加密金鑰的協商透過通話信號通道進行。 在端對端加密通話中，通訊流程與常規的一對一 Teams 通話相同。 但是，Teams 使用 DTL 根據在兩個用戶端端點上產生的每次通話憑證衍生加密金鑰。 由於 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識別碼驗證認證的使用者。

驗證是將使用者認證佈建到受信任伺服器或服務的程序。 Teams 會根據使用者的狀態和位置，而使用下列驗證通訊協定。

• 新式驗證 (MA) 是 Microsoft 針對用戶端到伺服器的通訊所進行的 OAUTH 2.0 實作。 此驗證可啟用多重要素驗證和條件式存取等安全性功能。 要使用 MA，線上租用戶和用戶端都需要啟用 MA。 電腦和行動裝置上的 Teams 用戶端以及 Web 用戶端全都支援 MA。

Teams 驗證是透過 Microsoft Entra ID 和 OAuth 來完成。 驗證程序可簡化為：

• 使用者登入 > 權杖發佈 > 下一次要求使用已發出的權杖。

使用 OAuth 時，用戶端到伺服器的要求會經過Microsoft Entra識別碼的驗證和授權。 擁有同盟合作夥伴所核發有效認證的使用者會受到信任，並和原生使用者一樣成功通過相同的程序。 不過，系統管理員可以實施進一步的限制。

針對媒體驗證，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 連接埠來向服務要求音訊視覺效果。 用戶端可使用這兩個連接埠來分別配置 UDP 和 TCP 連接埠，以啟用這些媒體流量。 這些連接埠上的媒體流量會使用金鑰來加以保護，金鑰則會透過受 TLS 保護的訊號通道來進行交換。

Teams 的同盟保護機制

同盟可讓您的組織與其他組織通訊，以共用 IM 和目前狀態。 Teams 預設會開啟同盟功能。 但是，租用戶系統管理員可以透過 Microsoft 365 系統管理中心控制同盟。

解決 Teams 會議面臨的威脅

企業使用者可以建立並加入即時會議，並邀請沒有Microsoft Entra識別碼、Microsoft 365 或Office 365帳戶的外部使用者參與這些會議。

讓外部使用者參與 Teams 會議很有用，但也帶來一些安全性風險。 為了解決這些風險，Teams 會使用下列防護措施：

在會議之前：

1. 決定哪些 外部參與者類型 可以加入您的會議：

   • 匿名存取 可讓 (1) 未登入 Teams 的未經驗證使用者加入會議， (通常會透過瀏覽器) 中的會議連結加入， 並且 從未與召集人及組織建立外部存取的外部租使用者 (2) 經過驗證的使用者加入。

   • 透過 外部存取， 您可以決定哪些已驗證的外部使用者和組織將能以更多許可權加入您的會議。 這些使用者被視為屬於信任的組織。

   • 來賓存取可 讓您為組織外部的人員建立來賓帳戶，以存取團隊、頻道中的檔、資源、聊天和應用程式，同時維持對公司資料的控制。

2. 決定誰可以直接加入會議，以及誰需要在大廳等候，才能被召集人、共同召集人或具有簡報者會議角色的已驗證使用者允許：

   • IT 管理員控制項
   • 召集人的控制項

3. 決定匿名使用者和撥入式來電者是否可以在組織中的使用者、受信任組織使用者和有來賓存取權的使用者加入通話之前召開會議。

在會議期間：

1. 指派特定 參與者會議角色 以決定會議控制許可權。 會議參與者分成群組，每個群組都有自己的許可權和限制， 如下所述。

在執行會議時修改：

• 您可以在會議繼續進行時 修改會議選項 。 儲存變更後，在幾秒內就會在進行中的會議中明顯顯示。 變更也會影響未來進行的任何會議。 如需如何指派這些角色的詳細資訊， 請參閱本文。

相關主題

安全性團隊支援在家工作最常見的 12 項工作

Microsoft 信任中心

使用 VPN 分割通道將遠端使用者的 Microsoft 365 或 Office 365 連線能力最佳化

• 實作 VPN 分割通道