上周跟一个在银行做运维的老朋友吃饭，他愁眉苦脸地跟我说，他们数据库最近差点出事，原因是外包运维人员误操作，差点把生产库给删了。这种事我听得太多了，几乎每周都能从不同朋友那里听到类似的故事——数据库被勒索病毒攻击、运维人员权限过大、备份恢复流程形同虚设。说白了，数据库运维安全这件事，很多人都是不出事不当回事，一旦出事可能就是灭顶之灾。
先说第一个策略：权限管控必须做到最小化。很多人觉得给运维人员开个root权限方便，干起活来效率高。但这种想法很危险。真实案例是，某电商平台的一个运维小哥，为了图省事，直接在root用户下执行了一条rm命令，结果把整个数据库目录给删了。恢复数据花了三天，直接损失上千万。正确做法是，每个运维人员只给最小必要权限，操作生产库必须走审批流程，所有高危命令要单独授权。比如在MySQL里，可以建一个只读账号给日常巡检用，需要写操作时再单独申请。这样做的好处是，就算有人误操作，影响范围也是可控的。
第二个策略是审计日志必须留全留细。很多公司觉得审计日志太占空间，于是设置自动删除，比如只保留7天。但这恰恰是运维安全的大忌。去年有个互联网金融平台被黑，黑客在里面待了整整两个月才被发现。为什么？因为他们审计日志只保留30天，黑客进来的第一周日志已经被覆盖了。正确的审计策略是：所有DDL和DML操作必须记录，包括谁操作的、什么时间、从哪个IP、执行了什么SQL。而且日志要异地备份，防止被黑客删除。现在很多数据库都支持内置审计功能，像MySQL的审计插件、Oracle的审计功能，开起来就行，别嫌麻烦。
第三个策略是备份恢复必须定期演练。说出来你可能不信，我接触过超过60%的公司，他们的备份恢复流程从来没有真正跑通过。有个做SaaS的朋友，他们数据库挂了之后，想从备份恢复，结果发现备份文件是坏的，根本没用。更惨的是，他们备份脚本写错了，实际只备份了表结构，数据根本没备份。定期演练不是走个过场，而是要真正模拟灾难场景。比如每个月做一次全量恢复演练，验证备份文件的完整性和恢复速度。我建议把恢复演练纳入运维考核指标，恢复超时或者失败直接扣绩效。只有这样，才能保证真出事时恢复流程能跑起来。
第四个策略是数据库必须做好基线加固。很多人装完数据库就默认配置上线，觉得默认配置已经很安全了。但事实是，默认配置往往存在大量安全隐患。比如默认的管理员账号、默认的端口、默认的密码策略。去年某云厂商被攻击，就是因为他们数据库装了默认的弱口令。基线加固要做的包括：禁用默认账号、修改默认端口、启用密码复杂度检查、限制连接IP范围、关闭不必要的存储过程。比如MySQL的root账号，建议改个复杂名字，或者直接禁用手动登录，改用临时密钥认证。这些操作看起来繁琐，但每一条都能堵住一个潜在的攻击入口。
第五个策略是运维操作必须实现全流程可追溯。很多公司运维人员操作数据库，还是靠手动执行SQL，出了事根本查不到是谁干的。我曾经遇到过一个案例，某公司核心表数据被恶意修改，但因为所有人都有root权限，谁也说不清是谁动的手。正确做法是：所有运维操作必须通过工单系统申请，执行时通过堡垒机操作，所有SQL语句自动记录。比如用Yearning这样的SQL审核平台，所有上线操作都要经过审批和审核。同时，敏感操作要启用双人复核机制，一个人操作，另一个人确认。虽然流程变长了，但安全系数提高了不止一个量级。
说一个很多人容易忽略的点：数据库密码管理。我发现很多公司还在用密码本，或者把密码写在Excel里，存在共享文件夹里。这种做法风险太大。建议用专门的密码管理工具，比如Hashicorp Vault或者CyberArk，自动轮换密码，每次登录拿临时凭证。同时，所有密码不能明文存储，必须加密。数据库连接串里更不要写明文密码，用配置中心来管理。这样就算代码泄露，攻击者也拿不到数据库密码。
数据库运维安全这件事，真不是花钱买个安全产品就能解决的。它需要从流程、制度、技术三个层面同时发力。权限最小化、日志全留、备份演练、基线加固、操作追溯，这五件事做好了，数据库运维安全就有了基本保障。就像我那个银行的朋友，现在他们把所有策略都落实到位了，虽然操作流程比以前繁琐了，但心里踏实多了。毕竟，数据库安全出了问题，损失的可不只是数据，还有客户的信任。
