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

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

学习阿里云的访问控制

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

常见的访问控制

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

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:实现高弹性的电商订单系统
基于消息队列以及函数计算,快速部署一个高弹性的商品订单系统,能够应对抢购场景下的高并发情况。
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
3月前
|
Apache 数据安全/隐私保护
HAProxy的高级配置选项-ACL篇之基于策略的访问控制
这篇文章介绍了HAProxy的高级配置选项,特别是如何使用ACL(访问控制列表)进行基于策略的访问控制,通过实战案例展示了如何配置HAProxy以允许或拒绝来自特定源地址的访问。
73 6
HAProxy的高级配置选项-ACL篇之基于策略的访问控制
|
4月前
|
安全 数据库 数据安全/隐私保护
|
4月前
|
安全 数据安全/隐私保护 开发者
|
4月前
|
安全 Linux 数据库
|
4月前
|
安全 数据安全/隐私保护
|
4月前
|
存储 监控 安全
Linux存储安全:访问控制的实践与策略
【8月更文挑战第18天】Linux存储安全:访问控制的实践与策略
71 0
|
6月前
|
弹性计算 安全 Shell
阿里云ECS安全加固:从访问控制到数据保护的全方位策略
【6月更文挑战第29天】阿里云ECS安全聚焦访问控制、系统加固及数据保护。安全组限定IP和端口访问,密钥对增强SSH登录安全;定期更新补丁,使用防病毒工具;数据备份与加密确保数据安全。多维度策略保障业务安全。
172 15
|
5月前
|
安全 Java 数据库
如何设计返利App的用户权限与访问控制策略
如何设计返利App的用户权限与访问控制策略
|
5月前
|
监控 安全 Java
Java中的权限管理与访问控制策略
Java中的权限管理与访问控制策略
|
7月前
|
弹性计算 安全 Shell
【阿里云弹性计算】阿里云ECS安全加固:从访问控制到数据保护的全方位策略
【5月更文挑战第22天】本文详述了阿里云ECS的安全加固策略,包括访问控制(如安全组设置和密钥对管理)、系统安全加固(如安全补丁更新和防病毒措施)以及数据保护(如数据备份、恢复和加密)。通过这些措施,用户可增强ECS安全性,保障业务安全稳定运行。
151 0