业界有很多种权限控制的设计模型。做过访问控制的人或多或少都比较过这些方案的优劣。我过往的一些相关经历，让我发现一些在做这个选择的时候，可以思考的问题。简单梳理一下，以作备忘。
引入访问控制的目的是什么？
这是非常重要的问题。是“为了安全”吗？不，这个目的太宽泛了，宽泛到无法指导你做任何有效而且合理的决策。作为一个安全策略的制定者，除了“为了安全”之外，必须要搞清楚，你要防范的人是哪些，想要控制其的哪些行为。不用很细，但是至少是“原则上”地。比如：
- 要防范的人，分哪些？公司内部，公司外部两类吗？防范方案有什么不同？
- 防范他们的什么行为？是要防范他们无意的误操作？还是要防范他们恶意的删库跑路？真的都要吗？
- 你愿意为了“安全”将效率牺牲到什么程度？比如，为了保护代码安全，最安全的做法，显然是给电脑断外网，并且禁用除显示器外的所有输出设备，不允许带入手机，也不允许把电脑带出，而且办公室不能有窗户，以防对面办公楼的长枪短炮拍摄到你屏幕上的代码。这个时候，你可能牺牲的不仅仅是效率，可能还有员工的技术成长、身心健康，以及这个岗位的离职率。这可不是说段子，很多外包IT公司的部分项目就是这么搞的。
访问控制的主体是谁？
或者说，谁应当受到访问控制？
- 人。人分哪些？内部员工，外部用户，还有吗？他们的权限模型需要统一吗？能够统一吗？
- 服务。首先，服务本身需要访问控制吗？我认为是必要的。因为服务所应当有的权限，是很难和公司内部某一个人的权限完全一致的。而且，人的变动会远多于服务的变动。对服务本身的访问控制的管理成本，一般也会远低于对人的访问控制的管理成本。另外，不要觉得对服务这个东西的访问控制很不自然，你手机上的App，也算是一种服务。而你肯定是想管理App的权限，而不是App的开发者能在你的手机上干什么。我见过的最奇怪的规矩是，权限只能给人，不接受给服务本身设置访问控制方案，但是接受服务以root身份运行，也接受负责服务的人，拥有本当属于服务的权限，也即生产环境的所有权限。当然，我也理解他们给出的解释：出了事儿，他们可以很方便地定位到责任人。而且他们只需要维护人的权限，完全不需要考虑服务的权限这么个事儿。这对他们自己而言，这的确是最安全的方案。
- 要统一吗？人类才华产生的最大非理性的冲动，就是见到分开的东西，就想找到一个统一的方式去处理，比如爱因斯坦干的那事儿。也许能统一，但是作为一个企业，而非一个科学家的时候，你要着重考虑的是成本收益及可操作性。而不是一个方案看上去有多完美多NB。当然，如果你要拿着这个方案去骗某个风投的话另当别论。
访问控制的客体是谁？
或者说，控制对什么东西的访问？显然并不是所有的东西都需要访问控制的。但你判断一个东西要不要做访问控制的条件有那些？要不要花钱？会不会失控？举几个例子：
- 办公室空调的按钮。据我了解很多人都希望有，但是这并不需要权限系统来解决，如果真要暴力解决，这只需要一些胶带并让公司行政把遥控器收好。
- 数据库DDL。这个一般都是要控制的，但是再考虑下主体，你要想好想让哪个主体来做。是人，还是服务？是开发还是运维？如果你选择人，那基本上就和市面上的DB Migration框架说再见了。这也说明了，访问控制上的一些高层面的决定，会影响你服务内技术栈的选择。
- 服务运行时环境变量及参数。这个伪逻辑是这样的，环境变量的变化，可以彻底改变应用程序的行为，所以要严格控制对环境变量及参数的改动，只能由维护人员有权限改。于是上线的过程，就需要由开发给运维交待一整页配置变更。于是，基本告别Continous Delivery了。当然，这个时候人们一般都会安慰自己说，我们其实也并不需要CD，而不是反思前面的问题有没有更好的解决方案。毕竟项目都是有Deadline的。
谁负责设计资源访问的细节？
我之前在一家投行工作，公司使用的是一个内部自研的权限控制系统，混合了ABAC和RBAC两种方案的优势，其权限数据结构是可定制的，由各个业务团队自行定义资源的一切细节，非常强大灵活。那段时间，负责这个框架的那个团队，开始做这样的一个事儿：用AI技术，分析当前的权限配置中不合理的部分。因为公司当时面临这样的一个问题：连业务团队自己，都已经无法看出自己的权限数据中有什么问题了。因为绝大多数情况下，人们使用这个框架的方式都是：简单看下原来的数据是什么样的，用最少的改动，最少的数据量，就可以完成这次权限配置变更的要求。而不会去深入地思考，“应该”做什么的数据变更是最合理的。最后这个权限控制数据库就失控了。不过好在人们都知道这个问题，并且在积极解决。所以再好的框架，再好的设计，也会因为不当的使用而难以发挥其里大的价值。那么哪些是使用上的细节和设计上的细节呢？比如：
- 公司到底有哪些角色？这些角色应该有哪些权限？这些细节是技术人员先定一个，还是先和相关方讨论清楚？
- 公司有哪些资源是比较容易分辨的，但是每类资源应该有哪些属性呢？是加属性好？还是加新资源好？
- 可以为每笔交易都定义一个独立的资源项吗？
- 客服需要客户信息，交易员也需要客户信息，但是需要的部分不同。这时，这两类客户信息，是两种资源吗？
类似以上这些问题，无论如何选择，都是可以完成工作的。但是质量上却有云泥之别。只是有些差别，有些后果，要出现后续的状况时，才会体现出来，做决定的时候，常常因为“都可以”而无视掉。
谁负责设定资源访问的权限？
即授权。一个简单的回答是：owner。然后下面的问题就是，谁是owner？我只想表达一点，从权限控制的角度，同一个东西的不同方面，其owner可以是不同的。比如：开发写了一个接口，这个接口谁能调用谁不能，肯定不是这个开发人员决定的，至少也要构架师才能决定；但是同一个接口，假设为了保护自身稳定性，添加了访问频率的上限的设定，在不影响整体服务功能和可用性的情况下，这个设定的owner可以是而且应该是开发者本人。