通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关保护开发生命周期的建议

  • 项目

适用于此 Azure 架构良好的框架安全清单建议：

SE：02 使用强化的、主要是自动化且可审核的软件供应链来维护安全的开发生命周期。 使用威胁建模来整合安全设计，以防止安全失败的实现。

相关指南： 威胁分析

本指南介绍了 在整个开发周期中应用安全最佳做法来强化代码、开发环境和软件供应链 的建议。 若要了解本指南，应了解 DevSecOps。

安全周期的关系图。

DevSecOps 通过以下方式将安全性集成到 DevOps 进程中：

  • 自动执行安全测试和验证。

  • 实现安全管道等工具，以扫描代码和基础结构即代码（IaC）是否存在漏洞。

工作负荷的核心是实现业务逻辑的应用程序代码。 代码和开发代码的过程必须 没有安全缺陷 ，以确保保密性、完整性和可用性。

使用标识和网络和其他措施的控制来保护基础结构平面是不够的。 防止代码或遭到入侵的代码块 的不良实现，以增强整体安全态势。 使用平面（即应用程序代码）也必须强化。 将安全性集成到开发生命周期的过程本质上是一个强化过程。 与资源强化一样，收紧代码开发也与上下文无关。 重点是增强安全性，而不是应用程序的功能要求。 有关强化的信息，请参阅 有关强化资源的建议。

定义

术语 定义
安全开发生命周期 (SDL) Microsoft提供的一组做法，支持安全保证和符合性要求。
软件开发生命周期 （SDLC） 用于开发软件系统的多阶段系统过程。

关键设计策略

应将安全措施集成到现有软件开发生命周期（SDLC）中的多个点，以确保：

  • 设计选择不会导致安全漏洞。

  • 由于可利用的实现和不正确的编码做法，应用程序代码和配置不会创建漏洞。

  • 通过供应链获取的软件不会带来安全威胁。

  • 应用程序代码、生成和部署过程不会被篡改。

  • 通过事件揭示的漏洞会得到缓解。

  • 未使用的资产已正确解除授权。

  • 合规性要求不会泄露或减少。

  • 审核日志记录在开发人员环境中实现。

以下部分为 SDLC 的常见阶段提供安全策略。

收集和记录安全要求

要求阶段 的目标是收集和分析应用程序的功能和非功能要求 或应用程序的新功能。 此阶段非常重要，因为它有助于创建专为应用程序目标定制的防护措施。 保护应用程序的数据和完整性应该是整个开发生命周期的每个阶段的核心要求。

例如，请考虑需要支持关键用户流的应用程序，使用户能够上传和操作数据。 安全设计选项应涵盖用户与应用程序的交互保证，例如对用户标识进行身份验证和授权，只允许对数据执行允许的操作，以及防止 SQL 注入。 同样，涵盖可用性、可伸缩性和可维护性等非功能要求。 安全选择应包括分段边界、防火墙入口和出口，以及其他跨领域安全问题。

所有这些决策都应很好地定义应用程序的安全状况。 在商定的规范 中记录安全要求，并将其反映在积压工作中。 如果业务利益干系人未批准投资，则应明确说明安全投资以及业务愿意承担的权衡和风险。 例如，可以记录需要在应用程序前使用 Web 应用程序防火墙（WAF），例如 Azure Front Door 或Azure 应用程序网关。 如果业务利益干系人尚未准备好接受运行 WAF 的额外成本，则需要接受应用程序层攻击可能指向应用程序的风险。

安全要求收集是此阶段的关键部分。 如果不进行这项努力，设计和实施阶段将基于未统计的选择，这可能会导致安全漏洞。 稍后可能需要更改实现以适应安全性，这可能很昂贵。

将安全要求转换为技术要求

在设计阶段， 安全要求将转换为技术要求。 在技术规范中，记录所有设计决策，以防止在实现过程中出现歧义。 下面是一些典型任务：

定义系统体系结构的安全维度

使用安全控件覆盖体系结构。 例如，根据 分段策略对隔离边界的实际控制、应用程序的组件所需的标识类型以及要使用的加密方法的类型。 有关一些示例体系结构，请参阅标识和访问管理和网络文章的“示例”部分中的插图。

评估平台提供的负担

了解 你与云提供商之间的责任划分非常重要。 例如，避免与 Azure 本机安全控制重叠。 你将获得更好的安全覆盖范围，并能够将开发资源重新分配给应用程序的需求。

例如，如果设计要求入口上的 Web 应用程序防火墙，可以将该责任卸载到负载均衡器，例如应用程序网关或 Azure Front Door。 避免将功能复制为应用程序中的自定义代码。

仅选择受信任的框架、库和供应链软件。 设计还应指定安全版本控制。 应用程序依赖项应源自受信任的参与方。 第三方供应商应能够满足安全要求 并共享其负责任的披露计划。 应及时报告任何安全事件，以便可以采取必要的操作。 此外，组织可能会禁止某些库。 例如，软件可能受到漏洞保护，但仍因许可限制而不允许。

为了确保本指南遵循软件的所有参与者， 请维护已批准和/或未经批准的框架、库和供应商的列表。 如果可能，请将护栏放在开发管道中以支持列表。 尽可能 自动使用工具来扫描依赖项 是否存在漏洞。

确定应用程序代码应实现的安全设计模式。

模式可以支持安全问题，例如分段和隔离、强授权、统一的应用程序安全性和新式协议。 某些操作模式（如隔离模式）可以帮助验证和阻止使用可能引入安全漏洞的软件。

有关详细信息，请参阅 支持安全性的云设计模式。

安全地存储应用程序机密

安全地实现应用程序使用的应用程序机密和预共享密钥的使用。 凭据和应用程序机密不应存储在源代码树中。 使用 Azure 密钥库等外部资源来确保，如果源代码可供潜在攻击者使用，则无法获取进一步的访问权限。 一般情况下，找到避免机密的方法。 尽可能使用托管标识是实现该目标的一种方法。 有关详细信息，请参阅 管理应用程序机密的建议。

定义测试计划

为安全要求定义明确的测试用例。 评估是否可以 在管道中自动执行这些测试。 如果团队具有手动测试流程，请包括这些测试的安全要求。

注意

在此阶段执行威胁建模。 威胁建模可以确认设计选择符合安全要求，并暴露应缓解的漏洞。 如果工作负荷处理高度敏感的数据，请投资可帮助进行威胁建模的安全专家。

在定义软件的体系结构和高级设计时，应在设计阶段进行初始威胁建模练习。 在该阶段执行此操作有助于在将潜在安全问题纳入系统结构之前识别它们。 但是，此练习不是一次性活动。 这是一个持续的过程，应该在整个软件的演变过程中继续。

有关详细信息，请参阅 威胁分析建议。

安全开发和测试做法

在开发和测试阶段，目标是 防止代码、生成和部署管道中的安全缺陷 和篡改。

在安全代码实践中训练良好

开发团队应在 安全编码实践方面进行正式和专门的培训。 例如，Web 和 API 开发人员可能需要特定的培训来防范跨站点脚本攻击，后端开发人员可以从深入培训中受益，以避免数据库级攻击（如 SQL 注入攻击）。

开发人员必须先完成此培训，然后才能访问生产源代码。

还应执行内部对等代码评审来促进持续学习。

使用安全测试工具

执行威胁建模以评估应用程序体系结构的安全性。

使用 静态应用程序安全测试（SAST） 分析漏洞的代码。 将此方法集成到开发人员环境中，实时检测漏洞。

在运行时使用 动态应用程序安全测试（DAST ）。 此工具链可以检查安全域中的错误，并模拟一组攻击来测试应用程序的安全复原能力。 如果可能，请将此工具集成到生成管道中。

遵循行业标准的安全编码做法。 有关详细信息，请参阅本文的 “社区资源 ”部分。

使用 linters 和代码分析器防止凭据推送到源代码存储库。 例如，.NET 编译器平台 （Roslyn） 分析器会检查应用程序代码。

在生成过程中， 使用管道加载项捕获源代码中的凭据。 扫描所有依赖项，如第三方库和框架组件，作为持续集成过程的一部分。 调查工具标记的易受攻击的组件。 将此任务与其他可检查代码改动、测试结果和覆盖率的代码扫描任务组合在一起。

使用测试的组合。 有关安全测试的一般信息，请参阅 安全测试建议。

编写足够多的代码

减少代码占用量时，还可以降低安全缺陷的可能性。 重复使用已在使用的代码和库，并且已通过安全验证 ，而不是复制代码。

利用 Azure 功能是防止不必要的代码的另一种方法。 一种方法是使用托管服务。 有关详细信息，请参阅使用平台即服务 (PaaS) 选项。

默认情况下，使用“拒绝”方法编写代码。 仅为需要访问权限的实体创建允许列表。 例如，如果代码需要确定是否应允许特权操作，则应编写它，以便 拒绝 结果为默认情况， 并且仅当代码明确允许时，才会发生允许 结果。

保护开发人员环境

开发人员工作站需要使用 强网络和标识控制来保护，以防止暴露。 确保勤奋地应用安全更新。

生成代理具有很高的特权，并且有权访问生成服务器和代码。 它们必须受到与工作负荷组件相同的严格保护。 这意味着 必须对生成代理的访问进行身份验证和授权，它们应与防火墙控制进行网络分段，应受到漏洞扫描等的约束。 Microsoft托管生成代理应优先于自承载生成代理。 Microsoft托管的代理为管道的每个运行提供干净虚拟机等优势。

自定义生成代理会增加管理的复杂性，并可能成为攻击途径。 必须安全地存储生成计算机凭据，并且需要定期从文件系统中删除任何临时生成项目。 可以通过仅允许来自生成代理的传出流量来实现网络隔离，因为它使用与 Azure DevOps 通信的拉取模型。

源代码存储库也必须受到 保护。 根据需要授予对代码存储库的访问权限，并尽可能减少漏洞暴露，以避免攻击。 有一个彻底的过程来查看安全漏洞的代码 。 出于此目的使用安全组，并实施基于业务理由的审批过程。

保护部署管道中的代码

它不足以保护代码。 如果它在可利用的管道中运行，则所有安全工作都是徒劳的且不完整的。 生成和发布环境也必须受到保护 ，因为你想要防止恶意执行组件在管道中运行恶意代码。

维护集成到应用程序中的每个组件的最新清单

集成到应用程序中的每个新组件都会增加攻击面。 若要确保在添加新组件或更新新组件时进行适当的问责和警报，应提供这些组件的清单。 将其存储在生成环境之外。 定期检查清单是否与生成过程中的内容匹配。 这样做有助于确保不会意外添加包含后门或其他恶意软件的新组件。

管道任务

  • 从受信任的源（如Azure 市场）拉取管道中的任务。 运行管道供应商编写的任务。 建议使用 GitHub 任务或 GitHub Actions。 如果使用 GitHub 工作流，首选Microsoft创作的任务。 此外，验证任务，因为它们在管道的安全上下文中运行。

  • 管道机密。 管道中运行的部署资产有权访问该管道中的所有机密。 为管道 的不同阶段设置适当的分段，以避免不必要的暴露。 使用内置于管道中的机密存储。 请记住，在某些情况下，可以避免使用机密。 探索使用工作负荷标识（用于管道身份验证）和托管标识（用于服务到服务身份验证）。

使不同的环境保持独立

在不同环境中使用的数据必须保持分开。 不应在较低环境中 使用生产数据，因为这些环境可能没有生产具有的严格安全控制。 避免从非生产应用程序连接到生产数据库，并避免将非生产组件连接到生产网络。

渐进式曝光

使用渐进式曝光， 根据所选条件向部分用户 发布功能。 如果出现问题，则会将这些用户的影响降到最低。 此方法是一种常见的风险缓解策略，因为它减少了外围应用。 随着该功能的成熟，你对安全保证更加有信心，你可以逐渐将其发布到更广泛的用户集。

保护生产中的代码

生产阶段提供了 解决安全漏洞的最后一个负责任的机会。 保留生产中发布的黄金映像的记录。

保留版本控制的项目

保留所有已部署资产及其版本的目录。 此信息在事件会审、缓解问题时以及系统恢复工作状态时非常有用。 还可以将版本化资产与发布的常见漏洞和暴露 (CVE) 通知进行比较。 应使用自动化执行这些比较。

紧急修复

自动化管道设计应灵活地 支持常规部署和紧急部署。 这种灵活性对于支持快速和负责任的安全修复非常重要。

发布通常与多个审批入口相关联。 请考虑创建一个紧急过程来加速安全修复。 此过程可能涉及团队之间的沟通。 管道应允许快速前滚和回滚部署，这些部署解决了在常规部署生命周期之外发生的安全修复、关键 bug 和代码更新。

注意

始终优先处理安全修补程序，以方便起见。 安全修补程序不应引入回归或 bug。 如果要通过紧急管道加速修复，请仔细考虑可以绕过哪些自动测试。 根据执行时间评估每个测试的值。 例如，单元测试通常可快速完成。 集成或端到端测试可以长时间运行。

在整个生命周期内维护代码安全性

此阶段 的目标是确保安全状况不会随时间而衰落。 SDLC 是一个持续的敏捷过程。 上述阶段中介绍的概念适用于此阶段，因为需求随时间而变化。

修补程序管理。 使用安全修补程序和更新使软件、库和基础结构组件保持最新。

持续改进。 通过考虑代码评审、反馈、吸取的教训和不断演变的威胁，持续评估和改进软件开发过程的安全性。

停用过时或不再使用的旧资产 。 这样做会减少应用程序的外围应用。

维护还包括事件修复。 如果在生产中发现问题，则需要及时将其重新集成到进程中，以便它们不会递归。

持续改进安全编码做法，以跟上威胁形势。

Azure 便利化

Microsoft安全开发生命周期（SDL）建议适用于开发生命周期的安全做法。 有关详细信息，请参阅 Microsoft安全开发生命周期。

Defender for DevOps 和 SAST 工具包含在 GitHub 高级安全性或 Azure DevOps 中。 这些工具可帮助你跟踪组织的安全评分。

按照以下资源中所述的 Azure 安全建议操作：

若要在源代码中查找凭据，请考虑使用 GitHub 高级安全性和 OWASP 源代码分析工具等工具。

验证应用程序中任何开源代码的安全性。 这些免费工具和资源可帮助你进行评估：

安全清单

请参阅完整的建议集。

安全清单