This procedure describes one approach for SAF-protecting services
and CCA keys:
- Decide whether you will protect keys, services, or both. You can
select which keys and services to protect.
- 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 a particular MAC or a particular PIN.
- Users who call applications to dynamically update the CKDS or
PKDS.
- Users who work with digital signing callable services.
- Users who work with PKCS #11 applications.
Usually, all users of ICSF should have access to keys
and services by virtue of their membership in one of these SAF groups,
rather than specific users. This is because SAF 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 SAF database is not sufficient. This is analogous to the
in-storage CKDS maintained by ICSF.) To refresh the in-storage SAF
profiles, the security administrator must use the SETROPTS command:
SETROPTS RACLIST(CSFKEYS) REFRESH
SETROPTS RACLIST(CSFSERV) REFRESH
If
you place SAF groups in the access lists of the
SAF 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
security administrator to create the SAF groups.
You should
also ask your 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)
- Ask your 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)
- If you want to use generic profiles that contain characters such
as * and %, ask your 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.
- 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.
- 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 RACF RDEFINE, RALTER, and SETR, see
the z/OS Security Server RACF Command Language Reference.