We continue our reading on the Study of Access Control Model in Information Security by Qing-Hai,Ying et al. Today we review the mention for Role Based Access Control (RBAC). DAC and MAC was not flexible to handle business changes such as adding, canceling, and merging departments, employee promotions, duty changes, etc. Instead role based access control was favored. In RBAC, authorization is mapped to roles. A user can take different roles. This effectively handles changes in the organization. Since users are not assigned rights directly but only acquire it with roles, management of individual user rights becomes a matter of assigning appropriate roles to user's accounts. The roles are classified based on the set of stabilized duties and responsibilities in the management. There are three primary rules for RBAC.
Role assigment - A subject can exercise a permission only if the subject has been selected or assigned a role.
Role authorization - A subject's active role must be authorized for the subject. i.e User cannot take any or all roles.
Permission authorization - A subject can exercise a permission only if the permission is authorized for the subject's active role. i.e the user can exercise only those permissions assigned to the role.
Roles can be hierarchical in which a higher level role assumes all that comes with the lower level role.
With a hierarchical role and constraints, an RBAC can be controlled to simulate a Lattice Based Access Control. Thus RBAC can also be used to implement DAC and MAC.
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles.
RBAC is not the same as ACLs. RBAC differs from access control lists in that RBAC assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. An ACL may control how whether a file can be read or written but it cannot say how the file can be changed. RBAC lends more meaning to the operations in the organization. It can be used to achieve a Separation of Duties which ensures that two or more people must be involved in authorizing critical operations SoD is used where no individual should be able to effect a breach of security through dual privilege.
Role assigment - A subject can exercise a permission only if the subject has been selected or assigned a role.
Role authorization - A subject's active role must be authorized for the subject. i.e User cannot take any or all roles.
Permission authorization - A subject can exercise a permission only if the permission is authorized for the subject's active role. i.e the user can exercise only those permissions assigned to the role.
Roles can be hierarchical in which a higher level role assumes all that comes with the lower level role.
With a hierarchical role and constraints, an RBAC can be controlled to simulate a Lattice Based Access Control. Thus RBAC can also be used to implement DAC and MAC.
A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles.
RBAC is not the same as ACLs. RBAC differs from access control lists in that RBAC assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. An ACL may control how whether a file can be read or written but it cannot say how the file can be changed. RBAC lends more meaning to the operations in the organization. It can be used to achieve a Separation of Duties which ensures that two or more people must be involved in authorizing critical operations SoD is used where no individual should be able to effect a breach of security through dual privilege.
No comments:
Post a Comment