在 Azure 上设计安全应用程序

本文介绍了在为云设计应用程序时需要考虑的安全活动和控制措施。 涵盖了Microsoft 安全开发生命周期 (SDL) 的要求和设计阶段中需考虑的培训资源、安全问题和概念。 目标是帮助你定义可用于设计更安全的应用程序的活动和Azure服务。

本文介绍了以下 SDL 阶段：

• 培训
• 要求
• 设计

培训

在开始开发云应用程序之前，请花时间了解Azure的安全和隐私。 通过执行此步骤，可以降低应用程序中可被利用的漏洞的数量和严重性。 你将能够更好地正确应对不断变化的威胁态势。

在培训阶段使用以下资源，熟悉开发人员可用的Azure服务，以及有关Azure的安全最佳做法：

• 开发人员的 Azure 指南介绍了如何开始使用 Azure。 本指南展示了你可使用哪些服务来运行应用程序、存储你的数据、引入智能、构建 IoT 应用，以及以更高效、更安全的方式部署解决方案。

• 面向Azure开发人员的入门指南为希望开始使用 Azure 平台以满足其开发需求的开发人员提供了重要信息。

• SDK 和工具介绍了Azure上可用的工具。

• 在推送到生产环境之前要考虑的五个安全项演示如何帮助保护 web 应用程序Azure并保护应用免受最常见的和危险的 Web 应用程序攻击。

• Azure 安全 DevOps 工具包是一系列脚本、工具、扩展和自动化流程，专为使用广泛自动化的 DevOps 团队提供全面的 Azure 订阅和资源安全需求。 适用于Azure的安全 DevOps 工具包可演示如何顺利地将安全性集成到本机 DevOps 工作流中。 此工具包提供了安全验证测试 (SVT) 等工具，该工具可帮助开发人员在编码和早期开发阶段编写安全代码并测试其云应用程序的安全配置。

• Azure安全最佳做法和模式 - 使用 Azure 设计、部署和管理云解决方案时要使用的安全最佳做法集合。 指导旨在为 IT 专业人员提供资源。 这可能包括构建和部署安全Azure解决方案的设计人员、架构师、开发人员和测试人员。

要求

要求定义阶段是一个关键步骤，它定义你的应用程序是什么，以及它发布后可用来做什么。 在需求阶段，还要考虑将在你的应用程序中构建的安全控制措施。 在此阶段，你还将开始执行在整个 SDL 中都将采取的步骤，以确保发布并部署安全的应用程序。

考虑安全和隐私问题

此阶段是考虑基础的安全和隐私问题的最佳时间。 在项目开始时定义可接受的安全和隐私级别有助于团队：

• 了解与安全问题相关的风险。
• 在开发过程中识别和修复安全漏洞。
• 在整个项目中应用确定的安全和隐私级别。

在编写对应用程序的要求时，请确保考虑有助于保护应用程序和数据安全的安全控制措施。

询问安全问题

询问安全问题，例如：

• 我的应用程序是否包含敏感数据？

• 我的应用程序是收集还是存储要求我遵守行业标准和合规性计划（如 联邦金融机构检查委员会 [FFIEC] 或 支付卡行业数据安全标准 [PCI DSS]）的数据？

• 我的应用程序是否收集或包含敏感的个人或客户数据，这些数据是否可以用来（单独使用或与其他信息一起使用）识别、联系或定位个人？

• 我的应用程序是否收集或包含可用于访问个人医疗、教育、财务或就业信息的数据？ 在要求阶段确定数据的敏感性有助于对数据进行分类，并确定将用于应用程序的数据保护方法。

• 我的数据存储在哪里？如何存储？ 考虑如何监视应用程序使用的存储服务是否存在任何意外变化（例如响应时间变长）。 你是否能够影响日志记录来收集更详细的数据并深入地分析问题？

• 我的应用程序是可供公众使用（在 Internet 上）还是仅供内部使用？ 如果你的应用程序可供公众使用，你如何保护可能会被收集的数据，避免其被不当使用？ 如果你的应用程序仅供内部使用，请考虑组织中谁应该有权访问该应用程序以及他们应该有权访问多长时间。

• 在开始设计应用程序之前，你是否了解你的标识模型？ 你能否确定用户的身份如其所言以及用户被授权执行什么操作？

• 我的应用程序是否执行敏感或重要的任务（例如转账、打开门锁或送药）？ 考虑如何验证执行敏感任务的用户是否被授权执行该任务，以及如何验证用户的身份如其所言。 授权 (AuthZ) 是指准许经过身份验证的安全主体执行某项操作的措施。 身份验证 (AuthN) 是要求参与方提供合法凭据的措施。

• 我的应用程序是否执行任何有风险的软件活动，例如允许用户上传或下载文件或其他数据？ 如果你的应用程序确实执行有风险的活动，请考虑如何让应用程序保护用户，防止用户处理恶意文件或数据。

审查 OWASP 前 10 大安全风险

考虑查看 OWASP 前 10 大应用程序安全风险。 “OWASP 前 10 大安全风险”介绍了 Web 应用程序的重大安全风险。 了解这些安全风险可以帮助你制定要求和设计决策，从而将应用程序中的这些风险降到最低。

考虑采取安全控制措施来防止违规，这很重要。 但是，你还需要假设会出现违规的情况。 假设发生安全漏洞，有助于提前思考一些关于安全的重要问题，这样就不必在紧急情况下仓促应对：

• 我将如何检测攻击？
• 如果存在攻击或违规，我该怎么办？
• 在遭受攻击（例如数据泄露或篡改）后我将如何进行恢复？

设计

设计阶段对于制定设计和功能规范的最佳做法至关重要。 它对于执行风险分析也至关重要，风险分析有助于减少整个项目中的安全和隐私问题。

如果你有安全要求并使用安全设计概念，则可以避免安全缺陷或尽量减少其出现。 安全缺陷是应用程序设计中的疏漏。在应用程序发布后，用户可能会利用它来执行恶意的或意外的操作。

在设计阶段，还要考虑如何在多个层次中应用安全措施；一层防御不一定够用。 如果攻击者穿过了你的 Web 应用程序防火墙 (WAF)，将会发生什么情况？ 你需要另一种安全控制措施来防御该攻击。

考虑到这一点，我们将讨论以下安全设计概念，以及在设计安全的应用程序时应解决的安全控制问题：

• 使用安全的编码库和软件框架。
• 扫描易受攻击的组件。
• 在应用程序设计期间使用威胁建模。
• 减少攻击面。
• 采用以身份作为主要安全边界的策略。
• 要求对重要事务进行重复身份验证。
• 使用密钥管理解决方案来保护密钥、凭据和其他机密。
• 保护敏感数据。
• 实施故障保护措施。
• 利用错误和异常处理机制。
• 使用日志记录和警报。

使用安全的编码库和软件框架

对于开发，请使用安全的编码库和具有内嵌安全性的软件框架。 开发人员可以使用现有的、经过证明的功能（加密、输入清理、输出编码、密钥或连接字符串以及任何其他会被视为安全控制措施的项目），不需从头开发安全控制措施。 这有助于避免与安全相关的设计和实现缺陷。

请确保使用框架及其提供的所有安全功能的最新版本。 Microsoft为所有开发人员提供全面的一套开发工具，适用于在任一平台或语言中开发云应用程序。 你可以从各种 SDK 中进行选择，以便使用所选语言进行编码。 可以利用功能齐全的集成开发环境（IDE）和具有高级调试功能和内置Azure 支持的编辑器。

Microsoft提供各种语言、框架和工具，可用于在Azure上开发应用程序。 例如，Azure适用于 .NET 和 .NET Core 开发人员。 对于我们提供的每种语言和框架，你可以通过快速入门、教程和 API 参考来快速入门。

Azure提供各种服务，可用于托管网站和 Web 应用程序。 这些服务允许你以你喜欢的语言进行开发，无论是.NET、.NET Core、Java、Ruby、Node.js、PHP 还是Python。 Azure 应用服务 Web 应用（Web 应用）是其中一项服务。

Web 应用向应用程序添加Azure功能。 它包括安全性、负载均衡、自动缩放和自动化管理。 应用，例如包管理、过渡环境、自定义域、SSL/TLS 证书以及从GitHub、Docker Hub和其他源持续部署。

Azure提供可用于托管网站和 Web 应用程序的其他服务。 对于大多数方案，Web 应用是最佳选择。 对于微服务体系结构，请考虑使用 Azure Service Fabric。 如果需要对运行代码的 VM 进行更多控制，请考虑Azure 虚拟机。 有关在这些 Azure 服务之间进行选择的更多信息，请参阅 Azure 应用服务、虚拟机、服务结构和云服务的比较。

为组件应用更新

为了防止出现漏洞，应持续清点你的客户端和服务器端组件（例如，框架和库）及其依赖项，看是否存在更新。 随着新漏洞的出现，我们会不断发布更新的软件版本。 请务必制定一个日常计划，以便监视、会审和应用针对你所使用的库和组件进行的更新或配置更改。

有关工具建议，请参阅 Open Web Application Security Project (OWASP) 上的 使用已知漏洞的组件 页。 你还可以订阅电子邮件警报，以便了解与所用组件有关的安全漏洞。

在应用程序设计期间使用威胁建模

威胁建模是一个过程，它需要先识别对业务和应用程序的潜在安全威胁，然后确保实施适当的缓解措施。 SDL 规定，团队应在设计阶段进行威胁建模，在此阶段解决潜在问题相对简单且经济高效。 在设计阶段使用威胁建模可以极大地降低总体开发成本。

考虑到非安全专家的情况，我们设计了 SDL Threat Modeling Tool 来简化威胁建模过程。 此工具提供有关如何创建和分析威胁模型的明确指导，使所有开发人员更容易进行威胁建模。

对应用程序设计进行建模并枚举所有信任边界中的 STRIDE 威胁（欺骗、篡改、否认、信息泄漏、拒绝服务和权限提升），已被证明是一种在早期捕获设计错误的有效方法。 下表列出了 STRIDE 威胁，并提供了一些使用Azure提供的功能的示例缓解措施。 这些缓解措施并非在每种情况下都起作用。

减少受攻击面

受攻击面是指可能出现潜在漏洞的位置的总数。 在本文中，我们重点介绍应用程序的受攻击面。 重点是保护应用程序，使其免受攻击。 从应用程序中删除未使用的资源和代码是最小化受攻击面的一种简单而快速的方法。 应用程序越小，受攻击面就越小。 例如，删除以下项：

• 尚未发布的功能的代码。
• 调试支持代码。
• 未使用的或已弃用的网络接口和协议。
• 未使用的虚拟机和其他资源。

定期清理资源并确保删除未使用的代码是很好的方法，可以确保减少恶意行动者发起攻击的机会。

深入分析攻击面是减少攻击面的更为详细和深入的方法。 受攻击面分析可帮助你映射需要检查和测试安全漏洞的系统部件。

受攻击面分析的目的是了解应用程序中的风险区域，以便开发人员和安全专家了解应用程序的哪些部分可能会受到攻击。 然后，你可以找到方法来尽可能降低这种可能性，跟踪受攻击面何时变化以及如何变化，并从风险角度来解读这意味着什么。

受攻击面分析可帮助你确定：

• 需要检查和测试安全漏洞的系统功能和部件。
• 需要纵深防御保护的高风险代码区域（需要防御的系统部件）。
• 当你改变攻击面时，需要刷新威胁评估。

若要减少攻击者利用潜在弱点或漏洞的机会，需要彻底分析应用程序的整体受攻击面。 它还包括禁止或限制对系统服务的访问、应用最小特权原则以及尽可能采用分层防御。

我们将讨论在 SDL 的验证阶段执行攻击面审查。

采用身份作为主要安全边界的策略

在设计云应用程序时，将安全边界的重点从以网络为中心的方法转向以身份为中心的方法非常重要。 过去，主要的本地安全外围是组织的网络。 大多数本地安全设计使用网络作为主要的安全枢纽。 对于云应用程序，可将标识视为主要安全外围，从而改善安全性。

若要制定以标识为中心的方法来开发 Web 应用程序，你可以执行的事项如下：

• 对用户实施多重身份验证。
• 使用强身份验证和授权平台。
• 应用最低权限原则。
• 实施实时访问。

对用户实施多重身份验证

使用双重身份验证。 双重身份验证是最新的身份验证和授权标准，因为它避免了用户名与密码类型的身份验证所固有的安全漏洞。 应设计并配置对Azure管理接口（Azure门户/远程 PowerShell）和面向客户的服务的访问权限，以使用 Microsoft Entra 多重身份验证。

使用强身份验证和授权平台

使用平台提供的身份验证和授权机制，而不要使用自定义代码。 这是因为开发自定义身份验证代码可能容易出错。 商业代码（例如，从Microsoft）通常经过广泛的安全审查。 Microsoft Entra ID（Microsoft Entra ID）是标识和访问管理的Azure解决方案。 这些Microsoft Entra工具和服务有助于安全开发：

• Microsoft 标识平台是开发人员用来构建安全登录用户的应用的一组组件。 该平台可以为需要构建单租户业务线 (LOB) 应用的开发人员和寻求开发多租户应用的开发人员提供帮助。 除了基本登录之外，使用Microsoft 标识平台生成的应用还可以调用Microsoft API 和自定义 API。 Microsoft 标识平台支持行业标准协议，如 OAuth 2.0 和 OpenID Connect。

• Microsoft Entra 外部 ID 在外部租户中是一种身份管理服务，用于自定义和控制客户在使用应用程序时进行注册、登录及管理其档案。 这包括为 iOS、Android 和 .NET 开发的应用程序等。 Azure AD B2C 可在保护客户标识的同时启用这些操作。

应用最低权限原则

最低权限概念的意思是给用户提供完成工作所需的精确的访问和控制权限，不提供任何额外的权限。

软件开发人员是否需要域管理员权限？ 管理助理是否需要访问其个人电脑上的管理控制措施？ 评估软件访问权限并没有什么不同。 如果使用 Azure 基于角色的访问控制（Azure RBAC）为用户提供不同的能力和权限，则不会让每个人访问所有内容。 通过将访问权限限定为每个角色必需的权限，可以限制出现安全问题的风险。

确保你的应用程序在其整个访问模式中强制实施最低权限。

实施实时访问

实施实时 (JIT) 访问以进一步降低权限的暴露时间。 使用 Microsoft Entra Privileged Identity Management：

• 向用户授予所需的仅 JIT 权限。
• 分配时限更短的角色，确信权限会自动撤消。

要求对重要事务进行重复身份验证

跨站点伪造请求（也称为 XSRF 或 CSRF ）是一种针对 Web 托管型应用的攻击。在此类攻击中，恶意 Web 应用会影响客户端浏览器与信任该浏览器的 Web 应用之间的交互。 可能出现跨站点伪造请求攻击是因为 Web 浏览器会随每个请求自动向网站发送某些类型的身份验证令牌。 这种形式的攻击也称为一键攻击或会话叠置，因为攻击利用了用户先前经过身份验证的会话。

防御此类攻击的最佳方法是在每次执行重要事务（例如购买、帐户停用或密码更改）之前都向用户请求只有该用户才能提供的内容。 你可以要求用户重新输入密码、完成验证码，或者提交只有该用户才会有的机密令牌。 最常用的方法是机密令牌。

使用密钥管理解决方案来保护密钥、凭据和其他机密

丢失密钥和凭据是一个常见问题。 唯一比丢失密钥和凭据更遭糕的事情是让未经授权的一方获取这些密钥和凭据的访问权限。 攻击者可以利用自动化和手动技术来查找存储在代码存储库（如 GitHub）中的密钥和机密。 请勿在这些公用代码存储库中或任何其他服务器上放置密钥和机密。

请始终将密钥、证书、机密和连接字符串放置在密钥管理解决方案中。 可以使用集中式解决方案，将密钥和机密存储在硬件安全模块 (HSM) 中。 Azure为您提供一个基于云的HSM，通过Azure 密钥保管库。

密钥保管库是一个机密存储服务：它是一个集中式云服务，用于存储应用程序的敏感信息。 密钥保管库通过将应用程序机密保存在单个中心位置并提供安全访问、权限控制和访问日志记录来保护机密数据。

机密存储在各个保管库中。 每个保管库都使用其自己的配置和安全策略来控制访问。 你可以通过 REST API 或通过可用于大多数编程语言的客户端 SDK 来访问数据。

保护敏感数据

保护数据是安全策略的重要组成部分。 对数据进行分类并确定数据保护需求有助于你在设计应用时始终考虑数据安全。 按敏感度和业务影响对存储的数据进行分类有助于开发人员确定与数据相关的风险。

在设计数据格式时，请将所有适用的数据标记为敏感数据。 确保应用程序将适用的数据视为敏感数据。 这些做法有助于保护敏感数据：

• 使用加密。
• 避免对机密（例如密钥和密码）进行硬编码。
• 确保实施访问控制和审核。

使用加密

保护数据应当是安全策略的重要组成部分。 如果数据存储在数据库中，或者在不同位置之间来回移动，请对静态数据（在数据库中）进行加密，并对传输中的数据（在往返于用户、数据库、API 或服务终结点的路上）进行加密。 建议始终使用 SSL/TLS 协议来交换数据。 确保使用最新版本的 TLS 进行加密（目前为版本 1.2）。

避免硬编码

某些东西绝不应当硬编码到软件中。 例如，主机名或 IP 地址、URL、电子邮件地址、用户名、密码、存储帐户密钥和其他加密密钥。 请考虑实施相关要求来规定哪些东西可以硬编码到代码中（包括代码的注释部分），哪些东西不能硬编码。

在代码中放置注释时，请确保不要保存任何敏感信息。 这包括你的电子邮件地址、密码、连接字符串；只有组织中的某个人才能知道的有关你的应用程序的信息；以及攻击者可能会用来攻击你的应用程序或组织的任何其他信息。

大致假设开发项目中的所有内容在部署时都是公开知识。 避免在项目中包括任何类型的敏感数据。

早些时候，我们讨论了 Azure 密钥保管库。 可以使用密钥保管库来存储密钥和密码等机密，而不是对其进行硬编码。 将密钥保管库与用于Azure资源的托管标识结合使用时，Azure Web 应用可以轻松安全地访问机密配置值，而无需在源代码管理或配置中存储任何机密。 若要了解详细信息，请参阅使用 Azure 密钥保管库 管理服务器应用中的机密。

实施故障保护措施

应用程序必须能够以一致的方式处理执行过程中出现的错误。 应用程序应该捕获所有错误，实施故障保护或故障关闭措施。

你还应当确保在错误日志中记录足够的用户上下文，以便识别可疑的或恶意的活动。 日志应当保留足够长的时间，以便延后进行法证分析。 日志的格式应便于日志管理解决方案处理。 如果出现与安全相关的错误，请确保触发警报。 如果日志记录和监视措施不足，攻击者就会进一步攻击系统并将其持久化。

利用错误和异常处理机制

进行正确的错误和异常处理是防御性编码的重要组成部分。 错误和异常处理对于确保系统的可靠性和安全性至关重要。 错误处理中的失误可能会导致各种类型的安全漏洞，例如向攻击者泄漏信息，以及帮助攻击者了解你的平台和设计的详细信息。

请确保：

• 集中处理异常，避免在代码中使用重复的 try/catch 块。

• 所有的意外行为都在应用程序中进行处理。

• 向用户显示的消息不会泄露重要数据，但会提供足够的信息来解释问题。

• 记录异常，并确保它们提供足够的信息，以便法证分析或事件响应团队进行调查。

Azure 逻辑应用为由依赖系统引起的处理错误和异常提供了一流的体验。 你可以使用逻辑应用来创建工作流，以便自动完成用于跨企业和组织集成应用、数据、系统和服务的任务和流程。

使用日志记录和警报

记录你的安全问题以便进行安全调查，并触发相关问题的警报，以确保人们及时了解问题。 在所有组件中启用审核与日志记录。 审核日志应该捕获用户上下文并标识所有重要事件。

确保不会记录用户提交到站点的任何敏感数据。 敏感数据的示例包括：

• 用户凭据
• 身份证号或其他身份信息
• 信用卡号或其他财务信息
• 健康信息
• 私钥，或者其他可用于解密已加密信息的数据
• 可以用来增强应用程序攻击效果的系统信息或应用程序信息

确保应用程序监视用户管理事件，例如用户登录成功或失败、密码重置、密码更改、帐户锁定和用户注册。 这些事件的日志记录可帮助检测潜在的可疑行为并对其做出反应。 此外，还可通过它收集操作数据；例如谁正在访问应用程序。

后续步骤

下面的文章中推荐了一些安全控制措施和活动，可帮助你开发和部署安全的应用程序。

• 开发安全的应用程序
• 部署安全的应用程序