安全(Security)设计原则（1）

概述

开发安全相关系统时，ISO/SAE 21434:2021建议遵循安全领域的设计原则。

ISO/SAE 21434:2021 Clause 10.4 [RC-10-06] Established and trusted design and implementation principles should be applied to avoid or minimize the introduction of weaknesses.

本文参考如下标准，介绍设计原则的第1部分: Security Architecture and Design

Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, NIST, 2018

本部分内容与系统的架构和设计相关，包括了将系统分解成系统元素，以及设计系统元素间的交互和接口时的一些设计原则。

1. Clear Abstractions /清晰的抽象

清晰的抽象原则是指：模块接口和功能应做到简单、清晰、最小必要性、充分满足、准确。

遵循本原则，可以使系统的结构和关系简单，这样就更容易进行分析、测试和使用。

设计时可以采用避免冗余(avoidance of redundant)、避免未使用接口(unused interfaces)、信息隐藏(information hiding)、避免接口或参数语义过载(avoidance of sematic overloading)等方式。

说明：

信息隐藏(information hiding)示例：A模块调用B模块接口时，B模块的内部信息对A模块是不可见的。（注：这也是低耦合、或implementation free原则的体现）

接口语义过载(sematic overloading)示例：某函数根据其被调用的形式，提供了不同的功能。（注：这种情况时，该函数不满足“单一性”的设计原则）

2. Least Common Mechanism /最小公用机制

最小公用机制原则是指：访问系统资源时，应尽量避免使用公用访问机制，以免造成模块间的相互影响。

公用机制中可能包括一些潜在的信息路径、数据流或控制流。

3. Modularity and Layering /模块化和分层

模块化和分层原则是指：应通过模块化分解和分层方法简化复杂系统。

架构设计(或设计)的过程，是对系统需要实现的功能进行分解，并分配到系统元素，进而设计系统元素之间的交互关系。在这个过程中：

模块化是把功能及其相关的数据结构隔离到定义良好的某个逻辑单元中。

分层可以更好地明确逻辑单元之间的关系，避免不必要的复杂性。

模块化设计原则，也可以帮助实现空间和时间上的隔离(partitioning)。

4. Partially Ordered Dependencies /偏序依赖

偏序依赖原则是指：模块之间的依赖关系应尽可能单向，具有层次关系的模块之间应尽可能做到自上向下依赖，对于循环性依赖应限制在单一层级内。

偏序依赖关系是数学集合中的表示"集合中元素间关系"的一个概念。

示例：模块A可以调用模块B，而模块B不能调用模块A。模块A和模块B之间的依赖关系是单向的，是一种偏序依赖关系。

系统设计的过程是通过将系统分解为一个一个系统元素，将每个系统元素设计在合适的位置(不同的层次)，并设计这些元素之间的关系。在这个过程中，各层之间遵循偏序依赖关系，上层依赖于下层，存在循环依赖的场合，限制在本层内。这样可以使系统元素之间的关系简化。

5. Efficiently Mediated Access /高效中介访问

安全相关的系统中，公共资源（如：CPU、内存、设备、通信端口、服务、基础设施、数据和信息）的访问，往往是主要的安全功能。资源访问不当可能会导致性能瓶颈。

高效中介访问原则是指：应尽可能少的利用公共资源，并且采用相应措施来确保“访问过程”的高效、畅通、不易造成性能瓶颈。

例如：通过使用硬件机制，实现高效的内存访问和保护。

6. Minimized Sharing /最小化共享

最小化共享原则是指：除非绝对必要，否则系统组件之间不应共享资源。

资源共享的风险：

可能会增加数据和信息的未授权访问、使用或修改的风险。

由于多个系统组件共享资源，可能会存在性能、资源存储、访问时机/时间竞争等问题。

最小化共享也有助于简化设计和实现。

7. Reduced Complexity /降低复杂度

降低复杂度的原则是指：系统设计应尽可能的小而简单。

小而简单的设计将更容易理解、分析、更不容易出错，包含的漏洞更少。

8. Secure Evolvability /演化性

演化性原则是指：应基于对未来的预判，系统性的规划安全，尽量避免因发生变更而临时调整对策。

虽然不可能对系统在各个方面的演化进行规划，但可以通过分析系统的使命或业务战略方向来预测系统的变化、预测环境的变化、预测维修和维护的需求等。

例如：在产品设计时，将可信度(trustworthiness)构建到系统中。

9. Trusted Components /信任组件

信任组件的原则是指：组件（被依赖方B）应值得信赖（B应向依赖方A提供足够的证据，证明自己值得信赖），表示为：A信任B。

为实现这个原则，需要一些度量，通过度量来在相同的抽象尺度上度量组件的可信度。

例如：

A模块调用B模块

A模块的可信度是X

B模块的可信度 >= X

组件之间进行组合或组件之间存在依赖时，这个原则尤其重要。

例如：复合组件的整体可信度等于其所包含的最不可信的子组件的可信度。

10. Hierarchical Trust /层次信任

层次信任原则是指：信任可分层，多层之间应单向信任，如：A信任B，B信任C。

这个原则可以帮助分析由信任组件构成的系统的可信度。

信任关系或信任链示例：

证书层次结构的根证书是层次结构中最可信的节点，而层次结构中的叶子可能是最不可信的节点。

分层系统中，位于系统最低层的安全内核是最可靠的组件。

11. Inverse Modification Threshold /基于信任度调整保护

基于信任度调整保护原则是指：组件的保护措施应能够匹配其设定的可信度，以证明自己值得信赖。

这种保护措施可以是组件自身的自我保护，也可以是其它组件为其提供的保护。

12. Hierarchical Protection/分层保护

分层保护原则是指：不需要保护组件免受更可靠组件的攻击。（即：可以不考虑比自己更值得信赖的组件会对自己发起攻击。）

例如：如果操作系统内核被认为是系统中最值得信任的组件，那么它必须保护自己不受应用程序的攻击，但反过来，应用程序不需要保护自己不受内核的攻击。

13. Minimized Security Elements /最少安全元素

最少安全元素原则是指：系统不应包括无关的可信任组件。

可信任组件的数量越少，信任关系就越少，系统就越简单；与其对应的开发和分析成本就越少。

14. Least Privilege /最小特权

最小特权原则是指：应为每个组件分配完成其指定功能的最小必要权限。

这个原则限制了组件的操作范围，会有两个效果：

组件故障、损坏或误用的安全影响最小化

简化了组件的安全分析

15. Predicate Permission /特权分离

特权分离原则是指：在操作或访问高度敏感数据、信息或资源之前，需要多个授权实体提供同意。

多方实体之间的特权划分降低了权力滥用的可能性。

这种机制的设计方案可能需要多个实体同时采取行动（例如，发射核武器需要两个授权人员在一个小的时间窗口内发出正确命令），或需要一系列行动，但没有一个实体有权力来顺序操作多个行动。

16. Self-Reliant Trustworthiness /自建信任

自建信任原则是指：应尽可能少的通过对其它实体的依赖来获得自身的可信性。（即：在建立信任时应尽可能避免依赖其它实体。）

如果需要维护与另一个外部实体的连接以保持其可信性，那么该实体将容易受到威胁。

17. Secure Distributed Composition /策略一致性

策略一致性原则是指：应将分布式系统视作整体，利用本文中的原则为其制定一套完整的安全策略，其子组件应遵循该策略。

本文谈到的很多设计原则都涉及组件之间的交互。分布式系统作为一个整体，也需要有效应用这些原则。

18. Trusted Communication Channels /可信通道

可信通道原则是指：通信通道应值得信赖（通道应向通信双方提供足够的证据证明自己值得信赖）

可以采用如下两个方式的组合来建立可信通道：

通信通道的访问控制

端到端(E2E)保护

安全(Security)设计原则（1）相关推荐

安全(Security)设计原则（2）
Security Capability and Intrinsic Behavior /安全的能力与行为安全的能力与行为相关的设计原则是指:为实现安全,必须要定义.设计和实施的系统行为.这些行为通常 ...
安全体系结构与七个设计原则
安全体系结构的七个设计原则. FLASK体系结构的主要特点. FLASK体系结构中客体服务器OM和安全服务器的基本组成和作用. LSM框架的特点,及其对内核的主要修改第一章安全体系结构的七个设计原则 ...
《VMware vSphere设计（原书第2版）》——1.3　设计原则
本节书摘来自华章出版社<VMware vSphere设计(原书第2版)>一书中的第1章,第1.1节,作者:[美] 福布斯·格思里(Forbes Guthrie)斯科特·罗威(Scott ...
微服务设计原则和解决方案
一.微服务架构演进过程近年来我们大家都体会到了互联网.移动互联带来的好处,作为IT从业者,在生活中时刻感受互联网好处的同时,在工作中可能感受的却是来自自互联网的一些压力,那就是我们传统企业的IT建设 ...
mysql 按日期拆分成多条记录_mysql性能优化2 设计规范设计原则结构优化拆分配置优化...
一.MYSQL数据库设计规范 1.数据库命名规范 a.采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成; b.命名简洁明确(长度不能超过30个字符); c.例如:us ...
微服务的4个设计原则和19个解决方案
微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设 ...
微服务的4个设计原则和19个解决方案 1
微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设 ...
腾讯技术分享：微服务接口设计原则
来源|腾讯技术工程(ID:Tencent_TEG) 本文结合自身后台开发经验,从高可用.高性能.易维护和低风险(安全)角度出发,尝试总结业界常见微服务接口设计原则,帮助大家设计出优秀的微服务. 1.前 ...
30条设计原则：之物极必反
Apache的架构师们遵循的30条设计原则本文作者叫Srinath,是一位科学家,软件架构师,也是一名在分布式系统上工作的程序员. 他是Apache Axis2项目的联合创始人,也是Apache S ...

安全(Security)设计原则（1）

安全(Security)设计原则（1）相关推荐

最新文章

热门文章