组织架构和权限模式

最近看了一些关于组织架构和权限的资料，再加上现在的项目里面有涉及，算是做一下这两天了解的大概总结吧，求指教。                               ------学徒

先说组织架构的东西，

所谓组织架构通俗点说就是一群不同特色的人怎么分组怎么分配，

在企业里基本上就是 老总 副总 主管 干部 员工，简单的分一下。

在学校里来说就是，校长，副校长，院长，副院长，主任 ，辅导员，班长，团支书 等等

基本上大概了解后，就是分析了，

先说组织结构的模型吧，毕竟是一个理论式的东西，总是有展现形式的。

直线型：最上级到最下级 是一条单线 就像是一个公司永远只有一个干活的人，其他人都是领导，让我想到了当初看到的一张图，你在敲代码的时候，你周围围了一圈大佬对你指指点点，

职能型：企业总是要分部门，什么财务部，什么技术部，什么视频部人事部了。当然上面最大的还是老板，但是老板只会和部长交流。我不配

矩阵型：这个就有点意思了，一般的都是针对项目来说，总的来说就是，人民群众是块砖，哪里需要哪里搬，像这种，想划水的，呵呵，我劝你放弃吧，

事业部：这个就有点大，我的理解就是集团化，总公司和子公司的关系，各自发展，但是子公司还是要受总公司的一些限制

下面基本上就是大多数企业的架构类型：（你能很明显的区分吗，反正我不行）

 说完组织架构，就要说相辅相成的权限了。

是的，你有一个公司，但是如果所有人都能代替老板签协议，我估计你的公司能被所有人卖一边，那么针对这种不科学的不现实的想法来说，老板权限肯定是最大的，你想偷偷赚点外快，想想吧你，别做梦了。

咳，回归正题，

权限说到底就是，制度，限制，对于你能干什么不能干什么有明确的控制，我还记得有那么一本书，听说书上写着各种赚钱的路子，但是没人能用，因为都没有权限，偶尔有那么一两个不听话的现在还在吃着免费的晚餐。

权限的概念没什么好说的，还是直接说模式：

懒得敲键盘了。

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特点： 集中化管理 可以按需实现不同颗粒度的权限控制 不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中 定义权限时，不能直观看出用户和对象间的关系 规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦

权限判断需要实时执行，规则过多会导致性能问题

好了，该你了