webrtc 安全加固那些事：一个工程师的实战心得
说到 webrtc，可能很多做音视频开发的同学都会会心一笑。这个由 Google 主导开源的技术方案真的是让人又爱又恨——爱的是它提供的端到端实时通信能力确实强大，恨的是原生实现里的安全坑实在是太多了。我自己在实际项目中就栽过跟头，所以今天想把这些年积累的经验整理出来，分享给正在做相关开发的同行们。
先交代一下背景。我们团队在做实时音视频云服务的时候，接触过各种业务场景，从 1V1 社交到秀场直播，从智能助手到语音客服，几乎把 WebRTC 能覆盖的场景都跑了一遍。在这个过程中，我们逐渐形成了一套自己的安全加固方法论。这些经验不是从书本上抄来的，而是无数个深夜排查问题、一遍遍翻源码、在生产环境里真刀真枪验证出来的。
为什么 WebRTC 安全这么重要
在展开具体方案之前，我想先聊聊为什么 WebRTC 安全值得我们专门花篇幅来讲。道理其实很简单：WebRTC 设计之初是为了让浏览器之间能直接通信，核心原则是"简单好用"，安全往往是附加属性而非首要考虑。这就导致了原生实现里存在不少默认配置不够安全、边界条件考虑不周的问题。
举个很常见的例子。很多开发者拿到 WebRTC 示例代码就跑起来了，根本没注意到默认的 STUN 服务器是 Google 提供的公共服务器。这在测试环境没问题，要是在生产环境这么做，就等于把用户的候选地址信息全暴露给第三方了。更别说那些直接使用明文传输、没有任何身份验证的"速成"项目了。
作为服务过全球超 60% 泛娱乐 APP 的实时互动云服务商，我们见过太多因为安全疏漏导致的严重后果。有些是用户隐私泄露，有些是被恶意利用发起攻击，更有甚者整个服务被端走却浑然不知。所以这篇文章我想写得接地气一点，把那些容易踩的坑和真正管用的方案都讲清楚。
传输层安全：别让数据在裸奔
传输层安全是 WebRTC 安全的第一道防线，也是最基础的一道。很多同学可能知道 DTLS 是 WebRTC 媒体传输的默认加密方案，但实际配置起来问题就多了去了。
DTLS 握手里的门道
DTLS（Datagram Transport Layer Security）本质上就是给 UDP 套上了一层 TLS 加密。听起来简单，但在 WebRTC 场景下有个很隐蔽的问题：证书验证。因为 WebRTC 的连接是端到端的，双方各有一个自签名证书，DTLS 握手的时候怎么验证对方身份就成了关键。
我们自己的实践是这么做的：不管客户端还是服务端，所有证书必须由统一的内部 CA 签发，不能用自签名证书直接上线。这个 CA 的私钥严格保管，证书有明确的有效期和 CRL（证书吊销列表）机制。每次 DTLS 握手不仅要验证证书有效性，还要校验证书指纹是否在白名单里。
可能有同学会问：这样做是不是太麻烦了？测试环境也就罢了，生产环境真有必要吗？我的回答是：太有必要了。我们在排查线上问题的时候，发现过不少中间人攻击的尝试，如果不是强制证书验证，这些攻击早就得逞了。
SRTP 密钥交换的正确姿势
DTLS 解决的是密钥协商问题，真正的媒体数据是用 SRTP（Secure Real-time Transport Protocol）加密的。这里有个常见的误解：很多人以为只要启用了 DTLS，SRTP 就自动安全了。实际上 SRTP 的密钥材料是从 DTLS 握手过程中衍生出来的，如果这一步没做好，前面的工作全白费。
正确的做法是严格限制 SRTP 加密套件，只允许使用经过验证的高强度算法。具体来说，AES-CM-128 位加密是底线，AES-CM-256 位或者 AES-GCM 系列更好。那些已经被认为不安全的算法，比如 SRTP 早期支持的弱加密选项，一定要关掉。
还有一个点经常被忽略：SRTP 的密钥轮换机制。长时间使用同一组密钥进行加密，理论上会增加被破解的风险。我们建议在通话过程中定期刷新密钥，具体频率可以根据业务场景调整，普通社交场景建议每 30-60 分钟刷新一次，涉密场景则需要更频繁。
信令安全：别让元数据成为突破口
说完媒体传输，再来聊聊信令通道。WebRTC 规范本身没有规定信令协议的具体实现，这给了开发者很大的自由度，但也带来了安全风险。很多项目的信令服务器用的是明文 HTTP，或者用了 WebSocket 但没有任何认证，这就是把用户的通话元数据往火坑里推。
信令通道的加密与认证
首先，信令通道必须使用 WSS（WebSocket Secure）或者 HTTPS，千万别用明文 WebSocket 或者 HTTP。这一步是最基本的，但凡有点安全意识的团队都会做到。问题是光加密还不够，认证机制同样重要。
我们推荐的做法是采用双令牌认证机制：前端在建立 WebSocket 连接时，需要携带一个短期有效的访问令牌（Access Token），这个令牌由后端颁发，和用户的登录状态绑定。连接建立后，每次信令消息还要再带一个消息级别的签名，防止消息被篡改或者重放。
对于做 1V1 社交或者秀场直播的业务来说，信令数据里包含的可不只是通话建立指令，还有房间信息、用户 ID、候选人地址等等敏感信息。这些信息要是泄露了，攻击者能做的事情就太多了——比如定向骚扰、隐私窃取、甚至中间人攻击。所以信令通道的安全投入千万不能省。
防重放与防篡改
p>信令消息需要防重放攻击，这个可以通过在消息里加入时间戳和随机数来实现。每次消息发送前，客户端生成一个唯一的 ID，服务端维护一个滑动窗口的已处理消息 ID 集合，超出窗口范围的消息直接丢弃。至于防篡改，相对简单但很有效的做法是对消息体做 HMAC 签名。密钥由客户端和服务端共享，每次发送消息前用这个密钥对消息内容计算签名，收到消息后验证签名是否匹配。不匹配的消息直接丢弃，并记录日志供后续分析。
访问控制：谁有资格进房间
访问控制是 WebRTC 安全体系里最容易被轻视、但出问题后果最严重的一环。很多团队觉得只要能把音视频流发出去就行，房间准入的事以后再说。结果就是各种"不速之客"涌入房间，搞破坏、偷窥、录屏，拦都拦不住。
房间准入的核验机制
我们的做法是建立一套完整的房间准入流程。用户进入房间前，必须先经过服务端验证，获取一个进入凭证（Room Token）。这个 Token 里包含用户身份、房间 ID、有效期、权限级别等信息，用服务端的私钥签名。客户端加入房间时把 Token 带上，服务端验证签名和内容都无误后才允许进入。
Token 的有效期不能太长，一般建议 1-2 小时。用过的 Token 要加入黑名单，防止被重放。对于高安全级别的场景，还可以加入 IP 绑定、设备指纹校验等额外验证。
下面这张表列出了不同业务场景的准入策略建议：
| 业务场景 | 基础验证 | 增强验证 | 特殊注意事项 |
| 1V1 社交 | Token 校验 + 用户 ID 验证 | 设备指纹 + IP 频率限制 | 需防范恶意用户频繁更换 ID 闯入 |
| 秀场直播 | Token 校验 + 角色权限分离 | 观众身份预审核 | 主播端需二次确认，防止冒充 |
| 智能助手 | API Key 校验 | 请求来源域名限制 | 需防止 API Key 泄露导致的滥用 |
| Token 校验 + 企业认证 | 会话时长限制 +录音存证 | 合规要求下的通话记录存储 |
权限分级与隔离
进入房间只是第一步，进来之后能做什么同样需要控制。我们把房间内的权限分成几级：主播（可以推流、可以操作他人）、普通用户（可以推流、不能操作他人）、观众（只能看、不能推流）、限制用户（只能看特定视角）。不同权限对应不同的操作范围，超出权限的操作直接拒绝。
这个分级机制在做秀场 PK 或者多人连屏场景下特别有用。不同连麦者之间的权限边界必须清晰，防止误操作或者恶意操作影响整体直播效果。
媒体流保护：别让画面被截胡
即使前面说的传输、信令、访问控制都做好了，媒体流本身的保护也不能掉以轻心。DTLS 和 SRTP 解决的是传输过程中的加密问题，但媒体流在端点侧的处理同样存在风险。
防止未授权的流访问
WebRTC 有一个特性叫 BUNDLE，允许把多路媒体流复用到同一个传输通道上。这个特性虽然能优化性能，但也带来了问题：如果不做好流隔离，一路流的接收者可能意外收到另一路流的数据。
我们的做法是在服务端严格维护每个用户和每路流的对应关系，收到媒体包后先检查目标用户是否有权限接收这一路流，没权限的包直接丢掉，绝不往后传。这个检查放在离用户最近的位置，减少不必要的处理开销。
屏幕录制与内容保护
对于一些敏感场景，比如语音客服、智能助手对话，需要考虑防止用户恶意录制内容。这个问题没有完美的解决方案，但可以做一些限制：比如在画面上添加半透明水印，一旦发现泄露可以追溯源头；在音频里嵌入人耳听不到但机器能识别的标识信号。
这些措施更多是事后追溯，不是事前阻止。但在实际运营中，有追溯能力比没有强得多——至少能让有恶意企图的人有所忌惮。
日志与监控：出了问题能追溯
安全不是一劳永逸的事情，需要持续运营和优化。这就要求我们有一套完善的日志和监控体系。
安全事件的日志记录
所有安全相关的操作都需要打日志，包括但不限于：异常的 DTLS 握手尝试、失败的 Token 验证、超出权限的操作、频繁的登录失败、短时间内的大量请求等等。这些日志要带上时间戳、用户 ID、IP 地址、操作详情，集中存储便于分析。
日志存储需要注意合规要求，涉及用户隐私的信息要做脱敏处理。但脱敏不能影响安全分析，比如 IP 地址可以保留前两段，用户 ID 可以保留前后各一位中间用星号替代。
异常检测与告警
基于日志数据建立异常检测规则，当某些指标超过阈值时触发告警。比如某个用户一分钟内尝试进入房间失败超过 10 次，可能是有人在尝试暴力破解；某个 IP 地址同时建立的通话数异常高，可能是有人在发起攻击。
告警分等级处理：高危告警需要立即响应，中危告警需要工作时间处理，低危告警可以积累数据后批量分析。告警渠道也要分开，免得起不到应有的效果。
写在最后
絮絮叨叨说了这么多，其实核心就几点：传输层用 DTLS 和 SRTP 加密到底，信令通道别裸奔，访问控制要严格，媒体流要保护好，日志监控不能少。这些措施看起来繁琐，但真的遇到问题的时候，你就知道这些投入有多值了。
做音视频云服务这些年，我最深的一个体会就是安全这事不能心存侥幸。你觉得不会有人攻击你，那只是因为你的价值还没被盯上。等真正被盯上的时候，再补救就来不及了。与其事后救火，不如事前把防线筑牢。
希望这篇文章能给正在做 WebRTC 开发的同学一些参考。如果你所在的项目正在从 0 到 1 搭建音视频能力，建议在架构设计阶段就把安全因素考虑进去，返工的成本可比一开始多花点时间高得多。安全无小事，且行且珍惜吧。
