Who's Knocking at Your Door? DB2 LUW Database Auditing Melanie Stopfer IBM Software Group Session Code: G15 10:30-11:30 AM May 18, 2012 | Platform: DB2 LUW Melanie Stopfer is a Consulting Learning Specialist and Developer for IBM Software Group. As a Certified DB2 9.7 Advanced Technical Expert and Certified Learning Facilitation Specialist, she has provided hands-on in-depth technical support to customers specializing in both data warehouse and transaction systems. She has worked with development labs and worldwide customers to provide DB2 solutions since 1988. She has received numerous awards for development and implementation of DB2 recovery, performance, administration and database upgrade and migration best practice solutions In 2009, Melanie was the first DB2 LUW speaker to be inducted into the IDUG Speaker Hall of Fame. She was named best overall speaker in 2012 and Top Ten Speaker at IDUG NA 2011, 2010, 2009, 2008, 2007,and IDUG EMEA 2011, 2010, 2009, 2008 and 2007. 1
Transcript
Who's Knocking at Your Door? DB2 LUW Database Auditing
Melanie StopferIBM Software GroupSession Code: G1510:30-11:30 AM May 18, 2012 | Platform: DB2 LUW
Melanie Stopfer is a Consulting Learning Specialist and Developer for IBM Software Group. As a Certified DB2 9.7 Advanced Technical Expert and Certified Learning Facilitation Specialist, she has provided hands-on in-depth technical support to customers specializing in both data warehouse and transaction systems. She has worked with development labs and worldwide customers to provide DB2 solutions since 1988. She has received numerous awards for development and implementation of DB2 recovery, performance, administration and database upgrade and migration best practice solutions In 2009, Melanie was the first DB2 LUW speaker to be inducted into the IDUG Speaker Hall of Fame. She was named best overall speaker in 2012 and Top Ten Speaker at IDUG NA 2011, 2010, 2009, 2008, 2007,and IDUG EMEA 2011, 2010, 2009, 2008 and 2007.
1
Click to edit Master title style
Objectives• Describe the tasks for DB2 database auditing performed by the
SYSADM user• List security administration tasks for DB2
databases that require the SECADM database authority in performing database level audits
• Utilize the db2audit command in implement instance level auditing and to configure the audit data and archive locations
• Create audit policies to enable collection of specific categories of audit data for a DB2 database
• Assign audit policies to selected tables, users or database roles using the AUDIT statement
• Understand auditing authority requirements
2
Learn the configuration and management tasks required for implementation of DB2 instance or database level auditing. You will learn the specific tasks that need to be performed by a SYSADM (system administrator) or SECADM (securityadministrator) to setup and control auditing of DB2 environments, including use of the db2audit command. The creation of audit policies which can be assigned to specific tables, users or database roles to perform selective collection of audit records will be discussed.
Objectives:•Describe tasks for DB2 database auditing performed by SYSADM user.•List security administration tasks for DB2 databases that require SECADM database authority in performing database level audits.•Utilize db2audit command to implement instance level auditing and configure audit data and archive locations.•Create audit policies to enable collection of specific categories of audit data for DB2 database.•Assign audit policies to selected tables, users or database roles using AUDIT statement.
2
3
3
DB2 Audit Facilities Prior to DB2 9.5
• Auditing facilities controlled by SYSADM user
• Audit operates at the DB2 instance level
• db2audit command used to manage audit processing– db2audit configure – To select audit options– db2audit describe – To display current audit status– db2audit start/stop – To control operations– db2audit extract – To extract audit records from the active audit log– db2audit prune – To remove audit records from the active audit log
$HOME/sqllib/security
db2audit.cfgdb2audit.log
audit.del checking.del objmaint.delsecmaint.del
sysadmin.del validate.del context.del
Prior to DB2 9.5, the facilities for auditing of DB2 databases were based on using the db2audit command, which required a user with SYSADM authority. The db2audit command operates at the instance level, so the types of audit data collected and the option to enable and disable auditing impacted all of the databases running under the same instance. •The audit configuration file and the audit log file were stored at a fixed location, the security subdirectory of the sqllib path for the instance.•The extract option of the db2audit command was used to extract audit records from the active audit log file for the instance. •The prune option of the db2audit command was used to remove older audit data from the active audit log file.
4
4
Standard DB2 Audit Data Categories • AUDIT – Generates records when audit settings
are changed or when the audit log is accessed. • CHECKING – Generates records during
authorization checking of attempts to access or manipulate DB2 database objects or functions.
• OBJMAINT – Generates records when creating or dropping data objects.
• SECMAINT – Generates records when granting or revoking: object or database privileges, or DBADM authority. Records are also generated when the database manager security configuration parameters SYSADM_GROUP, SYSCTRL_GROUP, or SYSMAINT_GROUP are modified.
• SYSADMIN – Generates records when operations requiring SYSADM, SYSMAINT, or SYSCTRL authority are performed.
• VALIDATE – Generates records when authenticating users or retrieving system security information.
• CONTEXT – Generates supporting detailed records, like the SQL statement for dynamic SQL.
DB2 provides options to select the types of audit records that can be generated by a DB2 database. There are also options to choose whether an audit record should be generated by normal successful activity, like an authorized database connection request, compared to a failed request, like a connection that is rejected because the password is incorrect or expired. There are different categories of audit records that may be generated. The categories of events available for auditing are:
•Audit (AUDIT). Generates records when audit settings are changed or when the audit log is accessed. •Authorization Checking (CHECKING). Generates records during authorization checking of attempts to access or manipulate DB2 database objects or functions. •Object Maintenance (OBJMAINT). Generates records when creating or dropping data objects. •Security Maintenance (SECMAINT). Generates records when granting or revoking: object or database privileges, or DBADM authority. Records are also generated when the database manager security configuration parameters SYSADM_GROUP, SYSCTRL_GROUP, or SYSMAINT_GROUP are modified. •System Administration (SYSADMIN). Generates records when operations requiring SYSADM, SYSMAINT, orSYSCTRL authority are performed. •User Validation (VALIDATE). Generates records when authenticating users or retrieving system security information. •Operation Context (CONTEXT). Generates records to show the operation context when a database operation is performed. This category allows for better interpretation of the audit log file. When used with the log's event correlation field, a group of events can be associated back to a single database operation. For example, a query statement for dynamic queries, a package identifier for static queries, or an indicator of the type of operation being performed, such as CONNECT, can provide needed context when analyzing audit results. The SQL or XQuery statement providing the operation context might be very long and is completely shown within the CONTEXT record. This can make the CONTEXT record very large.
5
5
Limitations for Audit Support Prior to DB2 9.5• Lack of flexibility:
– All databases in instance are controlled by a single audit configuration.
– Audit log file resides in a fixed location. For DPF databases, this may be a NFS shared file system.
– Can select type of audit data but no way to limit auditing to selected users or certain tables.
– Dynamic SQL text only available using CONTEXT option which generates a large volume of data.
• Performance impact:– Extracting audit data from the active audit log
can impact database performance.– General performance issues when producing
a large volume of audit data.
In order to address the major limitations of database auditing in previous DB2 releases, DB2 9.5 improved and extended the facilities for database auditing. For example prior to DB2 9.5:•The db2audit command set auditing option for the DB2 instance, so all of the databases in the instance are controlled by that single audit configuration.•The Audit log file resides in a fixed location. For DPF databases, this may be a NFS shared file system.•The configuration allowed the administrator to select categories of audit data but there was no method to limit auditing to selected users or certain tables•If the audit requirements included the SQL statement text, the generation of Dynamic SQL text required using the CONTEXT option which generates a large volume of data.•The EXTRACT option of the db2audit command retrieved data from the active audit file, which could impact database performance
Beginning with DB2 9.5, the audit facilities were enhanced, including these options:•The location for the active audit log files can be configured. This makes it easier for DPF partitioned databases to specify a local disk on each database server to hold the audit data. •Auditing can be enabled and configured at the database or instance level. •The generation of audit records can be limited to activity for selected users or tables.
6
6
DB2 9.5 & 9.7 Database Audit Features – Part 1
• Two distinct and independent methods for auditing database activity:– Instance level audit:
• db2audit command utilized to configure and manage instance level audit data collectionRequires SYSADM authority
– Database level audit:• Management requires SECADM authority for the DB2 database• SECADM creates audit policy objects in a database using CREATE
AUDIT POLICY statements• SECADM uses the AUDIT statement to assign an audit policy to the
database or to some specific type of activity, including a table, a defined database role or an individual user
• DB2 provided Stored procedures may be used by SECADM user to archive database audit data and extract the audit data for analysis
The enhancements to the DB2 audit facility beginning with DB2 9.5 include fine grained configuration, a new audit category, separate instance and database logs, and new ways to customize the audit configuration. With these options, you have control over exactly which database objects are audited and you do not need to audit events that occur for database objects that you are not interested in. Consequently, the performance impact of auditing (and its performance impact on other database operations) can be better managed. Individual databases can have their own audit configurations, as can particular objects within a database, such as tables, or even users, groups, and roles. In addition to providing easier access to the information that you need, this enhancement also improves performance, because less data needs to be written to disk. The security administrator is solely in control of configuring an audit for a database; the system administrator (holding SYSADMauthority) no longer has this authority. The security administrator also has sufficient access to manipulate the audit log and extract audit data records to files that can be easily loaded into DB2 tables.
The db2audit command was changed in DB2 9.5 to work with these enhanced auditing options.
•The audit facility provides the ability to audit at both the instance and the individual database level, independently recording all instance-and database-level activities with separate logs for each level. •In DB2 9.5, the system administrator (who holds SYSADM authority) can use the db2audit tool to configure an audit at the instance level and to control when information for that audit is collected. •The system administrator can also use the db2audit tool to archive both instance and database audit logs and to extract audit data from archived logs of either type.
The security administrator (who holds SECADM authority) can use audit policies with the SQL statement AUDIT to configure and control the audit requirements for an individual database. The security administrator can use the SYSPROC.AUDIT_ARCHIVE and SYSPROC.AUDIT_DELIM_EXTRACT stored procedures and the SYSPROC.AUDIT_LIST_LOGS table function to archive audit logs, locate logs of interest, and extract data into delimited files for analysis.
7
7
DB2 9.5 & 9.7 Database Audit Features – Part 2• The EXECUTE category for auditing SQL statements:
–Can only be used for database level audits, it can not be configured using db2audit command
–Reduces need to generate CONTEXT category audit records
• Active audit log is archived before data is extracted:–Reduces performance issue with extracting data from the
active audit log file–SYSADM user can use the db2audit command to archive
instance or database level audit data–SECADM uses the AUDIT_ARCHIVE stored procedure
to archive database level audit data
• The location for Active and Archived audit data can be configured:–SYSADM user uses the db2audit command to configure
the location for database and instance level active and archived audit logs
–Allows DPF databases to use local file system for audit log
The audit category, EXECUTE, which can only be configured for database level auditing, allows you to audit just the SQL statement that is being run. In DB2 releases prior to DB2 9.5 you needed to audit the CONTEXT event to capture this detail.
With the introduction of archival for audit data the db2audit command prune option has been removed. When the current audit data is archived, you should archive the audit logs on a regular basis (such as once a day or week), and after you have extracted the data that you need from the archived files, you can delete them or store them offline.
Archiving the audit log moves the active audit log to an archive directory while the server begins writing to a new, active audit log. This allows the audit log to be stored offline without having to extract data from it until necessary. After the security administrator or system administrator has archived a log, they can extract data from the log into delimited files. The data in the delimited files can be loaded into DB2 database tables for analysis.
The db2audit extract command parameter requires the specification of the names of the archived audit log files to be used for input. The extract command parameter allows you to specify which categories to extract and whether to extract success or failure events (or both).
8
8
SECADM Authorization with DB2 9.7
Security Administrators: SECADM– Must be granted by SECADM user at database level– Can be granted to user, group, or role.– PUBLIC cannot obtain SECADM authority directly or indirectly. – Instance owner does not have SECADM authority by default. – Required to implement & manage security features:
• Label Based Access Control • Define and manage database roles• Database level audit management• Trusted Contexts for three tiered applications
• Has ability to SELECT from catalog tables and catalog views,but cannot access data stored in user tables.
– Ability to Grant and Revoke database and object level privileges– Ability to grant ACCESSCTRL, DATAACCESS, DBADM to users,
groups, or roles
– Creator of database is initial SECADM user for new database– Migrator of database is initial SECADM user for existing database with
no SECADM
In a DB2 9.7 system, the SECADM authority is the security administration authority for a specific database. This authority allows you to create and manage security-related database objects and to grant and revoke all database authorities and privileges. Additionally, the security administrator can execute, and manage who else can execute, the audit system routines. SECADM authority has the ability to SELECT from the catalog tables and catalog views, but cannot access data stored in user tables. SECADM authority can be granted only by the security administrator (who holds SECADM authority) and can be granted to a user, a group, or a role. PUBLIC cannot obtain the SECADM authority directly or indirectly. SECADM authority gives a user the ability to perform the following operations:
•Create, alter, comment on, and drop: •Audit policies, Security label components, Security policies, Trusted contexts,
•Create, comment on, and drop: •Roles, Security labels
•Grant and revoke database privileges and authorities •Execute the following audit routines to perform the specified tasks:
•The SYSPROC.AUDIT_ARCHIVE stored procedure and table function archive audit logs. •The SYSPROC.AUDIT_LIST_LOGS table function allows you to locate logs of interest. •The SYSPROC.AUDIT_DELIM_EXTRACT stored procedure extracts data into delimited files for analysis. Also, the security administrator can grant and revoke EXECUTE privilege on these routines, therefore enabling the security administrator to delegate these tasks, if desired. Only the security administrator can grant EXECUTE privilege on these routines. EXECUTE privilege WITH GRANT OPTION cannot be granted for these routines (SQLSTATE 42501).•Use of the AUDIT statement to associate an audit policy with a particular database or database object at the server •Use of the TRANSFER OWNERSHIP statement to transfer objects not owned by the authorization ID of the statement
No other authority gives these abilities. The instance owner does not have SECADM authority by default. The creator of a database is the initial SECADM user for the new database. Only the security administrator has the ability to grant other users, groups, or roles the ACCESSCTRL, DATAACCESS, DBADM, and SECADM authorities.
9
9
DB2 9.7 Security Upgrade Considerations
• When upgrading DB2 database to DB2 9.7, security is defined to simulate previous methods where possible.–DB2 automatically grants DBADM, DATAACCESS and ACCESSCTRL
to the SYSADM group upon upgrade
–DB2 automatically grants DATAACCESS and ACCESSCTRL to every authorization ID that holds DBADM upon upgrade
–DB2 automatically grants SECADM to the user ID doing the upgrade if there is no authorization ID of type USER that holds SECADM in db
–SYSADM loses its implicit ability to grant/revoke DBADM and SECADM. These now require SECADM authority.
–SECADM required to configure and manage database auditing using SQL statements. SYSADM not required anymore. Grant SECADM authority to users who manage database auditing in upgraded databases.
–To run db2audit command, must have SYSADM.
In DB2 9.7, there are new authorities for access control and data access. For each authorization ID holding DBADM authority, including the SYSADM group, the UPGRADE DATABASE command explicitly grants ACCESSCTRL and DATAACCESS authorities so that existing database administrators maintain the same authority access and privileges as in previous releases. The UPGRADE DATABASEcommand also grants EXECUTE privilege on all system-defined routines by explicitly granting the SYSROLE_AUTH_DBADM system role to any authorization ID holding DBADM authority. In DB2 9.7, SECADM authority is required for security administration and it is the only authority that provides the ability to grant and revoke all authorities and privileges. If the database does not have a user with SECADM authority, the UPGRADE DATABASE command explicitly grants SECADM authority to the user performing this command. If any users in the SYSADM group need SECADM authority, you must explicitly grant it to them.
Also, the UPGRADE DATABASE command revokes the EXECUTE privilege from PUBLIC on the audit routines, AUDIT_LIST_LOGS, AUDIT_DELIM_EXTRACT, and AUDIT_ARCHIVE. For each authorization ID holding SECADM authority, the UPGRADE DATABASE command explicitly grants the EXECUTE privilege on the audit routines by granting the SYSROLE_AUTH_SECADM system role. In DB2 9.7, DBADM authority is required for database administration and SECADM authority is required for security administration. If users in the SYSADM group need either authority, you have to explicitly grant it. Also, a user who holds SYSADM authority is no longer able to grant any authorities or privileges, except to grant table space privileges. The UPGRADE DATABASE command explicitly grants DBADM authority to the SYSADM group. Therefore, there should be no upgrade impact but you should review all of the changes in authorities and make any necessary changes.
10
10
Setup if Upgrade to DB2 9.7 from DB2 9.1 or DB2 8• When upgrade instance to 9.7, audit configuration file is converted to DB2 V9.7 format.
• When upgrade database, instance-level configuration settings for auditing are used to create an audit policy in database. If audit facility is enabled at instance level, audit policy is associated with upgraded database to enable auditing. Otherwise, the audit policy is not associated. These actions ensure you observe same audit behavior on your database after upgrading to DB2 9.7.
1.Grant SECADM authority to users who manage audit facility: db2 CONNECT TO SAMPLE db2 GRANT SECADM ON DATABASE TO USER <user-id>
2.Query SYSCAT.AUDITPOLICIES validates DB2AUDIT_CFG_MIGR audit policy created during db upgrade
3.SELECT * FROM SYSCAT.AUDITPOLICIES A WHERE A.AUDITPOLICYNAME = 'DB2AUDIT_CFG_MIGR'
If DB2AUDIT_CFG_MIGR not created during upgrade, create using CREATE AUDIT POLICY statement.
4.Verify DB2AUDIT_CFG_MIGR audit policy associated with upgraded db by querying SYSCAT.AUDITUSE. SELECT * FROM SYSCAT.AUDITUSE U WHERE U.OBJECTNAME = 'SAMPLE‘
If db upgrade fails to associate DB2AUDIT_CFG_MIGR policy to upgraded db, use AUDIT statement to associate policy to db.
5.Optional: If want to extract all audit records from original audit log file had before upgrade and place contents into new audit log file in new default location, run db2audit command with extract parameter.
6.Now use DDL statements to manage database auditing: – CREATE AUDIT POLICY – ALTER AUDIT POLICY – AUDIT
You only have to perform this procedure if you upgraded your DB2 server from DB2 9.1 or DB2 8.
To setup security to manage database auditing in upgraded databases:
Grant SECADM authority to the users who manage the audit facility by using the GRANT command. The following sample commands show how to grant SECADM authority to a user:
db2 CONNECT TO SAMPLE db2 GRANT SECADM ON DATABASE TO USER <user-id>
Verify that the DB2AUDIT_CFG_MIGR audit policy was created for your databases during upgrade by querying the SYSCAT.AUDITPOLICIES system catalog view. The following sample query determines whether this audit policy was created:
db2 "SELECT * FROM SYSCAT.AUDITPOLICIES A WHERE A.AUDITPOLICYNAME = 'DB2AUDIT_CFG_MIGR'“
If the DB2AUDIT_CFG_MIGR audit policy was not created during upgrade, create it using the CREATE AUDIT POLICY statement.
Verify that the DB2AUDIT_CFG_MIGR audit policy was associated with the upgraded databases by querying the SYSCAT.AUDITUSE system catalog view. The following sample query determines whether the audit policy was associated with the SAMPLE database:
db2 "SELECT * FROM SYSCAT.AUDITUSE U WHERE U.OBJECTNAME = 'SAMPLE'“
11
11
Reference: Student Notes Only
1. If the database upgrade fails to associate the DB2AUDIT_CFG_MIGR audit policy to the upgraded databases, use the AUDIT statement to associate this policy to your database.
2. Optional: If you want to extract all audit records from the original audit log file that you had before upgrade and place the contents into a new audit log file in the new default location, run the db2audit command with the extract parameter. The original audit log file from a previous release remains in the same location that it was in prior to database upgrade. The default location for the audit logs in DB2 9.7 is: INSTHOME/sqllib/security/auditdata on Linux and UNIX, where INSTHOME is the instance home directory.INSTHOME\security\auditdata on Windows where INSTHOME is the instance home directory that stores user data and instance directories.
Now, you can use the following DDL statements to manage database auditing: • CREATE AUDIT POLICY • ALTER AUDIT POLICY • AUDIT
12
12
db2audit Command used to Manage Instance Level Auditing
DB2 provides an audit facility to assist in the detection of unknown or unanticipated access to data. The DB2 audit facility generates and permits the maintenance of an audit trail for a series of predefined database events. The records generated from this facility are kept in audit log files. The analysis of these records can reveal usage patterns which would identify system misuse. Once identified, actions can be taken to reduce or eliminate such system misuse. The audit facility acts at both the instance and database levels, independently recording all activities in separate logs based on either the instance or the database.
DB2 provides the ability to independently audit at both the instance and at the individual database level. The db2audit tool is used to configure audit at the instance level as well as control when such audit information is collected.
Authorized users of the audit facility can control the following actions within the audit facility, using db2audit: •Start recording auditable events within the DB2 instance. This does not include database level activities. •Stop recording auditable events within the DB2 instance. •Configure the behavior of the audit facility at the instance level only. •Select the categories of the auditable events to be recorded at the instance level only. •Request a description of the current audit configuration for the instance. •Flush any pending audit records from the instance and write them to the audit log. •Archive audit records from the current audit log for either the instance or a database under the instance. •Extract audit records from an archived audit log by formatting and copying them to a flat file or ASCII delimited file. Extraction is done in preparation for analysis of log records.
• To set audit categories objmaint and secmaint to collect all activity:– db2audit configure scope objmaint status both, secmaint status both
• To begin collecting audit data records for configured categories:– db2audit start
• To archive active instance level audit records:– db2audit archive
• To extract archived audit data to delimited files for loading into DB2 tables:– db2audit extract delasc to /auditdelasc
from files /auditarchive/db2audit.instance.log.*
Here are some examples of instance level audit management using the db2audit command.
The first step is to configure the audit categories that need to be collected.For example to set the audit categories objmaint and secmaint to collect both successes and failures the following command could be used:
db2audit configure scope objmaint status both, secmaint status both
The instance level audit facility must be stopped and started explicitly. When starting, the audit facility uses existing audit configuration information. The following command could be used to begin collecting audit data for the instance:db2audit start
The audit data must be archived before it can be extracted or saved to another location. The following command can be used to archive the current instance level audit data:db2audit archive
The following db2audit command could be used to extract a set of delimited files from the archived instance level audit files in a specified disk directory: db2audit extract delasc to /auditdelasc
from files /auditarchive/db2audit.instance.log.*
14
14
DB2 Instance and Database Auditing
• Instance level auditing:– Managed by user in SYSADM_GROUP defined by DBM CFG – Requires db2audit start command to begin collection of audit data– Logs all configured categories for all activity in a DB2 instance
• Database level auditing:– Managed by user with SECADM authority– Does NOT require db2audit start command
to begin data collection– Logs audit data based on assigned audit policies
• Both types of auditing:– Utilize audit buffer defined by AUDIT_BUF_SZ in DBM CFG
• Synchronous writes if AUDIT_BUF_SZ = 0 can effect performance• Asynchronous writes if AUDIT_BUF_SZ > 0
The management of DB2 instance level auditing must be performed by a user in the SYSADM_GROUP defined in the DBM configuration. The db2audit start and stop options are used to begin and suspend audit data collection for instance level auditing. The instance level auditing lacks the flexibility of database level auditing.
Database level auditing must be managed by a user with SECADM authority for the DB2 database. No db2audit start command is necessary to begin collection of database level audit data. As soon as an audit policy is assigned to some part of the database using the AUDIT command, DB2 will begin to collect the necessary audit records. The audit policies provide for very flexible collection of specific audit records.
Controlling the timing of writing audit records to the active log
The writing of the audit records to the active log can take place synchronously or asynchronously with the occurrence of the events causing the generation of those records. The value of the audit_buf_sz database manager configuration parameter determines when the writing of audit records is done.
If the value of audit_buf_sz is zero (0), the writing is done synchronously. The event generating the audit record waits until the record is written to disk. The wait associated with each record causes the performance of the DB2 database to decrease.
If the value of audit_buf_sz is greater than zero, the record writing is done asynchronously. The value of the audit_buf_sz when it is greater than zero is the number of 4 KB pages used to create an internal buffer. The internal buffer is used to keep a number of audit records before writing a group of them out to disk. The statement generating the audit record as a result of an audit event will not wait until the record is written to disk, and can continue its operation.
In the asynchronous case, it could be possible for audit records to remain in an unfilled buffer for some time. To prevent this from happening for an extended period, the database manager forces the writing of the audit records regularly. An authorized user of the audit facility may also flush the audit buffer with an explicit request. Also, the buffers are automatically flushed during an archive operation
15
15
Audit Path Configuration
• Default audit data path: ~/sqllib/security/auditdata– Windows: instance\security\auditdata
• Data path configuration supports Database Partition Expressions:– Previously used in Automatic Storage– Necessary in a cluster environment for HA failover
db2audit configure datapath /auditForNode $N
• An Archive Path can also be configured:– Sets default path to write archived audit log files – db2audit and stored procedures are aware of path, so can leave these
Storage of audit logsThe system administrator can configure the path for the active audit log and the archived audit log using the db2audit configure
command. Archiving the audit log moves the active audit log to an archive directory while the server begins writing to a new, active audit log. This allows the audit log to be stored offline without having to extract data from it until necessary. After the security administrator or system administrator has archived a log, they can extract data from the log into delimited files. The data in the delimited files can be loaded into DB2 database tables for analysis.
Configuring the location of the audit logs allows you to place the audit logs on a large, high-speed disk, with the option of having separate disks for each node in a database partitioning feature (DPF) installation. In a DPF environment, the path for the active audit log can be a directory that is unique to each node. Having a unique directory for each node helps to avoid file contention, because each node is writing to a different disk.
The default path for the audit logs on Windows operating systems is instance\security\auditdata and on Linux and UNIX operating systems is instance/security/auditdata. If you do not want to use the default location, you can choose different directories (you can create new directories on your system to use as alternative locations, if they do not already exist).
To set the path for the active audit log location and the archived audit log location, use the db2audit configure command with the datapath and archivepath parameters, as shown in this example:
The audit log storage locations you set using db2audit apply to all databases in the instance. Note: If there are multiple instance on the server, then each instance should each have separate data and archive paths.
The path for active audit logs (datapath) in a DPF environmentIn a DPF environment, the same active audit log location (set by the datapath parameter) must be used on each partition. There are two
ways to accomplish this: • Use database partition expressions when you specify the datapath parameter. Using database partition expressions allows the
partition number to be included in the path of the audit log files and results in a different path on each database partition. • Use a shared drive that is the same on all nodes.
You can use database partition expressions anywhere within the value you specify for the datapath parameter. For example, on a three node system, where the database partition number is 10, the following command:db2audit configure datapath '/pathForNode $N‘
creates the following files: • /pathForNode10 • /pathForNode20 • /pathForNode30 Note: You cannot use database partition expressions to specify the archive log file path (archivepath parameter).
16
16
Reference: Student Notes Only
Archiving active audit logsThe system administrator can use the db2audit tool to archive both instance and database audit logs as well as to extract audit data from archived logs of either type. To archive the active audit log, the security administrator can use the SYSPROC.AUDIT_ARCHIVE stored procedure. To extract data from the log and load it into delimited files, the security administrator can use the SYSPROC.AUDIT_DELIM_EXTRACT stored procedure.
The archived log files do not need to be immediately loaded into tables for analysis; they can be saved for future analysis. For example, they may only need to be looked at when a corporate audit is taking place. If a problem occurs during archive, such as running out of disk space in the archive path, or the archive path does not exist, the archive process fails and an interim log file with the file extension .bk is generated in the audit log data path, for example, db2audit.instance.log.0.20070508172043640941.bk. After the problem is resolved (by allocating sufficient disk space in the archive path, or by creating the archive path) you must move this interim log to the archive path. Then, you can treat it in the same way as a successfully archived log.
Archiving active audit logs in a DPF environmentIn a DPF environment, if the archive command is issued while the instance is running, the archive process automatically runs on every node. The same timestamp is used in the archived log file name on all nodes. For example, on a three node system, where the database partition number is 10, the following command:
db2audit archive to /auditarchivecreates the following files: •/auditarchive/db2audit.log.10.timestamp•/auditarchive/db2audit.log.20.timestamp•/auditarchive/db2audit.log.30.timestamp
If the archive command is issued while the instance is not running, you can control on which node the archive is run by one of the following methods: •Use the node option with the db2audit command to perform the archive for the current node only. •Use the db2_all command to run the archive on all nodes. For example: db2_all db2audit archive node to /auditarchiveThis sets the DB2NODE environment variable to indicate on which nodes the command is invoked.•Alternatively, you can issue an individual archive command on each node separately. For example: On node 10: db2audit archive node 10 to /auditarchiveOn node 20: db2audit archive node 20 to /auditarchiveOn node 30: db2audit archive node 30 to /auditarchiveNotes:•When the instance is not running, the timestamps in the archived audit log file names are not the same on each node.•It is recommended that the archive path is shared across all nodes, but it is not required.
The visual shows and example of the db2audit describe command output that lists the current status for instance level audit options, including the audit data and archive paths.
Audit log file names The audit log files have names that distinguish whether they are instance-level or database-level logs and which partition they originate from in a database partitioning feature (DPF) environment. Archived audit logs have the timestamp of when the archive command was run appended to their file name.
Active audit log file namesIn a DPF environment, the path for the active audit log can be a directory that is unique to each partition so that each partition writes to an individual file. In order to accurately track the origin of audit records, the partition number is included as part of the audit log file name.
For example, on partition 20, the instance level audit log file name is db2audit.instance.log.20. For a database called testdb in this instance, the audit log file is db2audit.db.testdb.log.20.
In a non-DPF environment the partition number is considered to be 0 (zero). In this case, the instance level audit log file name is db2audit.instance.log.0. For a database called testdb in this instance, the audit log file is db2audit.db.testdb.log.0.
Archived audit log file names When the active audit log is archived, the current timestamp in the following format is appended to the filename: YYYYMMDDHHMMSS (where YYYY is the year, MM is the month, DD is the day, HH is the hour, MM is the minutes, and SS is the seconds.
The file name format for an archive audit log depends on the level of the audit log: •instance-level archived audit log - The file name of the instance-level archived audit log is: db2audit.instance.log.partition.YYYYMMDDHHMMSS. • database-level archived audit log - The file name of the database-level archived audit log is: db2audit.dbdatabase.log.partition.YYYYMMDDHHMMSS.
In a non-DPF environment, the value for partition is 0 (zero).
The timestamp represents the time that the archive command was run, therefore, it does not always precisely reflect the time of the last record in the log. The archived audit log file may contain records with timestamps a few seconds later than the timestamp in the log file name because: When the archive command is issued, the audit facility waits for the writing of any in-process records to complete before creating the archived log file. In a multi-machine environment, the system time on a remote machine may not be synchronized with the machine where the archive command is issued.
In a DPF environment, if the server is running when archive is run, the timestamp is consistent across partitions and reflects the timestamp generated at the partition at which the archive was performed.
18
•Only SECADM user can create an audit policy for use in a database
Audit Policies Assigned using AUDIT StatementAUDIT statement determines audit policy used for database or databaseobject at current server. When object in use, audited according to that policy.>>-AUDIT----------+-DATABASE------------------+-+->
• Examples:AUDIT DATABASE USING POLICY DBAUDPRFAUDIT ROLE TELLER REPLACE POLICY TELLERPRFAUDIT TABLE EMPLOYEE REMOVE POLICY
AUDIT statement: The AUDIT statement determines the audit policy that is to be used for a particular database or database object at the current server. Whenever the object is in use, it is audited according to that policy.
Invocation: This statement can be embedded in an application program or issued interactively. It is an executable statement that can be dynamically prepared only if DYNAMICRULES run behavior is in effect for the package (SQLSTATE 42509).
Authorization: The privileges held by the authorization ID of the statement must include SECADM authority. DATABASE — Specifies that an audit policy is to be associated with or removed from the database at the current server. All auditable events that occur within the database are audited according to the associated audit policy. TABLE table-name — Specifies that an audit policy is to be associated with or removed from table-name. The table-name must identify a table, materialized query table (MQT), or nickname that exists at the current server (SQLSTATE 42704). It cannot be a view, a catalog table, a declared temporary table (SQLSTATE 42995), or a typed table (SQLSTATE 42997). Only EXECUTE category audit events, with or without data, will be generated when the table is accessed, even if the policy indicates that other categories should be audited. TRUSTED CONTEXT context-name — Specifies that an audit policy is to be associated with or removed from context-name. The context-name must identify a trusted context that exists at the current server (SQLSTATE 42704). All auditable events that happen withinthe trusted connection defined by the trusted context context-name will be audited according to the associated audit policy. USER authorization-name — Specifies that an audit policy is to be associated with or removed from the user with authorization ID authorization-name. All auditable events that are initiated by authorization-name will be audited according to the associated audit policy. GROUP authorization-name — Specifies that an audit policy is to be associated with or removed from the group with authorization ID authorization-name. All auditable events that are initiated by users who are members of authorization-name will be audited according to the associated audit policy. If user membership in a group cannot be determined, the policy will not apply to that user. ROLE authorization-name — Specifies that an audit policy is to be associated with or removed from the role with authorization ID authorization-name. The authorization-name must identify a role that exists at the current server (SQLSTATE 42704). All auditable events that are initiated by users who are members of authorization-name will be audited according to the associated audit policy. Indirect role membership through other roles or groups is valid. SYSADM, SYSMAINT, SYSCTRL, SYSMON, DBADM or SECADM — Specifies that an audit policy is to be associated with or removed from the specified authority. All auditable events that are initiated by a user who holds the specified authority, even if that authority is not required for the event, will be audited according to the associated audit policy. USING, REMOVE, or REPLACE Specifies whether the audit policy should be used, removed, or replaced for the specified object.
20
20
Reference: Student Notes Only
•USING — Specifies that the audit policy is to be used for the specified object. An existing audit policy must not already be defined for the object (SQLSTATE 5U041). If an audit policy already exists, it must be removed or replaced.•REMOVE — Specifies that the audit policy is to be removed from the specified object. Use of the object will no longer be audited according to the audit policy. The association is deleted from the catalog when the audit policy is removed from the object.•REPLACE — Specifies that the audit policy is to replace an existing audit policy for the specified object. This combines both REMOVE and USING options into one step to ensure that there is no period of time in which an audit policy does not apply to the specified object. If a policy was not in use for the specified object, REPLACE is equivalent to USING. POLICY policy-name — Specifies the audit policy that is to be used to determine audit settings. The policy-name must identify an existing audit policy at the current server (SQLSTATE 42704).
Statement Rules An AUDIT-exclusive SQL statement must be followed by a COMMIT or ROLLBACK statement (SQLSTATE 5U021). AUDIT-exclusive SQL statements are: AUDIT CREATE AUDIT POLICY, ALTER AUDIT POLICY, or DROP (AUDIT POLICY) DROP (ROLE or TRUSTED CONTEXT if it is associated with an audit policy) An AUDIT-exclusive SQL statement cannot be issued within a global transaction (SQLSTATE 51041) such as, for example, an XA transaction. An object can be associated with no more than one policy (SQLSTATE 5U042).
Changes are written to the catalog, but do not take effect until after a COMMIT statement executes. Changes do not take effect until the next unit of work that references the object to which the audit policy applies. For example, if the audit policy is in use for the database, no current units of work will begin auditing according to the policy until after a COMMIT or a ROLLBACK statement completes. If theobject with which an audit policy is associated is dropped, the association to the audit policy is removed from the catalog and no longer exists. If that object is recreated at some later time, the object will not be audited according to the policy that was associated with it when the object was dropped.
Example 1: Use the audit policy DBAUDPRF to determine the audit settings for the database at the current server. AUDIT DATABASE USING POLICY DBAUDPRF Example 2: Remove the audit policy from the EMPLOYEE table. AUDIT TABLE EMPLOYEE REMOVE POLICY Example 3: Use the audit policy POWERUSERS to determine the audit settings for the authorities SYSADM, DBADM, and SECADM, as well as the group DBAS. AUDIT SYSADM, DBADM, SECADM, GROUP DBAS USING POLICY POWERUSERS Example 4: Replace the audit policy for the role TELLER with the new policy TELLERPRF. AUDIT ROLE TELLER REPLACE POLICY TELLERPRF
212121
Although each object can only be associated with a single audit policy, many objects can be assigned the same policy. This means that all of the types of audit data needed at the database level need to be assigned to a single audit policy for the database. A single audit policy could be assigned to many tables or many users. If audit policies are associated with groups or roles, a user may inherit the combined audit types for all of the groups or roles that they are a member
21
21
Audit Statement Additional Information
• Controls the association of audit policies with database objects:–Many objects can be audited according to a single audit policy–Only one audit policy can be associated with any one objectAUDIT AUTHORITY DBADM, ROLE MARKETING,ROLE ACCOUNTING, ROLE SUPPORTUSING POLICY SENSITIVE_DATA_POL;
• Audit policies are combined when multiple policies are in effect, for example: –group1 audited according to policy1, –group2 audited according to policy2–User Pat is a member of both groups
• Combined in an inclusive manner
222222
The AUDIT statement can be used to assign or remove an audit policy at the database level. All auditable events that occur within the database are audited according to the associated audit policy.
Unlike instance level auditing, which begins when the db2audit start command is used, the assignment of an audit policy to any object, like the database implies that auditing will begin being collected, without needing to manually start the audit data collection.
22
• All auditable events generated within aconnection will be audited according topolicy associated with the databaseAUDIT DATABASE USING POLICY AUDITDB
The AUDIT statement can be used to associate or remove an audit policy for a table. The object could be a table, a materialized query table (MQT), or a nickname that exists at the current server. The object can NOT be a view, a catalog table, a declared temporary table (SQLSTATE 42995), or a typed table (SQLSTATE 42997). Only EXECUTE category audit events, with or without data, will be generated when the table is accessed, even if the policy indicates that other categories should be audited. The audit policy that applies to a table does not apply to a materialized query table (MQT) based on that table. It is recommended that if you associate an audit policy with a table, you also associate that policy with any MQT based on that table. The compiler might automatically use an MQT, even though an SQL statement references the base table; however, the audit policy in use for the base table will still be in effect.
You cannot DROP a policy if a table is associated with it. To “unassociate” a table from a policy, use the “REMOVE PLOLICY” clause of the AUDIT TABLE statement. After the REMOVE POLICY completes successfully, you may drop the AUDIT POLICY.AUDIT TABLE TEST.TRANSACTION REMOVE POLICYDROP AUDIT POLICY SENSITIVEDATAPOLICY
23
• Events generated whenever DML is executed against audited tableAUDIT TABLE EMPLOYEE REMOVE POLICY
An audit policy can be assigned to one or more of the special authorities for a DB2 instance or database including: •SYSADM , DBADM , SECADM, SYSCTRL, SYSMAINT, SYSMON
All auditable events that are initiated by a user who holds the specified authority, even if that authority is not required for the event, will be audited according to the associated audit policy.
The example assigns the audit policy POWERUSERS to determine the audit settings for the authorities SYSADM, DBADM, and SECADM, as well as a group named DBAS.
• Events logged whenever user generating event holds one of audited authorities even if authority is not required for event.For example:AUDIT SYSADM, DBADM, SECADM, GROUP DBAS USING POLICY POWERUSERS
The AUDIT statement can be used to assign or remove an audit policy from authorization IDs representing users, groups, or roles. All auditable events that are initiated by the specified user are audited according to the audit policy. The auditable events that are initiated by users that are a member of the group or role are audited according to the audit policy. Indirect role membership, such as through other roles or groups, is also included.
The example shown replaces the audit policy for the role TELLER with the new policy named TELLERPOL.
When a SET SESSION USER statement is executed, the audit policies associated with the original user (and that user’s group and role memberships and authorities) are combined with the policies that are associated with the user specified in the SET SESSION USER statement. The audit policies associated with the original user are still in effect, as are the policies for the user specified in the SET SESSION USER statement. If multiple SET SESSION USER statements are issued within a session, only the audit policies associated with the original user and the current user are considered.
• Groups and Roles:– Events logged whenever user generating
event is member of group or role that is associated with policyAUDIT ROLE TELLER REPLACE POLICY TELLERPOL
Our ROLE Is
TELLER
262626
The AUDIT statement can be used to associate or remove an audit policy from a trusted context object created by the SECADM user. The trusted context must exist at the current server (SQLSTATE 42704). All auditable events that happen within the trusted connection will be audited according to the associated audit policy.
When a switch user operation is performed within a trusted context, all audit policies are re-evaluated according to the new user, and no policies from the old user are used for the current session. This applies specifically to audit policies associated directly with the user, the user’s group or role memberships, and the user’s authorities. For example, if the current session was audited because the previous user was a member of an audited role, and the switched-to user is not a member of that role, that policy no longer applies to the session.
Granularity – Trusted Contexts●Events are logged when generated
from within a trusted context that is associated with a policy
●When a switch user operation is performed within a trusted context, all audit policies are re-evaluated based on new user replacing any policies from old user for current session.
272727
The EXECUTE category for auditing SQL statements
The EXECUTE category allows you to accurately track the SQL statements a user issues. Prior to DB2 9.5, the CONTEXT category was used to find this information.
This EXECUTE category captures the SQL statement text as well as the compilation environment and other values that are needed to replay the statement at a later date. For example, replaying the statement can show you exactly which rows a SELECT statement returned. In order to re-run a statement and produce the exact same result the database tables must first be restored to their state when the statement was issued.
27
27
EXECUTE category (1 of 2)
• EXECUTE is database level category that audits execution of SQL statements– Replaces the CONTEXT category for SQL statement execution
• Can optionally include input data– Host variables and parameter markers
• Given a reproduction of the data at the time of an event, the EXECUTE category provides sufficient information to replay statements to understand their effect (for example, what rows did that SELECT statement return)
282828
When you audit using the EXECUTE category, the statement text for both static and dynamic SQL is recorded, as are input parameter markers and host variables. You can configure the EXECUTE category to be audited with or without input values. Global variables are not audited. The auditing of EXECUTE events takes place at the completion of the event (for SELECT statements this is on cursor close). The status that the event completed with is also stored. Because EXECUTE events are audited at completion, long-running queries do not immediately appear in the audit log. The preparation of a statement is not considered part of the execution. Most authorization checks are performed at prepare time (for example, SELECT privilege). This means that statements that fail during prepare due to authorization errors do not generate EXECUTE events. Statement Value Index, Statement Value Type and Statement Value Data fields may be repeated for a given execute record. For the report format generated by the extraction, each record lists multiple values. For the delimited file format, multiple rows are used. The first row has an event type of STATEMENT and no values. Following rows have an event type of DATA, with one row for each data value associated with the SQL statement. You can use the event correlator and application ID fields to link STATEMENT and DATA rows together. The columns Statement Text, Statement Isolation Level, and Compilation Environment Description are not present in the DATA events. The statement text and input data values that are audited are converted into the database code page when they are stored on disk (all audited fields are stored in the database code page). No error is returned if the code page of the input data is not compatible with the database code page; the unconverted data will be logged instead. Because each database has it's own audit log, databases having different code pages does not cause a problem.
28
28
EXECUTE category (2 of 2)
• The EXECUTE can provide:– Statement text– Data type, length, value of input host variables and
parameter markers• Does not include LOBS, LONG, XML & structured types
– Compilation Environment– Counts indicating number of rows returned and rows modified
• The EXECUTE record is produced when execution completes
• If statement fails prior to execution, no EXECUTE data is generated:– This would include statements that fail for lack of proper security.
The CHECKING audit category can be used to track these events.
1. Archive active audit log with stored procedure SYSPROC.AUDIT_ARCHIVE.2. Use SYSPROC.AUDIT_LIST_LOGS table function to determine archived logs
of interest.
3. Use SYSPROC.AUDIT_DELIM_EXTRACT procedure to extract data into delimited files.
SECADM or user granted EXECUTE privilege on these routines can:
db2audit extract file …
These are the steps to archive and extract the audit logs using the audit routines:
1. Schedule an application to perform regular archives of the active audit log using the stored procedure SYSPROC.AUDIT_ARCHIVE. 2. Determine which archived log files are of interest. Use the SYSPROC.AUDIT_LIST_LOGS table function to list all of the archived
audit logs. 3. Pass the file name as a parameter to the SYSPROC.AUDIT_DELIM_EXTRACT stored procedure to extract data from the log and
load it into delimited files. 4. Load the audit data into DB2 database tables for analysis.
The archived log files do not need to be immediately loaded into tables for analysis; they can be saved for future analysis.
For example, they may only need to be looked at when a corporate audit is taking place. If a problem occurs during archive, such as running out of disk space in the archive path, or the archive path does not exist, the archive process fails and an interim log file with the file extension .bk is generated in the audit log data path, for example, db2audit.instance.log.0.20070508172043640941.bk. After the problem is resolved (by allocating sufficient disk space in the archive path, or by creating the archive path) you must move this interim log to the archive path. Then you can treat it in the same as a successfully archived log.
The security administrator can use the SYSPROC.AUDIT_ARCHIVE stored procedure and table function, the SYSPROC.AUDIT_DELIM_EXTRACT stored procedure, and the SYSPROC.AUDIT_LIST_LOGS table function to archive audit logs and extract data to delimited files. The security administrator can delegate use of these routines to another user by granting the user EXECUTE privilege on these routines. Only the security administrator can grant EXECUTE privilege on these routines. EXECUTE privilege WITH GRANT OPTION cannot be granted for these routines (SQLSTATE 42501). You must be connected to a database in order to use these stored procedures and table functions to archive or list that database’s audit logs.
If you copy the archived files to another database system, and you want to use the stored procedures and table functions to access them, ensure that the database name is the same, or rename the files to include the same database name.
The writing of the audit records to the active log can take place synchronously or asynchronously with the occurrence of the events causing the generation of those records. The value of the audit_buf_sz database manager configuration parameter determines when the writing of audit records is done. If the value of audit_buf_sz is zero (0), the writing is done synchronously. The event generating the audit record waits until the record is written to disk. The wait associated with each record causes the performance of the DB2 database to decrease. If the value of audit_buf_sz is greater than zero, the record writing is done asynchronously. The value of the audit_buf_sz when it is greater than zero is the number of 4 KB pages used to create an internal buffer. The internal buffer is used to keep a number of audit records before writing a group of them out to disk. The statement generating the audit record as a result of an audit event will not wait until the record is written to disk, and can continue its operation. In the asynchronous case, it could be possible for audit records to remain in an unfilled buffer for some time. To prevent this from happening for an extended period, the database manager forces the writing of the audit records regularly. An authorized user of the audit facility may also flush the audit buffer with an explicit request. Also, the buffers are automatically flushed during an archive operation. There are differences when an error occurs dependent on whether there is synchronous or asynchronous record writing. In asynchronous mode there may be some records lost because the audit records are buffered before being written to disk. In synchronous mode there may be one record lost because the error could only prevent at most one audit record from being written.
The audit logs are per pureScale member.
303030
The security administrator can delegate use of these routines to another user by granting the user EXECUTE privilege on these routines. Only the security administrator can grant EXECUTE privilege on these routines. EXECUTE privilege WITH GRANT OPTION cannot be granted for these routines (SQLSTATE 42501). If you copy archived audit files to another database system, and you want to use the SYSPROC.AUDIT_DEL_EXTRACT stored procedure to access them, ensure that the database name is the same, or rename the files to include the same database name. The SYSPROC.AUDIT_ARCHIVE stored procedure does not archive the instance level audit log. The system administrator must use the db2audit command to archive and extract the instance level audit log.
Procedure and table function parametersDirectory: An input argument of type VARCHAR(1024) that specifies the directory where the archived audit file(s) will be written. The directory must exist on the server and the instance owner must be able to create files in that directory. If the argument is null or an empty string, the default directory is used. Dbpartitionnum: An input argument of type INTEGER that specifies a valid database partition number. Specify -1 for the current database partition, NULL or -2 for an aggregate of all database partitions. Authorization: Execute privilege on the AUDIT_ARCHIVE procedure or table function, and SECADM authority on the database.AUDIT_DELIM_EXTRACT: performs extract to delimited file The AUDIT_DELIM_EXTRACT stored procedure performs an extract to a delimited file on archived audit files of the connected database. Specifically, to those archived audit files that have filenames that match the specified mask pattern.
30
Audit-related Stored Procedures and Functions
• SYSPROC.AUDIT_ARCHIVE:– Allows SECADM to archive active audit log for database– Call Parameters can override defaults for output location
for archived audit log and database partition number
CALL SYSPROC.AUDIT_ARCHIVE( '/auditarchive', -2 )
• SYSPROC.AUDIT_DELIM_EXTRACT:• Allows SECADM to perform extract of archived audit logs for database
into set of delimited files that can be loaded into DB2 tables• Call parameters can override defaults for delimiter, source and target
locations, file name mask and selection criteria for event types
CALL SYSPROC.AUDIT_DELIM_EXTRACT(NULL,'$HOME/AUDIT_DELIM_EXTRACT',NULL, '%20070618%', 'CATEGORIES EXECUTE STATUS BOTH')
313131
The database security administrator can use the AUDIT_LIST_LOGS table function in a SQL SELECT statement to list the names of archived audit log files. The names returned might then be used with the AUDIT_DELIM_EXTRACT stored procedure to generate the audit data in a set of files.
AUDIT_LIST_LOGS table function - Lists archived audit log filesThe AUDIT_LIST_LOGS table function lists the archived audit log files for a database which are present in the specified directory.
Procedure parametersdirectory - An optional input argument of type VARCHAR(1024) that specifies the directory where the archived audit file(s) will be written. The directory must exist on the server and the instance owner must be able to create files in that directory. If the argument is null or an empty string, then the search default directory is used.
AuthorizationEXECUTE privilege on AUDIT_LIST_LOGS table function and SECADM authority on the database.
• SYSPROC.AUDIT_LIST_LOGS– Allows SECADM to list archived audit logs for database prior to
extraction. – Can specify source location of archived audit logs as parameter.
SELECT FILE FROM TABLE(SYSPROC.AUDIT_LIST_LOGS('/auditarchive')) AS TWHERE FILE LIKE 'db2audit.dbname.log.0.200604%‘
Listing Archived Audit Logs using a Table Function
32
32
Access to Audit Data1. Use db2audit.ddl sample DDL statements in
sqllib/misc to create set of DB2 tables:• One table is defined for each category of audit data• A TABLESPACE with page size at least 8K must be used
2. Use SYSPROC.AUDIT_ARCHIVE procedure to archive active audit log data
3. Use SYSPROC.AUDIT_DELIM_EXTRACT procedure to extract archived audit data to set of delimited files:• One file for each category of audit data, for example,
execute audit records written to a file named ‘execute.del’
• Large object column data written to a file named ‘auditlobs’
4. Use LOAD or IMPORT utility to load data into tables• SECADM will need to be granted LOAD authority by
SYSADM
5. Use SQL to query audit data in tables
The SECADM user can access the audit data generated for database level audits using the DB2 provided stored procedures and standard DB2 utilities.
Creating tables to hold the DB2 audit data Before you can work with audit data in database tables, you need to create the tables to hold the data. You should consider creating these tables in a separate schema to isolate the data in the tables from unauthorized users. The format of the tables you need to create to hold the audit data may change from release to release. New columns may be added or the size of an existing column may change. The DB2 provided script, db2audit.ddl, creates tables of the correct format to contain the audit records. If you do not want to use all of the data that is contained in the files, you can omit columns from the table definitions, or bypass creating certain tables, as required. If you omit columns from the table definitions, you must modify the commands that you use to load data into these tables. Before audit data can be extracted, it needs to be archived. The SYSPROC.AUDIT_ARCHIVE procedure can be used to archive current audit records into a audit archive file. The SYSPROC.AUDIT_DEL_EXTRACT procedure can be used to extract all or selected audit records to a set of delimited files. There will be one delimited file for each audit record type. The delimited files can be loaded into DB2 tables using a LOAD or IMPORT utility. In order run a LOAD utility the SECADM user will need to be granted LOAD authority for the database.
33
33
Example of Query using EXECUTE Data
USERID EVENT ACTIVITY_TYPE ROWSMODIFIED ROWSRETURNED SQLTEXT---------- --------------- ------------- ------------ -------------------- ------------------------------db2user STATEMENT READ_DML 0 147 select * from inst461.stock db2user STATEMENT READ_DML 0 1 SELECT TABNAME, TABSCHEMA, TYPdb2user STATEMENT READ_DML 0 147 select * from mytestdb2user STATEMENT WRITE_DML 3 0 update mytest set qty = 0 wherdb2user STATEMENT WRITE_DML 3 0 update mytest set qty = 10 whedb2user STATEMENT READ_DML 0 147 select * from mytestdb2user STATEMENT WRITE_DML 3 0 delete from mytest where itedb2user STATEMENT WRITE_DML 3 0 delete from mytest where itedb2user STATEMENT WRITE_DML 0 0 delete from mytest where itedb2user STATEMENT READ_DML 0 2 select * from syscat.rolesinst461 STATEMENT WRITE_DML 3 0 update stock set qty = 10 wherinst461 STATEMENT WRITE_DML 6 0 update stock set qty = 0 where
12 record(s) selected.
SELECT substr(USERID,1,10) as USERID, substr(EVENT,1,15) as EVENT,substr(ACTIVITYTYPE,1,12) as ACTIVITY_TYPE, ROWSMODIFIED, ROWSRETURNED,substr(STMTTEXT,1,30) AS SQLTEXT FROM DB2SEC."EXECUTE" AS "EXECUTE“WHERE ACTIVITYTYPE IN ('READ_DML','WRITE_DML') ORDER BY "EXECUTE".TIMESTAMP ASC
The visual shows an example of a SQL query that accesses the EXECUTE audit data. The output includes an activity type, the SQL text and a count for the number of rows returned or modified for DML statements.
34
34
Extracting Audit Data to a File
• Use the db2audit command file option:db2audit extract file sampexec.txt category execute from files '/home/inst461/audit_archive/db2audit.db.MUSICDB.log.0.20080706225139'timestamp=2008-07-06-22.47.46.597946;
…………………statement text=select empno, lastname , workdept, salary from hr.employee order by workdept,empno;statement isolation level=CS;Compilation Environment Descriptionisolation: CSquery optimization: 5min dec div 3: NOdegree: 1 SQL rules: DB2refresh age: +00000000000000.000000resolution timestamp: 2008-07-06-22.47.46.000000federated asynchrony: 0maintained table type: SYSTEM;
rows modified=0;rows returned=42;
The visual shows an example db2audit command that a SYSADM user could use to create a file containing the generated audit data. In this example the EXECUTE category audit records will be formatted and written to a file.
The command used in this example was:
db2audit extract file sampexec.txt category execute from files '/home/inst461/audit_archive/db2audit.db.MUSICDB.log.0.20080706225139'
35
35
Audit Facility Record Layout Details
SC27-2433-01 IBM DB2 9.7 LUW Database Security Guide – Chapter 9 - Audit Facility Record Layout Details
For additional information consult SC27-2433 IBM DB2 9.7 LUW Database Security Guide Chapter 9.
36
36
DB2 Audit Management Expert for Multiplatforms• Collects and correlates data access information from variety of DB2
resources to produce comprehensive view of business activity for auditors.• Provides following features and functions:
–Data collection--Collect and correlate many different types of information into an audit repository:• Changes to an audited object (SQL UPDATE, INSERT, DELETE) • Reads of an audited object (SQL SELECT) • Explicit GRANT and REVOKE operations (to capture events where users may be
attempting to modify authorization levels) • Authorization attempts that are denied due to inadequate authorization • CREATE, ALTER, and DROP operations against an audited object (such as a table)
–Reporting user interface—Provides auditors with flexible options for examining data in audit repository.
–Administration user interface—Enables product administrators to facilitate configuration of data queries.
–Reporting options—Enables auditors to create meaningful reports. –Log Analysis—Enables auditors to generate reports through reporting client,
detailing changes that have occurred in particular tables within given time period.
DB2 Audit Management Expert is a separately licensed product.
DB2 Audit Management Expert collects and correlates data access information from a variety of DB2 resources to produce a comprehensive view of business activity for auditors.
See DB2 Audit Management Expert for Multiplatforms User's Guide (SC19-1093-03) for more details.
•db2 CREATE AUDIT POLICY statement and db2 AUDIT statement–Authorization• SECADM
•SECADM needs LOAD authority to load delimited audit data into tables
Recommended Option
38
38
Audit Performance Considerations
•Very dependent on type of workload–OLTP has higher overhead than warehousing
•Very dependent on speed of disks–Use fast disks–Use individual disks for each partition in DPF–Separate active audit log and archived audit logs–Isolate audit data from other database data on separate disks
•Very dependent on number of events generated–Use Audit Policies to only audit what is absolutely necessary
•CONTEXT and EXECUTE are heaviest categories–Others have little impact
•If AUDIT_BUF_SZ =0, writing to Active Log is synchronous. –Event generating audit record waits until record written to disk which
causes performance of database to decrease
When working in a partitioned database environment, many of the auditable events occur at the database partition at which the user is connected (the coordinator partition) or at the catalog partition (if they are not the same database partition). The implication of this is that audit records can be generated by more than one database partition. Part of each audit record contains information identifying the coordinator partition and originating partition (the partition where audit record originated).
The path for active audit logs (datapath) in a DPF environment In a DPF environment, the same active audit log location (set by the datapath parameter) must be used on each partition. There are two ways to accomplish this: 1. Use database partition expressions when you specify the datapath parameter. Using database partition expressions allows the partition number to be included in the path of the audit log files and results in a different path on each database partition. 2. Use a shared drive that is the same on all nodes.
You can use database partition expressions anywhere within the value you specify for the datapath parameter. For example, on a three node system, where the database partition number is 10, the following command: db2audit configure datapath ’/pathForNode $N’creates the following files: v /pathForNode10 v /pathForNode20 v /pathForNode30
Note: You cannot use database partition expressions to specify the archive log file path (archivepath parameter).
39
39
Best Practices for Managing Auditing
•Archive audit log regularly–For long term storage, compress groups of archived files. Delete logs
no longer of interest.
•Error Handling: Use error type AUDIT when create audit policy–If AUDIT and run out of disk space, error returned. Error condition must
be corrected before more auditable actions can continue. If NORMAL, logging fails and no error returned to user. Operation continues as if error did not happen.
•Remember to Commit. Do not take affect until next UOW.–CREATE AUDIT POLICY, ALTER AUDIT POLICY, and DROP AUDIT
POLICY,DROP ROLE and DROP TRUSTED CONTEXT
•Table format to hold archived data may change each release.–run db2audit.ddl for each release
•See student notes for other best practices:
Best practices for managing your audit include regularly archiving the audit log, using the error type AUDIT when you create an audit policy, and other tips as described here.
Archiving the audit logYou should archive the audit log on a regular basis. Archiving the audit log moves the current audit log to an archive directory while the server begins writing to a new, active audit log. The name of each archived log file includes a timestamp that helps you identify log files of interest for later analysis. For long term storage, you may want to compress groups of archived files. For archived audit logs that you are no longer interested in, the instance owner can simply delete the files from the operating system.
Error handlingWhen you create an audit policy, you should use the error type AUDIT, unless you are just creating a test audit policy. For example, if the error type is set to AUDIT, and an error occurs, such as running out of disk space, then an error is returned. The error condition must be corrected before any more auditable actions can continue. However, if the error type had been set to NORMAL, the logging would simply fail and no error is returned to the user. Operation continues as if the error did not happen. If a problem occurs during archive, such as running out of disk space in the archive path, or the archive path does not exist, the archive process fails and an interim log file with the file extension .bk is generated in the audit log data path, for example, db2audit.instance.log.0.20070508172043640941.bk. After the problem is resolved (by allocating sufficient disk space in the archive path, or by creating the archive path) you must move this interim log to the archive path. Then, you can treat it in the same way as a successfully archived log.
DDL statement restrictionsSome data definition language (DDL) statements, called AUDIT exclusive SQL statements, do not take effect until the next unit of work. Therefore, you are advised to use a COMMIT statement immediately after each of these statements. The AUDIT exclusive SQL statements are: AUDIT, CREATE AUDIT POLICY, ALTER AUDIT POLICY, and DROP AUDIT POLICY,DROP ROLE and DROP TRUSTED CONTEXT, if the role or trusted context being dropped is associated with an audit policy
Table format for holding archived data may change The security administrator can use the SYSPROC.AUDIT_DEL_EXTRACT stored procedure, or the system administrator can use the db2audit extract command, to extract audit records from the archived audit log files into delimited files. You can load the audit data from the delimited files into DB2 database tables for analysis. The format of the tables you need to create to hold the audit data may change from release to release.
Important: The script, db2audit.ddl, creates tables of the correct format to contain the audit records. You should expect to run db2audit.ddl for each release, as columns may be added or the size of an existing column may change.
40
40
Reference: Student Notes Only
Using CHECKING eventsIn most cases, when working with CHECKING events, the object type field in the audit record is the object being checked to see if the required privilege or authority is held by the user ID attempting to access the object. For example, if a user attempts to ALTER a table by adding a column, then the CHECKING event audit record indicates the access attempted was “ALTER” and the object type being checked was “TABLE” (not the column, because it is table privileges that are checked). However, when the checking involves verifying if a database authority exists to allow a user ID to CREATE or BIND an object, or to DROP an object, then although there is a check against the database, the object type field will specify the object being created, bound, or dropped (rather than the database itself). When creating an index on a table, the privilege to create an index is required, therefore the CHECKING event audit record has an access attempt type of “index”rather than “create”.
Audit records created for binding a package When binding a package that already exists, then an OBJMAINT event audit record is created for the DROP of the package and then another OBJMAINT event audit record is created for the CREATE of the new copy of the package.
Using CONTEXT event information after ROLLBACKData Definition Language (DDL) may generate OBJMAINT or SECMAINT events that are logged as successful. It is possible however that following the logging of the event, a subsequent error may cause a ROLLBACK to occur. This would leave the object as not created; or the GRANT or REVOKE actions as incomplete. The use of CONTEXT events becomes important in this case. Such CONTEXT event audit records, especially the statement that ends the event, indicates the nature of the completion of the attempted operation.
The load delimiterWhen extracting audit records in a delimited format suitable for loading into a DB2 database table, you should be clear regarding the delimiter used within the statement text field. This can be done when extracting the delimited file, using: db2audit extract delasc delimiter <load delimiter> The load delimiter can be a single character (such as ?) or a four-byte string representing a hexadecimal value (such as “0xff”). Examples of valid commands are: db2audit extract delasc db2audit extract delasc delimiter ! db2audit extract delasc delimiter 0xff If you have used anything other than the default load delimiter as the delimiter when extracting, you should use the MODIFIED BY option on the LOAD command. A partial example of the LOAD command with “0xff” used as the delimiter follows: db2 load from context.del of delmodified by chardel0xff replace into ... This will override the default load character string delimiter which is ? (double quote).
41
Monitoring Audit Time Spent Waiting for Resources• Standard Wait time statistics:
– total_wait_time - Total wait time– agent_wait_time - Agent wait time– pool_read_time - Total buffer pool physical read time– pool_write_time - Total buffer pool physical write time– client_idle_wait_time - Client idle wait time– direct_read_time - Direct Read Time– direct_write_time - Direct write time– fcm_recv_wait_time - FCM receive wait time– fcm_send_wait_time - FCM send wait time– ipc_recv_wait_time - Interprocess communication received wait time – ipc_send_wait_time - Interprocess communication send wait time– tcpip_recv_wait_time - TCP/IP receive wait time– tcpip_send_wait_time - TCP/IP send wait time– lock_wait_time - Time waited on locks– log_disk_wait_time - Log disk wait time– log_buffer_wait_time - Log buffer wait time
The visual lists the monitor elements that show how much time was spent waiting for different reasons. These can be used to determine if a system might have a performance bottleneck related to logging, disk I/Os, locking or network performance problems.
The list of detailed wait times includes any wait times associated with writing diagnostic messages or recording database audit records.
For DPF partitioned databases, there are a series of statistics that show how much time was spent waiting for data to be sent or received within the FCM component.
42
Listing db2auditd USR and SYS CPU TimeList of all EDUs for database partition 0
The db2pd –edus shows SYS and USR CPU for database audit facility when db2auditd function is running.
43
Auditing Using IBM GuardiumIBM InfoSphere Guardium Database Security• Supports heterogeneous database environments – strategic direction• Central management for all databases (DB2 and other vendors)• No changes to databases• Minimal overhead• Customized reporting• S-TAP: A lightweight (2-4% server impact), host-based software probe to
monitor network and local database traffic• S-GATE: A host-based agent for blocking unauthorized access to sensitive
data by privileged users• Collector: Collects data from S-TAP and performs real-time analyses and
creates audit trails to identify unauthorized activities• Central Policy Manager: Provides single unified set of audit policies,
aggregates and normalizes audit information across all DBMS platforms, applications and data centers for enterprise wide compliance reporting
IBM InfoSphere Guardium Database Security is a separately licenced product.
IBM InfoSphere Guardium is a highly scalable, database activity monitoring system that is able to collect audit information on databases at an extremely fine grained level of detail with almost no performance impact for the database. InfoSphere Guardium's architecture also ensure a true separation of duties, and can prevent data leaks both from internal and external threats. InfoSphere Guardium is also able to detect vulnerabilities within databases, helping prevent leaks before they occur. Finally, InfoSphere Guardium integrates with the enterprise and supports a wide variety of database management systems, reducing the complexity of enterprise compliance systems.
Melanie StopferInsert Company Name [email protected]: G15Who's Knocking at Your Door? DB2 LUW Database Auditing
