Reference: IEC/TR 62443-3-1:2009 (ISA-TR99.00.01-2007), Clause 5.1
Related:
Clause 5
|
FR 2 Use Control
|
2-1 Clause 11
|
Active Directory
Technology categories: Overview | Cl. 5 | Cl. 6 | Cl. 7 | Cl. 8 | Cl. 9 | Cl. 10
Clause 5 pages: Cl. 5 | 5.1 RBAC | 5.2 Password | 5.3 Challenge/response | 5.4 Token | 5.5 Smart card | 5.6 Biometric | 5.7 Location | 5.8 Password management | 5.9 Device-to-device
Role-based access control (RBAC) attaches permissions to roles (job duties), then attaches people to those roles. Staff turn over faster than duties, so updating a role membership is cheaper and less error-prone than rewriting per-user permissions on thousands of DCS, HMI, historian, PLC and similar devices.
RBAC tools set, modify or remove authorisations in applications. They do not replace the login check: they do not authenticate a user on every access.
Per-user permissions go stale when employees leave and contractors rotate. Plants then disable device security or leave terminated staff able to act. RBAC reduces that window by managing access as roles (operator view-only, vendor engineer on one machine, and so on) and by allowing a central store with departmental assignment of people to roles.
Users map to roles; roles map to permissions. Graphical (often web) tools centralise the repository while operations, maintenance and instrumentation managers assign their people. Roles may also reflect location, project or management level.
Still useful as a design pattern even when a plant-wide product is absent. Teaching note: modern DCS and identity platforms now offer RBAC; the TR’s availability warning still applies.