The last major RACF project I architected was for something I presume would probably fit your clients bill here. Some of the necessary elements we incorporated were:
Delegated (though not via RACF means) Ownership of all RACF general resource and dataset profiles - thereby making sure that there were people distributed throughout the organisation who a) knew what their security requirements were, at least conceptually, and b) took responsibility for authorising requests for access to or changes made to the RACF definitions they 'owned'. A naming convention that meant ownership of RACF definitions was able to be related to specific application systems (z/OS itself was considered just another application system running on the mainframe also - it's owner was of course the systems programming management). A request workflow that walked ordinary users through the process of raising a change record for RACF definitions. We used ServiceNow for this, with heavily customised workflows that linked into a Configuration Management Database that was a mirror, refreshed frequently, of the content of the RACF database. The previously mentioned CMDB was an essential part of ensuring that we had auditable, documented, reliable oversight - governance they like to call it nowadays - of the process of RACF change management. The CMDB relied heavily on the naming convention being used to identify which application (and therefore which responsible Owner) would be allowed to authorise requests. An in house written started task that issued the necessary RACF commands based on authorised changes coming through the ServiceNow workflow. Standardisation of the format for Installation Data - which we used to describe things such as a profiles security classification - i.e Public, Internal, Confidential, Secret - something like that, the labels are up to you. This 'data classification' was used to provide different versions of the ServiceNow workflow to suit the sensitivity of the resources being manipulated. (I would have liked to use/abuse SECLABEL/SECLEVEL for this but that made some people nervous :-). A lot of SMF based audit reports, especially with respect of the more highly classifiied resource profiles. Two years work with a couple of sysprogs, a project manager and assistant plus a great deal of support from the organisations management to get this task done. The alternative, was that we were going to need a team minimum 4 people with solid RACF knowledge to be available as mainframe security management - so the cost benefit analysis was quite crystal clear. There were many other considerations that our RACF Automation project had to consider, and we solved a lot of other historical audit related issues during the process also and were very fortunate that we could implement some worlds best practice mainframe security constructs (i.e. separating all batch access on an application by application basis) as a part of the project. Happy to discuss offline in case anyone is interested. Cheers - Mike PS: the organisation already had a fully integrated IAM solution for provisioning mainframe access and an RBAC-like construct for this, that's the easy part - anyone without this nowadays is simply dragging the chain. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
