最小可行网络的力量

对于刚刚开启云之旅的组织而言，理解云网络是最大的调整之一。当您审视其寻址方案和各个组件时，它看起来有点像 IP 网络。从大多数角度看，它确实是——但在许多其他方面，它并不是。软件定义网络（SDN）——例如云中提供的那些——不受物理网络的同等约束，这在起步阶段可能会相当令人困惑。

与其试图理解 SDN 与您的物理网络有何不同，不如把重点更多放在您需要网络做什么，以及更重要的是，什么不应被允许。您或许还记得一个叫做“默认拒绝”的概念，它意味着除非您明确允许某个连接发生，否则它会被默认阻止。后来出现了 Web 这个东西，限制 80 端口或 443 端口变得不再可行，因为几乎每个应用程序都在使用这些端口。此外，“默认拒绝”从未真正越过边界，我们的内部网络往往是扁平和开放的，依靠 DMZ 过滤来自外部世界的恶意流量。正如一次又一次的入侵事件所表明的，这种模式的效果只是差强人意。

但 SDN 让我们能够通过一个我们称之为“最小可行网络”的概念更加接近默认拒绝，该概念支持构建自定义网络，只包含完成工作所需的部件，别无其他。

最小可行网络应当先确定应用程序架构，然后仅创建支持该应用程序所需的网络，实施最小权限路由和安全组，并利用云负载均衡器等 PaaS 组件。这实际上把分组交换网络变成了电路交换网络，因为应用程序组件只能与其他被允许的组件通信，且中间的流量无法被嗅探（在某些情况下云服务提供商除外）。网络会丢弃所有其他流量。由于整个网络本身就是最小权限和默认拒绝的，这就消除了对传统 DMZ 或网络区域等架构的需求。

让我们用一个例子把这一点讲得更具体些。您可以创建一个传统的三层应用程序堆栈，前端是面向公网的应用程序负载均衡器，后端是位于私有子网中、只接受来自负载均衡器流量的 Web 服务器。Web 服务器只能连接到接受其连接的应用程序服务器。同样，应用程序服务器只能向允许此类连接的数据库发送流量。每一层都是默认拒绝的，只允许来自负载均衡器的入站连接和到数据库的出站连接。在许多情况下，除了公共负载均衡器（由云服务提供商维护的高度安全的 PaaS 架构）之外，您无需任何 Internet 连接（在私有子网中）即可实现这一点。

您不是先构建网络再把应用程序放进去，而是先设计应用程序，然后让网络适配应用程序的需求。这会大幅减少应用程序堆栈的攻击面，并相应降低您的风险。

我们在构建 securosis.com 站点时就运用了这些原则，您可以在下面的架构图中看到。如果我们以网络安全的视角审视该设计，可以看到：

• 访问受到云 WAF 的限制，因此只有干净的流量才会进入 VPC。
• 应用程序负载均衡器（ALB）是面向公网子网中唯一的资源，且只允许 80/443 流量。
• 所有实例都位于私有子网中，且只接受来自 ALB 的流量。
• “admin”实例接受登录，但仅限来自托管在不同环境中的 VPN。
• 图中未显示 RDS 数据库的子网，它们同样仅为私有，且只接受来自实例的流量。如果需要任何直接登录或用于数据整理的 RDBMS 访问，则会修改安全组规则以提供临时访问。
• 与 S3 的连接通过服务终端节点建立，从而无需使用 NAT 网关进行 Internet 访问。
• 非管理实例上已禁用 SSH。这些实例是自动扩缩且不可变的，只能通过更改基础镜像来修改。
• 不存在自引用安全组（允许内部访问的安全组），以防止横向攻击。AWS 中的安全组在资源级别而非子网级别生效，这对于阻止东西向攻击非常有效。
• 这种架构大幅减少了整体攻击面。网络只允许最低限度的必要连接，也只包含允许访问所需的最少子网和路由表。我们实质上是让网络适配了应用程序。事实上，网络是在应用程序堆栈完成架构设计之后才设计的。
• 这是一个非常简单的小型站点示例，但这些原则同样适用于层级更多、包含内部负载均衡器、API 网关和 PaaS 组件的大得多的架构。

如您所见，使用云网络架构可以获得极大的灵活性。您终于能够构建应用程序所需的网络，而不必让应用程序去适应您现有的网络。但伴随这种灵活性而来的，是配置错误并将大片基础设施暴露给公共 Internet 的可能性。因此，我们始终建议您监控自身的云安全态势，并借助云安全运营平台（例如 DisruptOps 提供的平台）落实最佳实践。