软件安全:从需求到设计,构建开发防护的铜墙铁壁

软件安全需求与设计是安全开发的“第一块基石”，决定了软件的安全底色。脱离科学的需求分析与合理的设计规划，后续的安全编码、测试只能“亡羊补牢”，难以从根源上规避风险。

1. 软件安全需求分析：以风险为核心的前置布局

安全需求分析并非简单罗列“要安全”，而是以风险管理为核心，构建系统化的需求体系，关键要点包括：

• 分类明确：分为安全功能需求（如身份认证、数据加密）与安全保障需求（如日志审计、漏洞修复机制），二者相辅相成，覆盖软件全生命周期安全。

• 双向定义：不仅明确系统“能做什么”，更要界定“不能做什么”，避免因需求模糊留下安全盲区。

• 平衡与视角转换：兼顾功能需求、安全需求与业务目标的平衡；需求工程师需跳出“用户视角”，切换到“攻击者视角”，预判潜在漏洞与攻击路径。

• 文档化落地：所有安全需求需形成标准化文档，作为设计、编码、测试的统一依据，避免需求模糊导致的安全遗漏。

2. 安全需求分析的标准化流程

1. 系统调查：全面梳理系统架构、业务场景、数据资产及用户群体，明确核心保护对象。

2. 脆弱点与威胁分析：先通过定性分析识别潜在脆弱点（如未授权访问入口）与威胁类型，再通过定量分析评估风险发生概率与影响范围。

3. 需求确定：基于分析结果，明确安全需求的优先级，形成可落地、可验证的需求清单。

3. 安全设计的重要性：提前介入，降本增效

传统开发模式中，安全测试往往滞后于发布环节，发现漏洞后再修复，不仅成本高昂，还可能因架构限制无法彻底解决。据安全专家 Gary McGraw 研究，50% 的安全问题源于设计瑕疵。

安全设计提前介入开发流程，能以更低成本规避高风险问题。

> 例如早期因设计缺陷导致的“明文存储口令”问题（如 Microsoft Bob 软件，将口令明文存储并在客户端对比验证），若在设计阶段规避，可避免后续大规模返工与安全隐患。

软件安全设计需贯穿“概要设计-详细设计”全阶段，确保每一项安全需求都转化为可落地的技术方案。

1. 两大设计阶段的核心任务

• 安全概要设计阶段：聚焦整体架构安全，包括安全体系结构搭建、功能块间安全交互流程、安全协议选型（如 HTTPS、OAuth2.0）、跨系统安全接口设计等，搭建安全骨架。

• 安全详细设计阶段：详细设计阶段作为安全功能的程序设计阶段，应当直接指导安全功能的编码工作。包括但不限于：模块设计、内部处理流程、数据结构、输入/输出项、算法、逻辑流程图等。

2. 安全设计的核心活动

1. 详细风险评估：基于需求分析结果，针对设计方案开展二次风险评估，识别设计层面的潜在风险。

2. 控制措施选择：选取适配的安全控制手段（如访问控制、数据脱敏），确保措施与风险等级匹配。

3. 安全技术实现：将安全设计转化为具体技术方案，明确加密方式、校验规则等关键参数。

4. 安全设计评审：组织跨团队评审（开发、测试、安全），验证设计方案的可行性、安全性与兼容性。

3. 必须遵循的安全设计原则

安全设计需坚守以下核心原则，构建全方位安全防线：

其中，攻击面最小化原则是降低安全风险的关键，也是后续重点落地方向。

攻击面是软件中所有可被攻击者利用的入口总和，攻击面越小，安全风险越低。降低攻击面的核心是“精简不必要暴露，强化必要防护”。

1. 分析软件攻击面

1. 分析功能重要性：判断功能是否为核心业务必需，剔除冗余功能。（是否必须）

2. 分析访问路径：明确功能可通过本地或远程访问，重点防护远程访问入口。（本地&远程）

3. 分析访问权限：区分匿名访问与认证访问，严格限制匿名访问范围。（匿名&经过认证）

3. 降低攻击面策略

• 低重要性功能：若攻击面大，直接取消该功能，从源头消除风险（如非核心业务的第三方插件）。

• 中重要性功能：若攻击面大，设置为非默认开启，需用户手动配置后启用（平衡可用性与安全性）。

• 高重要性功能：若攻击面大，关闭冗余接口，限制访问方式，叠加多重安全防护（如核心数据接口同时启用身份认证、IP 白名单与请求频率限制）。

3. 典型实践案例

SQL Server 2005 默认关闭 xp_cmdshell 存储过程，该过程可执行系统命令，攻击面极大，默认关闭后显著降低了攻击者通过数据库入侵系统的风险，仅在用户确有需求时手动开启。

4. 降低软件攻击面通常做法

威胁建模是安全设计的核心工具，通过系统化流程识别、评估并消减威胁，确保设计方案能抵御潜在攻击。其本质是“在设计阶段提前模拟攻击，提前部署防御”。

1. 威胁建模的核心价值

帮助团队在设计阶段全面掌握威胁场景，指导防御措施选型；实现风险可视化管理，验证架构设计的安全性；同时助力攻击面缩减，形成“威胁识别-防御落地”的闭环。

2. 标准化威胁建模流程

1. 确定对象：明确核心保护资产（如用户隐私数据、业务核心逻辑），结合应用场景、部署方式、用户习惯，梳理关键威胁场景（如移动设备物理失窃、Web 应用匿名访问漏洞）。

2. 识别威胁：全面排查潜在威胁，需明确“威胁≠漏洞”——威胁是攻击者的攻击意图与方式，漏洞是系统的薄弱点，威胁永远存在，需持续识别。

   S	Spoolfing Identity	假冒身份/欺骗标识
   T	Tampering with data	篡改数据
   R	Repudiation	抵赖
   I	Information Disclosure	信息泄漏
   D	Denial of Service	拒绝服务
   E	Elevation of Privilege	权限提升

3. 理解 STRIDE 六类威胁：STRIDE 模型将威胁分为六类，覆盖常见攻击场景：欺骗（如身份伪造）、篡改（如数据篡改）、否认（如日志删除）、信息泄露（如敏感数据泄露）、拒绝服务（如 DDoS 攻击）、权限提升（如越权访问）。

   威胁	安全属性	定义	举例
   Spoofing（哄骗）	可鉴别性	模仿其他人或实体	伪装成microsoft.com或ntdll.dll。
   Tampering（篡改）	完整性	修改数据或代码	修改硬盘、DVD或网络数据包中的DLL
   Repudiation（抵赖）	不可抵赖性	声称没有执行某个动作	“我没有发送过那封电子邮件”，“我没有修改过那个文件”，“亲爱的，我确实没有访问过那个网站！”
   Information Disclosure（信息泄露）	机密性	把信息披露给那些无权知道的人	允许某人阅读Windows源代码；公布某个Web网站的用户清单。
   Denial of Service（拒绝服务）	可用性	拒绝为用户提供服务	使得Windows或Web网站崩溃，发送数据包并耗尽CPU时间，将数据包路由到某黑洞中。
   Elevation of Privilege（权限提升）	授权	获得非授权访问权	允许远程因特网用户执行命令，让受限用户获得管理员权限。

4. 评估威胁：量化风险值，结合攻击发生概率与资产受损后果，确定威胁优先级（高风险威胁优先处理）。

5. 消减威胁：针对不同威胁采取差异化措施：重新设计规避威胁、采用标准防护技术、创新防御方案；对可接受风险（低概率低影响）记录备案，定期复盘。