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

威胁分析建议

适用于此 Azure Well-Architected Framework 安全清单建议：

SE：02	建立符合合规性要求、行业标准和平台建议的安全基线。 根据基线定期测量工作负载体系结构和操作，以随着时间的推移维持或改善安全状况。

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

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

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

定义 

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

关键设计策略

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

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

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

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

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

了解练习的范围

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

收集有关每个组件的信息

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

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

评估潜在威胁

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

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

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

缓解威胁

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

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

下面是一个示例：

提出此问题	确定控件...
是通过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) 记录了一种针对应用程序的威胁建模方法。

安全清单

请参阅完整的一组建议。

安全清单