

基于角色的访问控制(RBAC)存在的问题
source link: https://cloudnative.to/blog/problem-with-rbac/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

基于角色的访问控制(RBAC)存在的问题
本文主要讲述了 RBAC 面临的主要挑战。
直到最近,最流行的授权方法是基于角色的访问控制(RBAC)。这种解决方案涉及到创建一套角色,定义组织内所有的工作描述和功能,然后给用户分配角色,决定他们可以访问的内容(例如,文件、网络、应用程序、网页上的一个字段),以及他们可以执行的操作。
当使用 RBAC 时,系统管理员可以控制用户可以对特定的 IT 资源做什么,以及他们可以访问哪些区域。它的实现很简单,因为只有三个基本原则需要牢记,角色是基于 “角色分配”、“角色授权 “和 “权限授权 “的。然而,RBAC 并非没有问题和局限性。其中一个主要问题是,它不是一个自动的过程,这意味着它需要进行艰苦的管理,并且经常涉及大量的人工干预。
例如,假设你的组织结构图已经和你的员工名单以及他们的头衔一起最终确定,你已经准备好推出你的 RBAC 计划。你已经把所有的角色摆在你面前,你很自信,他们都有明确的定义,并且有正确的汇报线和控制范围。突然间,市场部副总裁提到,他们部门里有一些人需要访问某些资源、共享文件夹和专门的应用程序,而这些资源和应用程序只有其他部门的角色才能使用。你不能对副总裁说 “不”,所以你检查已有的映射,并试图找到一组额外的符合要求的角色。但这并不容易,因为没有完全匹配的角色。那么你要做什么呢?创建一个额外的角色,然后把它应用到所有有类似需求的员工身上就行了?通常情况下,这可能是你唯一的选择,因为根据内部安全政策,拆分现有角色可能是严格禁止的,因为这样做会削弱 RBAC 模型的有效性。
RBAC 在管理用户身份和访问权限上存在根本性缺陷。其固有的弱点在于它的笨重性、对人工输入的依赖性以及需要持续维护。动态的组织需要动态的访问控制。所有这些因素结合在一起,形成了一个不安全的 IAM 结构。
“大多数基于角色的访问控制项目失败的原因是缺乏基础,“PeaceHealth 的 Christopher Paidhrin 说。“每个组织都需要评估他们是否为基于角色的访问做好了准备。有效的基于角色的访问管理需要做很多工作,在能够有效管理之前,还有很多工作需要进入分析过程”。
我们来看看 RBAC 的主要挑战。
问题 1:角色爆炸
如果营销副总裁的访问请求场景听起来很熟悉,那是因为它经常发生。当您的访问控制所需的颗粒度过于详细时,就会发生角色爆炸。角色爆炸很难管理,成本很高,并且使访问控制变得混乱和复杂,降低了访问控制的有效性。此外,当在你的访问控制部署中添加更多的角色时,还有一些其他的问题需要仔细监控。其中一个问题是,当一个用户被分配了太多的角色,然后在公司内部改变了工作或职责时,就会出现这样的问题。IT 系统管理员要么忘记了,要么甚至有意识地决定将旧角色留在原地。角色的数量会导致安全漏洞,而这些漏洞往往难以发现和弥补。
问题 2:安全风险承受能力
作为一个系统管理员,了解系统的风险是很重要的。进行安全风险分析,并制定积极的风险防范计划,对 RBAC 的部署至关重要。RBAC 是以数据为中心的;数据被归类为与组织结构相关的数据,这就导致了访问控制角色的定义。如果你的组织对安全风险是被动的,RBAC 可能不是保障网络数据访问安全的最佳方式。RBAC 要求你在部署前对公司的安全布局和权限授予方式有深入的了解。 一旦部署后,很难对不断变化的安全威胁和风险做出反应。因此,要小心谨慎,并对您的 RBAC 政策进行 “两次测量,一次切割”。在一个由于数据隐私和保护法规不断变化而对安全有效性进行更严格审查的时代,这种安全模式的淡化大大增加了数据泄露的风险,在财务和声誉上都会产生重大后果。
问题 3:可扩展性和动态性
是的,在 RBAC 部署之初,你清楚地知道你需要定义哪些角色,以及需要将它们分配给谁。但是,现在已经过了一年,组织已经成长了。更多的人加入了公司,在匆匆忙忙的入职过程中,组织结构图和工作定义没有得到更新或明确定义。
这就是 RBAC 难以维护和管理的地方。这些 “死角 “限制了你的部署的可扩展性,可能需要重新设计才能回到正轨。更糟糕的是,由于潜在的时间压力,你可能需要实施一个 “变通 “的解决方案,从长远来看,它可能会助长问题,而不是纠正它。几乎就像一个 IAM whac-a-mole 游戏,你要不断解决新的问题。
这更多的时候是每两到三年一次的重大返工周期,如果有的话,是为了弥补角色分类学缺乏增量管理,以符合组织结构的变化需求,而组织结构仍然是动态的、反应性的,因为它必须对客户的需求和数字世界中更敏捷的业务模式做出反应。
问题 4:成本高、实施难
您的公司已经使用计算机并收集数据很长时间了,但从未真正需要任何形式的访问控制作为组织安全政策的一部分。如果你需要堵住漏洞,并决定采用 RBAC,你可能会发现需要复制服务器和其他支持 RBAC 的基础设施,成本过高,增加了复杂性。你还需要考虑在淘汰旧系统的同时将用户迁移到新系统的成本和风险。大多数情况下,迁移会遇到各种困难和不可预见的挑战,并导致两个系统中的安全漏洞以及其他代价高昂的缺陷,如计划外停机和数据丢失。
集成 RBAC,实现稳健灵活的访问控制
如果你从来没有计划重新分配员工或与合作伙伴合作,RBAC 本身就是一种管理数据和系统资源访问的好方法。然而,没有一个组织结构是一成不变的,这使得 RBAC 方法在一个动态的商业环境中变得很麻烦。 我们经常看到公司在他们的人力资源系统、Active Directory 和 IGA 之间建立集成,以实现同步的角色创建和持续的角色生命周期管理。这些集成不仅昂贵,而且脆弱,难以维护,最终不能产生预期的结果。
但并非所有的希望都落空了。将 RBAC 与其他类型的访问控制方法集成,可以让您创建一个强大的、精细的访问控制策略。
Recommend
-
21
用 Pomerium 来实现基于身份的访问控制 浏览:19次 出处信息 Google 在十年前提出了一套名为
-
5
基于角色的访问控制RBAC是什么? - Tailscale我们大多数人都听说过基于角色的访问控制 (RBAC) 及其稍微更新的后继者,基于属性的访问控制 (ABAC)。但我们并不总是欣赏它们包含的所有伟大想法。当今最常见的“RBAC”系统已被精简,使其比原始概念弱得多。通...
-
4
[译] 基于角色的访问控制(RBAC):演进历史、设计理念及简洁实现(Tailscale, 2021) Published at 2021-09-14 | Last Update 2021-09-14 本文翻译自 2021 年的一篇英文博客:
-
9
V2EX › 数据库 关于 RBAC 设计优化的问题 LotteWong · 1 天前 · 816 次点击
-
5
基于角色的访问控制(RBAC):演进历史、设计理念及简洁实现 ...
-
8
SRBAC 是一个基于...
-
7
Istio安全之服务间访问控制RBAC · Service Mesh|服务网格中文社区 2019年3月25日 ...
-
8
好久没写文章了,过年以后就有点懒… 最近也在学习 golang,再加上不断造轮子所以没太多时间;凑巧最近想控制一下 kubectl 权限,这里便记录一下。一、RBAC 相关相信现在大部分人用的集群已经都是 1.6 版本以上,而且...
-
4
+c编程手记 Guangzhou, China很多实际的容器化工作,都会要求你设计一个自己的编排对象,实现自己的控制器模式。K8s 里新增和操作 API 对象,必须先了解RBAC负责完成...
-
9
通过本文,我们将学习如何从头开始重新创建 Kubernetes RBAC 授权模型,并了解Roles、ClusterRoles、ServiceA...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK