本文概述如何使用应用服务环境部署安全应用程序。 为了限制来自 Internet 的应用程序访问，因此使用了 Azure 应用程序网关服务和 Azure Web 应用程序防火墙。 本文还提供有关使用 Azure DevOps 的应用服务环境的持续集成和持续部署 (CI/CD) 的指南。
此方案通常部署在银行和保险等行业，除了应用程序级别的安全性之外，客户还会意识到平台级别的安全性。 为了演示这些概念，我们将使用一个允许用户提交费用报告的应用程序。
可能的用例
以下用例可以考虑本方案：
- 生成一个需要额外安全性的 Azure Web 应用。
- 提供专用租户，而不是共享租户应用程序服务计划。
- 将 Azure DevOps 与内部负载均衡 (ILB) 的应用服务环境结合使用。
体系结构
下载此体系结构的 Visio 文件。
数据流
- HTTP/HTTPS 请求首先到达应用程序网关。
- 或者（图中未显示），可以为 Web 应用启用 Microsoft Entra 身份验证。 在流量首次到达应用程序网关后，系统会提示用户提供凭据以对应用程序进行身份验证。
- 用户请求流经环境的内部负载均衡器 (ILB)，后者又将流量路由到支出 Web 应用。
- 然后，用户继续创建支出报表。
- 作为创建支出报表的一部分，将调用已部署的 API 应用以检索用户的经理名称和电子邮件。
- 创建的支出报表存储在 Azure SQL 数据库中。
- 为了便于持续部署，代码将被签入到 Azure DevOps 实例中。
- 生成 VM 安装了 Azure DevOps 代理，允许生成 VM 拉取 Web 应用的位以部署到应用服务环境（因为生成 VM 部署在同一虚拟网络内的子网中）。
组件
- 应用服务环境为大规模安全运行应用程序提供了一个完全隔离的专用环境。 此外，由于应用服务环境和在其上运行的工作负载位于虚拟网络之后，它还提供了额外的安全和隔离层。 高规模和隔离的要求推动了 ILB 应用服务环境的选择。
- 此工作负载使用独立的应用程序服务定价层，因此应用程序在 Azure 数据中心的专用环境中运行，该数据中心使用更快的处理器、固态硬盘 (SSD) 存储，并且与标准版相比，内存与核心比率是其两倍。
- Azure 应用服务 Web 应用和 API 应用托管 Web 应用程序和 RESTful API。 这些应用和 API 托管在独立服务计划中，该计划还提供自动缩放、自定义域等，但位于专用层中。
- Azure 应用程序网关是一种在第 7 层运行的 Web 流量负载均衡器，可用于管理发往 Web 应用程序的流量。 它提供 SSL 卸载，这消除了托管 Web 应用 的 Web 服务器再次解密流量的额外开销。
- Web 应用程序防火墙是应用程序网关的一项功能。 在应用程序网关中启用 Web 应用程序防火墙可进一步增强安全性。 Web 应用程序防火墙使用 Open Worldwide Application Security Project (OWASP) 规则来保护 Web 应用程序免受跨站点脚本、会话劫持和 SQL 注入等攻击。
- 之所以选择 Azure SQL 数据库，是因为此应用程序中的大部分数据是关系数据，其中一些数据是文档和 Blob。
- Azure 网络在 Azure 中提供各种网络功能，网络可与 Azure 中的其他虚拟网络对等互连。 还可以通过 ExpressRoute 或站点到站点与本地数据中心建立连接。 在这种情况下，将在虚拟网络上启用服务终结点，以确保数据仅在 Azure 虚拟网络和 SQL 数据库实例之间流动。
- Azure DevOps 用于帮助团队在冲刺 (sprint) 期间进行协作，使用支持敏捷开发功能，以及创建生成和发布管道。
- 已创建 Azure 生成 VM，以便已安装的代理可以下拉相应的生成，并将 Web 应用部署到环境。
备选方法
应用服务环境可以在 Windows 上运行常规 Web 应用，或者，如本示例所示，部署在该环境中的 Web 应用都作为 Linux 容器运行。 选择了应用服务环境来托管这些单实例容器化应用程序。 有可用的替代方法 - 在设计解决方案时，请查看以下注意事项。
- Azure Service Fabric：如果你的环境主要基于 Windows，并且你的工作负载主要基于 .NET Framework，并且你不考虑重新构建到 .NET Core，请使用 Service Fabric 来支持和部署 Windows Server 容器。 此外，Service Fabric 支持 C# 或 Java 编程 API，并且为了开发本机微服务，可以在 Windows 或 Linux 上预配群集。
- Azure Kubernetes Service (AKS) 是一个开源项目和业务流程平台，更适合托管通常使用基于微服务的复杂多容器应用程序体系结构。 AKS 是一项托管 Azure 服务，可抽象出预配和配置 Kubernetes 的复杂性群集。 但是，需要对 Kubernetes 平台有大量了解才能支持和维护它，因此托管少量单实例容器化 Web 应用程序可能不是最佳选择。
可用于数据层的其他选项包括：
- Azure Cosmos DB：如果大多数数据采用非关系格式，则 Azure Cosmos DB 是一个不错的选择。 此服务提供的平台适合运行其他数据模型，例如 MongoDB、Cassandra、Graph 数据或简单的表存储。
注意事项
在 ILB 应用服务环境上处理证书时，需要注意某些事项。 需要生成一个链接到受信任根的证书，而不需要由最终存储证书的服务器生成的证书签名请求。 例如，使用 Internet Information Services (IIS) 时，第一步是从 IIS 服务器生成证书签名请求 (CSR)，然后将其发送到 SSL 证书颁发机构。
不能从应用服务环境的内部负载均衡器 (ILB) 发出 CSR。 处理此限制的方法是使用通配符过程。
通配符过程允许使用 DNS 名称所有权证明，而不是 CSR。 如果你拥有 DNS 命名空间，可以放入特殊的 DNS TXT 记录，通配符过程会检查该记录是否存在，如果找到，则知道你拥有 DNS 服务器，因为你拥有正确的记录。 根据该信息，它会颁发一个注册到受信任根的证书，然后您可以将其上传到 ILB。 无需对 Web 上的各个证书存储区执行任何操作应用，因为在 ILB 上具有受信任的根 SSL 证书。
如果你想要在 ILB 应用服务环境中运行的服务之间进行安全调用，请使自签名或内部颁发的 SSL 证书正常工作。 可考虑的另一种解决方案是，如何使 ILB 应用服务环境与内部颁发的 SSL 证书配合使用，以及如何将内部 CA 加载到受信任的根存储。
在预配应用服务环境期间，请在为环境选择域名时考虑以下限制。 域名不能是：
netazurewebsites.netp.azurewebsites.netnameofthease.p.azurewebsites.net
此外，用于应用的自定义域名和 ILB 应用服务环境使用的域名不能重叠。 对于域名为 contoso.com 的 ILB 应用服务环境，不能将如下所示的自定义域名用于应用：
www.contoso.comabcd.def.contoso.comabcd.contoso.com
为 ILB 应用服务环境选择一个不会与这些自定义域名冲突的域。 对于此示例，可为环境的域使用类似于 contoso internal.com 的域名，因为它不会与以 .contoso.com 结尾的自定义域名发生冲突。
要考虑的另一个方面是 DNS。 为了允许应用服务环境中的应用程序相互通信（例如，Web 应用程序与 API 通信），需要为持有环境的虚拟网络配置 DNS。 可以自带 DNS，也可以使用 Azure DNS 专用区域。
可用性
- 考虑在生成云应用程序时，应用针对可用性的典型设计模式。
- 在适当的应用程序服务 Web 应用程序参考体系结构中审核可用性注意事项。
- 若要针对可用性进行其他的考量，请参阅 Azure 体系结构中心的可用性清单。
可伸缩性
- 了解应用服务环境中的缩放工作原理。
- 查看云应用自动缩放的最佳实践。
- 生成云应用程序时，请弄清楚针对可伸缩性的典型设计模式。
- 在适当的应用程序服务 Web 应用程序参考体系结构中审核可伸缩性注意事项。
- 有关其他可伸缩性文章，请参阅 Azure 体系结构中心中提供的性能效率清单。
安全性
- 查看安全支柱概述。
- 在适当的应用程序服务 Web 应用程序参考体系结构中审核安全性注意事项。
- 考虑跟进某个安全开发生命周期流程，帮助开发人员生成更安全的软件并解决安全符合性要求问题，同时减少开发成本。
- 查看蓝图体系结构，以确定 Azure PCI DSS 符合性。
- Azure DDoS 防护与应用程序设计最佳做法相结合，提供增强的 DDoS 缓解功能来更全面地防御 DDoS 攻击。 应在任何外围虚拟网络上启用 Azure DDoS 保护。
复原
- 考虑将异地分布式缩放与应用服务环境结合使用，以获得更高的复原能力和可伸缩性。
- 审核针对复原的典型设计模式，考虑在适当情况下实施这些模式。
- 可以在 Azure 体系结构中心找到多个建议用于应用程序服务的做法。
- 考虑对数据层使用活动的异地复制，对图像和队列使用异地冗余存储。
- 有关复原的更深入讨论，请查看 Azure 体系结构中心的相关文章。
部署此方案
若要部署此方案，请按照此分步教程的说明操作，其中演示了如何手动部署每个组件。 遵循此教程时，请选择应用服务环境 v3 而不是 v2。 本教程还提供了 .NET 示例应用程序，该程序运行简单的 Contoso 支出报表应用程序。
定价
了解运行此方案的成本。 成本计算器中已预配置所有服务。 若要了解自己的特定用例的定价变化情况，请按预期的流量更改相应的变量。
我们已根据你预期接收的流量提供了三个成本配置文件示例：
- 小：此定价示例表示每月为几千个用户提供服务的最低生产级别实例所需的组件。 此应用使用某个标准 Web 应用的单个实例，这对于启动自动缩放来说已足够。 其他每个组件缩放到基本层，可以尽量减少成本，但仍可确保有服务级别协议 (SLA) 支持和足够的容量，可以处理生产级别的工作负载。
- 中：此定价示例表示中等大小的部署所需的组件。 在这里，我们估计一个月大约有 100,000 个用户。 预计的流量在处于中等标准层的单个应用程序服务实例中处理。 另外，认知和搜索服务的中型层也会添加到计算器中。
- 大：此定价示例表示应用程序需进行大规模的处理，每月的用户数在百万级别，移动的数据量为数 TB。 对于这种级别的使用量，必须将高级层 Web 应用部署在多个区域，并且需前置一个流量管理器。 数据由以下组件组成：存储、数据库和 CDN，都配置为存储 TB 量级的数据。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Faisal Mustafa | 高级客户工程师