Authorisation or “official permission for something to happen, or the action of giving someone official permission for something” can appear to be a strange thing to call out as a separate foundation within the 5 IAM Pillars.
Most people would assume that this comes under the pillar of authentication. Surely if you are allowed to login then you are authorised. This viewpoint is re-inforced when you consider the consolidation in the functionality provided by the IAM vendors.
This article is not here to talk about the products but rather the functionality required and hence the differences between authentication and authorisation.
A non-IT way to think about it is using a real-life example. Your passport (or other government provided Identity Card) authenticates who you are. Ok, many border controls require MFA with fingerprint or face scanners, but that password does not grant to rights to go into every building in the country you are visiting (or residing). For that you will need extra permissions.
That is this the key term here, permission. Authorisation is about allowing access to data, applications etc only if you have permissions and the key components of authorisation provide the functionality to manage those permissions.
The Components of Authorisation
Role Based Access Control (RBAC) became a fundamental part of deciding on who should have access to what. Whilst still true to a point this was soon superseded by Attribute Based Access Control (ABAC). This is granting access not just on role but other information about a user such as location, type of laptop, hours of work etc.
Access was, and still is, a part of automation (more on this later) but modern Access Management (AM) tools have embraced the concepts of ABAC and used it to provide dynamic access controls granting or denying access based on live information about a user. This jump and tied with better authentication has drastically reduced the security risk.
What is often forgotten with Access Management, though it can be a specialism in itself, is managing access for privilege users or Privilege Access Management (PAM). What is a privilege user can be a theoretical conversation based on one’s strictness to security, but in the most case its defined as administrator users who can configure, modify and perform tasks on systems general users cannot.
The aim of a PAM tool is to limit the tasks that the administrators can perform. Whilst it may seem restrictive, often an administrator can do too many administrator things inside and outside key systems. These wide ranging permissions make them a target for those dastardly criminals.
- RBAC
- ABAC
- Access Management
- Dynamic Access Policies
- Privilege Access Management
Role Based Access Control
Whenever access control is mentioned the first thing that comes to mind is Role Based Access Control or access based on a role within the organisation. Originally the role was merely someone’s job title. In other words, all sales people got access to an application that HR people could not.
It was realised that was an oversimplification, so the word role took on a new meaning. It came to mean a group or collection. For example all employees in the US. This approach allows for a neat hierarchical design and can often be mapped to groups in your favourite identity store (most likely Active Directory). From which permissions and access can be easily assigned to everyone in that group.
Using an Identity Store group as an means of managing RBAC allows for easy automation. Its fairly simple to write a script or to use a tool to move all people into a group that have a common office attribute value.
Attribute Based Access Control
ABAC is an extension of the RBAC model in that any attribute of the user identity can be taken into account, rather than just job title or group membership. In many cases it allows for associations of the user to be taken into consideration. For example what device has the user been supplied with or geographical location.
Ultimately in recent times the lines between RBAC and ABAC have become blurred especially when many providers will group users based on any attribute but still call this RBAC.
Dynamic Access Policies
RBAC and ABAC should be considered as static in nature i.e access and permissions are granted based on some fixed property of the user.
Dynamic Access Policies work differently, permissions are determined when access is requested. For example time of day, browser being used, geographical location of the user at the time of request.
Those who read the Authentication blog will probably be saying “hold on isn’t this the same as the Attribute Based authentication”. You may be partially correct, but the intentions are different. User attributes can be used to provide greater confidence that the user is authenticate (i.e. who they say they are and not some impersonator). With access, attributes are used to place further restrictions on the ability to use a resource even if the user is valid.
An example of this could be access to a production server for a backup operator. Access is only granted after 10pm Monday to Friday and from an IP address that is within the corporate environment (in other words on-premise, rather than remote).
With Access though the values change from that used at the time of authentication. Sometimes this can be used to further identify an intruder. A well-known indicator is what is known as impossible travel. This is where the user has wildly different locations that would be impossible to travel to in the time between requests. (Please ignore this if instant transporter devices have been invented at the time of reading).
Access Management
This is often confused with the all-encompassing technology platforms, but this refers to the functionality of managing access. Access is never a one and done operation, users needs change and their the resources they require do also.
It is often overlooked within IAM, but consider projects people work on. Some people may be lucky (or unlucky depending on your perspective about having variety in your job) and work on the same project throughout their lifetime within an organisation. Typically, though this is not the case.
It’s important to have a good process and associated functionality that can manage the changes. Often this is a manual process, which is fine, but as with all thing’s human is liable for errors. Therefore, an automated (or as much as possible) process is better.
A user should be given the ability to request access. As part of this process a superior should be given the ability to approve or reject the request.
There are a few types of approval process. Firstly there is two eyes i.e. a single person approves the request.
Then there is multiple of two eyes e.g four eyes. In other words more than one person. Each set of eyes acts as a gate, where rejection of the request stops it completely.
Lastly there is quorum. This is where a number of a group have to give approval for example two out of four.
It is always recommended to periodically review the access users have. We live in a dynamic world where people, roles and projects change. Never assume that a set of permissions will remain the same. This is essential to protect an organisation from possible threats due to out of date access.
Privilege Access Management
This a whole subject by itself and a separate and very large discipline within IAM.
To the un-initiated, PAM is a complicated subject. The first critical part is to define what is a privilege and therefore why does it managing?
Many purists will have you believe that every operation is a privilege and therefore should be tightly controlled and monitored. Many practices such as Zero Trust do preach this, though for non-privilege users that is often managed by typical Access Management policies.
One of the key differences between PAM and ordinary access management is the detailed monitoring and auditing of privilege sessions. Many PAM vendors will provide the ability to video record a session, but at worse will provide detailed and verbose logs of every session.
This can be seen as being overkill to do this on every activity, so a definition of a privilege is one that purists lose out on. Essentially a privilege operation should be considered one in which an elevated permission is required (more so than a normal user). Examples of this are for configuration changes, access to very sensitive data or is made by a high-value individual. This does seem a broad definition, but in most organisations, this typically comes down to a few individuals. These are your System Administrators.
The elevated permissions an administrator has are often broad ranging allowing them to do almost anything. This makes them target for attack and once the account has been compromised criminals have the power to do a lot of damage. It’s not just external people, there have even been some well-known cases were the administrators themselves are the threat (just think of Edward Snowden and Wikileaks).
There is some debate as to whether separate accounts should be used to differentiate between privilege operations and non-privilege. There are arguments for and against. The most common reason for having separate admin accounts is that there is a disassociated with the administrators’ everyday accounts and therefore is perceived to provide some additional security. The argument against is that this puts a strain on the movers and leavers process to ensure that the privilege account is deleted when the user changes role or leaves the organisation.
Simply put, managing privilege and administrator access is critical to the security of an organisation.
Summary
Authorisation should be considered a separate and distinct set of functionalities compared to authentication. Modern platforms blur the two together, but just because a user is authentic it doesn’t mean they should have access to everything.
Having a good model through Role or Attribute Based Access control will help give a base set of permissions for a user. These are based off static properties (or ones that seldomly change).
With the best will in the world, these models will not cover every situation. Therefore users will need to request access. Around this should be a good approval process.
Dynamic Access Policies allow for additional controls on attributes that can only be determined at the time of attempted access. These policies allow for fine grained control over when, who and how access can be granted.
Finally, there is the all-important Privilege Access Management. It is essential that privilege operations that require elevated permissions are controlled and monitored.