Back

现代应用如何处理角色和权限

现代应用如何处理角色和权限

您的用户可以查看文档。但他们能分享吗?他们可以与任何人分享,还是只能在组织内部分享?他们能撤销已授予的访问权限吗?这些问题揭示了为什么传统的基于角色的访问控制在现代应用中会失效。

当应用程序较为简单时,像”管理员”、“编辑者”和”查看者”这样的静态角色还能胜任。但如今的协作型、多租户 SaaS 产品需要更灵活的机制。本文将解释现代授权模式如何解决这些挑战,以及为什么业界已经从仅依赖角色的思维转向细粒度授权。

核心要点

  • 传统 RBAC 难以处理动态的、基于关系的权限,在复杂应用中会导致角色爆炸
  • ReBAC 通过实体关系确定访问权限,使分享和协作成为一等公民概念
  • ABAC 基于用户、资源和上下文属性评估访问权限,适用于依赖上下文的规则
  • 大多数生产系统将 RBAC 用于广泛分类,将 ReBAC 用于资源级权限
  • 策略即代码(Policy-as-code)方法使授权逻辑可测试、可审计且版本可控

为什么传统 RBAC 不够用

基于角色的访问控制(RBAC)通过角色分配权限。用户获得”编辑者”角色,该角色授予一组预定义的权限。简单直观。

问题随着应用增长而出现。考虑一个项目管理工具,用户需要针对每个项目、每个工作空间和每种文档类型拥有不同的访问级别。您开始创建像”项目-A-编辑者”和”工作空间-B-管理员”这样的角色。这种角色爆炸使系统变得难以管理。

RBAC 在处理基于关系的问题时也力不从心。“这个用户能编辑这个文档吗?”取决于他们是否拥有它、是否有人与他们分享了它,或者他们是否属于有访问权限的团队。静态角色无法优雅地表达这些条件。

现代授权模式

基于关系的访问控制(ReBAC)

ReBAC 通过实体之间的关系确定访问权限。它不是问”这个用户有编辑者角色吗?“,而是问”这个用户与这个文档有编辑者关系吗?”

Google 的 Zanzibar 系统在大规模场景下开创了这种方法。当您分享 Google 文档时,您就在创建一个关系。系统随后遍历这些关系来回答权限问题。像 OpenFGASpiceDBPermify 这样的工具为任何规模的应用实现了受 Zanzibar 启发的模型。

ReBAC 自然地处理协作场景。分享、团队成员资格和组织层级结构成为一等公民概念,而不是笨拙的角色变通方案。

基于属性的访问控制(ABAC)

ABAC 基于用户、资源和上下文的属性评估访问权限。一个策略可能声明:“如果用户的部门与文档的部门匹配,且请求发生在工作时间内,则用户可以访问文档。”

这种模型擅长处理依赖上下文的规则。医疗应用使用 ABAC 来执行 HIPAA 要求——访问取决于患者-医生关系、数据敏感性和访问上下文。

RBAC vs ReBAC:何时使用各自

RBAC 仍然适用于具有清晰、静态权限边界的应用。具有明确定义用户类型的内部工具能从其简单性中受益。

当权限取决于资源所有权、分享或组织结构时,ReBAC 更合适。任何具有”分享”功能或多租户的应用都应该考虑 ReBAC。

大多数生产系统结合使用两者。RBAC 处理广泛分类(管理员 vs. 普通用户),而 ReBAC 管理资源级权限。

Web 应用中访问控制的架构模式

将身份认证与授权分离

身份认证回答”这个用户是谁?”授权回答”他们能做什么?”现代架构将这些视为独立关注点,为每个关注点配备专用服务。

您的身份提供商处理身份认证。一个独立的授权服务——无论是内部构建还是托管——处理权限决策。这种分离允许每个系统独立演进。

策略即代码

现代授权模式倾向于将规则表达为代码,而不是数据库配置。策略即代码意味着您的授权逻辑存在于版本控制中,在拉取请求中得到审查,并通过标准流水线部署。

Open Policy Agent (OPA) 使用 Rego 进行策略定义。由 AWS 开发的 Cedar 提供了另一种策略语言。这些工具使授权逻辑可测试和可审计。

集中式策略,分布式执行

可扩展的模式是:集中定义策略,在每个服务处执行。您的策略引擎维护规则。每个微服务向引擎查询权限决策,通常会缓存结果以提高性能。

这种架构在保持服务间授权一致性的同时,避免了单点故障。

前端影响

后端始终是所有权限决策的真实来源。永远不要信任前端的安全性。

话虽如此,前端需要权限信息来提供良好的用户体验。功能门控——隐藏用户无法点击的按钮、禁用他们无法提交的表单——需要在客户端了解权限。模式很简单:使用权限检查(例如,“这个用户能执行这个操作吗?”)进行 UI 决策,但始终在服务器端验证。

CASL 这样的库帮助管理客户端权限逻辑,同时保持实际执行在服务器端。

结论

细粒度授权不是实验性的——这就是现代应用的工作方式。Google、GitHub 和 Notion 都使用基于关系的模型。各种规模的公司都在使用策略引擎来支持授权。

首先识别您当前 RBAC 的困难之处。如果您正在为每个权限组合创建角色,或者分享和协作感觉像是附加功能,那么现代授权模式将简化您的系统,同时使其更强大。

从”这个用户有什么角色?”转向”这个用户与这个资源有什么关系?”改变了您对权限的思考方式。这是一个更好的心智模型,更符合用户实际与现代应用交互的方式。

常见问题

RBAC 通过静态角色(如管理员或编辑者)分配权限。ReBAC 通过用户和资源之间的关系确定访问权限。RBAC 询问'这个用户有编辑者角色吗',而 ReBAC 询问'这个用户与这个特定文档有编辑者关系吗'。ReBAC 更自然地处理动态分享和协作。

可以,大多数生产系统结合使用这两种方法。RBAC 通常处理广泛的权限类别,例如区分管理员和普通用户。ReBAC 管理资源级权限,如文档分享和团队访问。这种混合方法为全局权限提供简单性,为资源特定的访问控制提供灵活性。

身份认证识别用户是谁,而授权确定他们能做什么。分离这些关注点允许每个系统独立演进。您的身份提供商处理登录和身份验证。专用的授权服务管理权限决策。这种分离提高了可维护性,并允许您在不影响另一个组件的情况下交换或升级任一组件。

始终在后端执行权限。服务器是所有访问控制决策的真实来源。但是,前端需要权限数据来提供良好的用户体验,例如隐藏不可用的按钮或禁用受限制的表单。在页面加载时获取有效权限用于 UI 决策,但在服务器端验证每个操作。

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.

OpenReplay