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.

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 only)
guardium_cassandra_audit-4.0.jar (for the query handler, versions 4.0 and higher)

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 cassandra user has the proper permissions to read them.

Apache Cassandra auditing supports multi-tenancy.

Procedure

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

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.

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

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>

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
```
To enable AUTH logging on, 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 PasswordAuthenticate, 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.
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
Set Java environment variables. For example,
```
JVM_OPTS="$JVM_OPTS $JVM_EXTRA_OPTS"
```

What to do next

Optionally, you can choose to decode the username during a failed login. To add the decoding functionality, use 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. You can optionally switch out the decoder for PasswordAuthenticator for a different decoder, which must be provided by the implementor of the custom authenticator. To specify the replacement decoder, add the following to JVM_EXTRA_OPTS (default-included decoder for PasswordAuthenticator 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);
}