Role Based Access Control - Overview

2. Contents 1 Introduction 1 2 What is Role Based Access Control? 2 2.1 Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 The NIST Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.3 Introducing Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 RBAC and Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.1 Batch Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.4.2 Change Control / Security Administration with Roles . . . . . . . . . . . . . . . . . 6 2.5 Approved Exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.6 Automatic Role Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.7 Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.8 Business Roles, Technical Roles and Role Hierarchy . . . . . . . . . . . . . . . . . . . . . . 11 2.9 Summary, RBAC Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Business Reasons for Deploying an RBAC System 14 3.1 Simplifying Security Change Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 Eliminating Privilege Accumulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Standardizing Security Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Cascading Changes to User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5 Simplifying Application Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.6 Coarse-Grained Separation of Duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4 RBAC Deployment Process 17 4.1 Role Modeling and Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.1.1 Top-Down (Roles from Business Function) . . . . . . . . . . . . . . . . . . . . . . 17 4.1.2 Bottom-Up (Roles from Technical Analysis) . . . . . . . . . . . . . . . . . . . . . . 17 4.1.3 Mixed Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2 Phased Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5 RBAC Ongoing Maintenance 20 5.1 Change Authorization Workﬂow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 i

3. RBAC: What, Why and How? 5.2 Periodic Certiﬁcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1 User Privileges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.2 Role Assignments and Approved Exceptions . . . . . . . . . . . . . . . . . . . . . 21 5.2.3 Role Deﬁnitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3 Managing Role Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.4 Adding Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.5 Retiring Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.6 System Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6 Organizational Impact 24 6.1 New Function: Role Analysts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2 Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3 Security Administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.4 End Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.5 The Help Desk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.6 IT Auditors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 APPENDICES 27 A About Hitachi ID Systems 28 © 2014 Hitachi ID Systems, Inc. All rights reserved.

4. RBAC: What, Why and How? 1 Introduction This document is intended to introduce readers to role based access control (RBAC), as applied to large numbers of users and multiple IT systems. It is organized into ﬁve distinct parts: 1. Development of RBAC concepts from a simple model to a complex but realistic privilege management infrastructure. 2. Business drivers to motivate organizations to use an RBAC system to manage security privileges. 3. Process for deploying RBAC into an organization. 4. Maintenance tasks for keeping a deployed RBAC system functioning smoothly. 5. Organizational impact of the deployment project and of the running RBAC system. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 1

5. RBAC: What, Why and How? 2 What is Role Based Access Control? 2.1 Definitions It is appropriate to start any discussion of role based access control (RBAC) with some definitions, to eliminate ambiguity. Following are some important concepts that will be used later: User The electronic representation of a human being or an automated service. Resource An IT asset – typically data or a function – which users may wish to access. Privilege The ability granted to a user to access a resource. Login account One type of privilege – a record that enables a user to sign into a particular system. Security group A type of resource. Privileges are often granted to security groups, as this is more efficient than assigning privileges to individual users. Group membership Another type of privilege – a record that indicates that a user belongs to a security group, and therefore has the privileges as those assigned to the security group. Target system A system containing resources and on which privileges are managed. For example, an Active Directory domain, a RACF security database, a database, an SAP R/3 system/client instance, etc. Security change request A request to change the privileges of a user. Requester The user who submits a change request. Recipient The user whose security privileges will be changed if a security change request is approved and applied. Authorizer A user who must approve a change request before it will be applied to the recipient. Security administrator A user with the ability to submit change requests that require no authorization. 2.2 The NIST Model Role based access control was popularized and given mathematical rigor by researchers working for the National Institute of Standards and Technologies. Their work on RBAC is available at the following web site: http://csrc.nist.gov/rbac/ The RBAC concepts in this document are loosely based on the definitions and concepts in the NIST RBAC work. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 2

6. RBAC: What, Why and How? 2.3 Introducing Roles To understand RBAC, one ﬁrst has to understand the administrative burden of assigning privileges to individual users. Consider an organization with 10,000 users and 10,000 resources and where each resource is accessed by an average of 20 users: 1. Security administrators must manage about 200,000 individual privileges (10,000 resources x 20 users). 2. An average user has about 20 privileges (200,000 privileges / 10,000 users). Continuing with this example, if users can be collected into groups of about 100 users each, where members of each user group have identical access requirements, then: 1. There will be about 100 groups of similar users (10,000 users / 100 users/group). 2. Each group of users will have the same number of privileges as any of its member users had – about 20. 3. In total, 2,000 individual privileges will have to be managed (100 groups x 20 privileges/group). 4. In addition, each user will have to be associated with a group – about 10,000 associations. In other words, if user privileges are highly regular, as in our example, then 200,000 privileges can be replaced by 2,000 privileges plus 10,000 user-to-group associations. This reduced complexity is the main motivation for RBAC. These concepts are illustrated in the following ﬁgures. 1. Managing a single user’s privileges is illustrated in Figure 1. Figure 1: A single user with privileges to multiple resources. 2. The same model, when scaled up to many users, creates administrative problems, as illustrated in Figure 2. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 3

7. RBAC: What, Why and How? Figure 2: Managing user privileges directly for many users. 3. If roles are introduced then managing privileges for a single user is slightly more complex than managing privileges directly. This is illustrated in Figure 3. Figure 3: Using a role to abstract a single user’s privileges. 4. Managing many users’ privileges is simpliﬁed by using roles, so long as many users have identical requirements. This is illustrated in Figure 4. Figure 4: Reducing administrative burden for similar users with roles. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 4

8. RBAC: What, Why and How? 2.4 RBAC and Enforcement RBAC is not built into every application. Moreover, few off-the-shelf applications are able to externalize their runtime security enforcement decisions (i.e., “is user X allowed to access resource Y?”). As a result, RBAC is typically overlaid on top of existing security models. This is done as follows: 1. Define roles as collections of privileges to access resources, where each privilege exists on a single application. 2. Assign roles to users. 3. Using this model, predict which users should get which privileges on each application. 4. Extract from each application a list of privileges that each user actually has. 5. Calculate the difference between the predicted and actual user privileges. 6. Correct user privileges on each system, to make them match privileges predicted by each user’s assigned roles. This enforcement process may be implemented in two ways: 1. Batch enforcement: the process is applied to every user, regularly. An example is an automated nightly process that brings users into compliance with the role model. 2. Change control / security administration: the security management user interface is changed so that users or security administrators choose roles for recipients, rather than individual privileges. 2.4.1 Batch Enforcement Batch enforcement is illustrated in greater detail in Figure 5. In the Figure: 1. An automated process runs connectors to extract a list of users, resources and privileges from each target system. 2. User assignment to roles is combined with role definitions to predict the privileges that each user should have. 3. Actual user privileges, as discovered on target systems in the first step, are compared to predicted privileges. 4. Any differences between actual and predicted user privileges are applied back to target systems, to remove the variance and bring actual user privileges into compliance with the role model. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 5

9. RBAC: What, Why and How? Figure 5: Simple batch enforcement of RBAC privilege model. 2.4.2 Change Control / Security Administration with Roles Normally batch enforcement is combined with a role-centric security management process. The idea is to replace security administration by assigning individual privileges to users with assignment of roles to users. This is illustrated in Figure 6. In the Figure: 1. If a self-service work-ﬂow system is used, end users request and approve changes. 2. Security administrators make direct changes (without waiting for authorization). 3. All changes are expressed in terms of roles. For example: (a) Create new user X using role R. (b) Delete user X (i.e., remove all roles from user X). (c) Remove role R1 from user X and add R2. 4. The RBAC engine maps role changes such as the above, to privilege changes (create/delete login © 2014 Hitachi ID Systems, Inc.. All rights reserved. 6

10. RBAC: What, Why and How? Figure 6: Security administration using roles. IDs, attach users to security groups on target systems, remove users from security groups on target systems). 5. Connectors apply those changes to target systems. 2.5 Approved Exceptions The simple model described in Subsection 2.3 on Page 3 and Subsection 2.4 on Page 5 can be quite difﬁcult to manage in practice, since user privilege requirements are often unique. If every user has at least one unique requirement, and a pure role model such as the one described in Subsection 2.3 on Page 3 is used, then there will be as many roles as there are users. When this happens, RBAC adds a layer of complexity without providing any leverage to simplify user administration. In other words, as the number of roles approaches the number of users, RBAC reverts to direct user management and provides no beneﬁt. To address this issue, practical RBAC systems should incorporate a concept of approved exceptions. This allows users to have privileges that diverge from what their role assignment predicts and for the organization to approve these exceptions, so that the enforcement engine (shown in Figure 5 on Page 6) does not “correct” those variances. A user’s privileges may vary from what his assigned roles predict in several ways: 1. Extra account: The user may have an extra login account. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 7

11. RBAC: What, Why and How? 2. Extra group: The user may have an extra membership in a security group. 3. Missing account: The role may call for a login account on a system to which the user does not have access. 4. Missing group: The role may call for a security group membership which the user does not have. By incorporating support for approved exceptions, users whose privilege requirements closely resemble but do not perfectly match a role’s definition can be assigned an existing role, rather than requiring that a new role be defined to capture the user’s exact requirements. This can significantly reduce the number of roles needed to implement RBAC in an organization. User privilege management with a combination of roles and approved exceptions is illustrated in Figure 7. Figure 7: Privilege management with a combination of roles and approved exceptions The enforcement engine must then be enhanced, to remove approved exceptions from the corrections that are applied to target systems. This is illustrated in Figure 8. The administration user interface must also change, as it must now be able to manage the set of approved exceptions as well as user-to-role assignments. This is illustrated in Figure 9. 2.6 Automatic Role Assignment A useful improvement to the basic role model described in Subsection 2.3 on Page 3 and Subsection 2.4 on Page 5 is to replace manual assignment of roles to users with an automated process. In short, if a user’s role can be predicted based on other user attributes – such as the user’s location, department, job title, etc., then it makes sense to automate role assignment and further simplify security administration. Automated role assignment normally takes the form of boolean expressions or simple rules. For example, “every user in department D1 and job code J1 should get role R1.” RBAC enforcement using rules to automatically assign roles to users is illustrated in Figure 10. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 8

12. RBAC: What, Why and How? Figure 8: Batch enforcement of RBAC privilege model with exceptions. Figure 9: Security administration using roles and exceptions. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 9

14. RBAC: What, Why and How? 2.7 Separation of Duties Another improvement to the role model is to introduce policies regarding separation of duties (SoD). Sepa- ration of duties rules are intended to prevent fraud, by requiring that two different people in an organization perform work on a transaction to complete it. This reduces the likelihood of fraud by requiring collusion by at least two parties. An example of separation of duties is a requirement that the same individual cannot simultaneously approve an invoice and issue payment for that invoice. Separation of duties may be static – i.e., reflected in the type of transactions that a user may perform, or dynamic – i.e., a requirement that distinct individuals perform different tasks relating to the same transaction, but without necessarily limiting which individuals are allowed to perform which tasks. Continuing with the example above, with static enforcement of separation of duties, one group of workers may be allowed to approve invoices while another group may be allowed to issue payments. The same individual cannot be assigned to both groups. Alternately, with dynamic enforcement of separation of duties, a single group of workers may be allowed both to approve invoices and issue payments, but the same individual cannot perform both functions on the same transaction. Role-based access control can be used to enforce static separation of duties rules. To do this, rules are introduced that specify roles or privileges that cannot be simultaneously assigned to the same user. The security administration user interface must be aware of these rules and prevent assignment of conflicting roles or privileges to the same user. The batch enforcement process can scan for users who have, through some out-of-band process, acquired roles or privileges that violate policy. It can then either remove all such roles or privileges or – taking a less disruptive approach – warn a security officer of the policy violation and wait for a human being to either correct the offending privileges or adjust the policy. Note that RBAC cannot enforce transactional or dynamic separation of duties rules – that can only be done by the applications themselves. Separation of duties rules may also allow for approved exceptions – i.e., specific users are allowed to have roles or privileges that violate the policy, perhaps for a limited period. RBAC enforcement using separation of duties rules is illustrated in Figure 11. 2.8 Business Roles, Technical Roles and Role Hierarchy Roles may be thought of as the intersection between business responsibilities and the technical privileges needed to fulfill them. Nevertheless, it may be helpful to think about roles either as primarily business oriented – i.e., business roles that represent job functions or responsibilities, or as primarily technical – i.e., collections of privileges that are shared by groups of like users. One way to combine these approaches is to introduce a role hierarchy. To do this, the definition of a role from Subsection 2.3 on Page 3 is extended to allow roles to include other roles, in addition to discrete privileges (login accounts and group memberships). Using a role hierarchy, business roles can be defined by nontechnical workers, to represent job functions. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 11

15. RBAC: What, Why and How? Figure 11: Batch enforcement with separation of duties. IT workers can define technical roles, to represent commonly assigned sets of privileges. The two types of roles are combined using a hierarchy, where business roles incorporate technical rules. Using a role hierarchy can reduce the work required to construct and maintain the privilege model, since one role is often the same as another, plus some extra privileges. A role hierarchy can also be useful to model an organizational hierarchy. For example, a manager’s role may be the same as that of his immediate subordinates, plus some additional “manager only” privileges. Rather than creating a whole new role for the manager from scratch, it can be more convenient to define the manager’s role as a combination of the roles of his subordinates plus extra privileges that are relevant only to the manager. 2.9 Summary, RBAC Artifacts The preceding sections introduced a broad array of concepts that, together, form an RBAC system. These concepts are summarized here: Role A collection of privileges that may be assigned to one or more users. Business role A collection of similar users. Technical role A collection of privileges that are often assigned to users concurrently. Role hierarchy Role definitions that allow one role to include another. Variance The difference between a user’s actual privileges on target systems and the privileges that the role model predicts the user should have. Role enforcement A process that identifies variances and attempts to eliminate them on target systems. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 12

16. RBAC: What, Why and How? Approved exception A variance that has been approved, such that the role enforcement engine will ignore it. Identity attribute Informational data about users, such as their name, location, department, job code, etc. Automatic role assignment A set of rules, based on users’ identity attributes, used to automatically assign roles to users. Separation of duties A set of rules deﬁning mutually exclusive roles or resources, typically used to prevent fraud. Enforcement of an RBAC policy that includes separation of duties and automatic role assignment, with an allowance for approved exceptions, is illustrated in Figure 11 on Page 12. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 13

17. RBAC: What, Why and How? 3 Business Reasons for Deploying an RBAC System Organizations may pursue a role based approach to managing security privileges for a number of reasons, as described in the following sections. 3.1 Simplifying Security Change Requests Most users are not familiar with the technical details of what security rights are required to perform a given business function. As a result, when they request security changes – such as creation of a new security profile for a new employee or changes to an existing user’s profile to reflect new responsibilities – they typically make a request with a reference to an existing user with the appropriate privileges. For example, a manager might request that a new hire be given the same privileges as another, existing user, because the new hire will perform the same job function as the existing user. This approach – of cloning an existing user when creating a new user – is undesirable since the existing user’s profile may have accumulated no-longer-appropriate security privileges over time. By cloning such a profile, inappropriate privileges which were previously assigned to just one user are now assigned to two, which magnifies the problem. A preferable approach is to enable those users who make security requests to make those requests in terms of a business function, which they do understand. If roles are named after well understood business functions, or if roles are automatically assigned to users based on their documented business function, then it is easier for users to submit correct security change requests. 3.2 Eliminating Privilege Accumulation Periodically, users’ security needs change. This happens when users are promoted, transferred, change job functions, relocate, etc. These business events normally trigger security change requests. When security administrators receive change requests, they often add new privileges but cannot safely remove old (unneeded) ones. This is because security administrators do not normally have complete knowledge of a user’s job function or requirements, so they cannot tell which of a user’s old privileges are still required and which can be safely removed. This problem is illustrated in Figure 12. The outcome of this change management process is that users accumulate privileges over time, rarely relinquishing them. This can lead to violation of policies such as separation of duties (See Subsection 2.7 on Page 11). By deploying RBAC, it is possible to associate each of the security privileges of a given user with roles. Changes in business responsibilities then map to changes in role assignments, and it is possible to determine which old privileges can be safely removed. This is illustrated in Figure 13. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 14

18. RBAC: What, Why and How? Figure 12: Without RBAC, changes in user responsibility lead toprivilege accumulation. Figure 13: With RBAC, it is possible to determine which old privileges can besafely removed. 3.3 Standardizing Security Privileges When security privileges are manually assigned to users, different users with the same job function may be inadvertently assigned different privileges. This is the result of human error and of different security administrators having a different understanding of requirements at different times. Organizations wishing to standardize user privileges based on job functions may deploy an RBAC system in order to deﬁne those standards and ensure that users are assigned privileges based on policy, rather than the judgment of security administrators. 3.4 Cascading Changes to User Privileges If user privileges are modeled using roles, then it becomes possible to change a role deﬁnition and have that change apply to all users who have been assigned that role. For example, if users in a given role should © 2014 Hitachi ID Systems, Inc.. All rights reserved. 15

19. RBAC: What, Why and How? all be granted access to a new application or security group, then it suffices to change the role definition to include the new privilege and run the enforcement engine. The engine will then detect violations for the users in question (missing privilege in this example) and make suitable corrections. 3.5 Simplifying Application Migrations Systems and applications change. Old applications inevitably are either upgraded or replaced. When this happens, users who had access to an old application have to be granted access to new ones. When user privileges are managed directly, reprovisioning them is a big job. When RBAC is used, migrations can be as simple as changing the role definitions that apply to users of the old application to include access rights on the new application. Once this is done, the enforcement engine will cascade the security changes from the role to the users, automatically granting all the appropriate users access to the new application. This reduces the effort required to migrate users from an old to a new application. 3.6 Coarse-Grained Separation of Duties While separation of duties rules may be applied directly to fine-grained privileges, some organizations prefer to articulate rules in the form “users assigned role R1 may not also be assigned role R2.” For this to work, roles must be defined and users assigned roles – i.e., security management using RBAC. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 16

20. RBAC: What, Why and How? 4 RBAC Deployment Process RBAC is normally implemented by an organization to supplement or replace a pre-existing process for managing users and privileges. Consequently, a process is required to migrate from fine-grained administration to RBAC. 4.1 Role Modeling and Mining The first step in implementing an RBAC system is to define roles (i.e., named collections of privileges) and to assign roles to users. This creates a model predicting the privileges that each user should have. The process of developing a set of roles and assigning them to users is called role modeling. Role modeling may be carried out by analyzing existing user privileges – i.e., by looking for sets of users and privileges that already exhibit role-like connections. Analysis of existing user privileges as a means to defining and assigning roles is called role mining. 4.1.1 Top-Down (Roles from Business Function) One approach to role modeling is to use a set of identity attributes to identify users whose security privileges ought to be similar. The identity attributes may be things like department code, location code, job code, etc. Users whose identity attributes have the same value (i.e., same department, same location, same job code, etc.) are expected to have the same privileges and therefore the same role. In top-down analysis, first every meaningful combination of the key identity attributes is identified. For every such combination, appropriate privileges are defined. Actual user privileges are then corrected so that they match the role model. This approach can yield not only a role definition but also a rule for automatically assigning the role to users, as described in Subsection 2.6 on Page 8. The main weakness of this approach is that while business users (typically managers) can articulate that a given set of users perform the same job function and therefore should have the same role, they normally do not know what security privileges those users need. A second problem with this approach is that mistakes can easily be made when defining a role “from scratch.” When the RBAC engine applies a mis-configured role to users, privileges that the users need for their jobs will be (mistakenly) removed and work will be interrupted until the role definition is corrected. 4.1.2 Bottom-Up (Roles from Technical Analysis) Another approach to role modeling is to look for clusters of users who have identical, or at least very similar privileges. These clusters represent candidate roles: 1. The privileges shared by the users in question constitute a role definition. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 17

21. RBAC: What, Why and How? 2. The users in the cluster assigned the new role. If the users have the same identity attributes, then a rule can also be drafted to automatically apply the new role to similar users in the future. Weaknesses of this approach include: 1. Users who ought to have identical privileges often do not, because of privilege accumulation, incon- sistent security administration, etc. A technical analysis will fail to identify such users as candidates for a new role. 2. It is possible for users who actually have different business responsibilities to have very similar privileges. In this case, a bottom-up analysis might mistakenly identify them as candidates for a shared role. 3. A technical analysis identifies users who have similar privileges, but cannot distinguish between privileges that users happen to have from those that they actually need. As a result, it can yield roles that contain more privileges than actually required. 4.1.3 Mixed Analysis The problems with a purely bottom-up and a purely top-down approach are due to data quality (up to 30% of privileges assigned to users may be inappropriate) and to a disconnect between a technical analysis (of privileges) and a business analysis (of users who do the same job). A third approach is therefore to try to combine the business and technical analysis. For example, managers might identify users who report to them and are expected to perform the same business function. Once such clusters of like users have been identified, a technical role analyst can compare the privileges of users in the cluster. Privileges that they have in common may form the basis of a role, while privileges that differ may be inappropriate (should be corrected) or required (should be approved as exceptions). This approach is generally more practical than either a purely top-down or a purely bottom-up approach: 1. It leverages the knowledge of both business users and technicians. 2. It can yield corrections to current privileges, in addition to role definitions and user-to-role classifica- tion. 3. It can yield approved exceptions, where current user privileges are correct but are not precisely mapped out by a coarse grained role model. 4. It at least has the potential to identify privileges that, while shared by a group of like users prior to deployment, are not actually needed by those users. 4.2 Phased Deployment It can months or even years to complete a role modeling project, yielding role definitions, user-to-role assignment, rules to auto-assign roles and approved exceptions for every user in a large organization. Such © 2014 Hitachi ID Systems, Inc.. All rights reserved. 18

22. RBAC: What, Why and How? a lengthy deployment process, combined with constant change in organizations, means that the model may never be 100% complete. This means that it makes sense to start applying the role model to users – i.e., to start enforcement – before the role model is complete. To do this, a mechanism is required to limit the scope of enforcement to cover just those users and resources that have been fully analyzed. Without such a mechanism, the enforcement engine would incorrectly conclude that users who have not yet been analyzed should have no privileges, and deprovision them. A simple approach to phased deployment is to set a ﬂag on each user, which indicates whether or not the user should be impacted by the RBAC enforcement engine. The ﬂag should be set for every user that has passed through the role modeling process. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 19

23. RBAC: What, Why and How? 5 RBAC Ongoing Maintenance Once an RBAC system has been deployed, it requires ongoing maintenance. Without this, over time, business rules, role definitions, user to role assignments and more will become obsolete and the system will enforce the wrong rules, for the wrong users, at the wrong time. If that happens, the RBAC system will no longer bring benefit to the organization, but rather create problems for security administrators. The following sections highlight some of the ongoing maintenance tasks required. 5.1 Change Authorization Workflow Required changes to user privileges identified by the RBAC enforcement engine may have to be approved before they are applied to actual user profiles on target systems. Changes may include: 1. Creating a new login ID for a user. 2. Attaching a user to a security group. 3. Disabling or deleting an existing login ID. 4. Removing a user from a group. 5. Approving exceptions to the model: (a) Extra login IDs. (b) Extra group memberships. (c) Missing login IDs. (d) Missing group memberships. Such changes must be subjected to authorization business logic: 1. Authorization required? Is approval by business users required before the change will take effect? 2. Selecting authorizers (request routing): If approval is required, by whom? 3. Consensus: If multiple authorizers are identified, how many of them are sufficient to approve a given change request? (e.g., 2 of 5). 4. Veto: If an authorizer rejects a request, does that block it entirely, or does it only block those resources for which that authorizer is responsible? © 2014 Hitachi ID Systems, Inc.. All rights reserved. 20

24. RBAC: What, Why and How? 5. Reminder timing: If authorizers fail to respond, how often should they be reminded? 6. Escalation path: If authorizers fail to respond for an extended period of time, what alternate authorizers should be selected to act in their place? Over time, the business rules regarding authorization will change. It is the responsibility of the RBAC system administrator to ensure that these rules continue to reflect business needs. 5.2 Periodic Certification It makes sense to periodically review both user security rights and the role model itself, to ensure that both are configured in a manner that is appropriate to current business needs. Such periodic reviews are called certifications and may be carried out as follows: 5.2.1 User Privileges This is a certification of the specific privileges – i.e., login accounts and membership in security groups – assigned to individual users. This type of certification does not require an role model and may be carried out prior to development of the role model. Running a detailed review and cleanup of user privileges prior to role modeling reduces the number of inappropriate privileges held by users and consequently makes bottom-up role modeling easier, since users who ought to have the same privileges are more likely to actually have the same privileges after the cleanup. User privilege certification may be carried out by managers (i.e., reviewing their direct reports), by application owners (i.e., of users who have login IDs on their applications) or by group owners (i.e., of membership in their groups). 5.2.2 Role Assignments and Approved Exceptions Individual users typically have many fine-grained entitlements, but only one or two assigned roles and few if any approved exceptions. It can be easier for managers to certify users’ role assignments plus approved exceptions than privileges. 5.2.3 Role Definitions In addition to reviewing and either certifying or correcting user assignment to roles and approved exceptions, it makes sense to also periodically review the definitions of the roles themselves – i.e., are they still appropriate? This sort of review should be carried out by role owners, who may be managers in the case of organizational roles or technical staff (such as application administrators) in the case of technical roles. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 21

25. RBAC: What, Why and How? 5.3 Managing Role Changes One of the reasons for deploying an RBAC system is to have security privileges assigned to users more quickly and reliably reflect changes in the business responsibilities of users. Technically, this means managing changes in user-role assignment. When a user changes roles, some of his old privileges should be removed, others should be retained and new privileges should be added. This is illustrated in Figure 13. One problem that may arise during role changes is determining precisely when to remove old privileges, that appear in the old role but not the new one. This is a problem because when users change jobs, they often continue to perform their old job in some backup capacity, for some time. Three ways to handle this are: 1. Remove the old privileges immediately, essentially preventing reassigned users from assisting their replacements. 2. Keep the old role for some time, and remove it when it is really no longer required. The problem with this approach is that end users do not volunteer to remove old privileges, so may never ask to remove the old role. Certification, as described in Subsubsection 5.2.2 on Page 21 may be the main solution to this problem. 3. Remove the old role immediately but defer removal of privileges associated with that role. For example, the enforcement engine could detect that a user no longer requires a privilege, but instead of removing it immediately, could submit a security change request to the authorization workflow to remove the privilege at a later date (e.g., in 30 days). 5.4 Adding Applications Applications may be added to the role model either because of a phased deployment (i.e., the application was in use prior to the RBAC system but integration was deferred) or because they are new. In either case, an important part of the ongoing maintenance of any RBAC system is a process to add applications. When this is done: 1. New roles may be defined, relating purely to the new application. 2. Existing roles may be extended, to include access to the application. 3. Existing roles may be split into two or more more new roles, since users in the old role may have the same privilege requirements everywhere except on the new application. The last point above is especially problematic, since it can cause an explosion in the number of roles as new applications are added. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 22

26. RBAC: What, Why and How? 5.5 Retiring Applications When applications that were already part of the RBAC system are retired, they must be promptly removed from the model. Otherwise, the enforcement engine will continually raise exceptions about users not having logins on the (now gone) application. Retiring applications can lead to role consolidation, where roles that previously differed only in terms of privileges within the retired application become identical. 5.6 System Migrations Applications are often migrated from one version or product to another. Migrations impact the role model in exactly the same way as (a) removing an old application and (b) adding a new application. In other words, they can be implemented by changing role deﬁnitions and allowing the RBAC engine to cascade the changes to user proﬁles. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 23

27. RBAC: What, Why and How? 6 Organizational Impact Using a role-based access control strategy to manage the security privileges of users has wide-ranging impact on how an organization functions: 6.1 New Function: Role Analysts The most obvious impact, evident when an RBAC project begins, is that a new business function is required – that of role analysts. Some organizations attempt to delegate the tasks of developing role definitions, of assigning roles to users and of approving exceptional privileges to managers or IT staff. In practice, such delegation is often unsat- isfactory: 1. Managers do not understand the technical requirements of their subordinates. While they can identify which of their subordinates perform the same job function, they normally cannot say what security privileges those employees and contractors require. 2. IT staff, such as system administrators and application owners, are often able to match security privileges, such as login accounts and membership in security groups, to functional capabilities in each application, but they cannot say with confidence which users in the business organization should have access to those functions or data. The role analyst’s function is therefore to bridge the gap between business-savvy but technically-ignorant managers and technically-savvy but business-ignorant IT staff. Hiring and retaining role analysts can be expensive and this is one of the fundamental costs of an RBAC deployment. As a very rough measure, one might estimate that an average role will have ten members and will require an hour of a role analyst’s time to develop plus 30 minutes per year to review and correct. Using these metrics, we can estimate that in an organization with 20,000 users: 1. There will be about 2,000 fine-grained roles. 2. About 2,000 hours, or about one person-year, will be required to develop the roles. 3. About 1,000 hours/year, or about 1/2 of an FTE, will be required to maintain the role model after it is fully deployed. 4. Since most organizations evolve rapidly, it may make sense to hire 3 or 4 role analysts for a few months, and retain one in a permanent capacity. It should be noted that the above figures are intended only to give a sense of the order of magnitude of the role modeling task, rather than to predict the exact effort required in any single organization. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 24

28. RBAC: What, Why and How? 6.2 Managers When an RBAC system is first deployed, each manager is likely to be contacted to assist in the development of the role model: 1. In some organizations, there is no complete or reliable data connecting users to their direct managers. Managers may therefore be asked to review and correct org-chart data before any other analysis can proceed. 2. At a minimum, managers should indicate which of their direct subordinates share the same job function (and so should be assigned a single role). 3. A role analyst will typically point out various discrepancies, where users who supposedly perform the same job function actually have different security rights. In each case, the manager will have to: (a) Indicate that the variance is likely an error, and should be corrected; or (b) Indicate that the user, in reality, does not perform the same job function as his previously identified peers, and should be assigned a different role; or (c) Indicate that the user does perform largely the same function as his previously identified peers, but does have a minor difference in responsibilities, which should be approved as an exception; or (d) Indicate that the variance is inconsequential, and should be approved not only for this user, but for any other user in the same nominal job function. Once the RBAC system has been deployed, managers will have to use it: 1. When requesting access for new employees or contractors, they will have to choose a role. In most organizations this is different from previous methods, such as instructing the help desk to create a new user profile “just like” an existing user. 2. When requesting that an employee or contractor be transferred from one job function to another, managers should specify whether and for how long the user’s old roles should be retained, which new roles to assign and when to assign them. 3. Periodically, managers should be asked to review user privileges, which will be expressed in terms of role assignments and approved exceptions, rather than in terms of fine-grained security privileges assigned to each user. 4. Some managers may be designated “role owners” and should periodically be asked to review the set of privileges assigned to each role for which they are responsible and the list of users who have been assigned that role. 6.3 Security Administrators Once an RBAC system has been implemented, security administrators will be asked to stop managing user privileges directly and instead assign roles to users. This means an end to routine use of native security administration tools and learning to use the RBAC system’s console instead. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 25

29. RBAC: What, Why and How? 6.4 End Users During the RBAC system’s deployment process, user privileges will be corrected in order to bring them into compliance with the role model. Inevitably, mistakes will be made, which means that users will be assigned excessive or inadequate privileges: 1. If users are assigned excessive privileges, they will likely not notice. Note: this is a security problem, rather than a usability problem for users. 2. If needed user privileges are mistakenly removed, users will be unable to use applications to perform their job functions. These users will lose productivity and will call the help desk for assistance. 6.5 The Help Desk The help desk organization must be aware of the RBAC deployment project, since users will inevitably lose some required privileges and will call for assistance: 1. It is helpful for role analysts to notify the help desk of which users have been added to the role model, when they were added and what security rights were added to or removed from each user. 2. Help desk analysts must be trained to identify problems that may have resulted from inappropriate changes to user privileges. 3. Help desk analysts should know how to check whether a given help desk caller had recently been impacted by the RBAC deployment and - if so - what changes were made. 4. Help desk analysts must be able to escalate security problems to the role analyst, who must be able to correct such problems. 6.6 IT Auditors Auditors beneﬁt from an RBAC system because they can review what security privileges a group of users is supposed to have, in addition to what they were previously able to do – namely to review what security privileges individual users do have. While not strictly a part of the RBAC system, a feature that often accompanies RBAC is enforcement of separation of duties policies, as described in Subsection 2.7 on Page 11. With this features, auditors are able to review SoD rules as well as role deﬁnitions and role assignments. © 2014 Hitachi ID Systems, Inc.. All rights reserved. 26

31. RBAC: What, Why and How? A About Hitachi ID Systems This white paper was written and published by Hitachi ID Systems – an identity management software vendor. Hitachi ID Systems publishes a range of identity management software, including Hitachi ID Identity Manager: a user provisioning program capable of implementing role based access control spanning multiple IT systems. To learn more about Hitachi ID Systems, please visit http://Hitachi-ID.com/ To learn more about Identity Manager, please visit http://Hitachi-ID.com/Identity-Manager/ © 2014 Hitachi ID Systems, Inc.. All rights reserved. 28

32. RBAC: What, Why and How? www.Hitachi-ID.com 500, 1401 - 1 Street SE, Calgary AB Canada T2G 2J3 Tel: 1.403.233.0740 Fax: 1.403.233.0725 E-Mail: sales@Hitachi-ID.com File: /pub/wp/documents/rbac-overview/rbac-overview-3.tex Date: 2007-11-24

Role Based Access Control - Overview

Esté a ler uma amostra.

Confira estes a seguir

Role Based Access Control - Overview

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (15)

Semelhante a Role Based Access Control - Overview (20)

Mais de Hitachi ID Systems, Inc. (20)

Mais recentes (20)