security入门示例（Security-安全性架构设计）

1 安全性目的和作用

软件安全问题从内因和外因说起，内部因素是指软件的内部漏洞。现代的信息系统规模大而且复杂性高，一般在开发软件漏洞不可避免，尤其大型软件的代码行数可达百万行，而软件缺陷的增长速度趋向于代码行数的平方而变化，代码行数越多，软件的安全风险也随之增加。显著影响软件复杂性的其他因素还包括代码紧密程度、补丁与其他部署后所做的修改之间的重叠率，以及严重的体系结构等问题。

软件安全问题的外因是目前的软件开发管理中，很多公司项目外包只注重软件功能而不关注对安全风险的管理，也埋下了很多隐患。由于劣币驱逐良币效应的存在，使得很多服务商不注重软件安全开发，给很多软件项目留下来漏洞风险。

随着模块化和代码的复用的日益平凡，大量的共享库被程序员使用以提高开发的效率，这些共享库来自开源软件，针对这些共享库的攻击，攻击者能将恶意代码植入这些共享库，从而随着软件的发布进入最终的用户计算环境中，也埋下了风险。

软件安全设计的目的在于将安全属性设计到软件架构中去，以实现软件产品本质的安全性。软件安全设计对于软件安全有着举足轻重的作用，大多数软件安全问题都是由于软件设计上的安全性考虑不足或不完整导致的。

2 安全性关注点

网络安全要求：

1. 保证主要网络和通信线路冗余；
2. 保证网络各个部分的带宽满足业务高峰期需要；
3. 加强网络访问控制，例如WAF防火墙；

主机安全要求：

1. 具有身份认证与标识、鉴别功能；
2. 控制用户对资源的访问权限;

应用安全要求：

1. 对用户进行资源访问授权；
2. 通信完整性，通过哈希值、摘要保证通信完整性；
3. 通信保密性要求，通过专用的通信协议或加密的方式保证通信过程的加密性。
4. 系统提供完整的交易日志；

数据安全要求：

1. 保证数据完整性，保密性；
2. 提供完备的和切实可行的数据备份与恢复方案，以及切换演练和应急切换步骤。

3 SDL简介

SDL的全称是Security Development Lifecycle，即：安全开发生命周期。由微软最早提出，是一种专注于软件开发的安全保障流程，是一个帮助开发人员构建更安全的软件和解决安全合规要求的同时降低开发成本的软件开发过程。

SDL的核心理念就是将安全考虑集成在软件开发的每一个阶段：需求分析、设计、编码、测试和维护。从需求、设计到发布产品的每一个阶段每都增加相应的安全活动，以减少软件中漏洞的数量并将安全缺陷降低到最小程度。

安全应用从安全设计开始，软件的安全问题很大一部分是由于不安全的设计而引入的，安全开发生命周期（SDL）是侧重于软件开发的安全保证过程，旨在开发出安全的软件应用。

4 SDL的12大实践

实践1-提供培训

安全是每个人的工作。开发人员、服务工程师以及程序和产品经理必须了解安全基础知识，并知道如何在软件和服务中构建安全性，以使产品更加安全，同时仍能满足业务需求并提供用户价值。

有效的培训将补充和加强安全策略、SDL实践、标准和软件安全要求。同时它以通过数据获取到的见解或新获得的技术能力为指导。

尽管安全是每个人的工作，但重要的是要记住，并非每个人都需要成为安全专家，也不是力求要成为熟练的渗透测试人员。但是，确保每个人都了解攻击者的视角，他们的目标和可能的技巧将有助于吸引所有人的注意力并提高团队知识水平。

实践2-定义安全要求

考虑安全性和隐私性是开发高度安全的应用程序和系统的基本方面，并且无论使用何种开发方法，都必须不断更新安全性要求，以反映所需功能的变化和威胁态势的变化。

显然，定义安全需求的最佳时间是在初始设计和规划阶段，因为这允许开发团队通过最小化中断的方式集成安全性。影响安全要求的因素包括（但不限于）法律和行业要求，内部标准和编码惯例，对先前事件的回顾以及已知威胁。这些要求应通过工作跟踪系统或通过工程线路得出的测量技术来跟踪。

实践3-定义指标和合规性报告

必须定义安全质量的最低可接受级别，并使工程团队有责任去达到该标准。尽早定义这些有助于团队了解与安全问题相关的风险，在开发过程中识别和修复安全缺陷，并在整个项目中应用标准。 设置有意义的缺陷门栏涉及明确定义安全漏洞的严重性阈值（例如，必须在指定的时间范围来修复发现具有“严重”或“重要”严重性等级的所有已知漏洞），并且在设置好之后就不能放松。

实践4-执行威胁建模

威胁建模应在存在重大安全风险的环境中使用。威胁建模可以应用于组件、应用程序或系统级别。通过这种做法，开发团队可以在计划的操作环境中并以结构化方式考虑，记录和讨论设计的安全隐患。

将结构化方法应用于威胁情景可帮助团队更有效，更低成本地识别安全漏洞，确认来自哪些威胁的风险，然后选择安全功能并建立适当的缓解措施。

实践5-建立设计要求

SDL通常被认为是保证活动，可帮助工程师实施“安全功能”，因为功能在安全性方面经过精心设计。为了实现这一点，工程师们通常将依赖于安全功能，例如加密，身份验证，日志记录等。在许多情况下，安全功能的选择或实施已被证明是如此复杂，以至于设计或实施的选择很可能也会导致漏洞。因此，至关重要的是要始终如一地应用这些应用程序，并对它们提供的保护保持一致的理解。

实践6-定义和使用加密标准

随着移动和云计算的兴起，确保所有数据（包括安全敏感信息以及管理和控制数据）在传输或存储时免受意外泄露或更改至关重要。加密通常用于实现这一点。在使用加密的任何方面做出错误的选择都可能是灾难性的，最好制定明确的加密标准，提供加密实现的每个元素的细节。一个好的一般规则是，只使用经过行业审查的加密库，并确保它们的实现方式能够在需要时轻松替换。

实践7-管理使用第三方组件的安全风险

如今，绝大多数软件项目都是使用第三方组件（包括商业组件和开源组件）构建的。选择要使用的第三方组件时，重要的是要了解它们中的安全漏洞可能会对集成它们的较大系统的安全性产生影响。拥有准确的第三方组件清单并制定发现新漏洞时的响应计划将大大有助于降低此风险。应根据组织的风险承受能力、使用的组件类型以及安全漏洞的潜在影响，应该考虑到进行更多的验证核实。了解有关管理使用开源软件等第三方组件的安全风险的更多信息。

实践8-使用认可的工具

定义并发布已批准工具以及这些工具相关的安全检查列表，例如编译器/链接器选项和警告。工程师应努力使用批准工具的最新版本，例如编译器版本，并利用新的安全分析功能和保护。

实践9-执行静态分析安全性测试（SAST）

Static Analysis Security Testing。在编译之前，分析源代码提供了一种高度可扩展的安全代码检查方法，并有助于确保遵循安全的编码策略。SAST通常集成到提交流程中，以便在每次构建或打包软件时识别漏洞。但是，某些产品集成到开发人员环境中，以发现某些缺陷，例如存在不安全或其他被禁止的功能，却在开发人员积极编码时，替换了那些原本更安全的方法。没有一刀切的解决方案，开发团队应确定执行SAST的最佳频率，并可能部署多种策略，以便在开发产品与足够的安全保障之间取得平衡。

实践10-执行动态分析安全性测试（DAST）

对完全编译或打包的软件执行运行时验证将检查功能，这些功能仅在所有组件都已集成并运行时才显而易见。通常使用工具或一组预先构建的攻击或专门监视应用程序行为的内存损坏，用户特权问题和其他关键安全性问题的工具来实现此目的。与SAST相似，没有一刀切的解决方案，尽管某些工具（例如Web应用程序扫描工具）可以更轻松地集成到持续集成/持续交付流程中，而其他DAST测试（例如模糊测试）则需要不同的解决方案方法。

实践11-执行渗透测试

渗透测试是由熟练的安全专家模拟黑客行为，执行软件系统的安全性分析。渗透测试的目的是发现由编码错误，系统配置错误或其他操作部署弱点导致的潜在漏洞，因此，该测试通常可以发现种类最多的漏洞。渗透测试通常与自动和手动代码检查结合使用，以提供比通常可能更高的分析水平。

实践12-建立标准的事件响应流程

制定事件响应计划对于帮助应对随着时间推移可能出现的新威胁至关重要。应与组织的专用产品安全事件响应团队（PSIRT）协调创建该事件响应计划。该计划应包括在安全紧急情况下应与谁联系，并建立安全服务协议，这些协议包括考虑到从公司组织的其他团队继承的代码和第三方的代码等。事件响应预案应在需要事件发生之前进行演练。

5 威胁建模

威胁建模是一种分析应用程序安全性的结构化方法，可以用来识别、量化和降低应用程序安全风险。威胁建模由微软2000年左右提出，作为SDL的核心模块且可实践的应用安全设计分析方法，用于识别潜在的威胁和建议，以帮助降低风险并在开发生命周期的早期实现安全目标。

应该在什么时候做威胁建模：

1. 新产品或新功能的设计阶段应开展威胁建模，发现风险、制定消减措施，消减措施是安全需求的一部分，需落入产品需求跟踪，确保产品安全。
2. 系统运行过程中也可以开展威胁建模，发现的风险可以为企业渗透测试提供支持，尽可能发现更多的漏洞。

有五个主要的威胁建模步骤：Define（定义安全要求）、Diagram（创建数据流图）、Identify（识别威胁）、Mitigate（缓解威胁）、Validate（验证威胁）。

STRIDE威胁建模是由微软提出的一种威胁建模方法，该方法将威胁类型分为Spoofing（仿冒）、Tampering（篡改）、Repudiation（抵赖）、Information Disclosure（信息泄漏）、Denial of Service（拒绝服务）和 Elevation of Privilege（权限提升）。这六种威胁的首字母缩写即是STRIDE，STRIDE威胁模型几乎可以涵盖目前绝大部分安全问题。

威胁	说明
仿冒（S）	先进行非法访问，并使用另一用户的身份验证信息，例如用户名和密码
篡改（T）	恶意修改数据。 示例包括未经授权更改持久保存的数据（例如保存在数据库中的数据），更改通过开放网络（例如 Internet）在两台计算机之间传输的数据
抵赖（R）	指用户拒绝执行某个操作，但其他操作方无法证实这种拒绝无效 - 例如，某个用户在无法跟踪受禁操作的系统中执行非法操作。 不可否认性是指系统对抗否认性威胁的能力。 例如，购买某个产品的用户可能需要在收货时签收该产品。 然后，供应商可以使用签收单来证明该用户确实收到了包裹
信息泄露（I）	将信息透露给本应不该有权访问这些信息的个人 — 例如，用户能够读取他们未授权访问的文件，或者入侵者能够读取在两台计算机之间传输的数据
拒绝服务（D）	拒绝服务 (DoS) 攻击会拒绝向有效用户提供服务 — 例如，使 Web 服务器暂时不可用。 必须防范某些类型的 DoS 威胁，这只是为了提高系统的可用性和可靠性
权限提升（E）	无特权用户获得特权访问权限，从而拥有足够的访问权限来入侵或破坏整个系统。 特权提升威胁包括攻击者有效突破系统防御，成为受信任系统本身的一部分，这是非常危险的局面

STRIDE威胁建模的总体流程：

5.1 定义安全要求

定义安全需求的最佳时间是在初始设计和规划阶段，因为这允许开发团队通过最小化中断的方式集成安全性。影响安全要求的因素包括（但不限于）法律和行业要求，内部标准和编码惯例，对先前事件的回顾以及已知威胁。这些要求应通过工作跟踪系统或通过工程线路得出的测量技术来跟踪。

灵活定义攻击者的目标，组织要保护的资产和信任级别，如：存储、源代码、主机、数据库、凭据、行级数据，知识产权等。公有云、私有云不同的责任共担模型就清晰给出了不同的业务需要关注哪些资产的示例，云上资产的建模更关注安全的信任边界。

5.2 创建数据流图

建模的第一步就是分解业务场景，绘制数据流图(DFD)。威胁建模针对的是一个个具体场景，所以首先需要对我们的系统根据实际情况进行业务场景的分解，比如登录场景、交易场景、审批场景、灾备场景等等，具体是什么场景以及有多少个场景，是和实际的系统和业务息息相关的。分解完业务场景以后，就对一个一个的场景分别进行STRIDE威胁建模，每个场景的STRIDE威胁建模是相对独立的。 首先对一个具体的场景绘制数据流图（DFD），一个简单Web应用的数据流图如下所示：

数据流图包括四个核心元素：外部实体、数据流、处理过程及数据存储。

• 外部实体：可以是浏览器、移动设备、人、进程等实体。

• 数据流：可以是功能调用、网络数据流等。

• 处理过程：可以是服务、组件等。

• 数据存储：除了数据库也可以是文件、注册表、共享存储、缓存等。

5.3 识别威胁

团队通过了解自己的系统可能容易受到哪些威胁来开始威胁建模。识别威胁后，团队评估每个威胁，以确定它们变成真正攻击的可能性，以及这种攻击的影响。

STRIDE威胁建模方法已经明确了每个数据流图元素具有不同的威胁，其中外部实体只有仿冒（S）、抵赖（R）威胁，数据流只有篡改（T）、信息泄露（I）、拒绝服务（D）威胁，处理过程有所有六种（STRIDE）威胁，存储过程有篡改（T）、信息泄露（I）、拒绝服务（D）威胁，但如果是日志类型存储则还有抵赖（R）威胁。具体可以对照如下表格进行威胁识别：

5.4 缓解威胁

根据不同的数据流图元素及威胁，相应的缓解措施也不相同。如本文示例数据流图中外部实体用户的仿冒威胁，其缓解措施简单来说就是对用户身份进行认证。对于一个Web应用来说，缓解仿冒威胁不仅需要较强的认证机制，还需要防止恶意攻击者用暴力破解、口令猜测等方法绕过认证从而造成仿冒用户的威胁。如果笔者来提出该用户仿冒威胁的缓解措施的话。

威胁	安全属性	定义	举例	消减措施
仿冒（S）	认证	冒充人或物	冒充其他用户账号	身份管理、认证（密码认证、单点登录、双因素、证书认证）、会话管理
篡改（T）	完整性	修改数据或代码	修改订单信息	完整性校验、访问控制
抵赖（R）	审计	不承认做过某行为	不承认修改行为	安全管理、安全审计、监控、保护时间戳
信息泄露（I）	保密性	信息被泄露或窃取	用户信息被泄露	敏感信息保护、数据加密、访问控制
拒绝服务（D）	可用性	消耗资源、服务可不用	DDOS导致网站不可用	负载均衡、防DDOS
权限提升（E）	授权	未经授权获取、提升权限	普通用户提升到管理员	用户组管理、访问控制列表、授权最小化

5.5 验证威胁

在威胁建模完成后，需要对整个过程进行回顾，不仅要确认缓解措施是否能够真正缓解潜在威胁，同时验证数据流图是否符合设计，代码实现是否符合预期设计，所有的威胁是否都有相应的缓解措施。最后将威胁建模报告留存档案，作为后续迭代开发、增量开发时威胁建模的参考依据。

6 SDL实战经验准则

1.与项目经理进行充分沟通，排除足够的时间

项目的安全评估，在开发的不同环节有着不同的安全要求，而这些安全要求都需要占用开发团队的时间，因此在立项阶段与项目经理进行充分沟通十分重要。

明确在什么阶段安全工程师需要介入，需要多长时间完成安全工作，同时预留多少时间给开发团队用以开发安全功能或者修复安全漏洞。

预留出必要时间对项目的时间管理也具有积极意义，否则很容易出现项目快发布，安全团队突然说还没有实施安全检查的情况。这种情况只能导致两种结果：项目因为安全检查而延期发布，开发团队、测试团队全员一起重新做安全检查；项目顶着风险发布，专门建立小项目专门修复安全问题。

两种结果都十分糟糕，为避免发生此类情况，在立项初期就应该与项目经理进行充分沟通，留出足够多的时间给安全检查。

2.规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏

安全事件产生的原因并不复杂，往往发生在大家忽略的地方。在实施SDL的过程中，技术方案的好坏不是最关键的，最关键的是要覆盖到全部项目，防止边边角角的小项目没有被覆盖到导致安全事件的发生。

公司规模较小时，员工沟通成本低，很容易保证所有项目都能及时通知到安全团队。但公司大到一定规模时，出现多个部门和多个项目组，沟通成本大大增加，这种情况下就很有必要从公司层面建立完善的“立项制度”。

SDL依托于软件工程，立项也属于软件工程的一部分。如果能集中管理立项过程，SDL就有可能在这一阶段覆盖到公司所有项目。相对于测试阶段和发布阶段来说，在立项阶段就有安全团队介入，留给开发团队的反应事件也更加富足。

3.树立安全部门的权威，项目必须由安全部门审核完成后才能发布

实施SDL的过程中，除了教育项目组成员（项目经理、产品经理、开发人员、测试人员等）实施安全的好处外，安全部门还需要树立一定的权威。

必须通过规范和制度，明确要求所有项目必须在安全审核完成后才能发布。如果没有这样的权威，对于项目组来说，安全就变成了一项可有可无的东西。如果产品急着发布，很可能因此砍掉或裁减部分安全需求，也可能延期修补漏洞，从而导致风险升高。

权威的树立在公司里需要从上往下推动，由技术总负责人或者产品总负责人确认安全部门实施。在具体实施时可以依据公司的不同情况在相应的流程中明确。负责产品的质量保障部门，负责产品发布的运维部门，都可以称为制度的执行者。

“项目必须由安全部门审核完成之后才能发布”这句话并非绝对，背后含义实为树立安全部门的权威。因此在实际实施SDL的过程中，安全也可能对业务妥协。因此在业务时间压力非常大，问题不是很严重的情况下，可以考虑事后再进行修补，或使用临时方案应对紧急情况。安全最终是为业务服务的。

4.将技术方案写入开发、测试的工作手册中

对于开发、测试团队，对工作最有效的约束方式即工作手册。对于开发来说手册即为开发规范。开发规范涉及的方面比较广，如函数名的大小写方式、注释的写法等。（腾讯开源开发安全指南链接如下：腾讯代码安全指南开源，涉及CC 、Go等六门编程语言 - FreeBuf网络安全行业门户）

但开发团队的规范内容鲜有涉及到安全规范，因此与其事后通过代码审核的方式告知开发者代码中存在漏洞，需要修补，不如直接将安全技术方案写入开发者的代码规范当中。比如规定好哪些函数禁用，只能使用哪些函数；或封装好安全功能，在代码规范中注明什么情况下使用什么样的安全API。

对于程序员来说，记住代码规范中的要求远比记住复杂的安全原理要容易得多。一般程序员只需要记住如何使用安全功能即可，无需深究原理。

对于测试人员的要求是相似的。在测试的工作手册中加入安全测试的方法，清楚列出每一个测试用例，每一步实现什么功能，这样一些基础的安全测试就可以交由测试人员完成，最后生成一份安全测试报告即可。

5.给工程师培训安全方案

微软SDL框架中，第一项就是培训。培训的作用不可小视，它是技术方案与执行者之间的调和剂。在准则四中提到，要将安全技术方案最大程度地写入代码规范等工作手册中，但同时要让开发者有机会了解到安全方案地背景，这也是很有意义的，可以通过培训达到这个目的。

培训最重要的目的是在项目开发之前，能够让开发者之傲如何写出安全的代码，从而节约开发成本。如果开发者未经培训，可能在代码审核阶段会被找出非常多的安全bug，修复每一个安全bug都将消耗额外的开发时间；同时开发者若不理解这些开发问题，由安全工程师对每一个问题进行解释和说明也是一份额外的时间支出。

因此在培训阶段贯彻代码规范中的安全需求，可以极大地节约开发时间，对整个项目组都有着积极的意义。

6.记录所有的安全bug，激励程序员编写安全的代码

为了更好地推动项目组写出安全的代码，可以尝试给每个开发团队设立绩效。被发现漏洞最少的团队可以得到奖励，并将结果公布出来。如此，项目组之间将产生竞争氛围，开发者更努力于遵守安全规范，写出安全的代码，还能帮助不断提高开发者的代码质量，形成良性循环。

7 SDL安全设计原则

SDL安全设计核心原则:

• Attack Surface Reduction：攻击面最小化
• Basic Privacy: 基本隐私
• Least Privilege: 权限最小化
• Secure Defaults: 默认安全
• Defense in Depth：纵深防御
• Threat Modeling：威胁建模

7.1 攻击面最小化

攻击面是指程序任何能被用户或者其它程序所访问到的部分，这些暴露给用户的地方往往也是最可能被恶意攻击者攻击的地方。

攻击面最小化即是指尽量减少暴露恶意用户可能发现并试图利用的攻击面数量。软件产品的受攻击面是一个混合体，不仅包括代码、接口、服务，也包括对所有用户提供服务的协议。尤其是那些未被验证或者远程的用户都可以访问到的协议，安全人员在攻击面最小化时首先要对攻击面进行分析，攻击面分析就是枚举所有访问入库、接口、协议一剂可执行代码的过程，从高层次来说，攻击面分析着重于:

• 降低默认执行的代码量
• 限制可访问到代码的人员范围
• 限定可访问到代码的人员身份
• 降低代码执行所需权限

7.2 基本隐私

用户使用软件时无可避免个人信息被收集、使用甚至分发，企业则有责任和义务建立保护个人信息的保护措施，抵御敌对攻击行为，确保用户基本隐私的安全性。隐私安全是建立可信任应用程序的关键因素。

在软件设计时考虑用户基本隐私的必要性及意义有:

• 履行法律规定和义务
• 增加客户的信赖
• 防止堵塞部署

对于特殊的软件或者全球性的产品，设计人员需要明确软件的行为及针对人群。尤其要考虑当地国家的法律法规，如美国儿童网路隐私保护法COPPA(Children’s Online Privacy Protection Act)等，企业在开发产品、服务时有必要制定明确的隐私准则，对获取、记录用户隐私的相关产品需有明确的要求和指导建议。

Tips:

• 只收集程序必须用到的隐私数据，并明确告知用户并征得用户同意;

• 微软对于用户隐私数据如密码、口令等均需要加密存储，最低要求是sha256 salt，对于更高要求的则使用PBKDF2算法加密存储;

7.3 权限最小化

如果一个应用程序或网站被攻击、破坏，权限最小化机制能够有效的将潜在损害最小化。常见的权限最小化实践如:

• 普通管理员/系统管理员等角色管理
• 文件只读权限/文件访问权限等访问控制
• 进程/服务以所需最小用户权限运行

在进行软件设计时，安全设计人员可以评估应用程序的行为及功能所需的最低限度权限及访问级别，从而合理分配相应的权限。如果程序特定情况必须要较高级别的权限，也可以考虑特权赋予及释放的机制。即便程序遭到攻击，也可以将损失降到最低。

Tips:

• Windows系统中网络进程、本地服务、用户进程的权限都较低且互相独立，分别为NETWORK SERVICE、LOCAL SERVICE、user权限，只有核心的重要进程实用SYSTEM权限;
• 最新版本的Office程序打开不可信来源的文档时，默认时不可编辑的，同时也是默认不可执行代码的，即使存在缓冲区溢出漏洞，也不会执行shellcode等恶意代码;

7.4 默认安全

默认安全配置在客户熟悉安全配置选项之前不仅有利于更好的帮助客户掌握安全配置经验，同时也可以确保应用程序初始状态下处于较安全状态。而客户可根据实际使用情况而决定应用程序安全与隐私的等级水平是否降低。

Tips:

• 在Win 7之后的Windows操作系统中，DEP(数据执行保护)默认是开启的。用户可设置选项改变DEP的状态;
• Win 10默认启用安全防护软件Windows Defender，用户可选择关闭;

7.5 纵深防御

与默认安全一样，纵深防御也是设计安全方案时的重要指导思想。纵深防御包含两层含义：首先，要在各个不同层面、不同方面实施安全方案，避免出现疏漏，不同安全方案之间需要相互配合，构成一个整体；其次，要在正确的地方做正确的事情，即：在解决根本问题的地方实施针对性的安全方案。

纵深防御并不是同一个安全方案要做两遍或多遍，而是要从不同的层面、不同的角度对系统做出整体的解决方案。

Tips:

• 针对XSS的防护，除了要对用户输入的特殊符号进行过滤，还要区分是否是富文本进而进行相应编码操作，在输入时过滤的同时在输出时也进行过滤操作。
• 即使做了十足的过滤、编码等安全防护，为了更一步确保缓解XSS攻击，Web站点也可以对Cookie启用HTTP-Only属性，确保即使发生XSS攻击，也可以阻止通过脚本访问Cookie的操作。

7.6 威胁建模

威胁建模是一种分析应用程序威胁的过程和方法。这里的威胁是指恶意用户可能会试图利用以破坏系统，和我们常说的漏洞并不相同。漏洞是一个特定的可以被利用的威胁，如缓冲区溢出、sql注入等。

作为SDL设计阶段的一部分安全活动，威胁建模允许安全设计人员尽在的识别潜在的安全问题并实施相应缓解措施。在设计阶段把潜在的威胁发现有助于威胁的全面和更有效的解决，同时也有助于降低开发和后期维护的成本。威胁建模的一般流程如下:

• 与系统架构师及设计人员沟通，了解设计详情
• 使用成熟的威胁建模方法分析当前设计潜在的安全问题
• 提出安全建议及对潜在威胁的缓解措施
• 对安全设计进行验证并对整个设计方案进行回顾并再次确认

微软使用的威胁建模方法是STRIDE威胁建模方法。为了便于安全人员快速便捷的进行威胁建模，微软开发基于STRIDE威胁建模方法的SDL Threat Modeling Tool威胁建模工具，该工具可以帮助安全人员画数据流图、分析威胁、生成并导出威胁建模报告。

参考资料：

https://www.microsoft.com/en-us/securityengineering/sdl/practices

https://learn.microsoft.com/zh-cn/azure/security/develop/threat-modeling-tool

---

往期其他热门文章：

Scalable-可扩展性架构设计

干货：程序员必备画图技能

推荐：本人使用频率最高的20款Mac软件（全）

干货：MAC上轻松搞定查看Java汇编代码

干货：RabbitMQ核心概念及工作原理

,