最近看了一些关于组织架构和权限的资料,再加上现在的项目里面有涉及,算是做一下这两天了解的大概总结吧,求指教。 ------学徒
先说组织架构的东西,
所谓组织架构通俗点说就是一群不同特色的人怎么分组怎么分配,
在企业里基本上就是 老总 副总 主管 干部 员工,简单的分一下。
在学校里来说就是,校长,副校长,院长,副院长,主任 ,辅导员,班长,团支书 等等
基本上大概了解后,就是分析了,
先说组织结构的模型吧,毕竟是一个理论式的东西,总是有展现形式的。
直线型:最上级到最下级 是一条单线 就像是一个公司永远只有一个干活的人,其他人都是领导,让我想到了当初看到的一张图,你在敲代码的时候,你周围围了一圈大佬对你指指点点,
职能型:企业总是要分部门,什么财务部,什么技术部,什么视频部人事部了。当然上面最大的还是老板,但是老板只会和部长交流。我不配
矩阵型:这个就有点意思了,一般的都是针对项目来说,总的来说就是,人民群众是块砖,哪里需要哪里搬,像这种,想划水的,呵呵,我劝你放弃吧,
事业部:这个就有点大,我的理解就是集团化,总公司和子公司的关系,各自发展,但是子公司还是要受总公司的一些限制
下面基本上就是大多数企业的架构类型:(你能很明显的区分吗,反正我不行)
说完组织架构,就要说相辅相成的权限了。
是的,你有一个公司,但是如果所有人都能代替老板签协议,我估计你的公司能被所有人卖一边,那么针对这种不科学的不现实的想法来说,老板权限肯定是最大的,你想偷偷赚点外快,想想吧你,别做梦了。
咳,回归正题,
权限说到底就是,制度,限制,对于你能干什么不能干什么有明确的控制,我还记得有那么一本书,听说书上写着各种赚钱的路子,但是没人能用,因为都没有权限,偶尔有那么一两个不听话的现在还在吃着免费的晚餐。
权限的概念没什么好说的,还是直接说模式:
懒得敲键盘了。
ABAC 有时候也被称为PBAC(Policy-Based Access Control)或CBAC(Claims-Based Access Control)。k8s中有使用这种授权策略 这种类型用的还是比较少的
来来来,敲黑板了,下面这道题,期末考试一定考,就看你们要不要了。
ACL:
1.自主访问控制(DAC: Discretionary Access Control) 这种设计最常见的应用就是文件系统的权限设计,如微软的NTFS。 DAC最大缺陷就是对权限控制比较分散,不便于管理 发会员卡
2.强制访问控制(MAC: Mandatory Access Control) 每一个对象都都有一些权限标识,每个用户同样也会有一些权限标识,而用户能否对该对象进行操作取决于双方的权限标识的关系,这个限制判断通常是由系统硬性限制的(管理员) MAC是为了弥补DAC权限控制过于分散的问题而诞生的 一把十字钥匙配一把带有十字锁芯的锁
RBAC(Role-Based Access Control:基于角色的访问控制)
模型 RBAC认为权限授权的过程可以抽象地概括为:Who是否可以对What进行How的访问操作,并对这个逻辑表达式进行判断是否为True的求解过程,也即是将权限问题转换为What、How的问题,Who、What、How构成了访问权限三元组,具体的理论,这里我们就不做详细的展开介绍,大家有个印象即可。 领取会员卡后的等级身份 初 中 高
ABAC
例如规则:“允许所有班主任在上课时间自由进出校门”这条规则,其中,“班主任”是用户的角色属性,“上课时间”是环境属性,“进出”是操作属性,而“校门”就是对象属性了
ABAC特点: 集中化管理 可以按需实现不同颗粒度的权限控制 不需要预定义判断逻辑,减轻了权限系统的维护成本,特别是在需求经常变化的系统中 定义权限时,不能直观看出用户和对象间的关系 规则如果稍微复杂一点,或者设计混乱,会给管理者维护和追查带来麻烦
权限判断需要实时执行,规则过多会导致性能问题
好了,该你了