📚 课程目录第1章安全需求概述

一、安全需求概述：什么是系统级安全需求？为什么需要安全需求规范？安全需求与功能需求的区别

系统级安全需求，说白了就是——你的系统必须能扛住哪些威胁。

我见过不少团队，一上来就写「用户登录要加密」「数据库要脱敏」。这些当然没错，但它们只是功能层面的安全点，不是系统级安全需求。

系统级安全需求关注的是整个系统的安全边界、信任模型、数据流向、认证授权框架。它不关心某个按钮怎么加密，而是关心：

一句话定义：系统级安全需求是描述系统「在安全方面必须做到什么」的顶层约束，它决定了安全架构的骨架。

举个例子。我曾经参与过一个金融支付系统的项目。业务方提的需求是「用户转账需要短信验证」。这看起来是个安全功能，对吧？但真正的问题来了——短信验证码的生成逻辑放在哪个服务里？验证码的传输通道是否独立？如果短信网关被劫持，系统怎么降级？

这些，才是系统级安全需求要回答的问题。

你想想看，一个系统从需求到上线，要经过多少人？产品、架构、开发、测试、运维……每个人对「安全」的理解都不一样。

没有规范，就会出现：

为什么会这样？因为每个人只看到了自己那一亩三分地，没人从系统整体去看安全。

我个人习惯，在项目启动阶段就拉一个安全需求规范文档。它就像一张安全地图，告诉所有人：

我的经验：没有规范的安全需求，最后都会变成「安全口号」。比如「系统要安全」「数据要保密」——这种话说了等于没说。

我记得有一次做政务云项目，客户要求「系统必须通过等保三级」。但等保三级是个合规目标，不是技术需求。如果我们直接把「通过等保三级」写进需求文档，开发根本不知道要做什么。

所以，安全需求规范的作用就是把合规要求翻译成可落地、可验证的技术条款。

这个问题，我每次培训都会被问到。其实区分起来很简单：

我举个例子你就明白了。

功能需求：「用户输入用户名和密码，点击登录按钮，系统验证通过后进入主页。」

安全需求：「系统应防止暴力破解，同一账号在5分钟内连续失败5次后，锁定该账号30分钟，并触发告警。」

看到了吗？功能需求描述的是正常流程，安全需求描述的是异常场景下的防护。

注意：安全需求不是功能需求的「附加项」。它们是并行的、独立的。很多项目失败，就是因为把安全需求当成「功能做完后再补的补丁」。

我曾经见过一个团队，把「密码加密存储」写成了功能需求。结果开发用 MD5 加密，测试说「功能实现了，密码确实存成了密文」。但 MD5 能叫加密吗？那是哈希，而且是不安全的哈希。

这就是混淆安全需求和功能需求的后果——你以为做了安全，其实只是做了个样子。

下面这张图，是我自己总结的系统级安全需求四层模型。每次做新项目，我都会拿它来对照检查。

这个模型的核心思想是：安全需求不能只停留在「目标」层面，必须层层分解到可验证的控制措施。

我每次做安全评审，都会拿着这个模型问团队：

如果哪个环节答不上来，那就是安全需求的缺口。

做安全需求这么多年，我见过太多翻车的案例。这里列三个最常见的坑：

误区一：把安全需求写成「安全功能」

比如「系统使用 AES-256 加密」。这是功能实现，不是需求。正确的写法是：「系统应保证存储数据的机密性，防止未授权读取。加密算法应使用经过国家密码管理局认可的算法。」

误区二：安全需求过于抽象

比如「系统应保证高可用」。什么叫高可用？99.9% 还是 99.99%？单机房还是多活？故障切换时间是多少？必须量化。

误区三：忽略安全需求的「负向验证」

功能需求只要测「能跑通」就行。安全需求必须测「跑不通」——也就是攻击场景。我曾经有个项目，安全需求写了「防 SQL 注入」，结果测试只测了正常查询，没测恶意输入。上线第一天就被注了。

嗯，这些坑我基本都踩过。所以现在我做安全需求规范，一定会要求：每条安全需求都必须有对应的攻击场景和验收用例。

系统级安全需求不是功能需求的附属品，它是独立的安全架构约束。没有规范的安全需求，系统就像没有围墙的城市——看起来繁华，实际上不堪一击。

记住三个关键点：