政务云多租户日志审计：隔离、留存与等保 2.0 合规

多租户隔离的边界

政务云最常见的形态是：平台方建一套可观测系统，几十家单位各自接入自己的应用日志。隔离做不好，A 单位的运维能搜到 B 单位的日志，在政务场景下这不是 bug，而是一起有实际后果的事故。

隔离要从三层一起做：数据层按租户（单位）分索引或分库，写入时打上 tenant_id；权限层按租户做资源级授权，检索、告警、大盘都只能看自己租户；展示层把租户上下文注入到每次查询，避免"忘记带 where 条件"的越权。三层缺一层，隔离就是纸糊的，另外两层在演示里再好看也没用。

审计日志要留什么、留多久

审计日志和普通业务日志是两回事：它记录的是"谁、在什么时间、对系统做了什么"。登录、检索条件、导出、配置变更、告警处置这几类必须全量记录，且不允许任何角色删除或修改——连管理员也不行，因为它的价值正在于不可篡改。

留存周期按《网络安全法》和等保要求，日志至少留存 6 个月，涉及关键信息基础设施的建议 12 个月以上。冷数据用压缩归档，读多写少，成本可控。审计日志要和业务日志分开存：既避免业务日志被清理时把审计记录一起带走，也避免改业务日志的留存策略时悄悄缩短了合规窗口。

举个例子：等保测评时，测评机构最常问的是"调出某账号最近三个月的全部登录与检索记录"。如果审计日志和业务日志混在一起、或者只留了 30 天，这一条就直接过不了。所以从设计第一天就把审计日志独立出来、按 12 个月滚动留存，是最省事的做法。

等保 2.0 的几个硬性要求

等保 2.0 对日志审计有明确条文，落地时盯住这几条：

• 审计记录要包含事件时间、主体（用户/进程）、客体（资源）、结果，且时间同步到统一 NTP；
• 对审计进程与记录要有保护，防止非授权删除、修改或覆盖；
• 关键操作（登录失败、越权尝试、配置变更）要能触发告警并通知安全管理员；
• 审计日志要定期备份，防止主机故障导致不可用。

一套可落地的配置

给一个最小可用的落地方案：

1. 每个单位建独立租户，写入端强制带 tenant_id，缺失即拒绝入库；
2. 审计事件单独一个 topic，消费者写入不可变的审计索引，关闭所有删除接口；
3. 告警规则覆盖：连续登录失败、非工作时段导出、跨租户查询尝试；
4. 每日增量备份审计索引到对象存储，留存策略按 12 个月滚动。

再补一条：给审计索引配热温冷三层，近 30 天热数据可秒级查，超过 90 天归档到冷层，兼顾查询体验和存储成本。上线前做一次越权演练：用 A 单位账号去检索 B 单位数据，结果必须是空且留下审计记录。这一步过了，才算真正合规——不是配置看起来合规，而是可验证地合规。