前言

最近在做安全运营建设方面的工作，整理了业务流程后通过向上溯源，我发现产品的安全风险或许来自最初需求设计阶段时就缺少了安全控制。在产品设计阶段如果只考虑业务需求而忽略安全性，则可能导致产品整体架构存在风险。不仅在上线后可能导致返工增加额外的整改成本，还可能由于功能安全缺陷直接遭受攻击造成重大问题。

在产品设计阶段时就应该主动加入安全活动，在源头减少不安全的设计从而提高产品整体的安全性。但是需要认识到的一点，产品设计时的安全活动不可能将安全风险降到0，我们需要的是在SDL各个阶段通过安全活动介入尽可能降低安全风险，同时还需要后续的安全运营把风险降到可接受范围。

SDL安全生命周期

在讲产品安全设计前需要先理解SDL。SDL是微软提出的从安全角度指导软件开发过程的管理模式。在传统的软件开发生命周期SDLC各个阶段加入安全活动，让每一个单独的活动执行都能提高产品的安全性。

可以参考如下图示：

可以发现业务流程从客户需求收集开始，产品源头就在需求分析与需求设计。而大部分的安全风险也就在需求设计时引入。因为进行需求设计的执行人通常为业务产品设计师或技术开发负责人，这些人群的安全意识与安全技术相对薄弱不足，在执行需求设计时缺少加入安全控制。所以，我们需要通过建设安全文化来帮助这类人群提高他们的产品安全设计意识。

而安全文化可以包括进行产品安全设计培训、安全需求检测清单checklist等来建设。

产品安全设计

现在来看产品安全设计，需要先明确的几个关键要素。

产品安全设计介入点

产品安全设计执行人

产品安全设计产出物

产品安全设计原则（即验收标准）

产品安全设计介入点应该在需求分析与需求设计阶段。产品安全设计的执行人则应该是产品设计师或技术开发负责人，通常企业中由该两个岗位负责业务产品设计。产品安全设计产出物是安全需求checklist自检后的清单，最后应该由安全部门根据验收标准在需求评审阶段前对产出进行验收。

产品安全设计的原则

最小化原则

安全最小化原则是最基本的原则之一，对外提供的服务越少，安全风险越小。产品组件、服务和用户只能访问其执行功能所必需的最少权限和资源。

默认安全原则

产品在默认配置下就是安全的，无需用户进行复杂的安全设置。当然部分情况下可以允许用户自行配置安全开关。

严格的风险模型和评估

在产品设计和发布的每个关键节点，都必须进行系统性的威胁建模和风险评估，识别潜在攻击面并采取缓解措施。

安全的默认配置

所有安全控制（如身份验证、加密、日志记录）在安装或初始化后应自动启用，且设置为最高安全级别。

保证软件供应链安全

对所有第三方和开源组件进行清单管理、漏洞监控和验证。使用安全的软件构建、分发和更新机制。

保持软件和硬件的可维护性

确保产品在其整个生命周期内都能得到安全更新和补丁。为终止支持提供明确的升级或退役路径。

采取纵深防御策略

不依赖单一安全控制，而是在产品的不同层级（硬件、固件、软件、网络）部署多层、互补的安全措施。

持续改进与优化

在实际实践中，一味按当前产品安全设计原则推进显然不符合不同大小企业的自身实际经营情况。所以产品安全设计原则还需要根据企业的安全成熟度与业务流程进行不断的优化改进。这一点需要企业安全人员通过组织培训会议，收集不同岗位的建议与反馈来对实际业务做针对优化。比如已经具备统一身份认证的系统，不必再要求考虑身份登录；对于只限于前端有限的产品更改，不必要根据安全需求checklist进行自检。