『访问控制』：为你的云上业务再加一把锁

企业上云首当其冲的就是要解决安全性的问题，是否满足企业对安全的诉求成了影响其是否上云的一个十分重要的因素之一。
 
安全是一个很大的话题，从底层资源数据的安全到上层应用访问的安全，从访问客体（资源或服务）的安全到访问主体（人或者第三方服务）的安全，这些都属于安全的范畴之内。访问控制正是从资源访问的主客体关系出发，解决企业对资源访问的权限控制的需求。
 
维基百科对访问控制的定义如下：
 
访问控制是指允许或禁止某人使用某项资源的能力。
 
云环境下的访问控制使得这个问题变得复杂。自网易云基础服务（蜂巢）今年 2 月14 日上线访问控制以来，接入访问控制的业务越来越多，截止目前已有六大业务支持访问控制。同时，访问控制还对其他云服务提供了支持，用户可以授权给网易云安全（易盾）和通信与视频来访问其在 NOS（对象存储）的数据资源。
 
目前，你可以自定义访问控制策略，通过一套特定 DSL 语法来定义权限。根据自己的实际使用场景和组织架构来定义对权限的需求，这具有十分重要的意义。
 
举个例子，如果不允许某某子账号删除 avatar 桶中 file-1.png 的图片，而允许其对其他任何文件有所有的控制权限，那么可以定义如下的策略来达到这个目的：
 

 
通过语言来定义权限，用户将获得十分灵活的权限控制，当然也包含了细粒度的权限控制。
 
使用 DSL 来定义权限的做法很早之前就存在了，可以追溯到 2001 年的 XACML 时代。目前主流的云计算厂商也均采用这种方式来描述权限。网易云基础服务（蜂巢）采用了业界相同的命名方式来降低用户的理解成本。接下来对策略语法做一个简单的介绍。
 
策略语法就是有着一定约束关系的 JSON 格式数据，由 version 和 statement 两个部分组成。version 目前只支持 1，而 statement 则是描述策略的具体形式。statement 由三个部分组成，action、effect 和 resource，这三个子句构成了访问控制最为核心的三个部分。
 
○ effect 表示授权类型，只能是 allow（允许）或者 deny（拒绝）。
 
○ action 表示动作，组成结构为 product:service-name:action-name。product 目前只支持 comb，service-name 代表云计算基础服务（蜂巢）下的服务，目前已支持的服务如下：
 
服务代号 | 服务名称
nos | 对象存储
nlb | 负载均衡
rds | 关系型数据库
mongodb | MongoDB
ncr | Redis 缓存
cdn | CDN
 
○ action-name 表示具体动作的名称，例如 nos 支持 GetBucket、PutObject 等动作，cdn 支持 CreateDomain、DisableDomain 等等，具体的动作请参考对应服务的文档。
 
○ resource 表示资源，组成结构为 product:service-name:region:az:account-id:resource-descriptor。
 
○ product 和 service-name 和 action 中的意义相同，region 表示地域，az 表示可用域，目前只支持 * ，account-id 是用户的主账号 id，目前也只能填入 * ，resource-descriptor 是具体资源的描述符。resource-descriptor 根据具体的服务会有变化，整体上是树形结构的。例如：bucket-1/file-1.png可以表示 nos 中 bucket-1 的桶中的 file-1.png 文件，而 instance/nlb-1 可以表示 nlb 中实例名称为 nlb-1 的实例。具体的规则请参考对应服务的文档。
 
statement 语句本身是一个 Array，你可以在其中最多定义 5 条子句。这样就允许你将多条策略组合在一个策略里面，也可以根据需要将策略拆改，选择权在你手上。
 
通过策略语言，企业完全可以根据自身的实际需要来定义权限，具有非常大的灵活性和自由度。
 
如果你以前使用过其他云的访问控制产品，那么上手会很快。如果是第一次接触此类产品，也不用担心，我们提供了一个强大的 “编译器” 来检查你的策略语法是否合法，并提供简单直观的错误展示来帮你迅速定位问题，如下图所示。
 

 
另外，访问控制还提供了子账号、组和角色来满足企业对访问主体描述性的需求，企业可以根据自身的组织架构和研发模式来组合使用这些身份。
 
掌握了授权策略后，理解鉴权的执行流程也是很重要的。鉴权流程按照 Deny 优先原则执行，如果有显式的 Deny，那么直接拒绝；如果有显式的 allow，那么则允许，否则也拒绝。具体流程如下。
 

 
在授权时请遵循最小权限原则，即根据用户的需要，将刚好能满足其需求的权限赋予给他，这样有助于规避一些越权执行的问题。除此之外，最佳实践还包含及时收回用户不再需要的权限，尽量通过组和角色来授权等等。详细的文档可以参考访问控制的官方文档。
 
通过以上的介绍，不知道你是否对访问控制有了一个大致的了解。如果还是有些云里雾里，那不如自己动手定义一个属于自己的访问策略吧！