大型组织文件管理的研究V3

大型组织机构通常由多个相对独立的下属组织单位组成，每个下属单位都有自己的职责和目标，本文探讨如何实现对大型组织机构的文件管理。

1. 组织

组织由总部、单位、部门、人员四个组织层级组成：

总部是一个组织的最顶级单位，例如集团名称、大学名称等，系统中有且只有一个总部。总部下包含多个层级的单位，而单位中也包含多个部门，形成一个树形组织结构。总部本身也是一个特殊的单位，遵守单位相关规则。

单位，是一种隶属于总部的组织逻辑类型，通常用于建立一个相对独立的人员管理逻辑范围，具有独立的组织结构和文件访问安全边界。例如集团子公司、大学学院、集团医院分院等。单位中可以包含多个子单位或部门，可以在总部或其他单位之下，但不能在部门下。

部门 是一个独立组织下的分支机构。可以直接隶属于总部，或某一个单位，可以在总部、单位、其他部门之下。

人员是隶属于组织中的个人，人员可以直接隶属于总部，也可以同时隶属于多个部门或单位中。

简化的树形组织结构示例：

1.1 组织关系

总部关系

1. 总部下可以有0或多个单位，单位有且只有1个总部。
2. 总部下可以有0或多个部门，部门有且只有1个总部。
3. 总部下可以有0或多个人员，人员必须隶属于1个总部。

单位关系

1. 单位可以有0或多个子单位，子单位1个或多个上级单位。
2. 单位可以有0或多个部门，部门有1个或多个上级单位。
3. 单位可以有0或多个人员，人员可以隶属于1个或多个上级单位。

部门关系

1. 部门可以有0或多个子部门，子部门有1个或多个上级部门。
2. 部门可以有0或多个人员，人员可以隶属于1个或多个上级部门。

人员关系

1. 人员可以直接隶属于总部/单位/部门之下。
2. 人员必须隶属于1个总部，但可以同时隶属于多个单位或部门之下。

1.2 组织隔离

单位 是一个相对独立的组织，拥有单位范围的安全边界。各单位之间在组织访问、文件访问、角色设置等操作中相互隔离，默认不能互通。

例如在集团医院中，如果将市北分院和崂山分院定义为单位，则默认市北分院的人员无法访问崂山分院的文件，同时也看不到崂山分院的组织结构。市北分院中创建和设置的自定义角色在崂山分院中不可见。

1.3 组织协作

在相互隔离的单位之间建立协作关系，是企业中常见的应用场景。

单个人员可以通过设置和授权方式实现对其他单位的组织或文件的访问。

例如：

1. 通过将市北分院的用户小明，设置可见西海岸分院，小明就可以访问西海岸分院的组织结构。
2. 通过将市北分院的用户小明，设置可下载西海岸分院的 技术资料空间，小明就可以访问西海岸分院的文件。

作为一个独立单位或部门，也可以设置可见组织，实现两个单位或部门之间的组织互通。组织互通后，就可以根据授权访问对方单位的文件。

2. 角色

在企业中访问控制的范围取决于员工所扮演的角色，角色中包含已确认的访问权限和职责，悦库系统中的角色包括文件管理员、人事管理员等，每一种角色根据其包含的职责有不同的访问权限。

例如单位人事主管角色用于管理单位内部的人员，拥有对人员/部门的创建、编辑和删除等人事相关操作权限。

在组织中只有人员可以拥有角色，一个人员可以同时拥有多个角色：

2.1 角色级别

角色按权力级别分为：管理员角色、主管角色、普通角色。管理人员不能创建高于自身角色级别的新角色，当为其他人指派角色时，被指派角色行为集必须是当前管理者自身角色的行为集的子集，这样可以防止角色恶意提权问题。

由系统创建的默认角色，其中1、2级为管理角色，3级为普通角色：

1级管理员角色

1级管理员角色只能隶属于总部之下，按职责分为文件/人事管理员，管理员角色可以查看整个组织。

文件管理员，可以管理系统中的所有文件，可以查看系统中的所有单位、部门和人员。

人事管理员，可以管理系统中所有下属单位以及下属单位中的部门和人员、管理本单位角色和公共角色，拥有人事管理最高权利，但只拥有人事权利，无管理文件权利。

2级主管角色

2级主管角色，管理的具体组织范围，根据指派角色时为其绑定的单位/部门而定。

文件主管，可以管理单位/部门中的所有文件，可以查看当前单位中的所有部门和人员。

人事主管，可以管理单位/部门中的所有部门和人员、管理角色，无管理文件权限。

运维主管，对系统进行运行管理维护，无其他管理权限。

3级普通角色

普通员工，可以在授权范围内对文件进行操作，默认仅可以访问本单位内组织，经过授权可以访问其它单位组织。

2.2 职责分离

职责分离是确保单个人员不具备完成恶意行为的所有必要权限的一种机制。

最常见的⽰例是：财务工作中的发起⽀付和授权⽀付操作，任何⼀个⼈员都不应该能够同时拥有这两种权限。

在文件管理领域中以FTP服务器为例：运维人员的职责是系统运行维护，却可以超出自身职责，直接查看FTP服务器上的所有企业文件(本应属于文件管理职责)，运维人员的职责不明确，将为企业文件增加泄露风险。

管理角色按职责分为职能管理和文件(业务)管理。人事管理和运维管理属于职能管理，人事管理角色只负责管理组织和人员，运维管理角色则只负责管理系统运维相关工作，职能管理角色不参与对文件访问权限的管理。文件管理角色专门负责组织内的文件(业务)管理，不参与组织的职能管理。

3. 资源

3.1 概念

资源主要是指空间、文件夹、文件。

空间是指文件的逻辑存储容器，类似于硬盘的分区，用于对文件进行逻辑分隔管理。考虑到组织安全访问的必要性，组织结构在此场景中也被定义为一种资源，例如用于限制人员查看其他子组织，实现组织隔离。

具有层级关系的资源称为结构化资源，空间、文件夹、组织结构都是结构化资源。

4. 访问安全

4.1 策略

策略(policy)是鉴权机制用于验证人员对资源操作行为合法性的基本依据，由主体、资源、行为三个要素组成，主体是：单位/部门/人员，资源是：空间/文件夹/文件，访问行为是：查看/下载/上传/删除等。

主体路径是指从组织根节点到当前主体的组织父节点所经过的所有节点的组合。资源路径是指从资源根节点到当前资源父节点所经过的所有节点的组合。

策略按行为类型分为：允许策略和拒绝策略。允许策略用于表达允许谁对哪个资源拥有什么操作行为，拒绝策略用于表达拒绝谁对哪个资源拥有什么操作行为。拒绝策略优先级大于允许策略，即当设置主体对同一资源同时拥有允许和拒绝策略时，鉴权结果为以拒绝策略为准。

以主体的视角来看，策略是主体的访问权限，以资源视角来看策略是资源的访问规则。例如一条策略允许小明对test.txt拥有下载行为，以主体视角是表达小明拥有对test.txt下载的访问权限，是一条允许访问权限，以资源视角是表达test.txt拥有小明对其下载的访问规则，是一条允许访问规则。

4.2 访问权限

访问权限是指以主体为视角的策略，表达其对资源可执行的行为，可以在主体上进行查看和编辑。

访问权限由私有权限和继承权限组成，私有权限是直接作用于主体的策略，继承权限是根据继承路径逐层递推累加节点权限后得出所有策略，私有权限优先级大于继承权限。

继承

继承权限可以使主体获取其路径中的所有访问权限，而不需要重复添加，且主体自身可以追加新的私有权限。主体不继承特性则可以使主体屏蔽从路径中继承权限，然后自行定义访问权限，拥有更好的灵活度。

1. 研发一部 的所有访问权限，递推计算过程为：

   • 研发部权限 = 公司(所有权限) + 研发部(私有权限)
   • 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)

2. 小明 的所有访问权限，递推计算过程为：
   • 研发部权限 = 公司(所有权限) + 研发部(私有权限)
   • 研发一部权限 = 研发部(所有权限) + 研发一部(私有权限)
   • 小明权限 = 研发一部(所有权限) + 小明(私有权限)

在一些特殊场景下，可能不希望继承父组织的访问权限，由子组织自行添加，可以实现更自主可控的访问控制。

小明 是研发部的试用期员工，按公司规定不能访问研发部中的共享资料，需单独为其添加工作范围内的访问权限。

鉴权

鉴权是通过计算主体和其组织路径对目标资源和其资源路径的访问权限，得出主体对资源的最终访问权限的计算过程。该过程需要考虑主体的角色、继承权限、私有权限、允许/拒绝权限的优先级，目标资源的路径层级等因素。

举个例子，需要对小明下载文件word.zip的操作进行鉴权，过程是：

查看小明及其主体路径节点对word.zip及其资源路径的任意节点层级是否有下载权限。例如研发部对word.zip有下载权限，则小明也就拥有了对word.zip的下载权限，或者小明对应用软件有下载权限，则同时也就拥有了对word.zip的下载权限，计算过程是：

1. 获取公司对word.zip及其资源路径节点的私有权限。
2. 获取研发部对word.zip及其资源路径节点的私有权限，并累计公司的继承权限。
3. 获取研发一部对word.zip及其资源路径节点的私有权限，并累计研发部的继承权限。
4. 获取小明对word.zip及其资源路径节点的私有权限，并累计研发一部的继承权限，得出小明最终对word.zip的访问权限。

权限组

由用户自定义的一组拥有特定作用的一条或多条访问权限，可用于对单个主体批量添加访问权限。

例如：公司规定试用期员工不能访问本部门所有文件，但可以访问部分和试用期工作相关的文件，以下：

资源	行为
/协同空间/技术资料/基础业务介绍	查看/下载
/协同空间/技术资料/常用工具	查看/下载
/协同空间/软件开发/编程语言/Python教程	查看/下载/分享

按照常规的赋权步骤，我们需要为试用期员工分别指定每条资源的访问权限，当试用期员工和访问资源都比较多时，显然这种方法费时费力，也很容易出错。

为了提高工作效率，我可以创建一个包含多条访问权限的试用期员工的权限组。当为试用期员工指定访问权限时，先将该员工设置不继承部门权限，然后直接为其添加'试用期员工的权限组，以此简化赋权操作。

4.3 访问规则

访问规则是指以资源为视角的策略，表达资源可以被主体执行的访问行为，可以在资源上进行查看和编辑。 访问规则和访问权限仅是主语视角不同，访问权限的主语是主体，而访问规则的主语是资源，但产生的作用是一致的，在系统内部实际都会被转换为以主体为主语的策略。

例如，管理员指定资源word.zip的访问规则是：word.zip 可以被小明执行下载行为，则在系统内部转换后对应的策略是：允许小明对word.zip 执行下载行为，这时的主语为小明，鉴权机制以主体作为主语计算最终权限。

规则组

由用户自定义的一组拥有特定作用的一条或多条访问规则，可用于对单个资源批量添加访问规则。

例如：一些分散的技术机密资源(在不同文件夹下)可以被小明、小刚等6人编辑，而小王、小高等10人仅可查看。

人员	行为
小明、小刚等6人	查看/编辑
小王、小高等10人	查看

按照常规的操作步骤，我们需要为资源分别指定每个人员的访问规则，当资源比较多时，显然这种重复操作费时费力，也很容易出错。

于是作为一名研发部文件主管，我可以创建一个包含多条访问规则的技术机密资源的规则组。当为技术机密资源指定访问规则时，直接为其添加'技术机密资源的规则组，以此简化操作步骤。

附录

用户故事

组织

1. 小明在A单位中，小刚在B单位中，他们相互之间不能看到对方的组织结构，且只能看到自己所在单位的组织结构。

2. 设置A单位的小明可以查看B单位的组织结构。

3. 设置A单位的所有人可以查看B单位的组织结构。

4. 设置A单位拥有B单位指定空间的文件夹的下载权限。

5. 设置A单位的研发部对B单位的测试部下所有文件有下载权限。

6. 小明属于A单位的研发部，同时也属于B单位的测试部，设置小明在A单位中担任研发部文件管理员，在B单位为普通员工。

7. 小明属于A单位的研发部，设置小明不继承上级部门权限。

8. 设置A单位的财务部门的直属员工对市场部"销售数据空间"的"每月报表文件夹"有下载权限。设置A单位的财务部门的所有员工对市场部"销售数据空间"的"每月报表文件夹1"有下载权限。？

9. 设置A单位的所有人可以查看B单位的组织结构，但试用期员工除外。

10. 设置A单位的所有人可以查看B单位的组织结构，但研发部除外。

11. 设置A单位的所有人可以查看B单位的组织结构，有效期1个月。

角色

1. 小明作为一名单位文件主管，希望将其单位下的研发部中的小刚指派为部门文件主管。
2. 小明作为一名单位文件主管，希望查看其单位中各个部门的文件。
3. 小明作为一名单位文件主管，希望自定义一个部门文件主管角色。
4. 小明作为一名单位文件主管，希望删除过去创建的自定义角色。

资源

1. 我作为一名单位文件主管，在高级财务和普通财务人员都有对"财务资料/年度报表"文件夹有访问权限的前提下，希望将 "财务资料/年度报表/董事会财报" 文件夹单独设置高级财务人员有访问权限，单位下普通财务人员不可见。

访问安全

1. 设置小明对”技术资料“空间下的”python“文件夹有下载权限，且只能下载该文件夹的直接子文件(资源不递归)。？
2. 设置小刚对”技术资料“空间下的”python“文件夹有下载权限(资源递归)。？
3. 设置研发部所有人员(主体递归)对”技术资料“空间下的”python“文件夹有下载权限。
4. 设置测试部直接人员(主体不递归)对”技术资料“空间下的”python“文件夹有下载权限。
5. 使用权限组方式设置多名试用期员工不能访问本部门所有文件，仅可下载分散的(不在同一文件夹)试用期员工培训资料。
6. 使用规则组方式设置一些分散的技术机密资源(在不同文件夹下)可以被小明、小刚等6人编辑，而小王、小高等10人仅可查看。

常见的大型组织形式

大学

集团公司

集团医院