本文提供的信息可以帮助您：
- 了解云中的托管应用程序的安全优势
- 评估平台即服务 (PaaS) 相比其他云服务模型的安全优势
- 将安全重心从以网络为中心的方案转换为以标识为中心的外围安全方案
- 实施一般的 PaaS 安全最佳实践建议
在 Azure 上开发安全应用程序是一个常规指南，其针对的安全问题和控制是你在开发适用于云的应用程序时应该在软件开发生命周期的每个阶段考虑的。
云的安全优势
请务必了解你与 Microsoft 之间的责任分工。 在本地，你拥有整个堆栈，但在迁移到云时，某些职责会转移到Microsoft。
云中具有安全优势。 在本地环境中，组织可能承担未满足的责任和有限的资源来投资安全性，从而创建攻击者可以利用所有层的漏洞的环境。
组织可以使用提供商的基于云的安全功能和云智能来改善其威胁检测和响应时间。 通过将责任转移到云提供商，组织可以扩大安全覆盖范围，为其他优先业务重新调配安全资源与预算。
PaaS 云服务模型的安全优势
让我们来了解一下 Azure PaaS 部署相比本地部署的安全优势。
从堆栈的底部（即物理基础结构）开始，Microsoft 可以消除常见的风险和管理责任。 由于 Azure 云受到 Microsoft 的持续监视，因此很难攻破。 对于攻击者而言，将 Azure 云作为目标没有任何意义。 他们往往会改换目标，除非他们有大量的金钱和资源。
在堆栈的中间，PaaS 部署与本地之间没有差别。 在应用程序层和帐户与访问管理层，面临的风险是类似的。 本文的后续步骤部分将指导你了解消除或最小化这些风险的最佳做法。
堆栈的顶层（即数据监管和权限管理）存在一种风险，不过可以使用密钥管理来缓解。 虽然密钥管理是一项额外的责任，但在 PaaS 部署中，你不再需要管理这些区域，因此你可以将资源转移到密钥管理。
Azure 平台还使用各种基于网络的技术提供强大的 DDoS 保护。 但是，根据链路和数据中心的不同，所有类型的基于网络的 DDoS 保护方法都有自身的限制。 为了帮助避免大规模 DDoS 攻击造成的影响，可以利用 Azure 的核心云功能快速自动扩展，从而防御 DDoS 攻击。
身份作为主要安全边界
通过 PaaS 部署，整体安全性方法发生了转变。 事必躬亲的局面现在可以改为与 Microsoft 分担责任。
PaaS 和传统的本地部署之间的另一个重要区别是定义主要安全外围的新视图。 一直以来，主要的本地安全边界就是网络，大多数本地安全设计都使用网络作为主要安全枢纽。 在 PaaS 部署中，可将标识视为主要安全边界，从而改善安全性。
在云计算的五大基本特征中，一个特征就是网络访问范围广泛，这使得以网络为中心的理念显得有点毫不相干。 许多云计算解决方案的目标是不管用户身居何处，都能允许他们访问资源。 对于大多数用户而言，他们的位置就是 Internet 上的某个节点。
下图演示了安全边界从网络边界演进成标识边界的过程。 安全性越来越少地与如何保护网络相关，而更多地与如何保护数据，以及如何管理应用和用户的安全性相关。 两者的关键差别在于如何为公司的重要资产提供更多的安全保障。
最初，Azure PaaS 服务（例如 Web 角色和 Azure SQL）提供的传统网络边界防护措施很少，或者根本不提供。 据了解，该元素的目的是向 Internet（Web 角色）公开，身份验证提供新的外围（例如 Azure SQL）。
新式安全措施假设入侵者会突破网络边界。 因此，新式防护措施已转移到标识。 组织必须建立具有强身份验证和授权卫生条件的基于标识的安全外围。
标识管理的最佳做法
下面是管理标识边界的最佳做法。
最佳做法：保护密钥和凭据以保护 PaaS 部署。 详细信息：丢失密钥和凭据是一个常见问题。 可以使用集中式解决方案，将密钥和机密存储在硬件安全模块 (HSM) 中。 Azure Key Vault 通过使用受 HSM 保护的密钥对身份验证密钥、存储帐户密钥、数据加密密钥、.pfx 文件和密码进行加密来保护你的密钥和机密。
最佳做法：不要将凭据和其他机密放入源代码或 GitHub。 详细信息：唯一比丢失密钥和凭据更遭糕的事情是让未经授权的一方获取这些密钥和凭据的访问权限。 攻击者可以利用 bot 技术来查找 GitHub 等代码存储库中存储的密钥和机密。 不要在这些公共代码存储库中放置密钥和机密。
最佳做法：使用强身份验证和授权平台。 详细信息：使用 Microsoft Entra ID 进行身份验证，而不是自定义用户存储。 使用 Microsoft Entra ID 时，可以利用基于平台的方法并委托对授权标识的管理。 当员工被解雇并且需要在多个身份和授权系统中反映信息时，Microsoft Entra ID 方法尤其重要。
使用平台提供的身份验证和授权机制，而不要使用自定义代码。 原因是开发自定义身份验证代码可能很容易出错。 大部分开发人员都不是安全专家，不太可能会注意到身份验证和授权的细微之处与最新开发情况。 商业代码（例如 Microsoft 编写的代码）通常会接受广泛的安全性评审。
使用多重身份验证（MFA）。 MFA 是身份验证和授权的当前标准，因为它避免了用户名和密码身份验证类型固有的安全弱点。 应设计并配置对 Azure 管理（门户/远程 PowerShell）接口和面向客户的服务的访问权限，以使用Microsoft Entra 多重身份验证。
使用 OAuth2 和 Kerberos 等标准身份验证协议。 这些协议经过广泛的同行评审，有时可实现为平台库的一部分用于身份验证和授权。
在应用程序设计期间使用威胁建模
Microsoft 安全开发生命周期指定团队应在设计阶段参与名为威胁建模的过程。 为了帮助简化此过程，Microsoft 已创建 SDL 威胁建模工具。 对应用程序设计进行建模，并在所有信任边界内列举 STRIDE 威胁，可以及早识别设计错误。
下表列出了 STRIDE 威胁，并提供了一些使用 Azure 功能的示例缓解措施。 这些缓解措施并非在每种情况下都起作用。
| 威胁 | 安全属性 | 潜在的 Azure 平台缓解措施 |
|---|---|---|
| 欺骗 | 身份验证 | 要求使用 HTTPS 连接。 |
| 篡改 | 完整性 | 验证 TLS/SSL 证书。 |
| 否认性 | 不可否认性 | 启用 Azure 监视和诊断。 |
| 信息泄露 | 机密性 | 使用 服务证书加密静态敏感数据。 |
| 拒绝服务 | 可用性 | 监视潜在拒绝服务条件的性能指标。 实现连接筛选器。 |
| 特权提升 | 授权 | 使用 Privileged Identity Management。 |
Azure App 服务
Azure App Service 是一个 PaaS 产品，可创建适用于任何平台或设备的 Web 和移动应用，并可连接到云中或本地任何位置的数据。 应用服务所包括的 Web 功能和移动功能是以前作为 Azure 网站和 Azure 移动服务单独交付的。 它还包括各种新功能，可以实现业务流程的自动化，并可托管云 API。
下面是使用应用服务的最佳做法。
最佳做法：通过 Microsoft Entra ID 进行身份验证。 详细信息：应用服务为标识提供者提供 OAuth 2.0 服务。 OAuth 2.0 注重简化客户端开发人员的工作，同时为 Web 应用程序、桌面应用程序和移动电话提供特定的授权流。 Microsoft Entra ID 使用 OAuth 2.0，可让你授予对移动和 Web 应用程序的访问权限。
最佳做法：根据“需要知道”和“最低权限”安全原则限制访问。 详细信息：对于想要实施数据访问安全策略的组织，限制访问是必须要做的事。 可以使用 Azure RBAC 将权限分配给特定范围内的用户、组和应用程序。
最佳做法：保护密钥。 详细信息：Azure Key Vault 可帮助保护云应用程序和服务使用的加密密钥和机密。 通过 Key Vault，可以使用受硬件安全模块 (HSM) 保护的密钥，来加密密钥和机密（例如身份验证密钥、存储帐户密钥、数据加密密钥、.PFX 文件和密码）。 为了提升可靠性，可以在 HSM 中导入或生成密钥。 请参阅 Azure Key Vault 了解详细信息。 还可以使用 Key Vault 和自动续订来管理 TLS 证书。
最佳做法：限制传入的源 IP 地址。 详细信息：应用服务环境提供虚拟网络集成功能，可帮助你通过网络安全组限制传入的源 IP 地址。 使用虚拟网络可将 Azure 资源置于可以控制其访问权限但无法通过 Internet 路由的网络中。 若要了解详细信息，请参阅将应用与 Azure 虚拟网络集成。 此外，还可以使用 专用链接（专用终结点） 并禁用公共网络，以强制应用服务和其他服务之间的专用网络连接。
最佳做法：强制实施仅限 HTTPS 的流量，并要求对所有连接使用 TLS 1.2 或更高版本。 尽可能禁用 FTP 访问;如果需要文件传输，请使用 FTPS 确保安全加密的传输。 详细信息：将应用服务配置为仅接受 HTTPS 流量可确保数据在传输中加密，从而防止敏感信息被拦截。 要求 TLS 1.2 或更高版本可以针对早期协议版本中发现的漏洞提供更强的安全性。 禁用 FTP 可降低未加密传输凭据或数据的风险。 如果需要文件传输，请仅启用 FTPS，这将在传输过程中加密凭据和数据。
最佳做法：监视应用服务环境的安全状态。 详细信息：使用 Microsoft Defender for Cloud 监视应用服务环境。 当 Defender for Cloud 识别潜在的安全漏洞时，它会创建一些建议，这些建议会指导完成配置所需控件的过程。 Microsoft Defender for App Service 为应用服务资源提供威胁防护。
有关详细信息，请参阅 Microsoft Defender for App Service。
Web 应用程序防火墙
Web 应用程序已逐渐成为利用常见已知漏洞的恶意攻击的目标。 这些攻击中常见的是 SQL 注入攻击和跨站点脚本攻击。 在应用程序代码中防止此类攻击可能具有挑战性，并且可能需要在应用程序拓扑的许多层进行严格的维护、修补和监视。 集中式 Web 应用程序防火墙有助于大幅简化安全管理，为抵卸威胁或入侵的应用程序管理员提供更好的保障。 WAF 解决方案还可以通过修补中心位置的已知漏洞来更快地应对安全威胁，而不是保护每个单独的 Web 应用程序。
Azure Web 应用程序防火墙（WAF） 可集中保护 Web 应用程序免受常见攻击和漏洞的伤害。 WAF 通过 Azure 应用程序网关 和 Azure Front Door 提供。
DDoS 防护
Azure 提供两个主要的 DDoS 保护层：DDoS IP 保护和DDoS 网络保护。 这些选项涵盖不同的方案，并具有不同的功能和定价。
- DDoS IP 防护：最适合保护特定公共 IP 地址，非常适合需要 IP 级别的基本 DDoS 缓解的较小或有针对性的部署。
- DDoS 网络保护：涵盖具有高级缓解、分析和集成的整个虚拟网络;适用于需要更广泛的安全性的大型或企业环境。
选择 DDoS IP 保护，以应对对成本敏感的情况；选择 DDoS 网络保护，提供全面覆盖和高级功能。
DDoS 防护在网络层（3/4）进行保护。 对于应用程序层（7）防御，请添加 WAF。 请参阅 应用程序 DDoS 保护。
监视应用程序性能
Azure Monitor 收集、分析和处理来自云和本地环境的遥测数据。 有效的监视策略有助于了解应用程序组件的详细运行状况， 它有助于向你发送关键情况的通知，让你在这些情况成为问题之前解决它们，从而提高运行时间。 它还有助于检测可能与安全相关的异常。
使用 Application Insights 监视应用程序的可用性、性能和使用情况，无论是托管在云中还是本地。 通过使用 Application Insights，可以快速确定并诊断应用程序中的错误，而无需等待用户报告这些错误。 利用所收集的信息，可作出有关应用程序维护和优化的明智抉择。
Application Insights 提供各种可以与所收集的数据交互的工具。 Application Insights 在公用存储库中存储其数据。 它可以通过 Kusto 查询语言充分利用各种共享功能，例如警报、仪表板和深入分析。
执行安全渗透测试
验证安全防御与测试任何其他功能一样重要。 将渗透测试规定为生成和部署过程的标准组成部分。 针对已部署应用程序对定期安全测试和漏洞扫描进行计划，并监视打开的端口、终结点和攻击活动。
后续步骤
本文重点介绍了 Azure PaaS 部署的安全优势以及云应用程序的最佳安全做法。 接下来，请阅读有关使用特定 Azure 服务保护 PaaS Web 和移动解决方案的建议做法。 我们将从 Azure 应用服务、Azure SQL 数据库和 Azure Synapse Analytics 和 Azure 存储开始。 随着适用于其他 Azure 服务的建议做法文章的发布，我们会在以下列表中提供相应的链接：
有关在开发适用于云的应用程序时，应在软件开发生命周期的每个阶段中考虑的安全性问题和控件，请参见在 Azure 上开发安全的应用程序。
有关通过 Azure 设计、部署和管理云解决方案时可以使用的更多安全最佳做法，请参阅 Azure 安全最佳做法和模式。
以下资源提供了有关 Azure 安全性及相关 Microsoft 服务的更多常规信息：
- Azure 安全文档 - 提供全面的安全指南
- Microsoft 安全响应中心 - 可在其中报告 Microsoft 安全漏洞（包括 Azure 问题）或将其通过电子邮件发送到 secure@microsoft.com