安全性与 Microsoft Teams
重要
Teams 服务模型可能会有所更改，以改善客户体验。 例如，默认访问或刷新令牌到期时间可能会经过修改，以提高使用 Teams 用户的性能和身份验证弹性。 进行任何此类更改的目的都是为了通过设计保证 Teams 安全可靠。
作为 Microsoft 365 和 Office 365 服务的一部分，Microsoft Teams 遵循所有安全最佳做法和过程，如通过深度防御保障服务级别安全性、服务内的客户控制、安全强化和操作最佳做法。 有关完整详细信息，请参阅 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 攻击，则可能很难克服，除非你禁用合作伙伴的联盟。
病毒与蠕虫
病毒是一种代码单元，其目的是复制更多类似的代码单元。 病毒需要主机（如文件、电子邮件或程序）才能起作用。 与病毒一样，蠕虫病毒也是一种代码单元，同样以复制更多的类似代码单元为目的，但与病毒不同的是，蠕虫并不需要主机。 病毒和蠕虫主要是在客户端之间传送文件期间或从其他用户发送 URL 时出现。 例如，如果你的计算机上存在某种病毒，则该病毒可使用你的身份代表你发送即时消息。 标准的客户端安全最佳实践（例如定期扫描病毒）可以缓解此问题。
网络钓鱼尝试
Teams 中的网络钓鱼攻击成本高昂，令人放心。 这些攻击通过虚假网站链接和看似无害但点击下载危险软件的附件，诱骗用户泄露密码、代码、信用卡号码和其他关键信息等信息。 由于其中许多攻击针对用户，即使是具有大量访问权限的高价值目标，它们也可能会普遍存在。 但是，Teams 管理员和用户都有防钓鱼策略。
如果组织中的用户收到来自外部发件人的钓鱼邮件，租户管理员可以 使用图形 API“RemoveAllAccessForUser”从用户视图中删除此邮件。
Teams 安全框架
Teams 认可安全理念，如零信任和最低权限访问原则。 此部分概述了构成 Microsoft Teams 安全框架的基本元素。
核心元素如下：
- Microsoft Entra ID，它为用户帐户提供单个受信任的后端存储库。 用户配置文件信息通过 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 要求所有服务器证书都应包含一个或多个 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 有助于防止窃听和中间人攻击。 对于中间人攻击，攻击者可在两个网络实体不知情的情况下，通过自己的计算机重新路由这两个网络实体之间的通信。 通过在两个终结点之间协调使用公钥加密系统进行加密，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 使用 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 同时启用联机租户和客户端。 电脑和移动设备上的 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 管理中心或使用 Tenant Remote PowerShell（TRPS）管理他们的服务。 租户管理员使用新式验证对 TRPS 进行身份验证。
在 Internet 边界配置对 Teams 的访问权限
为了使 Teams 正常运行（例如让用户能够加入会议），客户需要配置自己的 Internet 访问权限，例如允许 到 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 ID、Microsoft 365 或Office 365帐户的外部用户参与这些会议。
让外部用户参与 Teams 会议可能很有用，但也会带来一些安全风险。 为了解决这些风险，Teams 使用以下安全措施：
会议前：
决定允许哪些 外部参与者类型 加入会议：
注意
对组织没有外部访问权限的用户和组织将被视为匿名。 如果你已阻止匿名加入，他们将无法加入你的会议。
需要双向启用外部访问，两个组织都需要允许相互外部访问。
注意
有关 Teams 中的来宾和外部访问的详细信息，请参阅 此文。 它介绍了来宾用户或外部用户在登录 Teams 时应该能看到和使用的功能。
确定谁可以直接加入会议，谁需要等待大厅中被组织者、共同组织者或具有演示者会议角色的经过身份验证的用户允许：
确定匿名用户和拨入呼叫者是否可以在组织中的用户、受信任组织中的用户以及具有来宾访问权限的用户加入呼叫之前开始会议。
注意
安排会议仅限于组织中经过身份验证的用户或对组织具有来宾访问权限的用户。
会议期间：
- 分配特定的 参与者会议角色 以确定会议控制权限。 会议参与者分为多个组，每个组都有自己的特权和限制， 此处已概述。
注意
如果你正在录制会议，并且想要查看有关访问内容的权限矩阵，请参阅本文及其矩阵。
在会议运行时修改：
注意
Teams 管理员设置中的更改最多可能需要 24 小时。
相关主题
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈