数据库加固:账号、网络、备份三处最容易出事

加固 · 2 分钟阅读· 261 次阅读

数据库是数据泄露事故的核心目标。多数入侵不是 0day,而是弱口令或暴露端口。

加固思路很简单:不给公网、不给多余权限、备份也要保护。

先说结论

只监听内网、账号按库授权、备份加密异地。 三条做到,风险下降一个量级。

  • bind-address 绑内网 IP
  • 业务账号只授予必要库表权限
  • 禁用 FILE/SUPER 等高危权限
  • 备份加密并异地保存

漏洞是怎么产生的

数据库权限的原则是「够用就好」:业务账号不需要 DROP、不需要访问 mysql 库。

备份文件往往包含全量数据,却是最容易被忽略的泄露点。

修复与验证

修复不是改一行代码,而是四件事一起做:

  • 确认监听地址与防火墙只允许应用服务器访问
  • 按业务建独立账号,逐库授权
  • 删除匿名账号与 test 库
  • 开启慢查询与审计日志
  • 备份加密(gpg/age),并验证恢复

攻击面与检测点

按影响面排序,先修影响最大的:

项 风险 加固
监听 0.0.0.0 公网可扫 绑内网 + 防火墙
root 远程登录 弱口令即失守 禁远程 root
FILE 权限 读写服务器文件 收回权限
明文备份 拖库即泄 加密存储

数据库加固

几个容易踩的坑

下面这些是最常见的错误做法:

  • 把数据库端口映射到公网图方便
  • 所有应用共用一个 root 账号
  • 备份放 web 目录:可直接下载
  • 只做备份不做恢复演练

写在最后

数据库安全的核心是「缩小暴露面」,性能优化可以后面再说。

安全不是一次加固,是持续的假设:假设输入不可信、假设边界会破、假设有人会看错。

评论 (3)

半
半箱油

修复清单比漏洞描述有用多了,很多文章只讲怎么打不讲怎么防。

白
白帽小林

白名单那条永远是最有效的,正则黑名单迟早绕过。

运
运维老张

建议再补一条:把这类检查加到 CI 里,靠人记必然漏。

发表评论

验证码

提交后需站长审核,通过后才会显示。