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

威胁分析建议

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

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

相关指南： 有关保护开发生命周期的建议

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

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

定义 

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

关键设计策略

威胁建模是组织应集成到 SDLC 中的关键过程。 威胁建模不仅仅是开发人员的任务。 这是一个共同的责任：

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

在关键工作负载的业务需求方面，组织领导层和技术团队之间经常存在脱节。 这种断开连接可能会导致不需要的结果，尤其是安全投资。

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

安全要求充当威胁建模整个过程的指南。 为了使它成为有效的练习，工作负荷团队应具备安全思维模式，并在威胁建模工具中接受培训。

了解练习的范围

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

收集有关每个组件的信息

工作负荷体系结构关系图是收集信息的起点，因为它提供系统的可视表示形式。 此图突出显示了系统的技术维度。 例如，它显示用户流、数据通过网络移动的方式、数据敏感度级别和信息类型以及标识访问路径。

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

评估潜在威胁

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

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

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

缓解威胁

记录所有已识别的威胁。 对于每个威胁，如果这些控制失败，请定义安全控制措施和对攻击的响应。 定义一个过程和时间线，以最大程度地减少对工作负载中任何已识别漏洞的暴露，以便这些漏洞无法解除处理。

使用假定的违规方法。 它可以帮助识别设计中所需的控制措施，以在主要安全控制失败时降低风险。 评估主要控制措施失败的可能性。 如果失败，那么潜在的组织风险程度是多少？ 此外，补偿控制的有效性是什么？ 根据评估，应用深层防御措施来解决安全控制的潜在故障。

下面是一个示例：

提出这个问题	若要确定...
通过Microsoft Entra ID、传输层安全性（TLS）以及安全团队批准的另一种新式安全协议进行身份验证的连接： - 在用户和应用程序之间？ - 在应用程序组件和服务之间？	防止对应用程序组件和数据进行未经授权的访问。
是否仅限制对需要写入或修改应用程序中数据的帐户的访问权限？	防止未经授权的数据篡改或更改。
应用程序活动是否通过 Azure Monitor 或类似的解决方案记录并馈送到安全信息和事件管理（SIEM）系统中？	快速检测并调查攻击。
关键数据是否受安全团队批准的加密保护？	防止未经授权复制静态数据。
入站和出站网络流量是否通过 TLS 加密？	防止未经授权复制传输中的数据。
应用程序是否通过 Azure DDoS 防护等服务受到分布式拒绝服务（DDoS）攻击？	检测旨在使应用程序过载从而变为不可用的攻击。
应用程序是否存储登录凭据或密钥来访问其他应用程序、数据库或服务？	识别攻击是否可以利用你的应用程序攻击其他系统。
应用程序控制措施是否允许你满足监管要求？	保护用户的私有数据并避免合规性罚款。

跟踪威胁建模结果

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

在工作负荷团队积压工作过程中跟踪结果，以便及时负责。 将任务分配给负责缓解威胁建模识别的特定风险的个人。

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

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

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

Azure 便利化

Microsoft安全开发生命周期提供了一种威胁建模工具，可帮助完成威胁建模过程。 无需支付额外费用即可使用此工具。 有关详细信息，请参阅 “威胁建模”页。

示例

此示例基于安全基线（SE：01）中建立的 信息技术（IT）环境。 此方法可广泛了解不同 IT 方案中的威胁格局。

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

2. 潜在的攻击者。 攻击者会考虑随时可以轻松使用的各种工具来探索漏洞并开始攻击。

3. 安全控制。 作为威胁分析的一部分，确定用于保护解决方案的 Azure 安全服务以及这些解决方案的有效性。

4. 日志收集。 来自 Azure 资源和某些本地组件的日志可能会发送到 Azure Log Analytics，以便你可以了解开发的解决方案的行为，并尝试捕获初始漏洞。

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

6. Microsoft Defender for Cloud 可能会提出一些安全建议来改善安全状况。

相关链接

• STRIDE
• 威胁建模

社区链接

Open Web Application Security Project (OWASP) 记录了一种针对应用程序的威胁建模方法。

安全清单

请参阅完整的建议集。

安全清单