Linux-UNIX: Configuring Apache Cassandra and S-TAP for auditing interception

Configure Apache Cassandra and S-TAP to monitor encrypted traffic on Apache Cassandra. Monitoring includes authorization messages for login, normal SQLs, prepared statements, batch statements, bind variables, and bound values. This configuration does not require an inspection engine or K-TAP.

Before you begin

The user who runs the Cassandra database must be authorized to write to the Cassandra pipe in the S-TAP directory. Use guardctl authorize-user to add the user to the Guardium group.

When you copy the JAR files to the cassandra directory, make sure that the Cssandra user has the proper permissions to read them.

About this task

Limitations: Apache auditing does not include SOURCE_PROGRAM, SERVER_OS, CLIENT_OS, DB_PROTOCOL_VERSION, or OS_USER.

To configure Apache Cassandra and S-TAP for auditing, configure a logback to write to the S-TAP Cassandra audit reader in the same directory as the guard_stap .cassandra_audit executable. The logback is created when you enable Cassandra Audit in the S-TAP configuration. Specify the value for cassandra_audit_delimiter in the output string for logback.

The following JAR files for this configuration are part of the S-TAP installation. They are located in the directory where the S-TAP is installed, which is often, but not always, in /usr/local/guardium/guard_stap:
  • guardium_cassandra_audit-3.4.jar (for the query handler, versions 3.4 to 3.10)
  • guardium_cassandra_audit-3.11.jar (for the query handler, version 3.11 to 4.0)
  • guardium_cassandra_audit-4.0.jar (for the query handler, versions 4.0 to 4.15)
  • guardium_cassandra_audit-4.1.jar (for the query handler, versions 4.1.6 and higher)

Apache Cassandra auditing supports multi-tenancy.

Procedure

  1. Copy the relevant JAR files to the Cassandra lib directory so that the database can find and use them.
    For example,
    • Non-GIM S-TAP:
      cp -p /usr/local/guardium/guard_stap/guardium_cassandra_audit-4.0.jar /usr/share/cassandra/lib
    • GIM S-TAP:
      cp -p /usr/local/modules/STAP/current/guardium_cassandra_audit-4.0.jar /usr/share/cassandra/lib
  2. Enable Cassandra auditing in S-TAP by setting the cassandra_audit_enabled=1. You can set this parameter from the GUI, by editing the guard_tap.ini file, or by using the update_stap_config grdapi function.
  3. Authorize the cassandra user to write to the Cassandra pipe in the S-TAP directory.
    For example,
    • Non-GIM S-TAP:
      /usr/local/guardium/guard_stap/guardctl --db-user=cassandra authorize-user
    • GIM S-TAP:
      /usr/local/guardium/modules/ATAP/current/files/bin/guardctl –db-user=cassandra authorize-user
  4. Edit the logback.xml configuration file as shown in the following example. 
    <appender name="Guardium" class="ch.qos.logback.core.FileAppender">
<file>/usr/local/guardium/guard_stap/.cassandra_audit</file>
<immediateFlush>true</immediateFlush>
<encoder>
<pattern>%msg{}GUARD_DELIM</pattern>
</encoder>
</appender>
<logger name="com.ibm.guardium" level="INFO">
<appender-ref ref="Guardium"/>
</logger>
    • Non-GIM S-TAP:
      <file>/usr/local/guardium/guard_stap/.cassandra_audit</file>
    • GIM S-TAP:
      <file>/usr/local/modules/STAP/current/.cassandra_audit</file>
  5. Change jvm.options to enable the custom_query_handler_class to call into the logging mechanism by setting JVM_EXTRA_OPTS to include the following line. 
    Dcassandra.custom_query_handler_class=com.ibm.guardium.CassandraQueryHandler
  6. To enable AUTH logging, when users connect to the database, set a property in JVM_EXTRA_OPTS so that the logging mechanism can correctly redirect auth requests.
    For example, if you use PasswordAuthenticator, add the following statement to JVM_EXTRA_OPTS.
    -DGuardiumBaseAuthenticator=org.apache.cassandra.auth.PasswordAuthenticator
    Then, instead of specifying PasswordAuthenticator in cassandra.yaml, you can use com.ibm.guardium.CassandraAuthenticator.
  7. The default role manager (CassandraRoleManager) explicitly checks for PasswordAuthenticator. Therefore, if you enable AUTH logging, you also need to change role_manager in cassandra.yaml.
    Set role_manager to com.ibm.guardium.GuardCassandraRoleManager and specify an additional property in JVM_EXTRA_OPTS for the role manager to use.
    For example, -DGuardiumBaseRoleManager=org.apache.cassandra.auth.CassandraRoleManager
  8. Set the Java environment variables.
    The following example shows the setting for the Java environment variable:
    JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"

What to do next

If you choose to decode the username during a failed login, add the decoding function by using a class that can understand the format that you are using. Since Cassandra can be extended to use custom authenticators, this format might differ from the base PasswordAuthenticator, which uses SASL. Guardium provides a decoder that works for PasswordAuthenticator. If you choose to replace the decoder for PasswordAuthenticator, the implementor of the custom authenticator must provide a different decoder. To specify the replacement decoder, add the following to JVM_EXTRA_OPTS, the default-included decoder for PasswordAuthenticator is shown: 
-DGuardiumBaseAuthenticatorDecoder=com.ibm.guardium.GuardPasswordAuthenticatorDecoder
The interface for the replacement authenticator is as follows:
package com.ibm.guardium;
import java.nio.ByteBuffer;
public interface IGuardAuthenticatorDecoder
{
    String getUsername(byte[] clientResponse);
}