What is an Authorisation Matrix?

What is an Authorisation Matrix?

An authorisation matrix is a document, tool, or system that describes in detail which users or groups have access to specific applications, data, or other facilities within your organisation. It is therefore an important aid for account and access management, and it supports your information security and compliance.

Such an authorisation matrix has two objectives:

1. The matrix is the source for all user permissions as issued and managed within your Identity and Access Management (IAM) platform. The IAM ensures that all users receive access to all required applications, data, and other resources.

2. It is therefore also the ‘single source of truth’ that can be referenced during audits or after a security incident to inventory all access rights and, for example, produce an audit trail.

An authorisation matrix is necessary to comply with the Principle of Least Privilege (PoLP), a leading principle within security standards such as ISO 27001 and the General Data Protection Regulation (GDPR). This principle means that each employee is granted only the rights for those applications, data, and facilities that are genuinely required to perform their job. Each user effectively receives access on a ‘need to know’ basis. This contrasts with small start-ups where all users often have access to all facilities; unless information is highly specific and confidential. This is also called the ‘open unless’ principle.

IAM systems are commonly configured on a need-to-know basis, and an authorisation matrix is necessary to manage this effectively.

Is an authorisation matrix mandatory?

Security guidelines such as ISO 27001 or BIO often refer to an authorisation matrix, although such a matrix is not officially mandatory. Nor is there a fixed guideline for how a matrix should look or how it should be implemented. It is more a general term for a single central, structured, and managed register of all authorisation rules. Such a register is simply necessary to comply with current security and privacy guidelines. In our own HelloID platform we do not literally use a matrix, but we enforce authorisation management through a set of structured business rules.

Moreover, authorisation matrices often exist at two or more levels within organisations:

• At organisational or governance level it mainly concerns the rights and responsibilities around complete processes or subprocesses and groups of data. For example, who is the business owner of all customer data and customer systems?

• At a more operational level, such as in the IAM system, an authorisation matrix is much more detailed and focuses on access to specific systems and data shares.

Creating an authorisation matrix

How should you create such an authorisation matrix, and is there a standard authorisation matrix template? Templates do exist, although we noted that the actual design depends on the organisation and the management tools in use. In essence, creating an authorisation matrix always comes down to the following:

1. Identify the resources, meaning all information systems, applications, databases, and physical locations that require access management.

2. Define the users, user groups, or roles for which you must grant and manage permissions.

3. Determine, for the various users, groups, and roles, which systems, applications, and other facilities they should access on a need-to-know basis.

4. Access rights can then be further refined. For example, by the permitted actions such as view, edit, and delete. In healthcare, an additional ‘scope’ is often applied for access to care systems: someone may be granted access only to data for a specific location or group of clients.

You must then implement this information in your IAM system. As noted in step 4 above, once you refine access rights the authorisation matrix effectively becomes multidimensional. A simple table structure is then too limited, which is why our HelloID platform uses so-called business rules. These are more flexible and versatile, and you can enter, view, review, and adjust them directly online in the HelloID platform through a user-friendly interface.

Mapping all users, groups, roles, and their permissions can be quite complex in a larger organisation. You need a complete analysis of the existing organisational structure and all business processes. A useful aid to quickly and easily create a first authorisation matrix is so-called role mining. This performs a smart analysis of existing users and their access rights to generate an initial version of the authorisation matrix.

What are the alternatives to an authorisation matrix?

There is not so much an alternative to the authorisation matrix itself. As noted, it is a general term for a document or tool to record and manage access rights in a structured way. The way you organise those access rights can, however, differ. Below we outline possible forms of access control:

Access control approaches	Explanation
Access Control List (ACL)	Access to systems and data is managed per individual user. This is the closest to the basic concept of an authorisation matrix. It works well for small systems and organisations, but becomes difficult to manage in larger environments.
Role Based Access Control (RBAC)	With RBAC you organise access rights not per person but based on the roles or functions that people perform within an organisation. A salesperson therefore receives different access rights than a finance administrator.
Attribute Based Access Control (ABAC)	ABAC is similar to RBAC but is more flexible, and also more complex, because more attributes of users, applications, and data can be used. For example, to access certain data someone must have a particular role and also be authorised for data with a given classification level.
Policy Based Access Control (PBAC)	With PBAC you use policy rules to determine who has access to which data and applications. For example, you can make access to applications dependent on the time of day, such as working hours only, the access network used, or the sensitivity of the data.

These are different ways to organise and structure access rights. Each of the described control options has its own advantages and disadvantages, depending on the type of organisation, its size, and the sensitivity of the data being managed. In practice you will often see advanced IAM solutions using a combination of these methods for their authorisation management.

IAM and authorisation matrix

How do you use an authorisation matrix to configure your Identity and Access Management. In many IAM solutions, including HelloID, Role Based Access Control is recommended as the starting point for your access management. This is logical, because RBAC aligns well with the Least Privilege principle; you define the required access rights per role.

In fact, HelloID provides a more comprehensive mechanism to manage your authorisation rules, namely ABAC. Attributes are any relevant characteristics of users. These can include a person’s role or function, but also the department where they work or their work location. We can assign access rights based on combinations of such attributes, and that flexibility makes the system very powerful. Below are examples of such business rules:

• Using a business rule we can easily configure that someone with the function ‘care worker’ is granted access to the Electronic Client Record (ECD) in addition to standard M365 software. This is therefore a role-based access right.

• You can refine such an access right by using other attributes as well, so that a care worker is granted access only to ECD data for clients treated at the location and department where that employee works.

• Business rules also support the time factor. For example, you can grant the required authorisations several days before someone’s onboarding. You can also block an account when the contract ends while keeping the associated authorisations in the system for a grace period.

HelloID also allows you to grant individual optional access rights. For example, a specific application for a temporary project. Such a right does not follow from attributes or policies, which is why we do not manage these rights through general business rules. Instead, we use the HelloID Service Automation module. This automates and records the online request for such optional items; including review and approval, provisioning, and timely revocation if required.

HelloID gives you the flexibility to combine different control measures within your IAM environment and to tune your IAM authorisation matrix precisely to your organisation.

Want to learn more about configuring your authorisation rules and authorisation matrix using HelloID business rules? Watch our webinar.