| Guideline: Role-Based Access Control |
|
 |
 |
|
| Related Elements |
|---|
|
Role-Based Access Control is an approach to restricting system access to authorized users, and also user access to services and data. It is used by the majority of medium to large enterprises, and can implement mandatory access control (MAC) and discretionary access control (DAC). RBAC is sometimes referred to as role-based security. Also see: RBAC and Whitepaper: A Reference Model for Enterprise Security. Roles in ContextA "roles-in-context" diagram is used to detail the interactions of roles and actors with the activities in the system. This example diagram is the ThuNorTech process Perform Lab Study, but is a simplified version showing only the relevant activities and with extraneous information removed, but with the roles added.
At the Technical level exception handling has been added and roles have been refined and optimized. Roles OptimizationGoing too granular with roles is difficult to manage, but aggregating roles too much is inflexible. Define an RBAC grid (see below) and analyze the options through various grid structures in terms of "users vs. actors vs. roles vs. activities". Once this is understood and finalized, the difficult and complex job of drilling down into individual user/actor/role actions and optimizing this becomes easier.
In the example above, for example, would it better for the "Kathleen:Agent" to have the "Check-in Agent" role, the "Ticket Agent" role, and "Agent Manager" role that is a sub-type of "Middle Manager". A whole set of analysis is done to understand and optimize this structure—this is at the heart of the Roles Model. This analysis often isn’t done or at best poorly understood. The end result is to define the mapping of users to roles and to the required privileges at the technical level—part of the Technical Roles Model. THe other part of this analysis is the optimization of the required user interfaces; the GUIs. A matrix is used to capture this RBAC information. Two kinds of matrixes are used, either the protected object centric or the set of protected objects presentation. They both capture the same information, but the latter may be more practical in terms of managing and using the information. Also see: Guideline: CRUD Matrix. RBAC permissions matrix for Protected Object “X”
RBAC permissions matrix for a set of Protected Objects
The following Role-Based Access Control table is from the ThuNorTech example IT architecture (see: Practice: Perform Lab Study TRM). It is quite a simple example, but illustrates the way in which these interactions may be analyzed and security aspects clarified and defined. Also, the further analysis done at the Technical level has simplified the roles and how they relate to the defined tasks. See the equivalent Logical Roles Model: Practice: Perform Lab Study LRM. Managers typically can use the same functions and features as their staff, therefore a lab manager (user) would assume (have) the "Lab Manager" role and the "Lab Team" and "Tech Writer" roles and all of the access and privileges that go along with them. Some users may also have view access to functions that they would not normally use during the course of their duties. RBAC (coarse) permissions matrix for "activity" Protected ObjectsThe activities in a process are in the first column, and associated with defined roles. At the Technical level the analysis of roles is complete and all possible optimizations defined; optimizations of roles and also of associated GUIs.
The "data constraint" column indicates that there is need for managing access to the "lab study" object from a
check-out and check-in perspective to avoid consistency and other problems. |
© David W. Enstrom, 2018. All rights reserved. |