把数据库放进私有子网再配合安全组收紧入站，是目前云上数据库安全组配置里最具性价比的防护手段，能挡住绝大多数来自公网的扫描和暴力破解流量。
很多团队在云上跑业务,习惯性地把数据库和其他资源一股脑丢进同一个子网，然后图省事给安全组配个对所有人开放的入站策略，这等于把数据库密码贴在门把手上，下面这套配置思路，能帮你用最小的操作成本，把数据库的暴露面压到最低。
为什么数据库放进私有子网是安全组的底线
公有子网和私有子网的本质区别
云厂商划分子网时,核心逻辑就是看这个网段里的资源要不要直接面对公网，公有子网通常关联了互联网网关，里面的云主机自带公网IP或者能通过NAT转发被外部访问，私有子网没有这条通路，里面的资源只有内网IP，公网上的扫描器根本ping不到，更别提逐个端口试密码了。
行业共识认为,数据库这类存储核心资产的组件，默认就应该放在私有子网，这不是折腾，而是云安全架构里最基础的一层隔离，传统机房时代把数据库暴露在公网IP上，靠防火墙硬扛，那是没得选，上云之后有了子网隔离这个能力，再用老思路就有点说不过去了。
安全组在私有子网里扮演什么角色
私有子网解决了“公网能不能路由到你”的问题，安全组解决的是“内网里谁能访问你”的问题，两者配合，效果是叠加的：
- 私有子网负责挡掉公网侧的无效流量,比如扫描器、随机爆破脚本
- 安全组负责限制内网侧的访问来源,比如只允许应用服务器所在的网段连接数据库端口
- 默认情况下,私有子网里的数据库不绑定公网IP，这就掐断了最直接的攻击路径
有团队问,数据库在私有子网里，是不是就不用配安全组了？恰恰相反，私有子网挡的是外部，安全组管的是内部，如果安全组入站规则写的是允许所有来源访问3306端口，那内网里任何一台被攻陷的机器都能直连数据库，这依然是个大隐患。
数据库安全组配置，入站规则要收紧到什么程度
入站规则的“最小权限”原则怎么落地
安全组规则看着简单,无非是协议、端口、来源IP，但细节决定成败，业内专家指出，大量数据库泄露事件并非漏洞导致，而是安全组规则配置过度宽松，比如来源写0.0.0/0，等于对所有IP开放，和裸奔没什么区别。
真正合理的入站规则,应该精确到
具体IP或者IP段，操作路径如下：
- 打开云控制台的数据库实例页面,找到“安全组”或“防火墙”标签
- 在入站规则里,协议选“TCP”，端口填数据库实际使用的端口，比如MySQL的3306、PostgreSQL的5432、Redis的6379
- 来源填应用服务器所在的私网网段，比如
0.1.0/24，而不是0.0.0/0 - 如果有多台应用服务器分布在不同的子网,就分别添加对应的网段，别嫌麻烦用一个大网段糊弄
默认拒绝规则远比想象的更重要
很多云平台的安全组默认有一条拒绝所有入站流量的规则,但用户往往在配置时故意去删掉它。保留默认拒绝规则，只显式地添加几条允许规则，才是正确的做法，这就像门禁系统，默认锁门，只有刷卡才能进，而不是默认开门，看到可疑的人再关门。
安全组规则遵循白名单逻辑：没有明确允许的，就是不通过的，所以配置时不用想着“我允许了3306端口，是否需要再配一条禁用的规则”，不需要，白名单机制下，没有被允许的端口请求自然会被丢弃。
私有子网加安全组的实操配置步骤
第一步：确认数据库实例的网络位置
登录云控制台,找到数据库实例列表，看看实例所在的子网是公有还是私有，如果发现数据库跑在公有子网上，别犹豫，迁移到私有子网，大部分云厂商支持在线迁移，比如酷番云可以只变更内网IP把实例挪到目标子网，控制台里有操作入口，过程会有短暂连接中断，建议选业务低峰期操作。
简米云的话,RDS可以在控制台的“数据库连接”里切换交换机，本质就是迁移子网，迁移过程中IP会变，应用连接的地址也要同步更新，所以提前规划好窗口期。
第二步：配置安全组时先删掉宽松策略
在“安全组”管理页面，新建一个专门给数据库用的安全组，不要复用应用服务器的那组规则。
- 出站规则按需放行,一般保持默认全放通就行
- 入站规则只添加必要的,来源精确到应用服务器的私网IP或网段
- 确认没有一条入站规则来源是
0.0.0/0
第三步：绑定数据库实例并验证连通性
在数据库实例详情页,把刚建的安全组绑定到实例上，然后从应用服务器测试连接：
- 用
telnet或者nc测试数据库端口是否可达，比如
nc -vz 10.0.0.100 3306
- 用客户端工具尝试连接,确认账号密码、权限、SSL配置都没问题
- 从一台没有权限的跳板机或者办公网测试连接,观察连接是否超时，如果超时，说明安全组规则生效了
这一步很关键,验证“能连”和“连不上”的两类场景，确定规则没有误伤业务。
数据库安全组配置的常见误区和对比
安全组和网络ACL分不清楚
不少教程文章会把安全组和网络ACL混为一谈,实际两者是两层防护：
| 对比项 | 安全组 | 网络ACL（访问控制列表） |
|---|---|---|
| 作用层级 | 实例级别 | 子网级别 |
| 规则逻辑 | 白名单，只能设允许 | 允许+拒绝两种 |
| 生效方向 | 需要单独配置入站/出站 | 入站/出站同时配置 |
| 适用场景 | 精细到单个实例 | 整段子网的统一管控 |
数据库实例绑定了安全组,所属子网也可以配置网络ACL，如果两层都配，流量得同时通过两关，任一层的拒绝规则生效，连接就失败，通常建议网络ACL做粗粒度限制，安全组做细粒度管控。
数据库放在私有子网就不用管应用安全
有些人觉得数据库藏起来了,安全组也收了，就万事大吉，其实不对，私有子网和安全组解决的是“网络层可达性”问题，解决不了“应用层漏洞”，如果应用服务器本身被攻破，攻击者拿到应用服务器的权限，还是能通过合法路径访问数据库。
所以数据库的安全是个组合拳：
- 网络层：私有子网+安全组收紧入站
- 账户层：最小权限账号，定期轮换密码
- 审计层：开启慢查询日志和操作审计
- 备份层：自动备份和手动快照结合
追求极致的规则数量反而增加管理成本
安全组规则不是越少越好,而是越精确越好，有团队为了表面上的严格，把每个IP拆成单独的规则，结果管理混乱，后面排查问题都得翻半天规则列表，合理的做法是：把应用服务器划到一个或多个有业务含义的子网，用网段做来源，规则保持在个位数。
数据库安全组配置后怎么验证效果
配置完成不是终点,验证收口效果才算数，有几个检查动作建议定期做：
-
用外网云主机或者本地电脑,尝试连接数据库的公网入口，正常情况下，应该是连接超时，而不是“拒绝连接”或“连接成功”
- 检查安全组规则列表,看有没有来源为
0.0.0/0的入站规则，特别是协议为TCP的 - 查看数据库实例的监控日志,观察是否有来自未知内网IP的登录失败记录
- 用云厂商的“配置检查”工具或者第三方云安全评估平台，扫描当前数据库实例的风险项，大多数扫描工具会直接给出安全组风险提示
有些云厂商提供“安全组审计”功能，能显示安全组近期的变更记录，多关注这块，防止某个同事图省事加了一条临时开放规则后忘了清理，毕竟安全是长期运营的事，不是运维人员配置一次就完工的。
私有子网加安全组这套组合,操作成本低，效果立竿见影，数据库先挪到私有子网，再用安全组把入站范围压缩到只有业务需要的网段，数据库安全组配置这件事就算是及格了，只要规则不胡乱放开，大部分常见的自动化攻击手段根本摸不到你的数据库端口。
数据库安全组配置和子网隔离常见问题
数据库在私有子网，应用服务器需要配置NAT才能访问吗？
不需要。 私有子网里的资源访问同VPC内的其他私有子网资源，走的是云厂商内网路由，不经过NAT网关或公网，应用服务器正常连接数据库内网IP即可，只有私有子网里的资源主动访问公网（比如下载软件包）才需要配置NAT网关。
安全组入站来源用IP好还是用安全组ID好？
各有适用场景。 如果应用服务器数量很少，IP稳定不变，直接填IP更直观，但如果应用服务器经常弹性扩缩容，IP会频繁变化，这时候在入站规则来源里选择另一个安全组的ID更省事只要应用服务器绑定了那个安全组，就等同获得了访问权限，不用每次调整IP白名单，酷番云和简米云的安全组规则都支持这种写法。
数据库迁移到私有子网时会中断业务多久？
多数情况下总连接中断时间在两分钟以内。 具体时长看数据库实例规格和数据量，控制台发起迁移后，实例会进行跨子网的内网IP切换，这个过程业务侧表现为连接断开，需要应用具备自动重连机制，否则要手动重启应用，迁移前建议把维护时间设置在业务低峰期，并提前通知相关开发人员确认连接池配置了合理的超时重连参数。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/629382.html
