Role-based Access Control in a RACF environment

Transcription

1 Role-based Access Control in a RACF environment An investigation of some possibilities for enhancements Lennie Dymoke-Bradshaw June 2011 With contributions from Alan Harrison and GSE UK Security Working Group

2 Role based Access In the past RACF has dealt with users as individuals. It has been assumed that each user might require individually tailored access levels and permissions. This has served well in the past, but requirements have changed. Todays environment must deal with A Rapidly changing workforce A need for responsibilities to be managed independently of people A far tighter need for audit controls A more consistent alignment of security requirements with personnel structures More regular and tighter compliance reporting Requirements for a more readily understandable view of permissions A role-based access control system can provide much of this, but RACF is not best placed to take advantage. We recognise there may be situations in which a single user inhabits a Job role. However there are still advantages to maintaining Job roles (responsibilities) independently of users (people).

3 How does access control work with RACF currently? RACF current uses a user-based model for managing access to resources. Each resource profile has an access list, and there are entries in each access list granting or denying access. These entries can be for the USER. Each USER must also be a member of at least one GROUP. The GROUP may also be used in an access list (but the USER entry takes precedence if present). If a USER is a member of more than one GROUP, and multiple GROUPs are in an access list, then the entry with the highest access takes precedence. This processing can be altered by negating the system-wide option List of Groups, but this is rarely seen nowadays. Each USER profile also has other privileges, authorities and attributes such as AUDITOR, RESTRICTED, PROTECTED, CLAUTH. Each USER profile has attributes related to USER Segments. These apply information and controls for other operating system and subsystem components. Examples are TSO, CICS, OMVS. Some resource profiles have a second access list called the Conditional Access list. If access is not granted by the standard access list then it may be granted by this second list which includes various conditions.

4 What challenges are faced by RACF installations in attempting to implement Role-Based Access? Most enterprises using z/os (or z/vm) maintain large RACF databases with a large number of users. These organisation typically have a large turnover of staff, so that the creation, deletion and modification of user definitions is a major part of the security administration. In many cases, attempts have been made to organise using a Role-Based approach, but this frequently involves many controls outside of RACF, and special processes or panels written to achieve this. These are some of the issues facing such organisations. 1. The Creation of a new user profile is frequently performed by using an existing user as a model. However, there are no controls to ensure that all users with a Job role have the same access or attributes. 2. While this process of creating a userid using another userid as a model can be performed using priced RACF add-on packages, or home-grown routines, there is no functionality within the base product. 3. Some installations create specialised USER profiles to act as these Job roles, but these can be a security exposure as they are not associated with any particular person, but can still be used to gain access to resources. 4. There is no function available to compare one User profile with another, to confirm adherence to the Role Based approach 5. When temporary access is required, it is frequently granted, and then not withdrawn, but only from a single user, thus breaking the Role-Based relationships.

5 What challenges are faced by RACF installations in attempting to implement Role-Based Access? Continued. 6. When access changes are needed to a Job role this may be achieved by granting access to a group. In this case the Role-Based access is maintained. However, if is performed by connecting a user to a new group, then all users within the Job role need to have the same CONNECT command issued. Note that if access was granted to a resource by placing a group in an access list, then this may alter access for more than one Job role. 7. When a Job role has to be split, such as when a small number of people are given some administrative responsibility there is no simple way for this to be achieved. 8. There is no current method of grouping all the users within a Job role, other than using a naming convention or some other locally devised construct. 9. If members of the Job role have attributes not associated with Access, such as Auditor, Special, Restricted or have CLAUTH authorities, then these have to be separately managed. 10. If User profiles are to have attributes and capabilities set via RACF segments other than the base segment (e.g. for TSO, CICS or OMVS) then further processes have to be put in place to manage this. 11. If access to a resource is granted at the User level then this frequently breaks the Role Based approach. 12. If an installation defined Role Based access method is devised, then separate controls have to be in place to determine which users have authority to modify the authorities of the Role.

6 What benefits could accrue if Role Based controls were built into RACF? a. The set of Job roles can largely be derived from a personnel chart. b. The attributes of each Job role can be decided more easily by examination of the Job role s responsibilities. c. The Job roles can be maintained and managed using less commands. d. The assignment of users to Job roles can become a more easily managed task. e. The comparison of authorities between Users and Job roles can be more easily achieved. f. The examination of the capabilities of a particular User can be derived from the associated Job role definition. g. The moving of a User from one Job role to another is more easily achieved. h. The decommissioning of Users can be more easily achieved. i. The creation and deletion of Job roles can be more easily achieved. j. The adjustment of access for a Job role can be achieved in a more consistent manner. k. The assignment of special privileges or restrictions can be more consistently managed. l. The management of RACF Segments associated with Users can be achieved more easily and more consistently. This will result in, 1) more accurate reporting of roles and responsibilities. 2) Simplified auditing of roles and users 3) More confidence in the ability to report discrepancies

7 Terminology Role or Job role This defines the responsibilities of a number of people usually within a personnel chart or organisation chart. A collection of permissions Permissions (object-action pairs) Access list entries granted by PERMIT command User and Group attributes SPECIAL, PROTECTED, RESTRICTED, NOTERMUACC, etc CLAUTH values INTERVAL values Auditing flags

8 Proposal 1: TEMPLATE user The first approach we discuss uses a new attribute for the USER profile which for now we shall refer to as a TEMPLATE attribute. 1. A USER profile having the TEMPLATE attribute cannot be used in any authorisation decision. It cannot be used to logon, start a started task, run a batch job, or be used in a RACROUTE REQUEST=VERIFY macro, which results in the running of work. 2. A new process here called UserCopy will be provided to create a USER profile from a USER profile with the TEMPLATE attribute. 3. A new process here called UserCompare will be provided to compare one USER profile with another and produce either, A list of differences, or A set of commands to reconcile the differences

9 Proposal 1: TEMPLATE user with UserCopy process Request for new user called BILL for Role Clerk User: Clerk (Template) UserCopy User: Bill During the UserCopy process all attributes and permissions from Clerk are copied to Bill. Group connections and authorities are copied Segments are copied There has to be a customisable masking mechanism to specify those items which are required to be unique to users Name UID Home directories other fields (e.g. in CSDATA segments)

10 Proposal 1: TEMPLATE user with UserCompare process User: Bill User: Clerk (Template) UserCompare List of differences between Bill and Clerk (and optionally commands to reconcile differences) During the UserCompare process all attributes and permissions from Clerk are compared to Bill. Group connections and authorities are compared Segments are compared There has to be a masking mechanism to specify those items which are required to be unique to users Name UID Home directories other fields (e.g. in CSDATA segments)

11 Proposal 1: TEMPLATE user This approach provides a mechanism for most installations to introduce a Role-Based system, and provides basic tools for the maintenance of the Users within each role. If a USER profile has changes made to it which fall outside the Job role definition (as defined by the TEMPLATE user profile), then we have mechanisms to bring matters back into line. However, this would provide a system which cannot be mandated. It still needs regular checking to ensure that USER profiles do not diverge from TEMPLATE user profiles. There is no automatic adjustment of permissions, and the permissions are still held at the USER level, when really they should be held at the Job role level. For this reason we have an alternate proposal for a mechanism which can be used to manage permissions and attributes in a more consistent manner.

12 Proposal 2: New RACF Construct: Jobrole The second approach we discuss uses a new construct. The nature of this construct we do not mandate in any sense. It could be managed using a new RACF class. It could be similar to the TEMPLATE user discussed in Proposal 1. Or it could be something entirely different. However, we simply refer to it as a Jobrole. The Jobrole is sufficiently similar to a USER that it can be used to specify all user attributes, group connections and permissions. The Jobrole will have the ability to have multiple USER profiles associated with it. A user can be associated with one and only one Jobrole. When determining the access capabilities or permissions of the user The attributes of the user are ignored The attributes of the Jobrole will be used There still is a need for a customisable masking mechanism to specify those items which are required to be unique to users Name UID Home directories other fields (e.g. in CSDATA segments)

13 Proposal 2: New RACF Construct: Jobrole User Initialisation: Current User Initialisation: Proposed User: Bill User: Bill (linked to Jobrole Clerk) Jobrole: Clerk RACROUTE REQ=VERIFY RACROUTE REQ=VERIFY ACEE ACEE

14 Proposal 2: New RACF Construct: Jobrole With this new mechanism the building of the ACEE is achieved by finding the Jobrole associated with the user, and building from it and the user profile. All access permissions and attributes are taken from the Job role. All attributes which are unique to the user are taken from the user profile, E.g. Name, UID, Home, etc. Any requirements for access permissions will be made to the Job role. User ACEEs will automatically get the new or changed permissions or attributes. There will no longer be any need to ensure that all users within a Job role have the same access, as they will have this automatically. The need for group connections to be specified at the user level will no longer be needed. Management of Job roles will replace the management of user profiles. Group profiles can still be used to manage access to resources across multiple Job roles. One major remaining issue is addressed by Proposal 3.

15 Proposal 3: Restrict userids in access lists The presence of User entries in the access lists of resource profiles becomes a challenge in managing Job roles. If there are userids in access lists then this breaks the Job role rules as one member of a Job role will get access to a resource while another will not. There are several ways to tackle this, and we present some alternatives, recognising that customers may have different requirements in this area. 1. Firstly, there should be an option to be able to specify the Job role in the access list. The justification for this is simple. If the Job role is replacing the userid as the centre for attribute and access specification, then it makes sense to allow the Job role to be used in place of the userid. 2. Have a system-wide option to disallow the checking of userids in access lists. This could be o o o specified as, Mandated for everyone Only for ACEEs built using Job roles Not active 3. Provide a system-wide option to prevent userids being specified in the PERMIT command. Again this could be specified as, o o o Mandated for everyone Only for ACEEs built using Job roles Not active