AWS 上的安全性和微服务架构

第 5 章 网络安全 网络安全

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在第 1 章中，我简要讨论了某些控制是如何钝化的，因为它们的目的是单方面阻止所有请求，而不试图识别请求者或请求的背景。网络控制就是钝化安全控制的一个例子。本章将专门讨论可以在 AWS 上添加的各种网络控制。

网络控制是指可在基础设施的网络层添加的任何安全控制，如开放系统互连（OSI）网络模型所确定的那样。在本章中，我将假设你对计算机网络有基本的了解。你可以通过阅读 Andrew Tanenbaum 和 David Wetherall 合著的《计算机网络》（Pearson）了解更多有关计算机网络的知识。

网络层安全基础架构无法读取或理解应用层语义。安全基础架构看到的不是（运行业务逻辑的）应用程序之间的交互，而是相互交互的网络接口，因此很难应用可纳入业务逻辑的控制。总的来说，网络安全就像一把斧头：坚实、有力，但偶尔也会钝而不准确。我绝不是在诋毁网络安全的重要性，而只是指出它需要完善，以适应应用安全规则时的任何细微差别。

如果列出应用程序中的每项服务，大致可以将这些服务分为两组。第一类称为边缘服务，允许终端用户获取或更改其集合的状态。这些服务面向互联网，因此会面临来自世界各地的威胁，而大多数内部服务可能永远都不必面对这些威胁。据说，边缘服务位于 Cloud 基础架构的公共区域。在本章中，我不会重点讨论公共区域内的服务。请放心，我将在第 6 章详细介绍这些面向公众的服务。

第二类服务只与组织内的其他服务或资源通信。我将把这些服务称为后台服务。这些服务在非公开环境中运行，为其提供了额外的保护，使其免受外部（公开）威胁。本章主要关注在这一私有区域内运行的服务。

图 5-1显示了如何将服务分为边缘服务和后台服务。

图 5-1. 在任何示例应用中，被外部消费者调用的服务都可归类为边缘服务。边缘服务位于云环境的 "公共区"，而绝大多数服务要么是根据数据行事，要么是被其他服务调用，它们可以孤立地存在于 "私有区"，并需要不同的安全考虑。

几乎每个在云中运行的应用程序都会有一些边缘服务和一些后端服务，无论该应用程序是移动应用程序、电子商务网站还是数据处理应用程序。如果您的任何服务需要访问外部软件即服务（SaaS）提供商，您或许可以将后端服务进一步分类到一个专门的桶中，在这里，它们可以以受控方式访问外部互联网，但仍然不能直接从互联网访问。

提示

根据我的经验，最好尽量减少边缘（公共区域）的业务逻辑，并尽可能将其重构到安全的私有区域。这种技术可以保护应用程序的核心功能免受互联网上普遍存在的未知威胁，使外部人员更难获得未经授权的访问。

第 1 章以上锁的门为例向大家介绍了隔离和爆炸半径的概念。从本质上讲，您希望将服务隔离成逻辑分区，这样任何一个分区的漏洞都不会影响其他服务的安全。我还提出了根据业务逻辑分割（分区）微服务域的理由。在网络层，这种基于业务逻辑的分段策略被称为微分段。

如果微分段策略产生的分区过小，就会导致服务进行过多的跨网段调用。这将导致昂贵而复杂的开销。如果微分段策略导致分区过宽，则可能无法在网络层执行您希望执行的安全规则。这使得整个练习变得毫无意义。通过本章的学习，你将知道如何做出明智的选择，确定服务之间的界限，并能够实施符合企业安全需求的正确策略。 ...