Azure 架构良好的框架是一套指导原则，可用于通过卓越体系结构的质量支柱来评估解决方案：
本文结束了这个系列。 阅读简介。
该系列中提供的本指南将“架构良好”原则纳入所有设计选择。 本文总结了这些选择。 GitHub：适用于受管制工作负载的 Azure Kubernetes 服务 (AKS) 基线群集实施演示了这些原则（如果适用）。
PCI DSS 3.2.1 工作负载对怎样才算是架构良好的解决方案有严格的要求。 尽管使基础结构与 PCI 要求保持一致至关重要，但符合性并不止于托管基础结构。 不解决质量支柱问题（特别是安全性）可能会危及符合性。 架构良好的解决方案将基础结构与工作负载荷观点相结合，以达到实现合规结果所需的严格性。
安全性
请遵循安全设计原则中提供的基本指南。 这些章节汇总了适用于受管制环境的最佳做法。
调控
治理实施由 PCI-DSS 3.2.1 中的符合性要求驱动。 这会影响有关维护分段、访问资源、检测漏洞以及（最重要的）保护客户数据的技术控制。
企业分段策略
为了保持完全隔离，我们建议在独立订阅中部署受管制的基础结构。 如果为了实现符合性而需要多个订阅，请考虑将它们分组到管理组层次结构下，该层次结构在你的范围内订阅中统一应用相关的 Azure 策略。 在订阅中，在订阅级别应用相关的 Azure 策略，以捕获应当适用于持卡人数据环境 (CDE) 中所有群集的广泛策略。 在资源组级别应用相关的 Azure 策略，以捕获适用于特定群集实例的策略。 这些策略为登陆区域构建了核心防护措施。
在操作和连接方面将 PCI 工作负载（范围内）与其他（范围外）工作负载隔离开来。 可以通过部署单独的群集来创建隔离。 或者，使用分段策略来保持分离。 例如，群集使用单独的节点池，以便工作负载永远不会共享节点虚拟机 (VM)。
策略强制执行
通过启用 Azure 策略强制实施安全控制。 例如，在这种受管制的体系结构中，可以防止持卡人数据环境的错误配置。 可以应用一个不允许在 VM 节点上分配公共 IP 的 Azure 策略。 这样就会检测到此类分配，并对其进行报告或阻止。
有关可以为 AKS 启用的策略的信息，请参阅 Azure Kubernetes 服务的 Azure Policy 内置定义。
Azure 为大多数服务提供了多个内置策略。 查看这些 Azure Policy 内置策略定义，并根据需要应用它们。
符合性监视
必须系统地监视和维护符合性。 执行常规合规性证明。 了解云资源是否具有符合性有助于为证明和审计做好准备。
利用 Microsoft Defender for Cloud 中的法规符合性仪表板。 通过持续监视该仪表板，可以跟踪工作负载的符合性状态。
网络安全
在中心辐射型拓扑中，让每个实体拥有单独的虚拟网络会在网络空间中提供基本分段。 每个网络进一步划分为子网。
AKS 群集构成了 CDE 的核心。 它不应可供从公共 IP 地址访问，并且连接必须受保护。 流入和流出 CDE 的典型流可以分类为：
- 发往群集的入站流量。
- 从群集发出的出站流量。
- pod 之间的群集内流量。
为了满足受管制环境的要求，群集部署为专用群集。 在此模式下，进出公共 Internet 的流量受到限制。 即使是与 AKS 托管 Kubernetes API 服务器的通信也是专用的。 安全性通过严格的网络控制和 IP 防火墙规则进一步增强。
- 网络安全组 (NSG)，用于帮助保护网络内资源之间的通信。
- Azure 防火墙，用于筛选云资源、Internet 和本地之间的任何出站流量。
- 与 Azure Web 应用程序框架集成的 Azure 应用程序网关，用于筛选 Azure 应用程序网关拦截的来自 Internet 的所有入站流量。
- Kubernetes NetworkPolicy，用于仅允许群集内的 Pod 之间的某些路径。
- Azure 专用链接，用于连接到其他 Azure 平台即服务 (PaaS) 服务（例如 Azure Key Vault 和 Azure 容器注册表）以执行操作任务。
监视过程已就位，以便确保流量按预期流动，并且任何异常都会被检测到并予以报告。
有关网络安全的详细信息，请参阅网络分段。
数据安全
PCI-DSS 3.2.1 要求所有持卡人数据 (CHD) 永远不会被清除，无论是在传输中还是在存储中。
由于此体系结构和实施侧重于基础结构而不是工作负载，因此未演示数据管理。 下面是一些“架构良好”建议。
静态数据
数据必须通过行业标准加密算法进行加密。
- 请勿将数据存储在持卡人环境中。
- 在存储层之外进行加密。
- 仅将加密的数据写入存储介质。
- 不要将密钥存储在存储层中。
Azure 存储中的所有数据都使用强加密进行加密和解密。 首选自我管理的加密密钥。
如果需要暂时存储数据，请将相同的注意事项应用于该数据。 强烈建议启用 AKS 的主机加密功能。 可以使用内置的 Azure 策略强制加密临时数据。
选择存储技术时，探索保留功能。 确保在配置的时间过期时安全地删除所有数据。
该标准还要求不存储敏感的身份验证数据 (SAD)。 请确保数据未在日志、文件名、缓存和其他数据中公开。
传输中的数据
与 CDE 交互的实体的所有通信都必须通过加密通道进行。
- 必须只允许 HTTPS 流量流入 CDE。 在此体系结构中，Azure 应用程序网关拒绝端口 80 上的所有流量。
- 最好不要在 CDE 外部加密和解密数据。 如果要在 CDE 外部加密和解密数据，请考虑使该实体成为 CDE 的一部分。
- 在 CDE 中，使用 mTLS 在 Pod 之间提供安全通信。 可以选择为此目的实现服务网格。
- 仅允许安全密码和 TLS 1.2 或更高版本。
标识
设计访问策略时，请遵循以下安全原则：
- 从“零信任”策略开始。 根据需要设置例外。
- 授予最小特权 -- 只需足够完成任务。
- 最大程度地减少长期访问权限。
Kubernetes 基于角色的访问控制 (RBAC) 管理对 Kubernetes API 的权限。 AKS 支持这些 Kubernetes 角色。 AKS 与 Microsoft Entra ID 完全集成。 可以将 Microsoft Entra 标识分配给角色，并且还可利用其他功能。
“零信任”访问
Kubernetes RBAC、Azure RBAC 和 Azure 服务在默认情况下实施“全部拒绝”。 请谨慎替代该设置，仅允许访问那些需要它的实体。 实施“零信任”的另一个方面是禁止对群集节点的 SSH 访问。
最低特权
可以对 Azure 资源和 Pod 使用托管标识，并将其作用域限定为预期的任务。 例如，Azure 应用程序网关必须具有从 Azure Key Vault 获取机密（TLS 证书）的权限。 它不能具有修改机密的权限。
最大程度地减少长期访问权限
使用实时 Microsoft Entra 组成员身份最大程度地减少长期访问权限。 使用 Microsoft Entra ID 中的条件访问策略强化控制。 此选项支持许多用例，例如多重身份验证、将身份验证限制为由 Microsoft Entra 租户管理的设备，或阻止反常的登录尝试。
机密管理
将机密、证书、密钥和密码存储在 CDE 外部。 可以使用本机 Kubernetes 机密或托管密钥存储，例如 Azure Key Vault。 使用托管存储有助于执行机密管理任务，例如密钥轮换和证书续订。
确保对密钥存储的访问有网络和访问控制的制衡。 启用托管标识时，群集必须向 Key Vault 对自身进行身份验证才能获得访问权限。 此外，与密钥存储的连接不得通过公共 Internet。 使用专用网络，例如专用链接。
卓越运营
遵循卓越运营原则中提供的基本指导。 这些章节汇总了适用于受管制环境的最佳做法。
角色分离
对受管制环境强制执行明确的职责分离是关键。 根据工作负载的需要和与 CDE 的交互来定义角色和职责。 例如，对于与群集和从属服务相关的操作，可能需要基础结构操作员或站点可靠性工程师 (SRE) 角色。 该角色负责维护安全性、隔离、部署和可观测性。 将这些定义正式化并确定那些角色所需的权限。 例如，SRE 对群集访问具有很高的特权，但需要对工作负载命名空间的读取访问权限。
工作负荷隔离
PCI-DSS 3.2.1 要求在操作方面将 PCI 工作负载与其他工作负载隔离。 在此实现中，范围内和范围外的工作负载将分割到两个不同的用户节点池中。 范围内工作负载的应用程序开发人员和范围外工作负载的开发人员可能具有不同的权限集。 此外，还将有不同的质量要求。 例如，范围内代码必须支持符合性和证明，而范围外代码则不需要。 还需要有不同的生成管道和发布管理过程。
操作元数据
PCI DSS 3.2.1 标准的“要求 12”要求你维护有关工作负载清单和人员访问文档的信息。 强烈建议使用 Azure 标记，因为你可以将环境信息与 Azure 资源、资源组和订阅进行核对。
维护有关作为基础结构和工作负载一部分的已批准解决方案的信息。 这包括你选择引入到 CDE 的 VM 映像、数据库和第三方解决方案的列表。 甚至可以通过生成一个服务目录来自动执行此过程。 它通过在遵循持续平台操作的特定配置中使用那些已批准的解决方案来提供自助式部署。
可观察性
为满足要求 10，对 CDE 的可观察性对于合规性至关重要。 活动日志提供有关与帐户和机密管理、诊断设置管理、服务器管理相关的操作以及其他资源访问操作的信息。 所有日志都记录有日期、时间、标识和其他详细信息。 通过在 Azure Monitor 日志中配置数据保留和存档策略，将日志保留长达一年。
确保日志只能由需要日志的角色访问。 Log Analytics 和 Microsoft Sentinel 支持各种基于角色的访问控制，以便管理审核线索访问。
响应和修正
Azure 监视服务、Azure Monitor 和 Microsoft Defender for Cloud 可以在检测到异常活动时生成通知或警报。 这些警报包含上下文信息，如严重性、状态和活动时间。 生成警报时，制定修正策略并查看进度。 建议将数据集中到安全信息和事件管理 (SIEM) 解决方案中，因为集成数据可以提供丰富的警报上下文。
从 Microsoft Defender for Cloud 内的“安全警报”视图中，可以访问 Microsoft Defender for Cloud 在你的资源上检测到的所有警报。 让一个会审过程来解决该问题。 请与安全团队协作，了解如何将相关警报提供给工作负载所有者。
性能效率
遵循性能效率原则中提供的基本指导。 这些章节汇总了适用于受管制环境的最佳做法。
扩展
观察环境如何适应不断变化的需求将表明环境在高负载下的预期运行时行为。 自动缩放工作负载中的资源将最大程度地减少 CDE 中的人工交互。 额外的安全优势是始终减少攻击面。 可以利用支持“缩放为零”方法的资源来最大程度地增大优势。 例如，AKS 支持将用户节点池纵向缩减到 0。 有关详细信息，请参阅将用户节点池缩放为 0。
分区
分区是受管制工作负载性能效率的关键因素。 拥有分立组件可以清晰地定义责任并有助于精确控制，例如网络策略。 与任何分段策略类似，分区可以隔离组件并控制有关意外故障或系统泄露的冲击半径的影响。
“无共享”体系结构
“无共享”体系结构旨在消除并置的工作负载之间的争用。 此外，这还是一种消除单一故障点的策略。 在受管制的环境中，组件需要按逻辑或物理边界进行隔离。 这与“无共享”体系结构保持一致，从而带来可伸缩性优势。 此外，它还允许针对各种组件的相关安全控制措施和更严格的审核功能。
轻型框架
工作负载的复杂性难以记录和审核。 由于需要获得性能优势并符合“易于审计”法规要求，因此请力求简单。 评估超出需求的选择，因为这会增加攻击面区域以及滥用或配置不当的可能性。
可靠性
受管制环境的可靠性需要可预测，以便可以一致地解释它们以实现审核目的。 请遵循可靠性原则中提供的基本指南。 这些章节汇总了适用于受管制环境的最佳做法。
恢复目标和灾难恢复
由于受管制工作负载中处理的数据的敏感性，恢复目标和恢复点目标 (RPO) 的定义至关重要。 CHD 的可接受损失是什么？ CDE 中的恢复工作仍受标准要求的约束。 预计会出现故障，并针对那些与角色、职责和合理数据访问相关联的故障制定明确的恢复计划。 现场问题不是违反任何法规的理由。 这在完全灾难恢复的情况下尤其重要。 拥有清晰的灾难恢复文档，其中所述的步骤需符合要求且最大限度地减少意外的 CDE 或 CHD 访问。 恢复后，请务必查看恢复过程步骤，以确保未发生意外的访问。 记录这些实例的业务理由。
恢复
向体系结构添加复原和恢复策略可以防止需要临时访问 CDE。 系统应该能够在定义的 RPO 上自行恢复，而无需直接人工干预。 这样，便可避免不必要地暴露 CHD，即使是对有权进行紧急访问的个人也是如此。 恢复过程必须可审核。
解决与安全相关的风险
审查安全风险，因为它们可能是工作负载停机和数据丢失的来源。 安全方面的投资也会影响工作负载的可靠性。
操作过程
可靠性延伸到 CDE 之内和附近的所有操作过程。 将已进行了良好定义、自动化和测试的问题（如映像生成和跳转盒管理）流程纳入一个架构良好的解决方案。
成本优化
遵循成本优化原则中提供的基本指南。
由于符合性要求和严格的安全控制，因此，一个明显的代价是成本增加。 建议使用定价计算器建立初始估算值。
下面概要性地显示了此体系结构使用的主要资源的成本影响。
主要驱动因素是构成节点池和 Azure 防火墙的虚拟机规模集。 另一个参与者是 Log Analytics。 还存在与 Microsoft Defender for Cloud 相关的增量成本，具体取决于你选择的计划。
请清楚地了解服务价格的构成因素。 Azure 跟踪按流量计费的使用情况。 下面是此体系结构的 Azure 防火墙明细。
与某些资源（例如 Azure 防火墙）相关的成本可能会分散到多个业务部门和/或应用程序中。 优化成本的另一种方法可能是在组织中托管多租户群集，凭借工作负载多样性来最大程度地提高密度。 对于受管制的工作负载，我们不建议使用这种方法。 与成本优势相比，始终应优先考虑符合性和分段。
为了保持在预算限制内，控制成本的一些方法是调整 Azure 应用程序网关基础结构、设置自动缩放的实例计数并减少日志输出，只要它们仍然满足 PCI-DSS 3.2.1 要求的审计跟踪。 请始终根据设计在其他方面的折衷评估这些选择，以便满足 SLA 要求。 例如，你仍能够适当缩放以满足流量高峰需求。
创建 Azure 资源组时，请应用标记，以便可以跟踪它们来了解成本。 使用 Azure 顾问和 Microsoft 成本管理等成本管理工具来跟踪和分析成本。
考虑启用 AKS 成本分析，以便通过 Kubernetes 特定构造进行精细群集基础结构成本分配。