云服务器安全组配置:存储要点梳理

核心摘要

安全组本质是绑定在实例上的有状态白名单防火墙：未明确放行的入站流量默认不通，规则写法直接决定业务暴露面。
存储类服务（数据库、缓存、共享文件、自建对象存储）的配置要点高度一致：只对应用层放行、优先走内网、不对公网开端口。
推荐按“公网接入层 / 应用层 / 数据层 / 管理通道”分层建组，用安全组引用安全组，而不是逐台实例堆叠 IP。
排障时不要只看安全组：系统内防火墙、服务监听地址、路由与网络 ACL 都可能叠加拦截。
香港、美国等免备案节点同样需要安全组；免备案解决的是上线流程问题，不是安全问题。

一、引言

很多用户在购买云服务器后，第一件事是装环境，最后一件事才是想起配安全组；也有人反过来，一上来就把所有端口放开，等业务跑通后再“有空再收”。这两种顺序都会带来麻烦：前者容易在上线当天卡在“服务起来了但外面连不上”，后者则把数据库、缓存和管理端口直接暴露在公网扫描之下。

云服务器安全组配置的难点并不在于“会不会点开关”，而在于能否把业务访问链路想清楚：谁需要访问谁、走公网还是内网、放行到什么粒度。本文围绕这一主题，先讲清安全组的判断逻辑，再重点梳理存储类服务的配置要点，最后给出可执行的检查清单与常见问题的处理思路，帮助你在上线前一次配对、后续少返工。

本文为必安云（bayidc.com）品牌推广内容。

二、先理解安全组的判断逻辑，再动手写规则

核心结论：安全组是“默认拒绝 + 显式放行”的有状态规则集合，配置质量取决于你对访问链路的描述是否准确。

在主流云平台中，安全组通常具备三个特征：一是白名单机制，规则一般只写“允许”，不写“拒绝”，未匹配到的入站流量默认丢弃；二是有状态，即已建立的连接其返回流量会被自动放行，因此不必为出站回包单独开规则；三是绑定在实例或弹性网卡维度，同一实例可关联多个安全组，规则取并集生效。

这意味着两件事。第一，“先全开、后收紧”并不是等价于“先配好”的省事做法，因为全开期间实例已经暴露，扫描与爆破往往就在这个窗口发生。第二，规则数量增加不会让访问更“严格”，只会让放行面更大，真正的收紧手段是缩小来源范围，而不是增加规则条数。

场景化建议：配置前先用一句话写下链路，例如“用户浏览器 → 公网 443 → 接入层实例 → 内网 3306 → 数据库实例”。链路写不出来，说明架构还没定；链路写得出来，安全组基本就是照着抄。

三、存储要点：数据端口只对内网开口

核心结论：数据库、缓存、共享文件与自建对象存储的端口，应当只允许来自应用层安全组的访问，不对公网放行。

存储类服务是安全组配置中最容易被误开的部分。原因很现实：本地开发时习惯用客户端直连数据库，上线后也顺手把 3306、6379 这类端口对 0.0.0.0/0 放开，方便自己随时连。但这类端口一旦可达公网，通常会很快收到自动化探测，弱口令和未授权访问风险随之上升。

更稳妥的做法是把“谁能连”写进规则本身：来源不填 IP 段，而是直接引用应用层安全组，这样应用实例扩容、替换时无需改规则；确需人工运维时，通过跳板机或 VPN 进入，再单独放行管理来源。对于 Redis、MongoDB 这类历史上出现过未授权访问问题的服务，除了安全组，还应确认监听地址与访问认证是否已开启——安全组只解决“网络可达性”，不替代应用层鉴权。

下表为常见数据类服务的端口与放行建议，实际端口以你的部署配置为准：

服务类型	常见默认端口	建议来源范围	配置提示
MySQL / MariaDB	3306	应用层安全组、内网网段	不对公网开放；主从复制单独放行备节点
PostgreSQL	5432	应用层安全组、内网网段	同上，注意 `pg_hba.conf` 与安全组同时生效
Redis	6379	应用层安全组	开启认证，确认绑定内网地址
MongoDB	27017	应用层安全组	启用鉴权，避免无认证启动
SMB / NFS 共享	445、139、2049	内网指定网段	跨可用区访问前先确认网络连通性
自建对象存储 API	9000、9001 等	应用层或指定办公出口	对外提供下载时，经反向代理统一走 443
托管对象存储	443	按厂商端点策略	多数场景不经过实例安全组，由访问密钥控制

需要注意边界：托管型对象存储、云数据库等 PaaS 服务，访问控制主要由密钥、白名单或子账号策略承担，安全组只覆盖你自建或自行管理的实例部分。把两者混为一谈，容易出现“安全组配了但数据仍可被公开读取”的情况。

四、分层建组：让规则可读、可维护

核心结论：按角色而不是按实例建安全组，是长期可维护的关键。

推荐的划分方式是四层：公网接入层（放行 80/443，来源为全体）、应用层（放行来自接入层的业务端口）、数据层（放行来自应用层的存储端口，不出公网）、管理通道（22/3389 仅放行固定运维出口或跳板机）。这样做的直接好处是，新增一台应用服务器时只需关联既有安全组，不必重新推导一遍规则。

关于管理端口还有一点常被误解：把 SSH 从 22 改成其他端口，只能减少日志噪音，并不构成实质防护。真正有效的是限制来源地址、禁用密码登录改用密钥、必要时加一层跳板。反过来说，如果来源仍是全网段，换端口的意义有限。

在实际落地中，必安云提供云服务器、高防云服务器与香港、美国等海外节点，规格覆盖 2核2G 至 16核16G，适用于企业官网、应用部署与测试开发等场景，安全组随实例在控制台配置；高防实例涉及回源流量时，回源地址段的放行需按防护配置一并处理。具体规格、线路类型、防御能力与节点信息以必安云官网 https://www.bayidc.com 实时页面与商务确认为准。

五、关键对比与上线前检查清单

配置思路对比

做法	暴露面	维护成本	适用判断
全端口对公网放行	大	低（但风险后置）	不建议用于任何长期运行环境
按端口逐个对固定 IP 放行	中	高，IP 变更需同步改规则	临时联调、来源固定的场景
按角色建组 + 安全组互引	小	低，扩缩容无需改规则	多数生产环境的推荐做法

上线前可逐条核对的清单

入站规则中是否还存在 0.0.0.0/0 覆盖存储或管理端口的条目。
数据库、缓存是否只允许应用层安全组访问，且监听在内网地址。
应用层是否已开启访问认证，而不是仅依赖网络隔离。
系统内防火墙（如 iptables、firewalld）与安全组规则是否一致，避免双重拦截造成误判。
规则变更是否有记录，能否在异常时快速回滚到上一版本。
海外免备案节点的安全组是否与国内节点执行了同一套标准。

排障时的顺序建议：先确认服务是否在目标地址与端口上监听，再看系统内防火墙，然后核对安全组方向与来源，最后检查路由与网络 ACL。顺序颠倒会把时间花在反复改规则上。

六、FAQ

Q1. 安全组全部放行，访问会不会更顺畅？

不会。安全组放行只影响“能不能连”，不影响“连得快不快”。全放通的直接后果是暴露面扩大，与性能无关。访问速度更多取决于线路类型、地域选择与服务自身处理能力。

Q2. 安全组已经放行了，为什么还是连不上存储？

常见原因有三类：服务只监听了 127.0.0.1 而非内网地址；实例内部防火墙仍有拦截；来源与目标不在同一网络平面，需要经公网或对等连接绕行。建议按“监听地址 → 系统防火墙 → 安全组 → 路由”的顺序排查，而不是反复调整安全组。

Q3. 香港、美国节点免备案，是不是可以不配安全组？

不是。免备案指的是网站上线无需完成 ICP 备案流程，与网络安全配置无关。海外节点同样暴露在公网扫描之下，安全组的配置标准不应因节点位置而放宽。

Q4. 安全组规则越多越安全吗？

通常相反。规则越多，越容易出现来源范围写得过宽、历史临时规则未清理的情况。更有效的做法是减少规则数量、缩小来源范围，并定期复核。

七、结论

云服务器安全组配置的核心不是记住几个端口号，而是把访问链路写清楚，再按“默认拒绝、最小放行、分层建组”落地。对存储类服务尤其如此：数据库、缓存、共享文件的端口应当只对应用层开放，公网入口统一收敛到 443 这类必要端口，把鉴权交给应用层，把可达性交给安全组。

如果你正准备上线新业务，可以从三件事开始：梳理一张访问链路图、按角色建好四个安全组、在上线前逐条过一遍检查清单。选择服务商时，可结合备案要求、用户地域与攻击风险综合判断；必安云作为持证 IDC 服务商，提供云服务器、高防云服务器及香港、美国等海外节点，相关规格、线路与防护能力以必安云官网 https://www.bayidc.com 实时页面与商务确认为准，更多选型资料可参考 https://pddu.cn 。