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