Access Control Models: Review of Types and Use-Cases
Besides the authentication and identity verification tasks, all IT infrastructure is facing a problem of another kind. If the company is bigger than just a couple of people, then often such a business needs to restrict the access of certain users to certain information. It’s logical, as employees or groups of employees should only be able to access data related to their job and be restricted from the information that is irrelevant to job duties, such as financial data, customer info etc.
This is good both from security and management points of view, as it makes it easier to assign responsibility for tasks and track employees’ performance.
There are several access control models that can be implemented to solve this task. Today we’ll dive into this topic and explain which of them should be used, and when.
Mandatory Access Control
The mandatory access control (MAC) model was designed by the government and initially used for its purposes. It is a very strict access control model. In MAC, access to all data in the system is pre-defined by an administrator and controlled by the operating system.
MAC implements two concepts, the first one is the classification of the data (such as the degree of its importance or secrecy) and, second, the user category (department, project-related etc). As a result, it is possible to create rules describing which objects should be available to users included in a certain group.
Each user account also has these properties. When a user wants to access a certain file or folder, the OS checks what properties the object has and compares them to what is listed in the user profile. If this user belongs to a group that is allowed to access this type of data, the access will be granted. If not, declined.
Despite being one of the most secure access control models, MAC is also very vague. There are multiple ways to implement it, and all of them require thorough planning. It is also difficult and costly to manage object and accounts data to reflect changes in the infrastructure and the appearance of new data, departments, and employees.
As a result, it is rare to see pure mandatory access control in an organization. More often there is a combination of different approaches. For example, as it is done in the UNIX system, where DAC is used but the root account can bypass this access model and receive unrestricted privileges.
Discretionary Access Control
Instead of all data and access being controlled by the operating system, this paradigm allows users to control access to their data. So, the user can define what users and categories of users will get what type of an access to his or her data using an access control list (ACL). Each ACL includes a list of users and groups and a level of access they might have, for example, read-only, read and write, or full access. Often system administrators set up a range of access control privileges that users might grant via their ACL.
The key thing here is that users can only define access to resources they own, but not change the access type for files owned by someone else. An example of DAC in the real world is a social network where people can change the visibility of their content.
This is a much more flexible model than MAC, however, it introduces additional risk as well, as we have to rely on users’ defined access rights. If there is a mistake, people who should not have access to certain files, may accidentally receive it.
Role-Based Access Control
The role-based access control (RBAC) is a tool used by companies to grant access based on a user’s job function. In this model, permissions are assigned to roles within the organization. Thus accountants will gain access to financial information, sales reps to CRM with customer data, software engineers to code repositories or documentation, etc.
In RBAC, user is assigned a role, and he or she will always only receive the permissions allowed in this role, with no existing way of bypassing the system. RBAS is perfect for separating work duties by introducing roles for specific tasks.
This is why we use RBAC in 1C:Enterprise. Customizing roles allows companies using this business automation system to set additional conditions for handling data (data access restrictions). For example, a requested action can be performed on a specific object stored in the database only if the data access restriction for this object’s data is set to TRUE.
It is also possible to specify different restrictions for different tabular fields of object tables and information registers. This allows setting restrictions at both database record level and database field level.
A data access restriction is a condition described in a language that is a subset of the query language. This condition is applicable to each record of a database table on which an operation is performed. If the condition is TRUE, the operation is performed. Otherwise, the operation is not performed. The condition can be refined by using preprocessor instructions (#If <condition>, #Then, and so on).
Rule-Based Access Control
The model with the same acronym RBAC, but reads as rule-based access control. In this case, access is granted or declined only on the basis of pre-defined rules created by an administrator. In this variation of RBAC, each object has its own access control list (ACL), and the operating system checks whether a certain user (or group) is allowed to have access when he or she makes such an attempt.
In this model, users can’t change anything. Rule-based control is often used in organizations when there is a need to organize, say, a network connection for a certain group of users at a certain time of the day or week.
Attribute-Based Access Control (ABAC)
Another alternative to role-based access control is attribute-based access control (ABAC). This model grants rights by introducing special policies. These policies combine attributes for users, resource, and objects.
The main difference of ABAC is that every situation is assessed not from the role and desired action point of view, but on the basis of attributes assigned to this role and action. As a result, the business rule here is a set of conditions where different attributes should satisfy certain requirements.
ABAC uses Boolean logic with “IF, THEN” statements to understand should the user be granted access or not. (IF the user is an accountant, THEN allow him to access financial data).
