对云环境下访问控制系统的思考

欢迎访问网易云社区，了解更多网易技术产品运营经验。  

 

企业上云首当其冲的就是要考量安全性的问题。安全性范围很广，狭义上可以指云服务商的各种安全服务，如 DDoS 防护、其他安全性产品等，而广义上来说，安全性不仅包括基础设施的安全和稳定，如虚拟机的高可用、RDS 的高可靠等，也包括应用层面的安全性，如 WAF、证书服务、加密服务等等，还包括了因为企业本身的 IT 架构/研发架构的复杂性带来的资源管控方面的安全性需求等。可以说，谁解决好企业的安全性诉求，谁就会在云服务这片红海中占据很大的优势。

从广义上来理解，访问控制其实是安全中的一块，也是十分重要的一块。有些云计算提供商没有将其划归到安全的范围，可能是还没有意识到访问控制的重要性。

AWS 中访问控制对应的产品是 IAM，这可以说是云计算厂商中做的最早也最为完善的一个。AWS 对 IAM 的类别描述里有一个词我觉得形容该产品最为合适——“合规性“。其实，访问控制就是满足企业用户对于合规性的需求，说白了就是规范企业用户对云计算资源的访问。

本文就从访问控制的定义出发，介绍下传统的访问控制模型，再针对云服务场景中访问控制面临的特殊挑战，讲解下目前云服务厂商访问控制系统的设计原理。

什么是访问控制

维基百科关于访问控制的定义是：

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

这个定义中有这么几个关键点：

○ 人
○ 某项资源
○ 允许/禁止
○ 能力

这个定义虽略显简单，但其实已勾勒出了访问控制系统的大致形态。

人：访问控制的主体是人，代表其主要的使用群体是云服务商的用户，即这个系统是一个面向用户的系统。

某项资源：资源是访问控制的客体，某项这个限定词则表明资源的具体形式是未知的。

允许/禁止：这是访问控制对外提供服务的最为直观的表现形式，用一个更为专业的名称来描述的话就是 “鉴权”。

能力：为什么把能力专门拿出来作为一个关键点，是因为这是理论和实践间一个关键的区分点之一。访问控制的理论为我们设计对应的系统和产品指明了方向，但在实际的生产环境中使用时还是会遇到各种各样的问题。我们需要特别注意，访问控制系统作为一个通用的公共服务，它需要提供的是一种能力，而不能仅针对特定环境和产品，否则只是沦为某个特定的专家系统。

维基百科关于【访问控制】的定义还隐藏了一个关键点，那就是 “动作”。这里的动作（也可称之为操作）可以理解为具体系统所开放的能力，或者用户可以对系统执行的操作。例如，RDS 产品需要开放 createDataBase\listDataBase\deleteDatabase 等动作， NOS（网易云对象存储）需要开放 listBucket\createBucket\listObject\putObject 等动作等。就算脱离云计算的环境，动作也是访问控制中不可缺少的要素之一，因为任何给人使用的产品都会伴随与人的交互，而这些交互的细粒度表现就是这些动作。

传统的访问控制模型

在访问控制系统的设计中，有两种设计模式十分重要，也是得到广泛应用的，那就是访问控制列表（ACL）和基于角色的访问控制（RBAC）。

1. 访问控制列表（ACL）

访问控制列表是早期的一种访问控制技术，其原理十分简单，就是记录哪些用户对这个资源能进行哪些操作，有类似如下的二维表维护在文件中：

这种访问控制的方式好处显而易见，就是简单直观，易维护。这种设计在操作系统、路由器、交换机和工业控制系统中都得到了广泛的使用。

但是，ACL 的缺点也是显而易见的，那就是当用户、资源和操作组建增长时，维护这张表的代价会异常庞大。另外，这种设计模式将用户对资源的控制权限直接绑定，十分死板，灵活度不够，无法满足云环境下动态资源授权的需求。

2. 基于角色的访问控制（RBAC）

基于角色的访问控制将用户按其属性进行分类，构建出一个个具体的角色，通过将权限授权角色使不同的用户获取相应的权限。RBAC 非常适合现实的业务环境，尤其是企业用户，其资源的使用者不一定是资源的拥有者。在云环境中更是如此，可能使用 RDS 的人是公司的开发或者 PE，而 RDS 的归属者是对应的企业。

RBAC 从访问控制的主体的角度出发，很好地适应了企业的组织架构，同时也将用户和权限分离开，用户只需要通过扮演不同的角色就能获得对应的权限，这种方式解决了云环境下动态授权的权限需求。

那是否 RBAC 就能解决我们所有的问题了？显然还没有，现实的问题往往是复杂的。RBAC 将人和权限分离的方法确实解决了一部分灵活性的问题，但是也增加了使用成本，同时它对细粒度的权限控制没有给出很好的应对之法。

云服务中访问控制系统设计需考虑的问题

现在我们知道主流的访问控制模型一般是怎么做的了，那么如何应用在云环境中呢？我觉得在云环境下的访问控制系统主要需要考虑以下几个问题：

1. 资源标识的灵活性

访问控制系统的立项一般来讲会晚于云计算中的其他产品，因为它本身属于支撑产品。而随着其他产品形态组建完善，如何很好地描述各个产品的资源就成了一件令人头疼的事情。

在一些 IaaS 的产品形态中，很大一部分是以实例 (instance) 的方式来提供服务的；而在某些 PaaS 的产品形态中，有些是实例的方式来提供服务，而又有一些有着很强的特殊性，比如上文提到的 NOS，它们的资源描述是需要以树形方式来表达的；SaaS 产品用统一的访问控制系统来管理一般不太可能，因为每个 Software 的产品形态和使用方式千差万别，你很难去做到统一。

而在对访问控制系统的设计过程中我也发现了一个很有趣的现象，当你考虑的产品越接近应用层面（上层服务），访问控制系统就越接近专家系统。也就是说越上层的服务它的特殊性越强，所以通用性越差，只能做成专家系统。

2. 细粒度的权限控制

访问控制系统有一个比较困难的点，那就是细粒度的权限控制。这一点在访问控制模型中你找不到答案，里面只在比较宏观的层面讨论了人和权限的关系。但细粒度的权限控制需求在实际的业务场景中又切实存在着。比如一个企业有若干台虚拟机，有一些虚拟机用作 webserver，而有一些虚拟机用作数据库，还有一些作为中间件服务器，比如 Zookeeper 等等，使用这些虚拟机的人各不相同，所以他们能看到并操作的虚拟机也应该得到严格的监管，否则可能会引起安全事故。

细粒度的权限控制关键点在于 “多细”，过于细致的控制会导致你的系统复杂度变高，不利于系统的可维护性。我的建议是只做到实例级别，而这其中也有一个例外，那就是对象存储服务。

要做得有 “多细” 很大一部分取决于（第一点中）你资源标识的方式，如果你的资源描述方式合理，那么更加细粒度地访问控制并不会增加你系统的复杂度，这个我在下文中会提到。

3. 身份的多样性

云计算提供商要服务一个大客户，满足其业务架构只是其一，还有一个十分重要的条件就是满足其组织架构的实际需要。大企业绝对有实力也有能力解决其本身的业务架构，其实上不上云更多的是战略性的考虑，他们会更看重云服务的稳定性、安全性和可维护性。其本身的组织架构十分复杂，要想让其没有阻力地上云，解决企业员工的身份问题首当其冲。所以现在主流的云厂商都会提供多种身份的认定方式，例如：子账号、组和角色。

4. 权限的描述方式

权限的描述方式也是十分重要的一点，可以说这个点设计的好坏决定了你后期是悠然地应对业务方的接入还是每天火急火燎地和各个业务方定协议定接口。

我们知道所有需要访问控制的云产品必然有其支持的动作（Action），每个产品资源 (Resource) 的描述方式也各不相同，同时，允许（Allow）还是禁止 (Deny) 针对某个资源的操作也是需要明确给出来的。这三个点构成了权限描述的三个要素。

如果在前期的设计中没有充分思考这个问题，那么恭喜你，你很有可能给自己埋了一个深坑。你很有可能设计几张大表，来表示各个业务方支持的动作，资源以及用户和他们的关系。出现这样的设计是因为没有真正理解访问控制系统的业务领域。当你在设计这几张表的时候其实意味着访问控制系统在 “理解” 各个产品的功能，这对一个通用的访问控制系统是致命的。

访问控制系统作为一个底层/共享的通用系统，对外输出的只能是能力，而不是去理解各个产品它们自己的业务领域。说到这里，我还是推荐所有的技术人员有必要学习下 DDD 的理论，就算不用自己写代码，系统性地学习其战略模式也会让你收益很多。

5. 动态的授权体系

这一点相比于以上的 4 点来说要简单，这是因为如果你的访问控制系统已经很好地解决了上面的挑战，那么你也就自然而然地获得了动态的授权体系。

之所以是动态的，是因为云环境下用户和权限的关系往往不是一成不变的。用户在某个时刻希望获得 A 授权，而在另外一个时刻又希望获得 B 授权，而且有时授权还带有时效性，当过了截至时间授权也就自动失效了。这种动态性的需求是真实存在的，但我认为满足这个需求仰赖于对前 4 点挑战的解决，如果把前面的设计做好了，那么系统就自然满足了动态性的需求，这是一个水到渠成的事情。

云服务商如何设计访问控制系统

AWS 做访问控制（IAM） 的方法相对来说较为合理。IAM 将用户身份划归为子用户、组和角色，基本上这三种身份标识可以满足身份多样性的要求。IAM 关于权限描述的方式令人耳目一新，它使用领域专用（DSL）语言来描述权限，具体的形式如下：

{
“Version”: “2012-10-17”,
“Statement”: {
“Effect”: “Allow”,
“Action”: “s3:ListBucket”,
“Resource”: “arn:aws:s3:::example_bucket”
}
}

云环境下的访问控制系统最令人头疼的问题就是资源和权限的描述方式，这种极致的灵活性很难通过设计表格来获得。因为任何的以表为中心的设计方式都会映射到某个具体的领域模型上，又因为各个业务的权限控制各不相同，用 DSL 来将访问控制和具体的权限理解分隔开是最为合适的方式。

通过一套特定的 DSL 语法来描述权限，访问控制系统可以获得极大的灵活性，同时也不需要理解具体的权限，对权限的理解还是由各个业务方自己控制，这样系统就获得了最大程度的解耦。访问控制系统只用维护这套 DSL 语法就可以获得无限的扩展性。

实际上，用 DSL 语法来描述权限也不是 IAM 首创，早在 2001 年就出现了响应的规范——XACML（可扩展的访问控制高标识语言），该规范现在已经发展到 3.0 了。其大致的鉴权流程如下图所示，如果对其原理感兴趣的同学可以查看对应的资料。

总而言之，云环境下的访问控制系统面临的挑战很多，充分理解访问控制的原理有助于理解代码背后的意义，让我们的系统设计不至于走偏。基于 DSL 的访问控制模型已经成为业界的主流，但各个云计算厂商自身的业务场景和面向的目标人群又各有不同，如何制定适应自身环境的 DSL 成为了一个关键。

网易云为您提供容器服务，欢迎点击免费试用。  

以上就是我对云环境下访问控制系统的一点理解，如有不严谨的地方，还望指正。