威胁建模从资产、边界与攻击路径推导控制

安全需求若只来自通用检查表，往往不知道在保护什么，也不知道控制失效会造成什么后果。威胁建模把系统放在攻击者和业务影响的视角下描述：识别资产、入口、信任边界、假设和潜在攻击路径，再决定降低风险的设计与验证方式。

威胁模型不是一张画完即归档的数据流图。系统边界、依赖、攻击能力和资产价值持续变化，模型也要随架构和事故更新。它的价值在于让安全决策可追踪，而不是预测所有未来攻击。

范围从资产和决策问题开始

范围可以是一项新功能、一个服务、完整业务流程或供应链环节。范围过大时讨论会停留在抽象威胁，过小时又忽略跨边界路径。应先写明这次要保护的资产、关键操作和不在范围内的部分。

资产不仅是数据库。身份、授权关系、签名密钥、业务额度、可用性、审计证据和用户隐私都可能需要保护。同一数据在不同阶段价值不同，例如重置令牌短期敏感，公开文档本身不敏感但发布权限敏感。

业务影响为排序提供依据。数据泄露、错误转账、服务中断和审计丢失不能只用一个“高危”标签比较，应描述受影响主体、规模、可逆性和发现时间。

数据流图或组件图应包含主体、进程、存储、外部依赖和数据流，并标出身份或信任变化的位置。互联网到网关是边界，低权限服务调用高权限服务也是边界，构建系统向生产发布制品同样是边界。

每条流需要协议、身份、数据类别和方向。只画“API 调用”无法判断是否有双向认证、消息是否重放、响应是否含敏感信息。异步队列、批处理、管理通道和恢复路径经常被遗漏，却可能拥有更高权限。

部署现实要进入模型。容器图若忽略节点、云控制面和运维终端，就无法分析凭据窃取后的横向移动。第三方服务也不能画成无内部风险的方框，应记录依赖契约、数据去向和不可控假设。

STRIDE、攻击树和滥用场景能帮助团队系统地提出问题。身份伪造、篡改、抵赖、信息泄露、拒绝服务和权限提升是常见类别，但类别名称本身不是威胁描述。

有效条目应包含攻击前提、路径、目标资产和后果。例如“获得被盗刷新令牌后，从新设备换取访问令牌并读取其他租户数据”，比“身份伪造”更可验证。攻击前提不确定时，应把它作为待验证假设。

攻击者可能是外部人员、普通用户、合作方、内部运维或被攻陷的服务。不同主体拥有不同初始权限。把所有威胁都假设成匿名互联网攻击，会漏掉供应链和内部滥用。

发生可能性受暴露面、攻击成本、已有控制和可探测性影响，后果取决于资产。精确打分容易制造虚假客观性，尤其在缺少事件数据时。可以采用有定义的等级，但要保留判断依据和置信度。

高后果、低概率事件仍可能需要设计控制。相反，频繁但可自动恢复的小错误不一定优先。排序应连接业务风险容忍度，而不是机械按两个数字相乘。

风险接受需要所有者、理由、期限和触发复审的条件。没有负责人和到期日的“接受”通常只是遗忘。转移给供应商或保险也不会消除技术和声誉影响。

控制可以消除功能、减少暴露、阻断路径、降低权限、提高检测或改善恢复。最小权限只减少成功后的影响，输入验证主要阻断特定入口，备份支持恢复却不防止泄露。必须说明控制影响威胁链的哪一环。

预防、检测和响应需要组合。无法完全阻止的凭据滥用，可以通过短期令牌、设备条件、异常访问检测和快速吊销降低风险。控制之间还可能冲突，例如详细日志提高调查能力，也可能扩大敏感数据存储。

缓解条目应转为架构约束、开发任务、测试和运行告警。只写“加密”“鉴权”无法验收，需要明确数据范围、算法与密钥责任、授权资源和失败行为。

设计评审确认控制存在于架构，代码和配置测试确认实现，渗透测试与演练验证攻击路径。每种证据范围不同，单次扫描无法证明业务授权正确，人工评审也不能替代持续配置检查。

负向测试要覆盖缺失身份、过期令牌、跨租户标识、重复消息、越权批量操作和依赖失效。检测控制需要注入可识别事件，确认日志完整、告警到达和处置人能够行动。

修复后应重新评估残余风险。控制可能引入新的管理接口、密钥或可用性依赖。若模型不更新，风险表会显示已关闭，而新的攻击面没有记录。

新功能、架构迁移、权限变化、外部依赖替换和安全事故都应触发复审。变更评审可以只分析差异，但要确认原有假设仍成立。长期系统还需定期检查无人负责的资产和过期接受项。

版本化威胁模型应关联架构版本和发布记录。模型中的组件名称、数据流和控制必须能映射到实际系统，否则无法用于事故定位。废弃组件也应在确认流量和数据清除后再移除。

威胁建模不会保证没有漏洞。它提供的是一条可审计链路：为什么某项资产重要，攻击如何到达，控制在哪里生效，又用什么证据验证。安全投入因此能够围绕真实系统风险，而不是围绕术语和工具数量。