数据库最小权限与审计日志：降低网站被入侵后的横向风险

一、先拆分数据库账号，不让一个账号包打天下

最常见的隐患是所有程序都使用同一个数据库账号，并且拥有建表、删表、导出、授权等高危权限。更稳妥的做法是按业务角色拆分账号：前台只读或有限写入账号、后台管理账号、定时任务账号、报表统计账号、备份账号和只读审计账号。每个账号只允许访问自己需要的库、表和操作类型。例如前台文章展示只需要 SELECT，订单创建可能需要 INSERT，后台审核需要 UPDATE，但都不应该拥有 DROP、GRANT 或 SUPER 这类能力。

• 前台展示账号优先配置为只读，减少注入漏洞后的破坏能力。
• 后台账号按模块授权，避免一个功能点被攻破后影响全站数据。
• 备份账号只给读取和锁表所需权限，不要赋予修改业务数据的能力。

二、把高危操作变成可追踪的变更记录

数据库安全不能只看是否能登录，还要看登录后做了什么。建议开启慢查询日志、错误日志和关键操作审计，并把后台的敏感动作也写入业务日志，例如修改价格、变更用户余额、导出数据、删除文章、调整权限和修改支付配置。对于 MySQL 或 MariaDB，可以结合 general log、binlog、审计插件或数据库代理记录关键语句；对于生产环境，不建议长期开启过于详细的全量日志，而是根据性能和风险做分级记录。

• 余额、订单、权限、支付回调等核心表要重点记录修改来源。
• 日志中保留操作者、来源 IP、时间、影响数据和请求入口。
• 审计日志不要只存本机，重要系统应同步到独立日志位置。

三、限制数据库连接来源，减少暴露面

数据库端口不应该直接暴露给公网。如果业务部署在同一台服务器，优先监听本地地址；如果应用和数据库分离，应通过内网地址、安全组、白名单或专线通信，只允许指定 Web 服务器连接。远程维护数据库时，不建议长期开放 3306 等端口，可以使用 SSH 隧道、堡垒机或临时白名单方式，并在维护结束后关闭入口。这样即使数据库账号泄露，攻击者也不能从任意网络直接连接。

• 安全组和防火墙只放行业务服务器、备份服务器和管理节点。
• 禁止弱口令和默认账号，维护账号要单独管理并定期轮换。
• 数据库连接失败次数异常升高时，应触发告警并核对来源。

四、把权限巡检纳入每月运维清单

权限加固不是一次性工作。业务上线、临时排障、人员变动和脚本迁移都会产生遗留账号。建议每月检查一次数据库用户列表、授权范围、最近登录、密码更新时间和可疑远程地址。发现无人认领的账号要先确认用途，再禁用观察，最后删除；发现权限过大的账号要拆分或降权。对于核心业务库，还应定期做恢复演练，确保备份文件不只是存在，而是真的可以还原。

• 巡检时导出账号、主机来源、授权语句和最近使用情况。
• 临时账号必须有到期时间，排障结束后立即回收。
• 恢复演练至少覆盖结构恢复、数据恢复和业务可用性验证。