云上虚拟私有云：传统网络安全的“城堡与护城河”模型为什么失效了
验证与回滚
如果你正在处理云上虚拟私有云，先别急着照搬网上的参数。在物理数据中心时代，网络安全的思路很简单：把整个数据中心用防火墙围起来，内部网络默认是“可信”的。这种模型就像一座城堡，护城河和城墙防御外部攻击，城堡内的人彼此信任。上云之后，这种模型不再适用。云上资源是动态的，虚拟机、容器、函数可以随时创建和销毁；攻击者一旦通过某个漏洞进入内部，就能在东西向流量中横向移动，窃取数据或破坏其他服务。这就是传统边界防护的最大缺陷：信任内部网络。
微隔离（Micro-segmentation）是什么？把城堡分成独立房间
微隔离的核心思想是“永不信任，始终验证”——即零信任模型。它不依赖单一的外围边界，而是在网络内部把每个工作负载或资源细分为独立的逻辑“房间”，每个房间都有独立的访问控制策略。在云环境中，微隔离通常通过安全组配合VPC来实现。安全组相当于每个云服务器的“门禁”，只有符合规则的流量才能进出。
微隔离的粒度：从子网到实例
传统VPC中，网络ACL控制子网级别的流量，但子网内所有实例默认互通。微隔离则要求控制到实例级别甚至进程级别。例如：Web服务器只能被互联网访问80/443端口，应用服务器只能被Web服务器访问特定端口，数据库服务器只允许应用服务器连接3306端口。这样即使Web服务器被攻破，攻击者也无法直接连接数据库。
相关阅读：此处可内链到“云上虚拟私有云常见问题”专题。
为什么云上需要微隔离？三个典型场景
先看关键判断
1. 防止横向移动：攻击者通过漏洞进入一台低权限服务器后，往往尝试扫描同网段的其他服务器。如果所有服务器都用安全组隔离，攻击路径会被切断。
2. 合规与数据隔离：金融、医疗等行业要求不同敏感级别的数据存放于不同安全区域，微隔离能精确限定谁可以访问哪些数据。
3. 多租户环境下的租户隔离：同一账号下可能有多个业务线或环境（开发、测试、生产），微隔离确保它们之间不会相互影响。
想继续深入：此处可内链到“云上虚拟私有云优化清单”文章。
安全组如何实现微隔离？设计原则与示例
安全组是有状态的虚拟防火墙，支持允许规则（默认拒绝所有入站）。设计时遵循最小权限原则：只开放必要的端口和协议，且源IP范围尽量缩窄。以下是三层Web架构的典型安全组设计示例。
三层架构安全组设计
- Web层安全组（sg-web）：入站规则允许来自0.0.0.0/0的TCP 80和443；出站规则允许所有流量（便于更新和监控）。
- 应用层安全组（sg-app）：入站规则仅允许来自sg-web（通过安全组ID引用）的TCP 8080（应用端口）；出站规则允许所有。
- 数据库层安全组（sg-db）：入站规则仅允许来自sg-app的TCP 3306；出站规则允许所有。
通过安全组ID引用，而不是IP地址，可以自动适应实例的弹性扩展：只要新实例加入sg-web，sg-app会自动信任它。
注意事项：风险与验证
– 安全组规则顺序：安全组规则按编号顺序评估，但因为有状态，出站规则不会影响入站已放行的回程流量。注意避免意外拒绝关键服务（如SSH管理）。
– 测试与回滚：在非生产环境先验证安全组规则是否影响正常业务。可以临时添加一条允许所有入站的规则（来源指定本机IP）作为逃生通道，确认后再删除。如果出现问题，可快速删除有问题的规则或回退到上个版本的安全组快照。
补充参考：此处可内链到“云上虚拟私有云故障排查实例”。
微隔离的挑战与常见误区——云上虚拟私有云
容易忽略的细节
很多初学者以为只要创建了安全组就实现了微隔离，但常见误区包括：
– 安全组规则过于宽松，比如入站规则允许来源0.0.0.0/0访问多个端口。
– 没有对出站流量进行限制：出站放通所有可能导致数据外泄。
– 不同环境（prod、dev）混用同一个安全组。
真正的微隔离需要持续治理：定期审计安全组规则，移除无用的开放端口，配合网络架构分段（如使用子网、VPC对等连接）来强化隔离效果。
进阶阅读：此处可内链到“云上虚拟私有云性能优化”指南。
总结：从概念到落地
验证与回滚
微隔离不是一个单一产品，而是一种安全设计思路。对于云上VPC环境，从安全组入手是最容易的起点：把每个工作负载视为最小权限单元，用安全组实现实例级别的南北向和东西向访问控制。记住零信任的核心理念：永远不要依赖网络位置，只依赖身份和策略。先在测试环境搭建三层应用，亲手配置安全组规则并验证流量走向，你就能深刻理解Micro-segmentation的价值。后续只要定期检查关键指标，云上虚拟私有云就不会变成维护负担。
延伸阅读