Setting and listing audit controls
Audit control | Action |
---|---|
General | You can use:
|
Specific | You can specify:
|
Some audit controls are product-specific. Refer to the appropriate product documentation for setting these audit controls.
General audit controls
You specify general (system-wide) audit controls on either the SETROPTS command or the SET AUDIT OPTIONS ISPF panel. General audit controls direct RACF to log (or not to log) certain security-relevant events, such as the activities of OPERATIONS or group-OPERATIONS users, RACF command violations, and attempts to access RACF-protected resources.
To specify the general audit controls, you must have the AUDITOR attribute. After you have initially established your controls or modified existing controls, it is a good practice to list the current options to verify that the controls are correct.
- APPLAUDIT and NOAPPLAUDIT
- AUDIT and NOAUDIT
- CMDVIOL and NOCMDVIOL
- LIST
- LOGOPTIONS
- OPERAUDIT and NOOPERAUDIT
- REFRESH GENERIC
- REFRESH RACLIST
- SAUDIT and NOSAUDIT
- SECLABELAUDIT and NOSECLABELAUDIT
- SECLEVELAUDIT and NOSECLEVELAUDIT
If you have the group-AUDITOR attribute, you can use only the LIST and REFRESH GENERIC operands.
Logging RACF commands and DEFINE requests
SETROPTS AUDIT(USER GROUP DATASET TERMINAL)
If you specify AUDIT(*), RACF logs RACF command and
DEFINE request activity for all classes.SETROPTS AUDIT(IMS)
The following table shows the events that SETROPTS AUDIT(class) affects:
User | Group | Data set | Classes in the CDT |
---|---|---|---|
ADDUSER | ADDGROUP | ADDSD | PERMIT |
ALTUSER | ALTGROUP | ALTDSD | DEFINE Request |
CONNECT | CONNECT | DELDSD | RALTER |
DELUSER | DELGROUP | PERMIT | RDEFINE |
getUMAP | getGMAP | DEFINE Request | RDELETE |
initACEE registration / deregistration | REMOVE | ||
PASSWORD | |||
RACDCERT | |||
RACLINK | |||
RACMAP | |||
REMOVE | |||
R_pkiserv | |||
VERIFY | |||
If you have the AUDITOR attribute, you can also specify the NOAUDIT operand on the SETROPTS command and identify the class or classes for which you do not want RACF to log RACF command and DEFINE requests. If you specify NOAUDIT(*), RACF does not log RACF commands and DEFINE requests for any class.
NOAUDIT(*) is in effect at RACF initialization.
- All RACF commands (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH) issued by this user
- All additions, changes, or deletions that the user makes to RACF profiles using RACROUTE REQUEST=DEFINE requests
- All attempts that the user makes to access RACF-protected resources, except those authorized by global access checking and those not logged because the resource manager (issuer of the RACROUTE REQUEST=AUTH or RACROUTE REQUEST=FASTAUTH request) specified no logging
- All security decisions that are made during RACF callable services involving this user and any resource in certain z/OS® UNIX classes. For a list of these classes, see Auditing for z/OS UNIX System Services.
Bypassing logging of activity of users with the SPECIAL attribute
SETROPTS NOSAUDIT
If you have the AUDITOR attribute, you can also specify the SAUDIT operand on the SETROPTS command, to indicate that you want RACF to log the command and request activity (except LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH, which are never logged) of users with the SPECIAL or group-SPECIAL attribute.
SAUDIT is in effect at RACF initialization.
Logging the activities of users with the OPERATIONS attribute
SETROPTS OPERAUDIT
If you specify OPERAUDIT, RACF logs all accesses to RACF-protected resources granted because the user has the OPERATIONS or group-OPERATIONS attribute, and all uses of the ADDSD, and RDEFINE commands allowed because a user has the OPERATIONS or group-OPERATIONS attribute.
OPERAUDIT overrides the audit field of data set, file, directory and general resource profiles.
If you have the AUDITOR attribute, you can also specify NOOPERAUDIT. NOOPERAUDIT does no special auditing of users with the OPERATIONS or group-OPERATIONS attribute.
NOOPERAUDIT is in effect at RACF initialization.
Logging and bypassing RACF command violations
A violation can occur because RACF does not authorize a user to modify a particular profile or to enter a particular operand on a command.
If you have the AUDITOR attribute, you can specify the CMDVIOL operand on the SETROPTS command. This operand tells RACF to log all command violations (except for LISTDSD, LISTGRP, LISTUSER, RLIST, and SEARCH, which are never logged).
CMDVIOL is in effect at RACF initialization.
SETROPTS NOCMDVIOL
Activating auditing for security levels
If you have the AUDITOR attribute, you can activate auditing of access attempts to all RACF-protected resources. To activate this option, specify the SECLEVELAUDIT operand with an installation-defined security level name on the SETROPTS command. Auditing is done if the profile protecting a resource is equal to or greater than the security level you specify on the SECLEVELAUDIT operand.
- You can only specify a security level name defined by your installation in the SECLEVEL profile in the SECDATA class. If you specify a security level that is not in the SECLEVEL profile for the SECDATA class, RACF ignores the operand and does no logging.
- The SECDATA class must be active if you want RACF to perform security level control.
SETROPTS SECLEVELAUDIT(CONFIDENTIAL)
When you specify a security level, RACF audits all attempts to access resources with the specified security level and higher. This option allows your installation to audit access attempts to a RACF-protected resource, based on the sensitivity of the resource, as determined by the installation. If you do not specify a security level, RACF audits all access attempts to all resources for which your installation has defined a security level (SECLEVEL).
- If a program issues an AUTH or DEFINE request and specifies that RACF should not perform any logging, RACF does not log the event even if you request logging.
- When RACF grants access to a resource because of an entry in the global access checking table, RACF does not log the event even if you request logging.
If you have the AUDITOR attribute, you can also deactivate auditing of access attempts to RACF-protected resources based on installation-defined security levels. To deactivate this option, specify the NOSECLEVELAUDIT operand on the SETROPTS command.
NOSECLEVELAUDIT is in effect at RACF initialization.
Activating auditing for access attempts by class
If you have the AUDITOR attribute, you can audit attempts to access resources in specified classes according to the option selected. You can specify the DATASET class and any active classes in the class descriptor table. The resources need not have profiles created in order for the auditing to occur.
SETROPTS LOGOPTIONS(ALWAYS(TERMINAL))
In this case, auditing is done
every time a user logs on at any terminal on the system, whether that terminal is protected by a
profile or not, and whether that profile specifies auditing or not.- ALWAYS
- All attempts to access resources protected by the class are audited.
- NEVER
- No attempts to access resources protected by the class are audited. (All auditing is suppressed.)
- SUCCESSES
- All successful attempts to access resources protected by the class are audited.
- FAILURES
- All failed attempts to access resources protected by the class are audited.
- DEFAULT
- Auditing is controlled by the profile protecting the resource, if a profile exists. You can specify DEFAULT for all classes by specifying an asterisk (*) with DEFAULT.
- The SUCCESSES and FAILURES operands result in auditing in addition to any auditing specified in profiles in the class. In contrast, the ALWAYS and NEVER operands override any auditing specified in profiles in the class.
- If LOG=NONE is specified on a RACROUTE REQUEST=AUTH, it takes precedence and auditing is not performed.
- When RACF grants access to a resource because of an entry in the global access checking table, RACF does not log the event even if you request logging.
- If authority checking is performed with a RACROUTE REQUEST=FASTAUTH request, auditing is not affected by a SETROPTS LOGOPTIONS command.
LOGOPTIONS(DEFAULT(*)) is in effect at RACF initialization.
If your installation has specified SETROPTS LOGOPTIONS for any number of classes and you want this reset, specify LOGOPTIONS(DEFAULT(*)) on the SETROPTS command.
Activating auditing for security labels
SETROPTS SECLABELAUDIT
- The in-storage copy of the SECLABEL profile named EAGLE requires it, or
- The profile protecting the resource requires it.
RALTER SECLABEL EAGLE
AUDIT(FAILURES(READ))
After this command has been issued, a DATASET profile that has a security label of EAGLE, but no auditing specified, will have failed access attempts audited due to the security label auditing specified.
NOSECLABELAUDIT is in effect at RACF initialization.
If your installation has specified SETROPTS SECLABELAUDIT, additional auditing is done based on SECLABEL profiles. This option can be reset to the default by specifying NOSECLABELAUDIT on the SETROPTS command. The auditing options in the SECLABEL profiles do not have to be changed, however, because NOSECLABELAUDIT causes the audit options to be ignored.
- RACROUTE REQUEST=AUTH
- RACROUTE REQUEST=FASTAUTH
- RACROUTE REQUEST=DEFINE .
- ck_access
- ck_IPC_access
- ck_owner_two_files
- make_FSP
- make_ISP
- ck_process_owner
- R_ptrace.
When auditing security labels with the SECLABELAUDIT function, SMF audit records are written, thus requiring a high amount of system overhead. It is advised that auditing not be turned on for every security label in the system. Only those security labels with specific auditing requirements, as defined by the installation, should be audited.
Auditing for APPC/MVS
- Auditing user verification requests as transactions enter the system and complete
- Auditing the use of a particular APPC/MVS transaction program
- Determining the relationship between the audit records created during the execution of APPC/MVS transactions
User verification requests
There are two alternatives used in APPC/MVS that affect how auditing is performed. The alternative in effect is determined by the level of conversation security established between a pair of LUs. With either alternative, you can request a pair of audit records that mark the creation and deletion of a user's security environment.
- One alternative uses a concept known as persistent verification
(PV). When PV is used, the security environment for a user is
created when the user's first transaction request enters the
system. The security environment persists over multiple transactions
before being deleted. In terms of audit records for user verification, a user is audited twice at the most:
- First, when the user begins work on the system
- Next, when the user signs off, regardless of how many transactions are submitted.
- In the other alternative (non-PV), the user's security environment
is created and deleted for each transaction the user requests.
In terms of audit records for user verification, every transaction a user submits may be audited. This can potentially produce a large volume of SMF records.
With either alternative, the audit records marking the creation and deletion of the security environment contain a common audit key that links the audit records together.
With either alternative, the auditing is controlled with the APPL profile and the APPLAUDIT operand of the SETROPTS command. See Activating APPC/MVS auditing.
Transaction program auditing
Auditing of resource access attempts is done as part of day-to-day operations set up by the auditor or profile-owner for your installation. This existing auditing also occurs for transaction programs, but with a slight difference in audit records.
The audit records created by a transaction program contain an audit key that can be used to link audit records together.
In the case of persistent verification (where user verification is audited only twice-at signon and signoff), the audit key links records to a particular user. In the case of non-PV, the audit key links records created for a single transaction request.
Relationship of APPC/MVS audit records
Audit records created for users and transaction programs may be linked by a common key. All APPC/MVS audit records contain an 8-byte key that may be used to link the beginning and ending records together.
Activating APPC/MVS auditing
APPLAUDIT is a RACF option that allows user verification auditing to occur at the beginning and ending of a user's transaction processing work. Activating this auditing requires two steps:
- You must specify the APPLAUDIT operand on the SETROPTS command.
- You must request auditing for the APPL profile associated with an APPC/MVS LU.
SETROPTS APPLAUDIT
In addition to
setting APPLAUDIT on, you must also request auditing for the APPL profile.RALTER APPL profile-name GLOBALAUDIT(ALL)
where
profile-name is the name of the APPC/MVS LU.- AUDIT(ALL)
- AUDIT(SUCCESS)
- AUDIT(FAILURE)
- GLOBALAUDIT(ALL)
- GLOBALAUDIT(SUCCESS)
- GLOBALAUDIT(FAILURE)
Deactivating APPC/MVS auditing
SETROPTS NOAPPLAUDIT
NOAPPLAUDIT is in effect at
RACF initialization.Refreshing profiles
- In-storage generic profiles
- Profiles processed by SETROPTS RACLIST
- The global access table
- The program access table
- Shared systems
Refreshing in-storage generic profiles
You may want to use GENERIC REFRESH after changing the logging options in a generic profile that protects a specific data set, as described in Specific audit controls. However, extensive use of GENERIC REFRESH can adversely affect system performance.
SETROPTS GENERIC(DATASET TERMINAL) REFRESH
Note that you must issue this command each time you want RACF to perform the refresh process.
If you specify GENERIC(*), RACF refreshes profile lists for the DATASET class and all active classes in the except group resource classes (such as GTERMINL and GDASDVOL). When you initiate the refresh procedure, RACF sets an indicator in the RACF communication vector table for the class(es) that you specified. After the indicator is set, RACF refreshes the profile lists the next time it invokes the generic-profile search routine.
If you specify NOGENERIC on the SETROPTS command, RACF stops using in-storage generic profile lists but does not immediately delete them. RACF deletes the profile lists at the end of the job or TSO session, or when you again specify GENERIC. When you specify GENERIC, RACF rebuilds the profile lists. (If SETROPTS GENLIST has been used on your system, a copy of the generic profiles for the resource resides in common storage. You can also use REFRESH GENERIC to refresh these in-storage generic profiles.)
For classes RACLISTed by either the SETROPTS RACLIST command or RACROUTE REQUEST=LIST, generic including discrete profiles for the class must be refreshed. This process is described in the next section.
Refreshing RACLISTed profiles
If SETROPTS RACLIST has been used on your system, copies of the discrete and generic profiles for any resource within a general resource class reside in a data space and can be shared among users. SETR RACLIST(classname) REFRESH causes the data space to be replaced with another data space containing new copies of the discrete and generic profiles from the RACF database.
If SETROPTS RACLIST has been issued for a general resource class and you change the logging options for a general resource profile in the class, you may want to use the REFRESH option to refresh the profile.
SETROPTS RACLIST(DASDVOL TERMINAL) REFRESH
The RACROUTE REQUEST=FASTAUTH service routine works with in-storage profiles RACLISTed by the RACROUTE REQUEST=LIST macro with ENVIR=CREATE specified. To refresh those profiles, the application must delete them by using RACROUTE REQUEST=LIST,ENVIR=DELETE and then re-create them using RACROUTE REQUEST=LIST,ENVIR=CREATE again. However, if the GLOBAL=YES parameter is specified, a refresh is accomplished with SETR RACLIST(classname) REFRESH.
SETROPTS REFRESH processing on shared systems
If RACF is enabled for sysplex communication, the refresh operation for SETROPTS processing is propagated to all members of the RACF sysplex data sharing group.
Otherwise, the command applies only to the system (z/VM® or MVS™) on which you issue the SETROPTS command. If your installation has two or more systems sharing a RACF database, you must issue the SETROPTS command on all systems to have the refresh done on all systems.
However, if you do not perform a refresh (issue the SETROPTS command with the REFRESH option) on a system sharing a RACF database and that system needs to re-IPL, the refresh takes effect on that system when re-IPL is performed.
When you issue a SETROPTS REFRESH command, or one of the propagated RVARY commands (ACTIVE, INACTIVE, DATASHARE, NODATASHARE, SWITCH) from one member of a RACF sysplex data sharing group, the request is audited only on the system from which you issue the command, and only if auditing has been selected for that system. The request is not audited on the peer member systems (regardless of whether auditing has been selected).
For more details about SETROPTS commands that are propagated to all members of the RACF sysplex data sharing group, refer to z/OS Security Server RACF Command Language Reference.
Examples for setting audit controls using SETROPTS
The following examples show how to set system-wide audit controls by using the SETROPTS command.
SETROPTS LIST
You
can also use the LIST operand on the SETROPTS command; for example:
SETROPTS SAUDIT LIST
Example 1
SETROPTS AUDIT(USER,GROUP,DATASET,DASDVOL)
Example 2
SETROPTS SAUDIT
Example 3
SETROPTS OPERAUDIT
Example 4
SETROPTS AUDIT(USER)
Example 5
SETROPTS CMDVIOL
Example 6
SETROPTS SECLEVELAUDIT(CONFIDENTIAL)
Example 7
SETROPTS REFRESH GENERIC(DATASET)
SETROPTS AUDIT(USER,GROUP,DATASET,DASDVOL)
SAUDIT OPERAUDIT CMDVIOL SECLEVELAUDIT(CONFIDENTIAL)
REFRESH GENERIC(DATASET)
Example 8
SETROPTS REFRESH RACLIST(TERMINAL)
Example 9
SETROPTS LOGOPTIONS(ALWAYS(DEVICES))
Example 10
SETROPTS LOGOPTIONS(ALWAYS(OPERCMDS))
Example 11
SETROPTS SECLABELAUDIT
Example 12
SETROPTS APPLAUDIT
RALTER APPL profile-name AUDIT
where profile-name is the name of the APPC/MVS LU
name.Example 13 (z/OS UNIX System Services)
SETROPTS LOGOPTIONS(FAILURES(DIRSRCH,DIRACC))
Example 14 (z/OS UNIX System Services)
SETROPTS AUDIT(FSOBJ,PROCESS)
Specific audit controls
- All RACF-related activities for specific users
- Attempts to access specific data sets
- Attempts to access specific general resources
- Attempts to access resources protected by a security label
You can also list the complete contents of all profiles, including the owner-specified and auditor-specified logging options for resources.
If you have the AUDITOR attribute, you can set specific controls for any user, data set, or general resource, and list the contents of any profile. If you have the group-AUDITOR attribute, you can set controls and list profile contents only for those users, data sets, and general resources owned by the group in which you have the attribute, and any subgroup of that group.
User controls
- All RACF commands (except LISTDSD, LISTGRP, LISTUSER, RLIST and SEARCH) issued by this user
- All additions, changes, or deletions that the user makes to RACF profiles using RACROUTE REQUEST=DEFINE requests
- All attempts that the user makes to access RACF-protected resources, except those authorized by global access checking and those not logged because the resource manager (issuer of the RACROUTE REQUEST=AUTH or RACROUTE REQUEST=FASTAUTH request) specified no logging
- All security decisions made during RACF callable services involving this user and any resource in certain z/OS UNIX classes. For a list of these classes, see Auditing for z/OS UNIX System Services.
In general, you would probably not request user audit-logging as a matter of course, but it is useful in special situations. For example, you can specify user-audit logging if you suspect, based on other indicators such as command violations, that a particular user may be misusing the system or persistently trying to access or delete resources outside the user's control. Examples of the type of event that might indicate misuse of the system are either unauthorized attempts to modify a critical system resource (such as a PARMLIB data set) or a highly classified user resource (like payroll or business-planning data).
Example
ALTUSER SMITH UAUDIT
Data set controls
If owner controlled logging does not provide enough information for your audit, you can use the GLOBALAUDIT operand on the ALTDSD command or request the corresponding function on the AUDIT DATA SET ACCESS panel, in addition to the owner-specified logging values, to log user accesses to data sets.
GLOBALAUDIT allows you to specify logging for different kinds of attempts that users make to access resources at a given access level. With GLOBALAUDIT, you can log successful accesses, failed accesses, or both to a given resource and specify READ, UPDATE, CONTROL, or ALTER for the access level to the resource.
Figure 1 summarizes the GLOBALAUDIT operand for ALTDSD and what you are able to specify for logging. (For a complete description of the ALTDSD command and its operands, see z/OS Security Server RACF Command Language Reference.)
As with the other specific controls, you do not audit accesses to most data sets, as a general rule. Therefore, GLOBALAUDIT(NONE) is the default for the operand. After you complete your audit of the data set, it is good practice to restore the default. When GLOBALAUDIT(NONE) is in effect, RACF logs accesses to the data set only as specified by the resource owner.
Example 1
ALTDSD 'JIM.MEMO.TEXT' GLOBALAUDIT(ALL(READ))
Example 2
ALTDSD 'A.B.C' GLOBALAUDIT(FAILURES(READ) SUCCESS(UPDATE))
General resource controls
You can use the GLOBALAUDIT operand on the RALTER command or request the corresponding function on the AUDIT GENERAL RESOURCES ACCESS panel to log user accesses to a specific general resource.Because the audit level that you specify on GLOBALAUDIT overrides the level the resource owner specified in the profile, you use it when the logging specified in the profile does not produce enough information for your needs.
When you set audit controls for a general resource, you specify what information RACF is to log-the result of the access attempt-and when RACF is to log the information-the level of access. Figure 1 shows the various valid combinations of what to log and when to log it.
As with the other specific controls, you would not audit accesses to most general resources usually. Therefore, GLOBALAUDIT(NONE) is the default for the operand. After you complete your audit of the general resource, it is good practice to restore the default. When GLOBALAUDIT(NONE) is in effect, RACF logs accesses to the resource as specified in the profile.
Example
RALTER TAPEVOL NR1234 GLOBALAUDIT(ALL(READ))
Listing specific audit controls
RACF provides commands and corresponding ISPF panels that allow RACF users, depending on their authority or attributes, to examine the contents of RACF profiles. You, as an auditor with the AUDITOR or ROAUDIT attribute, can list the contents of all the RACF profiles (or all the profiles within the scope of your group if you are a group-AUDITOR). You can find a complete description of each of the commands, including sample output, in the z/OS Security Server RACF Command Language Reference.
- LISTDSD
This lists the contents of data set profiles. If you have the AUDITOR attribute or ROAUDIT attribute, you can list all profiles; if you have the group-AUDITOR attribute, you can list only those profiles within the scope of your group and its subgroups.
- LISTGRP
This lists the contents of group profiles. While the output does not contain any information directly related to specific audit controls, it does include information about the group structure and each user's authority within the group. This information may be useful to you. If you have the AUDITOR attribute or ROAUDIT attribute, you can list all group profiles; if you have the group-AUDITOR attribute, you can list only the profiles within the scope of your group and its subgroups. This will not list all users in a universal group.
- LISTUSER
This lists the contents of user profiles. If you have the AUDITOR attribute or ROAUDIT attribute, you can list all user profiles; if you have the group-AUDITOR attribute, you can list only those profiles within the scope of your group and its subgroups.
- RLIST
This lists the contents of general resource profiles. If you have the AUDITOR attribute or ROAUDIT attribute, you can list all resource profiles; if you have the group-AUDITOR attribute, you can list only those profiles within the scope of your group and its subgroups.
Example
LISTDSD DA('JIM.MEMO.TEXT') ALL
LISTDSD DA('JIM.MEMO.TEXT') ALL GENERIC
Auditing for the RACF/Db2 external security module
The RACF/Db2 external security module allows you to use RACF resource profiles to check authorization for DB2® privileges and authorities. With these profiles, which represent the various Db2 privileges, you can use the RACF auditing tools to extract the information you need.
You can use the SMF data unload utility or the RACF report writer to extract and format the SMF records. When the RACF/Db2 external security module uses a RACROUTE REQUEST=FASTAUTH request to create an audit record, the record contains log string data that includes additional diagnosis information described in Using the log string (LOGSTR) data. You can use the log string information to link Db2 trace record IFCID 314 and a corresponding RACF SMF record.
Restriction
This topic contains information about using RACF with Db2 Version 7, and earlier Db2 versions. For information about using RACF with Db2 Version 8, and later Db2 versions, see IMS in IBM Knowledge Center.
- Version and length of the RACF/Db2 external security module
- Name of the subsystem or group attach name
- FMID or APAR number associated with the module
- Customization options used for the module
- Classes that the module is trying to use
- Classes for which a RACROUTE request was successful
- &ERROROPT specifies the correct action to be taken for Db2 initialization and authorization errors. Note: The system programmer sets these options. For detailed information, see z/OS Security Server RACF System Programmer's Guide.