Azure 登陆区域中的 Azure 虚拟机基线体系结构

本文中的体系结构扩展了虚拟机 (VM) 基线体系结构 ，以解决在 Azure 登陆区域中部署虚拟机时的变化和期望。

在本文中的示例中，某组织希望基于 VM 的工作负荷使用平台团队集中管理的联合资源。 这些资源包括用于跨界连接的网络资源、身份访问管理和策略。 此示例假定组织采用 Azure 登陆区域，以便在多个工作负荷之间强制实施一致的治理和成本效益。

作为工作负荷所有者，你可以通过将共享资源的管理转移给中心团队，这样你就可以专注于工作负荷开发工作。 本文将从工作负荷团队的角度进行阐述。 具体说明了针对平台团队的建议。

文章布局

体系结构	设计决策	Azure Well-Architected Framework 方法
▪ 体系结构图 ▪ 工作负荷资源 ▪ 联合资源	▪ 订阅设置 ▪ 网络要求 ▪ 网络设计与基线相比的变化 ▪ 监视 ▪ 补丁合规性 ▪ 组织治理 ▪ 变更管理	▪ 可靠性 ▪ 安全性 ▪ 成本优化

体系结构

下载此体系结构的 Visio 文件。

组件

所有 Azure 登陆区域体系结构都会将平台团队和工作负荷团队之间的所有权分离。 应用程序架构师和 DevOps 团队需要充分了解这种责任划分，以便了解哪些属于他们的直接影响或控制范围，哪些不属于。

工作负荷团队拥有的资源

以下资源与基线体系结构基本保持不变。

• Azure 虚拟机是应用程序平台。 计算资源分布在各个可用性区域。

• Azure 负载均衡器用于对从前端 VM 到后端 VM 的流量进行专用负载均衡。 负载均衡器会将流量分发到各个区域的 VM。

• Azure 应用程序网关被用作反向代理，以便将用户请求路由到前端 VM。 所选 SKU 还用于托管 Azure Web 应用程序防火墙，以保护前端 VM 免受潜在恶意流量的影响。

• Azure Key Vault 用于存储应用程序机密和证书。

• Azure Monitor、Log Analytics 和 Application Insights 被用于收集、存储和可视化可观测性数据。

• Azure Policy 被用于应用特定于工作负荷的策略。

工作负荷团队会维护并履行以下资源和职责。

• 被放在这些子网上的分支虚拟网络子网和网络安全组 (NSG)，用于维护分段和控制流量流。

• 专用终结点，用于保护与平台即服务 (PaaS) 解决方案以及这些终结点所需的专用 DNS 区域的连接的安全。

• Azure 托管磁盘会在后端服务器上存储日志文件，即使 VM 重新启动，数据也会被保留。 前端服务器连接了可用于部署无状态应用程序的磁盘。

平台团队拥有的资源

平台团队拥有和维护这些集中资源。 此体系结构假定这些资源已预先预配，并将它们视为依赖项。

• 中心网络中的 Azure 防火墙用于检查和限制出口流量。 此组件取代了基线体系结构中的标准负载均衡器，后者不限制向 Internet 的出站流量。

• 中心网络中的 Azure Bastion 提供对工作负荷 VM 的安全操作访问。 在基线体系结构中，工作负荷团队拥有此组件。

• 分支虚拟网络是部署工作负荷的位置。

• 用户定义的路由 (UDR) 用于与中心网络强制建立隧道连接。

• 基于 Azure Policy 的治理约束和DeployIfNotExists (DINE) 策略是工作负荷订阅的一部分。

订阅设置

在登陆区域的情况中，工作负荷团队必须通知平台团队其特定要求。

工作负荷团队必须包含有关工作负荷所需的网络空间的详细信息，以便平台团队可以分配必要的资源。 你的团队会确定要求，而平台团队会确定在虚拟网络中分配的 IP 地址以及要向其分配订阅的管理组。

平台团队会根据工作负荷的业务关键性和技术要求分配适当的管理组，例如，工作负荷是否向 Internet 公开。 组织会确定这些管理组的配置，而平台团队会负责实现。

例如，基线体系结构的应用程序方案中的管理组就在考虑之列：

• 专用应用程序，例如内部业务线应用程序或现成商业（一线）解决方案，这些解决方案通常都位于 Azure 登陆区域的 Corp 管理组下。

• 公共应用程序，与面向 Internet 的应用程序一样，这些应用程序通常位于 Corp 或 Online 管理组下。

平台团队还负责为工作负荷部署设置一个或一组订阅。

以下各节将提供有关初始订阅设置的指导。 但是，平台团队通常会对集中式服务进行更改，以解决错过或更改的要求。 平台更改对所有工作负荷团队都会产生更广泛的影响。

因此，平台团队必须确保所有 VM 工作负荷都为任何更改做好准备，并且必须了解基于 VM 的解决方案的生命周期以及测试周期。 有关更多信息，请参阅管理随时间推移的更改。

工作负荷要求和履行

工作负荷团队和平台团队共同承担两个主要职责：管理组分配和网络设置。 对于此体系结构，请考虑向平台团队传达以下网络要求。 以这些要点为例，了解在实现类似体系结构时两个团队之间的讨论和协商。

• 分支虚拟网络的数量：在此体系结构中，只需要一个专用分支。 部署的资源无需跨越多个网络，而是集中在一个虚拟网络内。

• 分支网络的大小：考虑工作负荷的操作要求和预期增长。 例如，如果计划实现蓝/绿或金丝雀更新，则最大大小应考虑到并行部署所需的空间。

  将来的更改可能需要更多的 IP 空间，这可能与当前的分配不一致。 这些空间的集成可能会带来额外的复杂性。 主动提前申请足够的网络资源，以确保分配的空间能够满足未来扩展的需要。

• 部署区域：必须指定将部署工作负荷的区域。 平台团队可以使用此信息来确保在同一区域中预配分支和中心虚拟网络。 跨越不同区域的网络可能会因流量跨越地区边界而导致延迟问题，还会产生额外的带宽成本。

• 工作负荷特征和设计选择：将设计选择、组件和特征传达给平台团队。 例如，如果希望工作负荷生成大量与 Internet 的并发连接（琐碎），平台团队应确保有足够的端口可用于防止耗尽。 他们可以将 IP 地址添加到集中式防火墙以支持流量，或设置网络地址转换 (NAT) 网关，以通过备用路径来路由流量。

  相反，如果希望工作负荷生成最少的网络流量（背景噪音），平台团队就应该在整个组织中高效地使用资源。

  平台团队需要清楚地了解任何依赖项。 例如，工作负荷可能需要访问另一个团队拥有的数据库，或者工作负荷可能具有跨界流量。 工作负荷是否在 Azure 外部存在依赖项？ 这些信息对于平台团队来说非常重要。

• 防火墙配置：平台团队必须留意离开分支网络并通过隧道发送到中心网络的的流量。 中心的防火墙无法阻止该流量。

  例如，如果工作负荷需要访问 Windows 更新以保持修补状态，防火墙就不应阻止这些更新。 同样，如果有访问特定终结点的 Monitor 代理，则防火墙不应阻止该流量，因为它可能会中断工作负荷的监视数据。 应用程序可能需要访问第三方终结点。 不管怎样，请使用集中式防火墙来区分预期流量和不必要的流量。

• 操作员访问权限：如果操作员使用 Microsoft Entra ID 安全组通过 Azure Bastion 访问 VM，请通知平台团队。 Azure Bastion 是典型的中心资源。 确保安全组和 VM 支持安全协议至关重要。

  此外，告知平台团队包含 VM 的 IP 范围。 在中心网络中配置 Azure Bastion 周围的 NSG 时必须提供此信息。

• 公共 IP：告知平台团队入口流量配置文件，包括任何预期的公共 IP 地址。 在此体系结构中，只有 Internet 源流量才以应用程序网关上的公共 IP 为目标。 平台团队应告知工作负荷团队这些 IP 是否在 Azure DDoS 保护计划下，或者是否由工作负荷团队负责。

  在此体系结构中，还有一个公共 IP 用于通过 Azure Bastion 进行操作访问。 平台团队拥有此公共 IP，并将其注册到一项服务中，如平台团队也负责管理的 DDoS 防护。

VM 设计选择

VM SKU 和磁盘选择与基线体系结构相同。

组织可能会对工作负荷团队提出合规性要求，规定必须使用特定 VM 映像。 鉴于此类要求，平台团队可以管理一组通常被称为黄金映像的标准化映像，创建后可供整个组织内使用。

平台团队可以使用托管产品/服务（例如 Azure 计算库或专用存储库）来存储经批准的 OS 映像或工作负荷项目。 为 VM 选择 OS 映像时，请咨询平台团队，了解有关映像源、更新频率和使用情况预期的信息。 此外，还要确保映像可以满足工作负荷满足的必要业务要求。

网络

在基线体系结构中，工作负荷在单个虚拟网络中预配。 工作负荷团队负责管理虚拟网络。

在此体系结构中，平台团队将确定网络拓扑。 在此体系结构中假定中心辐射型拓扑。

下载此体系结构的 Visio 文件。

• 中心虚拟网络：区域中心包含与同一区域中的工作负荷资源通信的集中式服务。 有关详细信息，请参阅平台团队拥有的资源。 建议将中心置于连接订阅中。

• 分支虚拟网络：在此体系结构中，基线体系结构中的单个虚拟网络是分支网络。 它与中心网络对等互连，其中包含集中式服务。 平台团队拥有并管理此分支网络。 此网络包含工作负荷资源。 工作负荷团队拥有此网络中的资源，包括其子网。

请确保传达工作负荷要求给平台团队，并定期回顾它们。

虚拟网络子网

在分支虚拟网络中，工作负荷团队将创建并分配子网。 设置控制来限制进出子网的流量有助于提供分段。 此体系结构使用与基线体系结构相同的子网拓扑，为应用程序网关、前端 VM、负载均衡器、后端 VM 和专用终结点提供专用子网。

在 Azure 登陆区域中部署工作负荷时，仍需实现网络控制。 组织可能会施加限制，以防止数据外泄，并确保中心安全运营中心 (SOC) 和 IT 网络团队的可见性。

通过此方法，平台团队可以使用集中式服务来优化整体组织支出，而不是在整个组织中为每个工作负荷部署冗余安全控制。 在此体系结构中，Azure 防火墙是中央服务的一个示例。 对于每个工作负荷团队来说，管理自己的防火墙实例既不划算也不现实。 建议采用集中式防火墙管理方法。

入口流量

入口流量流与基线体系结构相同。

工作负荷所有者负责与公共 Internet 流入工作负荷相关的任何资源。 例如，在此体系结构中，应用程序网关及其公共 IP 位于在分支网络中，而不是中心网络中。 某些组织可能会使用集中式非管制 (DMZ) 实现将入口流量的资源置于连接订阅中。 与该特定拓扑的集成不在本文讨论范围之内。

出口流量

在基线体系结构中，工作负荷虚拟机规模集通过Azure 负载均衡器来访问公共 Internet，但该流量不受限制。

这种设计在此体系结构中有所不同。 所有离开分支虚拟网络的流量都会通过出口防火墙经由对等中心网络进行路由。 路由连接到分支网络中所有可能的子网，该子网将本地虚拟网络 (0.0.0.0.0/0) 中未找到的 IP 的所有流量定向到中心的 Azure 防火墙。

下载此体系结构的 Visio 文件。

为访问密钥库而与专用终结点进行的工作负荷通信与基线体系结构相同。 为简洁起见，上图省略了这一路径。

工作负荷团队必须识别、记录和传达基础结构和工作负荷操作所需的所有出站流量流。 平台团队允许所需的流量，而所有未通信的出口流量都可能会被拒绝。

控制出口流量不仅仅是确保允许预期的流量。 它还要确保只允许预期流量。 默认情况下，未通信的出口流量可能会被拒绝，但它符合工作负荷的最佳安全利益，以确保流量正确路由。

向平台团队传达任何唯一的出口流量要求。 例如，如果工作负荷与外部网络终结点建立了多个并发连接，请通知平台团队。 然后，平台团队可以在区域防火墙上预配适当的 Azure NAT 网关实现，或添加更多公共 IP 以加以缓解。

你的组织可能要求不鼓励使用体系结构模式，即使用工作负荷拥有的公共 IP 作为出口。 在这种情况下，可以使用 Azure Policy 来拒绝 VM 网络接口卡 (NIC) 上的公共 IP 和任何其他公共 IP，而不是已知的入口点。

专用 DNS 区域

使用专用终结点的体系结构需要专用 DNS 区域才能与 DNS 提供程序配合使用。 工作负荷团队必须清楚地了解平台团队提供的订阅中专用 DNS 区域的要求和管理。 专用 DNS 区域通常使用 DINE 策略进行大规模管理，这使得 Azure 防火墙能够充当可靠的 DNS 代理并支持完全限定的域名 (FQDN) 网络规则。

在此体系结构中，平台团队确保为专用链接终结点提供可靠的专用 DNS 解析。 与平台团队协作，了解他们的期望。

连接测试

对于基于 VM 的体系结构，有几个测试工具可帮助确定网络视线、路由和 DNS 问题。 可以使用传统的故障排除工具，例如 netstat、nslookup 或 tcping。 此外，还可以检查网络适配器的动态主机配置协议 (DHCP) 和 DNS 设置。 如果有 NIC，则故障排除功能更强，可以使用 Azure 网络观察程序来执行连接检查。

操作员访问权限

与基线体系结构一样，此体系结构支持通过 Azure Bastion 进行操作访问。

但是，基线体系结构将 Azure Bastion 部署为工作负荷的一部分。 对于采用 Azure 登陆区域的典型组织而言，他们将 Azure Bastion 部署为每个区域的中央资源。 平台团队拥有和维护 Azure Bastion，组织中的所有工作负荷都会共享它。 为了演示此体系结构中的用例，Azure Bastion 位于连接订阅的中心网络中。

操作员身份

此体系结构使用与基线体系结构相同的身份验证扩展。

始终坚持最小权限原则，对任务进行精细访问而不是长期访问。 在登陆区域上下文中，利用平台团队管理的实时 (JIT) 支持。

补丁合规性和 OS 升级

基线体系结构描述了修补和升级的自主方法。 当工作负荷与登陆区域集成时，这种方法可能会改变。 平台团队可能会决定修补操作，以便所有工作负荷都符合组织要求。

确保修补过程包括添加到体系结构的所有组件。 例如，如果选择添加生成代理 VM 来自动部署、缩放和管理应用程序，则这些 VM 必须符合平台要求。

监视

Azure 登陆区域平台在管理订阅中提供共享的可观测性资源。 但是，我们建议预配自己的监视资源，以促进工作负荷的所有权责任。 此方法与基线体系结构一致。

工作负荷团队预配监视资源，其中包括：

• Application Insights 作为工作负荷团队的应用程序性能监视 (APM) 服务。

• Log Analytics 工作区是所有日志和指标的统一接收器，这些日志和指标是从工作负荷拥有的 Azure 资源和应用程序代码中收集的。

下载此体系结构的 Visio 文件。

与基线类似，所有资源都被配置为将 Azure 诊断日志发送到 Log Analytics 工作区，工作负荷团队将该工作区作为基础结构 (IaC) 部署资源的一部分进行预配。 可能还需要将日志发送到中央 Log Analytics 工作区。 在 Azure 登陆区域中，该工作区位于管理订阅中。

平台团队可能也有 DINE 策略，可用于配置诊断，以便将日志发送到其集中式管理订阅。 请务必确保实现不会限制其他日志流。

关联来自多个接收器的数据

工作负荷的日志和指标及其基础结构组件存储在工作负荷的 Log Analytics 工作区中。 但是，Azure 防火墙、Microsoft Entra ID 和 Azure Bastion 等集中式服务生成的日志和指标都存储在中央 Log Analytics 工作区中。 关联来自多个接收器的数据可能是一项复杂的任务。

相关数据通常在事件响应期间使用。 如果在关联多个接收器中的数据时出现问题，请确保此体系结构的会审 Runbook 可以解决该问题，并在问题超出工作负荷资源时包括组织联系点。 工作负荷管理员可能需要平台管理员的帮助来关联来自企业网络、安全或其他平台服务的日志条目。

Azure Policy

平台团队可能会应用影响工作负荷部署的策略。 他们通常会应用 DINE 策略来处理自动部署到应用程序登陆区域订阅中的问题。 DINE 策略可以修改工作负荷资源或将资源添加到部署，这可能会导致通过工作负荷模板以声明方式部署的资源与处理请求实际使用的资源之间存在差异。 典型的解决方案是使用命令性方法来修复这些更改，但这种方法并不理想。

为了避免这种差异，应预先将将平台发起的更改纳入 IaC 模板中并进行测试。 如果平台团队使用的 Azure 策略与应用程序的要求冲突，则可以与平台团队协商解决方案。

管理随时间推移的变化

在此体系结构中，平台提供的服务和操作被视为外部依赖项。 平台团队继续应用更改、载入用户并应用成本控制。 为组织提供服务的平台团队可能无法确定单个工作负荷的优先级。 这些依赖项的更改（无论是金映像更改、防火墙修改、自动修补或规则更改）都可能会影响多个工作负荷。

因此，工作负荷和平台团队必须高效及时地进行沟通，以管理所有外部依赖项。 测试更改非常重要，这样才不会对工作负荷产生负面影响。

影响工作负荷的平台更改

在此体系结构中，平台团队会管理以下资源。 对这些资源的更改可能会影响工作负荷的可靠性、安全性、操作和性能目标。 重要的是，要在平台团队将这些更改付诸实施之前对其进行评估，以确定它们对工作负荷的影响。

• Azure 策略：对 Azure 策略的更改可能会影响工作负荷资源及其依赖项。 例如，可能会直接更改策略或将登陆区域移动到新的管理组层次结构中。 在进行新的部署之前，这些更改可能不会被注意到，因此对它们进行彻底测试非常重要。

• 防火墙规则：对防火墙规则的修改可能会影响工作负荷的虚拟网络或应用于所有流量的规则。 这些修改可能会导致流量被阻止，甚至出现无提示进程故障，例如 OS 修补程序应用失败。 这些潜在问题既适用于出口 Azure 防火墙，也适用于 Azure 虚拟网络管理器应用的 NSG 规则。

• 共享资源：对共享资源的 SKU 或功能的更改可能会影响工作负荷。

• 中心网络的路由：如果工作负荷依赖于到其他虚拟网络的路由，中心内路由的可传递性变化可能会影响工作负荷的功能。

• Azure Bastion 主机：对 Azure Bastion 主机可用性或配置的更改可能会影响工作负荷的操作。 确保跳转盒访问模式更改具有有效的日常、临时和紧急访问。

• 所有权更改：向工作负荷团队传达所有权和联系点的任何更改，因为这些更改可能会影响工作负荷的管理和支持请求。

影响平台的工作负荷更改

以下示例是此体系结构中应向平台团队传达的工作负荷更改。 平台团队必须在新的工作负荷团队更改生效之前，根据这些更改来验证平台服务的可靠性、安全性、操作和性能目标。

• 网络出口：监视网络出口量的任何显著增加，以防止工作负荷成为网络设备上的干扰邻居。 此问题可能会影响其他工作负荷的性能或可靠性目标。

• 公共访问：对工作负荷组件的公共访问更改可能需要进一步测试。 平台团队可能会将工作负荷重新定位到其他管理组。

• 业务关键性评级：如果工作负荷的服务级别协议 (SLA) 发生了更改，则可能需要平台和工作负荷团队之间采用新的协作方法。

• 所有权更改：向平台团队传达所有权和联系点更改。

工作负荷业务需求更改

为了维护工作负荷的服务级别目标 (SLO)，平台团队可能需要参与工作负荷体系结构更改。 这些更改可能需要平台团队进行更改管理，或者验证现有治理是否支持更改后的要求。

例如，将更改传达给以前不允许的任何出口流，以便平台团队可以在防火墙、虚拟网络管理器或其他组件中添加该流，以支持所需的流量。 相反，如果不再需要以前允许的出口流，平台团队应阻止该流，以便维护工作负荷的安全性。 还可以传达对到其他虚拟网络或跨界终结点的路由的更改，或对体系结构组件的更改。 每个资源都受策略和潜在出口防火墙控制的约束。

可靠性

此体系结构与基线体系结构中的可靠性保证相一致。

可靠性目标

由于出口网络控制等组件的存在，最大复合 SLO 可能低于基线复合 SLO。 这些组件在登陆区域环境中很常见，并非此体系结构所独有的。 如果工作负荷团队直接控制这些 Azure 服务，SLO 同样会减少。

尽管最大可能的 SLO 较低，但可靠性的关键在于跨职能团队的工作负荷组件的划分。 通过这种方法，工作负荷团队可从专门的团队中受益，该团队将专注于运行此工作负荷和其他工作负荷所使用的关键基础结构。

有关详细信息，请参阅有关定义可靠性目标的建议。

关键依赖项

将工作负荷在平台和应用程序登陆区域中执行的所有功能视作依赖项。 事件响应计划要求工作负荷团队了解这些依赖项的联系点和联系方法信息。 此外，还应在工作负荷的故障模式分析 (FMA) 中包含这些依赖项。

对于此体系结构，请考虑以下依赖项：

• 出口防火墙：由多个工作负荷共享的集中式出口防火墙将发生与工作负荷无关的更改。

• 网络端口耗尽：共享网络设备的所有工作负荷的使用量峰值可能导致网络饱和或出口防火墙上的端口耗尽。

• DINE 策略：Azure DNS 专用 DNS 区域（或任何其他平台提供的依赖项）的 DINE 策略会尽最大努力，而无需执行 SLA。 DNS 配置的延迟可能会导致应用程序处理流量的就绪延迟。

• 管理组策略：不同环境下的策略保持一致是可靠性的关键。 确保预生产环境与生产环境类似，以提供准确的测试，并防止可能阻止部署或缩放的环境特定偏差。 有关详细信息，请参阅管理 Azure 登陆区域中的应用程序开发环境。

其中许多注意事项可能在没有 Azure 登陆区域的情况下存在，但工作负荷和平台团队需要协作解决这些问题，以确保满足需求。

有关详细信息，请参阅执行失败模式分析的建议。

安全性

此体系结构的安全注意事项与基线体系结构相同。 以下各节中的建议基于架构良好的框架中的安全设计评审检查列表。

网络控制措施

正确配置网络控制以确保工作负荷安全。

入口流量

可以通过子网上的 NSG 或区域中心内的不可传递性质或控制，将工作负荷与组织内的其他工作负荷分支隔离开来。 构建仅允许应用程序及其基础结构的入站网络要求的全面 NSG。 我们建议不要只依赖中心网络的非传输性质来确保安全性。

平台团队可能会实施 Azure 策略，以确保应用程序网关将 Web 应用程序防火墙设置为拒绝模式，从而限制订阅可用的公共 IP 数和其他检查。 除了这些策略，工作负荷团队还应负责部署以工作负荷为中心的策略，以增强入口安全态势。

下表显示了此体系结构中的入口控制示例。

Source	目的	工作负荷控制	平台控制
Internet	用户流量	在允许公共流量转换到进入前端 VM 的专用流量之前，通过 NSG、Web 应用程序防火墙和路由规则传递所有请求	无
Azure Bastion	操作员访问 VM	VM 子网上的 NSG 会阻止进入远程访问端口的所有流量，除非它们源自平台的指定 Azure Bastion 子网	无
其他分支	无	通过 NSG 规则阻止	在 Azure 虚拟 WAN 安全中心情况下的不可传递路由或 Azure 防火墙规则

出口流量

应用 NSG 规则来表达解决方案所需的出站连接要求并拒绝其他所有要求。 不要只依赖于中心网络控制。 作为工作负荷操作员，你有责任在尽可能靠近源的地方阻止不受欢迎的出口流量。

请注意，虽然你在虚拟网络中设置了子网，但作为订阅自动售货过程的一部分，平台团队可能会创建防火墙规则来专门表示你的捕获要求。 确保体系结构生命周期内子网和资源位置的更改仍与原始请求相一致。 或者，你也可以与网络团队合作，确保最低访问权限出口控制的连续性。

下表显示了此体系结构中的出口示例。

终结点	目的	工作负荷 (NSG) 控制	平台（中心）控制
ntp.ubuntu.com	Linux VM 的网络时间协议 (NTP)	通过 UDP/123 连接前端 VM 子网上的 Internet（出口防火墙缩小了这一广泛的开放范围）	与工作负荷控制相同的防火墙网络规则限额
Windows 更新终结点	Microsoft 服务器的 Windows 更新功能	通过 TCP/443 和 TCP/80 连接后端 VM 子网的 Internet（出口防火墙缩小了这一广泛的开放范围）	包含 WindowsUpdate FQDN 标记的防火墙限额规则
监视代理终结点	VM 上的 Monitor 扩展所需的流量	通过 TCP/443 连接两个 VM 子网上的 Internet（出口防火墙缩小了这一广泛的开放范围）	TCP/443 上所有特定 FQDN 的必要防火墙应用程序规则限额
nginx.org	直接从供应商安装 Nginx（示例应用程序组件）	通过 TCP/443 连接前端 VM 子网上的 Internet（出口防火墙缩小了这一广泛的开放范围）	TCP/443 上 nginx.org 的必要防火墙应用程序规则限额
密钥保管库	在应用程序网关和 VM 中导入（传输层安全性）TLS 证书	从两个 VM 子网到专用终结点子网的 - TCP/443 连接 从应用程序网关子网到专用终结点子网的 - TCP/443 连接 从标记了所需的应用程序安全组 (ASG) 名称和应用程序网关子网的虚拟机的 - TCP/443 连接	无

DDoS 保护

确定负责应用 DDoS 防护计划以涵盖所有解决方案公共 IP 的人员。 平台团队可能会使用 IP 保护计划，甚至可能使用 Azure Policy 来强制实施虚拟网络保护计划。 此体系结构应具有覆盖范围，因为它涉及来自 Internet 的入口的公共 IP。

有关详细信息，请参阅关于网络和连接的建议。

机密管理

对于机密管理，此体系结构遵循基线体系结构。

作为工作负荷团队，请继续将机密保留在密钥保管库实例中。 根据需要部署更多实例，为应用程序和基础结构操作提供支持。

有关详细信息，请参阅保护应用程序机密的建议。

成本优化

对于工作负荷资源，基线体系结构中的成本优化策略也适用于此体系结构。

此体系结构极大地受益于 Azure 登陆区域平台资源。 即使通过退款模型使用这些资源，添加的安全性和跨界连接也比自行管理这些资源更具成本效益。

平台团队会在此体系结构中管理以下资源。 这些资源通常以消耗为基础（退款），或者可能免费提供给工作负荷团队。

• Azure 防火墙
• 安全信息和事件管理 (SIEM)
• Azure Bastion 主机
• 跨界连接，例如 ExpressRoute

利用平台团队提供的其他集中式产品/服务，将这些优势扩展到工作负荷，而不会影响其 SLO、恢复时间目标 (RTO) 或恢复点目标 (RPO)。

有关详细信息，请参阅收集和查看成本数据的建议。

部署此方案

GitHub 中提供了此参考体系结构的部署。

下一步

查看工作负荷团队与平台团队之间共享的协作和技术详细信息。

订阅销售