KAP v2.5 新特性：多层级细粒度权限管控

管理敏感数据的访问控制是所有企业数据安全的重要组成部分。在一些场景下，企业需要对数据进行细粒度的访问控制。例如，在银行的数据系统中，各支行只允许访问本支行的数据。又比如在医疗数据系统中，为了保护病人的隐私，医生只允许查看和自己的病人相关的信息。类似的场景也广泛的存在于律法，政府及军事等信息系统中。对消费者、病人、公民个人隐私的保护驱动了信息系统中细粒度的权限控制。

在没有细粒度权限管控功能的场景下，为了保证不同权限或不同部门的用户访问相同数据时的权限差异，管理员通常会采取为不同访问权限的用户创建多表或多个视图的解决方案，这种方案会增加数据维护的成本，也无法保证数据完整性。为了迎合企业对于细粒度数据管控的广泛需要，KAP 在新版本 2.5 中推出了表级、行级、列级三级数据访问权限控制，实现了项目级、表级、行列级多层级权限管控，满足企业在不同场景下对于数据权限管控的需要，使得不同的访问权限的用户可以使用统一的数据源及 KAP 语义层来进行查询。下面我们将就 KAP 多层级权限控制及其使用方法做详细介绍。

图 1

项目级权限

用户在 KAP 中能否访问一个项目并使用项目中的一些功能是由项目级别访问权限决定的。KAP 内置四种项目访问权限角色， 每个角色定义了一系列在 KAP 中有权限访问的功能。管理员在项目上为用户分配了访问权限后，用户会相应地继承数据源、模型及 Cube 上的访问权限。

项目级权限是实现 KAP 多租户场景的基础，每个项目分别赋权，用户访权限各自独立，每个项目用户可以独立导入数据源、创建模型、创建 Cube、运行 Cube、查询 Cube。这是很多企业多部门访问时所必须的需求。

图 2

表级权限

表级访问权限控制了用户在 KAP 中能查询的表。通常表级访问权限会配置在维度表上，场景通常是某个维度表包含了一些较为隐私的信息，如银行开户人的姓名、电话、身份证号等，在银行的信息系统中这些隐私信息需要较高的访问权限才能查看，因此需要对一般用户限制对用户信息表的数据访问。

图 3

行级访问权限

行级访问权限过滤了用户在表上可访问的行。行级访问权限通常都被用在限制非常敏感的数据。比如在一个公司中，销售大区经理仅能查看到属于他／她大区的销售数据，但看不到其他大区的销售数据。比如你希望给东北大区的销售经理设置行级权限这样他仅能看到地区=‘东北’的销售数据。

不论用户的查询使用 Cube、明细表索引还是查询下压查询都会受到行级权限的过滤。

图 4

行级权限会转换成查询中的 Where 语句附加在用户的查询后。如果对同一个列过滤多个值，每个值之间的逻辑运算符为“或”（OR）。 当为同一个用户设置多列的过滤的值时，不同列之间的逻辑运算符为“与” (AND)。

列级访问权限

列级访问权限限制了用户在表上不能访问的列。一个典型的需要限制列级访问权限的场景为，一张包含员工信息的维度表，大部分信息如姓名、性别、联系电话、职位等是公开可供所有员工查看的，而像工资这样的敏感信息是只有人事部门可以访问，因此需要对一般用户的对该工资列的访问进行限制。

如果用户在某列的访问权限被限制了，用户不可以查询这个列，不管是通过 Cube，明细表索引还是查询下压。列级权限需要以项目为单位进行设置。也就是说如果同一个表在不同的项目中都导入了，两个项目下的列级权限需要分别设置。

图 5

不论是表级、行级还是列级权限都是以项目为单位进行设置。也就是说如果同一个表在不同项目中都导入了，两个项目下的这些权限需要分别设置。这样配合上项目级权限，KAP 就实现了项目间完全的访问隔离。

总结

KAP2.5 为企业级用户提供了更强大的多层级权限管控，使得用户从粗粒度到细粒度的访问权限都可以得到差异化的管控。表级权限控制，方便用户对源表的访问权限进行差异化的配置。作为企业级的多用户数据库，同时使用项目级和表级权限管控满足了同一系统下的多个子公司、职能部门、业务群体的统一而灵活的权限需求。在表级权限下，支持细粒度的行列级权限管控，将权限配置细化到单元格级别，满足了企业用户对业务数据，客户个人信息等进行隔离的需求。

参考文献

欲了解更多关于 KAP2.5 版本多层级权限控制的详情，欢迎参阅 KAP 用户手册的以下相关章节。

1. 项目级权限
2. 表级权限
3. 行级权限
4. 列级权限