学习阿里云的访问控制策略

本文涉及的产品
访问控制,不限时长
简介: 我们使用访问控制策略来描述如何保护系统中的资源, 准许执行哪些操作, 禁止执行哪些操作. 本文从常见的访问控制策略入手, 逐步了解阿里云平台的访问控制策略表达方法.

学习阿里云的访问控制

我们使用访问控制策略来描述如何保护系统中的资源, 准许执行哪些操作, 禁止执行哪些操作. 本文从常见的访问控制策略入手, 逐步了解阿里云平台的访问控制策略表达方法.

常见的访问控制

不同的系统, 根据系统所管理的资源及所支持的操作的特性, 采取了不同的访问控制策略.

Linux文件访问控制

熟悉Linux的朋友都知道文件的访问控制,可以给用户、组及其他用户不同的读、写、执行权限。

$ ls -l

total 0

-rw-r--r--  1 gang  wheel  0 May 18 08:47 file1.txt

-rw-r--r--  1 gang  wheel  0 May 18 08:47 file2.txt

-rwxr-xr-x  1 gang  wheel  0 May 18 08:47 file3.sh

-rwxr--r--  1 gang  wheel  0 May 18 08:47 file4

对file1.txt和file2.txt,用户gang 有读写权限;其他用户有只读权限;

对file3.sh,用户gang有读写和执行权限;其他用户有读和执行的权限;

对于file4,用户gang有读写和执行权限;其他用户有只读权限。

SQL数据库访问控制

熟悉SQL的朋友都知道数据库的访问控制,可以给不同的数据库对象以不同的操作权限。

GRANT SELECT, INSERT, UPDATE, DELETE on <DB>.<TABLE> to <User>@<Host>;

上述语句授予了来自Host的用户User,对于数据库DB中的表Table的增删改查操作权限。

云平台访问控制

相比单个文件系统和单个数据库,云平台中的资源有以下特征

  1. 资源分散在不同区域的数据中心中。
  2. 资源种类更多。比如ECS虚拟机,RDB数据库,NoSQL数据库,FaaS等。
  3. 不同类型的资源,可以执行的操作不同。

第一个特征和第二个决定了我们在定位资源时,要比Linux文件系统及数据库表更复杂。从逻辑上来说,应该包括区域,服务类型,租户和服务实例。包含租户,是因为云平台都是多租户隔离的,服务实例运行在租户(逻辑上)隔离的环境中。
第三个特征决定了我们在授予用户操作权限时,可授权的操作是由服务类型决定的。

假如我们有以下的授权需求:
"允许租户A(TenantA)的用户User1重启(Reboot)该租户位于北京区域(cn-beijing)的ECS实例Instance-01"

如果用类似SQL的语法来表达如下:

GRANT ECS_Reboot on 'cn-beijing'.'ECS'.'TenantA'.'Instance-01' to 'User1'@'TenantA'

云平台的访问控制服务所采纳的语法是基于JSON格式的. JSON格式对于互联网开发者而言更常用 -- 绝大部分的互联网API的请求和响应格式都是JSON.

我们把上述SQL格式的授权, 翻译为JSON格式的:

{
"Resources": ["'cn-beijing'.'ECS'.'TenantA'.'Instance-01'" ],
"Actions": [ "ECS_Reboot"],
"Users": ["User1@TenantA"]
}

一方面, 同样的访问控制策略, 既可以赋给用户A, 也可以赋给用户B;  另一方面, 用户A可能的权限可能同时由多个访问控制策略所共同决定. 因此, 我们应该把访问控制策略独立出来.

访问控制策略:

{
"Id": "Policy-1",
"Resources": ["cn-beijing.ECS.TenantA.Instance-01" ], 
"Actions": [ "ECS_Reboot"]
},
{
"Id": "Policy-2",
"Resources": ["cn-shanghai.OSS.TenantA.MyFiles"],
"Actions": ["OSS_View", "OSS_Create"]
}

我们称用户被授予访问控制策略的过程叫做用户与访问控制策略的绑定.

{
"Binding": {
   "User": "User1@TenantA",
   "Policies": ["Policy-1", "Policy-2"]
}
}

本文的重点是访问控制策略. 因此, 让我们把绑定的事情先放一放.

首先, 我们上面只说了正向的"准许"的访问权限, 那么我们能不能反向"拒绝"呢? 假设某个服务实例S的大部分操作, 我们都想赋给用户U, 只有很少的操作(X, Y)不能给他(她). 这种情况下, 与其列出准许的操作, 不如列出拒绝的操作.

{
 "Id": "Policy-3",
"Statements": [
  { 
    "Effect": "Allow",
    "Resources" : ["S"],
    "Actions" : [ "*" ]
  },
  { 
    "Effect": "Deny",
    "Resources": ["S"],
    "Actions": ["X", "Y"]
  } 
]
}

由于默认情况下是没有授权的, 因此, 我们需要增加一个表示允许全部授权的规则, 然后再加上拒绝的规则. 这也意味着, "拒绝"规则的效力是高于"准许"规则的. 由于我们申明有了两(多)个规则, 因此, 增加一个"Statements"数组来表达它们.

其次, 作为一个平台, 我们将来可能会引入更多的策略表达能力, 因此, 我们需要引入策略规则版本的概念.

{
 "Id": "Policy-3",
 "Version": "1.0",
"Statements": [
  { 
    "Effect": "Allow",
    "Resources" : ["S"],
    "Actions" : [ "*" ]
  },
  { 
    "Effect": "Deny",
    "Resources": ["S"],
    "Actions": ["X", "Y"]
  } 
]
}

阿里云平台的访问控制

让我们拿一个真正的阿里云访问控制策略的例子来对比一下上面我们自己假想的访问控制策略.

{
"Version": "1", 
"Statement": [
  { 
    "Effect": "Allow",
    "Resource" : ["acs:ecs:*:*:instance/inst-001", 
"acs:ecs:*:*:instance/inst-002"],
    "Action" : [ "ecs:*" ]
  },
  { 
    "Effect": "Deny",
    "Resource": ["acs:ecs:*:*:instance/inst-001",
"acs:ecs:*:*:instance/inst-002"],
    "Action": ["ecs:Delete*", "ecs:Modify*", "ecs:Re*"]
  } 
]
}

差别在哪里?

  1. 阿里云采用了单数表达法.  我们前面使用的是"Statements", "Resources", "Actions", 在阿里云中实际上是"Statement", "Resource", "Action".
  2. 阿里云中的全局资源名称中,各个部分之间的分隔符是冒号":"而不是点".", 而且统一使用了小写的名称, 它的一般写法是"acs:<service-name>:<region>:<account>:<instance>". 其中, acs代表阿里云; service-name代表阿里云所提供的云服务的名字(英文代码), region表示数据中心区域(英文代码); account代表我们的账号ID; instance代表服务实例的ID.
  3. 服务的全局操作名称也是使用了冒号来分割服务名称和操作名称, 它的一般写法是"<service-name>:<API name>|<API name starts with (*) >"
  4. 参考阿里云的帮助文档, 我们可以发现阿里云的访问策略语法功能更丰富.

练习

设想以下场景:

我们团队有两个项目P1和P2,项目人员有产品工程师,开发工程师,测试工程师,运维工程师。其中项目的产品工程师是只负责各自的项目,开发工程师,测试工程师和运维工程师则同时参与两个项目中。我们为每个项目分别申请了一台测试机器,两台生产机器以及一个测试RDB数据库和一个高可用生产RDB数据库。测试环境的机器,开发工程师和开发工程师都可以查看和重启。生产环境的机器,只有运维工程师可以查看和重启。产品工程师只能查看所负责项目. 这个需求怎么用阿里云的访问控制策略实现?

项目P1:

P1-Test-App1, 用于测试环境的应用程序节点
P1-Test-RDB1, 用于测试环境的RDB数据库
P1-Prod-App1, P1-Prod-App2 用于生产环境的应用程序节点
P1-Prod-RDB1 用于生产环境的高可用版本的RDB数据库
项目P2:

P2-Test-App1, 用于测试环境的应用程序节点
P2-Test-RDB1, 用于测试环境的RDB数据库
P2-Prod-App1, P2-Prod-App2 用于生产环境的应用程序节点
P2-Prod-RDB1 用于生产环境的高可用版本的RDB数据库

参考文档

阿里云访问控制策略. 语法结构: https://help.aliyun.com/document_detail/28664.html; 基本元素: https://help.aliyun.com/document_detail/28663.html;  权限规则: https://help.aliyun.com/document_detail/28665.html
阿里云ECS鉴权: https://help.aliyun.com/document_detail/25494.html
阿里云RDB鉴权: https://help.aliyun.com/document_detail/26307.html

相关实践学习
消息队列+Serverless+Tablestore:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
1天前
|
云安全 SQL 安全
阿里云云盾学习
【8月更文挑战第15天】
7 2
|
1天前
|
运维 Java Devops
阿里云云效操作报错合集之访问知识库时出现访问异常,是什么原因
本合集将整理呈现用户在使用过程中遇到的报错及其对应的解决办法,包括但不限于账户权限设置错误、项目配置不正确、代码提交冲突、构建任务执行失败、测试环境异常、需求流转阻塞等问题。阿里云云效是一站式企业级研发协同和DevOps平台,为企业提供从需求规划、开发、测试、发布到运维、运营的全流程端到端服务和工具支撑,致力于提升企业的研发效能和创新能力。
|
3天前
|
安全 数据库 数据安全/隐私保护
|
3天前
|
安全 数据安全/隐私保护 开发者
|
3天前
|
安全 数据安全/隐私保护
|
5天前
|
安全 Linux 数据库
|
6天前
|
SQL 监控 Java
阿里云ads的学习教程
【8月更文挑战第10天】
23 1
|
13天前
|
SQL Java 数据库连接
阿里云ads学习
【8月更文第6天】
28 3
|
21天前
|
关系型数据库 Serverless 数据库
函数计算产品使用问题之如何访问阿里云的RDS
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
1天前
|
存储 监控 安全
Linux存储安全:访问控制的实践与策略
【8月更文挑战第18天】Linux存储安全:访问控制的实践与策略
12 0

热门文章

最新文章