内容简介：访问控制：为你的云上业务再加一把锁
企业上云首当其冲的就是要解决安全性的问题，是否满足企业对安全的诉求成了影响其是否上云的一个十分重要的因素之一。安全是一个很大的话题，从底层资源数据的安全到上层应用访问的安全，从访问客体（资源或服务）的安全到访问主体（人或者第三方服务）的安全，这些都属于安全的范畴之内。访问控制正是从资源访问的主客体关系出发，解决企业对资源访问的权限控制的需求。
维基百科对 访问控制 的定义如下：
访问控制是指允许或禁止某人使用某项资源的能力。
云环境下的访问控制使得这个问题变得复杂，我曾写过一篇 对云环境下访问控制系统的思考 来阐述这个问题。从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，那么则允许，否则也拒绝。具体流程如下。
在授权时请遵循最小权限原则，即根据用户的需要，将刚好能满足其需求的权限赋予给他，这样有助于规避一些越权执行的问题。除此之外，最佳实践还包含及时收回用户不再需要的权限，尽量通过组和角色来授权等等。详细的文档可以参考访问控制的官方文档。
通过以上的介绍，不知道你是否对访问控制有一个大致的了解。如果还是有些云里雾里，那不如自己去动手定义一个属于自己的访问策略吧！
This article used CC-BY-SA-3.0 license, please follow it.
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 中台之上（一）：重视业务架构，不要让“业务的归业务、技术的归技术”
- 小程序多业务线融合【完整分包业务接入】
- 抱歉，请不要把 “业务逻辑层” 理解为 “业务中台”
- 入职一家大公司，应该选择新业务还是老业务？
- 机器学习业务实践之路：如何通过机器学习算法快速解决实际业务
- 业务稳定性守门员：有赞业务对账平台的探索与实践
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
