Role-Based Access Control
Granting permissions to roles rather than individuals, so access follows job function and is easy to review and revoke.
Access by Job, Not by Person
Role-based access control (RBAC) assigns permissions to roles that reflect job functions, then assigns people to roles. An operator role might permit monitoring; an engineer role might permit configuration changes. Rather than granting rights to each person individually, you grant them once to a role and manage who holds it. This scales cleanly and makes access reviewable: you can ask what a role can do, and who holds that role.
Benefits
- Consistency: everyone in a role has exactly the same, defined access
- Auditability: reviewing roles is far easier than reviewing thousands of individual grants
- Fast onboarding and offboarding: change the role assignment, not dozens of permissions
- Least privilege: roles are scoped to the minimum a function needs
Separation of Duties
RBAC supports separation of duties: designing roles so that no single person can complete a sensitive action alone. The person who requests a change should not also be the one who approves it. This structural check limits both error and abuse, and it is enforced by how roles are defined and combined.
Role Explosion and ABAC
Poorly designed RBAC can proliferate into hundreds of narrow roles. Attribute-based access control (ABAC) addresses this by deciding on attributes, of the user, resource, and context, offering finer, more dynamic control at the cost of more complex policy. Many systems blend the two.
Fusion Context
In the Hyperion breeder and burner control designs, roles separate monitoring from command authority, and command authority over safety-relevant systems is a distinct, tightly held role. Separation of duties ensures that consequential actions require the right role and, where appropriate, more than one person, reinforcing least privilege across the plant's operators and engineers.