用于隔离和边界保护的多网格部署

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

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

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

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

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

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

隔离和边界保护

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

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

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

边界保护意味着：

• 在边界（防火墙，网关等）上设置访问控制机制
• 监视边界处的出/入流量
• 默认情况下，所有访问控制机制都必须为 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 听到您对 多网格 和 多集群 的意见。