RBAC (role-based access control) is a way of managing access in which permissions are granted to roles, such as Technician, Auditor or Finance, and people are given roles rather than individual permissions. When someone changes job, you change their role, and their access changes with it.
RBAC has three parts: users (people, and sometimes integration accounts), roles (bundles of access that match real jobs) and permissions (the actions a role allows, such as "post a disposal"). The model was formalized by NIST in the 1990s.
How RBAC works
- List the actions. Write down what people can do in the system: view, create, edit, delete, approve, configure, see cost data and so on.
- Group actions into roles. Each role matches a job, not a person. A Technician role might allow editing work orders and recording moves, but not seeing purchase cost.
- Assign users to roles. Most people need one role; a few need two.
- Check on every request. The system asks whether any of the user’s roles grants the action, and refuses it if not. The check must happen on the server, not only by hiding buttons.
- Review regularly. Confirm that each person still needs their role, and remove access for leavers on their last day.
Principles behind good RBAC
- Least privilege. Give each role the minimum access needed to do the job. A viewer who only runs reports should not be able to delete assets.
- Deny by default. Anything not explicitly granted is refused, so a new screen or field is protected until someone decides who needs it.
- Separation of duties. Split sensitive steps between roles. The person who records a disposal should not be the only person who can approve it.
RBAC vs ABAC vs ACL
| Item | RBAC | ABAC | ACL |
|---|---|---|---|
| Access decided by | The user’s role | Attributes of the user, the resource and the context, such as department, site or time | A list on each object naming who can do what with it |
| Example rule | Technicians can edit work orders | Technicians can edit work orders for assets at their own site | Folder X: Alice read, Bob read and write |
| Strength | Simple to set up, explain and audit | Very fine-grained and context-aware | Precise control of single objects |
| Weakness | Coarse; exceptions lead to many roles | Harder to design, test and explain | Unmanageable across thousands of records |
ABAC is attribute-based access control; ACL is an access control list. Many systems use RBAC as the baseline and layer attribute rules, such as "own site only", on top.
Example role matrix for asset management
| Action | Admin | Technician | Viewer |
|---|---|---|---|
| View assets, locations and reports | Yes | Yes | Yes |
| Create and edit assets | Yes | Edit only | No |
| Record moves, check-outs and returns | Yes | Yes | No |
| Create and update work orders | Yes | Yes | No |
| See cost, depreciation and disposals | Yes | No | No |
| Delete assets and tags | Yes | No | No |
| Manage readers, zones and alert rules | Yes | No | No |
| Manage users and roles | Yes | No | No |
RBAC in practice
- Hospital: biomedical engineers update maintenance records, ward staff look equipment up, and only finance sees cost.
- School or university: the IT technician issues and returns laptops, teachers can view what is in their rooms, and the bursar handles depreciation.
- Construction: the depot storekeeper checks tools in and out, site managers view their site, and an external auditor gets view and audit access for one quarter only.
Access reviews
An access review checks, on a schedule, that people still have the right roles. Export users and roles, have managers confirm or remove access, close leavers’ accounts and look for shared logins. With an audit trail, it shows both who can change data and who did.
Common mistakes
- Making everyone an admin to avoid permission questions.
- Forgetting integration accounts and devices. An API integration needs a role too, with only the permissions it uses.
Spreadsheets vs software
A shared spreadsheet only offers file-level access: view, comment or edit. Anyone with edit access can usually change the cost column, delete rows or copy the file, and you cannot hide purchase prices from someone who records moves. Software with RBAC checks each action and field on the server.
RBAC in Asetavo
Asetavo uses deny-by-default RBAC built from nine permissions: view, create, edit, delete, manage, finance, audit, devices and alerts. Admins combine them into roles such as admin, technician and viewer, and anything not granted is denied, in the web app and in the API. Finance fields such as cost, residual value and depreciation settings are stripped from writes unless the user holds finance. Device sessions can be revoked, and deactivating a user ends all of their sessions. Advanced roles come with the Business plan; see pricing, security and permissions in Asetavo and how Asetavo protects your data.
