istio.io/content/zh/blog/2019/isolated-clusters/index.md

title	subtitle	description	publishdate	attribution	keywords	target_release
用于隔离和边界保护的多网格部署	使用网格联邦将其隔离成多个网格以实现网格间通信的独立应用程序	将需要隔离的环境部署到单独的网格中，并通过网格联邦启用网格间通信。	2019-10-02	Vadim Eisenberg (IBM)	traffic-management multicluster security gateway tls	1.3

各种合规性标准要求保护敏感数据环境。下表列出了一些重要的标准及其保护的敏感数据的类型：

标准	敏感数据类型
PCI DSS	支付卡数据
FedRAMP	联邦信息，数据和元数据
HIPAA	个人健康数据
GDPR	个人资料

PCI DSS，例如，建议将持卡人数据环境放置在和系统其它部分不同的网络上。它还需要使用 DMZ，并在公网和 DMZ 之间以及 DMZ 和内部网络之间设置防火墙。

将敏感数据环境与其他信息系统隔离可以减少合规性检查的范围并提高敏感数据的安全性。缩小范围可降低合规性检查失败的风险，并降低合规性成本，因为根据合规性要求，要检查和保护的组件较少。

通过将处理数据的应用程序各部分分离到单独的服务网格中（最好也是在单独的网络上），然后将具有不同合规性要求的网格连接到 {{< gloss "multi-mesh" >}}多网格{{< /gloss >}} 部署中，可以实现敏感数据的隔离。连接网间应用程序的过程称为 {{< gloss "mesh federation" >}}网格联邦{{< /gloss >}}。

请注意，使用网格联邦来创建多网格部署与创建 {{< gloss "multicluster" >}}多集群{{< /gloss >}} 部署非常不同，后者定义了一个由跨多个群集的服务组成的单个服务网格。与多网格不同，多群集部署不适用于需要隔离和边界保护的应用程序。

在此博客文章中，我描述了隔离和边界保护的要求，并概述了多网格部署的原理。最后，我介绍了 Istio 当前在网格联邦支持和自动化工作的状态。

隔离和边界保护

隔离和边界保护机制在 NIST 特殊出版物 800-53，修订 4，联邦信息系统和组织的安全和隐私控制，附录 F，安全控制目录，SC-7 边界保护中进行了说明。

特别是 边界保护，隔离信息系统组件 控制增强：

{{< quote >}} 组织可以隔离执行不同任务和/或业务功能的信息系统组件。这种隔离限制了系统组件之间未经授权的信息流，并且还提供了为所选组件部署更高级别的保护的机会。使用边界保护机制将系统组件分开提供了增强对单个组件的保护并更有效地控制这些组件之间的信息流的能力。这种类型的增强保护可限制网络攻击和错误带来的潜在危害。提供的分离程度取决于所选的机制。边界保护机制包括，路由器、网关和防火墙等，将系统组件分离为物理上分离的网络或子网；跨域设备将子网分离；虚拟化技术；以及使用不同的加密密钥对系统组件之间的信息流进行加密。 {{< /quote >}}

各种合规性标准隔离建议，用于处理组织其余部分的敏感数据的环境。支付卡行业（PCI）数据安全标准建议为 持卡人数据 环境实现网络隔离，并要求将此环境与 DMZ 隔离。FedRAMP 边界授权指南描述了联邦信息和数据的 授权边界，而 NIST 特别出版物 800-37，修订版 2，信息系统和组织的风险管理框架：用于安全性和隐私的系统生命周期方法 附录 G，授权边界注意事项 建议保护这样的边界：

{{< quote >}} 将系统划分为子系统（即分而治之）有助于针对性地应用控制措施，以实现足够的安全性，保护个人隐私和具有成本效益的风险管理流程。将复杂的系统划分为子系统也支持域分离和网络分段的重要安全概念，这在处理高价值资产时可能非常重要。将系统划分为子系统时，组织可以选择制定单独的子系统安全和隐私计划，也可以选择在相同的安全和隐私计划中处理系统和子系统。 信息安全和隐私体系结构在将复杂系统划分为子系统的过程中起着关键作用。这包括在子系统之间的内部边界监视和控制通信，以及选择，分配和实施满足或超过组成子系统的安全性和隐私要求的控件。 {{< /quote >}}

边界保护意味着：

• 在边界（防火墙，网关等）上设置访问控制机制
• 监视边界处的出/入流量
• 默认情况下，所有访问控制机制都必须为 deny-all
• 不要通过边界暴露私有 IP 地址
• 不要让边界外的组件影响边界内的安全性

多网格部署有助于将系统划分为具有不同安全性和合规性要求的子系统，有助于边界保护。您将每个子系统放入单独的服务网格中，最好放在单独的网络中。使用网关连接 Istio 网格。网关在每个网格的边界监视和控制跨网格流量。

多网格部署的特性

• 非统一命名。一个网格 accounts 命名空间中的 withdraw 服务可能与其他网格 accounts 命名空间中的 withdraw 服务具有不同的功能和 API。这种情况可能发生在没有统一命名空间和服务命名策略的组织中，或者当网格属于不同组织时。
• 默认不暴露任何内容。默认情况下，网格中没有任何暴露的服务，网格所有者必须明确指定要暴露的服务。
• 边界保护。流量的访问控制必须在入口网关上执行，这将阻止未经允许的流量进入网格。该要求实现了纵深防御原则，并且是某些合规性标准的一部分，例如支付卡行业（PCI）数据安全标准。
• 可能不存在共同信任。由于某些安全要求或由于网格所有者最初未计划网格联邦，可能会出现一个网格中的 Istio sidecar 不信任其他网格中的 Citadel 证书的情况。

必需通过 默认不暴露任何内容 和 边界保护 来促进合规性并提高安全性。连接不同组织的网格，或者组织不能执行统一命名，或者不能建立网格之间的公共信任，非统一命名 和 可能不存在共同信任 也是必需的。

您可能要使用的一个可选功能是 服务位置透传：使用服务的请求使用本地服务名称将请求发送到远程网格中的公开服务。消费服务忽略了以下事实：某些目的地位于远程网格中，而某些目的地是本地服务。访问使用本地服务名称是统一的，例如在 Kubernetes 中是 reviews.default.svc.cluster.local。服务位置透传 在您希望能够更改使用的服务的位置的情况下很有用，例如，某些服务从私有云迁移到公共云而无需更改应用程序代码的情况。

网格联邦目前的工作

尽管您现在已经可以使用标准 Istio 配置完成网格联邦，但是它需要编写大量 YAML 文件模板，并且容易出错。我们正在努力使网格联邦过程自动化。同时，您可以查看这些多网格部署示例，以了解生成的联邦可能包括的内容。

总结

在此博客中，我描述了使用 Istio 多网格部署对敏感数据环境进行隔离和边界保护的要求。概述了 Istio 多网格部署的原理，并报告了 Istio 中有关网格联邦的最新工作。

我很高兴在 discuss.istio.io 听到您对 {{< gloss "multi-mesh" >}}多网格{{< /gloss >}} 和 {{< gloss "multicluster" >}}多集群{{< /gloss >}} 的意见。