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

企业上云首当其冲的就是要解决安全性的问题，是否满足企业对安全的诉求成了影响其是否上云的一个十分重要的因素之一。安全是一个很大的话题，从底层资源数据的安全到上层应用访问的安全，从访问客体（资源或服务）的安全到访问主体（人或者第三方服务）的安全，这些都属于安全的范畴之内。访问控制正是从资源访问的主客体关系出发，解决企业对资源访问的权限控制的需求。

维基百科对访问控制的定义如下：

访问控制是指允许或禁止某人使用某项资源的能力。

云环境下的访问控制使得这个问题变得复杂，我曾写过一篇对云环境下访问控制系统的思考来阐述这个问题。从2.14号上线访问控制以来，接入访问控制的业务越来越多，截止目前已有六大业务支持访问控制；同时，访问控制还对云服务提供了支持，用户可以授权给易盾和视频云来访问其在NOS（网易对象存储）的数据资源。现在，你可以自定义访问控制策略，通过一套特定DSL语法来定义权限。根据自己的实际使用场景和组织架构来定义对权限的需求，这具有十分重要的意义。

举个例子，如果不允许某某子账号删除avatar桶中file-1.png的图片，而允许其对其他任何文件有所有的控制权限，那么可以定义如下的策略来达到这个目的。

{
    "version": 1,
    "statement": [
        {
            "action": [
                "comb:nos:DeleteObject"
            ],
            "effect": "deny",
            "resource": [
                "comb:nos:*:*:*:avatar/file-1.png"
            ]
        },
        {
            "action": [
                "comb:nos:*"
            ],
            "effect": "allow",
            "resource": [
                "comb:nos:*:*:*:*"
            ]
        }
    ]
}

通过语言来定义权限，用户将获得十分灵活的权限控制，当然也包含了细粒度的权限控制。使用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，那么则允许，否则也拒绝。具体流程如下。

在授权时请遵循最小权限原则，即根据用户的需要，将刚好能满足其需求的权限赋予给他，这样有助于规避一些越权执行的问题。除此之外，最佳实践还包含及时收回用户不再需要的权限，尽量通过组和角色来授权等等。详细的文档可以参考访问控制的官方文档。

通过以上的介绍，不知道你是否对访问控制有一个大致的了解。如果还是有些云里雾里，那不如自己去动手定义一个属于自己的访问策略吧！