基于角色的访问控制仅基于组织内用户的角色来允许或限制用户对数据的访问。
阅读本文后,您将能够:
复制文章链接
基于角色的访问控制(RBAC)是一种用于控制用户在公司 IT 系统中能够执行的操作的方法。RBAC 通过为每个用户分配一个或多个“角色”并为每个角色赋予不同权限来实现此目的。RBAC 可应用于单个软件应用程序,也可应用于多个应用程序。
想像一间居住了几个人的房屋。每个居民都会得到一把可打开前门的钥匙:他们收到的钥匙不会有完全不同的设计,而且这些钥匙都可以打开前门。如果他们需要进入这一物业的其他部分,如后院的仓库,他们可能会收到第二把钥匙。没有居民会获得仓库的唯一钥匙,或可同时打开仓库和前门的特殊钥匙。
在 RBAC 中,角色是静态的,就像上例中房屋的钥匙一样。不论由谁拥有,它们都不会变化,而且需要更多访问权限的任何人都会被分配一个附加角色(或第二把钥匙),而不是获得自定义的权限。
从理论上讲,这种基于角色的访问控制方法使管理用户权限变得相对简单,因为权限不是针对单个用户量身定制的。但是,在具有许多角色和许多应用程序的大型企业中,RBAC 有时会变得复杂且难以跟踪,并且最终用户可能会获得超出其需求的权限。
在网络安全中,访问控制是指用于限制和控制用户能够执行的操作以及能够看到的数据的工具。输入密码以解锁智能手机是访问控制的一个基本示例:只有知道密码的人才能访问手机上的文件和应用程序。
一个人在公司中的职位可以称为“角色”。但是,角色在 RBAC 中具有更多技术层面的定义:它是一组明确定义的能力或权限,供公司系统内使用。每个内部用户至少分配有一个角色,一些用户还可具有多个角色。
角色是通用的,不是为组织内的任何一名员工量身定制的。例如,销售人员不会收到专门为其用户帐户设置的权限,而是会分配到“销售人员”角色以及所有附带的权限,例如能够查看和编辑客户帐户数据库。团队中的其他销售人员会分配到同样的角色。如果特定销售人员需要更高的权限,则要为其分配其他角色。
这种方法确实使添加或移除用户变得相对简单,管理员无需更改单个用户的权限,只需更改其角色便可。
在访问控制的上下文中,权限是执行某一操作的能力。例如,将文件上传到公司数据库的能力。受信任的用户(例如内部员工)拥有上传文件的权限,而外部承包商则可能没有此能力。在 RBAC 中,每个可能的角色都附带一组权限。
基于属性的访问控制(ABAC)是控制组织内部访问的另一种方法。ABAC 与 RBAC 有些类似,但更加精细:ABAC 中的权限基于用户属性,而非户角色。属性几乎可以是任何事物:用户的具体特征(例如,职务或安全许可)、所执行操作的属性,甚至是“现实中”的属性,例如当前的时刻或所访问数据的物理位置。
RBAC 和 ABAC 都考虑了用户的特征。但是,ABAC 可以考虑更多的上下文,如正在执行的操作和用户正在访问的数据或系统的属性,而 RBAC 仅考虑用户的角色。这使得 ABAC 比RBAC 更具动态性,但更难于有效管理。
基于角色的访问控制与基于规则的访问控制两者并不相同。基于规则的访问控制在一组规则的基础上构建,而基于角色的访问控制的基础是用户。基于规则的控制器会阻止某些操作,例如端口、IP 地址或数据输入类型,不论请求来自哪里。防火墙通常用于实施基于规则的访问控制。
Cloudflare Zero Trust 使企业能够保护、验证、监控和允许或拒绝用户访问 Cloudflare 上的任何域、应用程序或路径。Cloudflare Zero Trust 可将应用程序层用户权限快速应用到企业的内部资源,同时还能记录用户访问的所有资源。
RBAC is a security strategy used to manage what users can do within an organization’s digital environment. Instead of assigning unique permissions to every person, an organization assigns one or more "roles" to each user. Each of these roles comes with a pre-defined set of permissions.
A role is a standardized collection of permissions or abilities that apply to any user assigned to it. For example, an "account manager" role might include the ability to view and modify a customer database. These roles are not customized for specific individuals; rather, if a team member needs more access, they are assigned a secondary role that includes those additional permissions.
RBAC simplifies the process of managing user permissions because administrators do not have to tailor access for every employee. It is particularly helpful when adding or removing users, as an administrator can quickly grant or revoke access by changing a user's role rather than editing individual account settings.
The role-based model can become difficult to track in large organizations with many different roles and applications. This complexity can lead to a situation where users accidentally end up with more permissions than they need to perform their jobs.
While RBAC only considers a user's assigned role, ABAC can base permissions on specific user traits (like security clearance), the nature of the action being taken, or real-world context like the time of day and physical location.
The main difference is the focus of the restriction. RBAC is centered on the identity and role of the user, whereas rule-based access control is centered on specific technical constraints. For instance, a rule-based controller might block all traffic to a specific port regardless of which user is making the request.
A permission is the specific authorization to perform a task, such as downloading a file from a company server. In an RBAC system, these permissions are bundled together into roles. For example, a trusted internal employee might have a role that allows file downloads, whereas a role assigned to an outside party might not.
Cloudflare Zero Trust provides tools for businesses to secure and monitor user access to any application or path. This allows companies to quickly set application-level permissions and maintain detailed logs of all resources accessed by users, helping to ensure that security policies are strictly followed.