通过

有关威胁分析的建议

  • 项目

适用于此 Power Platform Well-Architected Security 清单建议：

SE:02 使用威胁建模来整合安全设计，以防止安全失效的实现。

在工作负荷的设计阶段期间，识别威胁、攻击、漏洞和应对措施的全面分析至关重要。 威胁建模是一项工程练习，包括定义安全要求、识别和缓解威胁以及验证这些缓解措施。 可以在应用程序开发或生产的任何阶段使用此技术，但它在新功能的设计阶段最为有效。

本指南介绍有关执行威胁建模的建议，以便您可以快速识别安全漏洞并设计安全防御。

定义

术语 定义
软件开发生命周期 (SDLC) 用于开发软件系统的多阶段系统化流程。
STRIDE Microsoft 定义的用于对威胁类型进行分类的分类。
威胁建模 用于识别应用程序和系统中的潜在安全漏洞、缓解风险和验证安全控制的流程。

关键设计策略

威胁建模是组织应集成到其 SDLC 中的关键流程。 威胁建模不仅仅是开发人员的任务。 这是以下两方之间共同承担的责任：

  • 工作负荷团队，负责系统的技术方面。
  • 业务利益干系人，了解业务成效，并在安全性方面具有既得利益。

在关键工作负荷的业务要求方面，组织领导层和技术团队之间经常存在脱节。 这种脱节可能会导致意外结果，尤其是对于安全投资。

当执行威胁建模练习时，应考虑业务和技术要求。 工作负荷团队和业务利益干系人必须就工作负荷的安全特定需求达成一致，以便他们可以在对策方面进行足够的投资。

安全要求充当整个威胁建模流程的指南。 若要使其成为一项有效的练习，工作负荷团队应具有安全思维模式，并接受威胁建模工具方面的培训。

了解练习的范围

清楚了解范围对于有效的威胁建模至关重要。 它有助于将工作和资源集中在最关键的领域。 此策略涉及定义系统的边界、盘点需要保护的资产，以及了解安全控制所需的投资级别。

收集有关每个组件的信息

工作负荷体系结构图表是收集信息的起点，因为它提供系统的可视化表示形式。 该图表突出显示系统的技术维度。 例如，它显示用户流、数据如何在工作负荷的不同部分之间移动、数据敏感度级别和信息类型，以及标识访问路径。

此详细分析通常可以提供对设计中潜在漏洞的见解。 了解每个组件的功能及其依赖项非常重要。

评估潜在威胁

从外到内的角度分析每个组件。 例如，攻击者如何轻松访问敏感数据？ 如果攻击者获得对环境的访问权限，他们是否可以横向移动，并可能访问甚至操纵其他资源？ 这些问题有助于了解攻击者如何利用工作负荷资产。

使用行业方法对威胁进行分类

Microsoft 安全开发生命周期使用的 STRIDE 是威胁分类方法之一。 对威胁进行分类有助于了解每个威胁的性质并使用适当的安全控制。

缓解威胁

记录所有已识别的威胁。 对于每个威胁，请定义安全控制，并在这些控制失败时对攻击做出响应。 定义一个流程和时间线，以最大程度地减少工作负荷中任何已识别的漏洞的暴露，以便这些漏洞得到解决。

使用假设违规方法。 它可以帮助确定设计中所需的控制措施，以在主要安全控制失败时缓解风险。 评估主要控制措施失败的可能性。 如果失败，潜在组织风险有多大？ 此外，补偿控制的有效性如何？ 根据评估，应用深层防御措施来解决安全控制的潜在失败。

下面是一个示例：

提出此问题 确定控制措施...
是通过 Microsoft Entra ID 进行身份验证的连接，还是使用安全团队批准的新式安全协议：

- 在用户和应用程序之间？

- 在应用程序组件和服务之间？

- 在用户和 AI 助手之间（代理）？		 防止未经授权访问应用程序组件和数据。
是否仅对需要在应用程序中写入或修改数据的帐户限制访问权限？ 防止未经授权的数据篡改或更改。
应用程序活动是否通过 Azure Monitor 或类似解决方案记录并馈送到安全信息和事件管理 (SIEM) 系统中？ 快速检测并调查攻击。
关键数据是否受安全团队批准的加密保护？ 防止未经授权复制静态数据。
入站和出站网络流量是否独立于安全团队批准的域？ 防止未经授权复制数据。
是否在环境中使用 IP 防火墙来防止从外部/公开位置（例如咖啡店）访问应用程序？ 防止从未经授权的公共位置访问。
应用程序是否存储用于访问其他应用程序、数据库或服务的登录凭据或密钥？ 识别攻击是否可以使用您的应用程序攻击其他系统。
应用程序控制措施是否允许您满足监管要求？ 保护用户的私有数据并避免合规性罚款。

跟踪威胁建模结果

强烈建议使用 Threat Modeling Tool。 工具可以自动执行识别威胁的流程，并生成所有已识别威胁的综合报表。 请务必将结果传达给所有感兴趣的团队。

将结果作为工作负荷团队积压工作的一部分进行跟踪，以便及时追究责任。 将任务分配给负责缓解威胁建模识别的特定风险的个人。

向解决方案添加新功能时，请更新威胁模型并将其集成到代码管理流程中。 如果发现安全问题，请确保有一个流程根据严重性对问题进行会审。 此流程应帮助您确定何时以及如何修正问题（例如，在下一个发布周期或更快的发布中）。

定期查看业务关键型工作负荷要求

定期与执行发起人会面以定义要求。 这些评审提供了一个使预期保持一致的机会，并确保将运营资源分配给计划。

Power Platform 便利化

Power Platform 建立在安全设计的文化和方法之上。 通过 Microsoft 行业领先的安全开发生命周期 (SDL) 和威胁建模实践，文化和方法均不断得到加强。

威胁建模审查流程可确保在设计阶段识别威胁，并缓解和验证威胁，以确保威胁已得到缓解。

威胁建模还考虑通过持续的定期检查对已投入使用的服务进行的所有更改。 依靠 STRIDE 模型有助于解决最常见的不安全设计问题。

Microsoft 的 SDL 相当于 OWASP 软件保障成熟度模型 (SAMM)。 两者都建立在安全设计对于 Web 应用程序安全性不可或缺的前提之上。

有关详细信息，请参阅 OWASP 前 10 大风险：Power Platform 中的缓解措施。

示例

此示例基于在有关建立安全基准的建议中建立的信息技术 (IT) 环境。 通过此方法，可大致了解不同 IT 场景的威胁环境。

开发生命周期角色。 开发生命周期中涉及许多角色，包括开发人员、测试人员、最终用户和管理员。 所有这些角色都可能遭到入侵，并通过故意创建的漏洞或威胁使环境面临风险。

潜在攻击者。 攻击者认为随时可以轻松使用各种工具来探索漏洞并开始攻击。

安全控件。 作为威胁分析的一部分，确定用于保护解决方案的 Microsoft、Azure 和 Power Platform 安全服务以及这些解决方案的有效性。

日志收集。 来自 Power Platform 资源和工作负荷中包含的其他组件（例如 Azure 资源和本地组件）的日志可能会发送到 Application Insights 或 Microsoft Purview，以便您可以了解开发的解决方案的行为，并尝试捕获初始漏洞。

安全信息事件管理 (SIEM) 解决方案。 即使在解决方案的早期阶段，也可以添加 Microsoft Sentinel，以便您可以生成一些分析查询来缓解威胁和漏洞，并在生产环境中预测安全环境。

安全清单

请参考整套建议。

安全清单