一、安全需求导论：到底什么是安全需求？
各位同学，咱们今天聊一个看似基础、但实际工作中最容易翻车的话题——安全需求。
我做了十几年安全架构，见过太多项目把安全当成“最后贴上去的补丁”。结果呢？上线前一天才发现密码没加密、接口没鉴权、日志里明文存了身份证号……嗯，那场面，真是“改代码两小时，扯皮一整天”。
所以第一节课，咱们先把地基打牢。搞清楚三个问题：
- 安全需求到底是什么？
- 它跟功能需求有啥区别？
- 为什么非重视它不可？
1.1 什么是安全需求？
先给个定义。安全需求，说白了就是——系统在保护信息资产、抵御威胁、满足合规方面必须做到的事。
它不是“我想要一个登录页面”，而是“登录页面必须能防暴力破解、密码必须加密存储、会话必须在30分钟无操作后自动过期”。
一句话记住：功能需求描述系统“做什么”，安全需求描述系统“不能出什么乱子”。
我习惯把安全需求拆成三个层次：
| 层次 | 说明 | 举例 |
|---|---|---|
| 业务安全需求 | 来自业务场景本身的风险控制 | “转账金额超过5万必须二次确认” |
| 技术安全需求 | 系统架构层面的防护措施 | “所有API调用必须校验JWT令牌” |
| 合规安全需求 | 法律法规、行业标准强制要求 | “用户个人信息必须脱敏展示” |
你看，这三个层次缺一不可。光有技术没业务，安全方案落不了地；光有合规没技术，审计来了照样挂。
1.2 安全需求 vs 功能需求：到底差在哪？
这个问题，我每次面试都会问。能说清楚的人，真不多。
咱们直接上对比表：
| 对比维度 | 功能需求 | 安全需求 |
|---|---|---|
| 用户感知 | 用户能直接看到、用到 | 用户通常感知不到，除非出问题 |
| 价值体现 | 实现业务价值 | 保护业务价值不被破坏 |
| 测试方式 | 验证“能不能用” | 验证“能不能防住” |
| 失败后果 | 功能不可用，影响体验 | 数据泄露、系统被控、法律罚单 |
| 需求来源 | 产品经理、业务方 | 安全工程师、合规部门、威胁分析 |
举个例子你就明白了。
功能需求说：“用户可以用邮箱注册账号。”
安全需求说：“注册时邮箱必须验证有效性，密码强度至少8位含大小写+数字，注册频率限制每分钟不超过5次。”
你看，功能需求是一条线，安全需求是一张网。
我的经验：很多开发同学觉得安全需求是“找茬”。其实不是。安全需求是在帮功能需求兜底——没有安全的功能，就像没上锁的门，谁都能进。
1.3 安全需求为什么这么重要？
这个问题，我用三个真实案例来回答。
案例一：某电商平台
上线前没做安全需求分析，结果“优惠券接口”没加防刷机制。上线当天被脚本刷走200万张券，直接损失300万。后来一查，接口文档里根本没写“同一用户每天限领1张”这条安全需求。
案例二：某医疗系统
患者查询功能只做了功能测试，没验证“医生只能看自己科室的患者”。结果一个实习医生无意中看到了全院患者的诊断记录……嗯，那家医院后来被罚了80万。
案例三：我自己的教训
我曾经负责过一个支付网关项目。当时产品经理说“用户支付成功后跳转回商户页面就行”。我心想这不就是个302跳转嘛，简单。结果上线第二天，安全团队发现——跳转URL没做校验，攻击者可以伪造跳转到钓鱼网站。幸亏发现得早，不然就是重大安全事件。
从那以后，我养成了一个习惯：每个功能需求旁边，必须写清楚对应的安全需求。哪怕只是“用户修改密码”这种小功能，也要想清楚“修改前要不要验证旧密码？”“修改后要不要发通知？”“密码传输要不要加密？”
避坑指南：千万不要把安全需求当成“非功能性需求”扔到项目最后处理。我曾经见过一个项目，安全需求被归类为“性能优化”一起排期，结果上线时安全测试都没做。后果？你自己想。
1.4 安全需求的知识体系
为了让你更直观地理解，我画了一张图。这张图也是咱们整个课程的知识骨架。
这张图你看懂了吗？
安全需求不是孤立的。它从业务中来，落到技术上去，最后还要过合规这道关。三者缺一，你的安全方案就是瘸腿的。
1.5 怎么判断一个需求是不是安全需求？
我教你一个简单的方法——“如果没做会怎样”测试。
- 如果没做，系统还能正常运行吗？ → 能，但可能被攻击 → 这是安全需求
- 如果没做，用户会发现吗？ → 通常不会，除非出事了 → 这是安全需求
- 如果没做，会被监管罚款吗？ → 会 → 这是安全需求
举个例子：
- “用户登录” → 功能需求（没它用户进不来）
- “登录失败5次后锁定账号” → 安全需求（没它系统也能登录，但容易被爆破）
你看，区别很明显。
一个小技巧：我在做需求评审时，会专门拿一支红笔，在功能需求文档上圈出所有“隐含的安全假设”。比如“用户上传头像”这个功能，隐含的安全假设是“上传的文件是安全的”。但实际呢？不校验文件类型、不限制大小、不扫描病毒，分分钟变成文件上传漏洞。
1.6 安全需求的常见误区
最后，我列几个我见过最多的误区。你对照看看，自己踩过几个？
| 误区 | 错误认知 | 正确做法 |
|---|---|---|
| 安全是运维的事 | 开发只管功能，安全上线后再说 | 安全需求必须从需求阶段就开始介入 |
| 安全需求就是加个验证码 | 以为验证码能解决所有安全问题 | 验证码只是安全的一小部分，远不够 |
| 安全需求可以后期补 | 先上线，安全后面再加固 | 后期补安全，成本翻10倍，效果打5折 |
| 安全需求是安全团队的事 | 开发不用管安全，安全团队会检查 | 安全是每个人的责任，开发是第一道防线 |
嗯，这些误区我当年全踩过。尤其是第一条——“安全是运维的事”。直到有一次，我开发的系统上线当天就被扫出SQL注入漏洞，运维大哥半夜打电话让我起来修代码……从那以后，我再也不敢说“安全跟我没关系”了。
好了，第一节课就到这里。记住一句话：安全需求不是“锦上添花”，而是“雪中送炭”。没有安全需求的功能，就像没系安全带的跑车——跑得快，但出事也快。