阿里云数据库审计开启后记录哪些 SQL，费用怎么算

数据库出问题的时候，很多团队最先卡住的是说不清楚：到底谁，什么时候，对哪张表做了什么。数据被误删、账号被人盗用、线上慢查询突然变多，如果手上没有完整的操作记录，排查基本只能靠猜。阿里云数据库审计就是为这类场景准备的，它把数据库的访问行为记下来，还能对异常操作做识别和告警。

数据库审计记什么，和普通日志有什么不同

数据库自带的日志，比如慢查询日志和二进制日志，主要服务于性能调优和数据恢复，拿来回答安全问题往往不够用。审计关心的是几件具体的事：谁执行的，从哪个地址连进来，什么时间，执行了什么语句，影响了多少行。缺了这些信息，做合规检查时很难拿出证据，出了安全事件也很难还原现场。

阿里云数据库审计以旁路方式采集SQL，业务代码不用改，数据库内核也不会被侵入。RDS、PolarDB 这类已经上云的实例可以直接开通，不用再自己搭一套审计系统，部署和运维的活都省了。

从使用角度看，审计主要做三件事：记录、分析、响应。

SQL 明细：会话信息、客户端 IP、执行时间、影响行数和 SQL 文本都会保存，可以按时间、用户、库表检索。排查时最常见的做法是先锁定库和表，再缩小到时间段。
风险识别与告警：比较典型的是没有 WHERE 条件的删除和更新、批量导出敏感字段、非业务时段的大量查询。命中后可以发通知，具体规则要结合自己的业务去调。
报表与合规支持：按周期生成访问统计和审计报告，安全同事和审计人员复核时可以直接用，不用再手工拼表。

留存时长要和合规要求一起考虑。保留越久，存储和检索的成本越高，检索速度也可能受影响。别一开始就想着全量永久保存，先按监管要求定周期，再根据实际查询需要调整。

费用没有一个固定数字，主要取决于审计覆盖的范围和实际用量，通常涉及计费方式、覆盖的实例规格、日志留存时长和存储用量。具体单价和计费规则会调整，直接以阿里云官网价格页和控制台的计费说明为准，别拿别人的报价套到自己身上。

估算时可以先从两件事入手：一是哪些实例需要审计，核心库和含敏感数据的库优先；二是每天大概会产生多少审计数据，要留存多久。这两个数字定下来，成本大致就有了轮廓。不要只看开通那一刻的价格，留存拉长后，存储费用会慢慢累积。

某电商团队的运营同学在后台跑数据清理脚本，WHERE 条件写错了，一段时间内的部分订单被删。问题刚暴露时，业务方第一反应是系统有 bug，开发则说代码没动过。两边各说各的，谁也拿不出证据。

后来团队在阿里云数据库审计里按库名、表名和时间段检索，很快找到那条 DELETE 语句的执行时间、来源 IP 和操作账号。账号是一个共享的运维账号，这本身就是个隐患。有了准确的时间窗口，团队结合备份做了精准回滚，没有动全库，避免了覆盖其他正常数据。

复盘时团队做了三件事：给高危语句配置风险告警，取消共享账号，改为按人分配权限，同时把数据变更纳入审批流程。审计找出的是操作的人，留下来的是改进后的流程。

审计范围一扩大，日志量和告警数量跟着涨。建议先从核心业务库和敏感数据库开始，把必须记录的操作列出来，再决定哪些告警要立即处理。目标定清楚，规则配置才有依据。

如果每天几百条告警，时间一长大家就会习惯性忽略。可以按风险等级分层：高危的直接推到值班群或工单系统，中低危的定期汇总复核。被确认为误报的规则要及时调整，否则噪声只会越来越大。

审计日志里常带着手机号、订单明细、查询条件这类敏感信息。能查看审计数据的人要严格限制，并定期检查谁在看这些记录。否则审计系统本身就可能成为新的泄露口子。

不少行业的监管要求和等级保护都提到了数据库操作留痕和日志留存。阿里云数据库审计能覆盖其中操作记录、访问追踪和日志保存的部分，但开通服务不等于合规就完成了。企业还需要有对应的管理制度，写清楚审计日志多久复核一次、由谁负责、异常怎么处置。具体条款是否满足，建议和合规或法务同事一起对照确认。

数据库审计让每一次数据操作都有据可查。先从关键库和高危规则做起，流程跟上，审计才真正用得上。