Authorization

Ruslan Rakhmetov, Security Vision

Authorization technology is an important part of information security that determines what exactly a user can do in the system after he has been authenticated (i.e., proved his identity). To log in means to run and pass an access check when the system decides whether one can view personal data, edit it, or only read it. In the current article, we will analyze each type of authorization — what it is, how it works, where it is used, its pros and cons. This will help one both to choose the right method for the tasks and to understand the differences.

All authorization models can be described by multiple groups, based on roles, attributes, access lists, and security policies.

RBAC (Role-Based Access Control) is one of the most popular and widely used authorization methods. It is easy to implement and straightforward for most systems. Role-based access control is a model in which access to resources is granted not directly to users, but through roles (sets of rights that determine what actions can be performed).

Such a model can be represented in the form of three levels:

1) the user receives one or more roles;

2) each role contains a set of permissions;

3) permissions determine what can be done (for example: read, write, delete).

You can imagine a house with different keys for many locks, when each tenant has his own level of access: the child opens only the front door, the parents also open the basement, the garage. A clear division by role can be seen, for example, in a supermarket, when a buyer takes goods and collects a grocery basket, the cashier punches and helps to pay, the manager recounts the cashier within the time frame specified by the regulations, and the store director has access to all systems.

In the RBAC authorization model, it is easy to assign and change access simply by changing roles, thanks to the transparency of the levels, it immediately becomes clear who is responsible for what. It is suitable for systems with hundreds of users, and in terms of security, it makes it easy to implement the principle of least privileges. Despite its simplicity and transparency, this model is not the most flexible: if you need to set unique rights for a user, you need to create new roles or make exceptions, and with a large number of combinations of rights, many roles can appear, and they are difficult to manage.

RBAC is widely used in corporate systems (for example, in a company, employees have the roles: accountant, manager, director, and everyone has their own rights in the system), sites and web applications (the administrator can do everything, the editor can publish, the user can only read), databases (for example, in PostgreSQL and Oracle, each role has its own visibility of tables, procedures and data), operating systems (in Linux or Windows: ordinary users have limited rights, the administrator has full access) and cloud solutions (for example, roles are created in AWS with access only to the necessary services). You can compare this model with the work of accesses in the library, when visitors can read books, librarians can give out and accept, and the manager can order new copies as needed. Or with work with data in the clinic, when the patient sees his card, the nurse can make appointments, the doctor makes diagnoses, and the chief physician manages everything at once and has the most complete access.

ABAC (Attribute-Based Access Control) is a much more flexible and "smart" way to control access. Attribute-based access control is an authorization model in which access decisions are made based on a set of attributes: user (who he is), resource (what it is), action (what he wants to do), context (in what environment). And access is issued if all the conditions match.

Instead of simple roles, as in RBAC, the logic "if X - then Y" is used here, for example: IF the user works in the HR department, the resource is a resume type file, the current time is working hours and access is requested from a corporate device, THEN allow access to read the file. Also, the model is applicable for checkpoints at the points of delivery of goods: if the buyer came to the place and provided the access code to the cell within the shelf life of the parcel, the door will open and the client will be able to receive the goods.

All authorization is based on access policies (rules/policies), consisting of logical expressions.

Thus, for example, access to school works (if it is a teacher, and he has an access card, and now the weekday is to allow entry) or a social discount is issued in supermarkets (if the buyer is > 60 years old, he has confirmation of age or status and purchases are made on weekdays until 17:00, then an additional 10% discount is provided).

ABAC provides more flexibility, you can set access depending on many factors. The access itself is configured granularly, to specific objects under certain conditions, and the authorization system scales perfectly: you do not need to create thousands of roles, as in RBAC. Since to implement the model you need to design and implement a system of rules, and over time the logic may become too confusing, the current option has a fairly high entry threshold - you need to understand the logic of policies well.

ABAC is used for corporate portals with many variables (department, region, experience, device), cloud platforms (AWS, Azure), where administrators flexibly manage access by resources, tags, conditions, in financial and medical systems, where you need to take into account many security factors, as well as in military and government agencies.

ACL (Access Control List) is a list of rules that is attached to each resource (for example, a file, database entries, API endpoint) and determines who and what can do with this object. Access through the control list determines permissions on the object, not on the user: each resource has a list where it is indicated who can access and what can be done according to the rules of the company.

So, for example, many office access systems are arranged (each door has its own list of who can enter, for example, the server room - only admins) or games on the console (each game can have access by profile: "children," "adult," "guest," which determine who can start the game, save progress or delete saves).

The ACL model is very flexible at the level of each resource, you can very accurately configure who has access to what, it has been used for decades (for example, in UNIX systems like MacOS), it is quite simple to implement it. Despite this, ACLs are difficult to scale (if there are many objects, it becomes difficult to manage lists), and it is more difficult to understand who has access to what than in the first model of our list (RBAC).

It is used in file systems (Linux, Windows, NTFS, ext4), web services (Apache.htaccess), databases (for example, MongoDB, Redis), network devices and cloud storage (Yandex.Disk, Google Drive, Dropbox).

MAC (Mandatory Access Control) is the toughest and strictest authorization model of all that we talked about above. A model of forced access control, in which the rules are set centrally, and users cannot change access rights on their own - like an army charter: everything is strictly according to the rules.

Each object (document, file, base, resource) and subject (user, process) are assigned security labels (for example, "Secret," "Confidential," "Open" for different document objects, and access is allowed only if the subject label corresponds to the object label (or higher).

This is similar to access to the launch area at the spaceport (only engineers with "clearance" have the ability to enter the territory and do their work there) or access to examination materials (only the commission has access, and students receive limited familiarization rights closer to the session).

MAC works on the principle of "do not trust anyone" (Zero-Trust): the user cannot change the access rights himself, which are checked according to the security policy set by the administrator. A hierarchy of access levels is used (as in the army or government). This ensures maximum security, uniformity of policies and maximum exclusion of the human factor. However, MAC-type systems show minimal flexibility and complexity in settings.

These four authorization methods describe the vast majority of processes:

RBAC is like a skip system, where everyone is assigned a role, and based on that role it is determined what they can do;

ABAC works like a smart doorman who checks a bunch of conditions before letting you in: "you're an employee... but you're from the wrong department... and even a day off... sorry, access is prohibited!";

ACL is great where object-level control is important (this is like guest lists for each room), not roles or context. But at scale, it can become uncomfortable;

And MAC, as a military discipline for files and data, no democracy: everything is decided by the label and security policy ("You are not on the list - you do not go, even if you are the head of the department").

The main purpose of authorization is to protect data and resources: authorization provides security, allowing only authorized users to access certain systems, functions or data. Without authorization, information can be vulnerable to unauthorized access.