有关保护开发生命周期的建议
适用于此 Power Platform Well-Architected 安全检查表建议：
| SE：02 | 使用强化的、大部分是自动化且可审核的软件供应链来维护安全开发生命周期。 使用威胁建模来整合安全设计，以防止安全失效的实现。 |
|---|
本指南介绍通过在整个开发周期中应用安全最佳做法来保护代码和开发环境的建议。
工作负荷的核心是实现业务逻辑的组件。 这些组件可以是低代码元素（例如画布应用和流）和代码优先元素（例如插件）的组合。 构成工作负荷的所有组件都必须没有安全缺陷，以确保保密性、完整性和可用性。
使用标识和网络控制来保护基础结构平面很重要，但还不够。 防止 Power Platform 工作负荷的不佳实施以及这些工作负荷中的活动受到攻击，以增强整体安全态势。 将安全性集成到开发生命周期的流程本质上是一个强化流程。 与资源强化一样，加强代码开发也与上下文无关。 重点是增强安全性，而不是应用程序的功能要求。
定义
| 术语 | 定义 |
|---|---|
| 安全开发生命周期 (SDL) | 提供的一组做法 Microsoft ，支持安全保证和合规性要求。 |
| 软件开发生命周期 (SDLC) | 用于开发软件系统的多阶段系统化流程。 |
关键设计策略
安全措施应在多个点集成到现有软件开发生命周期 (SDLC)，以确保：
- 设计选择不会导致安全漏洞。
- 低代码和代码优先组件以及配置不会由于可利用的实现和不正确的编码做法而产生漏洞。
- 低代码和代码优先组件以及部署流程不会发生篡改。
- 通过事件揭示的漏洞得到缓解。
- 合规性要求不会受到损害或减少。
- 审核日志记录在所有环境中实现。
以下部分提供 SDLC 常见阶段的安全策略。
要求阶段
要求阶段的目标是收集和分析应用程序工作负荷的功能性和非功能性要求或工作负荷的新功能。 此阶段非常重要，因为它有助于创建根据工作负荷目标定制的防护措施。 在整个开发生命周期的每个阶段，保护工作负荷的数据和完整性应该是一项核心要求。
例如，考虑用户将在应用程序内输入和修改数据的工作负荷。 安全设计选择应涵盖用户与数据交互的保证，例如对用户身份进行身份验证和授权、仅允许对数据执行允许的操作。 非功能性要求涵盖可用性、实用性和可维护性。 安全选择应包括分段边界、防火墙入口和出口以及其他跨领域安全问题。
所有这些决策都应该能很好地定义工作负荷的安全状况。 在商定的规范中记录安全要求，并将其反映在积压工作中。 该文档应明确说明安全投资，以及如果投资未获得业务利益干系人批准，企业愿意承担的权衡和风险。 例如，您可能会记录在 Power Platform 环境中使用 IP 防火墙的需求，通过限制 Dataverse 只能访问允许的 IP 位置来保护组织数据。 如果业务利益干系人没有准备好接受使用托管管径等解决方案的额外成本，他们必须准备好接受从公共位置（例如咖啡店）访问组织资源的风险。 再比如，假设您的应用程序必须连接到第三方数据源。 为此，Power Platform 可能有一个现成的连接器，但它可能不支持安全团队批准的身份验证要求。 在这种情况下，安全利益干系人可能愿意接受使用未审批身份验证方法的风险。 或者，您可以探索使用自定义连接器，同时权衡开发时间增加和潜在项目延迟的利弊。
安全要求收集是此阶段的关键部分。 如果不进行此工作，设计和实现阶段将基于未说明的选择，这可能会导致安全漏洞或要求更改，从而增加开发时间。 您可能需要稍后更改实现以适应安全性，这可能很昂贵。
设计阶段
在此阶段期间，安全要求将转换为技术要求。 在技术规范中，记录所有设计决策，以防止在实现期间出现歧义。 下面是一些典型任务：
定义体系结构的安全维度 使用安全控件覆盖体系结构。 例如，在网络隔离边界上实际使用的控件、工作负荷组件所需的标识和身份验证方法的类型以及要使用的加密方法的类型。
评估平台提供的可供性。 了解您与 Power Platform 之间的责任划分非常重要。 避免与 Power Platform 本机安全控件重叠或重复。 您将获得更好的安全覆盖范围，并且能够根据应用程序需求重新分配开发资源。
例如，与其创建自定义逻辑来对应用和流中未经批准的使用模式进行被动识别和警报，不如使用数据丢失防护策略来对连接器的使用方式进行分类。
仅选择受信任的参考实施、模板、代码组件、脚本和库。 您的设计还应指定安全版本控制。 应用程序依赖项应源自受信任的参与方。 第三方供应商应能够满足您的安全要求 并共享其负责任的披露计划。 应及时报告任何安全事件，以便采取必要的操作。 此外，组织可能禁止某些库或引用实现。 例如，即使它安全且没有漏洞，但由于它使用了您的组织尚未批准的功能、许可限制或引用实现的支持模型，它可能仍被禁止。
为了确保遵循本指南，请维护已批准和/或未经批准的框架、库和供应商的列表，并确保制作者熟悉此列表。 如果可能，请在开发管道中放置守卫以支持列表。 尽可能自动使用工具来扫描依赖项中的漏洞。
安全地存储应用程序机密。 安全地实现应用程序机密和应用程序使用的预共享密钥的使用。 凭据和应用程序机密绝不应存储在工作负荷（应用或流）的源代码中。 使用 Azure 密钥保管库等外部资源来确保，如果源代码可供潜在攻击者使用，则无法获取进一步的访问权限。
安全连接到您的数据。 利用 Microsoft Dataverse 提供的强大安全功能保护您的数据，例如基于角色的安全性和列级别安全性。 对于其他数据源，请使用采用安全身份验证方法的连接器。 避免使用纯文本格式存储用户名和密码的查询。 避免用于创建自定义连接器的 HTTP。
定义最终用户与工作负荷和数据交互的方式。 考虑用户是否将直接访问数据、需要的访问级别以及用户可以从何处访问数据。 考虑如何与最终用户共享应用程序。 确保仅向需要访问应用和数据的人授予访问权限。 避免复杂的安全模型，以鼓励使用解决方法来避免安全阻止程序。
避免硬编码。 避免对 URL 和密钥进行硬编码。 例如，避免在 Power Automate HTTP 操作中对后端服务的 URL 或密钥进行硬编码。 而是使用自定义连接器，或对 URL 使用环境变量，对 API 密钥使用 Azure 密钥保管库。
定义测试计划。 为安全要求定义明确的测试用例。 评估是否可以在管道中自动执行这些测试。 如果您的团队有手动测试的流程，请包括这些测试的安全要求。
备注
在此阶段执行威胁建模。 威胁建模可以确认设计选择是否与安全要求保持一致，并公开应缓解的差距。 如果工作负荷处理高度敏感的数据，请投资可帮助您进行威胁建模的安全专家。
初始威胁建模练习应在定义软件的体系结构和高级设计时在设计阶段进行。 在该阶段执行此操作有助于在将潜在安全问题纳入系统结构之前识别它们。 但是，此练习不是一次性活动。 这是一个持续的流程，应该在整个软件的演变过程中继续。
有关更多信息，请参阅有关威胁分析的建议。
开发和测试阶段
在此阶段期间，目标是防止代码、生成和部署管道中出现安全缺陷和篡改。
在安全代码实践方面接受过良好培训
开发团队应接受安全编码实践方面培训。 例如，开发人员应熟悉 Microsoft Dataverse 中的安全概念以实施最小特权安全模型，熟悉模型驱动应用的内容安全策略以限制嵌入到受信任域，并熟悉连接器/本地网关身份验证方法。
应要求开发人员先完成此培训，然后才能开始处理 Power Platform 工作负荷。
执行内部同行代码评审以促进连续学习。
使用代码分析工具
解决方案检查器应该用于 Power Platform 资源，并且可以检查任何传统代码的源代码是否存在潜在安全缺陷，包括代码中是否存在凭据。 识别源代码和配置文件中可能的凭据和机密暴露实例。 现在是审查如何在生产中处理连接凭据的好时机。
执行模糊测试
使用格式错误的数据和意外数据检查漏洞和验证错误处理，这对于包括 Power Pages 的解决方案尤其重要。
编写足够多的代码
减少代码占用空间时，还可以减少出现安全缺陷的可能性。 重用已在使用且已通过安全验证 的代码和库，而不是复制代码。 对版本、漏洞和法律责任进行开源软件检测和检查。 开放源代码 Power Platform 资源的数量不断增加，因此这一点不应忽视。 如果可能，应在设计阶段讨论这一点，以避免出现紧急问题。
保护开发人员环境
开发人员工作站需要通过强大的网络和标识控制来保护，以防止暴露。 确保努力应用安全更新。
源代码存储库也必须得到保护 。 在需要知道的基础上授予对代码存储库的访问权限，并尽可能减少漏洞暴露，以避免攻击。 制定一个全面的流程来审查代码 中的安全漏洞。 为此，请使用安全组，并实施基于业务理由的审批流程。
保护代码部署
仅仅保护代码是不够的。 如果它在可利用的管道中运行，则所有安全工作都是徒劳无益且不完整的。 还必须保护 生成和发布环境，因为您希望防止不良行为者在管道中运行恶意代码。
维护集成到应用程序中的每个组件的最新库存
集成到应用程序中的每个新组件都会增加受攻击面。 为了确保在添加或更新新组件时正确负责并发出警报，应提供这些组件的库存。 定期检查清单与生成流程中的内容是否匹配。 这样做有助于确保不会意外添加包含后门或其他恶意软件的新组件。
我们建议针对您的部署使用 Power Platform 的管道。 使用 GitHub Actions 扩展管道。 如果您使用 GitHub 工作流，则 Microsoft首选授权的任务。 此外，验证任务，因为它们在管道的安全性上下文中运行。
了解服务主体在部署中的使用。
生产阶段
生产阶段提供了修复安全漏洞的最后一个负责任的机会。 保留生产中发布的黄金映像的记录。
保留版本控制的项目
保留所有已部署资产及其版本的目录。 在事件会审、缓解问题以及使系统恢复工作状态时，此信息非常有用。 还可以将版本控制的资产与已发布的常见漏洞和暴露 (CVE) 通知进行比较。 应使用自动化来执行这些比较。
紧急修复
自动化管道设计应能够灵活地支持常规部署和紧急部署。 这种灵活性对于支持快速且负责任的安全修复非常重要。
发布通常与多个审批关口相关联。 请考虑创建紧急流程来加速安全修复。 此流程可能涉及团队之间的通信。 管道应允许快速前滚和回滚部署，以解决在常规部署生命周期之外发生的安全修复、关键 bug 和代码更新。
备注
始终优先考虑安全修复，优先于便利性。 安全修复不应引入回归或 bug。 如果要通过紧急管道加速修复，请仔细考虑可以绕过哪些自动测试。 根据执行时间评估每个测试的值。 例如，单元测试通常可快速完成。 集成或端到端测试可能长时间运行。
将不同的环境分开
不应在较低环境中使用生产数据**，因为这些环境可能没有生产环境具有的严格安全控制。 避免从非生产应用程序连接到生产数据库，并避免将非生产组件连接到生产网络。
使用渐进式公开
使用渐进式公开，根据所选条件向部分用户发布功能。 如果出现问题，将对这些用户造成的影响降到最低。 此方法是一种常见的风险缓解策略，因为它减少了公开区域。 随着该功能的成熟，并且您对安全保证更加有信心，您可以逐渐将其发布给更广泛的用户。
维护阶段
此阶段的目标是确保安全状况不会随着时间的推移而下降。 SDLC 是一个正在进行的敏捷流程。 前一阶段中介绍的概念适用于此阶段，因为要求会随时间的推移而变化。
持续改进。 通过考虑代码评审、反馈、经验教训以及 Power Platform 推出的新功能，持续评估和提高软件开发流程的安全性。
停用过时或不再使用的旧资产 。 这样做会减少应用程序的公开区域。
维护还包括事件修复。 如果在生产中发现问题，需要立即将其重新集成到流程中，这样它们就不会重复发生。
持续改进安全编码做法，以跟上威胁形势。
Microsoft Power Platform 中的 SDL
Power Platform 建立在安全设计的文化和方法之上。 通过 Microsoft行业领先的 安全开发生命周期 （SDL）和 威胁建模 实践，文化和方法都得到了不断加强。
威胁建模审查流程可确保在设计阶段识别威胁，并缓解和验证威胁，以确保威胁已得到缓解。
威胁建模还考虑通过持续的定期检查对已投入使用的服务进行的所有更改。 依靠 STRIDE 模型有助于解决最常见的不安全设计问题。
Microsoft的 SDL 相当于 OWASP 软件保障成熟度模型 （SAMM）。 两者都建立在安全设计对于 Web 应用程序安全性不可或缺的前提之上。 有关详细信息，请参阅 OWASP 前 10 大风险：Power Platform 中的缓解措施。
Power Platform 便利化
Microsoft 安全开发生命周期（SDL）推荐可应用于开发生命周期的安全做法。 有关更多信息，请参阅 Microsoft 安全开发生命周期。
Defender for DevOps 和 SAST（静态应用程序安全测试）工具包含在 GitHub Advanced Security 和 Azure DevOps 中。 这些工具可帮助您跟踪组织的安全分数。
通过解决方案检查器，您可以使用一组最佳实践规则对解决方案执行各种静态分析检查，并快速确定这些问题模式。 请参阅使用解决方案检查器验证解决方案。
相关信息
- 应用程序生命周期管理（ALM） Microsoft Power Platform
- 管道概述 Power Platform
- 应用程序生命周期管理 Power Platform
- 解决方案架构师系列：规划应用程序生命周期管理 Power Platform
- 在解决方案中使用环境变量
- 使用解决方案检查器验证您的解决方案
- Copilot Studio 安全和治理
安全清单
请参考整套建议。