From 94e648eb7a80111d458c7963fb796ee60e8af2a3 Mon Sep 17 00:00:00 2001 From: suxin <2439462239@qq.com> Date: Tue, 25 Oct 2022 15:59:22 +0800 Subject: [PATCH 1/4] update --- baseline/security-design-principle.md | 1063 ++++++++++++++++++++++++- 1 file changed, 1062 insertions(+), 1 deletion(-) diff --git a/baseline/security-design-principle.md b/baseline/security-design-principle.md index efc7902..e44fd81 100644 --- a/baseline/security-design-principle.md +++ b/baseline/security-design-principle.md @@ -1 +1,1062 @@ -# 安全设计原则 \ No newline at end of file +**安全设计原则** + + -------------------------------- -------------------------------------- + 编写人： 徐建、史昕岭、罗雨佳 编写日期： 2021.2.10 + + 审核人：邢楠 审核日期： 2021.2.13 + + 批准人： 批准日期： 2021.2.15 + -------------------------------- -------------------------------------- + +麒麟软件有限公司 + +**版本说明** + + ----------- ------------ ---------------------------------------------------------------------------------------------------------------------- ------------ ------------ ---------- ----------- + **日期** **版本号** **发布说明** **编写者** **签批人** + + **角色** **人员** **签字** + + 2021.2.15 V1.0 产品安全设计原则 史昕岭 编写人 史昕岭 + + 审核人 罗雨佳 + + 批准人 杨诏钧 + + 2022.5.16 V1.1 将安全设计原则缩减为核心的10条原则，并且对每条安全设计原则分规则阐述，使用范围，典型场景，落地策略四个小节进行描述。 徐建 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ----------- ------------ ---------------------------------------------------------------------------------------------------------------------- ------------ ------------ ---------- ----------- + +目录 + +[1 文档介绍 - 3 -](\l) + +[1.1 文档概述 - 3 -](\l) + +[1.2 文档使用指南 - 3 -](\l) + +[1.3 文档的更新与改进 - 4 -](\l) + +[1.4 落地方法 - 4 -](\l) + +[2 安全设计原则 - 5 -](\l) + +[2.1 最小攻击面 - 5 -](\l) + +[2.1.1 规则阐述 - 5 -](\l) + +[2.1.2 适用范围 - 6 -](\l) + +[2.1.3 典型场景 - 6 -](\l) + +[2.1.4 落地策略 - 7 -](\l) + +[2.2 最小权限 - 7 -](\l) + +[2.2.1 规则阐述 - 7 -](\l) + +[2.2.2 适用范围 - 8 -](\l) + +[2.2.3 典型场景 - 9 -](\l) + +[2.3 纵深防御 - 9 -](\l) + +[2.3.1 规则阐述 - 9 -](\l) + +[2.3.2 适用范围 - 10 -](\l) + +[2.3.3 典型场景 - 10 -](\l) + +[2.4 白名单 - 10 -](\l) + +[2.4.1 规则阐述 - 10 -](\l) + +[2.4.2 适用范围 - 12 -](\l) + +[2.4.3 典型场景 - 12 -](\l) + +[2.5 保护最弱环节 - 12 -](\l) + +[2.5.1 规则阐述 - 12 -](\l) + +[2.5.2 适用范围 - 13 -](\l) + +[2.5.3 典型场景 - 13 -](\l) + +[2.6 异常安全 - 14 -](\l) + +[2.6.1 规则阐述 - 14 -](\l) + +[2.6.2 适用范围 - 15 -](\l) + +[2.6.3 典型场景 - 15 -](\l) + +[2.7 默认安全 - 16 -](\l) + +[2.7.1 规则阐述 - 16 -](\l) + +[2.7.2 适用范围 - 17 -](\l) + +[2.7.3 典型场景 - 17 -](\l) + +[2.8 业务分割 - 17 -](\l) + +[2.8.1 规则阐述 - 17 -](\l) + +[2.8.2 适用范围 - 18 -](\l) + +[2.8.3 典型场景 - 19 -](\l) + +[2.9 不要轻信 - 19 -](\l) + +[2.9.1 规则阐述 - 19 -](\l) + +[2.9.2 适用范围 - 20 -](\l) + +[2.9.3 典型场景 - 21 -](\l) + +[2.10 公开设计 - 21 -](\l) + +[2.10.1 规则阐述 - 21 -](\l) + +[2.10.2 适用范围 - 22 -](\l) + +[2.10.3 典型场景 - 23 -](\l) + +[3 推荐资料 - 23 -](\l) + +# 文档介绍 + +## 文档概述 + +本文档对软件开发的通用安全设计经验，以及麒麟软件在安全操作系统开发过程中的安全设计经验进行总结进而提炼，阐述了在软件开发人员在可信设计阶段进行软件需求分析、软件总体设计、软件详细设计的各工作阶段中，都应该遵循的安全设计原则，用于指导软件开发人员在软件开发流程中如何进行系统级、产品级、模块级的安全设计。 + +归纳适用于公司产品线的安全设计原则，有利于归纳总结设计开发过程中的优秀实践及经验教训，将安全管理与安全体系前移，涵盖软件的全生命周期管理，确保软件整体的安全性。 + +## 文档使用指南 + +安全设计原则是指在软件设计过程中为了防范非法用户入侵，窃取软件资产，需要采取的基础性的，最为重要的安全设计思想和理念的总结，深入理解这些核心安全设计原则的内容，适用范围，经典场景，并在软件设计过程中遵循它们，能让你的软件设计避免很多常见的安全问题。软件开发人员需要深入理解这些安全设计原则，并在软件设计活动中加以实践。 + +每条安全设计原则分为规则阐述、适用范围、典型场景、落地策略四个小节。 + +- 规则阐述主要阐述设计原则的内容 + +- 适用范围主要从系统级，产品级，模块级三种不同体量软件设计过程中对该设计原则的使用情况，帮助软件开发人员更好的落地 + +- 典型场景主要是结合一个典型场景，加深对该设计原则的理解 + +- 落地策略主要用于指导后续安全研发体系化建设相关的工作，并且让研发人员明确其必要性。 + +## 文档的更新与改进 + +随着安全攻击技术的不断更新，公司安全研发体系的不断完善，本文档会处于一个持续改善的过程。 + +改进的过程必定是通过真实可见的安全攻击案例、产品安全事故进行根因分析后的总结、通用的业界安全设计标准，因此本文档的更新规范应遵从XXXX标准（后续完善） + +## 落地方法 + +本章节主要是描述将每一条安全设计规范进行落地的策略介绍问题，用于指导后续的安全研发体系建设，让研发人员充分理解本原则的重要性和指导性。 + +落地方法包含以下几种落地策略： + +- 考试培训 + + 考试培训是指将相关的、对应的知识库，以培训的形式向研发人员赋能，同时提炼为考试内容，与研发人员进行岗位、技能知识的强关联，只有通过了相关考试的人员才能从事对应的岗位或者采取相应的奖励措施。 + + 考试培训的方式主要是针对落地检查难度较大或者知识普及性质的安全设计原则，进行知识点源头式的规避，落地质量不如门禁规范系统，通常作为知识性的普及或者其他落地策略的补充。 + +- 安全设计原则自检表 + + 安全设计原则自检表，用于在软件总体设计，软件详细设计阶段，检查软件架构设计，模块设计，接口设计是否符合安全设计原则，软件设计人员需要对安全设计原则自检表中的所有检查项，填写是，否，不适用，选择是的表项，需要简述软件设计满足该表项描述的设计原则，填写不适用的表项，需要简述该设计原则为什么在本软件设计中不适用。安全设计原则自检表需要在软件总体设计，软件详细设计评审阶段提供，并接受评审。 + +- 设计方案安全评审 + + 设计方案安全评审，是在软件总体设计，软件详细设计阶段，在技术方案评审 + + 中，增加对技术方案安全性的评估，包括对软件总体设计方案的安全性，韧性，隐私保护等方面的风险评估，包括对软件详细设计方案的软件可靠性，可用性，健壮性的设计评审，以及对安全设计原则自检表中的自检结果进行评审和提出方案修改建议。 + +- 安全编码规范门禁系统 + + 安全编码规范门禁系统是指产品对应的编码平台、源码平台、编译平台在事务过程中的门禁系统，通过相关的安全工具进行强制安全分析，对不满足安全编码规范的代码予以自动化的拒绝。 + + 安全编码规范门禁系统的优点在于落地性较高、执行成本较低，缺点在于由于门禁系统的强制性，对门禁系统的规范质量要求非常高，需要减少误报、加强准确性，因此对门禁系统开发也是一个重要的工作 + +- 产品安全红线检查 + + 产品安全红线检查，是在产品设计阶段，由产品经理与研发人员，按照产品安全红线检查的要求，逐一对产品定义，软件设计进行安全检查，杜绝违反产品安全红线检查的产品定义或者软件设计方案。在测试阶段，按照产品安全红线检查的要求，执行相关测试用例，杜绝违反产品安全红线的软件发布。 + +- 安全攻防、渗透测试 + + 安全攻防、渗透测试，由应急响应团队在真实的安全攻击、渗透测试环境下，针对已发布软件采用黑客攻击手段，排查系统安全漏洞，提前发现安全风险，并反馈相关软件开发人员进行软件安全风险处置。 + +# 安全设计原则 + +本章节将根据防范安全攻击的安全需求、需要达到的安全目标、对应安全机制所需要的安全服务等因素，参照安全开发生命周期，归纳总结出部分系统设计阶段的安全原则。 + +## 最小攻击面 + +### 规则阐述 + +软件受攻击面是指，用户或其他程序以及潜在的攻击者都能够访问到的所有功能、代码、以及信息的总和，它是一个混合体，不仅包括代码、接口、服务，也包括对所有用户提供服务的协议，尤其是那些未被验证的或远处用户都可以访问到的协议。一个软件的暴露的攻击面越大，安全风险就越大。 + +软件每增加一个功能特性就有可能会引入新的风险。因此减少软件受攻击面的一个方式，就是尽可能去除、禁止不需要使用的模块、协议和服务。如果一个模块，协议，服务默认并不需要持续提供功能，可以采用默认关闭，在需要的时候动态启动，在使用完成后立即关闭的方式提高安全性。 + +还有一个减少软件攻击面的方式，是将软件进行某种程度的系统资源隔离。例如让重要的服务程序运行在安全沙箱中，只保留必要的对外通信手段。 + +**如何执行最小攻击面安全设计原则：** + +1. 去除软件中非必要的代码，接口，协议，端口，服务。 + +2. 默认提供一个最小化的软件功能，更多特性在用户配置后才开启 + +3. 对于没有持续服务的场景，可以通过精确控制开启服务的时间窗口来降低安全威胁。 + +4. 采用安全性高的软件通信方式，并且尽可能减少软件通信方式的种类。 + +5. 模块复用：尽可复用那些经过测试、已证明安全的库和通用组件，而不是自己开发。 + +6. 系统资源隔离：将软件的关键服务进行系统资源隔离保护。 + +7. 软件设计尽可能简单：系统越复杂，出现问题的风险越大。编码越多，bug越多。 + +### 适用范围 + +1. 在系统级的软件设计中，更多考虑的是针对用户场景，梳理提供默认开启系统功能，关闭哪些系统功能，在软件包层面梳理默认安全哪些软件包和服务，不安装哪些软件包和服务。在系统安全层面，梳理默认启动系统安全机制，默认关闭的安全机制，利用防火墙等，限制网络协议和端口等。 + +2. 在产品级的软件设计中，更多的考虑的是一个产品组件中哪些是对外提供服务的组件，哪些是对内提供服务的组件，要隐藏和保护对内的组件，提供安全认证手段保护对外的组件服务。产品级软件设计也要尽量减少通信方式种类，做到尽量统一。对没有持续服务场景的服务和组件，采取默认关闭，动态启动的方式。产品中的组件尽可能复用成熟的通用组件，而非自研。 + +3. 在模块级的软件设计中，更多的是考虑一个接口是否必要存在，一个端口是否必要存在，模块对外是否有必要，既提供功能库，又提供IPC通信接口，乃至RPC通信接口等问题，软件功能中那些部分是核心功能，需提供持续服务，哪些是次要功能，提供可配置，可动态启动的模式。 + +### 典型场景 + +1、减少系统攻击面的设计：系统默认不安装sshd，vnc，ftp，xrdp等软件和服务。 + +2. 统一登录认证功能设计：各个业务功能使用统一登录认证功能，通过认证模块复用的方式，让所有业务都在认证中心登录认证，避免了重复开发登录认证功能，减少了软件攻击面 。 + +3. 保护关键服务的安全设计：将关键服务使用安全容器进行系统隔离，只保留网络通信协议方式，并在安全容器内部配置严格的防火墙策略，这样能有效减少对关键服务的攻击面。 + +4. REE+TEE的安全架构设计，就是遵循了最小攻击面的设计原则，将核心的安全业务功能（例如安全支付功能）放到TEE可行执行环境中，TEE是一个环境单纯，只运行核心安全业务的环境，它的代码，协议，服务，端口的安全性都很容易进行可信验证，并且TEE的系统资源与REE完全隔离，两者之间只保留了严格的安全访问接口。这样的设计保证了TEE具备最小攻击面。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-1 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-1 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-1 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 最小权限 + +### 规则阐述 + +最小权限原则是指，系统仅授予软件实体（用户、管理员、进程、应用，服务和系统等）完成规定任务所必需的最小权限，并且该权限的持续时间也尽可能短。 + +当软件被授予一种权限，这种权限就存在被滥用的风险。或者软件的漏洞被黑客发现，使得黑客同样获取了这种权限。因此权限应该只被赋予确实需要此权限的软件。 + +最小权限设计的另一个考虑是将系统进行模块分割，单独设置每一个模块的权限，从而限制高特权只在一个模块中起作用，提升了软件整体的安全性。 + +UNIX的root权限，采用的是全有和全无的特权设计方案，这种方案带给了root用户无限的系统权限，因此无法对赋予root权限的模块进行进行最小权限限制，而Linux权能（Linux +Capability）则采用了将root权限分割的方案。软件程序被赋予某种权能后无需获得root权限即可获得某种特权。但是这种特权是受限的。 + +例如软件的某个模块需要有设置系统时间的功能，这是一种特权，让这个模块使用root权限运行显然没有遵循最小权限原则，正确的做法应该是让这个模块运行在普通用户权限下，但是给它赋予sys_time的linux权限。 + +最后需要指出的是最小权限安全设计原则中权限的内涵，并不是特指linux文件权限，Unix用户权限，或者Linux权能，也包括软件自身业务逻辑上形成的权限概念，例如在一个CS架构中，前台程序对后台数据的访问权限，这些软件逻辑面层形成权限的授予也应该遵循最小权限原则。 + +**如何执行最小攻击面安全设计原则：** + +1. 在软件设计中避免使用root权限，而是给软件程序赋予某种必须的Linux权能。 + +2. 默认采用最小权限设计，只有在确实需要增加某种权限的时候，再添加某种权限； + +3. 将软件功能模块进行分割，模块划分采用高内聚、低耦合的设计方法，在这个地方高内聚不仅仅指模块按功能高度聚合，也指模块按同一权限高度聚合，这样就能将某种权限集中赋予某个模块。 + +### 适用范围 + +1. 在系统级的软件设计中，更多考虑的对用户的权限管理，例如普通用户的最小权限定义，管理员用户的最小权限定义。以及对系统服务的最小权限管理，某一个系统服务是否需要使用root权限运行，能否使用Linux权能代替等。 + +2. 在产品级的软件设计中，更多考虑的是如果实现业务功能划分，将普通权限业务和特权业务进行功能划分，并且尽可能将需要同一种权限的业务功能划分到一个业务模块中。 + +3、在模块级的软件设计中，更多考虑的是模块间的高内聚，低耦合设计，某个模块是否需要root权限运行，能否使用Linux权能代替root权限等。 + +### 典型场景 + +1、一个后台服务程序需要具备配置网络接口，设置ip，netmask，gateway的权限，遵循最小权限安全设计原则的一种方案是，给这个后台服务程序添加cap_net_admin权限，而不是让这个后台服务程序以root权限运行。 + +2、在系统的rbac强制访问安全解决方案中，操作系统将用户划分为多种角色，让用户在执行不同的服务时，拥有不同的角色，然后对每种角色的权限进行了严格的区分，就是一种经典的最小权限安全设计方案。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-2 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-2 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-2 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 纵深防御 + +### 规则阐述 + +纵深防御原则又称为多层防御原则,是指在软件设计中加层安全策略，这样一来，当第一层次的防御措施失效，攻击行为有可能被下一层次的安全策略有效防御。纵深防御原则有助于减少系统的单一失效点。 + +一个典型的纵深防御的例子是大型网络应用业务如何保护业务数据，首先业务架构层面，将应用服务器和数据服务器进行业务网络划分，应用服务器处于外网可访问的网络中，数据服务器处于内网网络中，第一层防御是在应用服务器部署强大的企业级防火墙。第二层防御是处于应用服务器和数据服务器之间的防火墙，第三层防御是数据服务器向外提供服务采取严格的认证授权，第四层防御是对数据服务器中的数据库进行加密存储。 + +从上面的例子可以看出，纵深防御也可以认为是一种冗余安全设计，冗余设计总是能带来安全上的收益，但是也总是会带来性能或者资源消耗的增加。所以如果决定在一个软件设计中需要采取的安全策略的层数，是评估一个的重点。 + +**如何执行纵深防御安全设计原则：** + +1. 评估业务的安全性需求，确定需要的纵深防御层数。 + +2. 根据软件业务场景，列举所有可能实施的安全机制，然后平衡业务效率和安全性，进行安全机制组合。 + +### 适用范围 + +纵深防御安全设计原则，更多的是在系统级和产品级的软件安全设计中进行考虑。 + +1、在系统级的软件安全设计中，一个操作系统需要考虑提供多种基础性安全机制，例如内核安全机制，系统安全机制，应用安全机制，远程访问，本地调用等等，需要这些纵深防御安全机制的有机组合，提升系统的整体安全性。 + +2、在产品级的软件安全设计中，软件开发人员需要考虑产品的业务划分，明确产品的核心业务，附加业务，对外业务，对内业务（参考业务分割安全设计原则），针对各个业务特点，实施多层级安全策略。 + +3、在模块级的软件安全设计中，更多的考虑是要识别安全风险，在适当的地方，合理的使用系统和产品提供的安全机制，例如在需要提权的地方使用polkit认证，在需要数据防篡改使用数字签名等。 + +### 典型场景 + +1. linux操作系统提供多种纵深防御安全机制，帮助软件开发人员定制丰富的多层级安全策略，提升系统安全，例如pam认证框架，unix用户管理，文件权限管理，ACL访问控制，linux权能，LSM安全框架实现MAC访问控制，netfilter网络包过滤机制实现网络防火墙，namespace机制，cgroup机制等等 + 。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-3 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-3 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-3 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 白名单 + +### 规则阐述 + +白名单，顾名思义，指的是这样一种安全策略，默认规则是所有成员都没有某种权限，然后列出一个可信任成员列表（白名单），只给处在这个名单中的成员赋予这种权限。与白名单安全机制对应的是黑名单安全机制，它采取完全相反的安全策略，即默认规则是所有成员都有某种权限，然后列出一个不可信任成员列表（黑名单），只取消处在这个名单中的成员的这种权限。 + +不管是黑名单还是白名单，处在名单中的成员都是在软件实际使用中的某种经验总结形成的，数量都是有限的，因此处在名单之外的成员才是大多数。所以很容易得出结论，白名单是一种比黑名单更安全的设计策略。 + +**如何执行白名单安全设计原则：** + +1. 优先考虑白名单机制：当面临白名单和黑名单安全机制选择时，优先考虑白名单安全机制是一个很好的安全设计习惯，只有在论证了确认不适合采用白名单安全机制的情况下，再采用黑名单安全机制。 + +2. 找出合理的最小可用白名单：选择采用白名单策略还是黑名单策略，关键问题其实不在于软件逻辑的复杂度，这两个策略从软件逻辑复杂度上是相同的。关键的问题在于软件设计人员，是否有经验或者方法，找出白名单策略中的最小可用白名单。白名单不能过大，导致非法成员可以设法获取权限，产生安全漏洞，白名单也不能过小，导致在后期发现用户的某个功能因为白名单的限制无法实现。这会带来很多维护上的问题，因为并不是所有白名单都提供添加白名单成员的机制的，例如一个固化在软件代码中的安全字符过滤白名单，就只能通过软件升级进行更新，因此在设计初期要仔细设计方案找出找出合理的最小可用白名单，这很重要。 + +3. 白名单要可配置：如果不能在一开始就很方便的找出合理的最小可用白名单，那么就应该采用白名单可配置的设计，方便后续在软件运行过程中，根据情况增加和减少白名单。 + +4. 让用户自己选择：当某个不可信成员申请某种采用白名单机制的权限时，弹框提示用户，让用户自己选择是否将该成员加入白名单，也是一种很好的白名单设计。 + +### 适用范围 + +1、在系统级软件设计中，更多的考虑的是一个设备驱动的加载，外设的准入，用户的准入，应用程序和服务的准入，网络端口和协议的准入，在这些地方的软件设计上，是否可以使用白名单机制。 + +2、在产品级的软件设计中，更多的考虑的是服务的接入，用户认证名单，产品中的关键数据的访问权限，在这些地方的软件设计，是否可以使用白名单机制。 + +3、在模块级的软件设计中，更多的考虑的是，对外接口的参数过滤，防SQL注入，防命令注入的过滤规则，模块中的文件或数据列表，是否可以使用白名单机制。 + +### 典型场景 + +1. 在数据库操作函数中，设置安全字符串检查白名单，结合软件的场景，决定允许的字符串，能够有效的防止SQL注入类攻击。 + +2. kysec应用程序执行控制采用了白名单设计，只允许可信任程序执行，在不可信程序申请执行权限时，也提供了弹框提示用户是否允许该程序执行的白名单动态添加机制。 + +3. 在一个特权服务中，如果有system系统调用，需要对输入参数做严格的字符过滤，采用白名单机制，例如根据使用场景，如果输入限制为一个文件路径，则可以对文件路径组成的字符做较为严格的限制，避免黑客利用复杂的文件路径方式拼接，找到命令注入点。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-4 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-4 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-4 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 保护最弱环节 + +### 规则阐述 + +保护最弱环节，指的是，在一个软件设计中，整体的安全性由它的最弱环节决定。如果把安全比作一个链条，那么这个链条的坚固程度，将由这个链条最容易断链的一环决定。如果把安全比作一个木桶中的水，那么木桶能装的水的多少（安全性的高低），将由这个木桶最短的一块木板决定，这就是著名的"木桶原理"。攻击者往往选择攻击一个软件系统中的最薄弱的环节。 + +软件开发人员通常能够意识到软件中使用的密码算法可能不够安全，例如RC4算法不够安全，RSA56的秘钥长度不够，。但是他们可能意识不到，相比使用暴力破解的方法攻击用户使用的弱口令，攻击者更倾向的是攻击软件开发人员编写代码中的漏洞，例如利用缓存区溢出安全漏洞。因为从攻击者角度来看，找出并利用缓存区溢出安全漏洞是更容易实现攻击的薄弱环节。 + +有人指出纵深防御和保护最弱环节的设计原则存在某种矛盾性。一个设计原则，强调要采取多种安全措施纵深防御，一个设计原则强调找出安全链条的最弱一环。其实两设计条原则侧重点不一样。纵深防御是着眼于整个软件系统，采取层层防御，防止单点失效。保护最弱环节，是着眼于软件系统中各个功能独立的组件，找出最容易受到攻击的一环，进行加固。 + +**如何执行保护最弱环节的安全设计原则：** + +1. 软件拆解，逐一评估：将一个软件系统拆解成一个个的组件，逐一进行风险分析，找出系统最薄弱的环节，进行加强安全设计。 + +2. 重点关注一个软件的子系统之间的通信安全，通信很容易成为一个薄弱环节。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是，对系统提供的各种基础安全能力的风险评估，例如用户登录认证的安全评估，防网络ddos攻击能力的安全评估，系统提供的强制访问安全机制的安全评估，从这些基础安全能力中找出最弱环节，进行安全加固 + +2. 在产品级软件设计中，更多的考虑的是，对产品按业务拆分的各个子系统的安全评估，以及对子系统间的通信方式进行安全性评估，找出最弱环节进行安全加固 + +3. 在模块级软件设计中，更多的考虑的是，对模块内部安全机制进行安全评估，以及对模块对外设计接口进行安全评估，找出最弱环境进行安全加固。 + +### 典型场景 + +1. 针对用户总是采用弱口令导致用户密码破解的问题，在一个产品的用户注册系统中，强制进行密码复杂度检查，要求密码复杂达到规定的强度后，才允许用户注册。 + +2. 一个root权限的后台服务的对外服务接口，必须强制进行polkit认证，才能授权用户使用。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-5 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-5 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-5 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 异常安全 + +### 规则阐述 + +异常安全，指的是在软件设计阶段，对软件程序可能面临的各种异常情况进行充分的考虑，并且对异常处理流程进行充分的设计。最优的设计方案是，能采用某种备用机制，使得软件从异常故障状态中恢复，能够继续提供服务，次优的设计方案，则是保证软件程序即使进入异常故障的情况下，也不会产生安全漏洞。 + +利用程序异常处理代码的处理不当，获取信息泄露，或者实现权限提升是攻击者的常用手段。而异常处理也是软件开发人员在设计方案时候会经常忽视，很多软件开发人员会默认自己设计的软件流程会完美的运行，或者天然的认为某种异常情况是理论上不可能出现。而忽略了由于软件系统的复杂性，多种因素的叠加，导致理论上"不可能"出现的情况，常常被攻击者成功复现。 + +攻击者也会使用fuzz等模糊测试工具，攻击构造大量异常数据流，尝试引发系统进入异常故障状态，触发内存泄漏或缓冲区溢出，然后再进一步考虑如何利用缓存区溢出成功实现执行代码跃迁，实现信息泄露或者权限提升。这种利用攻击工具进行大量的异常数据攻击，发现由于系统故障处理不当的攻击路径是一种最常见的攻击者辅助攻击手段。 + +有效预防这种模糊测试攻击的方法，只能是在软件设计阶段，对异常情况做充分的考虑，考虑清楚软件的每一个可能场景以及处理方案。并且在软件编码阶段，严格遵守安全编码规范，增加代码的鲁棒性，对每一个可能异常分支，进行合理的逻辑处理。 + +异常安全的设计原则，还有一个重要的作用，就是抵御拒绝服务攻击，攻击者很多时候利用软件异常情况很多时候并不能实现权限提升，但是很有可能让程序崩溃，达到拒绝服务的攻击目的。 + +**如何执行异常安全设计原则：** + +1. 在做软件方案设计时，针对一个设计场景，要穷举所有可能场景，并针对所有场景制定合理的处理流程。 + +2. 不要因为一个逻辑分支的可能性极小，而忽略它。 + +3. 设计备用机制，在程序异常故障的时候启用，继续提供服务。 + +4. 在设计软件接口时，定义清楚输入参数的范围，指导软件开发人员的编码工作。 + +5. 当软件逻辑进入到一个异常场景的时候，可以不能正确地提供服务，但是不能导致软件系统崩溃。 + +6. 如果软件无法避免异常，无法从故障中恢复，那么请确保在这种情况下软件的安全。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是系统提供的基础性服务的健壮性，例如为网络端口提供防ddos攻击的安全能力，为远程服务提供稳定可靠的登录认证安全能力，既要保证认证过程的安全等级，又要提供防暴力破解的消减措施，同时要重点防范拒绝服务类攻击。 + +2. 在产品级软件设计中，更多的考虑的是对外服务的健壮性。例如当一种对外通信机制失效的情况下，是否能够应急启动另外一种对外通信机制。当产品的一个服务组件失效时，有没有提供备用组件继续提供服务等等。最低限度的安全设计要求则是当产品陷入异常故障之中无法恢复时，也不能损失用户数据，或者导致用户数据泄露。 + + 3、在模块级软件设计中，更多的考虑的是接口的健壮性。例如定义清楚接口的参数的范围和边界，不要出现模糊地带，软件开发人员则要严格检查输入参数的边界。 + +### 典型场景 + +1. 如果应用程序把用户恶意构造的字符串带入到数据库查询语句中，并直接将数据库查询产生的异常报错信息显示在前台，攻击者就可以利用SQL报错型注入方法构造payload，直接查询获取数据库中所有的数据； + +2. 攻击者可以通过缓冲区溢出来重写存储在返回地址内的值从而达到控制程序的执行流程的目的； + +3. 在实现一个软件接口时，要对所有的参数做边界检查，并保证各种异常参数输入时，接口能保证安全执行，不出现缓冲区溢出。 + +4. 攻击者构造异常输入参数，引发软件崩溃，实现拒绝服务攻击。 + +5. linux内核的设计原则之一，就是假设应用程序的开发者完全不懂操作系统，那么至少要保证应用程序的异常不能导致操作系统崩溃。围绕这一核心目标，才有了linux的内核空间和用户空间的隔离设计，接口异常处理设计，oom内存管理回收机制等等设计。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-6 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-6 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-6 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 默认安全 + +### 规则阐述 + +默认安全是指，在软件设计中，为用户提供合理安全措施，并且默认处于开启状态，包括默认开启文件安全权限、默认开启安全策略，尽可能让用户不需要额外配置软件就可以实现默认的安全防护。默认安全设计原则也是保持系统简单化的重要方式。 + +软件设计人员在进行方案设计的时候，经常犯的一个错误是认为软件的使用者也具备跟自己一样的安全知识和意识。在心理学上，这普遍存在的现象被称为"知识的诅咒"，一个人一旦知道了某件事，就很难想象这件事在未知者眼中的样子。而且一个对某件事研究的越深，知识的对他的"诅咒"也越深，也越不能理解未知者。因此，一个资深物理学家写的关于量子计算机的科普文章可能晦涩难懂，一个资深安全专家可能无法理解用户怎么会设置一个弱口令。 + +要破除"知识的诅咒"，一个最好的办法就是，假设你的读者没有任何物理学基础，你在科普文章中要从头给他介绍有关基础物理原理，量子物理原理，量子计算原理的一切。 + +在软件设计中，总是假设用户没有任何安全方面的知识，以此为基础来设计我们的软件逻辑，例如，要引导用户进行安全的配置，在用户设置密码时，提示用户密码强度不足，以及向用户解释怎样的密码才算一个好的密码。总之你的设计就是要给用户你能提供的最好的、最合适的安全防御措施，这就是默认安全的核心思想。 + +**如何执行默认安全设计原则：** + +1. 为用户提供默认的安全配置。 + +2. 为专业用户保留修改安全配置的能力。 + +3. 以引导的方式，提示用户做出更好的安全配置，并且培养用户的安全意识。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是系统默认提供和开启的安全策略是哪些，开启时应该使用何种方式。例如应用程序执行安全，应用防护，联网保护，端口保护功能，是应该默认开启，默认开启是强制生效，还是引导用户自己做出选择。 + +2. 在产品级软件设计中，更多的考虑的是产品默认开启的安全策略，例如用户的登录认证，密码的默认强度，默认提供防暴力破解的消减措施等，给用户设置合理的默认权限等，默认对用户数据进行加密和隐私保护。 + +3. 在模块级软件设计中，更多的考虑的是，默认限制用户对特权接口的任意访问，对模块中存储数据的保密性保证和完整性验证，对模块内使用的文件的默认权限设置，对模块间通信数据安全保证。 + +### 典型场景 + +1. 用户登录认证，默认设计口令复杂度检查，不能使用弱口令，默认开启密码错误达到一定次数后，锁定账号一段时间功能，避免密码被暴力破解。 + +2. 对用户存储的数据，默认设计加密，数字签名保护措施，防止数据被窃取，被篡改。 + +3. 远程数据通信和本地数据通信默认都要采用身份认证和通信数据加密。 + +4. 操作系统对特权系统调用默认采用DAC权限检查，保证了只有特权用户，或者特权进程，或者具备某种特殊权能的进程才能执行这些系统调用，用户不需要了解这些安全特性就能享受这些安全策略的保护。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-7 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-7 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-7 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 业务分割 + +### 规则阐述 + +业务分割，是指将软件的系统功能或者业务分割成尽可能多的独立单元，并且独立单元之间要实现某种程度的资源隔离，当某一个单元模块出现安全漏洞时，不会影响其他的单元，将单一安全漏洞产生损害程度降低到最小。 + +业务分割安全设计原则的一个经典的比喻就是，不要把所有鸡蛋都放在一个篮子里。一个篮子不慎跌落，打烂的只是这一篮子鸡蛋，我们还有其他篮子和鸡蛋。通过篮子和鸡蛋的比喻，我们还能说明这样一个道理，篮子并不是越多越好。最安全的设计当然是一个篮子一个鸡蛋。但是每增加一个篮子就要增加相应的成本开支，因此在现实中我们通过安全评估，采用增加适当的篮子数量分散风险。 +同样的在软件设计中，业务分割也会带来隔离成本，我们要平衡软件安全性，隔离成本，软件单元之间通信的性能损耗成本，以及复杂度提升带来的软件管理成本。 + +同时作为一个安全设计原则指导，我们建议软件设计人员在按业务功能采取进行高内聚，低耦合的设计，也同时要考虑按照权限等级，大小进行业务分割的设计。同一权限的业务更适合放在一起，不同权限的业务更适合分开。这一设计指导，我们在最小权限设计原则的章节也进行的相同的描述，这也说明最小权限安全设计原则和业务分割安全设计原则，是相互补充和相互促进的关系，可以在软件设计过程中同时进行考虑。 + +**如何执行业务分割安全设计原则：** + +1. 业务分割分为纵向和横向两个维度，通常的方法是先将业务按功能横向划分为不同的业务子系统，然后在业务子系统再实施纵向业务分割，划分为前台，中台，后台等。 + +2. 同时从业务功能内聚角度和权限内聚的角度去考虑业务分割的问题。 + +3. 横向的业务划分通常是赋予不同种类的权限。 + +4. 纵向的业务划分通常是赋予不同等级的同类权限。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是横向业务划分，将不同的系统功能划分为不同的功能子系统，而系统的纵向划分通常要遵循一个系统的通用架构设计，例如linux将操作系统从纵向划分为内核空间和用户空间，那么每一个linux子系统都需要满足这样的纵向划分原则。 + +2. 在产品级软件设计中，需要同时进行横向和纵向的业务划分，按照我们建议的划分方法，先进行横向业务划分，再进行纵向业务划分。 + +3. 在模块级软件设计中，更多的考虑的是纵向业务的划分。我们通常赋予一个模块某种特定的权限，在纵向的划分过程中，原则都是前台赋予一个低权限，后台赋予一个高权限。 + +### 典型场景 + +1. 在一个多用户数据访问系统中，我们首先将业务横向划分为用户登录管理子系统，数据访问子系统两个业务模块。用户登录管理子系统，负责管理用户密码，管理用户登录会话，赋予的是发起用户密码认证的权限。数据访问子系统，赋予的是用户对用户和系统存储数据的访问，修改权限。然后在子系统内部再进行纵向划分，例如将数据访问业务子系统纵向再划分为前台和后台两个子系统，前台通常具备的是数据只读权限，后台通常具备的是数据读写权限。 + +2. 在linux操作系统中，系统提供的功能按业务横向划分为，CPU调度，内存管理，文件系统，设备驱动等横向linux子系统，然后在每个子系统内部，再划分为纵向的内核空间和用户空间两个层次的软件模块。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-8 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-8 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-8 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 不要轻信 + +### 规则阐述 + +不要轻信，是指我们在软件设计中，不要轻易相信第三方开发的组件和服务，甚至也不要轻易相信自己开发的程序。只有经过充分的安全评估，才能信任一个第三方组件和服务，软件的服务端只有再采取了充分的身份认证之后才能信任哪怕是自己开发的客户端。 + +信任关系是在两个实体间（组织，个人，软件）基于对方的了解程度建立起来的一种关系。而在两个软件之间要定义清楚这种了解程度，并不是一件简单的事情。我们可以从某个行业软件如何获取安全认证的角度理解这件事情。安全认证是一个综合性的，复杂的安全评估过程，安全机构不会仅仅因为送测的系统通过了渗透测试和黑盒安全测试用例就认可你的软件的安全性。一个安全认证过程，通常有以下几个常见步棸：系统安全启动方案评估，系统配置安全评估，系统编译安全评估，系统文件权限检查，系统软件非安全函数扫描，系统开源软件版本扫描，安全测试用例执行。通过所有的这些复杂的步棸，才能让安全机构对你提供的系统有了充分的了解，从而建立起某种程度的信任关系，基于这种信任关系，安全机构才会给你签发符合相应安全等级的安全证书。 + +信任拓展，指得是信任关系可以通过某种方式进行拓展。例如我们通过漏洞扫描工具对第三方开源组件进行漏洞扫描，确认第三方开源组件已经修复了所有已知的安全漏洞，我们选择信任第三方开源组件。这就是一种信任拓展方式。可信计算技术中，通过根证书对系统应用签发数字签名，也是一种信任拓展的方式。 + +软件设计人员要时刻警惕信任拓展的被滥用的风险。并没有经过安全评估就选择信任第三方，或者没有经过应用程序安全审核就签发应用程序签名就是典型的滥用信任拓展的情况。会给软件系统带来未知的安全风险。 + +**如何执行不要轻信安全设计原则：** + +1. 在软件系统中谨慎地引入第三方组件：要经过充分的评估，需要评估组件的技术方案，安全方案，使用漏洞扫描工具扫描开源组件的漏洞修复情况，使用安全编码门禁工具扫描第三方组件的非安全编码行为等。 + +2. 在CS架构中，服务端的软件设计要天然的对客户端保持怀疑，首要的就是客户端必须使用身份认证技术证明自己身份；即使客户端证明了自己的身份，服务端也要考虑对客户端的权限做某种限制。 + +3. 一个高权限服务默认对一个低服务服务默认采取不信任策略。 + +4. 在可信证书链中，上级证书要对下级证书负有安全评估责任，下级证书有向上级证书证明自身安全的义务。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是，对系统提供的开源软件，进行安全评估，例如对开源组件进行漏洞扫描工具扫描，非安全编码行为工具扫描等，如果不符合我们设定的安全标准，则不能引入。其次，针对系统提供的远程服务，例如sshd，smbd，rdp等，需要进行权限限制，以及安全加固。 + +2. 在产品级软件设计中，更多的考虑的是，首先也是工具扫描，在符合引入标准之后，需要进一步的对第三方的安全方案进行全面评估，最终决定引入。 + +3. 在模块级软件设计中，更多的考虑的是模块中，高权限模块要采取不信任低权限模块的默认策略。高权限模块的数据要使用文件权限控制，数据加密签名等手段，阻止低权限模块的直接访问。高权模块在提供服务接口时要设计身份认证方案。高权限模块需要对低权限模块传入的参数，数据进行合规性检查等。 + +### 典型场景 + +1. openssl开源组件是一个被广泛采用的网络安全通信基础包，大部分的网络服务都是基于openssl进行加密通信来进交换密码，如果openssl软件包被攻击者修改，植入木马，那么主机上的所有基于openssl进行网络通信服务，都能够被攻击者利用中间人攻击窃取所有通信数据。 + +2. ssh服务端对ssh客户端采取不信任策略，实施客户端需要使用tls加密通信方式向ssh服务端发起用户身份认证，在输入正确的用户名密码之后才能登录远程服务器。ssh服务默认禁止root用户直接登录，避免被暴力破解。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-9 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-9 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-9 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +## 公开设计 + +### 规则阐述 + +公开设计安全设计原则，只是软件的安全性不能依赖对软件设计方案进行保密来保证，软件设计的安全性应该来自于设计本身。 + +一个公开设计的经典例子是加密算法的设计。不了解密码学的人会有这样的疑惑，为什么国际标准密码算法都是算法公开和源码公开的，不担心被攻击者利用吗？这是因为加密算法的安全性不会因为算法公开而降低，加密算法的安全性是由其秘钥决定的，只要保证了秘钥的安全存储，不被攻击者拿到，也就保证了加密数据的安全。密码算法因为算法公开，从数学上证明了理论上的破解难度，反而证明了自己的安全性。 + +软件设计人员的一个通常的设计误区，在于认为从二进制格式保存的数据，或者二进制程序中提取秘密信息是一件很困难的事情，从而认为二进制保存数据，或者将重要信息硬编码在程序中是一件安全的事情。实际上对有经验的攻击者来说，从二进制中提取秘密信息并不是那么困难。例如，明文二进制数据，base64编码数据，加密数据，在有经验的攻击者看来都是具有明显的区别的数据块，很容易区别。而加密算法中，非对称加密和分组对称算法，分别会在不同的场合下采用，密文长度也有不同的要求，这些也都有办法进行区别。而熟悉逆向工程的攻击者能够很容易找出二进制程序中的隐藏的硬编码信息。 + +公开设计的另一层含义是，软件设计人员不要在软件中最终发布软件中预留软件后门，例如通过某种特殊方式绕过安全机制，通过某一个隐藏的功能接口执行特权功能，通过一个隐藏的协议或者端口进行特别的通信，因为这些隐藏手段在攻击者看来并不高明，这些隐藏的后门设计一定会被攻击者利用。如果一个软件需要提供一个调试功能，那这个调试功能要求一定不会影响软件安全性的，因此要求以无须隐藏，可以公开的方式进行软件设计。 + +**如何执行公开设计安全设计原则：** + +1、公开安全设计，尽可能让更多的人参与到安全设计的评审过程。 + +2、软件设计中应该采用公开的，经过严格证明的行业标准加密算法，行业认可的身份认证技术，行业认可的安全通信技术等，而不是使用自己设计的私有的加密算法，通信协议，认证技术等，并试图通过设计保密以保证安全。 + +3、设计安全方案保护你的加密秘钥等重要信息，而不是在软件中使用硬编码方式保存。 + +4、始终记住二进制格式保存数据并不能保证数据的安全性。 + +5、不要在最终发布的软件中包含隐藏的软件后门，这些后门会被利用。 + +### 适用范围 + +1. 在系统级软件设计中，更多的考虑的是，系统提供的基础安全功能的安全性，应该由系统的基础安全设计方案来保证，而不是试图通过对这种安全机制的实现方案保密来保证。 + +2. 在产品级软件设计中，更多的考虑的是，产品用户身份认证技术，组件间的身份认证技术，组件间的安全通信技术，产品数据安全保存技术都要符合行业标准和规范，而不是意图采用隐藏技术方案与闭源代码实现其安全性。 + +3. 在模块级软件设计中，更多的考虑的是，设计模块重要信息的安全保存方案，以及加密秘钥的安全存储，避免采用硬编码的方式保存重要信息 + +### 典型场景 + +1. 在软件系统中，设计统一的秘钥管理中心服务，为其他应用程序提供秘钥安全保管服务，这是一种秘钥基础设施的公开设计方案。 + +### 落地策略 + ++-----------+---------+-----------------------+-----------------------+ +| 范围 | 适用性 | 落地策略 | 落地检查 | ++-----------+---------+-----------------------+-----------------------+ +| 模块级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-10 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| 产品级 | 是 | - 考试培训 | 培 | +| | | | 训反馈，考试成绩反馈 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-10 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | 设计文 | +| | | | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全编码规范门禁系统 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| 系统级 | 是 | - 考试培训 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - 安全设计检视 | 自检项编号：C-SDC-10 | ++-----------+---------+-----------------------+-----------------------+ +| | | - | 设计文 | +| | | 安全编码规范门禁系统 | 档评审，检视结果评审 | ++-----------+---------+-----------------------+-----------------------+ +| | | - 设计方案安全评审 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 《产品安全红线》检查 | | ++-----------+---------+-----------------------+-----------------------+ +| | | - | | +| | | 安全攻防、渗透测试 | | ++-----------+---------+-----------------------+-----------------------+ + +# 推荐资料 + +《安全软件开发之道 构筑软件安全的本质方法》 -- Gitee From 15044abcdf3fac3670973553edbc40901a437335 Mon Sep 17 00:00:00 2001 From: suxin <2439462239@qq.com> Date: Tue, 25 Oct 2022 08:01:29 +0000 Subject: [PATCH 2/4] update baseline/security-design-principle.md. Signed-off-by: suxin <2439462239@qq.com> --- baseline/security-design-principle.md | 98 --------------------------- 1 file changed, 98 deletions(-) diff --git a/baseline/security-design-principle.md b/baseline/security-design-principle.md index e44fd81..3ea870b 100644 --- a/baseline/security-design-principle.md +++ b/baseline/security-design-principle.md @@ -70,104 +70,6 @@ ----------- ------------ ---------------------------------------------------------------------------------------------------------------------- ------------ ------------ ---------- ----------- -目录 - -[1 文档介绍 - 3 -](\l) - -[1.1 文档概述 - 3 -](\l) - -[1.2 文档使用指南 - 3 -](\l) - -[1.3 文档的更新与改进 - 4 -](\l) - -[1.4 落地方法 - 4 -](\l) - -[2 安全设计原则 - 5 -](\l) - -[2.1 最小攻击面 - 5 -](\l) - -[2.1.1 规则阐述 - 5 -](\l) - -[2.1.2 适用范围 - 6 -](\l) - -[2.1.3 典型场景 - 6 -](\l) - -[2.1.4 落地策略 - 7 -](\l) - -[2.2 最小权限 - 7 -](\l) - -[2.2.1 规则阐述 - 7 -](\l) - -[2.2.2 适用范围 - 8 -](\l) - -[2.2.3 典型场景 - 9 -](\l) - -[2.3 纵深防御 - 9 -](\l) - -[2.3.1 规则阐述 - 9 -](\l) - -[2.3.2 适用范围 - 10 -](\l) - -[2.3.3 典型场景 - 10 -](\l) - -[2.4 白名单 - 10 -](\l) - -[2.4.1 规则阐述 - 10 -](\l) - -[2.4.2 适用范围 - 12 -](\l) - -[2.4.3 典型场景 - 12 -](\l) - -[2.5 保护最弱环节 - 12 -](\l) - -[2.5.1 规则阐述 - 12 -](\l) - -[2.5.2 适用范围 - 13 -](\l) - -[2.5.3 典型场景 - 13 -](\l) - -[2.6 异常安全 - 14 -](\l) - -[2.6.1 规则阐述 - 14 -](\l) - -[2.6.2 适用范围 - 15 -](\l) - -[2.6.3 典型场景 - 15 -](\l) - -[2.7 默认安全 - 16 -](\l) - -[2.7.1 规则阐述 - 16 -](\l) - -[2.7.2 适用范围 - 17 -](\l) - -[2.7.3 典型场景 - 17 -](\l) - -[2.8 业务分割 - 17 -](\l) - -[2.8.1 规则阐述 - 17 -](\l) - -[2.8.2 适用范围 - 18 -](\l) - -[2.8.3 典型场景 - 19 -](\l) - -[2.9 不要轻信 - 19 -](\l) - -[2.9.1 规则阐述 - 19 -](\l) - -[2.9.2 适用范围 - 20 -](\l) - -[2.9.3 典型场景 - 21 -](\l) - -[2.10 公开设计 - 21 -](\l) - -[2.10.1 规则阐述 - 21 -](\l) - -[2.10.2 适用范围 - 22 -](\l) - -[2.10.3 典型场景 - 23 -](\l) - -[3 推荐资料 - 23 -](\l) - # 文档介绍 ## 文档概述 -- Gitee From 697e01a0f5d6a59b68d35bc50a6c8705d0e121f3 Mon Sep 17 00:00:00 2001 From: suxin <2439462239@qq.com> Date: Tue, 25 Oct 2022 08:02:34 +0000 Subject: [PATCH 3/4] update baseline/security-design-principle.md. Signed-off-by: suxin <2439462239@qq.com> --- baseline/security-design-principle.md | 45 --------------------------- 1 file changed, 45 deletions(-) diff --git a/baseline/security-design-principle.md b/baseline/security-design-principle.md index 3ea870b..bc072f1 100644 --- a/baseline/security-design-principle.md +++ b/baseline/security-design-principle.md @@ -12,7 +12,6 @@ **版本说明** - ----------- ------------ ---------------------------------------------------------------------------------------------------------------------- ------------ ------------ ---------- ----------- **日期** **版本号** **发布说明** **编写者** **签批人** **角色** **人员** **签字** @@ -26,50 +25,6 @@ 2022.5.16 V1.1 将安全设计原则缩减为核心的10条原则，并且对每条安全设计原则分规则阐述，使用范围，典型场景，落地策略四个小节进行描述。 徐建 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ----------- ------------ ---------------------------------------------------------------------------------------------------------------------- ------------ ------------ ---------- ----------- - # 文档介绍 ## 文档概述 -- Gitee From 0c59b5e0c72f6ab1be8d3ebad8dc7302f2c50d11 Mon Sep 17 00:00:00 2001 From: suxin <2439462239@qq.com> Date: Tue, 25 Oct 2022 08:04:12 +0000 Subject: [PATCH 4/4] update baseline/security-design-principle.md. Signed-off-by: suxin <2439462239@qq.com> --- baseline/security-design-principle.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/baseline/security-design-principle.md b/baseline/security-design-principle.md index bc072f1..0bbfe1e 100644 --- a/baseline/security-design-principle.md +++ b/baseline/security-design-principle.md @@ -13,7 +13,6 @@ **版本说明** **日期** **版本号** **发布说明** **编写者** **签批人** - **角色** **人员** **签字** 2021.2.15 V1.0 产品安全设计原则 史昕岭 编写人 史昕岭 @@ -24,7 +23,6 @@ 2022.5.16 V1.1 将安全设计原则缩减为核心的10条原则，并且对每条安全设计原则分规则阐述，使用范围，典型场景，落地策略四个小节进行描述。 徐建 - # 文档介绍 ## 文档概述 -- Gitee