CDH大数据权限管理
CDH大数据之Sentry权限管理
cdh版本的hadoop在对数据安全上的处理通常采用Kerberos+Sentry的结构。
kerberos主要负责平台用户的用户认证，sentry则负责数据的权限管理。
Apache Sentry是Cloudera公司发布的一个Hadoop开源组件，它提供了细粒度级、基于角色的授权以及多租户的管理模式。
Sentry提供了对Hadoop集群上经过身份验证的用户和应用程序的数据控制和强制执行精确级别权限的功能。Sentry目前可以与Apache Hive，Hive metastore / HCatalog，Apache Solr，Impala和HDFS（仅限于Hive表数据）一起使用。
Sentry旨在成为Hadoop组件的可插拔授权引擎。它允许自定义授权规则以验证用户或应用程序对Hadoop资源的访问请求。Sentry是高度模块化的，可以支持Hadoop中各种
数据模型的授权。
详情见：
基于HUE可视化的大数据权限管理
基于Sentry的大数据权限解决方案
基于Kerberos+Ldap复合认证的大数据权限
基于Kerberos认证的大数据权限解决方案
基于LDAP认证的大数据权限解决方案
BI数据权限设置，让你的数据更有保障
企业进行数据分析时，为了保密或业务需要，有许多业务数据，一些员工是无权查看的，这时需要对不同人员的数据权限进行管控。
那么具体授权操作是如何实现的？这里我们以数林BI为例，通过两个实例来和大家分享。
以业务员销售分析这一模型为例，每个业务员只能查看本年自己的个人业绩情况。
如图所示，点击【基础设置】模块，选择用户后单击【模型数据】-【新增】，进入新增模型数据权限界面，对“业务销售分析”这一模型进行授权（若是其他分析报表的数据授权也可参照此例）：
1. 部门处过滤“销售”，查看所有销售部职员；
2. 管理处取消“选中”，排除所有管理人员；
3.点击【全选】，选择所有显示的用户；
4.点击“仅表格条件”变更为“且开始日期”并将“上一次更新”修改为“今年初”；
5.在“业务员职员名称”下方的过滤栏输入“@姓名@”，保存即可完成所有业务员的授权。
还是以业务销售分析模型为例，假设每个部门经理只能查看自己负责的部门业绩情况，操作步骤依然类似：
1.部门处过滤“销售”，查看所有的销售部职员；
2. 管理处选择“选中”，查看所有管理人员；
3. 点击【全选】，选择所有显示的用户；
4. 在“业务员部门名称”下方的过滤栏输入“@部门@”，保存即可完成所有业务经理的授权。
当然，管理员也可通过自定义属性，将需要的属性进行维护，用上述类似的便捷操作对用户的数据模型权限进行授权，让管理员减少重复的授权操作。如图所示：
关于更多BI权限设置操作，小伙伴们可参考我们之前分享的BI权限层层管控的相关文章内容。
如上图，未设置BI权限前，每个人都可以都可以看到这张业绩报表的所有数据展现，当我们权限设置后，每个人只能看到自己权限内的数据：
vue-element 权限管理数据的处理，简单实用。
1,首先获取到后端返回给我们的权限数据,数据大概长这么个样子。
2,要渲染到element的树形结构上的话，要做一层递归处理，让它形成树形结构。这个也可以不用递归，我看他们用map这个属性，也能很好的处理。具体做法如下：
这个数据渲染好以后，是长这样的，也就符合了我们el-tree组件所需的数据结构。
3，现在管理员开始在管理界面开始做权限管理操作。如图所示：
这样的话返回给后端的是一个id组成的数组， data=[1,4,10] 这就是你返回给后端的数据 ，还没完接下来该复现了。
4,现在后端给数据返回给你，他是按照刚才你给的数据返回过来的。然后添加上check属性，这个也是你们约定，数据大概就长这样：
你可能还在想不错，不错。还不用递归，循环就给数据拿了。当你拿到所有的数组check为true的数据组成的数组treelist,然后 this.$refs.tree.setCheckedKeys(this.treelist) 上去时，已经不符合要求了，因为父集全选，子集就会全选。他会变成这样：
5，这样肯定不行，我们要再做一次数据处理，让它符合要求。1， 要给数据再次递归成树形结构 ，还是上面的方法给数据递归成树形结构。2，遍历这个树形结构，判断父集的子集是否全部为true，如果不是就就让他的check属性设置为false，
这里说明一下。this.state 这个变量你要自己设置一下或者全局变量都行，反正要设置一下，设置为true。首先我们给递归好的树形结构放在 traveData 这个函数里面这个函数会递归一遍我们的数据，主要是判断
item.check = item.children.length 0 ? this.getchildStatus(item.children) : item.check
这里是判断他有没有子集，没有的话就是ok，那么check的值就是合理的，如果他有子集但是它的check为true这就很不合理，因为我们不知道他的子集到底是不是都是选了的，也就是check为true，所以要做一层碰断，判断他的子集是否全为true，只要他的子集有一个不为true，那它就不能为true this.getchildStatus(item.children) 所以这里又做了一层，遍历他的所有子集。判断check的值。ok做到这里我们大概也差不多了。拿到 return data 的值我们还要做一次数据的递归，
6,至此，我们已经拿到了 this.treelist的值我们只要
这样就可以把我们的树形结构又从新渲染好了。数据用的都是模拟数据，但是和业务场景的数据其实差别不大，只要按照这个流程就ok了。不管是element，antd，我觉得这个全选和半选感觉还可以优化下。不是真的挺绕的。
权限管理——后台系统的权限设置，吐血整理，原型图食用更直观
公司最近在做一个项目，具体我就不说了，业务做完了之后，主管说后台现在业务流程可以跑得通了，但是接下来要做权限管理，不然这个系统还是没法用，不可能每个人在后台都可以随意操作和更改数据吧，我也就开始着手做后台的权限系统。
说实话***次接触权限系统，相信很多PM跟我一样上网搜索各种资料，但很多都是理论上的知识，看上去也都能理解，但就是做起来的还是毫无头绪，我在研究了网上大量的权限设置相关的知识后，总结了一下：
1.权限设置现在普遍采用用户-角色-权限三者结合的方式，也成RBAC模型，是目前主流的权限配置模型，我说了是主流，也并不代表所有，但是相当多的电商平台，销售crm和SaaS平台也是这么做的，我结合了一下公司的业务，发现确实也是适合的，就采用这样的方式，将权限和角色绑定（多对多），然后在跟用户匹配（多对一），这点不难理解，比如产品经理这个角色，权限可以有很多，比如用户管理，活动管理和数据管理等权限；那一个用户在一家公司可能身兼多职，不仅担任产品经理的岗位，还可能是一个项目经理，客户经理或者是销售经理，这样的人物在公司也都很常见；
2.权限设置也分为操作权限和数据权限，一个是对后台数据可以进行增删改查，另外一个是是否有权限查看某些数据，这两个权限一定是分开设置的，可能有的文章会提到还会要页面权限，但是我在实际操作中将【页面权限】和【操作权限】放在一起设置，即我勾选某个操作权限的时候，对应的我也就享有这个页面权限。数据权限则指的是我在这个页面里具体能看到哪些数据，是全部数据，本人数据，本人及下属的数据，部门数据，还是部门及及子部门数据（总共就这五种）？屡清楚权限的范围其实是最难的，作者当时想了很久。
3.部门和用户***是放在一起设置，如果说只是配置操作权限的话，完全是可以抛弃部门的，可以作为一个不重要的选填项放在用户信息列表中，但是前面在讲数据权限的时候也提到了，查看数据的范围不仅取决于用户的岗位，还跟部门有联系，不然你这么设置查看本部门的数据？怎么设置查看部门及子部门的数据？比如一个销售经理，他肯定要能看到自己团队所有人的销售数据，一个区域经理，肯定要能看到管辖区域内各地方的数据对吧。我的建议是在创建部门的时候就去添加用户。
接下来我就是放原型图的时候了，我知道这肯定是你们最想看的，做权限管理，我只做了三张表
首先是角色表， 角色表是为了绑定权限的 ，大家可以看到我的角色表是分为两个部分的，左边这部分是创建角色，角色列表，右边这个权限列表，我是采用表格的展现形式，你当然也可以用像window是
那样的文件夹的形式，只是我觉得这样的形式很直观。超级管理员不用说了，肯定拥有***的权限，而且不可更改和设置，其他的角色你都可以添加修改和删除。我的权限列表显示的都是【前台功能】，所谓前台功能呢，就是对数据的操作，没有做【后台功能】呢，是因为我们公司的业务规模小，一个超级管理员就够用了，我不用将安全设置啊，流程设置啊，审批设置啊还有系统设置啊放权下去，所以这里只展示了业务层面上的操作权限。
其次是职能表，重要的话说三遍， 职能表就是用来设置数据权限的！职能表就是用来设置数据权限的！职能表就是用来设置数据权限的！
可以看到这张表跟角色表很相似，左边是职能表，类似于角色，右边就是数据权限的配置，选中某一个职能，然后可以给他配置数据权限，要注意， 操作权限的配置是多选的，数据权限的配置是单选的！还有就是，角色表的名称和职能表的名称起的一样也可以，没有关系的，但是区分开他们分别绑定的是操作权限和数据权限就好了，别迷了。
最后，再来说一下部门/用户表，这个表的作用不用说大家也知道是做什么的了，没错就是要把角色和职能绑定到用户身上，实现权限设置的闭环。
可以看出来这个表也是分为两个部分，左边这个部门是部门的增删改查，右边这个是用户的增删改查，配置权限。选中某个部门，就可以查看到某个部门下的所有用户，很清晰也很直观，全公司默认是一级部门，不可删除和更改，之后就可以往下添加子部门，这样的扩展性不言而喻，很多公司都是把部门给写死了，这样会导致后期的扩展性很差，万一出现部门合并，取消某个部门了怎么办，还有合并部门要注意数据的转移！新增用户需要填写的信息必填项都已标注，选择部门和直属上级当然是为了绑定数据权限（查看下级数据和查看部门数据）。
新增用户后，就可以开始配置角色和职能了，大家可以清楚地看到，角色和职能完全是分开的，分别选中某项权限添加给用户，互相独立，虽然看似简单的页面，但是作者在一开始硬是想不来的，毫无头绪，这样匹配角色和职能直观清晰，扩展性好，互相不影响。
这就是简单的权限配置，但是作者在做的时候发现一个问题，那就是数据转移的问题，考虑到即使在一个公司，员工也有可能转岗，离职，离职的话数据不会删除，只是将用户的【在职】状态变成【离职】状态就好了，但是如果一个用户转岗了，比如从销售岗转到客服岗，那么他之前的操作数据又该存放在哪里？如果部门合并了或者是解散了，部门数据归哪里?如果有哪位大神懂得话，麻烦指点一下，作者的小公司里的没有产品大牛，完全靠自己摸索，请大神们不吝赐教。
想要具体的原型图，可以留言哦，我还没有画完……
若依-数据权限管理
在实际开发中，需要设置用户只能查看哪些部门的数据，这种情况一般称为数据权限。
例如对于销售，财务的数据，它们是非常敏感的，因此要求对数据权限进行控制， 对于基于集团性的应用系统而言，就更多需要控制好各自公司的数据了。如设置只能看本公司、或者本部门的数据，对于特殊的领导，可能需要跨部门的数据， 因此程序不能硬编码那个领导该访问哪些数据，需要进行后台的权限和数据权限的控制。
开发过程如下
+前端传递params的方式
如何数据权限设置控制
对数据进行控制***通过弹性的方式，在一个系统里面或者功能模块里面对用户角色或者岗位进行设置，一般权限控制默认在一个权限管理系统模块进行设定，数据权限也应该如此。
权限系统除了可以对用户能操作那些功能进行限定，也还可以对其访问那些组织机构的数据进行限定，我们通过权限系统，把这些权限控制的数据进行保存，在应用系统模块里面进行整合即可，根据角色拥有的数据权限，授予用户对其他部门或者机构的数据进行访问。如下面是我权限系统模块里面对角色权限的设置操作。
1）对角色功能权限进行设置
2）对角色数据权限进行控制
当对角色的数据权限进行保存后，我们就可以把这个角色能够访问的组织机构（公司、部门、工作组等等）进行记录起来了。
2）应用系统的集成，实现数据权限的控制
如我的一个病人资料应用系统，客户要求就是基于互联网的应用系统，因此使用WCF数据通讯模式实现数据的集中管理，而且他们要基于医院单位的数据管理模式，也就是每个单位管理各自的数据，我们可以把不同的医院单位作为不同的公司性质来区分，这样在权限模块中进行设置即可。
1）在应用程序中，通过在程序头部，让可以管理多个医院机构的用户选择管理的数据访问，即可实现不同的数据区分管理。
2）当用户在上面切换不同的机构，所有存在的界面数据全部实现刷新，如打开了很多界面，那么这些界面的数据也随之更新为对应新的机构下的数据。
关于数据权限管理和数据权限管理办法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。