云联信息支招：数据库审计，出了事才想起开日志
数据被批量导出，客户投诉到公司，查了一周查不出是谁做的。数据库没有开审计日志，只能看到连接记录，看不到执行了什么语句。这类事故，事后补救的成本远高于事前开启。
审计日志要记什么
谁（账号、来源 IP）、什么时候、对哪个库表、执行了什么语句、影响多少行、是否成功。六项齐全，才能还原操作。
慢日志和审计日志不是一回事
慢日志记性能问题，审计日志记行为。只开慢日志，查不到谁删了数据。两者都要开，用途不同。
高危操作单独告警
删除、更新不带条件、批量导出、权限变更，这四类操作实时告警。等日志事后查，损失已经发生。
日志保留期限
等保要求不少于六个月，涉及资金和客户信息的建议一年。日志存本地容易被清理，最好转存到独立的日志服务。
账号要能对应到人
全公司共用一个数据库账号，日志里全是同一个名字，等于没审计。按人分配账号，或者通过堡垒机统一代理并记录。
只读账号的边界
报表、数据分析用只读账号，限制可访问的库表。给分析人员开写权限，是数据泄露的常见原因。
定期抽查
每月抽十条高危操作日志，核实是否有审批、是否符合流程。抽查本身就是威慑，比制度文件有效。
审计与合规
等保测评、行业监管都会查审计日志。临时补是补不出来的，日志是时间的产物。
成本与性能的平衡
全量审计对性能有影响，可以只审计高危语句和敏感表。按风险分级，比全开或全不开都合理。
审计日志的存储
日志量大的库，审计日志本身会占不少空间。转存到独立的日志服务，既不占数据库空间，也方便检索。
审计结果的闭环
发现异常操作要跟进处理，不能只记不看。每月出一次高危操作清单，逐条确认是否有审批。
审计的性能影响
全量审计对高并发库有性能开销。先只审计写操作和敏感表，观察影响再扩大范围。
日志的检索能力
日志量大时，靠文本搜索找一条记录很慢。用支持结构化查询的日志服务，效率高很多。
权限变更的审计
授权和回收权限的操作要重点审计。很多数据泄露源于一次不该给的授权，而不是外部攻击。
数据库审计的价值在于可追溯。记全六项、高危操作告警、账号对应到人、日志独立存储，这四点做到，出事时才有据可查。审计不是合规负担，是数据安全的基础设施。成本可以通过分级审计控制。云联信息【资深云服务专家微信：cloud7591】可以协助设计审计范围和告警规则。