SEC05-BP01 创建网络层

根据工作负载组件的逻辑分组，按照数据敏感性和访问权限要求，将网络拓扑划分成不同的层。区分需要接受来自互联网的入站访问的组件（例如公有 Web 端点）与只需要进行内部访问的组件（例如数据库）。

期望结果：网络中的各个层是完整的深度防御安全方法的一部分，是工作负载身份验证和授权策略的有力补充。根据数据敏感性和访问权限要求进行了分层，并采用合适的流量流动和控制机制。

常见反模式：

建立此最佳实践的好处：建立网络层是限制网络中不必要路径的第一步，尤其是在需要限制去往关键系统和数据的路径的情况下。通过这种方法，未经授权的操作者更难于访问您的网络，也更难导航到网络中的其它资源。彼此分隔的网络层带来的益处包括减少了检查系统的分析范围，例如进行入侵检测或恶意软件防御时。这可以减少误报的可能性和不必要的处理开销。

在未建立这种最佳实践的情况下暴露的风险等级：高

实施指导

在设计工作负载架构时，一种常见的做法是根据组件的职责将组件分隔到不同的层中。例如，Web 应用程序可以具有表示层、应用层和数据层。在设计网络拓扑时，您可以采用类似的方法。底层网络控制措施可用于强制执行工作负载的数据访问权限要求。例如，在三层 Web 应用程序架构中，您可以将静态的表示层文件存储在 Amazon S3 中，并通过 Amazon CloudFront 等内容分发网络（CDN）来提供这些文件。应用层可以有公有端点，该端点由应用程序负载均衡器（ALB）在 Amazon VPC 公有子网（类似于非军事区，简称 DMZ）中提供服务，并将后端服务部署到私有子网中。数据层中托管数据库和共享文件系统等资源，可以与应用层的资源位于不同的私有子网中。在每个这些层的边界（CDN、公有子网、私有子网），您都可以部署控制措施，仅允许授权流量穿过这些边界。

类似于根据工作负载组件的功能用途对网络层进行建模，此时同样需要考虑所处理数据的敏感性。以 Web 应用程序为例，虽然您的所有工作负载服务可能都位于应用层内，但不同的服务会处理具有不同敏感性级别的数据。在这种情况下，根据您的控制要求，您可能需要针对不同的数据敏感性来划分应用层，例如使用多个私有子网、同一个 AWS 账户 中的不同 VPC，甚至是不同 AWS 账户 中的不同 VPC。

网络层的另一个注意事项是工作负载组件的行为一致性。仍旧以上例来说明，在应用层中，您的服务可能接受来自最终用户或外部系统集成的输入，这些输入本质上比其它服务的输入风险更大。例如文件上传、要运行的代码脚本、电子邮件扫描等。将这些服务放在各自的网络层中，可以在这些服务周围建立更可靠的隔离边界，并可以防止它们的独特行为在检查系统中产生误报提醒。

在设计过程中，请考虑使用 AWS 托管服务会对您的网络拓扑造成什么影响。探索 Amazon VPC Lattice 等服务如何有助于简化跨网络层的工作负载组件互操作性。使用 AWS Lambda 时，除非有特殊的原因，否则应将该服务部署在您的 VPC 子网中。对于限制访问互联网网关的安全策略，确定如何利用 VPC 端点和 AWS PrivateLink 来简化遵守这些策略所需的工作。

实施步骤

资源

相关最佳实践：

相关视频：

相关示例：