从安全需求到系统架构设计全流程 - 第1节

一、安全需求分析基础：什么是安全需求

安全需求，说白了就是系统必须满足的“安全底线”。

我经常跟团队讲一个比喻：你盖一栋楼，功能需求是“有几间房、装什么电梯”，安全需求就是“这楼抗震几级、消防通道够不够宽”。没有安全需求，系统就像纸糊的城堡——功能再花哨，一碰就碎。

在我做过的项目里，最惨的一次教训是：一个内部管理系统，上线第三天就被拖库了。原因？开发时根本没想过“谁可以访问什么数据”这个基本问题。嗯，从那以后，我再也不敢把安全需求放在最后补。

二、安全需求的三大来源

安全需求不是拍脑袋想出来的。我个人习惯从三个方向去挖掘：法规、业务、威胁建模。缺一个，需求就可能漏掉。

2.1 法规合规驱动

这是最“硬”的来源。法律条文摆在那，不满足就罚款、停业、甚至坐牢。

举个例子：你做一款面向欧盟用户的App，GDPR（通用数据保护条例）要求用户数据必须加密存储、必须提供删除权。这不是你“想不想做”的问题，是必须做。

2.2 业务场景驱动

业务本身会“长”出安全需求。你想想看：一个电商平台，用户要付钱，那支付环节就必须防篡改、防重放。一个医疗系统，病历数据就是命，必须保证谁改了、什么时候改的都能追溯。

我遇到过这样一个案例：某在线教育平台，业务方说“我们要支持学生上传作业”。听起来很简单对吧？但仔细一想——上传的文件可能包含恶意脚本，如果直接展示给其他学生看，那就是XSS攻击的温床。于是，文件类型校验、内容扫描、存储隔离这些安全需求就出来了。

业务安全需求通常来自：

• 资产识别：系统里最值钱的数据是什么？用户密码？交易记录？核心算法？
• 业务流程分析：哪个环节最容易出问题？登录？支付？数据导出？
• 用户角色梳理：谁可以做什么？管理员、普通用户、访客的权限边界在哪？

2.3 威胁建模驱动

这是我最喜欢的方法。因为它不是“被动响应”，而是“主动找茬”。

威胁建模，就是站在攻击者的角度，想方设法搞垮你的系统。然后针对每一种攻击路径，推导出对应的安全需求。

常用的框架是STRIDE，微软提出的威胁分类法：

三、安全需求分类：功能性与非功能性

安全需求不是铁板一块。我个人习惯把它们分成两类：功能性和非功能性。分清楚这两类，后续的设计和验收才不会打架。

3.1 功能性安全需求

这类需求是“系统必须做什么”。它是具体的、可测试的、可以直接写进用户故事里的。

举个例子：

• “用户登录时，密码输入错误超过5次，账户锁定30分钟。”
• “所有API调用必须携带有效的JWT令牌。”
• “管理员删除用户时，必须二次确认并记录操作日志。”

功能性安全需求的特点：

• 可验证：测试人员可以写用例来验证“锁没锁”、“令牌验没验”。
• 可编码：开发人员知道“if…else…”怎么写。
• 与业务逻辑交织：它往往嵌入在业务流程里。

3.2 非功能性安全需求

这类需求是“系统应该做到什么程度”。它不直接对应某个功能按钮，但决定了系统的安全质量。

举个例子：

• “系统应能抵御常见Web攻击，如SQL注入、XSS。”
• “数据传输过程中，加密强度不低于AES-256。”
• “系统在遭受DDoS攻击时，核心业务可用性不低于99.9%。”

非功能性安全需求的特点：

• 偏架构：它影响的是系统整体设计，而不是某个模块。
• 偏策略：它定义的是“安全水位”，而不是具体操作。
• 难量化：“抵御攻击”怎么测？需要渗透测试、代码审计等手段。

四、知识体系总览

下面这张图，把本章的核心逻辑串起来了。你可以把它当作安全需求分析的“地图”。

这张图展示了安全需求分析的完整脉络：从三大来源出发，经过分类梳理，最终形成可落地、可验证的需求条目。我个人习惯在项目启动会上就把这张图贴出来，让所有人对齐认知——安全不是安全团队的事，是每个人的事。