Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Setting audit controls z/OS Security Server RACF Auditor's Guide SA23-2290-00 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Audit controls are special RACF® functions that RACF allows only the auditor to perform. To preserve the checks and balances necessary to an effective security mechanism, not even the security administrator with the SPECIAL attribute can execute auditor functions. Therefore, you should ensure that SPECIAL users do not also have the AUDITOR attribute.
Some audit controls are product-specific. Refer to the appropriate product documentation for setting these audit controls. General audit controlsYou 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. If
you have the AUDITOR attribute, you can specify these SETROPTS operands
or request the function on the corresponding panel:
If you have the group-AUDITOR attribute, you can use only the LIST and REFRESH GENERIC operands. Logging RACF commands and DEFINE requestsIf you
have the AUDITOR attribute, you can specify the classes for which RACF logs all detected accesses
to the RACF database through RACF commands and DEFINE requests.
You can specify this option with the AUDIT operand on the SETROPTS
command; it becomes effective immediately. The following example specifies
that you want RACF to log RACF commands and DEFINE requests
for users, groups, data sets, and the TERMINAL general-resource classes.
If
you specify AUDIT(*), RACF logs RACF command and DEFINE request
activity for all classes.If you want to log any change in RACF protection for IMS™, enter:
The following table shows the events that SETROPTS AUDIT(class) affects:
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. Note: If
you have the AUDITOR attribute, you can specify with the UAUDIT operand
on the ALTUSER command that you want RACF to
log the following:
Bypassing logging of activity of users with the SPECIAL attributeIf you
have the AUDITOR attribute, you can request that RACF bypass logging of all RACF commands and the AUTH and DEFINE requests
issued by users with the SPECIAL or group-SPECIAL attribute. You can
specify this option with the NOSAUDIT operand on the SETROPTS command
as shown in the following example:
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. Note: If
you are concerned only with how SPECIAL users change profiles, you
do not need to specify SAUDIT if AUDIT(*) is in effect.
SAUDIT is in effect at RACF initialization. Logging the activities of users with the OPERATIONS attributeIf you
have the AUDITOR attribute, you can audit all accesses to resources
granted because the user has the OPERATIONS or group-OPERATIONS attribute,
by using the OPERAUDIT operand on the SETROPTS command. The following
example shows how to specify this option.
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. Note: Some programs that call RACF functions such as RACROUTE
REQUEST=AUTH and RACROUTE REQUEST=DEFINE can request that RACF perform no logging. Thus,
if an OPERATIONS or group-operations user accesses a protected resource
through such a program, RACF does
not log the access even if you request OPERAUDIT.
OPERAUDIT overrides the audit field of data set, file, directory and general resource profiles. OPERAUDIT does not affect any auditing requested by the GLOBALAUDIT operand on the RACF commands. 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 violationsA 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). Note: Specifying CMDVIOL
causes RACF to log all the
command violations that it detects. You can then use the RACF report writer to produce a
printed audit trail of command violations. You can determine how
many command violations are occurring and which users are causing
the violations. A significant number of command violations, especially
when RACF is first installed,
may indicate the need for more user education. The report can also
help you to identify any specific users who are persistently trying
to alter profiles without the proper authority.
CMDVIOL is in effect at RACF initialization. If
you have the AUDITOR attribute, you can request that RACF bypass logging of all violations detected
by RACF commands (except RVARY
and SETROPTS, which are always logged) during RACF command processing. You can specify this
option with the NOCMDVIOL operand on the SETROPTS command as shown
in the following example:
Activating auditing for security levelsIf 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. Note:
The following example shows how to activate auditing
based on the security level CONFIDENTIAL. (This example assumes that
the installation has defined the level CONFIDENTIAL in the SECLEVEL
profile.)
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). Note:
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 classIf 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. The
following command specifies that auditing be done for all attempts
to access the TERMINAL class.
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.You
can specify that auditing be done for the following conditions:
Note:
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 labelsIf you
have the AUDITOR attribute, you can audit all attempts to access resources
whose profiles have a security label specified. The auditing that
is done is specified in the SECLABEL profile that defines the security
label. To do this, specify the SETROPTS command as follows:
When
SECLABELAUDIT is in effect, the SECLABEL profiles for which RACLIST
processing has been done enhance the auditing specified in resource
profiles. For example, if the security label EAGLE has been defined
by the installation and a resource with security label EAGLE is accessed,
when a user with security label EAGLE logs on, RACF records the event if either:
For example, to audit all failed accesses to resources
with a security label of EAGLE, the installation should issue the
following command:
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. Note: A
value of NONE in the SECLABEL profile does not suppress auditing;
auditing is determined by other auditing specifications (such as the
resource profile).
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. The
SECLABELAUDIT function applies whenever resources are accessed or
defined, and includes accessing and defining z/OS UNIX files
and directories. SECLABELAUDIT is checked during the following operations:
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/MVSThere are several considerations
associated with APPC/MVS auditing:
User verification requestsThere 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.
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 auditingAuditing 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 recordsAudit 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 auditingAPPLAUDIT 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:
Issue the following command:
In
addition to setting APPLAUDIT on, you must also request auditing for
the APPL profile.For example, you could issue the following
command:
where profile-name is
the name of the APPC/MVS LU.Note: The security administrator
must have previously activated the APPL class, defined the APPL profile,
and issued a SETROPTS RACLIST for the class.
To turn on
auditing for the profile in the APPL class, use any of the following
operands on the RALTER command:
Note: Remember to issue a SETROPTS RACLIST REFRESH for the
APPL class.
Deactivating APPC/MVS auditingTo disable auditing of APPC transactions,
users with the AUDITOR attribute should specify the SETROPTS command
as follows:
NOAPPLAUDIT
is in effect at RACF initialization.Refreshing profilesYou
can use the SETROPTS command to refresh profiles. This includes refreshing:
Refreshing in-storage generic profilesYou 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. You
can refresh in-storage generic profiles by specifying both the GENERIC
and REFRESH operands on the SETROPTS command. When you specify both
GENERIC and REFRESH, you also specify one or more classes for which
you want RACF to refresh in-storage
generic profiles. This causes all the in-storage generic profiles
within the specified general resource class (except those in the global
access checking table) to be replaced with new copies from the RACF database. The following example
shows how to refresh in-storage generic profiles for the DATASET and
TERMINAL classes:
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 profilesIf 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. The
following example shows how to refresh SETROPTS RACLIST processing
for the DASDVOL and TERMINAL classes.
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 systemsIf 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 toz/OS Security Server RACF Command Language Reference. Examples for setting audit controls using SETROPTSThe following examples show how to set system-wide audit controls by using the SETROPTS command. Note: If
you want to list the current system-wide audit controls set with the
SETROPTS command, enter:
You
can also use the LIST operand on the SETROPTS command; for example:
Example 1To log any changes
to the profiles in the USER, GROUP, DATASET, and DASDVOL classes,
enter:
Example 2To log RACF commands issued by SPECIAL
and group-SPECIAL users, enter:
Example 3To log all accesses
to resources that users make as a result of the OPERATIONS attribute,
enter:
Example 4To
log all successful password changes (including password phrase changes),
enter:
Example 5To log all RACF command violations, enter:
Example 6To
log all attempts to access any resource with a security level of confidential
or higher enter:
Example 7To
refresh the in-storage, generic data set profiles, enter:
Note: You
can combine these six examples into a single SETROPTS command by entering:
Example 8To
refresh the in-storage profiles for terminals when SETROPTS RACLIST
has been used for the terminal class, enter:
Example 9To log all device access checking
for communication, unit record, and graphics devices, enter:
Example 10To log all operator commands that
are protected by profiles in the OPERCMDS class, enter:
Example 11To enable the use of SECLABEL
profiles to determine the level of auditing you want, enter:
Example 12To audit APPC transactions,
enter:
where profile-name is
the name of the APPC/MVS LU name.Example 13 (z/OS UNIX System Services)To log all failing directory
searches and access checks for read/write access to directories, enter:
Example 14 (z/OS UNIX System Services)To
control auditing of the successful creation and deletion of file system
objects and dubbing and undubbing of processes, enter:
Specific audit controlsSpecific audit controls
enable you to log the following:
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 controlsYou
can use the UAUDIT or NOUAUDIT operand on the ALTUSER command, or
request the corresponding functions on the AUDIT USER panel, to log
all RACF-related activities for a specific user. When you set this
control, RACF logs the following
events:
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). ExampleTo use the UAUDIT
operand on the ALTUSER command to audit the person whose user ID is
SMITH, enter:
Data set controlsIf 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.) Figure 1. GLOBALAUDIT Operand on the ALTDSD
Command
Note: Some authorized programs that call RACF to perform authority checking can request
that RACF perform no logging.
Therefore, if you request GLOBALAUDIT auditing for an access attempt
made through such a program, RACF does
not log the event.
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 1To
use the GLOBALAUDIT operand of the ALTDSD command to direct RACF to log all accesses to data
set JIM.MEMO.TEXT, enter:
Example 2To
use the GLOBALAUDIT operand of the ALTDSD command to direct RACF to log all failed accesses,
all successful updates, and any scratch of data set A.B.C, enter:
General resource controlsYou 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. ExampleTo use the RALTER
command to specify auditing of all events for a tape volume NR1234,
enter:
Listing specific audit controlsRACF 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 auditor, 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. The commands and the functions related to auditing are:
ExampleTo
list the complete profile for data set ‘JIM.MEMO.TEXT’, enter:
Note: If
no discrete profile exists for data set ‘JIM.MEMO.TEXT’, a generic
profile may protect the data set. To list any such generic profile,
enter:
Auditing for the RACF/DB2 external security moduleThe 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. RestrictionThis 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 http://publib.boulder.ibm.com/infocenter/imzic. In addition, you can use the information found in messages IRR908I
through IRR913I to help you understand how the RACF/DB2 external security
module is set up for a particular subsystem. These messages identify
the:
|
Copyright IBM Corporation 1990, 2014
|