悦库安全访问白皮书V1
信息化时代背景下，企业中大多数数据以文件形式进行保存、共享、访问，数据即资产，文件即资产。
出于数据隐私的考虑，企业中不同部门、不同项目中的人员所能访问的文件和对其能进行的操作都必须是安全可控的，我们在本文中第1~4章阐述了大组织中对海量树结构分布的文件进行更有效、灵活的安全访问控制方法。
在第6章介绍了文件的流程化，这有助于企业建立文件协同工作的标准流程，实现高效工作。
在大型企业中，软件的合规性尤其重要，参考国家《网络安全等级保护测评》标准，实现系统和软件的网络信息安全功能，可以从整体上度量企业信息化系统的标准安全规格。在第7章中我们对国际《信息技术安全评估通用标准》和国家《网络安全等级保护测评》标准做了一些总结。
1. 组织
组织架构是将企业人员根据工作职能建立的具有上下层级结构的有向无环图，由总部、单位、部门、人员四个组织层级组成。
总部是一个组织的最顶级单位，例如集团名称、大学名称等，系统中有且只有一个总部。总部下包含多个层级的单位，而单位中也包含多个部门，形成一个树形组织结构。总部本身也是一个特殊的单位，遵守单位相关规则。
单位，是一种隶属于总部的组织逻辑类型，通常用于建立一个相对独立的人员管理逻辑范围，具有独立的组织结构和文件访问安全边界。例如集团子公司、大学学院、集团医院分院等。单位中可以包含多个子单位或部门，可以在总部或其他单位之下，但不能在部门下。
部门 是一个独立组织下的分支机构。可以直接隶属于总部，或某一个单位，可以在总部、单位、其他部门之下。
人员是隶属于组织中的个人，人员可以直接隶属于总部，也可以同时隶属于多个部门或单位中。
简化的树形组织结构示例：
1.1 组织关系
总部关系
- 总部下可以有0 或多个单位，单位有且只有1个总部。
- 总部下可以有0或多个部门，部门有且只有1个总部。
- 总部下可以有0或多个人员，人员必须隶属于1个总部。
单位关系
- 单位可以有0或多个子单位，子单位1个或多个上级单位。
- 单位可以有0或多个部门，部门有1个或多个上级单位。
- 单位可以有0或多个人员，人员可以隶属于1个或多个上级单位。
部门关系
- 部门可以有0或多个子部门，子部门有1个或多个上级部门。
- 部门可以有0或多个人员，人员可以隶属于1个或多个上级部门。
人员关系
- 人员可以直接隶属于总部/单位/部门之下。
- 人员必须隶属于1个总部，但可以同时隶属于多个单位或部门之下。
1.2 组织隔离
单位 是一个相对独立的组织，拥有单位范围的安全边界。各单位之间在组织访问、文件访问、角色设置等操作中相互隔离，默认不能互通。
例如在集团医院中，如果将市北分院和崂山分院定义为单位，则默认市北分院的人员无法访问崂山分院的文件，同时也看不到崂山分院的组织结构。市北分院中创建和设置的自定义角色在崂山分院中不可见。
1.3 组织协作
在相互隔离的单位之间建立协作关系，是企业中常见的应用场景。
单个人员可以通过设置和授权方式实现对其他单位的组织或文件的访问。
例如：
- 通过将
市北分院的用户小明，设置可见西海岸分院，小明就可以访问西海岸分院的组织结构。 - 通过将
市北分院的用户小明，设置可下载西海岸分院的技术资料空间，小明就可以访问西海岸分院的文件。
作为一个独立单位或部门，也可以设置可见组织，实现两个单位或部门之间的组织互通。组织互通后，就可以根据授权访问对方单位的文件。
1.4 用户组
用户组是一种在组织架构以外将多个不同部门或单位中的用户组织在一起的方式，以便更容易地管理他们的权限。每个组都有一个唯一的组ID和一组成员。用户可以属于一个或多个组。
如果我们有很多用户需要具有相同的权限，那么将他们添加到一个组会更简单，更容易管理。例如，如果我们有一个大型的项目团队，需要调配多个部门下的不同职责人员，我们可以创建一个“developers”组，然后一次 性地给这个组分配权限，而不是给每个项目参与者单独分配权限。
2. 角色
在企业中访问控制的范围取决于员工所扮演的角色，角色中包含已确认的访问职责和能力，悦库系统中的角色包括文件管理员、人事管理员等，每一种角色根据其包含的职责有不同的访问能力。
例如单位人事主管角色用于管理单位内部的人员，拥有对人员/部门的创建、编辑和删除等人事相关操作权限。
在组织中只有人员可以拥有角色，一个人员可以同时拥有多个角色：
2.1 角色级别
角色按权力级别分为：管理员角色、主管角色、普通角色。管理人员不能创建高于自身角色级别的新角色，当为其他人指派角色时，被指派角色行为集必须是当前管理者自身角色的行为集的子集，这样可以防止角色恶意提权问题。
由系统创建的默认角色，其中1、2级为管理角色，3级为普通角色：
1级管理员角色
1级管理员角色只能隶属于总部之下，按职责分为文件/人事管理员，管理员角色可以查看整个 组织。
文件管理员，可以管理系统中的所有文件，可以查看系统中的所有单位、部门和人员。
人事管理员，可以管理系统中所有下属单位以及下属单位中的部门和人员、管理本单位角色和公共角色，拥有人事管理最高权利，但只拥有人事权利，无管理文件权利。
2级主管角色
2级主管角色，管理的具体组织范围，根据指派角色时为其绑定的单位/部门而定。
文件主管，可以管理单位/部门中的所有文件，可以查看当前单位中的所有部门和人员。
人事主管，可以管理单位/部门中的所有部门和人员、管理角色，无管理文件权限。
运维主管，对系统进行运行管理维护，无其他管理权限。
3级普通角色
普通员工，可以在授权范围内对文件进行操作，默认仅可以访问本单位内组织，经过授权可以访问其它单位组织。
2.2 职责分离
职责分离是确保单个人员不具备完成恶意行为的所有必要权限的一种机制。
最常见的⽰例是：财务工作中的发起⽀付和授权⽀付操作，任何⼀个⼈员都不应该能够同时拥有这两种权限。
在文件管理领域中以FTP服务器为例：运维人员的职责是系统运行维护，却可以超出自身职责，直接查看FTP服务器上的所有企业文件(本应属于文件管理职责)，运维人员的职责不明确，将为企业文件增加泄露风险。
管理角色按职责分为职能管理和文件(业务)管理。人事管理和运维管理属于职能管理，人事管理角色只负责管理组织和人员，运维管理角色则只负责管理系统运维相关工作，职能管理角色不参与对文件访问权限的管理。文件管理角色专门负责组织内的文件(业务)管理，不参与组织的职能管理。
3. 访问安全
3.1 通用权限模型
以下介绍了四种常见的通用权限模型，通用权限模型是系统安全访问控制模块设计实现的理论依据。
自主访问控制， 简称 DAC (Discretionary Access Control)，通过根据主体的身份和所属组限制对对象的访问(UGO+RWX/ACL)。所谓的自主，是指拥有访问权限的主体可以将权限赋予其他主体。
强制访问控制，简称 MAC (Mandatory Access Control)，是一种根据自定义标签限制对对象的访问的方法。在SELinux中定义为类型、类别、层级三种标签。
基于角色的访问控制，简称 RBAC (Role-Based Access Control)，是一种基于角色并使用角色中预先定义的策略(Policy)对主体操作对象进行验证的访问控制方式。
基于属性的访问控制，简称ABAC(Attribute Based Access Control)，是一种根据主体属性、对象属性、环境条件，使用预先定义的策略(Policy)对操作对象进行验证的访问控制方式。
3.2 策略
策略(policy)是由管理员添加到系统中的安全规则，系统鉴权机制使用策略验证人员对资源操作行为合法性，由主体、资源、行为三个要素组成，主体是：单位/部门/人员，资源是：空间/文件夹/文件，行为是：查看/下载/上传/删除等。
策略按行为类型分为：允许策略和拒绝策略。允许策略用于表达允许谁对哪个资源拥有什么操作行为，拒绝策略用于表达拒绝谁对哪个资源拥有什么操作行为。拒绝策略优先级大于允许策略，即当设置主体对同一资源同时拥有允许和拒绝策略时，鉴权结果为以拒绝策略为准。
以主体的视角来看，策略是主体的访问权限，以资源视角来看策略是资源的访问规则。例如一条策略允许小明对test.txt拥有下载行为，以主体视角是表达小明拥有对test.txt下载的访问权限，是一条允许访问权限，以资源视角是表达test.txt拥有小明对其下载的访问规则，是一条允许访问规则。
主体
主体是指人员、部门、单位、总部、用户组等组织类型相关节点。
主体路径是指从组织根节点到当前主体的组织父节点所经过的所有节点的组合。
资源
资源主要是指空间、文件夹、文件。
资源路径是指从资源根节点到当前资源父节点所经过的所有节点的组合。
空间是文件的逻辑存储容器，类似于硬盘的分区，用于对文件进行逻辑分隔管理。考虑到组织安全访问的必要性，组织结构在此场景中也被定义为一种资源，例如用于限制人员查看其他子组织，实现组织隔离。
具有层级关系的资源称为结构化资源，空间、文件夹、组织结构都是结构化资源。
行为
行为包括文件行为和职能行为。
文件行为包含对文件的常见操作行为，例如：上传、下载、新建、查看、删除等。
职能行为是指分配给特定角色的访问行为，这些行为定义了角色成员可以在系统中访问和操作的资源。职能行为分为三类：空间管理、人事管理、运维管理，每一个分类对应一种角色职责，其下都包含多种行为。
行为组
行为组是指文件行为组，是将多个文件行为合成为一个组，用于便捷的分配文件访问权限。例如可以将下载、查看、列出三个文件行为合成名称为只读的行为组，这样后续为主体指定只读权限时就会方便很多。
由多个职能行为合成的组其实就是角色，用于定义主体的职责和能力。
3.3 访问权限
访问权限是指以主体为视角的策略，表达其对资源可执行的行为，可以在主体上进行查看和编辑。
访问权限由私有权限和继承权限组成，私有权限是直接作用于主体的策略，继承权限是根据继承路径逐层递推累加节点权限后得出所有策略，私有权限优先级大于继承权限。
继承
继承权限可以使主体获取其路径中的所有访问权限，而不需要重复添加，且主体自身可以追加新的私有权限。主体不继承特性则可以使主体屏蔽从路径中继承权限，然后自行定义访问权限，拥有更好的灵活度。
-
研发一部 的所有访问权限，递推计算过程为：
- 研发部权限 = 公司(所有权限) + 研发部(私有权限)
- 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)
- 小明 的所有访问权限，递推计算过程为：
- 研发部权限 = 公司(所有权限) + 研发部(私有权限)
- 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)
- 小明权限 = 研发一部(所有权限) + 小明(私有权限)
在一些特殊场景下，可能不希望继承父组织的访问权限，由子组织自行添加，可以实现更自主可控 的访问控制。
小明 是研发部的试用期员工，按公司规定不能访问研发部中的共享资料，需单独为其添加工作范围内的访问权限。
鉴权
鉴权是通过计算主体和其组织路径对目标资源和其资源路径的访问权限，得出主体对资源的最终访问权限的计算过程。该过程需要考虑主体的角色、继承权限、私有权限、允许/拒绝权限的优先级，目标资源的路径层级等因素。
举个例子，需要对小明下载文件word.zip的操作进行鉴权，过程是：
查看小明及其主体路径节点对word.zip及其资源路径的任意节点层级是否有下载权限。例如研发部对word.zip有下载权限，则小明也就拥有了对word.zip的下载权限，或者小明对应用软件有下载权限，则同时也就拥有了对word.zip的下载权限，计算过程是：
- 获取
公司对word.zip及其资源路径节点的私有权限。 - 获取
研发部对word.zip及其资源路径节点的私有权限，并累计公司的继承权限。 - 获取
研发一部对word.zip及其资源路径节点的私有权限，并累计研发部的继承权限。 - 获取
小明对word.zip及其资源路径节点的私有权限，并累计研发一部的继承权限，得出小明最终对word.zip的访问权限。
权限组
由用户自定义的一组拥有特定作用的一条或多条访问权限，可用于对单个主体批量添加访问权限。
例如：公司规定试用期员工不能访问本部门所有文件，但可以访问部分和试用期工作相关的文件，以下：
| 资源 | 行为/组 |
|---|---|
| /协同空间/技术资料/基础业务介绍 | 查看/下载 |
| /协同空间/技术资料/常用工具 | 查看/下载 |
| /协同空间/软件开发/编程语言/Python教程 | 查看/下载/分享 |
按照常规的赋权步骤，我们需要为试用期员工分别指定每条资源的访问权限，当试用期员工和访问资源都比较多时，显然这种方法费时费力，也很容易出错。
为了提高工作效率，我可以创建一个包含多条访问权限的试用期员工的权限组。当为试用期员工指定访问权限时，先将该员工设置不继承部门权限，然后直接为其添加'试用期员工的权限组，以此简化赋权操作。
3.4 访问规则
访问规则是指以资源为视角的策略，表达资源可以被主体执行的访问行为，可以在资源上进行查看和编辑。 访问规则和访问权限仅是主语视角不同，访问权限的主语是主体，而访问规则的主语是资源，但产生的作用是一致的，在系统内部实际都会被转换为以主体为主语的策略。
例如，管理员指定资源word.zip 的访问规则是：word.zip 可以被小明执行下载行为，则在系统内部转换后对应的策略是：允许小明对word.zip 执行下载行为，这时的主语为小明，鉴权机制以主体作为主语计算最终权限。
规则组
由文件管理者自定义的一组拥有特定作用的一条或多条访问规则，可用于对单个资源批量添加访问规则。
例如：一些分散的技术机密资源(在不同文件夹下)可以被小明、小刚等6人编辑，而小王、小高等10人仅可查看。
| 人员 | 行为/组 |
|---|---|
| 小明、小刚等6人 | 查看/编辑 |
| 小王、小高等10人 | 查看 |
按照常规的操作步骤，我们需要为资源分别指定每个人员的访问规则，当资源比较多时，显然这种重复操作费时费力，也很容易出错。
于是作为一名研发部文件主管，我可以创建一个包含多条访问规则的技术机密资源的规则组。当为这些技术机密资源对应的文件指定访问规则时，直接为其添加'技术机密资源的规则组即可，以此简化操作步骤。
3.5 策略关系
我们需要再次阐明策略的三要素：主体、资源、行为。记住这三要素对理解整个权限模型的内部关系非常重要。他们之间存在多种联系、组关系，下面进行整体介绍，便于大家有一个宏观的理解。
主体权限关系
主体包括单位、部门、人员、用户组，针对主体的权限管理可以通过设置权限组、权限、角色实现。权限由资源+行为/组 构成，而角色则定义了主体有限的职能行为能力，下图说明了主体权限的内部结构关系：
资源规则关系
资源包括空间、文件夹、文件，针对资源的访问规则管理可以通过设置规则组、规则实现。规则由主体(可能是单位、部门、人员、用户组)+行为/组 构成，下图说明了资源的内部结构关系：
3.6. ABAC
Attribute Based Access Control (基于属性的访问控制 )，简称ABAC, 是一种根据主体属性、对象属性、环境条件，使用预先定义的策略(Policy)对操作对象进行验证的访问控制方式。ABAC是对RBAC的改进，用于更细粒度更灵活的访问控制，NIST于2015年发表论文对ABAC标准进行了定义。
3.6.1 工作原理
下图展示了基于ABAC访问控制机制下，主体访问对象的工作原理：
- 主体请求访问对象。
- ABAC访问控制机制根据主体属性、对象属性、环境参数、操作、策略对该请求进行授权验证。
- 如果验证通过，则可以访问对象。
3.6.2 在现实世界的例子
”我作为一名爸爸，希望授权5岁的儿子，在电视上看1个小时的《超级飞侠》动画片。“
在这个例子中，“爸爸”相当于系统管理员，可以对动画片资源设定访问权限。
主体是“儿子”，主体的属性是：5岁（属年龄）。
对象是“文件“，对象的属性是：超级飞侠（属名称），动画片（属类型）。
环境属性是：电视(属设备)、1个小时（属时间范围）。
假如当前系统的策略定义格式为：allow {主体[属性]} {对象[属性]} {环境}{操作}，则对这个例子的策略定义为：
allow {'{'}儿子[年龄=5岁]{'}'} {'{'}文件[类型=动画片 and 名称=超级飞侠]{'}'} {'{'}环境[设备=电视 and 时间=10:00~11:00]{'}'} {'{'}操作[读]{'}'}
在满足以上条件后，在儿子观看《超级飞侠》时，ABAC访问控制机制就可以根据主体属性、对象属性、环境条件，使用爸爸预先定义的策略(Policy)对这次访问进行验证，如果验证结果通过，就可以观看。
3.6.3 ABAC其他场景
ABAC的应用场景非常广泛。
可以基于文件的大小、时间、标签、类型、内容关键字等实现基于文件属性的访问控制。
可以基于用户的登录IP、MAC地址、设备指纹等实现基于设备属性的访问控制。
还可以基于用户的角色、性别、年龄等实现基于用户属性的访问控制。
例如以下基于文件标签的访问控制实例：
在常见的文件系统中，我们只能使用文件夹对文件进行分类存放和访问。想一想，我们访问文件的时候是不是首先需要考虑文件放在哪个文件夹中？但同一个文件有时从不同维度看有不同的分类方式，比如在\ABC公司\XXX项目下名称为：XXX合同.docx的文件，在市场部门人员看是一个合同类别的文件，而在行政部人员看可能是一个机密类别的文件。
使用标签对文件进行类别定义，在后续的文件管理过程中有很大的便捷性：
-
可以根据标签快速定位文件位置。
-
根据标签设置文件的访问控制规则，参考上述例子，管理员可以设置：“小明可以查看/编辑标签是
合同的文件，小刚不能查看标签是机密的文件”。文件虽然只能存放在一个位置下，但通过设置文件标签实现了不同类别文件的访问控制。
6. 流程化
文件流程化是在现有工作流工具基础上结合文件管理系统提供的基础访问能力实现的可编排的业务流程。
文件流程化业务堆栈，以下：
以权限控制流程为例，在常见的文件权限控制方式下，通常只能设置人员对固定位置文件的访问权限，例如可设置权限：小明 可访问 “/公司/研发部资料“ 下的所有文件，这只是一条权限，在实际生产环境中，尤其是大型组织，情况要复杂的多，例如：
- 教师创建”数学作业” 文件夹，用于学生提交作业，截至时间为下午6点，过时则禁止学生上传/编辑，过时1小时前邮件提醒没有提交作业的学生。
- 拒绝角色为”实习生“的人员上传大于 1GB 的文件。
- 对于标签为"合同"的文件，自动设置”机密“标签(只能被授权"机密"人员访问)， ”研发部“人员只能查看，不能修改。
为此我们可以使用工作流方式实现上述流程，工作流中可能包含多个任务和权限，而权限不仅包括主体、资源、行为三个基本要素，还包括了人员/组织属性、文件属性、文件标签、角色、用户组、IP、请求时间等更丰富的表达 ，它们可以使用工作流进行自由搭配，灵活组合，实现更强大的安全访问控制能力。
以工作流方式实现上面 "教师收作业" 用户故事的简单流程：
7. 合规性
7.1 国际信息安全标准
早期最著名的安全标准是TCSEC，全称是 Trusted Computer System Evaluation Criteria (可信计算机系统评估标准)，是美国国防部在 20 多年的研究和开发中发展出来的⼀组安全标准，于1983年公布，最初只是军用标准，后来延伸至民用领域。最终被后续发布的信息技术安全评估通用标准（简称CC，现行版本3.1）取代，更准确的说法应该是整合。CC 是通过统一一些预先存在的标准而产生的，目的是保证计算机安全产品的规范、实施和评估过程是以严格、标准和可重复的方式进行的，发展历程如下：
由于CC是国际通用标准(ISO/IEC 15408)，不提供特定的安全要求和功能列表，但依然遵循TCSEC 采取的方法。TCSEC 中规定了两种类型的访问控制标准：⾃主访问控制 (DAC) 和强制访问控制 (MAC)。DAC 的要求被认为在技术上对商业和⺠⽤政府安全需求以及单级军事系统是正确的，而 MAC最初⽤于多级安全军事系统，目前这两种访问控制标准都已在Linux系统中实现。
等同于CC v2.3的中文版本 GB/T18336(信息技术安全评估准则) 标准于2005年开始实施，对于认证流程和实施方法，中国 GB/T18336 标准与CC标准模式基本类似，但是中国并不是CC互认成员单位。
7.2 中国等保系统
等保即网络安全等级保护测评，是对信息和信息载体按照重要性等级分级别进行保护的一种工作。信息安全等级保护要求不同安全等级的信息系统应用具有不同的安全保护能力。信息系统安全等级测评是验证信息系统是否满足相应安全保护等级的评估过程。网络安全等级保护已是网络运营者的刚需！金融、游戏、教育、医疗、互联网、政府、交通行业以及财税系统、经贸系统、电信系统、供水系统、国防建设系统等都需要做网络安全等级保护。
《GBT 25070-2019 信息安全技术网络安全等级保护安全设计技术要求》中对提供了对等保二级、等保三级的系统设计规范的描述，以下原文摘自 GBT 25070-2019标准。
7 第二级系统安全保护环境设计
7.1 设计目标
第二级系统安全保护环境的设计目标是:按照GB17859-1999对第二级系统的安全保护要求，在第一级系统安全保护环境的基础上，增加系统安全审计，客体重用等安全功能，并实施以用户为基本粒度的自主访问控制，使系统具有更强的自主安全保护能力，并保障基础计算资源和应用程序可信。
7.2 设计策略
第二级系统安全保护环境的设计策略是:遵循GB17859-1999的4.2中相关要求，以身份鉴别为基础，提供单个用户和(或)用户组对共享文件、数据库表等的自主访问控制;以包过滤手段提供区域边界保护;以数据校验和恶意代码防范等手段，同时通过增加系统安全审计、客体安全重用等功能，使用户对自己的行为负责，提供用户数据保密性和完整性保护，以增强系统的安全保护能力。第二级系统安全保护环境在使用密码技术设计时，应支持国家密码管理主管部门批准使用的密码算法，使用国家密码管理主管部门认证核准的密码产品，遵循相关密码国家标准和行业标准。第二级系统安全保护环境的设计通过第二 级的安全计算环境、安全区域边界、安全通信网络以及安全管理中心的设计加以实现。计算节点都应基于可信根实现开机到操作系统启动，再到应用程序启动的可信验证，并将验证结果形成审计记录。
7.3 设计技术要求
7.3.1 安全计算环境设计技术要求
7.3.1.1 通用安全计算环境设计技术要求
本项要求包括:
a) 用户身份鉴别
应支持用户标识和用户鉴别。在每一个用户注册到系统时，采用用户名和用户标识符标识用户身份，并确保在系统整个生存周期用户标识的唯一性;在每次用户登录系统时，采用受控的口令或具有相应安全强度的其他机制进行用户身份鉴别，并使用密码技术对鉴别数据进行保密性和完整性保护。
b) 自主访问控制
应在安全策略控制范围内，使用户对其创建的客体具有相应的访问操作权限，并能将这些权限的部分或全部授予其他用户。访问控制主体的粒度为用户级，客体的粒度为文件或数据库表级。访问操作包括对客体的创建、读、写、修改和删除等。
C) 系统安全审计
应提供安全审计机制，记录系统的相关安全事件。审计记录包括安全事件的主体、客体、时间类型和结果等内容。该机制应提供审计记录查询、分类和存储保护，并可由安全管理中心管理。
d) 用户数据完整性保护
可采用常规校验机制，检验存储的用户数据的完整性，以发现其完整性是否被破坏
e) 用户数据保密性保护
可采用密码等技术支持的保密性保护机制，对在安全计算环境中存储和处理的用户数据进行保密性保护。
f) 客体安全重用
应采用具有安全客体复用功能的系统软件或具有相应功能的信息技术产品，对用户使用的客体 资源，在这些客体资源重新分配前，对其原使用者的信息进行清除，以确保信息不被泄露。
g) 恶意代码防范
应安装防恶意代码软件或配置具有相应安全功能的操作系统，并定期进行升级和更新，以防范和清除恶意代码。
h) 可信验证
可基于可信根对计算节点的BIOS、引导程序，操作系统内核，应用程序等进行可信验证，并在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录。
8 第三级系统安全保护环境设计
8.1 设计目标
第三级系统安全保护环境的设计目标是:按照GB17859-1999对第三级系统的安全保护要求，在第二级系统安全保护环境的基础上，通过实现基于安全策略模型和标记的强制访问控制以及增强系统的审计机制，使系统具有在统一安全策略管控下，保护感资源的能力，并保障基础计算资源和应用程序可信，确保关键执行环节可信。
8.2 设计策略
第三级系统安全保护环境的设计策略是:在第二级系统安全保护环境的基础上，遵循GB17859-1999的4.3中相关要求，构造非形式化的安全策略模型，对主、客体进行安全标记，表明主、客体的级别分类和非级别分类的组合，以此为基础，按照强制访问控制规则实现对主体及其客体的访问控制。第三级系统安全保护环境在使用密码技术设计时，应支持国家密码管理主管部门批准使用的密码算法，使用国家密码管理主管部门认证核准的密码产品，遵循相关密码国家标准和行业标准。
第三级系统安全保护环境的设计通过第三级的安全计算环境、安全区域边界安全通信网络以及安全管理中心的设计加以实现，计算节点都应基于可信根实现开机到操作系统启动，再到应用程序启动的可信验证，并在应用程序的关键执行环节对其执行环境进行可信验证，主动抵御病毒入侵行为，并将验证结果形成审计记录，送至管理中心。
8.3 设计技术要求
8.3.1 安全计算环境设计技术要求
8.3.1.1 通用安全计算环境设计技术要求
本项要求包括:
a) 用户身份鉴别
应支持用户标识和用户鉴别。在对每一个用户注册到系统时，采用用户名和用户标识符标识用户身份，并确保在系统整个生存周期用户标识的唯一性;在每次用户登录系统时，采用受安全管理中心控制的口令、令牌、基于生物特征、数字证书以及其他具有相应安全强度的两种或两种以上的组合机制进行用户身份鉴别，并对鉴别数据进行保密性和完整性保护。
b) 自主访问控制
应在安全策略控制范围内，使用户对其创建的客体具有相应的访问操作权限，并能将这些权限的部分或全部授予其他用户。自主访问控制主体的粒度为用户级，客体的粒度为文件或数据库表级和(或)记录或字段级。自主访问操作包括对客体的创建、读、写、修改和删除等。
c) 标记和强制访问控制
在对安全管理员进行身 份鉴别和权限控制的基础上，应由安全管理员通过特定操作界面对主、客体进行安全标记;应按安全标记和强制访问控制规则，对确定主体访问客体的操作进行控制。强制访问控制主体的粒度为用户级，客体的粒度为文件或数据库表级。应确保安全计算环境内的所有主、客体具有一致的标记信息，并实施相同的强制访问控制规则。
d) 系统安全审计
应记录系统的相关安全事件。审计记录包括安全事件的主体、客体、时间、类型和结果等内容应提供审计记录查询、分类、分析和存储保护;确保对特定安全事件进行报警;确保审计记录不被破坏或非授权访问。应为安全管理中心提供接口;对不能由系统独立处理的安全事件，提供由授权主体调用的接口。
e) 用户数据完整性保护
应采用率码等技术支持的完整性校验机制，检验存储和处理的用户数据的完整性，以发现其完整性是否被破坏，且在其受到破坏时能对重要数据进行恢复。
f) 用户数据保密性保护
应采用密码等技术支持的保密性保护机制，对在安全计算环境中存储和处理的用户数据进行保密性保护。
g) 客体安全重用
应采用具有安全客体复用功能的系统软件或具有相应功能的信息技术产品，对用户使用的客体资源，在这些客体资源重新分配前，对其原使用者的信息进行清除，以确保信息不被泄露。
h) 可信验证
可基于可信根对计算节点的BIOS、引导程序、操作系统内核、应用程序等进行可信验证，并在应用程序的关键执行环节对系统调用的主体、客体、操作可信验证，并对中断、关键内存区域等执行资源进行可信验证，并在检测到其可信性受到破坏时采取措施恢 复，并将验证结果形成审计记录，送至管理中心。
j) 配置可信检查
应将系统的安全配置信息形成基准库，实时监控或定期检查配置信息的修改行为，及时修复和基准库中内容不符的配置信息。
j) 入侵检测和恶意代码防范
应通过主动免疫可信计算检验机制及时识别入侵和病毒行为，并将其有效阻断。
参考链接
GBT 25070-2019 信息安全技术网络安全等级保护安全设计技术要求