访问控制 -- Access Control

RBAC和ABAC

https://www.jianshu.com/p/107c50720a6f

面向目标机器的资源。

 

什么是RBAC？

 

RBAC.png

比如当用户登录某财务管理系统的时候，允许哪些用户访问编辑哪些菜单，允许访问编辑哪些商品资源等，决定这些权限都取决于用户是哪个角色。
在RBAC，角色通常是指具有某些共同特征的一组人，例如:部门、地点、资历、级别、工作职责等。
在系统初始时Admin根据业务需要创建多个拥有不同权限组合的不同角色，如角色A拥有全部菜单的访问跟编辑权限，角色B只有菜单A的访问编辑权限无其他菜单的编辑权限。当需要赋予某个用户权限的时候，把用户归到相应角色里即可赋予符合需要的权限。

什么是ABAC？

 

ABAC.png

ABAC访问控制利用了一组称为 “属性 “的特征。这包括用户属性、环境属性和资源属性。
用户属性：包括如用户的姓名、角色、组织、ID 和安全许可等内容。
环境属性：包括如访问时间、数据的位置和当前组织的威胁等级。
资源属性：包括如创建日期、资源所有者、文件名和数据敏感性。

可以根据业务需求制定不同的访问控制策略。如可以指定财务部门的人员可以在工作日上班时间并且在办公网络访问系统，若属于财务部门的人员使用办公网络但不在办公时间访问则增加进一步的鉴权验证，若属于财务部门的人员不在办公时间访问且非使用办公网络则拒绝访问。

RBAC和ABAC的区别

RBAC与ABAC之间的主要区别在于方法授予访问权限的方式。 RBAC按照角色授予访问权限，ABAC可以根据用户特征，对象特征，操作类型等属性确定访问权限。

 

ABAC

https://www.okta.com/blog/2020/09/attribute-based-access-control-abac/

Attribute-based access control (ABAC) is an authorization model that evaluates attributes (or characteristics), rather than roles, to determine access. The purpose of ABAC is to protect objects such as data, network devices, and IT resources from unauthorized users and actions—those that don’t have “approved” characteristics as defined by an organization’s security policies.

ABAC as a form of logical access control became prominent in the past decade, having evolved from simple access control lists and role-based access control (RBAC). As part of an initiative to help federal organizations improve their access control architectures, the Federal Chief Information Officers Council endorsed ABAC in 2011. They recommended ABAC as the model to adopt for organizations to safely share information.

In this post, we explore how attribute-based access control works in greater depth and consider the ways that adopting ABAC could benefit your organization.

 

How does ABAC use attributes to express access control policies?

Attributes are the characteristics or values of a component involved in an access event. Attribute-based access control analyzes the attributes of these components against rules. These rules define which attribute combinations are authorized in order for the subject to successfully perform an action with the object.

Based on how attributes interact in an environment, every ABAC solution can evaluate them within an environment, and enforce rules and relationships. Policies take attributes into account to define which access conditions are allowed or not.

For example, let’s say that the following policy is in place:

“If the subject is in a communications job role, they should have read and edit access to media strategies for the business units they represent.”

Whenever an access request happens, the ABAC system analyzes attribute values for matches with established policies. As long as the above policy is in place, an access request with the following attributes should grant access:

• Subject’s “job role” = “communications”
• Subject’s “business unit” = “marketing”
• Action = “edit”
• Resource “type” = “media strategy document”
• Resource “business unit” = “marketing”

In effect, ABAC allows admins to implement granular, policy-based access control, using different combinations of attributes to create conditions of access that are as specific or broad as the situation calls for.

 

Host-Based Access Control

面向目标机器服务

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/identity_management_guide/configuring-host-access#about-hbac

Host-based access control rules (which are described in Chapter 22, Policy: Configuring Host-Based Access Control) can be applied to individual hosts. However, using host groups allows centralized, and potentially simplified, access control management because an access control rule only needs to be defined once and then it is applied immediately and consistently to all the hosts within the group.

Figure 22.1. Host Groups and Host-Based Access Control

Note

While access must be explicitly granted to users and hosts within the IdM domain, IdM servers are configured by default with an allow all access control rule which allows access for every host within the domain to every host within the domain.

To create an IdM server without the default allow all rule, run ipa-server-install with the --no_hbac_allow option.

The rule first defines things that can be accessed, and there are two types of entities:

• Hosts, or target hosts, within the IdM domain.
• Services on the target hosts. Multiple services can be combined into service groups. The service group can be modified without having to edit the access control rule itself.

The rule also sets who can have access (the IdM domain user).

Note

It is possible to use categories for users and target hosts instead of adding each one individually to the access control rule. The only supported category is all.

The entities in host-based access control rules follow the Kerberos principal entries: users, hosts (machines), and services. Users and target hosts can be added directly to host-based access control rules. However, services must be added to the host-based access control configuration first to make it available to rules, and then added to the access control rules.