Linux-UNIX: A-TAP configuration and activation

Configure and activate each Application TAP (A-TAP).

Before you begin

Verify the following prerequisites are met:
  • 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 guardium group. If the guardium group was created in LDAP, then create a local group called guardium with the same group ID (when authorizing the DB user it is added to this group), or add the guardium group ID (GID) to the DB user in /etc/passwd. For a shell installation, if the inspection engine db_user is 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_user specified in the instance configuration, and must be specified as the db_user for 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}.
Authorizing the user is optional. If you have 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.

Procedure

  1. Verify ktap_installed=1 in the guard_tap.ini file.
  2. Log off from all active database sessions and stop the database. It is very important that all processes with database admin user are stopped. For example, on Oracle, issue the command ps -ef | grep oracle
  3. As root user, authorize the database administrative user to log traffic by using the guardctl utility with the authorize-user command: <guardium_base>/xxx/guardctl authorize-user <user-name>
    For example:
    shell installer with postgres authorize user
    /usr/local/guardium/guard_stap/guardctl authorize-user postgres Authorizing user 'postgres' to log traffic
    shell installer with postgres verify authorization
    /usr/local/guardium/guard_stap/guardctl is_user_authorized postgres User 'postgres' is authorized.
    GIM installation with postgres authorize user
    /usr/local/guardium/modules/ATAP/current/files/bin/guardctl authorize_user postgres Authorizing user 'postgres' to log traffic
    shell installer example with Greenplum authorize user
    /usr/local/guardium/guard_stap/guardctl authorize-user <gpadmin> Authorizing user '<gpadmin>' to log traffic
    Note: If you're using MongoDB, restart the mongod-mms-auto process.
  4. Store the configuration parameters.
    1. Configure the required parameters for your database type and platform. For more information, see Linux-UNIX: Database-specific guardctl parameters.
      The following parameters are required across all databases to activate A-TAP:
      • --db-instance is the database instance identifier
      • --db-user is the database user name
      • --db-type is the type of database system
      • --db-home is the database home directory path
      • --db-version is the database version number
    2. Store the configuration for the database instance by using the store-conf command of the guardctl utility as follows: <guardium_base>/xxx/guardctl db_instance=<instance> [<name>=<value> ...] store-conf
    For example:
    shell installer Oracle on Linux store-conf
    /usr/local/guardium/guard_stap/guardctl --db-user=oracle11 --db-type=oracle --db-instance=on12rh60 --db-home=/home/oracle11/product/11.1.0/db_1 --db-version=11.2 store-conf
    GIM installation Oracle on Linux store-conf
    /usr/local/guardium/modules/ATAP/current/files/bin/guardctl db_instance=$ORACLE_SID db_home=$ORACLE_HOME db_type=oracle db_user=oracle12 db_version=12 store-conf
    shell installer Greenplum on Linux store-conf
    /usr/local/guardium/guard_stap/guardctl --db-user=<gpadmin> --db-type=greenplum –db-home=<db_user home directory> --db-instance=<greenplum> --db-base==<db_user home directory> store-conf
    Note: Instrumentation is done automatically during activate; there is no explicit instrumentation.
  5. Activate A-TAP.
    1. Enter <guardium_base>/xxx/guardctl db_instance=<instance> activate.
      For example:
      shell installer Oracle on Linux activate
      /usr/local/guardium/guard_stap/guardctl --db-instance=onrh60x activate
      GIM installation Oracle on Linux activate
      /usr/local/guardium/modules/ATAP/current/files/bin/guardctl --db-instance=onrh60x activate
      shell installer Greenplum on Linux activate
      /opt/guardium/guard_stap/guardctl --db-type=greenplum --db-home=/usr/local/greenplum-db-4.3.4.0 --db-user=gpadmin --db-instance=greenplum --db-base=<db_user home directory> activate

      You can activate and deactivate A-TAP by using the Encryption checkbox of the inspection engine configuration in the Guardium GUI. However, there are no advantages to activating it in the GUI. This option is not available for Linux platforms.

    2. Confirm that the instances are activated by using the list-active command of the guardctl utility: <guardium_base>/xxx/guardctl list-active

      For example: <guardium_base>/xxx/guardctl list-active oracle

  6. Start the database server.
  7. For Sybase IQ 16.1 SP04 and later, take the following steps to enable retrieval of the database user before you activate the A-TAP.
    1. Create a stored procedure that calls the function 'guard' in the Sybase IQ A-TAP library:
      (DBA)> create or replace procedure CGuard ( in p1 long varchar, in p2 long varchar) external name 'guard@/usr/lib64/libguard-atap-sybaseiq-any-64.so'
      If the GNU C library (glibc) is earlier than version 2.34, test that the call succeeds by executing the following command and verifying that it doesn't report an error. You can ignore the error messages if glibc is equal to or later than version 2.34.
      (DBA)> call CGuard(connection_property('UserID'),connection_property('Number'))
    2. Create a login procedure:
      (DBA)> create or replace procedure dba.login_msg_user() begin call dbo.sp_login_environment; call CGuard(connection_property('UserID'),connection_property('Number')); end
    3. Grant execute permissions to PUBLIC for the login procedure:
      (DBA)> grant execute on DBA.login_msg_user to PUBLIC
    4. Set the login procedure to execute for PUBLIC:
      (DBA)> set option PUBLIC.login_procedure='DBA.login_msg_user'
    Tip: After you activate the A-TAP, use the ps -ef | grep dataserver command to report on the running Sybase process (rather than showserver).