Db2 for IBM i S-TAP

You can use the Guardium Db2 for i S-TAP® to monitor and report on any database access on IBM i. This includes any programs, such as RPG, that use native database I/O operations or SQL access.

You can use information gathered by the Guardium Db2 for i S-TAP to create activity reports, help you meet auditing requirements, and generate alerts of unauthorized activity. Detailed auditing information includes:

Session start and end times
TCP/IP address and port
Object names (for example, tables or views)
Users
SQLSTATEs
Job and Job numbers
SQL statements and variables
Client special register values
Interface information, such as ODBC, ToolboxJDBC, Native JDBC, .NET, and so on

The S-TAP receives data from two sources:

SQL Performance Monitor (otherwise known as database monitor) data for SQL applications
Audit entries from the QSYS/QAUDJRN audit journal for applications using non-SQL interfaces

Data from these sources includes:

Any SQL access whether it is initiated on the IBM i server or from a client
Any native access that is captured in the audit journal

The S-TAP sends this data to the Guardium® system in real time.

Note: The Db2 for IBM i S-TAP supports basic S-TAP features only. Features such as blocking, query rewrite, and FAM are not supported.

For more information about the Db2 for i S-TAP and related topics, see:

i S-TAP for encryption, load balancing, and failover

The IBM i S-TAP supports TLS encryption and S-TAP session load balancing/failover.

Note: i S-TAP TLS support and load balancing is supported only for IBM i 7.1 and 7.2.

Similar to UNIX S-TAPs, i S-TAP configuration parameters are saved in a guard_tap.ini file in the /usr/local/guardium directory on the IBM i server.

Administrators configure the S-TAP is done using the same APIs and UI (S-TAP Control) as other UNIX S-TAPS. When the GUI or API is used to make a change to the S-TAP configuration, the Guardium sniffer sends a message to the S-TAP, which backs up the old .ini file, saves the configuration to the new .ini file and then restarts itself.

Administrators can set up encrypted communication between the S-TAP and the appliance using the S-TAP configuration controls as well as set up various load balancing options.

Using S-TAP failover and load balancing

The failover and load balancing options for the i S-TAP are similar to what exists for UNIX S-TAPs. Use the participate_in_load_balancing parameter to determine whether to use failover or load balancing behavior, and use the SQLGuard sections of your S-TAP to set up primary, secondary, and tertiary Guardium hosts.

One difference is that there is no need for participate_in_load_balancing=3; because of the way the I S-TAP communication is architected, complete session information is available on each message. This means that even before the enhancements delivered in this patch, you could have used hardware balancing (such as F5) with participate_in_load_balancing=1 and a virtual IP address in the primary SQLGuard section of the configuration file.

In a failover configuration, the S-TAP is configured to register with multiple collectors, but only send traffic to one collector at a time (participate_in_load_balancing=0). The S-TAP in this configuration sends all its traffic to one collector unless it encounters connectivity issues to that collector that triggers a failover to a secondary collector.

How to use AppEvent from IMS

The data holding user information of an APP_EVENT DLI call needs to have similar syntax as GuardAppEvent api.

The first two bytes represent ccsid of the encoding of the following bytes. For example, 0x04B8 stands for ccsid 1208. The following bytes need to have the syntax as below:

SELECT

‘GuardAppEvent:Start’,

‘GuardAppEventType:type’,

‘GuardAppEventUserName:name’,

‘GuardAppEventStrValue:string’,

‘GuardAppEventNumValue:number’,

‘GuardAppEventDateValue:date’

FROM DUAL

For further reference for type, name, string, number, date, check GuardAppEvent API.

Currently, only UTF8 encoding is supported.