云服务器和传统物理机的一个明显区别，是流量在到达系统之前，还会经过云平台的一层访问控制，通常叫安全组或者防火墙策略。这层规则的生效位置在实例之外，即使系统里的服务配置写错了，只要没有放行，外部依然连不上。理解这一点很重要：加固的功夫要分层做，最外面这层改起来最快，效果也最直接。
最普遍的问题是放行范围写成了对所有地址开放，理由是省事，反正里面还有密码。其次是规则越加越多，早期的测试规则没人清理，端口清单越来越长，自己也说不清每一条是为什么开的。还有一种是把管理端口和业务端口混在一起放行，管理入口本该只对固定出口开放，结果变成了全网可访问。
这几类问题的共同点是：配置时只考虑了能不能通，没有考虑需不需要通。等到出事回头翻规则，往往已经理不清哪些还在被使用。
思路可以概括成先关后开：默认拒绝所有入站流量，然后按实际提供的服务逐条放行，每条规则都要能回答三个问题——谁需要访问、访问哪个端口、为什么不能限定来源。业务端口面向公开用户，来源只能放开；管理端口、数据库端口、缓存端口这些，来源就应该收窄到固定的出口地址或者跳板机。
出站流量同样值得管。默认全部允许意味着机器一旦被控制，可以自由向外发起连接、下载后续工具。按需限制出站目标，能在一定程度上抬高攻击者继续操作的成本。
网站服务的端口对全网开放，这是业务需要；远程管理的端口只对运维出口开放，并尽量改到不常见的位置；数据库和缓存的端口不对公网开放，只允许同内网的应用机器访问；监控与日志采集的端口限定在采集端；其余的临时端口用完就删。
规则本身没有版本概念，改动之后容易被遗忘。比较实用的做法是定期导出一份规则清单，逐条确认是否还有业务在用。上线新服务时先申请后开通，下线时同步回收，避免清单无限膨胀。判断一条规则是否还有用的方法也很简单：把它的命中记录调出来，长期没有流量的，基本可以考虑关闭。
如果业务量比较大，规则数量迟早会多到难以人工维护。这时候把规则按用途打上标签，比如业务、运维、监控各成一组，排查和清理都会轻松很多。
规则改完不等于生效。最直接的验证方式是从外部真实访问一遍：用一台不在允许列表里的机器，尝试连接原本开放的管理端口，确认返回的是超时或拒绝，而不是登录界面。只在控制台里看着规则存在，说明不了任何问题。
其次是看业务有没有被误伤。监控数据、服务之间的调用、定时任务用的接口，这些都是平时不显眼、一旦被挡住就会报警的位置。放行时按最窄的来源写，能用一个地址就不要写整段，能用一段就不要写全部。
最后是留底。把每次改动的原因和时间记下来，过一段时间回头看，能很快分辨出哪些规则还有用，哪些是当时临时加的、后来再没人动过。规则堆得太多自己都看不懂，安全性反而下降。
安全组改完之后，别忘了同步更新相关的说明文档和监控项。新增的放行规则如果没有对应的记录，过半年谁也不敢删，规则越堆越多，自己也说不清哪条还在用。
临时开放的端口尤其要留个提醒。为了一次调试开的入口，如果没有回收的备注，很容易就这么一直开着，变成长期暴露面。同一台机器上的服务往往还互相依赖，收紧之前先确认调用方用的是哪个地址、哪条链路。
与其等到出事再回头看配置，不如设定一个固定周期，把对外暴露的入口、账号列表和放行规则过一遍。每次改动都不大，积累起来的效果却很明显，也比一次大范围调整安全得多。
周期不必太密，能坚持执行才有意义。
售后客服
企业微信
