解读

在国内金融、政务、医疗等强监管行业，合规审计的核心是“日志不可篡改、不可缺位、可追溯”。Cloud SQL 的“日志排除过滤器”（Log Exclusion Filter）允许用户通过 sink 条件主动丢弃某些日志条目，从而节省存储与网络费用。然而，一旦排除规则配置不当，就可能把敏感操作记录（如 root 用户删表、权限变更、数据导出）也一并丢弃，导致审计轨迹断裂。面试官希望候选人能同时看到技术灵活性与合规刚性之间的冲突，并给出可落地的权衡方案。

知识点

1. Cloud SQL 审计日志层级：ADMIN_READ、DATA_WRITE、DATA_READ 三类，对应不同监管粒度。
2. 排除过滤器作用域：在组织、文件夹、项目或 sink 级生效，支持布尔条件与正则，优先级高于包含过滤器。
3. 国内合规基线：
   – 等保 2.0 要求保留 6 个月以上原始日志；
   – 人行《金融数据安全分级指南》 要求“高敏感”级别操作日志保存不少于 5 年；
   – 个人信息保护法 强调“可审计、可溯源、可举证”。
4. 不可变存储：Cloud Storage 桶加“Bucket Lock”或“Retention Policy”后，对象在锁定期内无法删除，可对抗恶意或误删。
5. 双层日志架构：实时热日志（BigQuery）+ 冷备不可变日志（Cloud Storage），既满足审计长周期，又降低费用。
6. IAM 最小权限：把 logs.exclusion.create 权限单独拆出角色，由合规管理员与安全团队双人审批，避免研发随意加规则。
7. Terraform 代码评审：把排除规则写成 IaC，强制经过SonarQube+Checkov静态扫描，防止正则误杀关键 eventName。
8. 监控告警：利用 Log-based Metrics 对“被排除的日志条数”做实时计数，一旦突增立即触发 PagerDuty，实现“负日志”监控。

答案

日志排除过滤器通过 sink 条件把命中规则的日志直接丢弃，在合规审计场景下最致命的风险是“审计轨迹缺位”。例如，某券商把包含“cloudsql.instances.export”关键词的日志全部排除以节省流量，结果导致央行现场检查时无法举证“核心客户数据是否在夜间被导出”，被认定为重大合规缺陷，面临 800 万元罚款与业务暂停。
因此，在国内落地时应遵循“先合规、后降本”原则：

1. 用白名单方式仅排除低敏感高频日志，如健康检查心跳；
2. 对 ADMIN_WRITE、DATA_WRITE 类日志禁止设置任何排除规则，并通过 IAM 条件策略强制约束；
3. 把原始日志双写至带 Bucket Lock 的 Cloud Storage 与 BigQuery，前者满足长周期不可篡改，后者支持秒级审计查询；
4. 在组织策略层面启用**“日志不可删除”**布尔约束，任何排除规则的变更必须走 IT 服务管理流程，留痕供内审；
5. 定期由第三方审计机构做**“负日志”穿透测试**，随机抽取 10 个操作事件，反向验证日志是否真实存在，确保过滤器没有误杀。
   通过以上五步法，即可在节省 30% 日志存储成本的同时，满足等保、人行、证监等多重合规要求，实现技术可控与监管可信的平衡。

拓展思考

如果未来监管要求“日志必须在境内完成实时备份且不可被云服务商内部员工读取”，可进一步：

1. 启用Cloud SQL 的 CMEK（客户管理的加密密钥），把日志加密密钥托管在阿里云 KMS 或国密 HSM，实现“云服务商无法解密”；
2. 使用Private Service Connect 把日志实时转发至自建Fluent Bit 集群，再落盘到金融云专属 Region 的不可变存储，物理隔离公有云运维人员；
3. 通过Confidential VM 运行日志审计平台，把内存级攻击面降到最低，满足央行“关键数据不可出域、不可被内部人员接触”的最新窗口指导。