【SDL最初实践】安全设计

“为了减少产品设计带来的安全隐患，避免后续发现问题时，对功能实现流程甚至程序架构大刀阔斧改动带来高昂代价。在产品设计阶段，需要加入必要的安全活动，减少并消除产品安全隐患，纵深提升业务安全能力。”

01

—

安全目标

安全团队可以通过引导相关责任人进行自检，要求输出安全检查结果，并推动落实安全整改项来开展安全活动。在此过程中，需关注以下四个基本要素：

• 安全介入时间：产品设计阶段。
• 推荐执行角色：产品设计人员或技术架构师（一般而言技术架构师，即开发总负责人。产品中会涉及不同功能模块，若是不同的开发独立负责，则需要开发总负责人组织各开发进行安全自查、统一反馈）。
• 安全自检产物：安全设计checklist自检报告。
• 安全验收标准：自检报告中不存在不符合项；对于不符合项需制定相应解决方案并落地解决。

02

—

安全活动

在产品设计阶段，安全活动主要围绕设计要求、减小攻击面和威胁建模展开。

1）确定设计要求

从隐私和安全角度两方面进行考虑：

• 基本隐私设计：明确国家法律法规，对获取、记录用户隐私的相关产品做出设计要求。（在告知用户并征得同意的情况下，仅收集程序必须用到的隐私数据。）
• 基本安全设计：分为默认安全（在程序的默认配置中，需进行安全配置，确保程序初始状态是安全的）和最低加密（在程序处理之前，对所有数据进行严格验证或通过加密方式进行可靠地传输）。

2）减少攻击面

尽量减少暴露给恶意用户可能访问到的程序相关资源，包括但不仅限于端口、接口、服务、协议。

• 系统服务最小原则：可以是安全域划分、测试域名内网化，也可以是同一个应用（war包）仅允许发布在一个域名等运维安全相关举措。
• 应用最小权限原则：评估实现程序功能所需的网络访问最小权限、程序运行的最小访问级别、边界防火墙端口最小化，从而建立按最小需求分配相应的权限机制。
• 分层防御原则：在程序的不同层面实施安全方案，不同方案间需要相互配合构成一个整体，在解决根本性问题时需要实施针对性的安全方案。

3）威胁建模

威胁建模是一种分析应用程序威胁的方法，可识别潜在的安全问题并实施相应解决或缓解措施。通常使用微软提出的STRIDE威胁等级分类法，将威胁分为：Spoofing（仿冒）、Tampering（篡改）、Repudiation（否认）、Information Disclosure（信息泄漏）、Denial ofService（拒绝服务）和 Elevation ofPrivilege（权限提升）六部分。

上述六大威胁所表示的定义、安全属性、消减措施可参照下表：

此外微软官方还提供了免费的威胁建模工具，可作为平时研究使用。

03

—

安全实践

在实际的安全活动中，一般采用安全设计checklist + 威胁建模的模式。

• 针对一般业务系统功能的新增、迭代等变更，可降低安全要求暂不做威胁建模，重点围绕安全设计checklist展开；
• 针对存在重大安全风险的环境、核心业务系统、业务系统通用功能等业务场景，可按需进行威胁分析与建模（威胁建模存在厚重、耗时长、技术门槛高等难题，不太适合企业所有的业务场景）。

由此，安全设计checklist便是安全设计阶段的重中之重。一套好的安全检查项，并不是大而全，而是小而精且有效、业务方好理解。关于安全设计checklist的设计与内容，除了紧贴设计要求、安全编码规范、安全测试等后续安全活动反哺外，还可以参照一些互联网上的优秀案例。比如，美的金融SDL安全设计checklist：

又如，VIPKID产品设计与开发安全红线：

此外，还可以针对角色的不同，制作内容一致表现形式不同的安全检查项。比如从业务方视角：

又如，从安全角度出发：

04

—

持续优化

安全设计需要一定的积累和尝试，才能总结出一套可落地、有效的安全流程与解决方案。在实践过程中，发现一些比较行之有效的做法：

1）宣贯会上搜集业务方切身需求与体会

通过定期召开“安全评估流程”宣贯，不断搜集来自前端开发、后端开发、产品设计人员等不同参与人员的建议，持续优化现有安全设计checklist。

• 前端代码和后端代码需要精细优化，分别制定安全设计checklist或在现有表格中做明显区分；
• 针对企业系统的特点，对于统一功能单独制定安全设计要求，不需要在每个系统中都要求开发来填写相关设计项，比如：单点登录、会员修改/重置密码；
• 针对性对产品设计人员进行专业培训，选取一些常见的、工作中发现的案例进行分享，可以是某一功能实现的流程分析强调发现的安全问题；
• 推行产品设计安全规范，类似于开发安全规范，从安全设计阶段进行取材，制定公司（业务）特有的“安全红线”。

2）从后续安全活动中吸取经验，反哺安全设计检查项

在其后的环节，特别是代码审计和安全测试发现的漏洞与安全缺陷，可以反推到安全设计阶段，不断优化、持续补强针对某一重要系统或某一通用功能的专属安全设计checklist。

3）扩大相关责任人范围，衔接安全开发

如果仅聚焦于产品设计师可能带来的安全问题，往往难以满足在该阶段的期望（产品设计师输出产品功能原型图、业务流程图，具体功能实现便交由开发）。从降低安全活动带来的成本与打通SDL流程的角度考虑，需要将安全编码的理念提前一部分加入到安全设计阶段，因此该阶段关注的人物对象便是产品设计人员、开发人员。