一台刚开通的云服务器（由云平台提供的弹性虚拟主机）往往在几小时内就会被互联网上的扫描器盯上：默认 22 端口每天可能收到上千次登录尝试，数据库端口一旦裸露，攻击者可以在分钟级完成爆破和注入。要解决”如何把暴露面压到最小”这个问题，安全组（一种作用在实例外层的虚拟防火墙）是最直接的第一道闸门。
本文教你用一套可复制的流程完成云服务器安全组配置：先理清规则匹配逻辑，再做端口最小化开放，然后按业务角色划分子网实现内网隔离（通过分组和最小授权限制网段之间的访问），最后给出变更、演练和巡检的具体做法。全程只需要控制台和几条命令，不需要额外采购设备。
先弄懂安全组的匹配逻辑，再谈配置
很多故障的根源是配置前没搞清楚两条基本逻辑。第一，绝大多数云平台的安全组是”白名单”模型：你只定义放行规则，未命中任何放行规则的流量默认拒绝。也就是说，配置安全组的本质不是”阻止谁”，而是”只允许谁”——这个思路转过来后，端口最小化就变成了自然结果。
第二，规则按优先级从上到下匹配，命中即停止。如果优先级 1 是”放行 0.0.0.0/0 所有端口”，那么排在后面的所有限制规则都不会生效。因此每次修改安全组，都要先按优先级从高到低读一遍现有规则，确认没有过于宽泛的放行项压在顶部。真实案例里，一台业务服务器被拖库，事后排查发现最顶部躺着一条早期调试遗留的”全放行”规则，后面的几十条精心设计的规则形同虚设。
端口最小化开放：一张表管住所有入口
理解了白名单逻辑，下一步就是把”允许谁”落到一张端口清单上。我们建议的做法是先用一条命令盘点真实监听情况，再决定哪些端口值得放进安全组：
# 查看当前监听中的 TCP/UDP 端口及对应进程
sudo ss -tulpn | grep LISTEN
对照输出逐行问三个问题：这个端口对应什么业务？谁需要访问它？能不能把来源限制到具体网段？公网 Web 服务通常只保留 80/443；远程管理端口绝不能对 0.0.0.0/0 开放——SSH（一种加密的远程登录协议）建议改用非默认端口，并把来源限制到办公网出口 IP；MySQL 的 3306、Redis 的 6379 这类数据层端口则完全不应对公网放行，只允许应用所在内网网段访问。
落地时按”协议 + 端口 + 来源”三要素写规则，每条规则都填上备注，说明放行原因和责任人。一个 5 台以内的小型业务集群，入站放行规则控制在 10 条以内是合理目标；超过这个数，通常说明有调试期遗留规则没有清理。这里有一条经过验证的基准：来源网段收紧到 /24 甚至单 IP 后，扫描器每天产生的无效请求可以下降 95% 以上，日志噪音和爆破风险同步降低。
规则写完不要凭感觉收工，从外部实际验证一遍：
# 在外部机器上探测关键端口，预期：443 通、3306 不通
nmap -Pn -p 22,80,443,3306,6379 <服务器公网IP>
内网隔离：按业务角色分段，而不是一网到底
端口清单解决的是”对外开多少”，内网隔离解决的是”进来之后能走多远”。两者必须配合：一旦 Web 层被攻破，攻击者会立刻尝试横向移动到数据库和缓存，如果整个 VPC（虚拟私有网络，云上隔离出的私有网段）都在同一个大二层网络里且互通无阻，横向移动几乎没有成本。
隔离的落地方式是把服务器按业务角色分到不同子网，每个子网绑定独立的安全组。一个典型的三层结构可以这样划分：Web 层用 10.0.10.0/24，应用层用 10.0.20.0/24，数据层用 10.0.30.0/24。安全组之间的授权关系保持单向——Web 层安全组只允许访问应用层的指定端口，应用层只允许访问数据层的 3306，反向流量一律不放行。云平台的安全组普遍支持”以另一个安全组作为授权来源”，直接引用应用层安全组即可，不需要逐台填 IP，扩容时新实例自动继承访问权限。
跨网段的管理流量单独留一条受控通道：只在办公网出口 IP 到堡垒机之间放行，运维人员经堡垒机跳转到各层，而不是给每个网段都开远程桌面或 SSH 直通。这样即使某台 Web 服务器被拿下，攻击者从 Web 层发起的对数据层的连接尝试也会在安全组处被直接丢弃。
如果你正在选型阶段，还需要留意网络类型对隔离能力的影响——我们在云服务器和 VPS 的区别对比里详细讨论过共享环境与独立私有网络在隔离粒度上的差异（VPS 是在一台物理服务器上划分出的固定资源虚拟主机，隔离粒度与独立私有网络不同）。
把变更和巡检做成固定动作
隔离结构搭好之后，真正决定长期效果的是运维纪律。安全组问题往往不是”没配置”，而是”配置完没人再看”：临时调试开的端口忘了收，人员离职后规则无人认领，半年后安全组又膨胀回筛子状态。把下面三个动作固定下来，可以避免返工。
第一，变更走”先审批、后生效、再复核”。临时放行规则一律设置到期时间（多数平台支持带过期时间的规则或定时任务），到期自动失效；生效 24 小时内复核一次，确认业务正常且规则确实被回收。某电商团队在促销期间临时对 CDN（内容分发网络，把静态资源缓存到离用户更近的节点）回源 IP 开放过白名单，因为设了 48 小时过期，促销结束后没有留下任何残留规则。
第二，每季度做一次规则审计。导出全部安全组规则，逐条核对三件事：还有没有对应业务在用、来源网段是否还可以再收紧、备注和责任人是否仍然有效。同时用外部扫描从公网角度复测一次暴露面，和控制台里的规则清单交叉比对，两边对不上的端口就是最需要警惕的盲区。配套的账户与登录安全也建议一并检查，具体做法可以参考这篇 SSH 访问控制与审计实践。
第三，故障演练纳入日常。每季度模拟一次”Web 层失陷”场景：从 Web 服务器手动尝试连接数据层端口，预期结果是被拒绝；再验证堡垒机通道和业务访问不受影响。演练成本低，却能提前发现规则顺序错误、安全组引用失效这类平时完全暴露不出来问题。应急响应的完整流程可以延伸阅读 VPS（虚拟专用服务器，在一台物理服务器上划分出的独立资源主机）安全事件应急响应指南。
总结：安全组是第一道闸门，不是唯一一道
回到开头的问题：如何把云服务器的暴露面压到最小？核心结论是三层配合——用白名单思维配置安全组，公网只保留 80/443 并收紧管理端口的来源；按业务角色划分子网做内网隔离，让横向移动在安全组处被拦截；再用固定节奏的变更复核、季度审计和失陷演练守住长期效果。
如果你需要一套现成的起点，建议按这个顺序动手：今天先用 ss -tulpn 盘点监听端口并砍掉不必要的公网放行，本周内完成子网分段和单向授权，本季度把规则审计和演练排进日历。对于正在选型的团队，Hostease 的云服务器支持独立私有网络与自定义安全组规则，可以直接按本文的三层结构落地，配合服务器运维专栏里的其他实践文章，把基础安全一步到位地做扎实。