能碰数据库的人不多，但每一个都得盯：数据库审计怎么做才不流于形式
一家做工业设备的公司，技术部有个惯例：数据库管理员手上一直挂着生产库的超级账号，工作六七年，从没人质疑过。后来他跳槽去了竞争对手，走之前把近五年的客户项目库、工艺参数全部导了一遍。企业事后去查，发现数据库日志只开了最低级别，谁能查到什么、查了多少条，一概说不清。想追责，连证据都凑不齐。
数据库是企业核心数据最后待的地方，能直接连上它的人其实不多——运维、开发、BI 分析师，加起来往往不超过十个人。但恰恰是这少数人，手里握着全公司的家底。大多数企业在这件事上的投入，跟风险完全不成比例。
数据库安全的三个常见错觉
错觉一：网络隔离了就安全。数据库放在内网、只允许白名单访问，这确实挡住了外面的人。但真正的风险来自里面——能连上数据库的账号，本身就是最高价值目标。一个钓鱼邮件钓走运维的凭证，隔离就形同虚设。
错觉二：日志开了就等于审计做了。很多企业数据库日志处于默认状态：要么根本没开，要么开了但从没人看。几百万行日志躺在那里，出事后想查某张敏感表被谁查过，要翻三天。没被使用过的日志，等于没有。
错觉三：共享账号省事。"admin 大家共用，出问题再说"——出了问题就是说不清。账号无法对应到人，审计就失去了全部意义，追责更是无从谈起。
把审计做实的四步
第一步：账号到人。所有数据库账号实名化，杜绝共享账号。高权限账号按需申请、定期回收，离职当天必须回收，这条要写进离职流程跟交接表绑在一起。
第二步：采集完整的操作记录。谁、什么时候、从哪台机器、用什么账号、执行了什么语句、动了哪张表、影响多少行——这些要素要完整留存。尤其要盯住批量导出：一条 SELECT 拉走几十万行的操作，正常业务里极少出现，出现就该有告警。
第三步：给危险行为画红线。不是所有操作都要人工看，而是把高危行为定义出来：非工作时间的批量查询、对敏感表的全文导出、DELETE/UPDATE 影响行数异常、新增的超级管理员账号。这些一旦触发就实时告警，而不是等季度复盘。
第四步：最小权限。开发查生产库，给只读账号就够了；BI 取数，只开放它需要的几张视图。很多人手里拿着大炮，是因为从没人收过权限。
审计不是抓内鬼，是让规矩立起来
很多企业担心审计搞得像监控员工，人心惶惶。实际经验恰恰相反：把规则摆在明面上——哪些表属于敏感数据、什么行为会告警、告警后怎么处理——员工知道了边界在哪里，反而更踏实。审计的威慑力在于"留痕"本身，而不是事后翻旧账。
上邦在给制造业和研发型企业做数据安全方案时，习惯把数据库审计和终端文档管控放在一起看：数据出系统走的是应用和终端，出企业走的是外发和传输，两头都有记录、都能告警，数据的完整行踪才闭环。能碰数据库的人不多，但每一个都值得盯着——不是为了不信任谁，而是为了让想伸的手先掂量掂量。