数据库安全配置怎么做

数据库出事往往不是被正面攻破，而是账号权限太肥、端口暴露在公网、日志没开、备份没人管。这篇按「先收缩出入口、再管账号、最后补审计」的顺序，把配置动作拆成可勾选的清单，并说明每项在什么情况下可以不做。适合手上管着几套库、要交自查表的运维与安全同学。

数据库出事，多数不是被高手正面打穿，而是自己把门留得太宽：账号权限肥得能删库、端口直接映射到公网、日志压根没开、备份文件躺在能下载的目录里。真正要做的配置动作没那么多，关键是有个顺序。

这篇按「先收缩出入口、再管账号、最后补审计」来排，每节都给可勾选的清单和判断标准，顺便说清哪些项在什么情况下可以省。适合手上管着几套库、月底要交自查表的运维和安全同学。

先砍暴露面：谁能连到你的库

先确认数据库监听在哪个地址、哪个端口。正常做法是只对内网或指定网段开放，确需公网访问时走跳板机或专线，不要直接把库端口映射出去。这一步投入最小、挡掉的扫描最多，所以放在最前面。

• 核对三处规则是否一致：云平台安全组、主机防火墙、数据库自身的白名单配置，常见坑是云上收了、主机防火墙还开着；
• 区分生产与测试实例，测试库不要复用生产的连接串和凭据，它们通常更松、更少人看；
• 定期看一眼当前连接来源，把来路不明的 IP 列出来查一遍，别只看规则文件；
• 判断是否适用：纯单机离线、没有远程运维需求的场景可以放宽监听限制，只要有人远程连就必须收敛。

账号与权限：把能改数据的口子收到最少

权限这块的核心就一句：一个应用一套凭据，业务账号不该有建表、删库、改权限这类管理能力。多人共用一个高权账号是最常见的隐患，出了事连是谁操作的都查不出来。

只读账号

给报表、数据分析、排查问题用，只能查不能改，用完即弃或定期轮换。

读写账号

给业务应用用，权限限定在它自己那几个库表，不含结构变更能力。

运维账号

需要时才申请、走带审计的通道，用完立刻回收，不做长期常驻。

除权限拆分，还要盘历史账号：安装时留下的示例账号、离职同事的账号、半年没人用的只读号，都列出来逐个确认。这一步不追求一次清干净，但要形成定期盘点的习惯。

• 按应用拆账号，禁止多人共用同一个高权凭据；
• 业务账号去掉建表、删库、改权限等管理能力；
• 只读、读写、运维三类分开，运维权限临时申请；
• 清理默认账号、示例账号和长期不用的账号；
• 判断是否适用：单人或极小团队的本地开发环境可以共用一套，只要有对外服务就别省。

连接链路：加密、隔离与访问入口

跨网段或跨机房的连接建议启用传输加密，否则口令和查询结果就在网络里明文跑。同时把库放在独立子网，只允许应用服务器访问，别和面向公网的机器放同一个安全组。

管理入口只留一条路：控制台、SSH 隧道、跳板机三选一，别每条路都留一个能连库的后门。多留一个入口，就多一处没人管的配置。

审计、日志与备份：出事之后拿得出东西

日志要记录登录来源、失败次数、权限变更、批量删除类操作。重点不是全量记录，而是这几类能还原出「谁在什么时候做了什么」。日志本身要防篡改，单独存放、只追加权限，别和应用日志混在同一台机器上等同一把钥匙。

1. 打开关键日志启用连接日志与慢查询日志，确认权限变更和批量删除有记录，然后实际触发一次看是否落盘。
2. 隔离存放把审计日志放到独立路径或独立主机，设置只追加权限，验证普通账号改不了、删不掉。
3. 做恢复演练定期从备份真恢复一次，检查数据是否完整，只验证「备份文件存在」不算数。
4. 定脱敏口径日志里涉及个人信息的字段做脱敏，具体口径可到 质量检测相关页面（/tools/quality-check） 和站内脱敏内容对照。

自查顺序与常见漏项

按「暴露面 → 账号 → 链路 → 审计备份」的顺序查，先堵最容易被扫到的口子，再补细活。这样即使时间不够，前半段做完也已经挡掉大部分自动化扫描。

具体指标数字与评估口径，以站内页面当时的记录为准，可以去 检测口径与数据来源（/about） 核对当时的口径，避免拿旧数字对现在的配置下判断。

• 先跑暴露面：监听地址、端口、安全组、白名单；
• 再跑账号：权限拆分、历史账号清理；
• 然后跑链路：加密、子网隔离、管理入口收敛；
• 最后补审计备份：日志、防篡改、恢复演练；
• 每次变更后重跑，配置漂移比一次配错更常见。

数据库安全配置不是一次配完就完事，而是一份每次变更后都要重跑的清单。