Data Authority Managementa
data_authority_managementa
独立的数据权限控制
访问限制、
某些数据不允许访问
数据清洗、
某些数据部分返回
业务场景和数据安全级别划分（绝密、高保密、保密、可公开，四个级别）， 主要从“高保密”等级的敏感数据，开始进行梳理。
这里我们把敏感数据分成四个维度进行梳理，用户、商家、终端、公司。（用户、业务、公司。）（基础数据标签、业务数据标签）
应用动态数据屏蔽有五种可能的技术：
1、在数据库中：数据库接收SQL并将重写应用于返回的屏蔽结果集。适用于开发人员和DBA，但不适用于应用程序（因为连接池，应用
程序缓存和数据总线会隐藏数据库中的应用程序用户身份，并且还会导致应用程序数据损坏）。
2、应用程序和数据库之间的网络代理：捕获SQL并在select请求上应用重写。适用于具有简单'select'requests但不适用于存储过程（
代理仅识别exec。）和应用程序的开发人员和DBA（因为连接池，应用程序缓存和数据总线隐藏了数据库中的应用程序用户身份，也可以
导致应用程序数据损坏）。
3、最终用户和应用程序之间的网络代理：识别文本字符串并替换它们。此方法不适用于复杂的应用程序，因为当无意中应用实时字符串替
换时，它很容易导致损坏。
4、应用程序和XACML中的代码更改：代码更改难以执行，无法维护且不适用于打包的应用程序。
5、在应用程序运行时：通过检测应用程序运行时，定义策略以重写从数据源返回的结果集，同时具有对应用程序用户的完全可见性。此方法
是动态屏蔽复杂应用程序的唯一适用方法，因为它可以控制数据请求，数据结果和用户结果。
=================================================wota5037的博客================================ 基于资源的权限系统-设计思路 基于资源的权限系统-数据库设计
基于资源的权限系统-设计思路 概述 权限系统提的最多的就是 RBAC（基于角色的访问控制）。 所谓角色，其实就是权限的集合，某个角色就是某几个权限的结合。其目的是为了简化授权和鉴权的过程。
基于角色的权限控制用在简单的权限环境下没有问题，如果在权限控制比较复杂的系统中，或者说要做通用的权限系统时，基于角色的权限控制会带来以下问题：
1、角色可以用来做功能权限，做数据权限的话，会导致角色数量非常多 比如：bug管理系统，一般有 developer, reporter, manager 等一些角色，其中，reporter
可以创建bug，developer 可以解决，回复bug，manager 可以统计bug 等等。 在这个系统中，通过设置 developer，reporter，manager 几个角色，可以使得授权，
鉴权更加简单，直观。 但是，如果权限粒度要求更细的话，比如，某些reporter只能创建普通级别的bug，某些reporter可以创建各个级别的bug，或者有更加细粒
度的权限要求的话，角色的数量就会激增。 到时候，管理角色本身带来的工作量反而会大于角色带来的好处。
2、角色是一维的，不同的角色之间一般都是独立的，而人员之间一般有树状的组织关系。所以，角色就很难与已有的组织关系互相映射。 而授权的时候，经常
是上级的组织会自动获取下级创建的数据的一些权限
3、对于不确定的系统来说，角色不好定义。如果是bug系统，比较成熟，方便定义角色类型，如果是通用系统的话，用户其实不太容易定义好自己需要的角色。
另一种 RBAC（resource base access control）
基于资源的权限系统。
术语介绍
人员 : 实际使用系统的用户，也就是需要进行权限检查的人
组织 : 树形结构，但是人员可以属于一个或者多个组织
资源 : 需要授权的东西都可以认为是资源，每个功能是资源，每个接口也是资源，每条数据也是资源。 资源树 上的根就是整个系统。
动作 : 对资源的操作，比如常用的 创建，删除，更新，查询
权限 : 组织 + 资源 + 动作 （什么人对什么资源可以做什么动作）
系统初始化
权限系统本身提供一个超级用户(admin)，通过此用户来初始化最初需要的信息。
初始信息只需要定义：
组织的根节点：以后追加的所有人员和组织都在此节点之下（比如就是某个公司）
资源的根节点：以后追加的所有资源都在此节点之下（比如就是需要进行权限控制的系统）
动作：对资源可能进行的操作（一般就是CURD，增删改查）
有了以上信息，就完成了针对某个系统和组织的权限系统的基本初始化。 基本信息初始化之后，可以导入组织/人员，以及资源信息，或者直接在权限系统提供的页面上操作。
注意 每个资源只有一个父节点，每个组织也只有一个父组织，但是每个人员可以属于多个组织
授权过程
授权是权限系统中重要的步骤之一，另一个重要步骤就是鉴权。 授权有2种视图：
人员/组织 视图 下的授权流程
选择 资源
选择 动作
确认授权
生成权限数据
注1 前2步的选择都可以多选。
资源 视图 下的授权流程
选择 人员/组织
选择 动作
确认授权
生成权限数据
鉴权过程
鉴权是使用最频繁的步骤，几乎每次请求都会有鉴权的操作。 鉴权就是判断 某人对某资源做某个动作 是否合法，所以鉴权的 input 是 人员/组织，资源，动作； output 则是是否鉴权成功。
根据 input 的内容（人员/组织，资源，动作），查看权限表中是否有匹配的数据
1.1 有匹配的数据，返回鉴权成功
1.2 没有匹配的数据，查找 人员/组织 所属的父组织，再次用 （父组织，资源，动作）作为 input，查看权限表中是否有匹配的数据
1.2.1 有匹配的数据，返回鉴权成功
1.2.2 没有匹配的数据
1.2.2.1 当前组织已经是 根组织，返回鉴权失败
1.2.2.2 当前组织不是 根组织，进入步骤 1.2
自动授权规则
对功能权限来说，一般数据量不会太大，即使没有自动授权，手动授权也可以完成。 但是对数据权限来说，不仅数据量庞大，而且如何授权也不确定，数据的变化也可能会很频繁，手动来做几乎不可能。
自动授权目的是将自动授权机制参数化，让用户通过设置不同的参数来生成不同的权限数据。 自动授权机制是以插件的形式加入到权限系统中的，默认可以提供几种常用的自动授权机制插件。 在授权时，也可以指定使用一种或者多种自动授权插件。
下面以一个示例来说明插件是如何使用的。 示例插件：创建数据时自动授权插件 功能：用户A 创建数据X 后，生成如下权限数据：
用户A 可以 修改 查询 删除 数据X
用户A 所属组织的成员可以 查询 修改 数据X
其他组织的成员可以 查询 数据X
此插件参数就是3个list：自己的动作列表，同组织成员的动作列表，其他组织人员的动作列表 插件的参数是在权限系统中的插件管理功能中配置的（插件参数的设置需要用到动态表单，因为插件的参数个数，类型等都是不定的）
使用流程如下：
某用户创建了一条数据
创建完数据后，调用权限系统的授权接口，在授权接口中指定使用上面的 示例插件
权限系统的授权接口会调用上面的 示例插件 给用户，用户所属组织以及其他组织 分别授予相应的权限
针对不同类型的系统，授权方式千差万别，将授权的实现剥离出来，是为了增加系统的通用性。
总结
通用权限管理的主要的功能就是 授权 和 鉴权 ，其本质都是对权限数据（什么人对什么资源可以做什么动作）的管理。 授权的难点在于给某人授与某个数据的权限之后，组织中其他关联人员
可以计算出自己对这个数据的权限，这就是自动授权插件的意义。 鉴权的难点一是权限的数据量会比较大（如果权限粒度细的话），一是有些权限是需要计算的。
基于角色的权限系统的核心在 角色（人员），而基于资源的权限系统核心在 资源，资源是权限系统需要保护的东西。 希望能从资源的角度来设计出更加通用的权限管理系统。
对于不确定的系统来说，角色不好定义。如果是bug系统，比较成熟，方便定义角色类型，如果是通用系统的话，用户其实不太容易定义好自己需要的角色。
基于资源的权限系统-数据库设计
通用权限管理设计 之 数据权限
权限控制可以理解，分为这几种 ： 【功能权限】：能做什么的问题，如增加产品。 【数据权限】：能看到哪些数据的问题，如查看本人的所有订单。 【字段权限】：能看到哪些信息的问题，如供应商账户，看不到角色、 部门等信息。
几个概念 【资源】：数据权限的控制对象，业务系统中的各种资源。比如订单单据、销售单等。属于上面提到的【领域】中的一种 【主体】：用户、部门、角色等。 【条件规则】：用于检索数据的条件定义 【数据规则】：用于【数据权限】的条件规则
【资源】 - 【主体】 - 【数据规则】
这个方案至少需要2张表，一个是 【资源，主体，规则关系表】、一个是【数据规则表】
=================================================wota5037的博客================================ tableName：字段等级表字段等级表 记录被控制表中的权限等级
需求：
基于表名、字段进行
1）、清洗条目
2）、字段脱敏
用户 维度
角色/标签 维度
需求：
不控制（公开）：
所有人可看
控制：
1、部分人完全可看：
2、部分人部分可看：
1、不给某个 用户 返回 某表 的某些 条目
2、不给某个 用户 返回 某表 的某些 字段 的部分内容
3、不给某个 角色/标签 返回某表的某些条目
4、不给某个 角色/标签 返回某表的某些字段的部分内容
5、显示无权限访问数据，全部用“*”代替
3、部分人不可看（指定人不可看）：