Access Control (AC) Models

Role-Based Access Control (or RBAC) is an access control policy that restricts information system access to authorized users.

Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. Access can be granted by the owner as with DAC and applied with the policy according to MAC.

RBAC can be applied in various amounts to meet the needs of an organization, as the graphic illustrates.

The top (non-RBAC management) shows an organization that is not using any form of RBAC. Individual users are granted permissions to run (load and execute) sets of applications programs. The organization may not want its accounts payables staff developing software, soon a per user ID basis, they block them from being able to run integrated development tools such as Visual Studio.

The next example (limited RBAC management) shows a limited use of roles, associating particular applications to specific roles. Thus, the accounts payable team member role has permission to run QuickBooks (Application 1, Role A), but the developers(Role B) can run other apps for software development and test them. In this example, each individual user ID is associated with one or more specific roles as well.

Note too that this allows for applications to be used irrespective of any roles assigned to users; for example, all users may be able to run Firefox or Chrome.

The next portion (hybrid MAC management) shows more extensive use of RBAC in an organization. The limited RBAC management case (top portion of the figure) illustrates a hybrid use case, which shows how individuals may have one or more roles, each of which is permitted to use one or more specific applications. The rights and privileges associated with Role A in this example would probably be different than those involved in Role B, even if the same applications program was being used in both roles. A point of sales application, for example, may have roles defined for sales clerk and sales supervisor, but only the supervisor role would be able to run that application and use its price override or transaction void features.

The lower portion (full RBAC management) shows a full implementation of RBAC, with all user IDs first mapped to roles, and then those roles mapped to applications.

Rule-Based Access Control (RuBAC)

Rule-Based Access Control (or RuBAC) is a pre-defined list of rules to determine access with additional granularity controls such as when, where, and if the system will allow read, write, or execute on special conditions.

RuBAC is managed by the system owner and represents an implementation of DAC. These rules are often expressed in Boolean logic terms and can be quite complex and specific. For example, a company's Chief Financial Officer may normally have extensive permissions to view financial and accounting details and authorize exceptionally large payments; RuBAC could be used to restrict the use of these privileges via remote access to a narrow set of IP addresses, to specific days of the week and times of the day, and so forth. If the CFO travels to potentially risky or hazardous areas of the globe, this could protect the organization if the CFO is kidnapped or their smartphone stolen on such a trip.

Mandatory Access Control (or MAC) means that access control policy decisions are made by a central authority and not by the individual owner of an object. User cannot change access rights.

An example of MAC occurs in military security, where an individual data owner does not decide who has a top-secret clearance, nor can the owner change the classification of an object from top-secret to secret.

Discretionary Access Control (DAC)

Discretionary Access Control (or DAC) leaves a certain amount of access control to the discretion of the object's owner or anyone else who is authorized to control the object's access

The owner can determine who should have access rights to an object and what those rights should be. DAC allows for the greatest flexibility in controls along with the greatest vulnerabilities. The object's owner can pass on control weaknesses that can contribute to access and privilege aggregation. Many of the commercial operating systems used on endpoint devices, such as Windows and Android, use forms of discretionary access control so that purchasers (individual or organizations) can choose how to tailor these controls to their own needs.

Nondiscretionary Access Control (NDAC)

Policies in this category have rules that are not established at the discretion of the user.

Non-discretionary policies establish controls that cannot be changed by users, but only through administrative action.

Attribute-Based Access Control (ABAC)

Attribute-Based Access Control (ABAC) is an access control paradigm whereby access rights are granted to users with policies that combine attributes together.

The policies can use any type of attributes (user attributes, resource attributes, environment attributes, time of day, etc.). ABAC is a simpler form of RuBAC.

This facilitates the setting of stricter permissions for access, based on risk. For this reason, it is often called risk-intelligent access control. It sets out and mandates the entitlements that an individual subject should have based on Boolean logic arguments that state "if this condition is met, then this can be done."