安全
网关运维中真正见功力的部分，往往在演示顺利时看不见，在事故发生时起决定作用。
密钥保管
| 秘密 | 存放位置 | 绝不允许出现的位置 |
|---|---|---|
| 服务商密钥 (sk-…) | 宿主机上权限 0600 的 env 文件，或密钥管理服务；仅网关进程用户可读 | 日志、报错正文、客户端响应、git、容器镜像、明文备份 |
| 虚拟密钥 (vk-…) | 网关数据库中散列存储 | 创建之后的任何完整展示——界面只显示一次，日志只记前缀 |
| 管理员凭证 | 密码管理器，并开启 TOTP | 群聊消息、仓库里的 .env 文件 |
最小权限
- 容器以专用非 root UID 运行，根文件系统只读，临时文件走 tmpfs。
- 管理面只绑定 localhost，访问必须经 SSH 隧道或 VPN。公网接口只承载推理流量。
- 数据库账号在运行期不持有 DDL 权限，迁移作为独立步骤单独执行。
- 每个客户团队使用独立的虚拟密钥，各自带模型白名单与预算上限——吊销任何一个客户，都不会波及其他客户。
日志脱敏
网关处在请求链路的正中间，它的日志天然就是高价值目标。部署时默认做以下脱敏处理：
Authorization头 →vk-****后4位- 提示词与补全正文 → 默认只记录 token 数；仅当客户为排障显式开启内容日志时才记录，且设定自动过期。
- 上游报错正文 → 服务商密钥在错误信息到达客户端或日志之前即被剥离。
演示中的请求日志展示的正是这套形态：满足运维需要，但没有窃取价值。
事故处置（演练过的流程，不是纸面预案）
| 事故 | 处置 |
|---|---|
| 虚拟密钥泄露 | 立即吊销（请求直接失败关闭），复查其活跃窗口内的审计日志，按原有策略补发新钥。影响范围：仅这把密钥的配额。 |
| 疑似服务商密钥泄露 | 在服务商侧轮换，更新密钥库，重启网关（重试代理可以吃掉这几秒钟的中断），最后用金丝雀请求确认恢复。 |
| 疑似主机沦陷 | 第一时间在服务商侧吊销服务商密钥——那才是真正值钱的东西。之后用干净镜像加加密备份重建，绝不从可疑主机上恢复任何可执行文件。 |
| 数据丢失 | 恢复前一夜的加密备份；备份点之后的用量记录确认丢失就如实说明，账务以服务商控制台为准进行对账。 |