第2章 RMC核心概念

2. RMC核心概念：资源、主体、权限、安全域

好，咱们正式开始聊RMC的核心概念。这四个词——资源、主体、权限、安全域——是整个权限体系的基石。你想想看，任何一个系统，不管多复杂，归根结底就是：谁（主体）能对什么（资源）做什么（权限），在什么范围内（安全域）。

我个人习惯把这四个概念比作一个公司的运作：
资源就是公司的资产，比如文件柜、会议室；
主体就是员工，比如你、我、老板；
权限就是门禁卡上写着的“允许进入哪些房间”；
安全域就是不同的办公区域，比如研发区、财务区、公共区。

嗯，这样一讲是不是就清晰多了？下面咱们逐个拆解。

2.1 资源（Resource）—— 你要保护的东西

资源，说白了就是系统中一切需要被保护的对象。它可以是一份文档、一个API接口、一台服务器、甚至是一条数据库记录。

我在项目中遇到过最典型的例子：一个电商系统的订单数据。订单本身是资源，订单里的金额、收货地址、手机号，这些字段也是资源。你想想看，如果权限只控制到“能不能看订单”，那太粗了。实际场景里，客服只能看订单状态，财务才能看金额，仓库只能看收货地址。

所以，资源是有粒度的。RMC里，资源可以是一个树形结构：

// 资源定义示例
{
  "resourceId": "order:12345",
  "type": "order",
  "attributes": {
    "status": "shipped",
    "amount": 299.00,
    "phone": "138****1234"
  },
  "parentResource": "order:list"
}

这里要注意：资源不是孤立的。一个订单属于某个用户，属于某个店铺，这些关系本身就是资源的一部分。我建议在设计资源模型时，先把资源的层级关系画清楚，否则后面权限配置会乱成一锅粥。

  核心要点：资源是权限控制的目标。定义资源时，粒度要适中——太粗则控制力不足，太细则管理成本爆炸。

2.2 主体（Master）—— 谁在操作

主体，就是发起操作的那个“谁”。可以是用户、可以是服务账号、可以是第三方应用。在RMC里，主体不一定是人。

我记得有一次帮一个金融客户做权限设计，他们有个自动化交易系统。这个系统本身就是一个主体，它需要权限去读取行情数据、提交订单。你不能说“系统没有权限”，系统也是主体。

主体通常有这些属性：

身份标识：用户ID、服务ID、角色ID
所属组织：部门、项目组、租户
信任等级：比如内部员工 vs 外部合作方

这里有个坑：主体可以代表多个角色。比如一个人既是管理员又是普通用户，那他的权限就是两个角色的并集。我曾经见过一个系统，因为没处理好角色叠加，导致一个普通员工意外获得了管理员权限……嗯，那场面，挺刺激的。

我的建议：主体设计时，一定要考虑“角色继承”和“角色互斥”。比如“财务”和“审计”这两个角色，通常不应该由同一个人同时拥有。

2.3 权限（Capability）—— 能做什么

权限，就是主体对资源的具体操作能力。在RMC里，权限不是简单的“读/写/删”，而是细粒度的操作描述。

举个例子：一个文档管理系统里，权限可以是这样：

权限名称	操作	资源范围	条件
查看订单	read	order:*	仅限本人订单
修改订单	update	order:*	仅限待支付状态
删除订单	delete	order:*	仅限管理员

你看，同样是“订单”这个资源，不同的权限可以附加不同的条件。这就是RMC的灵活之处。权限不是死的，它是可编程的。

我习惯把权限定义成这样的结构：

{
  "capability": "order:update",
  "effect": "allow",
  "condition": {
    "owner": "$currentUser",
    "status": "pending"
  }
}

说白了，权限就是一条规则：在什么条件下，允许或禁止某个操作。

注意：权限不要设计得太复杂。我曾经见过一个系统，权限条件里嵌套了五层逻辑，结果每次权限判断都要跑几百毫秒。性能扛不住啊。保持简单，能用就行。

2.4 安全域（Security Domain）—— 边界在哪里

安全域，是RMC里最容易忽略但又最重要的概念。它定义了权限生效的范围。

举个例子：一个跨国企业，中国区的管理员只能管理中国区的用户和资源，不能碰欧洲区的数据。这个“中国区”就是一个安全域。

安全域可以是：

物理域：不同的机房、不同的网络段
逻辑域：不同的租户、不同的项目、不同的环境（开发/测试/生产）
时间域：某些权限只在特定时间段内有效

我遇到过最典型的场景：一个SaaS平台，每个客户是一个独立的租户。租户A的管理员不能看到租户B的任何数据。这就是安全域在起作用。

安全域的设计原则：

隔离性：不同域之间的数据默认不可见
可嵌套：一个域可以包含子域，比如“中国区”下面有“北京分公司”
可继承：子域默认继承父域的权限策略，但可以覆盖

  一句话总结：安全域就是权限的“围墙”。没有围墙，权限就失去了边界，系统就乱了。

2.5 四者的关系 —— 一张图说清楚

好了，四个概念都讲完了。它们之间的关系，我用一张SVG图来展示：

这张图你看懂了吗？
主体拥有权限，权限定义了能对资源做什么操作，而这一切都发生在安全域的边界内。四者缺一不可。

2.6 避坑指南

最后，分享几个我踩过的坑：

坑一：把主体和用户划等号。 我曾经设计过一个系统，只考虑了“人”作为主体，结果后来要接入第三方API，发现没法给“服务”授权。改起来那叫一个痛苦。
坑二：权限粒度太粗。 一开始图省事，只定义了“读/写/管理”三个权限。后来业务方说“能不能让客服只能看订单，不能改金额？”……嗯，只能重构。
坑三：忘了安全域。 一个多租户系统，没做安全域隔离。结果租户A的管理员，通过修改请求参数，看到了租户B的数据。这属于严重的安全事故。

我的经验：设计阶段多花一天把这四个概念理清楚，后面能省一个月的改bug时间。真的，不骗你。

好了，这一章就到这里。四个概念的关系，你可以在实际项目中慢慢体会。下一章咱们聊聊RMC的架构设计，看看这些概念怎么落地到代码里。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

2. RMC核心概念：资源、主体、权限、安全域

2.1 资源（Resource）—— 你要保护的东西

2.2 主体（Master）—— 谁在操作

2.3 权限（Capability）—— 能做什么

2.4 安全域（Security Domain）—— 边界在哪里

2.5 四者的关系 —— 一张图说清楚

2.6 避坑指南