一、安全需求概述
各位同学好，我是老赵。今天咱们开始聊安全需求。说实话，我做了十几年安全架构，见过太多项目把安全当成"最后贴的膏药"。结果呢？上线第一天就被捅出漏洞，然后整个团队通宵补锅。
为什么会这样？说白了，就是没搞明白安全需求到底是什么。
1.1 什么是安全需求
安全需求，不是让你写"系统要安全"这种废话。它是一组可验证的约束条件，用来保护系统的三个核心属性：
- 机密性——数据只能被授权的人看到
- 完整性——数据没有被篡改
- 可用性——系统在需要的时候能正常工作
我习惯把安全需求拆成两层：
| 层次 | 说明 | 例子 |
|---|---|---|
| 业务安全需求 | 来自业务场景的约束 | "只有本部门经理才能审批50万以上的报销单" |
| 技术安全需求 | 实现业务约束的技术手段 | "审批接口必须校验JWT中的角色字段" |
你想想看，如果只写技术需求，业务方看不懂；只写业务需求，开发又不知道怎么落地。所以这两层必须对齐。
核心观点：安全需求是"系统在对抗环境下必须满足的行为约束"。它不是功能，是功能的"边界条件"。
1.2 安全需求与功能需求的区别
这个问题我每次上课都要讲。很多团队把安全需求混在功能需求里写，结果就是——"登录功能"写了一大堆，但"登录失败5次锁定账号"这种安全约束，没人提。
我画个对比表，大家一看就明白：
| 维度 | 功能需求 | 安全需求 |
|---|---|---|
| 关注点 | 系统"做什么" | 系统"不能做什么" |
| 触发条件 | 正常用户操作 | 恶意或异常行为 |
| 可测试性 | 正向用例验证 | 负向用例+攻击模拟 |
| 变更频率 | 随业务迭代 | 随威胁环境变化 |
| 典型表述 | "用户能上传头像" |
举个例子。我之前带过一个支付项目，产品经理写功能需求："用户可以使用信用卡支付"。听起来没毛病吧？但安全需求呢？
- 信用卡号必须加密存储（机密性）
- 支付金额不能被篡改（完整性）
- 同一笔订单不能重复扣款（一致性）
- 支付接口必须限流，防止刷单（可用性）
你看，一个简单的"支付"功能，背后挂着四条安全需求。如果只写功能需求，开发做出来的东西就是"能跑，但一打就碎"。
我的经验：写需求的时候，把功能需求和安全需求分开列。功能需求用"用户故事"，安全需求用"约束条件"。这样评审的时候，谁漏了安全点，一眼就能看出来。
1.3 安全需求的重要性
嗯，这里我要说点扎心的话。我见过太多公司，安全需求被当成"成本"而不是"投资"。结果呢？
我给你们看一组真实数据（来自我参与过的项目复盘）：
| 安全活动介入阶段 | 修复一个漏洞的平均成本 | 修复时间 |
|---|---|---|
| 需求阶段 | 约 500 元 | 1-2 小时 |
| 设计阶段 | 约 2,000 元 | 半天 |
| 编码阶段 | 约 8,000 元 | 1-2 天 |
| 测试阶段 | 约 20,000 元 | 3-5 天 |
| 上线后 | 约 100,000+ 元 | 1-2 周（含公关） |
我曾经接手过一个项目，上线后才发现用户ID直接暴露在URL里，改一下就能看别人的订单。修复本身只花了2小时，但数据泄露通报、用户赔偿、品牌损失……加起来超过50万。你说，如果在需求阶段就写一条"用户ID不能作为可枚举的查询参数"，能花多少成本？
安全需求的重要性，我总结成三点：
- 决定架构的"地基"——安全需求没想清楚，后面改架构等于拆房子重盖
- 降低修复成本——越早发现，越便宜，这是铁律
- 满足合规要求——等保、GDPR、PCI-DSS，哪个不是安全需求的"硬约束"？
避坑指南：我曾经见过一个团队，为了赶上线，把安全需求全部砍掉，说"后面再补"。结果后面补了三个月，比正常开发还多花两倍时间。安全需求不是"可选项"，是"必选项"。你跳过它，它迟早会跳回来咬你。
知识体系总览
下面这张图，是我对安全需求在整个软件架构中位置的总结。大家可以先有个整体印象：
这张图把咱们今天讲的内容串起来了。从安全需求定义出发，到三大核心属性，再到分层结构，最后落到与功能需求的区别和重要性。后面的课程，我们会沿着这个结构一步步深入。
好，第一章就到这里。记住一句话：安全需求不是"附加题"，是"必答题"。你越早答，代价越小。