Linux-UNIX: A-TAP configuration and activation
Configure and activate each Application TAP (A-TAP).
Before you begin
- S-TAP® and K-TAP are installed.
- If the software is installed with Guardium® Installation Manager (GIM), verify that GIM_ROOT_DIR is the absolute path to the modules. For example: /usr/local/guardium/modules.
- The user must be authorized for the
guardiumgroup. If theguardiumgroup was created in LDAP, then create a local group calledguardiumwith the same group ID (when authorizing the DB user it is added to this group), or add theguardiumgroup ID (GID) to the DB user in /etc/passwd. For a shell installation, if the inspection enginedb_useris specified, then you don't need to authorize the user even in an LDAP environment.
About this task
There are two methods of managing your A-TAPs: either as user root for all functions, or as a db user. The db user option can configure, activate, deactivate, and instrument A-TAP, but cannot perform all functions. This means that the non-root user can handle day to day activities of the A-TAP, without requiring the root user. The guardctl help window lists the permitted commands for the logged-in user. The functionality is:
- When activating an A-TAP instance not as root, the current user must be the
db_userspecified in the instance configuration, and must be specified as thedb_userfor the matching inspection engine in the S-TAP configuration. - A non-root user cannot manage (configure, active, deactivate, and instrument) an A-TAP instance that was initially configured by the root user.
- The root user can activate and deactivate a non-root created A-TAP instance, but must specify the instance name as
${DB_USER}/${DB_INSTANCE}.
db_user specified in the guard_tap.ini file, you don't need to authorize the user, but you still can. If db_user is not specified in the guard_tap.ini file, you must authorize the user and cannot perform any actions as non-root with guardctl.