译者序

由于译者水平有限，本文不免存在遗漏或错误之处。如有疑问，请查阅原文。

以下是译文。

• 译者序
• 1 从 DAC 到 MAC
• 设计：DAC 基础上引入专门的 admin 角色
• 例子：TCP/UDP 端口号
• 适用场景：文档/系统访问控制
• 设计
• 使用场景：普通用户的文件权限控制
• 1.1 DAC（自主访问控制）：各文件 owner 自主设置文件权限
• 1.2 MAC（强制访问控制）：（强制由）专门的 admin 设置文件权限
• 1.3 MAC 之双因素登录（two-factor login as MAC）
• 1.4 图片分享：DAC/MAC 模型比较
• 1.5 MAC 概念：限制太多，又好像没什么限制
• 2 第一次尝试：基于 RBAC/ABAC
• Windows 文件安全模型：每个文件一个 ACL
• 控制谁能访问哪个文件
• 2.1 RBAC（基于角色的访问控制）
• 2.2 ABAC（基于属性的访问控制）
• 2.3 也许你从未用过真正的 RBAC
• 2.4 存在的问题：ACL 太多，到处重复，批量修改麻烦
• 3 第二次尝试：每个 ACL 对应一个用户组
• 3.1 仍以 Windows 文件系统为例
• 3.2 存在的问题
• 4 第三次尝试：重拾被忽视的概念：object tags
• 4.1 根据 user type 而非 file type 创建 user group
• 4.2 Roles 去扁平化，增强表达力：将 ACL 定义为一组策略规则
• 4.3 关于策略规则的进一步解释
• 4.4 其他特性
• 4.5 MAC 归来
• 4.6 例子：API 访问控制
• 5 职责分离
• 5.1 根据 policy rules 和 user groups 自动生成访问权限
• 5.2 Tags 和 roles 各自的适用场景
• 5.3 小结
• 6 结束语
• 附录（译者注）：Tailscale 的安全策略模型

1 从 DAC 到 MAC

1.1 DAC（自主访问控制）：各文件 owner 自主设置文件权限

最早出现的是 DAC（Discretionary Access Control），直到今天仍然很常见。

设计

如下图所示，在 DAC 中 object owner 有权设置该 object 的访问权限。

DAC：通过授予 individuals/groups 以 read/write/execute 权限， object (file) 的创建者能完全控制该 object 的内容和权限。

1. 在 Unix 系统中，设置 file permission（“模式”，这也是 chmod change mode 的来历） 就能授予别人 读/写/执行 这个文件的权限。
2. 在 Google Doc 中，点击 share 按钮能授予权限。

使用场景：普通用户的文件权限控制

• 军方不怎么喜欢 DAC，因为这种方式中，合规性很难保证，机密文件很容易被恶意 reshare 出去。

• 但在普通用户场景中，这种方式还是很常用也很合理的。

  
  

1.2 MAC（强制访问控制）：（强制由）专门的 admin 设置文件权限

注意：不要把 MAC (mandatory access control) 与网络术语 “MAC address” 中的 MAC (media access address) 搞混了，二者没有任何关系，只是碰巧缩写相同。

设计：DAC 基础上引入专门的 admin 角色

MAC (Mandatory access control) 对 DAC 做了增强。如下图所示， 由 administrator（管理员）或 administrative rule（管理员级别的规则） 来定义 rules。

MAC：文件 owner 只能设置一个文件 type，这个 type 包含了哪些权限是由 admin 或 policy 设置的。用户能编辑文件内容，但无法修改文件权限。

因此在 MAC 模型中，一个人做某些事情的 能力是无法再分享给其他人的，从而避免了文件被 reshare 的问题。

例子：TCP/UDP 端口号

MAC 很难解释，因为在实际中很少看到它，甚至看到了之后，你都不觉得它是“访问控制”。

Wikipedia 给了一个很好的例子：TCP 或 UDP 端口号。当你占用了一个 local port 之后（假设没设置 SO_REUSEADDR）， 这台机器上的其他任何人就都无法再用这个端口号了 —— 不管他们是什么级别的特权用户。这里，端口范围不可重叠这一条件，就是强制性的（mandatory）。

之前关于 file locking 的文章中，我讨论了 advisory locks 和 mandatory locks 之间的区别：

• advisory lock：其他 apps 可以安全地读这个文件；
• mandatory lock：按照规则，其他不允许 apps 读任何内容。

• 一个带锁的房间，门口有警卫站岗，
• 出示门禁卡能进入这个房间，
• 但警卫禁止携带相机进入房间。

• 一个功能完整的（full-on）MAC 系统是很难真正实现的。
• Digital restrictions management (DRM，数字限制管理) 是 MAC 的 一种，在这种模型中，文件的接收方无法再将文件分享给别人 —— 每个 BitTorrent 用户都能体会到这种方式是如何奏效的。

1.3 MAC 之双因素登录（two-factor login as MAC）

2FA as MAC：密码可以共享，但硬件 token 不能。密码是 DAC，而硬件 token 是 MAC。

1.4 图片分享：DAC/MAC 模型比较

• 在某些服务中，任何有正确 secret URL 的人都能访问给定的图片/消息/文件，并且 任何有这个 URL 的人都能继续分享它，这是 DAC 模式。
• 在另一些服务中，单有这个 URL 还不行，必须要登录有权限查看这个文件的账号之后， 才能 reshare：这 MAC 模式。虽然某些人能通过特定的 URL 访问 这个文件，但 reshre 这个 URL 并不能让其他人看到这个文件。

当然，如果一个人能下载这个文件，然后发送副本给别人，那结果还是泄露了这个文件 。这也是为什么一些人认为 secret URL 的安全性在数学上与 MAC 是等价的，因为现在 分享 URL 已经和分享文件一样难了。但二者有一个区别：你可以关闭一个 URL 的共享，但无法追回一个已经发送出去的文件副本。

1.5 MAC 概念：限制太多，又好像没什么限制

历史上，军方中的 MAC 是围绕 multi-level security 构建的，这里的设计思想是：并非只有 admin 和 non-admin 两种用户，实际上有很多层的访问。他们最初将其设想为同心圆（“最高机密许可”、“机密许可” 等等），但最后证明 表达力太弱（too unexpressive）。

如今的访问控制更像是独立的 flags 或 subgroups。例如， SELinux 提供了对每个进程内的每个权限的细粒度控制，而传统 Unix/Linux 上只有 root 和常规用户权限的区分。但最终证明 SELinux 这套东西是噩梦般的复杂， 难以真正实用 —— 除非你在 NSA（发明 SELinux 的机构）工作，但即使 你在 NSA 也不一定会用。

最终来说，MAC 的概念证明是过于限制又过于模糊（both too restrictive and too vague）。当人们谈论 MAC 时，我们很难搞清楚他们到底指的是什么，唯一知道是：这东西 用起来非常让人抓狂。

2 第一次尝试：基于 RBAC/ABAC

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

• admin 将某些 user 放到一个 group，然后

• 可以指定将某些资源（文件、计算机等）共享给某个 group（role）；

• 系统确保只有指定的 role 能访问指定的资源；

• 文件的接收方没有 reshare 权限 —— 除非拷贝一份，否则是无法 reshare 的。

2.2 ABAC（基于属性的访问控制）

• 属性可以是位置、客户端设备平台、认证类型、用户的 http cookies 等。
• 当系统判断是否授予某个用户对某资源的访问权限时，ABAC 系统 除了检查他们的 RBAC role（group），还会检查这个人携带的各种属性。

如果你遇到过下面这种情况 —— 登录某个服务时弹出额外的图片识别认证 reCAPTCHA， 而你旁边的朋友登录时却不用 —— 就说明你遇到了 ABAC。

ABAC 很有用，因为这些额外的属性能给我们带来很多有用信息，尤其 是对于那些连接到互联网的、攻击矢量特别多的系统。但在概念上，ABAC 与 RBAC 类似，只是稍微向前演进了一点。属性的解析和认证工作是中心式的，大部分都实现 在各家的 identity provider 中。有鉴于此，接下来我们的讨论重点扔将放在 RBAC。

2.3 也许你从未用过真正的 RBAC

这里也可以拿 Unix 作为例子，但经典 Unix 文件安全与常见的安全模型不同， 它只支持单个 owner、单个 group，以及 self/group/other 文件模式。如今 Linux 也支持 facls， 这算是 RBAC，但没人知道怎么用，因此这个也不算数。

Windows 文件安全模型：每个文件一个 ACL

1. 每个文件（或目录）都有一个 users 和 groups 列表，以及
2. 每个列表中的成员可以对这个文件做什么操作。

1. User：在这个文件上执行操作的用户。在经典 RBAC 术语中，称为 subject。

2. Group 或 Role：由管理员定义的一组 user。

3. File：需要做访问控制的资源（resource）。也称为 object。subject 对 object 进行操作。

4. Permission 或 Entitlement：一条 subject-action-object（用户-动作-目标文件）规则。有时会说某个 subject 有一条 entitlement，或者说某个 object 允许某个 permission，这两种表达方式本质上是一样的，只是从不同的角度描述。

5. ACL：一个 entitlements 列表。

控制谁能访问哪个文件

每个文件都有一个 ACL（permission 列表）。

1. 找到 ACL 对应的 groups/roles，在其中添加或删除 user（称为修改 group/role 的 membership）；或者，
2. 直接修改 ACL，添加或删除 permissions。

1. 修改 group/role membership（简单），或者
2. 找到所有相关文件，逐个修改对应的 ACL（慢且易出错）。

2.4 存在的问题：ACL 太多，到处重复，批量修改麻烦

• 几乎所有系统，不管是不是 RBAC，都支持寻找文件系统中的 objects，然后修改它们的 ACL， 但配套的 object 管理系统可能做的很差。

• 在分布式系统中，这些 objects 可能分散在世界各地，放在各种不同的存储系统中，而 它们的共同之处就是都依赖你的 identity 系统。

• 如果某天发现一个 permission 给错了，就必须找到这个 permission 的所有副本并解 决之，否则就遗留了一个安全问题。但如果 objects 管理系统做得比较糟糕，这里做起 来就会很麻烦。

3 第二次尝试：每个 ACL 对应一个用户组

• 将尽量多的信息从 ACL（分散在各处）中移出，

• 将尽量多的东西移入 user groups（集中式存储，而且能审计）。

3.1 仍以 Windows 文件系统为例

经验不足的人在这里会犯的一个错误是：只创建一个名为 report 的 group，然后给 予这个 group read/write 权限。通常来说，需要文件读权限的用户，要比需要 写权限的用户更多。甚至在某些情况下，writer 和 reader 用户之间都 没有重叠（例如审计日志场景）。

3.2 存在的问题

1. 现在需要有某种形式的 IAM admin 访问控制，也就是对 用户组的增删查改做控制。
   上一节的 RBAC/ABAC 模型中无需这种功能，因为它直接修改文件的 ACL。IAM admin 管控带来的一个新问题是：
• 如果管控太松，会导致很多人都有 IAM 的访问权限，存在风险；
• 如果管控太紧，大部分都无权修改 group membership，又会使得这种模型的好处大打折扣。
2. End users 仍然能四处游荡，在需要时能修改每个 report 文件的 ACL （“Alice 真的真的需要查看这个文件”），破坏了你精心设计的系统 —— 而你自己都 无法察觉。
3. 现在需要为每个 ACL 组合创建一个 user group。
   最后会发现，公司的每个工程师都属于 975 个 group，每个 group 都需要定义 read/write 两种类型。你必须 review 每个 group 的 membership。这种方式虽然比 老的 ad-hoc 文件权限方式审计性要好，但也好不了太多。

4 第三次尝试：重拾被忽视的概念：object tags

4.1 根据 user type 而非 file type 创建 user group

4.2 Roles 去扁平化，增强表达力：将 ACL 定义为一组策略规则

• 由 HR 部门定义的 human-relevant roles，以及
• 由安全部门定义的标签（tags），以及
• 二者是如何联系到一起的。

4.3 关于策略规则的进一步解释

4.4 其他特性

4.5 MAC 归来

1. 不需要一个针对 security policy 的 global admin access control。
2. 每个 tag owner 能直接对他们的 objects 进行授权，但他们能授予哪些访问权限，是 由整体上的安全策略（the overall security policy，即 roles）控制的。

4.6 例子：API 访问控制

1. Engineering 中的任何人都可以启动一个dev-api-server node，
2. 该 node 能接受从任何 dev-api-client node 来的非加密连接（TLS 太难了！开发环境就放行非加密连接吧），但反之并不亦然。
3. 只有 Ops 中的人能启动 prod-api-server 和 prod-api-client nodes，它们只处理 https 流量，拒绝非加密 http。

5 职责分离

5.1 根据 policy rules 和 user groups 自动生成访问权限

5.2 Tags 和 roles 各自的适用场景

1. Roles 描述的是 identity system (authentication) 中的人。Roles 变化很少，通常在入职、晋升或转岗时由 HR 部门设置。

2. Object types (tags) 由 object owner 在这个 object 创建时设置。

3. Entitlements 用 (Role, Tag) 描述，由简单的程序（安全策略）来定义，由安全团队设置。

1. Accounting 部门中的财报 writer 并不关心谁是 Executive，也不关心 Executive 是否 有权查看或编辑财报。他们只需知道要给 report 文件打上 financial-report tag。
2. 安全团队并不关心哪个文件打了 financial-report（讨论一般情况下），也不关心谁是Executive。他们需要的是

• 能读、写对应的安全策略，以及确保策略生效：

• 确保 financial-report tag 只能被 Accounting 部门打，对应的文件只能被 Executives 和 Accounting 读（read only）。
3. HR 团队不知道也不关心文件或安全策略，他们只关心这周招了一个 Accounting role 的人。

5.3 小结

1. 允许 Engineers 运行 dev API servers，接受来自本机或 dev API clients 的 incoming 连接 —— 这个没问题；
2. 通常不允许创建 outgoing connections —— 这个也没问题；
3. 噢对了，Carol 的 dev API server 需要主动访问数据库服务器，只能开单独策略了 —— 问题来了。

6 结束语

1. 每个人都是一个 User (subject)。
2. 每个 user 都有一个或多个 Roles。
3. 每个 object 都有一个或多个 Tags。
4. 一条 “security policy” 定义一个将 (Role, Tag) 转换成 Entitlements 的 公式。
5. 一个执行层（enforcement layer）负责 enforce security policy，并为每个 object 生成有效 entitlements 列表（ACL）。

1. Device 或 container 的 owner 可以设置 tag；
2. 安全团队决定谁 own 哪些 tag、每个 tag 关联了哪些 permissions、tags 会授权给哪些 roles；
3. Identity/HR 团队决定哪些 users 应该属于哪些 roles。

附录（译者注）：Tailscale 的安全策略模型

ACL rules 格式：

{
  "action": "accept",  "users": [ list-of-sources... ],      # 广义的访问来源，相当于 RBAC 模型中的 users/subjects
  "ports": [ list-of-destinations... ], # 广义的访问目标，相当于 RBAC 模型中的 objects/resources}

如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享

·END·

相关阅读：
一张图看懂微服务架构路线
基于Spring Cloud的微服务架构分析
微服务等于Spring Cloud？了解微服务架构和框架
如何构建基于 DDD 领域驱动的微服务？
小团队真的适合引入SpringCloud微服务吗？
DDD兴起的原因以及与微服务的关系
微服务之间的最佳调用方式
微服务架构设计总结实践
基于 Kubernetes 的微服务项目设计与实现
微服务架构-设计总结
为什么微服务一定要有网关？
主流微服务全链路监控系统之战
微服务架构实施原理详解
微服务的简介和技术栈
微服务场景下的数据一致性解决方案
设计一个容错的微服务架构