数据库被拖库、被误删、被内部人顺走，事后复盘十次有九次能追到配置没做全：账号共用、端口对公网开着、备份库没人管、审计日志压根没开。这篇不讲原理，给一份能照着核对的配置方法清单，按优先级排好顺序，并说清哪些做法在什么情况下不适用，避免你把线上业务配挂。
数据库被拖库、被误删、被内部人顺走，事后复盘十次有九次能追到配置没做全：账号共用、端口对公网开着、备份库没人管、审计日志压根没开。这类问题不需要多高深的技术，纯粹是清单没核对完。
下面按账号、网络、数据、审计四条线拆一份配置方法清单，每条都写清判断标准和什么情况下不适用。不讲原理，只讲能照着核对的步骤，避免你把线上业务配挂。
一、账号与权限：先把"谁能连、连了能干什么"收紧
先别动配置，先把现状盘清楚。登录数据库拉一下当前所有账号、每个账号的授权范围、来源主机限制，跟实际调用方对一遍。对不上的账号先禁用不要急着删，禁用是可逆的，删了再回溯就麻烦了。
- 禁用或删除默认账号、示例库与匿名账号，每个应用单独建账号，禁止多人共用同一套凭据；把账号清单和实际调用方对一遍，对不上的先禁用再问。
- 按最小权限授权，只给业务真正用到的库表与操作类型，禁止业务账号带建库、改结构、读系统表的权限；给账号限定来源主机，别写成任意地址。
- 管理类账号与应用账号分开，DBA 的日常查询走只读账号，高危操作走带审批的临时提权通道，而不是直接用超级账号。
- 定期复查长期不活跃的账号，没人认领的直接禁用，别让它成为后门。
二、网络可达性与接入面：能连到才是风险
把数据库端口对公网开放是最常见也最致命的一条。先确认你的数据库到底能从哪些地方连到：从办公网、从外网、从云上其他租户。做法是先内部梳理安全组和防火墙规则，再从外部实际扫一遍，确认没有历史遗留的放行规则。
| 检查项 | 判断标准 | 不适用情况 |
|---|---|---|
| 端口暴露 | 默认不对公网开放，外连走白名单加跳板机或内网专线 | 完全物理隔离的离线内网，收益有限 |
| 远程管理口 | 关掉不必要的远程管理端口与调试接口 | 调试环境可临时开放，但要限时 |
| 传输加密 | 账号密码不明文过网络，连接启用加密传输 | 同机房内网可评估，跨网必须做 |
| 读写入口 | 报表与分析类只连只读副本 | 小规模单库场景可暂不拆分 |
- 从外部扫端口用外部机器对数据库端口做一次连接测试，确认是否能通；能通就去看是哪条规则放行的，能不能收窄来源。
- 收窄来源 IP把放行规则从任意地址改成具体的业务机器或跳板机地址段，改完立刻用业务账号连一次验证。
- 区分读写入口报表、分析类任务改连只读副本，避免分析任务把主库压垮或误改数据；确认只读账号没有写权限。
- 留回滚步骤改网络策略前先把旧规则截图或导出，一旦业务报连不上能快速回退。
三、数据侧：存储加密、脱敏与备份
存储层加密和备份加密是两件事，别混着做。前者防的是磁盘被物理拿走，后者防的是备份文件外流。很多人主库做得很严，备份库却随便谁都能连，备份库往往是最松的一环。
- 备份库同样要单独建账号、单独限网络，别和主库共用一个宽松的账号。
- 敏感字段做脱敏或加密后再落库，密钥不和应用放在同一台机器、同一个配置文件里。
- 备份要定期做恢复演练，确认备份真能还原；只有备份任务成功日志、没有还原验证，等于没备份。
- 脱敏和加密怎么选，看你的使用场景是对外展示还是要能还原，两种做法不可逆，改之前先小范围验证。
四、审计与日志：出事时能不能说清
审计不是开了就行，关键是日志存哪、谁能删、留多久。最常见的问题是审计日志和数据库在同一台机器上，数据库账号自己就能删，出了事一点痕迹都没有。审计日志要单独存放，数据库账号无权删改自己的审计日志。
- 登录失败
- 重点记录，能看出有人在爆破账号
- 权限变更
- 授权、提权操作全留，事后能追溯是谁改的
- 大批量导出
- 记下影响行数，方便判断是正常跑批还是拖库
- 结构变更
- 建表改表删表全记，防止误操作无据可查
- 时间对齐
- 数据库日志和应用侧日志时间对齐，排查时才能串起来
日志留存期限按你的合规要求定，到期归档而不是直接删。导出类操作记下影响行数，方便事后判断是正常跑批还是拖库。保留取证用的原始记录格式，别只留聚合后的报表。
五、怎么验：一次配置核对的排查顺序
四项都改完不等于没事了，得按顺序验一遍。顺序很关键，前面的问题没解决，后面的加固意义不大。
- 外部能看到什么从外网扫端口，确认数据库没有意外暴露；有暴露先收口，其他都往后放。
- 谁能连进来核对账号清单与来源主机限制，确认没有共用账号和任意地址放行。
- 连进来能干什么抽查业务账号的实际权限，确认不带建库改结构这类高危操作。
- 干了有没有记录触发几类高危操作，确认审计日志真的有记录、存在单独位置、业务账号删不掉。
每改一项先在小范围或从库验证，确认业务不报错再推到主库；改权限和网络策略务必留回滚步骤。把核对结果整理成一张清单，标明每项的责任人、上次核对时间、例外说明，下次照单复查即可。
各家数据库的配置项名称不同、默认值也一直在变。具体数值、评分口径与各家规则的对照，到站内 /safety 与 /tools/quality-check 看当时的版本，别照着旧笔记执行。
下一步把本文的清单当底稿，对照站内安全评测页看当时的规则版本和检测方法，再决定你这边哪些项要优先补。→常见问题
预算和人力都有限，只能先做一件事，做哪个？
先收账号与权限：把默认账号、共用账号、超级账号给应用用这几类问题处理掉，收益最直接、风险最低。网络策略改动容易影响业务连通性，放到第二步，配合一次停机窗口或从库验证再做。具体各项的优先级口径可在站内 /safety 分区对照当期整理。
开了审计日志会不会把数据库拖慢？
取决于日志粒度和写入量。先只覆盖登录、权限变更、大批量导出这几类高危动作，观察一段时间的性能表现再决定要不要扩大范围。全量记录所有查询在小库上无所谓，在高写入业务上可能很吃 IO，别一次性全开。
用了云厂商的托管数据库，这些还需要自己配吗？
托管只解决了底层补丁、物理安全和基础备份，账号权限、来源限制、审计开关、敏感字段处理仍然在你自己手里。去控制台把这几项逐个核对一遍，再对照 /safety 分区的清单，看看有没有默认放开但你没注意的选项。
