5.4 Implement and manage authorization mechanisms

Role Based Access Control (RBAC)
Rule-based access control
Mandatory Access Control (MAC)
Discretionary Access Control (DAC)
Risk based access control

There are different models for access control in an organization. The specific control chosen depends on the needs of the organization, the type of data being protected, and the type of users. An organization may implement multiple access control models.

Access Control permissions usually relate to being able to read, write, delete, and/or modify a file, and list contents of a folder. Additional, more extensive permissions, can apply to a database (such as the ability to read, write, delete, or modify entries in a database, create tables in a database, or create users in the database).

The permissions can apply to the entire system or granularly to specific files.

MAC – Mandatory Access Control

Each user has certain permissions on the system
The user cannot grant his permissions to other users
For example, if a user has read access to a file, the user cannot grant another user with read access to the file
The user cannot modify any of the permissions on the file

DAC – Discretionary Access Control

A user has certain permissions
The user can grant his permissions to other users
For example, if a user has read access to a file, the user can grant another user with read access to the file
An example of when DAC is better than MAC: a project manager has access to files related to his projects; the project manager grants access to other members of the team. The project manager does not have to contact an IT person to obtain access for members of his team.
An example of when MAC is better than DAC: an intelligence analyst needs to grant a co-worker access to classified documents; the analyst should not be able to do so; the individual requesting access must have a need-to-know basis and appropriate security clearances, which need to be verified by a central authority

ABAC – Attribute-Based Access Control

Each user has certain attributes (for example, the user’s role in the organization, age, security clearance, department, etc.)
Each resource has certain attributes (for example, the contents, department, owner, etc.)
When the user attempts to access the resource, the system uses the user’s attributes and the resource’s attributes to determine whether to provide access.
ABAC is more complicated because the system requires many rules to decide whether to permit/deny a user. If a rule does not exist, then the default action is to deny the access. It might take a substantial amount of work to set up all the rules.

Role-Based Access Control

Permissions are not assigned to individual users or to objects
Permissions are assigned to operations/actions (known as roles)
A user can be assigned to a specific role; the user inherits the permissions assigned to the role
The organization can define the operations and actions that are relevant to their organization. For example:
- Sales person (can access sales data)
- Accountant (can enter data into the accounting system)
- Accounts payable clerk (can approve invoices and issue payments)

Rule-Based Access Control

Permissions are not assigned to individual users or objects
Instead, a set of rules exist; the rules may permit or deny specific actions depending on the attributes
Each time an action is attempted, the system evaluates the action against the set of rules
The rules do not consider who is attempting the action, only what the action is

Conditional Access

We can use AI to make more complicated access decisions when a user needs to access a resource. This might also be called Risk Based Access Control.
Some factors that the AI might consider
- User role. Does the user have permission to access this resource?
- IP address. Where is the user currently located?
- Device type. Is the user attempting to access the resource from a smartphone, a corporate device, or a personal device?
- Application type. What application is the user attempting to access?
- Risky sign in behavior.
AI and machine learning can gather data over time to create a threat assessment that can more accurately predict whether access to a resource is legitimate.

Privileged Access Management

Privileged Access Management determines whether a user account can access a privileged resource
We might create a set of privileged user accounts for use by administrators. An administrator might have a privileged account in additional to his normal user account.
We can apply the same AI rules to privileged accounts that we did to regular accounts.

Some more ideas about access control

Permission – what you can do with an object (read, write, execute)
Right – ability to act on a system, such as modify settings. Permissions and rights are usually interchangeable.
Privilege – a combination of rights and permissions granted to a user.
Implicit Deny – users are normally denied rights to everything unless they are specifically granted access.
Access Control Matrix – a table with subjects (a user), objects (a file) and privileges. When a subject takes action on an object, we check the matrix to see if he has permission.
Capability Table – a table that shows us a list of subjects and what objects each subject has permission to access or modify
Constrained Interface – a constrained interface is where an application an restrict what a user can see or do based on their permissions. We might want to hide functions that a user doesn’t have access to – they shouldn’t even know that those functions exist.
Content-Dependent Control – restricts access to data based on the content within the object
Context-Dependent Control – requires a user to engage in specific activity before showing additional data. For example, restricting access based on the date/time
Need to Know – subjects are only granted access to data based on a need to know – we only give you access to data that you need to perform your job, even if you have the clearance or right to see the data