VMax 消息服务端安全事件响应

1. 原则与边界

本 Runbook 面向消息实例、PostgreSQL、Push Gateway、APNs 凭据、对象存储和可观测性系统。事件响应不得通过收集消息明文、私钥或完整身份图谱扩大事件影响。

• 来源 MUST：生产发布前完成事故响应 Runbook、密钥轮换和备份恢复演练。
• 来源 MUST：服务端与 Gateway 不具备消息明文或客户端私钥，因此响应人员不得要求用户提供这些秘密作为常规诊断材料。
• 已验证事实：当前没有运行系统或值班链路，本文件是设计草案，不是已演练证据。

2. 分级建议

级别	示例	目标动作
P0	实例签名私钥/APNs 凭据泄漏；明文或私钥进入服务端；大规模消息丢失	立即隔离、停止相关写入/外发、启动总控与法律/隐私评估
P1	数据库未授权访问；幂等失效导致重复；ACK/TTL 大规模失效；跨实例数据泄漏	15 分钟内响应，控制扩散并保全最小证据
P2	局部积压、Gateway 故障、备份失败、依赖漏洞无已知利用	当班处置，保持拉取路径并安排修复
P3	低风险配置漂移、无影响扫描告警	计划修复与复盘

具体响应时限与值班角色为待总控决策。

3. 通用流程

1. 确认：记录 UTC 时间、事件类型、受影响版本/实例和最小 request ID；不复制 payload。
2. 遏制：按组件摘流、禁用凭据或冻结变更，优先保持已持久化密文的拉取与 ACK 能力。
3. 保全证据：只保存必要的脱敏日志、配置版本、镜像 digest、schema 版本和指标快照；访问受控并设置短保留。
4. 根因与范围：区分客户端、网络、API、Worker、数据库、Gateway/APNs 和可观测性泄漏。
5. 修复恢复：走已验证备份、迁移和密钥轮换流程；先隔离验证再切流。
6. 通知：依据确认事实说明影响、时间范围和用户动作，不使用未验证安全结论。
7. 复盘：列出时间线、检测缺口、数据范围、恢复证据和责任项；到期销毁临时证据副本。

4. 场景处置

4.1 PostgreSQL 未授权访问

• 隔离数据库与受影响凭据，保留只读取证快照；禁止把 dump 下载到个人设备。
• 假设攻击者可见公开身份材料、设备路由、时间/大小元数据和仍在 TTL 内的密文；不要因为 E2EE 就宣称“无影响”。
• 检查是否存在明文、私钥、token 或异常审计字段；若存在，升级为 P0。
• 轮换数据库凭据、游标签名/加密密钥和相关服务 secret；实例签名私钥是否轮换取决于暴露证据。
• 从可信版本恢复/修复，核对信封、ACK、过期、幂等和 outbox。

4.2 实例签名私钥泄漏

• 立即停止使用旧私钥签发配置，保护当前公钥指纹和时间线证据。
• 客户端已固定旧指纹，不能静默替换；需要受验证的信任迁移和明确用户确认。
• 新旧签名如何交叉认证与吊销涉及身份/配置协议，待总控决策；在方案冻结前不得自行设计。

4.3 APNs/Gateway 凭据泄漏

• 撤销并轮换对应凭据，停止受损 Gateway，保留消息 HTTPS 拉取路径。
• 禁用或重新注册相关 wake route；不要求消息实例暴露 APNs token 或消息内容。
• 普通私有实例依赖官方 Gateway 时向管理员说明后台通知可能延迟，但消息仍应可拉取。
• 完全主权部署各自处理独立 Bundle ID 凭据，不能使用官方私钥应急替代。

4.4 消息重复或丢失

• 先确定“客户端显示重复”“服务端重复行”“重复 Push”还是“ACK 后重投”；不要把至少一次传输误判为数据库重复。
• 核对 Idempotency-Key、message_id 唯一约束、事务提交、ACK 与恢复时间点。
• 暂停破坏性清理，保持脱敏计数证据；修复后用重试、超时、并发和恢复回放验证。
• 不通过读取或解密用户消息来确认重复。

4.5 TTL/配额清理失效

• 阻止继续积压，必要时降低新入队速率；不得无差别删除未过期信封。
• 以分批、限速、可恢复任务清理已过期或已 ACK 数据，观察锁与磁盘。
• 评估备份、对象存储版本和日志副本是否仍延长保留；披露实际而非配置值。

4.6 敏感数据进入日志或监控

• 停止采集与下游转发，隔离索引、缓存、告警、导出和备份副本。
• 识别数据类型、时间范围、访问者和外部处理商；按隐私/法律流程判断通知。
• 修复默认拒绝脱敏，使用 canary 重跑正常、错误、panic 与导出路径。
• 删除必须覆盖副本并保留删除证明；不在工单中粘贴泄漏值。

4.7 备份不可恢复

• 宣告恢复风险，不继续覆盖最近可用副本。
• 在隔离环境尝试上一恢复点并记录实际 RPO/RTO；不得把备份任务成功等同于恢复成功。
• 若影响未送达密文，说明可能的数据损失窗口；不能从服务端重建明文。

4.8 Redis 队列丢失或被篡改

• 隔离 Redis，保留最小配置和指标证据；Redis 数据本身不作为权威业务证据。
• 暂停 dispatcher/Worker，检查 PostgreSQL outbox_events 与业务状态，轮换 Redis 凭据和 namespace。
• 在干净 Redis 上从未完成 outbox 重建任务；handler 必须按稳定 event_id 幂等，接受重复但不能重复产生业务副作用。
• 比对过期、ACK 清理、Push outbox 和 dead-letter 计数，确认没有永久漏执行。
• 若 Redis job payload 含有密文、token 或用户可读数据，按敏感数据泄漏升级事件；设计要求本不应包含这些字段。

4.9 S3 对象存储事件（P1）

MVP 不启用对象存储，因此 S3 故障不应影响文本消息。P1 启用后，凭据泄漏、bucket 公开、对象缺失或生命周期失效需独立处置；对象虽为密文，仍按敏感数据和元数据暴露评估，不能宣称无影响。

5. 通知内容最小化

通知可包含事件类别、受影响实例/版本、时间范围、已确认的数据类别、已完成控制、用户需要采取的动作和下次更新时间。禁止包含具体用户地址、IP、token、密文、私钥或未经确认的攻击归因。

任何“消息内容未泄漏”结论必须基于确认服务端确实从未接收明文、实现与日志扫描结果、以及受影响范围；E2EE 设计本身不是证据。

6. 演练

• 每季度至少演练数据库凭据泄漏、消息积压/重复和备份恢复。
• 每次发布前演练迁移中断、磁盘满、Worker 崩溃和 APNs 不可用。
• 每年或凭据体系变更时演练实例签名密钥和 APNs 凭据轮换。
• 演练不得使用真实消息、真实 token 或生产私钥；使用可追踪 canary。

7. 待总控决策

1. 值班角色、P0/P1 响应时限与外部通知审批。
2. 实例签名密钥泄漏后的信任迁移协议；需与身份地址/配置签名决策联动。
3. 事件证据保留期和法律保全例外；需平衡隐私与审计。
4. 完全主权部署的责任划分和官方支持边界。
5. 漏洞披露与开源安全公告流程；开源许可与发布策略不得由本文冻结。

8. 完成判据

只有当遏制措施生效、受影响范围有证据、恢复校验通过、敏感副本已处理、用户/监管通知完成（如适用）、长期修复有负责人和期限后，事件才能关闭。未演练的 Runbook 只能标为草案。