跳转到内容

安全加固与密钥轮换

生产环境至少满足:

  • 所有用户流量走 HTTPS。
  • PostgreSQL、Redis、management gRPC、metrics 不直接暴露公网。
  • root 密码、JWT secret、OPAQUE setup secret、credential encryption key、cluster secret 都使用 Secret Manager 或 Kubernetes Secret 管理。
  • 禁用默认弱 secret;配置文件和 Helm values 不提交真实 secret。
  • 配置备份和恢复演练,确保 secret 与数据库一起恢复。
  • 开启 metrics 后限制抓取来源或使用鉴权。
Secret丢失影响轮换难度处理
jwt.secret旧 token 失效,用户需要重新登录可计划轮换,低峰发布
security.opaque_server_setup_secretOPAQUE 密码记录可能无法验证不要常规轮换,必须备份
security.credential_encryption_key已加密 Provider 凭据无法解密不要直接替换,先迁移凭据
cluster.secret节点间认证失败多副本需滚动协调
management.auth_tokenCLI/management TCP 鉴权可定期轮换
metrics.auth.bearer_tokenmetrics 抓取鉴权同步监控系统配置
SMTP/OAuth2/Provider 凭据邮件、登录或媒体能力异常按外部系统策略轮换
  1. 备份 PostgreSQL、配置文件和全部生产 secret。
  2. 确认轮换目标和影响范围:登录、Provider 凭据、集群、management 或 metrics。
  3. 在测试环境使用生产同结构数据验证。
  4. 准备回滚方案:旧 secret、旧配置、旧镜像或数据库备份。
  5. 通知用户可能需要重新登录或重新绑定 Provider。
  6. 低峰期执行,并观察错误率、登录失败、Provider 解密错误和 WebSocket 重连。
  1. 生成新 secret。
  2. 更新 secret 存储。
  3. 重启所有 SyncTV 副本。
  4. 预期旧 access/refresh token 失效,用户重新登录。
  5. 观察 401、登录成功率和 WebSocket 重连。

如果必须更换 security.credential_encryption_key,不要直接替换后启动。安全流程应该是:

  1. 备份数据库和旧 key。
  2. 在维护模式下停止会写 Provider 凭据的操作。
  3. 使用旧 key 解密现有 Provider 凭据。
  4. 使用新 key 重新加密并写回。
  5. 更新配置为新 key。
  6. 启动服务,验证所有 Provider 登录、浏览和播放。

如果当前没有自动化迁移工具,保守做法是保留旧 key,不做轮换;或者删除并重新创建受影响的 Provider 凭据。

OPAQUE setup secret 是密码认证协议的长期服务端 secret。除非你已经设计好账号密码迁移或强制用户重置密码流程,否则不要轮换。

如果泄露:

  • 立即评估泄露范围。
  • 强制所有用户重置密码或重新注册 OPAQUE 密码记录。
  • 同时轮换 JWT secret,清理会话。
  • 保留审计记录和事件时间线。
项目动作
TLS公网只暴露 HTTPS/WSS
CORS只允许真实前端 origin,不带 path
Trusted proxy只信任真实反向代理地址
Rate limit登录、验证码、WebSocket、API 都配置合理限制
WebAuthnrp_origin 与真实 HTTPS origin 一致
OAuth2redirect URL 精确匹配,state 存储依赖 Redis
Provider凭据加密,禁止把 token 写入 sourceConfig
LogsJSON 日志,不输出 secret、Cookie、JWT
Metrics不公网暴露,启用 bearer 或平台鉴权
Backups数据库和 secret 一起备份、一起演练恢复