This procedure describes one approach for RACF-protecting keys and services:

1. Decide whether you will protect keys, services, or both. You can select which keys and services to protect.
2. You may want to organize the users who need access to ICSF keys and services into groups. To do this, obtain a list of the user IDs of users who need to use ICSF keys and services. If batch jobs or started tasks need to use ICSF, obtain the user IDs under which they will run.

   Group any of the user IDs together if they require access to the same keys and services. For example, you might want to set up groups as follows:

   • Users who work with MAC-related callable services
   • Users who work with PIN-related callable services
   • Users who work with a particular MAC, or a particular PIN
   • Users who call applications to dynamically update the CKDS
   • Users who perform functions available on the User Control Functions panel

   Usually, all users of ICSF should have access to keys and services by virtue of their membership in one of these RACF groups, rather than specific users. This is because RACF maintains the access lists in in-storage profiles. When the in-storage profiles are created or changed, the in-storage profiles must be refreshed. (Merely changing them in the RACF data base is not sufficient. This is analogous to the in-storage CKDS maintained by ICSF.) To refresh the in-storage RACF profiles, the RACF security administrator must use the SETROPTS command:

       SETROPTS RACLIST(CSFKEYS) REFRESH
   
       SETROPTS RACLIST(CSFSERV) REFRESH

   If you place RACF groups in the access lists of the RACF profiles, you can change a user's access to the protected services and keys by adding or removing the user from the groups. Ask your RACF security administrator to create the RACF groups.

   You should also ask your RACF security administrator to connect you to these groups with CONNECT group authority. This permits you to connect and remove users from the groups.

   For example, the security administrator could issue these commands:

       ADDGROUP groupid
   
       CONNECT  your-userid  GROUP(groupid)  AUTHORITY(CONNECT)

   With CONNECT group authority, you are able to connect other users to the groups:

       CONNECT  other-userid  GROUP(groupid)

   With CONNECT group authority, you are also able to remove users from the groups:

       REMOVE  other-userid  GROUP(groupid)

3. Ask your RACF security administrator for the authority to create and maintain profiles in the CSFKEYS and CSFSERV general resource classes. Usually, this is done by assigning a user the CLAUTH (class authority) attribute in the specified classes. For example, the security administrator can issue this command:

       ALTUSER  your-userid  CLAUTH(CSFKEYS CSFSERV)

4. If you want to use generic profiles that contain characters such as * and %, ask your RACF security administrator to activate generic profile checking in the CSFKEYS and CSFSERV classes:

       SETROPTS  GENERIC(CSFKEYS CSFSERV)

   Note:

   Using generic profiles has several advantages. Using generic profiles you can reduce the number of profiles that you need to maintain. You can also create a "top" generic profile that can be used to protect all keys and services that are not protected by a more specific profile.
5. Define profiles in the CSFKEYS and CSFSERV classes. For further instructions, see Setting up profiles in the CSFKEYS general resource class and Setting up profiles in the CSFSERV general resource class.
6. Activate logging for CSFSERV using these commands:
   • ALTUSER userid UAUDIT - audits a userid

   • RALTER class-name profile-name AUDIT(audit-attempt[(audit-access-level)]) - used by the profile owner

     RALTER class-name profile-name GLOBALAUDIT(access-attempt[(audit-access-level)]) - used by a user with AUDITOR authority to set up profiles

   • SETROPTS CLASSACT(CSFSERV) RACLIST(CSFSERV)
     SETR LOGOPTIONS(CSFSERV(....))
     

   For more information on RDEFINE, RALTER, and SETR, see the z/OS Security Server RACF Command Language Reference.

7. Determine if you need to establish a Key Store Policy for a CKDS and/or a PKDS. A Key Store Policy is made up of a number of controls. Each Key Store Policy control is a resource in the XFACILIT class. The existence of a profile for a particular resource in the XFACILIT class enables that control. A Key Store Policy applies only to encrypted keys in a CKDS or PKDS. No key store policy controls are available or needed for a TKDS, because none of the keys in a TKDS are enciphered under a key-encrypting key. By enabling Key Store Policy controls, you can:
   • verify, when an application passes a callable service a key token instead of a key label, that the user has authority to the secure token. Profiles in the CSFKEYS class are named based on key labels (a discrete profile will exactly match the key label, while a generic profile will contain generic characters to match a number of key labels). Because the profiles are based on the key label, a SAF authorization check needs to know the key label of a CKDS or PKDS key record in order to perform the authorization check. A Key Store Policy control is available that will, if an application passes a callable service a key token instead of a key label, locate the associated key label(s) for the token so that a SAF authorization check can be carried out. By default, if ICSF cannot find an associated key label for the key token, the callable service will fail. However, another Key Store Policy control lets you use a default profile to specify access authority to tokens that are not stored in the CKDS or PKDS.
   • prevent applications from storing duplicate tokens in a CKDS or PKDS.
   • raise the level of access authority required to create, write to, or delete a key label.
   • raise the level of access authority required to export a token using the Symmetric Key Export callable service (CSNDSYX or CSNFSYX).
   • set additional restrictions on how keys covered by the profile can be used.
   You should familiarize yourself with the controls you can enable and decide on the Key Store Policy that is best for your installation. Refer to Defining a key store policy for more information.