资源访问控制上的一些思考

业界有很多种权限控制的设计模型。做过访问控制的人或多或少都比较过这些方案的优劣。我过往的一些相关经历,让我发现一些在做这个选择的时候,可以思考的问题。简单梳理一下,以作备忘。

引入访问控制的目的是什么?

这是非常重要的问题。是“为了安全”吗?不,这个目的太宽泛了,宽泛到无法指导你做任何有效而且合理的决策。作为一个安全策略的制定者,除了“为了安全”之外,必须要搞清楚,你要防范的人是哪些,想要控制其的哪些行为。不用很细,但是至少是“原则上”地。比如:

  1. 要防范的人,分哪些?公司内部,公司外部两类吗?防范方案有什么不同?
  2. 防范他们的什么行为?是要防范他们无意的误操作?还是要防范他们恶意的删库跑路?真的都要吗?
  3. 你愿意为了“安全”将效率牺牲到什么程度?比如,为了保护代码安全,最安全的做法,显然是给电脑断外网,并且禁用除显示器外的所有输出设备,不允许带入手机,也不允许把电脑带出,而且办公室不能有窗户,以防对面办公楼的长枪短炮拍摄到你屏幕上的代码。这个时候,你可能牺牲的不仅仅是效率,可能还有员工的技术成长、身心健康,以及这个岗位的离职率。这可不是说段子,很多外包IT公司的部分项目就是这么搞的。

访问控制的主体是谁?

或者说,谁应当受到访问控制?

  1. 人。人分哪些?内部员工,外部用户,还有吗?他们的权限模型需要统一吗?能够统一吗?
  2. 服务。首先,服务本身需要访问控制吗?我认为是必要的。因为服务所应当有的权限,是很难和公司内部某一个人的权限完全一致的。而且,人的变动会远多于服务的变动。对服务本身的访问控制的管理成本,一般也会远低于对人的访问控制的管理成本。另外,不要觉得对服务这个东西的访问控制很不自然,你手机上的App,也算是一种服务。而你肯定是想管理App的权限,而不是App的开发者能在你的手机上干什么。我见过的最奇怪的规矩是,权限只能给人,不接受给服务本身设置访问控制方案,但是接受服务以root身份运行,也接受负责服务的人,拥有本当属于服务的权限,也即生产环境的所有权限。当然,我也理解他们给出的解释:出了事儿,他们可以很方便地定位到责任人。而且他们只需要维护人的权限,完全不需要考虑服务的权限这么个事儿。这对他们自己而言,这的确是最安全的方案。
  3. 要统一吗?人类才华产生的最大非理性的冲动,就是见到分开的东西,就想找到一个统一的方式去处理,比如爱因斯坦干的那事儿。也许能统一,但是作为一个企业,而非一个科学家的时候,你要着重考虑的是成本收益及可操作性。而不是一个方案看上去有多完美多NB。当然,如果你要拿着这个方案去骗某个风投的话另当别论。

访问控制的客体是谁?

或者说,控制对什么东西的访问?显然并不是所有的东西都需要访问控制的。但你判断一个东西要不要做访问控制的条件有那些?要不要花钱?会不会失控?举几个例子:

  1. 办公室空调的按钮。据我了解很多人都希望有,但是这并不需要权限系统来解决,如果真要暴力解决,这只需要一些胶带并让公司行政把遥控器收好。
  2. 数据库DDL。这个一般都是要控制的,但是再考虑下主体,你要想好想让哪个主体来做。是人,还是服务?是开发还是运维?如果你选择人,那基本上就和市面上的DB Migration框架说再见了。这也说明了,访问控制上的一些高层面的决定,会影响你服务内技术栈的选择。
  3. 服务运行时环境变量及参数。这个伪逻辑是这样的,环境变量的变化,可以彻底改变应用程序的行为,所以要严格控制对环境变量及参数的改动,只能由维护人员有权限改。于是上线的过程,就需要由开发给运维交待一整页配置变更。于是,基本告别Continous Delivery了。当然,这个时候人们一般都会安慰自己说,我们其实也并不需要CD,而不是反思前面的问题有没有更好的解决方案。毕竟项目都是有Deadline的。

谁负责设计资源访问的细节?

我之前在一家投行工作,公司使用的是一个内部自研的权限控制系统,混合了ABACRBAC两种方案的优势,其权限数据结构是可定制的,由各个业务团队自行定义资源的一切细节,非常强大灵活。那段时间,负责这个框架的那个团队,开始做这样的一个事儿:用AI技术,分析当前的权限配置中不合理的部分。因为公司当时面临这样的一个问题:连业务团队自己,都已经无法看出自己的权限数据中有什么问题了。因为绝大多数情况下,人们使用这个框架的方式都是:简单看下原来的数据是什么样的,用最少的改动,最少的数据量,就可以完成这次权限配置变更的要求。而不会去深入地思考,“应该”做什么的数据变更是最合理的。最后这个权限控制数据库就失控了。不过好在人们都知道这个问题,并且在积极解决。所以再好的框架,再好的设计,也会因为不当的使用而难以发挥其里大的价值。那么哪些是使用上的细节和设计上的细节呢?比如:

  1. 公司到底有哪些角色?这些角色应该有哪些权限?这些细节是技术人员先定一个,还是先和相关方讨论清楚?
  2. 公司有哪些资源是比较容易分辨的,但是每类资源应该有哪些属性呢?是加属性好?还是加新资源好?
  3. 可以为每笔交易都定义一个独立的资源项吗?
  4. 客服需要客户信息,交易员也需要客户信息,但是需要的部分不同。这时,这两类客户信息,是两种资源吗?

类似以上这些问题,无论如何选择,都是可以完成工作的。但是质量上却有云泥之别。只是有些差别,有些后果,要出现后续的状况时,才会体现出来,做决定的时候,常常因为“都可以”而无视掉。

谁负责设定资源访问的权限?

即授权。一个简单的回答是:owner。然后下面的问题就是,谁是owner?我只想表达一点,从权限控制的角度,同一个东西的不同方面,其owner可以是不同的。比如:开发写了一个接口,这个接口谁能调用谁不能,肯定不是这个开发人员决定的,至少也要构架师才能决定;但是同一个接口,假设为了保护自身稳定性,添加了访问频率的上限的设定,在不影响整体服务功能和可用性的情况下,这个设定的owner可以是而且应该是开发者本人。

发表评论