1. 课程导入与威胁建模定位

企业系统安全设计的核心挑战，不在于“有没有做安全”，而在于“安全是否被放在了正确的位置、针对了正确的对象、覆盖了正确的时机”。很多团队在项目上线前才补做渗透测试，结果发现架构层面的信任边界早已固化，修复一个越权漏洞往往要牵动多个服务；也有团队堆砌了大量安全设备，却说不清系统最关键的资产是什么、攻击者最可能从哪条路径进入。威胁建模（Threat Modeling）正是为了解决这类“方向性”问题而存在的方法：它在设计阶段就把系统拆解为资产、入口、数据流与信任边界，系统性地追问“谁会攻击、攻击什么、怎么攻击、会造成什么后果”，从而把有限的安全投入集中到真正高风险的位置。

企业系统安全设计的三个核心挑战

第一是攻击面持续扩张。现代企业系统通常由 Web 前端、API 网关、微服务、消息队列、数据库、第三方 SaaS 以及内部运维通道共同组成，任何一个对外暴露的接口、一个过度授权的服务账号、一条未加密的内部调用，都可能成为入口。第二是信任边界模糊。容器化与云原生让“内网”不再等于“可信”，服务间调用、跨租户数据访问、CI/CD 流水线权限，都需要重新定义谁信任谁、信任到什么程度。第三是安全介入时机滞后。需求阶段不识别威胁，设计阶段不约束权限模型，编码阶段就只能靠代码扫描事后补救，成本高且容易遗漏逻辑漏洞。

威胁建模在 SDL 中的位置

安全开发生命周期（SDL，Security Development Lifecycle）把安全活动嵌入需求、设计、开发、验证、发布、响应各个阶段。威胁建模属于设计阶段的核心活动，它上承需求阶段的安全与合规要求，下启开发阶段的安全编码规范、验证阶段的测试用例与发布阶段的风险评审。下图展示了威胁建模在 SDL 中的位置及其与相邻活动的输入输出关系。

从图中可以看到，威胁建模不是孤立的一次性动作，而是把需求阶段的安全要求“翻译”为设计阶段可执行的结构化分析，再输出给开发与验证阶段作为落地依据。缺少这一环，安全要求容易停留在文档里，测试也只能靠经验猜测重点。

课程目标与整体学习路径

本课程的目标不是让读者背下 STRIDE 或攻击树的定义，而是具备独立完成一次企业级威胁建模并推动消减措施落地的能力。具体包括：能够识别系统资产与信任边界；能够用数据流图（DFD）描述系统；能够针对不同对象套用 STRIDE、攻击树等方法产出威胁清单；能够结合 DREAD 或风险矩阵对威胁排序；能够把威胁转化为安全设计约束、编码规范与测试用例；能够在真实项目中组织一次轻量、可持续的威胁建模评审。

整体学习路径按“认知—方法—实践—落地”递进展开：先建立企业系统安全设计与威胁建模的整体认知（本章），再掌握资产识别、信任边界与数据流建模等基础技能，随后深入学习 STRIDE、攻击树、威胁排序与消减设计，最后通过完整案例把方法串成可复用的工作流，并讨论如何在团队中持续运营威胁建模。学习过程中建议始终带着一个自己熟悉的真实系统作为练习对象，每学完一种方法就回到该系统上做一次小规模分析，这样比单纯阅读方法定义更容易形成可迁移的能力。