In this pocket guide, you’ll find essential information about main security controls. I will explain the concepts, risks, share real-world examples and some interesting, less obvious insights.
Idea
Authorization is verification of the privileges of the party you communicate with. Please do not confuse with authentication, which is verification of its identity. The party could be a user, or a system.
Most communications follow the client->server model, where the client requests to perform a certain action on the remote server. There is no concept of mutual authorisation for client->server communications.
Well-designed authorisation (access) model follows the principle of least privilege – the party should only have the minimum set of permissions necessary to perform its intended function.
Application examples
Two common ways of organising permissions are:
- Role-based access control (RBAC) – privileges are assigned based on the role of the user or system. Allowing server shell access to “Administrator” role is a good example.
- Attribute-based access control (ABAC) – privileges are assigned based on the attributes of the party. Allowing access to the internal resource only to users who come from the internal network is a good example.
Risks
Unauthorised access or action is considered a “High” risk.
Overly coarse/wide definition of privileges is a deviation from the principle of least privilege, and it may lead to unauthorised access.
Privileges are often assigned manually and become outdated. To combat that, periodic user access review is employed to ensure the permissions match the current users. The process could be automated to some extent, but human confirmation is often required.
A disgruntled employee could misuse their privileges to harm the company. Therefore, employee privileges should be promptly revoked upon termination. That could be automated via integration with the company’s HR system.
Roles with the most powerful privileges are called high-privileged roles. Misusing these permissions could do a lot of harm, so the high-privileged roles need special care. A good practice is to assign these roles on the short-term basis, implement additional authorisation, additional logging, and/or session recording.
Quirks
I often catch overlooked roles in the authorisation design. Here is the high-level checklist:
- Business users of the application (consumers)
- High-privileged business users (managers)
- Business partners (brokers or vendor support team)
- Developers and operational staff
- High-privileged operational staff
- System roles for API integrations
Similarly to authentication, authorisation can be sourced locally, centrally, or from a third-party identity provider. Centralised authorisation has the same benefits – reduced attack surface, ease of management and synchronisation.
Further reading
Please check out the map of cyber security controls below. It is simple yet awesome.
