我见过这个场景太多次了。应用程序已经完成。演示很棒。然后安全清单出现了：将存储从公共互联网移除、在 VNet 内运行、为合作伙伴允许列表提供出站 IP、证明只有正确的子网与正确的服务通信。
此时应用程序模型和基础设施模型开始以令人痛苦的方式分离。
Aspire 新的 Azure 企业网络支持直接解决了这个问题。你在 AppHost 中将网络形态描述在使用它的资源旁边。
构建块
每个 Azure 网络概念的用途，提炼如下：
| 功能 | 使用时机 | 为何重要 |
|---|---|---|
| 虚拟网络 | 需要私有地址空间时 | 子网、私有端点和路由的网络边界 |
| 子网 | 需要在 VNet 内分离工作负载时 | 系统的每个部分获得自己的地址范围和策略面 |
| 委托子网 | 平台服务（如 ACA）需要管理子网时 | 允许服务安全地在 VNet 中放置受管基础设施 |
| NAT 网关 | 需要可预测的出站公共 IP 时 | 用于允许列表和审计的稳定地址 |
| 私有端点 | 希望 PaaS 资源可私密访问时 | 在 VNet 内放置该服务的私有 IP，消除公共暴露 |
| NSG | 需要子网级流量规则时 | 每个子网的入站和出站流量显式允许/拒绝 |
在 AppHost 中描述它
这里的关键转变是你将网络与使用它的资源一起建模，而不是在随时间与应用模型产生偏离的单独 Bicep 文件中。
从 AppHost，你可以：
- 使用
AddVirtualNetwork()和AddSubnet()创建 VNet 和子网 - 为子网附加 NAT 网关以获得稳定的出站 IP
- 为存储、Key Vault、SQL 和其他 PaaS 服务创建私有端点
- 使用入站和出站安全规则定义 NSG
- 配置网络安全边界以实现跨资源策略
结果是当你运行 azd up 时，基础设施与应用模型所说需要的内容相匹配。而不是手动维护的模板所说的。
为何对实际应用程序重要
一旦在 Aspire 中建模了网络，一些事情就会变得容易很多：
Key Vault 和存储的私有端点 — 你在这些资源上描述 WithPrivateEndpoint()，Aspire 处理 DNS 区域配置和端点附加。应用程序永远不会改变。
一致的出站 IP — 向相关子网添加 NAT 网关，应用程序的每个出站请求都通过一个已知的稳定 IP。合作伙伴可以将其加入允许列表。审计人员可以追踪它。
代码中的 NSG 规则 — 不再需要在门户中点击或维护 Bicep 代码段，你的安全规则与它们保护的资源一起存在于 AppHost 中。
这是不会让演示令人兴奋但会让生产系统可维护的集成类型。
总结
如果从一开始就与应用程序一起建模，网络安全在项目生命周期后期出现是一个已解决的问题。Aspire 的企业网络支持使这成为可能，而无需单独的基础设施轨道。
完整详情请参阅原始文章：Securing Azure apps with Aspire enterprise networking
