一、安全架构导论：从“救火队员”到“设计者”的转变

大家好，我是你们这堂课的讲师。做了十几年安全架构，我最大的感触是：安全这件事，越早介入，成本越低，效果越好。今天咱们就来聊聊安全架构的“第一性原理”。

1.1 安全架构的定义与目标

安全架构到底是什么？说白了，它不是一堆防火墙和加密算法的堆砌。它是一套系统性的设计原则和结构，用来确保软件在面临各种威胁时，依然能保护其核心资产。

我个人习惯把安全架构的目标归纳为三个核心词：

• 机密性：不该看的人，绝对看不到。比如用户的密码、银行卡号。
• 完整性：数据在传输和存储过程中，不能被篡改。你想想看，如果银行转账记录能被随便改，那世界就乱套了。
• 可用性：该用的时候，系统得能用。DDoS攻击就是冲着破坏可用性来的。

1.2 安全架构在软件开发生命周期中的位置

很多团队把安全当成“上线前的安全检查”，这其实是个大坑。我在项目中遇到过太多次，产品都快发布了，才发现有严重的安全漏洞，结果只能通宵打补丁。

正确的做法是：安全应该贯穿整个软件开发生命周期（SDLC）。

阶段	安全活动	我的经验
需求分析	威胁建模、安全需求定义	这时候问一句“数据怎么存”，能省后面80%的麻烦
设计阶段	安全架构评审、攻击面分析	我建议画数据流图时，就把信任边界标出来
开发阶段	代码安全规范、静态扫描	别等代码写完再扫，边写边扫效率最高
测试阶段	渗透测试、安全回归	自动化测试能覆盖80%的常见漏洞
运维阶段	安全监控、应急响应	日志一定要留，不然出了事你都不知道怎么发生的

1.3 常见安全威胁模型

做安全架构，手里得有几把“尺子”。STRIDE和DREAD就是我常用的两把。

STRIDE模型

STRIDE是微软提出的威胁分类方法，每个字母代表一类威胁。我习惯用它来做“威胁头脑风暴”，确保不遗漏。

• S - Spoofing（假冒）：比如伪造身份登录系统。
• T - Tampering（篡改）：比如修改传输中的数据包。
• R - Repudiation（抵赖）：用户做了操作，事后不承认。
• I - Information Disclosure（信息泄露）：敏感数据被不该看到的人看到。
• D - Denial of Service（拒绝服务）：让系统无法正常服务。
• E - Elevation of Privilege（权限提升）：普通用户拿到管理员权限。

DREAD模型

STRIDE帮我们“找”威胁，DREAD则帮我们“排”优先级。DREAD是一个风险评估模型，每个维度打分（1-10），最后算总分。

维度	含义	打分参考
Damage（损害）	如果攻击成功，损失有多大？	数据泄露=10分，小bug=1分
Reproducibility（可复现性）	攻击能稳定复现吗？	每次都能成功=10分，极难复现=1分
Exploitability（可利用性）	攻击门槛高不高？	脚本小子都能搞=10分，需要专家=1分
Affected Users（受影响用户）	影响多少人？	所有用户=10分，极少数=1分
Discoverability（可发现性）	漏洞容易被发现吗？	公开已知=10分，极隐蔽=1分

嗯，这里要注意：DREAD的评分主观性比较强，我建议团队一起打分，取平均值，避免个人偏见。

1.4 安全架构师的角色与职责

很多人问我：安全架构师到底是干嘛的？是写代码的？还是管人的？

我的理解是：安全架构师是连接业务、开发和安全的桥梁。你既要懂业务逻辑，又要懂技术实现，还得能跟老板讲清楚“为什么这个安全投入是值得的”。

具体来说，我日常的工作包括：

• 制定安全策略和标准：比如密码策略、加密算法选型、API安全规范。
• 进行威胁建模和风险评估：用STRIDE找威胁，用DREAD排优先级。
• 评审架构设计：确保新功能在设计阶段就考虑了安全。
• 推动安全文化建设：让每个开发都意识到安全是自己的事。
• 应急响应和复盘：出了安全事件，要能快速定位并修复，事后还要复盘改进。

知识体系总览

下面这张图，是我对本章知识体系的总结。你可以把它当作一张“地图”，后续章节都会围绕这些核心概念展开。

好了，第一章的内容就到这里。记住我今天说的：安全架构不是终点，而是贯穿始终的思维方式。下一章，我们会深入聊聊威胁建模的具体实践，到时候我会拿一个真实案例来拆解。