凌晨两点，生产系统里的一张核心业务表突然出现结构变化。数据库本身仍然在线，应用也没有立即报错，但第二天业务团队发现部分报表结果与前一天不一致。到了这种时候，安全团队真正想知道的并不是一句笼统的「系统发生过修改」，而是需要迅速回答几个非常具体的问题，哪个数据库账号执行了操作，操作发生在什么时间，从哪个客户端发起，执行了哪条语句，操作成功还是失败，权限是谁授予的，在操作之前是否还有异常登录行为。这正是 SAP HANA Cloud 审计体系存在的价值。很多人谈数据库安全时，注意力容易集中在账号、密码、角色、权限、TLS、IP Allowlist 和数据加密这些能力上。它们解决的是「谁可以进入系统」以及「进入系统以后可以做什么」的问题。Audit Logging 关注的是另一条安全链路，它负责留下证据，让我们的安全团队能够回答「谁做过什么」「什么时候做的」「操作是否成功」「哪些安全配置曾经发生变化」。SAP 对 Auditing 的定位也很明确。审计本身并不会直接提高数据库的防御能力，但设计合理的审计体系能够发现权限配置过宽、识别入侵尝试、追踪安全配置变化、调查敏感数据访问行为，并帮助企业满足治理和合规要求。SAP HANA Cloud 当前的安全文档将用户认证、权限变化、数据库对象创建和删除、系统配置修改以及敏感信息访问都列为典型审计对象。理解 SAP HANA Cloud 的 Audit Logging 时，有一个概念必须分得很清楚。Auditing 处于启用状态，并不等于所有数据库操作都会自动进入我们的业务审计日志。在 SAP HANA Cloud 的 SAP HANA Database 实例中，Auditing 始终处于启用状态，不需要像传统本地部署环境那样再把整个审计子系统打