密钥保密要求
接入 TiRTC 时，你需要重点保护两个值：SecretKeyId 和 device_secret_key。
它们都不能下发到客户端，也不要出现在日志、截图、工单或聊天记录里。区别在于：SecretKeyId 是应用级密钥，通常放在服务端；device_secret_key 是设备级密钥，通常还会写进设备端。后者一旦泄露，处理起来更麻烦，不能简单地在服务端换一个新值就结束。
放在哪里
| 密钥 | 是什么 | 可以出现在哪里 | 不应出现在哪里 |
|---|---|---|---|
SecretKeyId | 应用级密钥，用于服务端签名和鉴权 | 你的业务服务端 | 客户端源码、客户端安装包、前端页面脚本、日志、截图、工单 |
device_secret_key | 设备级密钥，和 device_id 一起证明设备身份 | 设备端受控存储位置；服务端必要的签名或校验流程 | 客户端、普通配置文件、日志、群聊、邮件、截图、工单 |
不要这样做
这些做法都容易把密钥泄露出去：
- 把
SecretKeyId写进客户端代码或示例工程 - 把
device_secret_key当成普通字符串打印到日志 - 在群聊、邮件、工单、截图里直接发送完整密钥
- 把完整的
device_id+device_secret_key组合字符串（某些 API、CLI 或配置项里写作license）当成一个可以随手分享的整体字符串 - 为了排查方便，把密钥写入本地配置文件并提交到仓库
有些 API、CLI 或配置项会把 device_id + device_secret_key 的组合写作 license。不要被这个名字误导。只要里面包含 device_secret_key，就按设备级密钥处理。
推荐做法
日志里只放定位信息
排查设备问题时，日志里通常只需要这些信息：
不要打印：
SecretKeyIddevice_secret_key- 完整的
device_id+device_secret_key组合字符串 - 可直接复用的完整
token
发给别人前先脱敏
如果排查时必须展示相关字段，只展示足够定位问题的最小信息：
- 只展示
device_id，不展示device_secret_key - 只说明“签名失败”或“凭证不匹配”，不要把原始密钥贴出来
不要把所有值都塞给所有端
每一端只拿自己真正需要的值：
- 客户端主要接触
remote_id和token - 设备端只在初始化或上线等必要场景接触
device_secret_key - 服务端只在签名、鉴权或校验等必要流程接触
SecretKeyId和device_secret_key
如果已经泄露了怎么办
先不要继续转发相关内容，然后确认泄露范围：代码仓库、日志、聊天记录、截图、工单、示例工程和排查脚本。
接下来要看泄露的是哪个值。
SecretKeyId 泄露
SecretKeyId 通常只保存在服务端。泄露后，应停止继续使用已经泄露的值，并按你的平台配置或交付流程申请、配置新的应用级密钥；同时清理已经泄露出去的副本。
device_secret_key 泄露
device_secret_key 绑定的是具体设备身份，通常已经写入设备端。对已经出厂、部署或交付的设备来说，它很难像服务端密钥一样直接替换。
处理时先确认受影响的 device_id 范围，再联系 TiRTC 平台侧同步更换方案。如果确实需要更换，通常要通过类似 OTA 的方式把新 device_secret_key 下发到设备端，同时在平台侧同步更新对应设备的密钥。
设备端和平台侧没有同步完成前，设备上线、Token 签发或连接校验都可能不正常。