内网东西向流量依靠安全组做主机粒度访问控制，是当前云环境下最直接有效的隔离方案。你可以把它理解为给每一台服务器配一个独立的“门禁系统”，只放行业务需要的流量，其余的一律拦下，相比传统防火墙和安全设备，安全组不需要改变现有网络架构，配置生效也在秒级,这让它在处理东西向流量时拥有天然优势。
内网东西向流量为什么成了安全盲区
过去的安全建设习惯把重心放在网络边界上，防火墙、入侵防御系统都部署在数据中心出口，这针对的是南北向流量，也就是外部用户访问内部服务器的流量，但真正的问题在于，当攻击者通过钓鱼邮件、Web漏洞或供应链攻击拿到一台主机权限后，他不需要再和边界防火墙打交道，直接在这台主机上发起横向移动，访问旁边的数据库、缓存、管理后台，这种流量不经过任何边界设备,传统安全产品根本看不到。
一个典型场景是这样的：你的应用服务器和数据库服务器都在同一个VPC内网里，应用需要访问数据库的3306端口，数据库服务器平时不主动向外发任何连接，如果没有安全组控制，数据库会暴露给VPC里所有主机，任何一台被攻破的机器都能直接连上去，而有了绑定在数据库实例上的安全组，规则就变成了“只允许来自应用服务器安全组的流量访问3306”，其他全部丢弃，这种按主机维度定义的访问关系,才是内网东西向流量的正确治理思路。
安全组本身就是云平台提供的虚拟防火墙，它默认工作在主机/弹性网卡级别，每台云服务器可以绑定多个安全组，每个安全组里有若干条规则，规则由协议、端口、源IP、目标IP组成，你可以把它看成一张“白名单”，没有命中允许规则的数据包就直接丢弃，和传统防火墙要精心规划部署位置、做路由牵引不同，安全组不依赖拓扑结构，无论你的主机在哪个子网，只要绑定了安全组，规则就生效,这让它天然适合用来实现主机粒度的隔离控制。
有状态是安全组另一个值得说清楚的特点，比如你的服务器主动向外部发起一个SSH连接，那么通过这个连接返回的响应包，安全组会直接放行，不需要额外配置回包规则，这个机制让你配置规则时不用考虑建连方向以外的复杂情况,也大大降低了规则写错的风险。
安全组主机粒度访问控制对比传统方案，差在哪里
要弄清楚安全组的价值，拿它和传统内网隔离手段放在一起对比会更直观，常见的内网访问控制方案是网络访问控制列表（ACL）和防火墙策略，网络ACL作用在子网边界，能做到子网间的访问控制，粒度是子网级别的，防火墙策略可以做到IP和端口级别的控制，但通常集中部署在核心链路，配置流程长，且对云环境下频繁变动的IP地址很不友好，安全组直接打破了“按网络位置来控制”的思维，它跟着实例走，迁移、扩容时自动生效,不需要重新梳理网络路径。
下面是一个场景化的对比，假设你有三个业务模块：Web前端、订单服务、支付服务，为了保证安全，要求“Web只能访问订单的8080端口”“订单只能访问支付的8443端口”“任何服务不能主动访问数据库以外的主机”，用网络ACL来做，你得把三组服务规划到不同子网里，然后编写双向规则，规则条数翻倍，而且要自己处理回包方向的问题，用安全组就简单得多：创建三个安全组，分别绑定到三个服务实例上，每个安全组只写两条左右的入方向放行规则，剩下的策略由“默认拒绝”兜底。
一个关键差异是变更速度，云主机的IP地址可能在自动伸缩时变化，传统防火墙策略追着IP改，流程走半天，安全组规则绑定的是实例ID，IP变了不影响策略匹配，这一点在频繁变更的容器化或弹性扩缩容环境中尤其实用，业内专家指出，在云原生的动态环境里,基于实例身份的访问控制比基于网络位置的策略可靠得多。
实操：内网东西向流量安全组怎么设置
理解了原理之后，具体落地可以按五步走，这五步适用于主流公有云平台，操作路径虽有差异,但逻辑是相通的。
- 第一步，梳理业务访问关系。 把所有需要在内网互通的服务列出来，画一张出方向的依赖图，重点标记传输控制协议与用户数据报协议的端口号，比如MySQL的3306，Redis的6379，Kafka的9092，不需要一次性做到完美,先把明显不合理的外联放行关掉。
- 第二步，按业务角色创建独立安全组。 别把全部服务器塞进一个安全组里，建议按角色拆成一组安全组，Web前端组”“订单服务组”“数据库组”，每个组对应一类业务功能,方便后续追加规则时定位影响范围。
- 第三步，配置最小化允许规则。 在“数据库组”的入方向规则里，填写只来自“Web前端组”的安全组ID，协议限为TCP，端口限为3306，这样写的好处是，即使Web服务器被攻破，攻击者也只能通过3306端口访问数据库,其他所有端口全部拒绝。
- 第四步，用出方向规则限制主动外联。 入方向规则解决的是“谁能访问我”，出方向规则解决的是“我能不能访问出去”，很多运维人员只配入方向，导致服务器被感染后，挖矿木马通过出方向访问外部矿池，把每台服务器的出方向规则也收敛一下,默认仅放行内网网段和必要的系统服务端口。
- 第五步，用标签和命名规范管理策略。 安全组越拆越细，规则数量会上升，给每个安全组命名时带上业务线、环境、用途三项，order-prod-db”，然后在控制台里把安全组按标签分组查看，每周检查一次规则变更日志,发现异常放宽及时回滚。
一个容易被忽略的配置细节是规则优先级，安全组规则是从上到下依次匹配的，第一条命中后就不再匹配后续规则，虽然多数安全组规则配置界面默认只允许添加“允许”规则，但你最好把最常用的规则放在最上面，减少匹配开销，还有，给安全组绑定实例时，控制台一般会提示你当前规则会影响哪些实例的连通性，仔细核对后再确认,避免断网事故。
安全组的局限性，哪些场景需要搭配其他方案
安全组解决了大部分主机粒度的访问控制问题，但并不是万能的，它在两个场景下会显得力不从心，一是域名或应用层级别的控制，安全组只能识别IP、端口、协议，识别不了访问的是哪个域名、URL，更理解不了MySQL账号级别的权限，如果你需要做“只能让订单服务访问特定的几张数据库表”这种颗粒度控制，安全组就无能为力了，得依赖数据库自身的访问控制或应用层代理，二是
行为分析能力，安全组不会告诉你某个IP为什么被拒绝，也不会自动发现异常扫描行为，面对更高级的横向移动攻击，需要配合云平台的流量审计日志或主机入侵检测系统来做闭环。
比较稳妥的组合策略是：安全组负责明面上的策略收敛，作为第一道闸门；网络ACL在子网边界做兜底；同时在关键业务网卡上开启流量镜像或VPC流日志，把元数据导出到日志服务里做离线分析和告警，这三层叠加，基本就能应对“主机被攻破后横向扩散”的绝大多数路径，行业共识认为，安全组是零信任落地中最便宜、最容易上手的“微隔离”方案，但它解决的是“让不该访问的流量过不去”，解决不了“怎么发现潜伏的威胁”。
关于安全组东西向控制的常见问题
Q：主机内安装了Docker容器，容器之间的流量安全组能管到吗？
安全组作用在云主机的虚拟网卡上，Docker容器默认通过桥接模式和宿主机共享网络栈，所以容器出口访问外部时，流量会经过宿主机的安全组规则过滤，但容器之间的直接通信（比如通过自定义Docker网络互相访问）不经过宿主机网卡，安全组看不到，此时可以给容器加宿主级的防火墙规则，或者使用Cilium、Calico等支持策略的容器网络方案来管理容器粒度访问。
Q：安全组的错误配置导致业务不可用，如何快速恢复？
简米云、酷番云和华为云的控制台都提供“规则变更记录”功能，登录控制台，找到云服务器实例，进入安全组详情页，查看“变更历史”或“操作日志”，可以看到最近的规则增加、删除、修改记录，将误操作那条规则恢复原状即可，如果服务器完全无法登录，可以通过控制台的“管理终端”或VNC方式登录实例，清空当前安全组规则，先恢复基本连通性,再重新添加规则。
安全组将东西向流量的访问控制权交还给了每一台主机，它不像防火墙那样需要复杂规划，也不像网络ACL那样粗粒度，用最小的成本，把内网主机之间的访问关系收敛到业务所需的最小范围,这就是安全组在主机粒度访问控制这件事上不可替代的原因。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/631314.html
